3 ms·

But it’s not as fast as just allocating a structure on the stack instead of checks graph 20 objects on the heap, all pointing to the next with 64bit pointers. I

But it’s not as fast as just allocating a structure on the stack instead of checks graph 20 objects on the heap, all pointing to the next with 64bit pointers. I’ve got Rust struct that are 80 bytes and the same structure in Java is 800 bytes.

gf000 2y ago
What's the difference between the stack and a thread-local, constantly hot/in-cache other region of the same memory? Especially that in many cases the objects are allocated right next to each other, so fetching happens from cache again. Not saying that expertly written Rust code can't beat naive Java one, and especially with the object headers Java will have a performance disadvantage in many cases - but that's a tiny disadvantage in most real-world use cases, multiple times offset by its advantages. (Besides, Java has on-stack replacement which can do the exact same thing as rust does, but the JIT-compiler Gods have to be in the correct alignment for that)
- lowbloodsugar 2y ago
  What’s the difference…? 1. The size. 2. I don’t see that happening and I look at the output of the C2 compiler when I’m dealing with hotspots. In aware of the cool shit the JVM can do but done right, areas of code can be as fast as C or Rust. It in general, My experience is that Rust is much faster. Sometimes 10x faster where it matters to me (sustained server load).
  - munksbeer 2y ago
    >Sometimes 10x faster where it matters to me (sustained server load). I don't think that is a reasonable stat. What do you mean by faster? I'd be extremely surprised if this is representative of any real-world examples where someone has taken moderate care to write good Java code.
    - lowbloodsugar 2y ago
      Well just the fact that a structure can fit in one cache line vs ten is a start. A lot of the systems I deal with aren’t “ephemeral” meaning the data gets copied out of Eden into survivor and then tenured just in time to die. What else. Interfaces uses that don’t always point to a single type so they don’t get hard coded. Interfaces are quite a bit worse than even abstract base classes in Java if they actually have to be decided upon. Most of the time you’ll be doing that same behavior in Rust using enums rather than dyn. Lets see. “Clever bit tricks”. So like fitting a Set implementation into a cache line if it only has 8 element and using a regular hash set if it’s bigger. So much opportunity.
- bjourne 2y ago
  Deallocating stack-allocated objects is completely free. Allocating in a thread-local buffer maybe can be fast as allocating on the stack, but the allocations still increase the frequency with which the gc has to collect garbage.
  - gf000 2y ago
    Not quite - the still reachable objects can be evacuated concurrently, and then the whole buffer is reset with literally zero work (just setting the pointer to the buffer's start).
    - bjourne 2y ago
      Even if collection is run concurrently it is still the same amount of work.
hinkley 2y ago
A lot of Lisps don’t even have a stack. It’s effectively a second heap with only call frames on it. That’s one way to implement tail call elimination for instance.

gf000 2y ago

What's the difference between the stack and a thread-local, constantly hot/in-cache other region of the same memory? Especially that in many cases the objects are allocated right next to each other, so fetching happens from cache again. Not saying that expertly written Rust code can't beat naive Java one, and especially with the object headers Java will have a performance disadvantage in many cases - but that's a tiny disadvantage in most real-world use cases, multiple times offset by its advantages. (Besides, Java has on-stack replacement which can do the exact same thing as rust does, but the JIT-compiler Gods have to be in the correct alignment for that)

lowbloodsugar 2y ago
What’s the difference…? 1. The size. 2. I don’t see that happening and I look at the output of the C2 compiler when I’m dealing with hotspots. In aware of the cool shit the JVM can do but done right, areas of code can be as fast as C or Rust. It in general, My experience is that Rust is much faster. Sometimes 10x faster where it matters to me (sustained server load).
- munksbeer 2y ago
  >Sometimes 10x faster where it matters to me (sustained server load). I don't think that is a reasonable stat. What do you mean by faster? I'd be extremely surprised if this is representative of any real-world examples where someone has taken moderate care to write good Java code.
  - lowbloodsugar 2y ago
    Well just the fact that a structure can fit in one cache line vs ten is a start. A lot of the systems I deal with aren’t “ephemeral” meaning the data gets copied out of Eden into survivor and then tenured just in time to die. What else. Interfaces uses that don’t always point to a single type so they don’t get hard coded. Interfaces are quite a bit worse than even abstract base classes in Java if they actually have to be decided upon. Most of the time you’ll be doing that same behavior in Rust using enums rather than dyn. Lets see. “Clever bit tricks”. So like fitting a Set implementation into a cache line if it only has 8 element and using a regular hash set if it’s bigger. So much opportunity.
bjourne 2y ago
Deallocating stack-allocated objects is completely free. Allocating in a thread-local buffer maybe can be fast as allocating on the stack, but the allocations still increase the frequency with which the gc has to collect garbage.
- gf000 2y ago
  Not quite - the still reachable objects can be evacuated concurrently, and then the whole buffer is reset with literally zero work (just setting the pointer to the buffer's start).
  - bjourne 2y ago
    Even if collection is run concurrently it is still the same amount of work.

hinkley 2y ago

A lot of Lisps don’t even have a stack. It’s effectively a second heap with only call frames on it. That’s one way to implement tail call elimination for instance.