3 ms·

> Are you really suggesting that because dealing with a bug takes longer your better off ignoring it and returning a huge negative number by default? You're lu

by exDM69 11y ago

> Are you really suggesting that because dealing with a bug takes longer your better off ignoring it and returning a huge negative number by default? You're lucky if you get a huge negative number. Signed integer overflow is undefined behavior and may have awkward consequences when coupled with compiler optimization. E.g. if(x+1 > x) may be replaced with if(true) legally. And this is why computers programs are fast. Yes, it may be a good idea to do something else in a high level language but if your kernel, web browser, etc were written with a nanny language that checks for every possible corner case for every operation, it would be painfully slow. Integer addition arithmetic is one of the most common operations your computer does, making that 2-10x or more slower would have catastrophic consequences. And despite all this "danger", your kernel and web browser and http server just work.

Retric 11y ago
CPU speed is rarely a limitation because RAM is just stupid slow, and in MIPS and Alpha CPU's with HW support it's a rounding error as in well under 1% for most code. Even software based overflow detection runs in the 5-10% range not 100-1,000% range your suggesting. PS: There are several models you can test yourself. http://blog.regehr.org/archives/1154 http://blog.regehr.org/archives/1154 edit: http://resources.sei.cmu.edu/asset_files/TechnicalNote/2010_004_001_15164.pdf http://resources.sei.cmu.edu/asset_files/TechnicalNote/2010_... Has actual benchmarks in the 6-8% range.
- wtallis 11y ago
  Yeah, it's pretty much a given that checking for overflow won't be the bottleneck when you're doing pointer arithmetic to traverse a large data structure. The memory accesses will dominate over the cost of the highly-predictable branches.
ScottBurson 11y ago
> Integer addition arithmetic is one of the most common operations your computer does, making that 2-10x or more slower would have catastrophic consequences. Common Lisp is a compiled language that has arbitrary-precision integer arithmetic by default. What we generally find is that in most kinds of code the cost of the conditional branch is negligible; it's dwarfed by memory access, function call, and other conditional logic in the program. There are, of course, exceptions. Most of these are array operations where one is doing a small amount of work on each of a large number of array elements; array index computations are a good example of a place where one doesn't generally want to pay the cost of overflow checking. For those situations, Common Lisp provides declarations one can write to cause the overflow checking to be skipped. The overall effect is far from catastrophic. Common Lisp is competitive with other compiled languages -- not the very fastest, perhaps, but definitely in that range, and a good 10 to 30 times faster than interpreted Python or Ruby -- languages in which a lot of code is being written these days. Now to this specific example. What would have happened if it were written in CL? If the programmer had not specified otherwise, the arithmetic would be done in arbitrary precision and would work correctly. That's clearly the correct choice in this case: even though an array index is being computed, it's effectively a random index from the hardware's point of view; cache prefetching will be no help at all. That being the case, the performance will be dominated by memory latency (at least to the L2 and L3 caches, if not all the way to main memory). Also, in many applications, the comparison between two elements will involve a function call; it won't be just an integer less-than instruction. So worrying about a couple of integer overflow tests would be pretty silly. I concede the possibility that, this argument notwithstanding, the programmer might have turned off overflow checking anyway. Well, you can shoot yourself in the foot in any language. Lisp just tries to make it not be the default.

by exDM69 11y ago

Retric 11y ago

CPU speed is rarely a limitation because RAM is just stupid slow, and in MIPS and Alpha CPU's with HW support it's a rounding error as in well under 1% for most code. Even software based overflow detection runs in the 5-10% range not 100-1,000% range your suggesting. PS: There are several models you can test yourself. http://blog.regehr.org/archives/1154 http://blog.regehr.org/archives/1154 edit: http://resources.sei.cmu.edu/asset_files/TechnicalNote/2010_004_001_15164.pdf http://resources.sei.cmu.edu/asset_files/TechnicalNote/2010_... Has actual benchmarks in the 6-8% range.

wtallis 11y ago
Yeah, it's pretty much a given that checking for overflow won't be the bottleneck when you're doing pointer arithmetic to traverse a large data structure. The memory accesses will dominate over the cost of the highly-predictable branches.

ScottBurson 11y ago

> Integer addition arithmetic is one of the most common operations your computer does, making that 2-10x or more slower would have catastrophic consequences. Common Lisp is a compiled language that has arbitrary-precision integer arithmetic by default. What we generally find is that in most kinds of code the cost of the conditional branch is negligible; it's dwarfed by memory access, function call, and other conditional logic in the program. There are, of course, exceptions. Most of these are array operations where one is doing a small amount of work on each of a large number of array elements; array index computations are a good example of a place where one doesn't generally want to pay the cost of overflow checking. For those situations, Common Lisp provides declarations one can write to cause the overflow checking to be skipped. The overall effect is far from catastrophic. Common Lisp is competitive with other compiled languages -- not the very fastest, perhaps, but definitely in that range, and a good 10 to 30 times faster than interpreted Python or Ruby -- languages in which a lot of code is being written these days. Now to this specific example. What would have happened if it were written in CL? If the programmer had not specified otherwise, the arithmetic would be done in arbitrary precision and would work correctly. That's clearly the correct choice in this case: even though an array index is being computed, it's effectively a random index from the hardware's point of view; cache prefetching will be no help at all. That being the case, the performance will be dominated by memory latency (at least to the L2 and L3 caches, if not all the way to main memory). Also, in many applications, the comparison between two elements will involve a function call; it won't be just an integer less-than instruction. So worrying about a couple of integer overflow tests would be pretty silly. I concede the possibility that, this argument notwithstanding, the programmer might have turned off overflow checking anyway. Well, you can shoot yourself in the foot in any language. Lisp just tries to make it not be the default.