5 ms·

JVM is a marvel at making OOP code merely 10% or 50% slower than C, but I find procedural/data-oriented programming to be quite a lot clearer, faster, and more

JVM is a marvel at making OOP code merely 10% or 50% slower than C, but I find procedural/data-oriented programming to be quite a lot clearer, faster, and more predictable (with respect to performance) and I don't need nor a huge runtime nor an expert to tune it nor a complicated toolchain to bundle it in with my application (or otherwise ensure that the properly tuned runtime is installed on my target).

hedora 3y ago
To get it to that level of performance, you need to have expert java programmers, and the result will be hard to maintain. For instance, you can’t use String on hot paths. Also, NPEs can happen almost anywhere, and the compiler doesn’t enforce thread safely (by which I mean “statically checked to be data race free”) Also, the 10-50% slower rule of thumb only applies to throughput. Tail latency is generally much worse than that.
- RhodesianHunter 3y ago
  It depends on what you're doing. In C you're going to be hampered by, again, the ecosystem. There is nothing comparable in C as performant as all of the streaming tooling built up around Kafka for example. So your can benchmark percentages all you want, but there are a lot of things you just can't do in C that you can on the JVM (without 100 developers and three years)
  - morelisp 3y ago
    > There is nothing comparable in C as performant as all of the streaming tooling built up around Kafka for example. This is an ill-chosen example. librdkafka is as or more performant than the Java stuff. As a server, Redpanda blows Kafka out of the water (but this is rarely any bottleneck with brokers).
    - RhodesianHunter 3y ago
      Yes, if you take the time to hand roll a replacement like Redpanda did it will be faster (though to your point that seems fairly pointless given the constraints imposed by IO) I was referring more to the general ecosystem of Flink/Spark/KStreams/KTable etc.
      - agallego 3y ago
        this seems truthy but isn't in practice. a lot of work, my perf optimization team @ redpanda does (yes we have a full team chasing tail latencies) is spent on CPU optimization, debouncing, amortizing costs, metadata lookups, hash tables, profilers, etc. so there is a lot of additional work after the IO layer which a decent async eventing thing can get you to get good perf.
        RhodesianHunter 3y ago
        What I mean to say is that in my experience the time spent round-tripping to Kafka is more than the time it takes Kafka to do whatever I'm asking it to do. So at least for my use-cases a faster Kafka would be of no benefit. Now if it means I can run fewer smaller brokers that's awesome.
        agallego 3y ago
        def. that should be the case, we have iot companies pushing us on a single pthread a a few megs of ram.
      - morelisp 3y ago
        > Flink/Spark/KStreams/KTable etc. Then it's still a bit of an untruth since all of those use RocksDB for their high-performance storage layer, which isn't in Java. You could maybe (maybe!) argue for some ergonomics (though especially hard to argue for Spark!) but performance still goes plainly to C (/ C++).
        3y ago
c_crank 3y ago
You can write procedural/data-oriented code in Java.
- morelisp 3y ago
  As long as you hire C/C++/Rust programmers to write it.
- throwaway894345 3y ago
  Sort of (Java still doesn't have value types), and even then you still have most of the cons of a big runtime.
za3faran 3y ago
Always funny to see OOP being thrown around like it's some sort of bogeyman. C++ is OOP, so is Rust (minus inheritance), yet both are as fast or faster than C.

hedora 3y ago

To get it to that level of performance, you need to have expert java programmers, and the result will be hard to maintain. For instance, you can’t use String on hot paths. Also, NPEs can happen almost anywhere, and the compiler doesn’t enforce thread safely (by which I mean “statically checked to be data race free”) Also, the 10-50% slower rule of thumb only applies to throughput. Tail latency is generally much worse than that.

RhodesianHunter 3y ago
It depends on what you're doing. In C you're going to be hampered by, again, the ecosystem. There is nothing comparable in C as performant as all of the streaming tooling built up around Kafka for example. So your can benchmark percentages all you want, but there are a lot of things you just can't do in C that you can on the JVM (without 100 developers and three years)
- morelisp 3y ago
  > There is nothing comparable in C as performant as all of the streaming tooling built up around Kafka for example. This is an ill-chosen example. librdkafka is as or more performant than the Java stuff. As a server, Redpanda blows Kafka out of the water (but this is rarely any bottleneck with brokers).
  - RhodesianHunter 3y ago
    Yes, if you take the time to hand roll a replacement like Redpanda did it will be faster (though to your point that seems fairly pointless given the constraints imposed by IO) I was referring more to the general ecosystem of Flink/Spark/KStreams/KTable etc.
    - agallego 3y ago
      this seems truthy but isn't in practice. a lot of work, my perf optimization team @ redpanda does (yes we have a full team chasing tail latencies) is spent on CPU optimization, debouncing, amortizing costs, metadata lookups, hash tables, profilers, etc. so there is a lot of additional work after the IO layer which a decent async eventing thing can get you to get good perf.
      - RhodesianHunter 3y ago
        What I mean to say is that in my experience the time spent round-tripping to Kafka is more than the time it takes Kafka to do whatever I'm asking it to do. So at least for my use-cases a faster Kafka would be of no benefit. Now if it means I can run fewer smaller brokers that's awesome.
        agallego 3y ago
        def. that should be the case, we have iot companies pushing us on a single pthread a a few megs of ram.
    - morelisp 3y ago
      > Flink/Spark/KStreams/KTable etc. Then it's still a bit of an untruth since all of those use RocksDB for their high-performance storage layer, which isn't in Java. You could maybe (maybe!) argue for some ergonomics (though especially hard to argue for Spark!) but performance still goes plainly to C (/ C++).
      - 3y ago

c_crank 3y ago

You can write procedural/data-oriented code in Java.

morelisp 3y ago
As long as you hire C/C++/Rust programmers to write it.
throwaway894345 3y ago
Sort of (Java still doesn't have value types), and even then you still have most of the cons of a big runtime.

za3faran 3y ago

Always funny to see OOP being thrown around like it's some sort of bogeyman. C++ is OOP, so is Rust (minus inheritance), yet both are as fast or faster than C.