Hacker News Reader

Comment by tikhonj | Hacker News Reader

This is what happens when we let machine constraints trump semantics.

When you say int, you usually want an actual integer, not an integer with an arbitrary limit. In this day and age, having that limit there is simply premature optimization.

I think having a nice bignum type--one that looks and feels just like a normal numeric type--is very important. It should also probably be the default; you should only switch to a machine type if you have a good reason. With gmp, big integers perform well enough to be used widely.

View on HN

> In this day and age, having that limit there is simply premature optimization.

You say this with certainty. Do you know of studies of real-world programs where machine-sized integers were replaced whole-sale with bignums?

All Ruby code does this. Mathematics can still be performant because of tagged pointers. If the MSB is set, the value is a Ruby object. If it's not set, the value should be considered a native data type.

Perhaps I should have been more specific. I know that there are languages that have this property. My question is if there are studies on the performance impact. Preferably in a language that is suitable for high-performance applications (like games).

The python example is good here, because originally the Python language had separate types for unbounded-integer and machine-sized-int. This happened as part of the move from Python 2.x to Python 3.x, right along with changing strings from byte-arrays to unicode.[1]

There has been lots of fuss and even pushback about the change to use unicode instead of byte arrays, but I have never heard anyone complain about semantics OR performance of the switch to a single integer type.

[1] - http://www.python.org/dev/peps/pep-0237/

Everything written in Python has the automatic promotion from C longs to bignums when the result no longer fits: see http://docs.python.org/2/library/stdtypes.html#numeric-types...

Depends on the situation.

I assume this was probably a server side bug, since all the accounting would never be trusted to the client side.

If you are writing highly-performant server code, the actually memory size is extremely important. You cannot (should not) abstract away the machine specifics of the datatype if you want to write optimized code.

In some cases where the underlying datatype isn't a concern (e.g. Javascript), I agree with you. But ultimately, this isn't a failure of technology, it is a failure of the software development process.

Most servers are x86-64 these days. So using 32 bit signed ints barely improves performance at all. Could have gone with a 64 bit unsigned int as it is a positive value all of the time.

A x64 CPU will take a single instruction to operate on a both a 64-bit and 32-bit integer, and the CPU registers are all 64-bit, so in that context you are right that it doesn't matter that much between the datatypes.

However, the physical size of the integer as stored in the CPU cache, RAM, and HDD is still going to be 2x as big for a 64-bit integer. In a hypothetical worst case, you are cutting your CPU cache and memory bandwidth in half, which is tragic.

Additionally, while most physical servers are x64, the OS, server software, and virtualization layer is still often 32-bit -- maybe for legacy, maybe for performance, maybe for a lot of reasons. Upgrading that whole stack up to 64-bits just for the luxury of having default 64-bit integers seems misguided.

Completely agree about big integers. I expect that the next generation of programming languages will offer a "number" type that's big integer or decimal by default, and then allow engineers to refine the type as an optimization. One trouble is the data storage layer - typical database fields are fixed size and don't naturally accommodate big integers. Thus where MMOs are concerned, using big integers will still require some deliberate effort.

Sounds like common lisp (though I doubt it was the first to have a flexible number type).

Lisp before Common Lisp had it. But the Common Lisp language sorted it out, such that other languages copied it partly.

python has this now after 2.5, iirc. it's handy when you want an unbounded calculator =D

Another approach is to have compile time checking of overflow or bounded numbers. There's been discussion about the utility of this on the Rust list recently and I wrote up some of my experience with languages that let you do checking: http://bluishcoder.co.nz/2013/05/07/ranged-integer-types-and...

Haskell is already doing this

Reply on news.ycombinator.com