Apple hyping java...
Andreas.Raab at gmx.de
Mon Apr 1 12:35:09 UTC 2002
> But, I do read, and keep track of what things get mentioned
> over time, and I've noticed comments going by that seem to imply
> that they are like "green threads" in Java, meaning that I/Os
> sometimes hang them up, that sort of thing. That's not something
> I want in a thread system. I also left one item off the list,
> which is that it's nice if the threads actually use
> multiple processors on a multiple processor machine.
Correct on both accounts. Threads are green threads and they don't make
use of multiple processors. While I can't speak for MP systems I've long
thought about solutions to make all I/O non-blocking. Unfortunately,
this is not exactly simple to do in a cross-platform way.
> Remember, this is in the context of grumbling at Apple for
> going with Java instead of Squeak, and Java's support for
> threads, though not perfect, is not terrible. Apple
> builds multiprocessors, and I've been using an MP PC
> for the last five years.
I didn't even listen to this grumbling about Apple and Java. I was
interested in pointing out some of the positive aspects of Squeak in the
area of threads; I was certainly not trying to make anybody else look
bad (as if there was any need to ;-)
[Mind you, if I take my measures (which I ran across a variety of ST
implementations) if it comes to parallelism Squeak beats the hell out of
all existing Smalltalks. Wanna beat VisualWorks by a factor of 100?!
Just give it a few thousand threads to deal with ;-]
> This says (to me) that you're not using more than one processor.
> That's going to count against Squeak in some cases. Multiprocessor
> sync, even when things go well, requires some global knowledge,
> and that's costly (something like 10 memory bus cycles on a Pentium,
> was the figure I saw once).
> Except, you know what -- I'll bet you've got code written already
> that assumes that locks are very cheap, and that would change if
> you went to a "proper" MP-using implementation. I think Java had
> to deal with this -- early Java was interpreted, and for a while
> used only simple "green" threads, and all the useful datastructures
> (StringBuffer, Hashtable, Vector) were synchronized on every
> That got noticeably painful and slow when things had to work on an
> MP, and lo-and-behold, unsynchronized versions of Vector and Hashmap
> appeared. It's now one of the standard Java performance gotchas --
> "oh, you used the synchronized data structures when you didn't need
> to, and it was slow". Is that something you want for Squeak?
Most certainly not. But I'm interested if you got some data points on
how the performance shifted when switching away from the green threads.
Are there any publications on this?
> So, I don't really know the right answer here, but you might want
> to think about this one thing carefully before you take the MP
> plunge. Maybe you don't want to do it -- truly concurrent
> programming is noticeably harder than the sequential kind, even
> when sequential programming is simulating concurrent programming.
Well, I don't know. My feeling about this is that concurrency isn't
necessarily harder if the high-level abstractions support it well.
Looking at stuff like E, Mozart, ToonTalk and similar systems (which
sometimes do require a new look at what it means to write a program) I
can't say that the (usually hidden) concurrent aspects are harder to
understand than any control structures in "sequential languages". The
biggest problem with concurrency in non-concurrent languages is the
absence of high-level concurrent constructs supporting the operations in
a "natural" way.
More information about the Squeak-dev