4 ms·

The garbage collector needs to know what things in memory are pointers/references and what things are actual data.

by kd0amg 12y ago

StefanKarpinski 12y ago
This seems like a strange tradeoff in that case. Most programs don't have a lot of "loose" integers lying around. Programs that have a lot of integer values tend to store them in arrays, which are themselves tagged and thus have all the information needed to do GC. To save a 64-bit tag per loose integer value (of which there usually aren't very many) this design sacrifices the performance of every integer operation, not to mention memory compatibility with C. I'm curious what kind of code motivated the choice.
- logicchains 12y ago
  It's not just loose 'integers'. I believe bools and simple variants are represented as ints, as are empty options.
  - StefanKarpinski 12y ago
    That's a non-sequitur. Bools require only a single bit and variants/enums don't need all 64 bits. Those are completely distinct cases from the integer case which is fundamental and performance-critical.
    - ufo 12y ago
      They are exactly the same as integers in that they are not pointers and thus count as dead-ends for the garbage collection algorithm. In theory, you could unbox some extra things at the cost of complicating the garbage collection algorithm and the memory representatio of values. GHC does this for Haskell but the Ocaml guys don't because they highly value keeping the compiler as simple as possible. By the way, integer tagging is only important if your code s heavy in arithmetic operations or floating point operations (Ocaml tries to unbox floating point arrays, but sometimes it has to box floats). This often not that big of a problem and in the worst case you can always link Ocaml with C if you really want to.
      - StefanKarpinski 12y ago
        > They are exactly the same as integers in that they are not pointers and thus count as dead-ends for the garbage collection algorithm. Except that they are not the same since bools and enums don't need 64 bits and you mostly don't do integer arithmetic with them. > In theory, you could unbox some extra things at the cost of complicating the garbage collection algorithm and the memory representatio of values. GHC does this for Haskell but the Ocaml guys don't because they highly value keeping the compiler as simple as possible. I'm unclear on how special-casing integers and foisting a lot of bit-twiddling on all integer operations makes the compiler less complicated. Treating all values uniformly and using machine arithmetic everywhere would seem to minimize compiler complexity and make things faster. > By the way, integer tagging is only important if your code s heavy in arithmetic operations or floating point operations (Ocaml tries to unbox floating point arrays, but sometimes it has to box floats). This often not that big of a problem and in the worst case you can always link Ocaml with C if you really want to. Noted: if you want to do numerical work in OCaml, use C ;-) But seriously, is there code that isn't heavy on integer arithmetic or floating point operations? Do computers do anything else?
        ufo 12y ago
        The bit twidling means that you can store any kind of Ocaml value in a single machine word. https://realworldocaml.org/v1/en/html/memory-representation-of-values.html https://realworldocaml.org/v1/en/html/memory-representation-... This makes the generated executables less efficient but it makes the lives of the compiler and garbage collector easier: Every single variable or function parameter has the same size and you can easily tell if a value is a pointer or not just by looking at it. In a way, its a little bit like executing bytecode in a virtual machine. The executable does some extra bit twiddling, boking and tagging but lots of things get simpler because of the uniform value representation. > But seriously, is there code that isn't heavy on integer arithmetic or floating point operations? Do computers do anything else? Lots of software nowadays is bottlenecked by the speed of network interfaces or RAM, meaning that the arithmetic speed isn't a big factor.
        StefanKarpinski 12y ago

The garbage collector needs to know what things in memory are pointers/references and what things are actual data.

by kd0amg 12y ago

The garbage collector needs to know what things in memory are pointers/references and what things are actual data.

This seems like a strange tradeoff in that case. Most programs don't have a lot of "loose" integers lying around. Programs that have a lot of integer values tend to store them in arrays, which are themselves tagged and thus have all the information needed to do GC. To save a 64-bit tag per loose integer value (of which there usually aren't very many) this design sacrifices the performance of every integer operation, not to mention memory compatibility with C. I'm curious what kind of code motivated the choice.

logicchains 12y ago
It's not just loose 'integers'. I believe bools and simple variants are represented as ints, as are empty options.
- StefanKarpinski 12y ago
  That's a non-sequitur. Bools require only a single bit and variants/enums don't need all 64 bits. Those are completely distinct cases from the integer case which is fundamental and performance-critical.
  - ufo 12y ago
    They are exactly the same as integers in that they are not pointers and thus count as dead-ends for the garbage collection algorithm. In theory, you could unbox some extra things at the cost of complicating the garbage collection algorithm and the memory representatio of values. GHC does this for Haskell but the Ocaml guys don't because they highly value keeping the compiler as simple as possible. By the way, integer tagging is only important if your code s heavy in arithmetic operations or floating point operations (Ocaml tries to unbox floating point arrays, but sometimes it has to box floats). This often not that big of a problem and in the worst case you can always link Ocaml with C if you really want to.
    - StefanKarpinski 12y ago
      > They are exactly the same as integers in that they are not pointers and thus count as dead-ends for the garbage collection algorithm. Except that they are not the same since bools and enums don't need 64 bits and you mostly don't do integer arithmetic with them. > In theory, you could unbox some extra things at the cost of complicating the garbage collection algorithm and the memory representatio of values. GHC does this for Haskell but the Ocaml guys don't because they highly value keeping the compiler as simple as possible. I'm unclear on how special-casing integers and foisting a lot of bit-twiddling on all integer operations makes the compiler less complicated. Treating all values uniformly and using machine arithmetic everywhere would seem to minimize compiler complexity and make things faster. > By the way, integer tagging is only important if your code s heavy in arithmetic operations or floating point operations (Ocaml tries to unbox floating point arrays, but sometimes it has to box floats). This often not that big of a problem and in the worst case you can always link Ocaml with C if you really want to. Noted: if you want to do numerical work in OCaml, use C ;-) But seriously, is there code that isn't heavy on integer arithmetic or floating point operations? Do computers do anything else?
      - ufo 12y ago
        The bit twidling means that you can store any kind of Ocaml value in a single machine word. https://realworldocaml.org/v1/en/html/memory-representation-of-values.html https://realworldocaml.org/v1/en/html/memory-representation-... This makes the generated executables less efficient but it makes the lives of the compiler and garbage collector easier: Every single variable or function parameter has the same size and you can easily tell if a value is a pointer or not just by looking at it. In a way, its a little bit like executing bytecode in a virtual machine. The executable does some extra bit twiddling, boking and tagging but lots of things get simpler because of the uniform value representation. > But seriously, is there code that isn't heavy on integer arithmetic or floating point operations? Do computers do anything else? Lots of software nowadays is bottlenecked by the speed of network interfaces or RAM, meaning that the arithmetic speed isn't a big factor.
        StefanKarpinski 12y ago