3 ms·
He did not need the choice but others do. And he is wrong when he says it makes no difference whether you use a byte or eight of them. Yes, it will take the sam
by danbruc 12y ago
He did not need the choice but others do. And he is wrong when he says it makes no difference whether you use a byte or eight of them. Yes, it will take the same amount of time to add two of them but it will also cost eight times more cache space and memory bandwidth to move them around. It may not be an issue if you have a single number or ten of them but it certainly becomes one if you have an array with millions or billions of them.
- philosophus 12y agoI don't believe he said it makes no difference.
- danbruc 12y ago»But in todays CPUs there is no advantage using the short thing. You can add 64 bits or 8 bits, takes the same amount of time. And you look up what is the cash value of having saved seven bytes on a number. When you add that up it is zero. So there is no benefit.« [1] As long as you are concerned with adding a bit of eye candy and interactivity to a web page this may be true enough to get away with the JavaScript way of making every number a double precision floating point number but there a other domains where this will not fly. And even in the world of JavaScript asm.js is trying hard to overcome this limitation. [1] http://www.youtube.com/watch?v=bo36MrBfTk4&t=42m17s http://www.youtube.com/watch?v=bo36MrBfTk4&t=42m17s
- coldtea 12y ago>but there a other domains where this will not fly. Sure, and I believe everybody, including Doug, knows this not so subtle distinction. He wasn't talking about programming HPC for NASA.
- danbruc 12y agoHe is comparing Java and JavaScript and implies that it is a bad choice of Java to offer several options. And given the broad range of applications Java is used for I don't think this is a justifiable opinion.
- diroussel 12y agoBut in java (64-bit JVM) this statement is true: "You can add 64 bits or 8 bits, takes the same amount of time."
- rtpg 12y agoThere are use cases where you need the choice, but most people do not need the choice. Most programs written in the real world (enterprise-y Java apps) do not need strong control on GC, choice of integer types, or many other things offered to them. Reducing choice will increase code/tool quality. I think that we should make the uncommon choice reallllly hard to put into place. Make it a pain to configure the GC, give specific integer types really long names. Just stop people from premature optimization and leave these tools to people who know what they're doing.
- danbruc 12y agoIf you are unable to make good decision between different number types you better don't write software, IMHO. How do you reason about the operations you apply to your data if you are ignorant of the possible values?
- rtpg 12y agoI write software, and the amount of times I even have to explicitly manipulate numbers in a given week is very close to zero. Even iteration is done through iterators instead of indexes, so writing a plus sign is done pretty sparingly. Data manipulation beyond "pull out of database" or "submit user input to database" is a lot rarer in enterprise software like this than in scientific computing. I'm not saying it's bad to be aware of it, but software is more than numbers.
- danbruc 12y agoI develop enterprise software, too, and I definitely think it matters there, too. You better make sure your database columns have the correct number type or you will get in trouble if your inventory numbers or monetary values start showing rounding errors.
- ionforce 12y agoYou are comparing two different types of numbers. What was originally compared was different sized integral types. What you are comparing is two numeric types that have a large semantic gulf (fractions vs integers). So your point is disingenuous in the context of the former.