4 ms·

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 li

by tikhonj 14y ago

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.

jcrites 14y ago
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.
- aidenn0 14y ago
  Sounds like common lisp (though I doubt it was the first to have a flexible number type).
  - lispm 14y ago
    Lisp before Common Lisp had it. But the Common Lisp language sorted it out, such that other languages copied it partly.
- hedgie 14y ago
  python has this now after 2.5, iirc. it's handy when you want an unbounded calculator =D
vinkelhake 14y ago
> 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?
- stouset 14y ago
  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.
  - vinkelhake 14y ago
    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).
    - mcherm 14y ago
      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/ http://www.python.org/dev/peps/pep-0237/
- acdha 14y ago
  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-int-float-long-complex http://docs.python.org/2/library/stdtypes.html#numeric-types...
mckilljoy 14y ago
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.
- UnoriginalGuy 14y ago
  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.
  - mckilljoy 14y ago
    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.
hebz0rl 14y ago
Haskell is already doing this
doublec 14y ago
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-bounds-checking.html http://bluishcoder.co.nz/2013/05/07/ranged-integer-types-and...

by tikhonj 14y ago

jcrites 14y ago

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.

aidenn0 14y ago
Sounds like common lisp (though I doubt it was the first to have a flexible number type).
- lispm 14y ago
  Lisp before Common Lisp had it. But the Common Lisp language sorted it out, such that other languages copied it partly.
hedgie 14y ago
python has this now after 2.5, iirc. it's handy when you want an unbounded calculator =D

vinkelhake 14y ago

> 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?

stouset 14y ago
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.
- vinkelhake 14y ago
  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).
  - mcherm 14y ago
    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/ http://www.python.org/dev/peps/pep-0237/
acdha 14y ago
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-int-float-long-complex http://docs.python.org/2/library/stdtypes.html#numeric-types...

mckilljoy 14y ago

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.

UnoriginalGuy 14y ago
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.
- mckilljoy 14y ago
  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.

hebz0rl 14y ago

Haskell is already doing this

doublec 14y ago

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-bounds-checking.html http://bluishcoder.co.nz/2013/05/07/ranged-integer-types-and...