You could have invented the LMAX Disruptor, if only you were limited enough
hmijailblog.blogspot.com
You could have invented the LMAX Disruptor, if only you were limited enough
1–10 of 30 posts
Re: You could have invented the LMAX Disruptor, if only you were limited enough
#2What this says to me is that Java's reputation for sluggishness is a result of its idiomatic coding styles more than the language itself. In particular the casual way people allocate and discard objects for everything they do.
If you program it like it was C then you can get good performance, which make sense given that the language was built for embedded devices with anemic processors. Of course you undoubtedly give up some maintainability when you do that, but the tradeoff is getting 6 million packets through the thing per second.
This would also explain why Java benchmarks so well but still tends to be slow in the real world.
Re: You could have invented the LMAX Disruptor, if only you were limited enough
#3What this says to me is that Java's reputation for sluggishness is a result of its idiomatic coding styles more than the language itself. In particular the casual way people allocate and discard objects for everything they do. If you program it like it was C then you can get good performance, which make sense given that the language was built for embedded devices with anemic processors. Of course you undoubtedly give…
> but still tends to be slow in the real world
Is it, though?
Re: You could have invented the LMAX Disruptor, if only you were limited enough
#4What this says to me is that Java's reputation for sluggishness is a result of its idiomatic coding styles more than the language itself. In particular the casual way people allocate and discard objects for everything they do. If you program it like it was C then you can get good performance, which make sense given that the language was built for embedded devices with anemic processors. Of course you undoubtedly give…
Java's reputation for sluggishness was really formed based on people's experience with Applets and Swing applications and especially badly written Applets and Swing applications.
Java in the real world is fast. That's why it's used as the backbone of so many large organizations and so many scale out solutions (Cassandra, Kafka, Hadoop, etc) are written in Java.
Re: You could have invented the LMAX Disruptor, if only you were limited enough
#5What this says to me is that Java's reputation for sluggishness is a result of its idiomatic coding styles more than the language itself. In particular the casual way people allocate and discard objects for everything they do. If you program it like it was C then you can get good performance, which make sense given that the language was built for embedded devices with anemic processors. Of course you undoubtedly give…
Java's reputation for sluggishness was really formed based on people's experience with Applets and Swing applications and especially badly written Applets and Swing applications. Java in the real world is fast. That's why it's used as the backbone of so many large organizations and so many scale out solutions (Cassandra, Kafka, Hadoop, etc) are written in Java.
Yes, I'd take this in conjunction with https://news.ycombinator.com/item?id=17824575 : "language speed" and "UI responsiveness" are only loosely related, and there are so many ways to end up wasting time blocking or locking without really realising it.
Re: You could have invented the LMAX Disruptor, if only you were limited enough
#6What this says to me is that Java's reputation for sluggishness is a result of its idiomatic coding styles more than the language itself. In particular the casual way people allocate and discard objects for everything they do. If you program it like it was C then you can get good performance, which make sense given that the language was built for embedded devices with anemic processors. Of course you undoubtedly give…
> but still tends to be slow in the real world Is it, though?
It's not, but this is a thing people have said since the early days of Java which is still going around the internet. I personally use Java every day and have yet to hear someone complain about the speed of our backends.
The Techempower benchmarks are a great "real world" example IMO: https://www.techempower.com/benchmarks/#section=data-r16&hw=...
Re: You could have invented the LMAX Disruptor, if only you were limited enough
#7What this says to me is that Java's reputation for sluggishness is a result of its idiomatic coding styles more than the language itself. In particular the casual way people allocate and discard objects for everything they do. If you program it like it was C then you can get good performance, which make sense given that the language was built for embedded devices with anemic processors. Of course you undoubtedly give…
Slow, in this context, is too much of a vague term. Are we talking about latency? Throughput? GC pauses? UI sluggishness? VM startup speed?
Re: You could have invented the LMAX Disruptor, if only you were limited enough
#8What this says to me is that Java's reputation for sluggishness is a result of its idiomatic coding styles more than the language itself. In particular the casual way people allocate and discard objects for everything they do. If you program it like it was C then you can get good performance, which make sense given that the language was built for embedded devices with anemic processors. Of course you undoubtedly give…
> but still tends to be slow in the real world Is it, though?
Every time I fire up an Apache Tomcat and it burns several gigabytes of memory to somehow run a simple web service very slowly...
A more famous example might be Minecraft, where even with its blocky graphics it can tax a high end gaming machine when you turn the view distance up to a range that almost no other engine would consider long. The engine has been rewritten in other languages where it is much faster, notably the Microsoft version and the Phone version.
Re: You could have invented the LMAX Disruptor, if only you were limited enough
#9Earlier quoted context omitted.
> but still tends to be slow in the real world Is it, though?
Every time I fire up an Apache Tomcat and it burns several gigabytes of memory to somehow run a simple web service very slowly... A more famous example might be Minecraft, where even with its blocky graphics it can tax a high end gaming machine when you turn the view distance up to a range that almost no other engine would consider long. The engine has been rewritten in other languages where it is much faster, notabl…
Memory usage is still terrible with Java but at least there are plans to address part of it with value types etc. But for a web service performance is pretty good (just look at techempower benchmarks and the fact that most high scale companies use Java for a significant part of their infrastructure). If you need to talk about startup time you don't need scalablitiy or really want a different solution/architecture.
Re: You could have invented the LMAX Disruptor, if only you were limited enough
#10Earlier quoted context omitted.
> but still tends to be slow in the real world Is it, though?
Every time I fire up an Apache Tomcat and it burns several gigabytes of memory to somehow run a simple web service very slowly... A more famous example might be Minecraft, where even with its blocky graphics it can tax a high end gaming machine when you turn the view distance up to a range that almost no other engine would consider long. The engine has been rewritten in other languages where it is much faster, notabl…
Isn't the memory use itself a big problem on modern architectures? Or has it gotten better lately since CPU clocks have been relatively flat and memory clocks have been creeping up? The problem with the "allocate-and-discard" model of programming in the past is that it thrashes the hell out of the cache, which means lots of trips to main memory, which is slow on modern machines.
When you get an article like this going "holy shit, where have you been all my life circular buffers" it emphasizes the point. You wanna go fast you have to avoid invalidating cache as much as possible.