4 ms·

I mean, micro-benchmarks are just generally not something to put a huge amount of stock into in general, regardless of language. Software that scales out to hun

I mean, micro-benchmarks are just generally not something to put a huge amount of stock into in general, regardless of language. Software that scales out to hundreds of thousands if not millions of users is generally written in "slow", "bloated" languages, and seems to be doing ok. It really all depends on the use case, and who is creating the software. Most enterprise software is slow and bloated, but a lot of other stuff exists that is quite the contrary. Two easy examples: - Cyberduck is written in Java, yet nobody seems to be complaining about how slow and bloated it is. - There exists a version of Quake 2 written in Java: http://bytonic.de/html/benchmarks.html http://bytonic.de/html/benchmarks.html It seems to be able to push out more frames than native, actually. Both of those are real software that actually run well on Java, regardless of penalty paid for running in a VM, JIT, and GC. Also when looking at the amount of memory and time taken when comparing C to Java in the microbenchmarks, always be sure to mentally factor in the base overhead of starting up the JVM both in time and memory. It's pretty easy to see that when a C version takes up something like 100KB of memory and the Java one takes up 30MB, Java consistently takes up at least ~30MB regardless of how much memory is required for that microbenchmark. When the C version takes up 300MB and the Java one takes up 700MB, that's a bit better of a comparison. (though still not perfect, because the Java GC will reserve a lot of memory for itself, even if it isn't using the full 700MB, if it feels it needs that much, etc.)

Alphasite_ 10y ago
Does their exist a JVM with an OS level shared heap, to reduce GC overhead? Obviously each can be collected independently of one another so pausing shouldn't be a significant issue and IPC becomes a Normal heap reference which may aid in performance.
merb 10y ago
> Cyberduck is written in Java, yet nobody seems to be complaining about how slow and bloated it is. Lol I just double checked that after you said it, it never felt "Javaish" even the interface is really sane. Actually they are using JNA for a lot of stuff and they written foundation bindings... (https://g.iterate.ch/projects/ITERATE/repos/cyberduck/browse/binding/src/main/java/ch/cyberduck/binding https://g.iterate.ch/projects/ITERATE/repos/cyberduck/browse...) cool stuff I keep that for reference. However he should put the bindings stuff under something like LGPL since most stuff will fall under fair use anyway (simple class Names which you would use anyway even without looking at the Source when making a JNA binding to Cocoa)
userbinator 10y ago
It seems to be able to push out more frames than native, actually. The table in your link shows it being 6% faster in one (literally) corner case, while all the other entries show it being slower by varying amounts. Keep in mind that in this benchmark a lot of the "heavy lifting" is being done by the GPU via OpenGL, so it isn't great for benchmarking languages that run on the CPU. It also doesn't mention what the "Original C Code" was compiled with.
igouy 10y ago
>> overhead of starting up the JVM both in time Not much for those programs: http://benchmarksgame.alioth.debian.org/sometimes-people-just-make-up-stuff.html#jvm-startup-time http://benchmarksgame.alioth.debian.org/sometimes-people-jus... >> It's pretty easy to see … memory Yes: http://programmers.stackexchange.com/a/189552/4334 http://programmers.stackexchange.com/a/189552/4334

Alphasite_ 10y ago

Does their exist a JVM with an OS level shared heap, to reduce GC overhead? Obviously each can be collected independently of one another so pausing shouldn't be a significant issue and IPC becomes a Normal heap reference which may aid in performance.

merb 10y ago

> Cyberduck is written in Java, yet nobody seems to be complaining about how slow and bloated it is. Lol I just double checked that after you said it, it never felt "Javaish" even the interface is really sane. Actually they are using JNA for a lot of stuff and they written foundation bindings... (https://g.iterate.ch/projects/ITERATE/repos/cyberduck/browse/binding/src/main/java/ch/cyberduck/binding https://g.iterate.ch/projects/ITERATE/repos/cyberduck/browse...) cool stuff I keep that for reference. However he should put the bindings stuff under something like LGPL since most stuff will fall under fair use anyway (simple class Names which you would use anyway even without looking at the Source when making a JNA binding to Cocoa)

userbinator 10y ago

It seems to be able to push out more frames than native, actually. The table in your link shows it being 6% faster in one (literally) corner case, while all the other entries show it being slower by varying amounts. Keep in mind that in this benchmark a lot of the "heavy lifting" is being done by the GPU via OpenGL, so it isn't great for benchmarking languages that run on the CPU. It also doesn't mention what the "Original C Code" was compiled with.

igouy 10y ago

>> overhead of starting up the JVM both in time Not much for those programs: http://benchmarksgame.alioth.debian.org/sometimes-people-just-make-up-stuff.html#jvm-startup-time http://benchmarksgame.alioth.debian.org/sometimes-people-jus... >> It's pretty easy to see … memory Yes: http://programmers.stackexchange.com/a/189552/4334 http://programmers.stackexchange.com/a/189552/4334