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

The JVM is not that heavy

opensourcery.co.za

Post reply on HN
Print view View original

351–360 of 373 posts

Re: The JVM is not that heavy

#351

Post by cbsmith »

geocar wrote: post #273
cbsmith wrote: post #212

Earlier quoted context omitted.

Huh? What? Several points: * Who said the 10MB is all used at once? * I don't know your hardware, but there is very, very good chance you are actually quite wrong about * If you were referring strictly to CPU cache, then I'm even more confused, because the entire existence of that stuff is predicated on it being faster than memory, so... (and even still, if your total CPU cache isn't 10MB, it likely isn't that much s…

> Who said the 10MB is all used at once? The parent was suggesting that this was all that was actually needed out of the 100mb or so downloadable. If you think the JVM is smaller, how small is it exactly? > If you were referring strictly to CPU cache, then I'm even more confused, because the entire existence of that stuff is predicated on it being faster than memory, so... (and even still, if your total CPU cache isn…

> I don't have anything with 10MB cache.

The link you provided was to three distinct models of i7 processors... all with 8MB of L3 cache. I would argue that 8MB isn't much smaller than 10MB, but I will understand if you disagree. However, even the slowest of those processors also has 1MB of L2 cache and 256KB of L1 cache, not to mention other "cache-like" memory in the form of renamed registers, completion queues, etc. At most, we're talking > If you get into L1, you get about 1000x faster.

I think you are making my point for me.

> Maybe I have a different perspective? If a 600kb runtime is 1000x faster, I want to know what I get by being 10x bigger.

You are assuming that at all times all of that 10MB must be touched by the processor at once. You can have a 10MB runtime where most of the cycles are being spent on a hotspot generated by it. Are you going to penalize your 600KB runtime for the size of the source code? ;-)

Re: The JVM is not that heavy

#352

Post by cbsmith »

geocar wrote: post #320
adrianN wrote: post #288

Earlier quoted context omitted.

Unless you linearly scan the whole binary all the time, your CPU makes sure that only the stuff you're currently using is in the cache, so only the data your hot loop is touching. You could easily see that your assumption is wrong by observing that a typical C application is not 1000 times faster than a typical Java application.

> Unless you linearly scan the whole binary all the time, your CPU makes sure that only the stuff you're currently using is in the cache, so only the data your hot loop is touching. Cache fills optimize for linear scans, and have nothing to do with eviction. > You could easily see that your assumption is wrong by observing that a typical C application is not 1000 times faster than a typical Java application. What ass…

> Spark is supposed to be one the fastest Java-implementations of a database system, and it's 1000x slower than the fastest C-implementation database systems, but this is clearly a problem limited by memory.

Wow.. so much wrong, I'm not sure how to unpack it all.

a) Spark is Scala, not Java, though both do use the JVM, so I'll give you that.

b) Spark is not a database system, though it is a framework for manipulating data

c) Spark is generally considered to be much faster than Hadoop, and does it's job well, but I'm not sure it qualifies as the fastest anything.

d) By any reasonable interpretation, the fastest Java database system is definitely not Spark. You will find that benchmarks of Java database systems generally don't even include Spark (as an example https://github.com/lmdbjava/benchmarks/blob/master/results/2...)

e) Fast is an ambiguous term... usually you are looking at things like latency, throughput, efficiency, etc. I'm not sure which you mean here.

f) If you know anything at all about runtimes, you'd know that if you've found a Java based system that is 1000x slower than a C based system, either your benchmark is extremely specialized, broken, or you are comparing apples & oranges.

Look, Java certainly has some overhead to it, and sometimes it significantly impacts performance. Before you get too excited about attributing it to runtime size, you might want to look at the size of glibc...

Re: The JVM is not that heavy

#353

Post by kazinator »

gregschlom wrote: post #25

Also worth noting that the JVM itself only weighs a couple of megabytes. The bulk of the size comes from the Java runtime (ie: the "standard libraries"), and there are lots of things that your app may not need there (XML parsing, serialization, etc...) A couple of years ago I wrote a simple tool ( https://github.com/aerofs/openjdk-trim ) that allows you to filter out what you don't need. We were able to get the size…

Couple of megabytes without a run-time is huge. What's hiding in there; a VirtualBox image with a Linux kernel + initrd? Or maybe a high definition splash screen in PNG form?

Re: The JVM is not that heavy

#354

Post by exabrial »

jshen wrote: post #226
exabrial wrote: post #167

Earlier quoted context omitted.

These types of arguments cause many intelligent people to headdesk. They're hardly an apples to apples comparison. Of course "Go was Faster". It's because you started with a clean slate!

That's not it. A fairly small http server in go will run in tens of megabytes. The same thing on the JVM requires a couple hundred megabytes at best. The difference in startup time is roughly the same as well.

Not correct at all. You can run Tomcat in 5mb of ram and it starts in less than 250ms

Re: The JVM is not that heavy

#355

Post by geocar »

cbsmith wrote: post #352
geocar wrote: post #320

Earlier quoted context omitted.

> Unless you linearly scan the whole binary all the time, your CPU makes sure that only the stuff you're currently using is in the cache, so only the data your hot loop is touching. Cache fills optimize for linear scans, and have nothing to do with eviction. > You could easily see that your assumption is wrong by observing that a typical C application is not 1000 times faster than a typical Java application. What ass…

> Spark is supposed to be one the fastest Java-implementations of a database system, and it's 1000x slower than the fastest C-implementation database systems, but this is clearly a problem limited by memory. Wow.. so much wrong, I'm not sure how to unpack it all. a) Spark is Scala, not Java, though both do use the JVM, so I'll give you that. b) Spark is not a database system, though it is a framework for manipulating…

> By any reasonable interpretation, the fastest Java database system is definitely not Spark

What database would you recommend for solving the taxi problem using the JVM?

> Spark is Scala, not Java, though both do use the JVM, so I'll give you that.

What does JVM stand for? I was under the impression that we were talking about it's size (10mb v. 100mb).

> You will find that benchmarks of Java database systems generally don't even include Spark

And? What are we talking about here?

> If you know anything at all about runtimes, you'd know that if you've found a Java based system that is 1000x slower than a C based system, either your benchmark is extremely specialized, broken, or you are comparing apples & oranges.

Why?

We're talking about business problems, not about microbenchmarks.

If this is a business problem, and I solve it in 1/1000th the time, for roughly the same cost, then what exactly is your complaint?

> Fast is an ambiguous term... usually you are looking at things like latency, throughput, efficiency, etc. I'm not sure which you mean here.

It's not ambiguous. I'm pointing to the timings for a specific, and realistic business problem.

> Look, Java certainly has some overhead to it, and sometimes it significantly impacts performance. Before you get too excited about attributing it to runtime size, you might want to look at the size of glibc...

Does Java include glibc?

What exactly is your point here?

Re: The JVM is not that heavy

#356

Post by geocar »

adrianN wrote: post #331
geocar wrote: post #320

Earlier quoted context omitted.

> Unless you linearly scan the whole binary all the time, your CPU makes sure that only the stuff you're currently using is in the cache, so only the data your hot loop is touching. Cache fills optimize for linear scans, and have nothing to do with eviction. > You could easily see that your assumption is wrong by observing that a typical C application is not 1000 times faster than a typical Java application. What ass…

If your assumption that a 10MB JVM kills the cache were true, then the alioth benchmarks you have posted wouldn't show a speed difference of ~3. I suggest you learn a bit more about how CPUs work and what benchmarks mean before posting bold claims.

Why not? Those problems fit into cache.

Re: The JVM is not that heavy

#357

Post by geocar »

tobz wrote: post #341
geocar wrote: post #327

Earlier quoted context omitted.

> You're comparing completely, utterly different results here, and it's really hurting any point you're trying to make. Then argue with the point you think I could be making instead of the point that you think I'm making[1] [1]: http://philosophy.lander.edu/oriental/charity.html > you would have to compare KDB and Java/Spark both running on the Xeon Phis, and/or running both on 11x m3.xlarge AWS instances - and even…

If "this approach" is using Java/Spark, instead of something that is a smaller binary, then there are some easy answers to your questions: - people don't want to write C (or K, or whatever yields a small binary) - the cost of switching languages is not worth the speed-up - it's already fast enough I don't think you're wrong, overall, that, specifically, kdb can be much faster than an equivalently sized Spark cluster,…

I'm not arguing for anything: I'm asking what do we get for this cost.

It sounds like you're suggesting we get:

* Not having to write in SQL (note KDB supports SQL92)

Maybe something else? I'm not sure I understand.

Re: The JVM is not that heavy

#358

Post by kazinator »

pjmlp wrote: post #248
cutler wrote: post #196

Earlier quoted context omitted.

This is one thing I've never understood about Clojure - the Java interop. I actually love Clojure but I close my eyes to the fact that it requires an object-oriented VM to work its magic. Clojure is a functional Lisp based on immutable data structures which is about as far from Java OOP as it gets yet we're encouraged to mix Java objects and classes into our Clojure apps as if nothing matters.

Funny, when I code in Clojure there are these things called multi-methods, protocols and multiple dispatch. I think it was originally designed in a Lisp library called CLOS, which incidentally stands for Common Lisp Object System. Very nice explained on how to implement OOP in Lisp, in a book called "The Art of the Metaobject Protocol". Users of Lisp based languages should think twice before criticizing OOP.

Users of Lisp based languages generally think about six times, on average, before criticizing OOP (each time).

Re: The JVM is not that heavy

#359

Post by sk5t »

imtringued wrote: post #280
sk5t wrote: post #209

Earlier quoted context omitted.

On first glance the dropwizard test app appears to be doomed to mediocrity via reliance on hibernate. Call me crazy, but I like my dropwizard with Spring DI for (singleton) resource setup, a micro-ORM to get work done, and HikariCP datasources at runtime.

What's wrong with hibernate? The only thing I can think of is that you're not using "JOIN FETCH entity.relation" when accessing collections and end up with the N+1 select problem but that is because you're using any ORM incorrectly. Entity framework has include and active record has includes which do the same thing. The qt ORM also has something similar. The only ORM I have seen that lacks this critical feature is od…

Well, for benchmarking the essential framework, which does not mandate any ORM, I would want to use something for data access that takes the question of time spent on type reflection, internal caching, and the like, out of the picture. Hibernate and EMF have their place, but not as part of benchmarking the thing that hosts 'em. Core Dropwizard performance is all about how it uses Jetty, Jackson, and maps requests to resources and operations.

Re: The JVM is not that heavy

#360

Post by cbsmith »

geocar wrote: post #355
cbsmith wrote: post #352

Earlier quoted context omitted.

> Spark is supposed to be one the fastest Java-implementations of a database system, and it's 1000x slower than the fastest C-implementation database systems, but this is clearly a problem limited by memory. Wow.. so much wrong, I'm not sure how to unpack it all. a) Spark is Scala, not Java, though both do use the JVM, so I'll give you that. b) Spark is not a database system, though it is a framework for manipulating…

> By any reasonable interpretation, the fastest Java database system is definitely not Spark What database would you recommend for solving the taxi problem using the JVM? > Spark is Scala, not Java, though both do use the JVM, so I'll give you that. What does JVM stand for? I was under the impression that we were talking about it's size (10mb v. 100mb). > You will find that benchmarks of Java database systems general…

> What database would you recommend for solving the taxi problem using the JVM?

You have me at a disadvantage here... The only taxi problem that comes to mind is a probability problem that I'd not likely use a database for at all...

> If this is a business problem, and I solve it in 1/1000th the time, for roughly the same cost, then what exactly is your complaint?

If you came to the conclusion that your business problem runs 1000x faster because of differences in the runtime... you've made a mistake. It is far more likely your benchmark is flawed, or there are significant differences in the compared solutions beyond just the runtimes.

Seriously, I've spent a career dealing with situations exactly like that: "hey, this is 1000x slower than what we are doing before... can you fix that?". Once you are dealing with optimized runtimes, while there can be important differences between them, there just isn't that much room left for improvement.

> It's not ambiguous. I'm pointing to the timings for a specific, and realistic business problem.

The problem is perhaps not ambiguous to you, but you haven't described it in terribly specific terms. More importantly though, you haven't described what you mean by "faster"? That's the ambiguity.

> Does Java include glibc?

> What exactly is your point here?

C programs do. Lots of very efficient, high performance C programs.

Post reply on HN