Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.java.programmer > #35635
| From | Askfor <askfor@nowhere.net> |
|---|---|
| Newsgroups | comp.lang.java.programmer |
| Subject | Re: Java is faster! |
| Date | 2016-09-23 20:34 +0200 |
| Organization | T-Com |
| Message-ID | <ns3tah$5ou$1@ls237.t-com.hr> (permalink) |
| References | <faster-20160923143035@ram.dialup.fu-berlin.de> |
Stefan Ram wrote: > "Java is faster! > In terms of throughput in a long running system ... > For specific applications ... > On a well tuned JVM ... > With near-optimal GC strategy selected ..." > > says Chandler Carruth, one of Google's C++ experts. (JFTR) > Long ago I have been using Borland C compiler on DOS. One day I wanted to see how it generates x86 assembly code. I have written a simple C program and instructed compiler to generate assembly source. When it was done I was impressed. The code was barely readable, but efficient. Jumps were made in totally wild ways, but it made sense. If human being tried to write the same code in assembly, he or she would have had to split it in some logically structured and readable sections because it was relatively large piece of assembly code. Because of it, the code probably wouldn't have been optimal. Compiler, on the other hand, did not bother with it. It simply organized code in most efficient way, ignoring readability. So, it is possible for JVM to generate large chunks of machine code when it needs that, and it might be more optimized because it has "bigger picture". Higher leve instructions generate larger chunks of code, which might get better optimization.
Back to comp.lang.java.programmer | Previous | Next | Find similar | Unroll thread
Re: Java is faster! Askfor <askfor@nowhere.net> - 2016-09-23 20:34 +0200
csiph-web