9 ms·
Whenever I get back into Clojure and use type hinting, I usually forget that Clojure doesn't allow ints, only longs. Kind of a strange choice given the JVM supp
by gleenn 10y ago
Whenever I get back into Clojure and use type hinting, I usually forget that Clojure doesn't allow ints, only longs. Kind of a strange choice given the JVM supports signed variants of the common word lengths. But then I read articles like this.
I'm a pretty high-level language user (read: I don't do C, et al), so when I read stuff like this it always makes me cringe and be happy Hickey decided to keep it simple. 64 bits, everywhere! (God save us when things go to 128)
- marcosdumay 10y ago> God save us when things go to 128 That will take a while. And even then, people will likely keep using 64 bits for most things.
- jdright 10y agoSomeone said that about 64 bits.
- mikeash 10y agoAnd 32 bits! Probably 16 bits too.... But, it takes longer each time. With exponential growth (e.g. Moore's Law) then you use up bits linearly. If you double every two years, then you use one bit every two years. That means we have about 32 years from when 32-bit became inadequate to when 64-bit becomes inadequate.
- _ph_ 10y agoAnd with Moores Law running out of steam (isn't physics a bitch!) this might not even ever happen. At least not in the sense which drove us up to 64 bit. There are of course plenty of reasons why we would like to do math with 128 or more bits, but for memory addresses, 64 bit are a plenty.
- Dylan16807 10y ago64 bits are fine until you want to share address space over a whole bunch of nodes. We currently have supercomputers with tens of gigabytes per processor and tens of thousands of processors. Already up to 51 bits. We're also working out fast persistent storage like NVMe and crosspoint that allow us to attach a board with terabytes where we used to attach gigabytes of DRAM. Combine those two and you can max out a 64 bit address space with current technology, let alone tomorrow's technology.
- LukeShu 10y agoRemember that each bit doubles the space. You would need 50,000 processors with 350 terabytes of memory each to hit 64 bits. Then again, super computers aren't really running the same architecture as the rest of us.
- Dylan16807 10y agoSo let's crunch the numbers a bit. There are already supercomputers with 40k CPUs, let's go all out and plan to use 80k CPUs. 8TB NVMe cards have been out for a couple years, we should be able to get 16TB cards by the time we're assembling. We should be able to fit four per CPU with a compact design. That gets us to 5EB. That's dangerously close to the 16EB limit, and that's with 2016/2017 technology. And the point where you start having trouble isn't 16EB, it's under 8EB, when you stop being able to use the normal user/kernel split or have all the memory mapped into kernel space. > Then again, super computers aren't really running the same architecture as the rest of us. Sure, but there are pushes to make datacenters act more like a giant computer, so there are niceties to a shared address space that aren't restricted to traditional supercomputers.
- gaius 10y agoYou say that but SSI is bound to become fashionable again at some point.
- IshKebab 10y agoI doubt we'll ever have more than 2^64 bytes of RAM, so that will probably never happen. (Please don't make the obvious reply.)
- marcosdumay 10y agoEven if we have more than 2^64 bytes (that's 16 EB, not really an astronomical amount) of RAM, it's not obvious that the optimum way to use them will be by placing everything at the same address space.
- simcop2387 10y agoYea i'd fully expect something like PAE to be more useful and common. Even if something is using more than 16EB of ram, i can't imagine it'll be a single process and instead it'll be larger distributed system instead, leaving each process smaller than that. Just filling up 16 EB of ram right now would take: < simcop2387> farnsworth: eta[16 EiB, 19200 MiB/s] - #now# -> "years" < farnsworth> simcop2387: 2177.63532452879 years based on marketing info on DDR4. So at the very least it's going to take a while before we even have to worry about a max of 16EiB in address space.
- cpeterso 10y agoLarger address spaces are useful, even if you don't have 2^64 bytes of physical RAM. For example, most 32-bit Firefox crashes are OOM crashes due to virtual address space exhaustion.
- kryptiskt 10y agoIBM System/38 and descendants have had 128-bit pointers since the mid-70's.
- lmm 10y agoInteger overflow on the JVM has defined behaviour, so it's not the security issue that it is in C.
- caf 10y agoIt's wasn't the undefined-ness of the overflow that was the problem here - the bugs would have been exactly the same if 2s complement wrapping overflow had been mandated. So these would still have been bugs under the JVM too - crashing from an out-of-bound array access or failing to allocate a stupendously large number of objects. The JVM would stop them from turning into potential arbitrary code execution, though (as some, but not all, of these bugs did).
- wtbob 10y ago> 64 bits, everywhere! What if you need to represent 2^64? Bignums everywhere!