6 ms·

Not my experience at all. I am maintaining a very high performance JIT compiler for a Haskell like programming language used in production at large enterprises

Not my experience at all. I am maintaining a very high performance JIT compiler for a Haskell like programming language used in production at large enterprises around the world. So I am used to very carefully analyse performance. And reference counting is never the bottleneck. You might be right in theory but not in practice.

kgeist 4y ago
I wonder how Haskell's purity influences RC usage patterns. Are there tricks which aren't possible in an imperative language?
- tomsmeding 4y ago
  Haskell specifically is a poor choice of language here, because it creates cycles like the pest. (This is because it uses lazy evaluation, and programming patterns (design patterns?) using lazy evaluation tend to use cyclical references. Strict FP languages might support your point better, but then Ocaml again doesn't work because it mutates like the pest.) Furthermore it also allocates like the pest: busy Haskell programs regularly allocate on the order of 1GB/sec. However, this works out fine because the majority of those allocations are short-lived, hence become dead quickly, hence a GC that is designed to only touch live data (like Haskell's GC!) will handle that well.
  - mbrodersen 4y ago
    It is a Haskell inspired language but not Haskell. The syntax is similar but it is eagerly evaluated and has no IO and no data cycles. It is used 100% for evaluating complex optimisation and business rules within a client application. The language was carefully crafted to maximise rules writer productivity and execution performance.
    - tomsmeding 4y ago
      Ah, I was just responding to my parent, committing the sin to not remember what they are replying to. Interesting; with purity and eager evaluation, and presumably no mutually recursive bindings either, you should indeed get absence of cycles. I do wonder: does absence of mutually recursive bindings come back to bite you at some point? Or does the need for that just not arise in your domain? Is there stuff that you feel is awkward to express in your language that would be fine in Haskell proper?
smasher164 4y ago
Not sure about the characteristics of your workload, but here's a talk where a group wrote device drivers in several high-level languages, and measured their performance: https://media.ccc.de/v/35c3-9670-safe_and_secure_drivers_in_high-level_languages#t=2176 https://media.ccc.de/v/35c3-9670-safe_and_secure_drivers_in_... They found that the Swift version spent 76% of the time doing reference counting, even slower than Go, which spent 0.5% in the garbage collector.
- bitcharmer 4y ago
  Yeah, GP has no idea what they are talking about. They replied something similar on another thread without ever providing evidence for their claims. They even claimed their RC implementation in Haskell is faster than hand-crafted C++. Gave me a chuckle.
  - mbrodersen 4y ago
    And your reply game me a chuckle :) The code is unfortunately not open source so I can’t provide the evidence. You believe what you want to believe of course. However I am happy to answer any questions on how it is implemented down to the lowest-level nitty gritty details.
- deterministic 4y ago
  All that tells me is that the Swift implementation is different from the one I implemented.
kaba0 4y ago
Well, it won’t be the bottleneck itself, but it has an overhead on basically every operation, which likely won’t show up during profiling. Also, I fail to see the advantage of RC in case of a presumably mostly immutable language - a tracing GC is even faster there due to no changes to the object graph after allocation, making a generational approach scale very well and be almost completely done in parallel.
- mbrodersen 4y ago
  Nope. The compiler does a full program optimisation, reducing the reference counting to an absolute minimum. There is close to zero overhead passing data around. It does not work like C++ shared_pre. shared_ptr is slow.
  - kaba0 4y ago
    > The compiler does a full program optimisation That's the equivalent of an escape analysis I assume, which optimization exists for tracing GCs as well.

kgeist 4y ago

I wonder how Haskell's purity influences RC usage patterns. Are there tricks which aren't possible in an imperative language?

tomsmeding 4y ago
Haskell specifically is a poor choice of language here, because it creates cycles like the pest. (This is because it uses lazy evaluation, and programming patterns (design patterns?) using lazy evaluation tend to use cyclical references. Strict FP languages might support your point better, but then Ocaml again doesn't work because it mutates like the pest.) Furthermore it also allocates like the pest: busy Haskell programs regularly allocate on the order of 1GB/sec. However, this works out fine because the majority of those allocations are short-lived, hence become dead quickly, hence a GC that is designed to only touch live data (like Haskell's GC!) will handle that well.
- mbrodersen 4y ago
  It is a Haskell inspired language but not Haskell. The syntax is similar but it is eagerly evaluated and has no IO and no data cycles. It is used 100% for evaluating complex optimisation and business rules within a client application. The language was carefully crafted to maximise rules writer productivity and execution performance.
  - tomsmeding 4y ago
    Ah, I was just responding to my parent, committing the sin to not remember what they are replying to. Interesting; with purity and eager evaluation, and presumably no mutually recursive bindings either, you should indeed get absence of cycles. I do wonder: does absence of mutually recursive bindings come back to bite you at some point? Or does the need for that just not arise in your domain? Is there stuff that you feel is awkward to express in your language that would be fine in Haskell proper?

smasher164 4y ago

Not sure about the characteristics of your workload, but here's a talk where a group wrote device drivers in several high-level languages, and measured their performance: https://media.ccc.de/v/35c3-9670-safe_and_secure_drivers_in_high-level_languages#t=2176 https://media.ccc.de/v/35c3-9670-safe_and_secure_drivers_in_... They found that the Swift version spent 76% of the time doing reference counting, even slower than Go, which spent 0.5% in the garbage collector.

bitcharmer 4y ago
Yeah, GP has no idea what they are talking about. They replied something similar on another thread without ever providing evidence for their claims. They even claimed their RC implementation in Haskell is faster than hand-crafted C++. Gave me a chuckle.
- mbrodersen 4y ago
  And your reply game me a chuckle :) The code is unfortunately not open source so I can’t provide the evidence. You believe what you want to believe of course. However I am happy to answer any questions on how it is implemented down to the lowest-level nitty gritty details.
deterministic 4y ago
All that tells me is that the Swift implementation is different from the one I implemented.

kaba0 4y ago

Well, it won’t be the bottleneck itself, but it has an overhead on basically every operation, which likely won’t show up during profiling. Also, I fail to see the advantage of RC in case of a presumably mostly immutable language - a tracing GC is even faster there due to no changes to the object graph after allocation, making a generational approach scale very well and be almost completely done in parallel.

mbrodersen 4y ago
Nope. The compiler does a full program optimisation, reducing the reference counting to an absolute minimum. There is close to zero overhead passing data around. It does not work like C++ shared_pre. shared_ptr is slow.
- kaba0 4y ago
  > The compiler does a full program optimisation That's the equivalent of an escape analysis I assume, which optimization exists for tracing GCs as well.