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

271–280 of 373 posts

Re: The JVM is not that heavy

#271

Post by geocar »

gregschlom wrote: post #174
geocar wrote: post #144

Earlier quoted context omitted.

I don't know. 10MB still sounds really too big. Why is it so big? What do we gain? I don't have a system with 10MB of cache, so I imagine Java can't run faster than memory...

10MB for a platform that allows you to run code on all three major operating systems without too much trouble and in a performant way is a huge win, in my opinion. Not many alternatives come close to that.

Q/KDB is 600kb, also runs code on all three major operating systems (and a few minor ones). It's also about 1000x faster than Java/Spark[1].

1000x slower doesn't sound like a huge win to me; it sounds like a huge cost, so my question is what do we gain by making our programs 1000x slower?

[1]: http://tech.marksblogg.com/benchmarks.html

Re: The JVM is not that heavy

#272

Post by mike_hearn »

hkjgkjy wrote: post #120
ohstopitu wrote: post #74

Just out of curiosity: If you decide to use Java (or any other languages that run on JVM), are their 3rd party libraries as "nice" (read: as many) as npm?

Former node dev, currently Clojure here. Npm has more abundance of good packages. They are typically better documented and easier to get started with, sadly :(. JVM has some really great stuff - things which are lightyears ahead of what is there in NPM. Much of which started as university projects, as Java is popular at schools. I wish JVM developers took a hint from others and started making very easy and fun docume…

Can you give some examples?

I've usually found docs to be pretty good in the Java library space. One of the nice surprises about it.

Re: The JVM is not that heavy

#273

Post by geocar »

cbsmith wrote: post #212
geocar wrote: post #144

Earlier quoted context omitted.

I don't know. 10MB still sounds really too big. Why is it so big? What do we gain? I don't have a system with 10MB of cache, so I imagine Java can't run faster than memory...

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't 10MB, it likely isn't that much smaller).

http://www.intel.co.uk/content/www/uk/en/processors/core/cor...

I don't have anything with 10MB cache.

> It's not like the whole package would sit in RAM the whole time anyway. By your same assertion, I could say that one of my CPU registers is only 64-bits wide, so I imagine all programs larger than 64-bits can't run faster than L3 cache...

If you get into L1, you get about 1000x faster.

http://tech.marksblogg.com/benchmarks.html

> I'm not sure why you'd say it is too big.

Maybe I have a different perspective? If a 600kb runtime is 1000x faster, I want to know what I get by being 10x bigger. I'm quite surprised that there are so many responders defending it given that these benchmarks were just on Hacker News a few days ago.

Re: The JVM is not that heavy

#274

Post by geocar »

krallja wrote: post #201
nv-vn wrote: post #200

Earlier quoted context omitted.

Not that the majority of users have that. Even eschewing those outside of wealthy countries, most users are on mobile devices (laptops, tablets, cell phones). Of those who have desktop PCs, very few have terabyte SSDs and even fewer have 32gb of RAM. For most people, RAM is probably somewhere between 4-8GB.

10MB fits comfortably within 4GB of RAM.

I don't think it's healthy to think of that 4GB module as "RAM".

It's connected to your CPU by a serial communications interface so access is not uniform or timely, and if the CPU needs any of it, it stops what it's doing while it waits.

The "cache ram" (L1 and to a lesser extent L2) actually acts like the RAM that we learn about in Knuth, so that when we discuss algorithms in terms of memory/time costs, this is the number we should be thinking about. Algorithms that are performant on disk/drum are modern solutions for what you're calling "RAM".

Re: The JVM is not that heavy

#275

Post by fauigerzigerk »

mike_hearn wrote: post #260
jshen wrote: post #225

Earlier quoted context omitted.

I have golang website/web app that runs at tens of megabytes per process. A very similar java web app runs in a few hundred megabytes per process. I also run these in on cloud platforms that auto scale. The golang processes spin up very quickly, the java ones not so much. In these two respects the JVM is heavy compared to golang for my very common scenarios. The heaviness also causes me to spend more money for the JV…

But what max heap size did you set for the JVM? I have an app that people were complaining took too much memory. A quick look with VisualVM showed that its actual heap usage when idling was only 50 mb but because we hadn't set any heap size limit, it was reserving hundreds of megs from the OS. The idea is that it can run faster if it does that. The fix was simply to use the -Xmx option to tell it to use less memory a…

The JVM is very inflexible in that respect. If you give it more memory it will keep all of it way beyond the point where it matters for performance. If you give it less memory you need to know exactly how much less you can give it before performance craters.

In other words, JVM deployments need a lot more tuning than Go and they will generally need a lot more memory as well. But you're right, not setting -Xmx at all will make the JVM look worse than it really is.

Re: The JVM is not that heavy

#276

Post by mnw21cam »

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.

I have a little server I wrote in Java. Admittedly it is not a HTTP server, but it quite happily handles a thousand simultaneous connections with a memory limit of 200MB. It's currently sitting around 26MB, but I'm sure some of that would disappear if the VM did a GC.

Re: The JVM is not that heavy

#277

Post by mnw21cam »

mike_hearn wrote: post #262
jshen wrote: post #226

Earlier quoted context omitted.

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.

Are you sure? I've written small HTTP servers in Java that can happily run with a heap of 30-50mb or less. Runtime overheads add some on top of that, but not much. I think the perception of Java suffers a lot because it will consume all the RAM on your machine by default if you let it (but not immediately). It's a very poor default because even though there are technical arguments for doing that (goes faster), they a…

It was a couple of seconds on my Cyrix 300MHz-ish CPU back in 1998. I would have expected it to get a little better since then.

Re: The JVM is not that heavy

#278

Post by ipsi »

geocar wrote: post #270
hota_mazi wrote: post #213

Earlier quoted context omitted.

> I don't know. 10MB still sounds really too big. Can't tell if sarcastic or... o_O. In the unlikely case you're actually serious, you really need to rethink your perception of memory costs in 2017.

No, I'm really quite serious. KDB[1] is about 1000x faster than Spark[2], and is only about 600kb (and most of that is shared library dynamic linker stuff that makes interfacing with the rest of the OS easier). A big part of why it's fast is because it's small -- once you're inside cache memory everything gets faster. That's the real cost of memory in 2017. So what did we gain for paying it? [1]: https://news.ycombin…

You're comparing completely, utterly different results here, and it's really hurting any point you're trying to make.

You're comparing KDB running on 4x Intel Xeon Phi 7210 CPUs, totaling 256 physical CPUs.

Compared to the best result for Java/Spark, which was running on 11x m3.xlarge instances on AWS. That's only 44 CPUs, plus it's running on AWS, not 100% dedicated hardware, so it's tough to tell what sort of an impact the virtualization + EBS has on performance. Plus, from the AWS page: "Each vCPU is a hyperthread of an Intel Xeon core except for T2 and m3.medium", which does not do anything good for the results.

Yes, technically, KDB was 199.80x faster (not 1000!) than Java/Spark, when it was given vastly superior, dedicated hardware without virtualization, and when tackling a problem that the hardware setup is optimized for. Note that the author calls this out by saying "This isn't dissimilar to using graphics cards" when talking about the setup he was using for the KDB benchmarks.

To get a sensible idea of the relative difference in performance, 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 then, if Java/Spark does poorly on the Xeon Phi test, that might just mean that the Java/Spark developers haven't optimized for that particular setup.

Re: The JVM is not that heavy

#279

Post by grw_ »

ominous wrote: post #259
ksec wrote: post #252

Earlier quoted context omitted.

That is why i am looking forward and VERY excited for TruffleRuby, SubstrateVM, Graal, along with C Extention. I think once there is official way to trim JDK down, making deployment super easy and fast ( Single executable File ), Java will pick up stream again. The only problem and hesitation we have...is Oracle.

Not to sound rude, but the expression you were aiming to use is maybe "pick up steam". Random example: http://idioms.thefreedictionary.com/pick+up+steam

OT, but this expression seems like a corruption of 'build up steam' and 'pick up speed'. 'Pick up steam' doesn't really make sense in original context- something a steam train would do while stationary and preparing to move :)

Re: The JVM is not that heavy

#280

Post by imtringued »

sk5t wrote: post #209
nostrademons wrote: post #176

Earlier quoted context omitted.

Take a look at the TechEmpower benchmarks: https://www.techempower.com/benchmarks/ DropWizard is modern, but it isn't fast. Go and even Node.js are significantly faster. If you want performance, you cut layers out of the stack - check out the numbers for raw servlets or even just straight Jersey annotations in that benchmark. If I were doing JSON-over-HTTP microservices in Java, I'd likely use straight Jersey + Jacks…

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 odb. It doesn't allow setting the fetching strategy on a per query basis. You have to either always use eager loading or lazy loading which basically makes it useless for my purposes.

Post reply on HN