Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

You could have invented the LMAX Disruptor, if only you were limited enough

hmijailblog.blogspot.com

Post reply on HN
Print view View original

11–20 of 30 posts

Re: You could have invented the LMAX Disruptor, if only you were limited enough

#11

Post by dagenix »

jandrese wrote: post #8
maaaats wrote: post #3

Earlier 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…

It doesn't sound like you understand how memory Management in Java works. In Java, you have a defined heap size. Java will claim memory in order to support that heap. If you are unhappy about how much memory it is using, you can change the heap size.

Re: You could have invented the LMAX Disruptor, if only you were limited enough

#12

Post by draw_down »

This is the kind of thing I really love reading. It’s ostensibly about a technical subject, but that’s really a jumping-off point for examining how we think and talk about things, how portions of our field become Balkanized, how what we encounter shapes our sense of what’s possible and ultimately hardens into “common knowledge”.

Re: You could have invented the LMAX Disruptor, if only you were limited enough

#13

Post by coldtea »

flipp3r wrote: post #6
maaaats wrote: post #3

Earlier quoted context omitted.

> 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=...

>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.

That's because for backends it doesn't matter. The DB layer or network will hide any slowdown anyway.

But for Desktop apps the latency due to GUI overhead and GC pauses can be from mildly annoying to unbearable.

Re: You could have invented the LMAX Disruptor, if only you were limited enough

#14

Post by PaulHoule »

jandrese wrote: post #2

What 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…

C was built for a minicomputer which might or might not be the brains of a phone switch, a software development environment, a word processing cluster for a newspaper, industrial control for a steel mill, etc.

The thing about Java is that it has promised and delivered a much better threading experience than other programming languages. When somebody proved the Java memory model was unsafe, Sun fixed it. C and other languages have adopted essentially this memory model but a decade and a half later. Java provides bulletproof tools in forms of Executors, Latches and other specialized concurrency constructs. It takes time to learn to use them, but you can ship fast and correct code for something like the LMAX Disruptor.

Re: You could have invented the LMAX Disruptor, if only you were limited enough

#15

Post by lmilcin »

jandrese wrote: post #2

What 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…

Hi! I have worked on algorithmic trading framework for third largest Polish brokerage house and I also re-implemented LMAX Disruptor for this project.

Actually, allocating and discarding objects is not the problem. Java allocation and deallocation is extremely efficient for short living objects.

I would say memory layout, access patters resulting from object orientedness are much more important factor.

It is possible to get very close to raw performance, but you have to reinvent almost everything. The code starts looking like plain C very quickly.

Re: You could have invented the LMAX Disruptor, if only you were limited enough

#16

Post by aidenn0 »

jandrese wrote: post #2

What 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…

The other thing is that the JVM was sluggish when Java was at peak hype. The steady performance improvements in the decades since have made a big difference.

Re: You could have invented the LMAX Disruptor, if only you were limited enough

#17

Post by latencyloser »

lmilcin wrote: post #15
jandrese wrote: post #2

What 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…

Hi! I have worked on algorithmic trading framework for third largest Polish brokerage house and I also re-implemented LMAX Disruptor for this project. Actually, allocating and discarding objects is not the problem. Java allocation and deallocation is extremely efficient for short living objects. I would say memory layout, access patters resulting from object orientedness are much more important factor. It is possible…

Just adding on that this is my experience as well.

Objects usually fell into one of two categories: discarded immediately or held for the entire application lifetime. Anything in between was problematic. Most things ended up using object pools. We also used to never really convert anything from binary format and just used wrapper objects to access the byte arrays directly.

Another sort of trick was scheduling GC for times when the application was OK to pause helped considerably, and made behavior more predictable as well.

It'd be tough to compare it to C/C++ given the complexity of the application. But without giving away specifics, we had solid performance afaik. But you're correct that it does end up making for some interesting Java code.

Re: You could have invented the LMAX Disruptor, if only you were limited enough

#18

Post by jerven »

dagenix wrote: post #11
jandrese wrote: post #8

Earlier quoted context omitted.

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…

It doesn't sound like you understand how memory Management in Java works. In Java, you have a defined heap size. Java will claim memory in order to support that heap. If you are unhappy about how much memory it is using, you can change the heap size.

Or use ShenadoahGC ;) and it will uncommit heap not in use. Or wait for http://openjdk.java.net/jeps/8204089 to land. In any case vastly improving idle RSS consumption.

Re: You could have invented the LMAX Disruptor, if only you were limited enough

#19

Post by jerven »

coldtea wrote: post #13
flipp3r wrote: post #6

Earlier quoted context omitted.

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=...

> 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. That's because for backends it doesn't matter. The DB layer or network will hide any slowdown anyway. But for Desktop apps the latency due to GUI overhead and GC pauses can be from mildly annoying…

Sorry, but backends speed does matter. Not every backend is DB connection limited. Faster elasticsearch/solr/lucene etc... is very welcome.

Re: You could have invented the LMAX Disruptor, if only you were limited enough

#20

Post by scarejunba »

draw_down wrote: post #12

This is the kind of thing I really love reading. It’s ostensibly about a technical subject, but that’s really a jumping-off point for examining how we think and talk about things, how portions of our field become Balkanized, how what we encounter shapes our sense of what’s possible and ultimately hardens into “common knowledge”.

Reminded me of the reaction to this paper in Medicine https://doi.org/10.2337/diacare.17.2.152

It's just rudimentary integration approximation to a mathematics undergraduate but to those in Medicine unfamiliar with it, it was an achievement.

Post reply on HN