6 ms·

1TB of RAM is cheap though, versus spending engineering hours. Reminds me of the classic WTF "That would've been an option too" https://thedailywtf.com/article

1TB of RAM is cheap though, versus spending engineering hours. Reminds me of the classic WTF "That would've been an option too" https://thedailywtf.com/articles/That-Wouldve-Been-an-Option-Too https://thedailywtf.com/articles/That-Wouldve-Been-an-Option...

MangoCoffee 6y ago
agree. hardware is getting cheaper and cheaper
- ksec 6y ago
  Except Memory / DRAM.
mroche 6y ago
This was a great read, thanks for that! Never heard of The Daily WTF before.
- petters 6y ago
  Congratulations! https://xkcd.com/1053/ https://xkcd.com/1053/
  - mroche 6y ago
    Of course there’s an XKCD for this! Ah, the wonders of the internet. The article in question was written in 2008: I was 11 years old. I guess I now fall in to the category of “heard of it by the age of 30”.
jacques_chester 6y ago
> 1TB of RAM is cheap though, versus spending engineering hours. It's not about the amount of RAM, it's how fast and predictable the overall system is. Note in particular the remark about cache locality; that can be the difference between nanoseconds and microseconds.
- whizzter 6y ago
  What the GP is referring to (Misc.Unsafe) is basically going back to manual pointer reads/writes (IE writing more or less C code in Java), the benefit is you get C speed/memory layout/cache-locality but with the downside of writing it in a less suited language (Java). HOWEVER If you DO _allocate_ much then 1TB seems like a great choice since GC pauses are killers w.r.t. latency in comparison to cache issues. A cache line (often 64 bytes) would probably only hold at most a couple of Java objects (minimum is probably like 16 or more bytes for each small object) so cache locality won't be improved much by a GC (Yes, the G1 GC in newer JDK's does neighbour compacting iirc so you get a little cache locality but only if the patterns were bad from the start, but avoiding GC entirely is better)
  - apalmer 6y ago
    Can you explain why you would code java this way instead of dropping down to C?
    - whizzter 6y ago
      Probably because they started out in Java and don't want a full rewrite once they've gotten this far (might be that they don't have many C++ devs anyhow). I remember working on similar codebases 10 years back when J2ME games were still a thing (J2ME runtimes usually had horrible GC's and some people really went overboard in trying to avoid them) and it wasn't that fun at all (Even if the questDB codebase that is linked elsewhere in this thread seems to be saner). Also JNI for calling C/C++ code is fairly bad and error prone (if you want to combine code), JNA is better but i think this is one of the bigger reasons that Oracle is funding GraalVM is that it promises "seamless" interoperability and breaking up things into Java and C/C++ parts might be a good option in the future.
      - pjmlp 6y ago
        JNI replacement is called Panama it doesn't have anything to do with GraalVM. GraalVM is the new name of MaximeVM one of the JVM meta-circular JVMs. Other well known ones being JikesRVM and SquawkVM. What Oracle and others in the Java community are doing is reducing the need to drop down to C with support for value types and more fine grained control over native memory. Java 16 will have the first preview release of the new low level memory APIs.
deleted 6y ago
[deleted]
alexeiz 6y ago
> ...a new intern named Bob. Bob raised a finger and said "Yes, I have a question... Damn those smart-ass interns!

MangoCoffee 6y ago

agree. hardware is getting cheaper and cheaper

ksec 6y ago
Except Memory / DRAM.

mroche 6y ago

This was a great read, thanks for that! Never heard of The Daily WTF before.

petters 6y ago
Congratulations! https://xkcd.com/1053/ https://xkcd.com/1053/
- mroche 6y ago
  Of course there’s an XKCD for this! Ah, the wonders of the internet. The article in question was written in 2008: I was 11 years old. I guess I now fall in to the category of “heard of it by the age of 30”.

jacques_chester 6y ago

> 1TB of RAM is cheap though, versus spending engineering hours. It's not about the amount of RAM, it's how fast and predictable the overall system is. Note in particular the remark about cache locality; that can be the difference between nanoseconds and microseconds.

whizzter 6y ago
What the GP is referring to (Misc.Unsafe) is basically going back to manual pointer reads/writes (IE writing more or less C code in Java), the benefit is you get C speed/memory layout/cache-locality but with the downside of writing it in a less suited language (Java). HOWEVER If you DO _allocate_ much then 1TB seems like a great choice since GC pauses are killers w.r.t. latency in comparison to cache issues. A cache line (often 64 bytes) would probably only hold at most a couple of Java objects (minimum is probably like 16 or more bytes for each small object) so cache locality won't be improved much by a GC (Yes, the G1 GC in newer JDK's does neighbour compacting iirc so you get a little cache locality but only if the patterns were bad from the start, but avoiding GC entirely is better)
- apalmer 6y ago
  Can you explain why you would code java this way instead of dropping down to C?
  - whizzter 6y ago
    Probably because they started out in Java and don't want a full rewrite once they've gotten this far (might be that they don't have many C++ devs anyhow). I remember working on similar codebases 10 years back when J2ME games were still a thing (J2ME runtimes usually had horrible GC's and some people really went overboard in trying to avoid them) and it wasn't that fun at all (Even if the questDB codebase that is linked elsewhere in this thread seems to be saner). Also JNI for calling C/C++ code is fairly bad and error prone (if you want to combine code), JNA is better but i think this is one of the bigger reasons that Oracle is funding GraalVM is that it promises "seamless" interoperability and breaking up things into Java and C/C++ parts might be a good option in the future.
    - pjmlp 6y ago
      JNI replacement is called Panama it doesn't have anything to do with GraalVM. GraalVM is the new name of MaximeVM one of the JVM meta-circular JVMs. Other well known ones being JikesRVM and SquawkVM. What Oracle and others in the Java community are doing is reducing the need to drop down to C with support for value types and more fine grained control over native memory. Java 16 will have the first preview release of the new low level memory APIs.

deleted 6y ago

[deleted]

alexeiz 6y ago

> ...a new intern named Bob. Bob raised a finger and said "Yes, I have a question... Damn those smart-ass interns!