41–50 of 112 posts
I wonder how often it'd be possible to deduce that an overflow is not possible from the context. (For example, if we've just checked that INT_MAX/a > b before doing a*b.)
The cost of doing it in software is just a highly predictable (not taken) branch after every integer arithmetic operation that the compiler can't prove stays within bounds. The article presents no data on this cost. I have none to hand either, but I'm going to predict that on a modern CPU with typical workloads it will be small enough that it would be very hard to measure.
The article speaks as though doing it in hardware would be free, but that's very far from true. The hardware solution might have a nominal cost of 'zero clock cycles' where overflow doesn't occur, but extra transistors in critical, heavily used parts of the CPU core would be burning a small but nonzero amount of energy all the time even on code that doesn't use the overflow check - i.e. the vast majority.
If you think overflow check is a great feature (of which personally I'm not at all convinced), go ahead and add it to a new language or provide it as a library function in an existing language. But imposing it as an inescapable tax on all hardware makes no sense whatsoever.
Earlier quoted context omitted.
Checks are the smallest cost of bignums. Dynamic allocation isn't free, it's terribly expensive. Dereferencing pointers isn't free, it's terribly expensive. It's one thing for a scripting language (where people expect poor, inconsistent performance) to have automatic bignums but it's quite another for a language in which people will be writing performant code to have automatic bignums. They introduce a thousand diffi…
Isn't the alternative introducing a thousand difficult-to-debug edge cases that cause your code to produce incorrect output, or crash? I'd rather the default setup be "can be slow sometimes". If you're writing performance-sensitive code where you want to control the overflow behavior, make that an option, but not the default. In the context of Swift, it would make a lot of sense to me for Int to be a bignum with no b…
1. There is a large class of languages where they do not make sense as a default.
2. The most sensible approach is to fastlane the all-int native case, but this comes at the cost of a preciptitous drop in speed the moment even a single bignum happens.
> Isn't the alternative introducing a thousand difficult-to-debug edge cases that cause your code to produce incorrect output, or crash?
Unintentional bignums are usually bugs, so incorrect output / crash is usually the best one could hope for anyway. People understand that programs have bugs and crash, but the combination of slowness with incorrect output is a special recipe for infuriated users (I waited 30 minutes for the file to load and then it crashed?!?!).
x86 processors already have overflow and carry bits in their flags register to tell when overflow has occurred. It makes more sense to me to have compiler writers check the flags if they care about overflow, and avoid the slow down if they don't.
I wonder how often it'd be possible to deduce that an overflow is not possible from the context. (For example, if we've just checked that INT_MAX/a > b before doing a*b.)
It's a little amusing that x86 has the INTO instruction, a single byte opcode at position CEh, that was designed specifically for this purpose and was there since the 8086, but when AMD designed their 64-bit extensions, it turned into an invalid instruction (and Intel was forced to go along, presumably for compatibility.) A rather shortsighted move, I think; instead of having a possibly useful (but not previously oft…
Those instructions generate an interrupt; you'd have to define the OS ABI to make those instructions trap back to the application in a catchable way.
Earlier quoted context omitted.
Those instructions generate an interrupt; you'd have to define the OS ABI to make those instructions trap back to the application in a catchable way.
If you put the INTO immediately after the overflowing instruction, the OS could just go back one instruction (harder than it seems, but not impossible). Wouldn't that work?
Also, you almost certainly don't want to just go back an instruction; you want to catch and handle the overflow.
Earlier quoted context omitted.
The entire premise of the linked article is that doing it the way you suggest is too expensive for the common case, where no overflow happens. Further, it implicitly asserts that the cost of a hardware trap/exception, while great, will be offset by the savings from the common case. Now, it doesn't back these assertions with much data, but neither do you :)
The problem is that potentially-overflowing integer instructions make a real mess out of things like out-of-order execution and speculative execution. For data to back this, see your favorite computer architecture reference, particularly anything that discusses the consequences of highly-complex instructions in things like the VAX.
I think the article overstates the cost of doing this in software and understates the cost of doing it in hardware. The cost of doing it in software is just a highly predictable (not taken) branch after every integer arithmetic operation that the compiler can't prove stays within bounds. The article presents no data on this cost. I have none to hand either, but I'm going to predict that on a modern CPU with typical w…
Personally, I'd like to see more programming done in languages that simply don't allow integer overflow in the first place. Most current languages have arbitrary-precision integers; well-implemented arbitrary-precision integers are quite efficient when they fit in a machine word, and as efficient as possible when larger. Sure, you'll lose a bit of performance due to checks for overflow, but those checks need to exist…
Checks are the smallest cost of bignums. Dynamic allocation isn't free, it's terribly expensive. Dereferencing pointers isn't free, it's terribly expensive. It's one thing for a scripting language (where people expect poor, inconsistent performance) to have automatic bignums but it's quite another for a language in which people will be writing performant code to have automatic bignums. They introduce a thousand diffi…