Mailing Lists: Apple Mailing Lists
Image of Mac OS face in stamp
 
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Mac OS X Java Performance

Thanks for cranking the flame temperature down. Here are some more comments:

On Wednesday, July 30, 2003, at 02:26 PM, Todd Blanchard wrote:

OK, so I heard wrong.

Nice list of languages - I've only got Basic, FORTRAN, C, C++, Smalltalk, Objective C, and Java.

Yea. It's pretty frightening. But I started collecting a paycheck as a hacker in 1969, so it's kinda unavoidable.

Of these I like C, Smalltalk and Objective C (its a really good compromise). C because of its minimalism for high performance work.

One of the things that is not weel understood is that a good measure of C's minimalism is a result of the constraints of the environment: the first C compiler ran on a system where the maximum process size was 32K. Within that constraint, they did a masterful job.

For the others, the key feature is message sending vs function calling. DoesNotUnderstand is a very powerful thing.

My impression of Java is that there wasn't enough budget to do it right or you were trying really hard to appeal to C++ developers. Compared to Smalltalk, its not very flexible and its less productive. For instance, I still have the compile edit printf cycle (debuggers have been kind of a disappointment in Java).

One could have a long debate. There were no budget issues that inhibited "doing it right". I'd argue that is was done right. Appeasing C++ developers was a concern, but it was a small one. A bigger concern was balancing flexibility and performance. I wanted to get as much as possible of the flexibility of languages like Smalltalk or Lisp, with as much as possible of the permance of C and C++. I think we've done very well. Hotspot benchmarks frequently beat C these days - the only real performance issue we have these days is startup time., which has been getting much better.

Flexibility is also a matter of debate. Smalltalk and Lisp's flexibility is good for prototyping, but problematic for producing robust production code. Many things that sometimes feel restrictive in prototyping (classes/interfaces as strict contracts; Excepetions; ...) turn out to be liberating in production contesxts. Java is definatly biased towards producing production code.


On Wednesday, July 30, 2003, at 02:31 PM, James Gosling wrote:

This is so damned false I don't know where to begin. I designed Java so I could write more code in less time and have it be way more reliable.

Yeah, this is why Dave Winer wrote Frontier - his own dynamic language all his blog stuff is built on. He uses it all the time now - I can't say it appeals to that many people. I find it really weird for instance.

In the past I've wasted huge numbers of hours chasing down memory smashes and all the other time wasters that are so typical of what happens when writing C code. I wanted to spend time writing code, not debugging. Life is too short for debugging. All of those little "limitations" turn out to be things that make coding faster and debugging vanish.

Perhaps you should download Squeak sometime. Just to see where I'm coming from. If you compare Java to C++ - no argument its a huge improvement. BTW, the Squeak guys felt the same way and wrote the VM in Smalltalk. Then they wrote a translator to C. It gets debugged in Smalltalk though. I recommend Dan Ingall's paper "Back To The Future". ftp://st.cs.uiuc.edu/Smalltalk/Squeak/docs/OOPSLA.Squeak.html

Incidentally, this puts the lie to the idea that you need primitive types. You don't.

Depends on your performance goals. Uniform type systems are easy if your performance goals aren't real strict. In the java case, I wanted to be able to compile "a=b+c" into one instruction on almost all architectures with a reasonable compiler. The closest thing I've seen to accomplishing this is "Self" which gets close, except that the compiler is *very* complex and expensive, and it doesn't get nearly all the cases. I haven't read any of the squeak papers, so I can't comment on it.

They just complicate things. Which brings me to my favorite Java bug:

new Long(5).equals(new Integer(5)) returns false?!?! But long x = 5; int y = 5; (x==y) evaluates to true. Seems pretty inconsistent.

I basically agree with you here, but it's a long debate.


One of the design principles behind Java is that I don't care much about how long it takes to slap together something that kinda works. The real measure is how long it takes to write something solid. Lots have studies have been done on developer productivity, and Java beats C and C++ by a factor of 2.

No argument there. But that's not what I'm comparing it to. To me working in Java feels like running in heavy boots.

I'm glad you like it though.

-Todd Blanchard
_______________________________________________
java-dev mailing list | email@hidden
Help/Unsubscribe/Archives: http://www.lists.apple.com/mailman/listinfo/java-dev
Be sure to read the FAQ http://developer.apple.com/java/faq/ before posting
Do not post admin requests to the list. They will be ignored.


Visit the Apple Store online or at retail locations.
1-800-MY-APPLE

Contact Apple | Terms of Use | Privacy Policy

Copyright © 2007 Apple Inc. All rights reserved.