On Sun, 10 Apr 2005, Christopher Smith wrote:
> I presume you mean "faster than C code". Of course, there was a time > where the statement was "there isn't one thing a C project can do faster > than an assembly project". True. However, some have already expressed belief that if one is able to program in C, then they are able to program in Java. The problem is that ASM is a lot more difficult to follow than C code. And, what we are really saying when we say, 'if you can program in C, then you can program in PHP/Java/PERL et al.', is 'if you are familiar with issuing logical instructions in C then the same syntax is prevelant in many other languages.' It's not true, that C programming and all it's philosophies may be used to any level of effectiveness in complex programming across non-procedural languages. With this in mind, I have to concede that as computers become more capable and faster, that more complex languages will arise where the new language may not perform as fast as the older language. It's just that C remains technically practical for any of the applications available today. To write PhotoShop entirely in ASM would just be suicide, but how much of Gimp is done in Java? This is the relation, most people still do not utilize the object oriented approach in project design, making the difference between C and C++ projects mere smoke and mirrors and a hand full of buzz-words. So, while it was true and people did say the same thing when C was taking over ASM projects, I think today we have more validity in complaining about the lack of advantages in speed and efficiency of Java replacing C. > A nice global optimizing compiler can, depending on the project, make > C code outperform assembler unless the assembler programmer spends a > *lot* more time optimizing his/her code. Very true. A lot of todays ASM goes into direct hardware access or other low level things: such as writing drivers, kernel loaders, boot loaders etc. > With Java and C this is even more true, as > their runtime abstractions are quite different, resulting in different > performance trade offs which can favour one or the other. Sure, you > could write a C program that generated and executed assembly on the fly, > and allowed for heap allocated objects to be preemptively moved > around... but think of all the work! Think of how hard it'd be to work > with standard tools and libraries. Yuck! I agree. This is why I try to decide the best tool for the job. > efficiently. The "painfully slower" scenario applies to Sun's J2SE JDK > runtime, which as you can imagine, isn't terribly optimized for "hello > world" type programs. ;-) Yes, most of the JVMs I deal with are Sun's own. I have put some interest in IBMs JVM, but I didn't see any convincing reason to advocate it's use over Sun's. > >I have never seen a company say, "We would like this to run > >on Linux, whats the best route? Port the Win32 code base to Java!" > >I'm sure this has happened a few times, I never saw it it's usually > >the other way round. > > The primary reason for this in my experience has been the poor support > for Java on Linux. With everything that I agree with in your post, here I have to say no. I think that Java on Linux is on par with Windows. Java support on Solaris is virtually unbelievable considering the two comes from the same company. Java on MacOS X is pretty painful too, despite Apple managing the JVM releases. I have Blackdown on my AMD64, but I haven't compared it to Sun's JVM on a 32bit system; partly becuase of my new impartial feelings towards Java. I judge this based off of some very complex Java/Swing applications I have ran on both systems. And, Linux perform very well. > What has been common, particularly in the past, has > been "We would like this to run on Unix, what's the best route? Port the > Win32 code base to Java!". Well, I haven't seen this myself. I'll admit, that every place I have worked at was predominatly UNIX; some flavor of UNIX to include Linux. Some people I have talked to, never saw a UNIX or Linux box. So, it might be natural for either extreme to witness this practice, however I refuse to lean on suspicion in light of an 800lb gorrilla as my heart is for expanding the use of free software. Omega -- [email protected] http://www.kernel-panic.org/cgi-bin/mailman/listinfo/kplug-lpsg
