Path: csiph.com!x330-a1.tempe.blueboxinc.net!usenet.pasdenom.info!weretis.net!feeder4.news.weretis.net!news.musoftware.de!wum.musoftware.de!fu-berlin.de!uni-berlin.de!individual.net!not-for-mail From: blmblm@myrealbox.com Newsgroups: comp.os.linux.misc Subject: Re: Good Linux to start with Date: 10 Jul 2011 19:01:08 GMT Organization: None Lines: 50 Message-ID: <97ub7kFag8U1@mid.individual.net> References: <87mxgqbheu.fsf@araminta.anjou.terraraq.org.uk> <87box6bcuk.fsf@araminta.anjou.terraraq.org.uk> X-Trace: individual.net JGfZDHlut4hFdSJLxWs9Pg9/PjOmrSQl2hu3DXY1hMezZXZGAV X-Orig-Path: not-for-mail Cancel-Lock: sha1:CuyKVQbmcU2+2lHEN1a+2oAk3qs= X-Newsreader: trn 4.0-test76 (Apr 2, 2001) Xref: x330-a1.tempe.blueboxinc.net comp.os.linux.misc:1734 (Late to the party, maybe, but I hadn't been following this thread until its longevity made me curious .... ) In article <87box6bcuk.fsf@araminta.anjou.terraraq.org.uk>, Richard Kettlewell wrote: > Mark writes: > > Richard Kettlewell wrote: > >> Aragorn writes: > > >>> Especially if you know how slow bytecode is. Just look at Java. ;-) > >> > >> A couple of years back I did a comparison between some simple integer > >> computation-heavy C (compiled with gcc -O2 for then-current GCC) and the > >> equivalent C# compiled to CIL bytecode. > >> > >> The C#/CIL version ran measurably faster. Just for fun (based on a mention of sorting in another post in this subthread) I just tried writing a simple selection sort in C and Java, and indeed -- in some environments the Java version was actually faster, which rather surprised me, and when it wasn't faster, the slowdown compared to C was, hm, I'm too lazy to compute it, but a factor of 1-point-something. > > I guess YMMV applies. Some code to parse & validate messages was > > ported from C to Java and it runs considerably slower and uses a lot > > more memory. > > The point is that the implication that bytecodes are inherently slow is > simply wrong. Another key point is that, AIUI, all (most?) current implementations of Java actually compile bytecode to native code at runtime. Supposedly this can actually produce native code faster than that produced by an optimizing compiler, since the compilation can take into account details of the environment. But in any case it means that what's actually happening at runtime is not the naive interpretation of byte code done (again AIUI) by early implementations -- which *were* slow, apparently leading many people to form opinions that could now use an update. Just sayin'. > The fact that you can construct a Java program that's > slower than a functionally equivalent C program is neither here nor > there; one could construct two functionally equivalent C programs with > very different performance characteristics, too. -- B. L. Massingill ObDisclaimer: I don't speak for my employers; they return the favor.