At 04:12 PM 3/29/2002 -0600, Aaron J Reichow wrote:
Oh yeah, Java SUCKS.
Too true!
Guys,
It doesn't suck enough to make a difference, and too many times people have declared that "thus-and-such-sucks" for that simple assertion to convince anyone. Remember, people aren't comparing Java to Squeak (or ML, or Haskell) -- they're comparing it to C++. In that comparison, Java looks pretty good.
If you want to convince someone, you have got to put a little more work into your argument, and think a bit about your audience.
Just for example -- I wouldn't write a compiler in Squeak. I might write a game, or a web server, or a graphical app, in Squeak. From what I see of the discussions of threads and security on this list, I am not at all sure that I would use Squeak in a context where I really needed lots of threads running well, or someplace where I had to worry about someone finding a way in through some hole; the discussions have just not been very confidence-inspiring.
That's just my advice, worth at least what you paid for it. I downloaded Squeak once and played with it, and thought it was very interesting, but could never figure out where to begin. I don't have enough free time for this sort of unguided adventure, and I don't think I differ much from most people (except that I probably pick up languages faster than your average bear, and I actually think it would be good for me to learn Squeak).
So, to get to the point, you should either quit whinging about how much Java sucks and how misguided Apple is, or you should do something about it. And YOU should do something about it; I also want to become more proficient in ML and Haskell, and I will pursue whichever learning curve is gentlest.
yours, grumpily,
David Chase (who usually just reads this list)
On Fri, 29 Mar 2002, David Chase wrote:
[snip]
Just for example -- I wouldn't write a compiler in Squeak.
I would.
There are several compiler written in Squeak including Squeaks own :)
I might write a game, or a web server, or a graphical app, in Squeak. From what I see of the discussions of threads and security on this list, I am not at all sure that I would use Squeak in a context where I really needed lots of threads running well,
"lots of threads running well" is a bit ambiguous since a lot depends on what you mean by "lots", "well", and, for that matter, "threads" :)
Squeak *standardly* has "lots of threads running well" (or, at least, "several threads running well"), unlike many langauge systems. (For *oodles* of threads runnin *great* in an *easy to program way*, I prefer Erlang, I confess :)).
[snip]
That's just my advice, worth at least what you paid for it. I downloaded Squeak once and played with it, and thought it was very interesting, but could never figure out where to begin. I don't have enough free time for this sort of unguided adventure,
FWIW, there are three books on Squeak in print. They are all fairly good, IMHO, though they have different strengths and weaknesses and surely won't appeal to everyone. The Smalltalk literature is reasonably large too, and much of it is very nice.
[snip]
So, to get to the point, you should either quit whinging about how much Java sucks and how misguided Apple is, or you should do something about it.
I prefer to do both :)
And YOU should do something about it;
I also prefer to get other peple to do something about it :)
I also want to become more proficient in ML and Haskell, and I will pursue whichever learning curve is gentlest.
My experience favored Haskell, FWIW. Check out the HaXML utilities. Pointers included in the following article:
http://www.xml.com/pub/a/2001/02/14/functional.html
I also do recommend Erlang. No static typing (in general use), which really makes ML and Haskell different, but it's very very neat and, IMHO, fun to program. Lots of good docs. Big libraries. Etc.
yours, grumpily,
I see your grumpiness and raise you a cranky.
David Chase (who usually just reads this list)
Cheers, Bijan Parsia (who usually just thinks that he *is* the list :))
On Fri, 29 Mar 2002, David Chase wrote:
It doesn't suck enough to make a difference, and too many times people have declared that "thus-and-such-sucks" for that simple assertion to convince anyone.
It sucks enough to make a difference to some people, like myself, who don't use it. If it didn't suck, I would use it.
I agree about the "thus-and-such-sucks," business, but I'm not trying to convince anyone. I was agreeing. If the context were different, perhaps trying to convince a professor let me use Smalltalk on a project rather than Java, or answering one of the "Why Smalltalk over Java?" threads in comp.lang.smalltalk, I would've been obliged to back up that statement, if I wanted anyone to take my assertion seriously. But I'm not here to convince anyone to use Squeak over Java- if they want to know why they should, I imagine they would start a thread. (has anyone else noticed the remarkable lack of Squeak vs. XXX-lang on the list?)
Remember, people aren't comparing Java to Squeak (or ML, or Haskell) -- they're comparing it to C++. In that comparison, Java looks pretty good.
On a Smalltalk list, I imagine they would be comparing Java to Smalltalk. In a lot of ways, they are similar in methodology, and have similar strengths. Java over C++ advocacy on a Smalltalk list would be a wee bit [OT]. :)
If you want to convince someone, you have got to put a little more work into your argument, and think a bit about your audience.
In the context of the list, why? A lot of those on this list have a general idea why we would think that Java sucks. Those of us who agree all have our overlapping reasons. My audience here isn't hardcore C++ coders.
So, to get to the point, you should either quit whinging about how much Java sucks and how misguided Apple is, or you should do something about it. And YOU should do something about it; I also want to become more proficient in ML and Haskell, and I will pursue whichever learning curve is gentlest.
What would you propose? I use Squeak in the real world, where non-squeakers see my apps. I've written a couple small Mac apps with it that other people use. I don't think trying to advocate to Apple would do much good.
Like Bijan, I would say go with Haskell. Just generally made more sense to me, but YMMV. :)
David Chase (who usually just reads this list)
Regards, Aaron (who spends more time answering questions on #squeak than replying here)
Aaron Reichow :: UMD ACM Pres :: http://www.d.umn.edu/~reic0024/ "A weed is just a plant whose virtures have not yet been discovered." :: r. w. emerson
At 12:45 AM 3/30/2002 -0600, Aaron J Reichow wrote:
Remember, people aren't comparing Java to Squeak (or ML, or Haskell) -- they're comparing it to C++. In that comparison, Java looks pretty good.
On a Smalltalk list, I imagine they would be comparing Java to Smalltalk.
I thought that this list was already pretty much for the converted, or at least the sympathetic. "java sucks", "amen!" is, as they say, preaching to the choir, at least here. It may feel good, you may get a good loud "amen" back, but it's not very productive. Squeak's a bit of a fringe language, if you could get a slightly bigger bandwagon, that would probably be a good thing. You might get someone to write "Squeak for dummies".
So, to get to the point, you should either quit whinging about
how much Java sucks and how misguided Apple is, or you should do something about it. And YOU should do something about it; I also want to become more proficient in ML and Haskell, and I will pursue whichever learning curve is gentlest.
What would you propose? I use Squeak in the real world, where non-squeakers see my apps. I've written a couple small Mac apps with it that other people use. I don't think trying to advocate to Apple would do much good.
There's at least one Squeak application that made me go "wow!", and that was the player-piano/orchestra. I thought that was really cool. However, I don't know what was underneath it. What would complete the "wow!" is seeing that the code behind it (which I had a hard time finding) is not too large, not too crammed full of special cases, easy to reuse, easy to understand, easy to extend.
In terms of Java versus Squeak, I wouldn't promote Squeak for writing compilers. (Yes, I know some people do, but I know someone who wrote an optimizing compiler in Fortran. We did a vectorizer in PL/1, too. That doesn't mean it's a good idea.) Java's type system isn't annoying enough there to make a difference (and sometimes, it is very helpful to have things statically checked), and a complex optimizing compiler is not an easy thing to to test by pieces.
On the other hand, dealing with user interfaces, and presenting data to users, seems to be something where Squeak's flexibility might help you. I'm working on something now that is best described as underspecified ad-hoc middleware, in Java, and I find myself bumping into what I know are artifacts of Java's type system, frequently. Furthermore, the development/testing goes in a much different style than the compiler -- the server runs, I poink the web page, I look at what comes out, if I don't like it, I dribble in some breakpoints and try it again, stepping through to see if I like what I see. I don't debug compilers this way, you can be sure of that. The difference between this and a typical compiler is that the interface (here) is very wide, and loosely specified, and there's a relatively small amount of computing that takes place between poink and redisplay. In a compiler, the inputs and outputs are well-specified, and there may be a tremendous computing "distance" between them.
My one reservation is the threads. Squeak (which is both a language and an implementation) is, to my taste, weak there. Java, a language, is usually implemented with crappy threads. My employer/ company (NaturalBridge) did a Java implementation that supports about 30,000 threads, which is "enough" for now, though in my personal opinion clearly still limited. Sun's trying to promote asynchronous I/O (in jdk1.4) instead of cheap threads, which I think is just plain insane on several counts. It is vastly easier to write (something like) a web server or transaction processing engine if the code you are writing is structured as a thread (or two) per transaction. If Squeak has expensive threads (like most Java implementations, not like NaturalBridge's, not like Erlang) it will be somewhat limited for a class of applications where I think it would actually be rather well-suited.
Another possibility, and here I would worry about security (maybe) is in the design of games. It just looks like Squeak should be good for this, what with the nice UI. I guess I should be a little careful what I mean when I say "game". I'm not talking about 3-D psuedo-realistic blood-n-guts foo, but little fun games, along the lines of Tetris, or MacSokoban, or MozPong. And maybe, it could be put on the net. It's been done before, but I would hope that (because of the flexibility in the language itself) it could be done better, or maybe very thoroughly (as in, could you put together a framework so that you could implement every single game in Hoyle, just "because it was there".)
So, I guess if I was going to do something productive, I would download the latest stable version, and have another go at doing something fun/useful, and take notes of everyplace I got confused or frustrated, document that, and call it Squeak for dummies.
David Chase
Hi
I do not have the expertise but I would like to know how we could improve the thread model of Squeak. I started to look at Mozart which apparently has a good thread model and was wondering if it could be possible to imporve the one of Squeak.
Have you any intention in this direction? Squeak belongs also to the people that improve it ;)
My one reservation is the threads. Squeak (which is both a language and an implementation) is, to my taste, weak there. Java, a language, is usually implemented with crappy threads. My employer/ company (NaturalBridge) did a Java implementation that supports about 30,000 threads, which is "enough" for now, though in my personal opinion clearly still limited. Sun's trying to promote asynchronous I/O (in jdk1.4) instead of cheap threads, which I think is just plain insane on several counts. It is vastly easier to write (something like) a web server or transaction processing engine if the code you are writing is structured as a thread (or two) per transaction. If Squeak has expensive threads (like most Java implementations, not like NaturalBridge's, not like Erlang) it will be somewhat limited for a class of applications where I think it would actually be rather well-suited.
Stef
At 08:27 PM 3/30/2002 +0100, ducasse wrote:
I do not have the expertise but I would like to know how we could improve the thread model of Squeak. I started to look at Mozart which apparently has a good thread model and was wondering if it could be possible to imporve the one of Squeak.
Have you any intention in this direction? Squeak belongs also to the people that improve it ;)
My one reservation is the threads. ...
There's several ways to have good support for threads:
1) no stupid restrictions on how many.
2) locks should be fast -- ideally, about as fast as a bus-locked compare-and-swap (or load-linked/store-conditional) to acquire or release one. They should also be pretty near fair (FIFO) in how they give competing threads access to the lock. Note that this is independent of how "lock" is spelled in the source language -- when you rip away the abstractions, there's mutual exclusion at the bottom, and threads are competing for access, and it should be fast and fair.
3) there should probably be a useful set of different lock types provided. Not only do people botch them when they roll their own, the underlying implementation can probably do them faster. Java's a little sparse here -- you get synchronized, wait, notify, that's all. (Modula-3 is the same.) You might find yourself wanting (e.g.) reader/writer locks, so that you could have many concurrent readers.
4) there needs to be a consistent/complete set of primitives. Java and Modula-3 do okay here -- you can use sync/wait/notify to build all the others without gratuitous busy-waiting etc. It's not a comprehensive set of operations, but it is at least consistent and complete.
5) don't do what Java did -- don't make "any object" also able to function as a lock. It's painful to implement, steals bits from your garbage collector, and (in a big system, or one that you want to be secure) not useful anyway.
6) wouldn't hurt a bit to go look at Doug Lea's work with Java. I regard most of what he did as "Java needed this, but they left it out, so here is something that does what you need and works".
The answer I just gave you is conventional and low-risk. Periodically people come up with "you really ought to do it this way" formulations for locking, but most of these never seem to catch on. I don't know if it's because of insufficient bandwagon, or if they are fundamentally flawed, or if (it turns out that) ubiquitous locking is just too damn expensive (it IS quite expensive on many multiprocessors). There is also Erlang, which I don't know enough about.
One reservation I have about locking, concurrency, and OO in general, is whether there's a plain old conflict in the styles. There's problems in some of the Java libraries, with objects that can "change". They inherited too much from C/C++, and many of the data structures are mutable by default. That forces synchronization on both modify and on access, and (because Java synchronization is simple exclusive access) that creates inefficiencies and bottlenecks. Worst thing is, in a big system you cannot "take advantage" (as if it were a good thing) of this mutability, because the objects are shared, and you don't know whether the other viewers are prepared for the change.
It is "better", both in avoiding needless sync cost, and because you don't really know who is referencing what, to adopt an idiom where (shared) objects are initialized, and never change state after that. Not completely functional, but more nearly functional. This isn't true for all objects, but in general, there's lots of them that should not be gratuitously mutable. How will this fit with Squeak?
There is a high-risk answer, also, that is independent of how you present threads/locking to users. If you want high performance, you'll either need to restrict your attention to the (empty?) set of OSes with good thread support, or else you'll have to do it yourself, at the very lowest level. We lean heavily on the compiler in the Java system that I worked on (30,000 threads possible) and also use unorthodox calling conventions that have to be hidden from native code. In an interpreted system, it's not quite so extreme, but you still have to be careful with your I/O libraries.
David Chase
David,
My one reservation is the threads. ...
I wonder why - have you ever looked at Squeaks threads?! Here are few comments on your suggestions.
There's several ways to have good support for threads:
- no stupid restrictions on how many.
In Squeak there are none. There are a few implications for the garbage collector (these are of highly technical nature and solutions have been proposed) but I've been using plenty (e.g., >10k) of threads in Squeak with no problems whatsoever (err ... besides debugging them ;-)
- locks should be fast -- ideally, about as fast as a bus-locked compare-and-swap (or load-linked/store-conditional) to acquire or release one.
In Squeak, locks are almost as fast as that. I once measured the overhead of a thread switch (which is what really counts here since if the lock can be aquired the entire operation is basically zero cost) and the it's roughly the speed of four message sends. In other words, if your machine makes a million msg sends per second you can do a quarter million process switches per second easily.
They should also be pretty near fair (FIFO) in how they give competing threads access to the lock.
In Squeak, they are.
Note that this is independent of how "lock" is spelled in the source language -- when you rip away the abstractions, there's mutual exclusion at the bottom, and threads are competing for access, and it should be fast and fair.
That's exactly the case in Squeak.
- there should probably be a useful set of different lock types provided.
Which types? We only have one but everything else can be trivially added. Not at the same speed but once the functionality is there it could be moved down to the VM level and be handled more efficiently there.
- there needs to be a consistent/complete set of primitives.
What does 'complete' mean in this context?
- don't do what Java did -- don't make "any object" also able to function as a lock.
We don't. There's class Semaphore and everything is implemented here. Note that there are a few advantages to having every object be able act as a lock - it frees you from adding the necessary access wrappers in each and every function.
- wouldn't hurt a bit to go look at Doug Lea's work with Java. I regard most of what he did as "Java needed this, but they left it out, so here is something that does what you need and works".
Since I haven't looked at it, can you elaborate a bit on what he did?
Cheers, - Andreas
On Sunday 31 March 2002 04:34 pm, Andreas Raab wrote:
6) wouldn't hurt a bit to go look at Doug Lea's work with Java. I regard most of what he did as "Java needed this, but they left it out, so here is something that does what you need and works".
Since I haven't looked at it, can you elaborate a bit on what he did?
Doug wrote an excellent book called "Concurrent programming in Java: Design principles and patterns", published by Addison-Wesley. ISBN=0201310090
Table of Contents:
1. Concurrent Object-Oriented Programming. Using Concurrency Constructs. A Particle Applet. Thread Mechanics. Further Readings.
Objects and Concurrency. Concurrency. Concurrent Execution Constructs. Concurrency and OO Programming. Object Models and Mappings. Further Readings.
Design Forces. Safety. Liveness. Performance. Reusability. Further Readings.
Before/After Patterns. Layering. Adapters. Subclassing. Method Adapters. Further Readings.
2. Exclusion. Immutability. Applications. Construction.
Synchronization. Mechanics. Fully Synchronized Objects. Traversal. Statics and Singletons. Deadlock. Resource Ordering. The Java Memory Model. Further Readings.
Confinement. Confinement Across Methods. Confinement Within Threads. Confinement Within Objects. Confinement Within Groups. Further Readings.
Structuring and Refactoring Classes. Reducing Synchronization. Splitting Synchronization. Read-Only Adapters. Copy-on-Write. Open Containers. Further Readings.
Using Lock Utilities. Mutexes. Read-Write Locks. Further Readings.
3. State Dependence. Dealing with Failure. Exceptions. Cancellation. Further Readings.
Guarded Methods. Guarded Suspension. Monitor Mechanics. Guarded Waits. Notifications. Timed Waits. Busy Waits.
Structuring and Refactoring Classes. Tracking State. Conflict Sets. Subclassing. Confinement and Nested Monitors. Further Readings.
Using Concurrency Control Utilities. Semaphores. Latches. Exchangers. Condition Variables. Further Readings.
Joint Actions. General Solutions. Decoupling Observers. Further Readings.
Transactions. Transaction Protocols. Transaction Participants. Creating Transactions. Vetoable Changes. Further Readings.
Implementing Utilities. Acquire-Release Protocols. Delegated Actions. Specific Notifications. Further Readings.
4. Creating Threads. Oneway Messages. Message Formats. Open Calls. Thread-Per-Message. Worker Threads. Polling and Event-Driven IO. Further Readings.
Composing Oneway Messages. Composition. Assembly Line. Further Readings.
Services in Threads. Completion Callbacks. Joining Threads. Futures. Scheduling Services. Further Readings.
Parallel Decomposition. Fork/Join. Computation Trees. Barriers. Further Readings.
Active Objects. CSP. Further Readings.
Thanks Ned. I'll get a copy of it.
Cheers, - Andreas
-----Original Message----- From: squeak-dev-admin@lists.squeakfoundation.org [mailto:squeak-dev-admin@lists.squeakfoundation.org] On Behalf Of Ned Konz Sent: Monday, April 01, 2002 2:45 AM To: squeak-dev@lists.squeakfoundation.org Subject: Re: Apple hyping java...
On Sunday 31 March 2002 04:34 pm, Andreas Raab wrote:
6) wouldn't hurt a bit to go look at Doug Lea's work with Java. I regard most of what he did as "Java needed this, but
they left
it out, so here is something that does what you need
and works".
Since I haven't looked at it, can you elaborate a bit on
what he did?
Doug wrote an excellent book called "Concurrent programming in Java: Design principles and patterns", published by Addison-Wesley. ISBN=0201310090
Table of Contents:
- Concurrent Object-Oriented Programming.
Using Concurrency Constructs. A Particle Applet. Thread Mechanics. Further Readings.
Objects and Concurrency. Concurrency. Concurrent Execution Constructs. Concurrency and OO Programming. Object Models and Mappings. Further Readings.
Design Forces. Safety. Liveness. Performance. Reusability. Further Readings.
Before/After Patterns. Layering. Adapters. Subclassing. Method Adapters. Further Readings.
- Exclusion.
Immutability. Applications. Construction.
Synchronization. Mechanics. Fully Synchronized Objects. Traversal. Statics and Singletons. Deadlock. Resource Ordering. The Java Memory Model. Further Readings.
Confinement. Confinement Across Methods. Confinement Within Threads. Confinement Within Objects. Confinement Within Groups. Further Readings.
Structuring and Refactoring Classes. Reducing Synchronization. Splitting Synchronization. Read-Only Adapters. Copy-on-Write. Open Containers. Further Readings.
Using Lock Utilities. Mutexes. Read-Write Locks. Further Readings.
- State Dependence.
Dealing with Failure. Exceptions. Cancellation. Further Readings.
Guarded Methods. Guarded Suspension. Monitor Mechanics. Guarded Waits. Notifications. Timed Waits. Busy Waits.
Structuring and Refactoring Classes. Tracking State. Conflict Sets. Subclassing. Confinement and Nested Monitors. Further Readings.
Using Concurrency Control Utilities. Semaphores. Latches. Exchangers. Condition Variables. Further Readings.
Joint Actions. General Solutions. Decoupling Observers. Further Readings.
Transactions. Transaction Protocols. Transaction Participants. Creating Transactions. Vetoable Changes. Further Readings.
Implementing Utilities. Acquire-Release Protocols. Delegated Actions. Specific Notifications. Further Readings.
- Creating Threads.
Oneway Messages. Message Formats. Open Calls. Thread-Per-Message. Worker Threads. Polling and Event-Driven IO. Further Readings.
Composing Oneway Messages. Composition. Assembly Line. Further Readings.
Services in Threads. Completion Callbacks. Joining Threads. Futures. Scheduling Services. Further Readings.
Parallel Decomposition. Fork/Join. Computation Trees. Barriers. Further Readings.
Active Objects. CSP. Further Readings. -- Ned Konz currently: Stanwood, WA email: ned@bike-nomad.com homepage: http://bike-nomad.com
At 02:34 AM 4/1/2002 +0200, Andreas Raab wrote:
David,
My one reservation is the threads. ...
I wonder why - have you ever looked at Squeaks threads?! Here are few comments on your suggestions.
Not really. I read the Squeak list partly because I am not completely happy with Java, and I wonder what might be better. (All programming languages suck, but some of them suck a little less.) I also read it because I have never been happy with any of the UI programming stuff that I've tried to use. But, I don't have the time to really dive in and go after it. I keep hoping I will have the opportunity. I've tried a couple of times, and gotten pissed off at what looks to me like an unnecessarily terse and cryptic UI (but that is another matter).
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. 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.
(but, see below).
In Squeak, locks are almost as fast as that. I once measured the overhead of a thread switch (which is what really counts here since if the lock can be aquired the entire operation is basically zero cost)
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 operation. 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?
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.
- there needs to be a consistent/complete set of primitives.
What does 'complete' mean in this context?
Complete, meaning that you can actually build the things you need if they aren't there. E.g., sync/wait/notify lets you build "condition variables" w/o busy waiting, in the idiom of
sync (foo) { while (! condition) { foo.wait(); }}
and
sync (foo) { modify condition; foo.notify(); }
Readers and writers you would build out of s/w/n, but it's tricky enough that I'd fear a goof just typing it out as fast as I can type, and r/w CAN go quickly (even on a MP) if it is supported as a primitive, otherwise it's a pile of bus-locks and not so quick.
"Complete", of course, is not necessarily useful. You can compute anything you want with the S-K combinators because they're complete, but generally, people don't try to get much done with them, because it is so tedious.
So, what you want is a set of operations that is complete (in case you need to build something new) but also contains canned solutions to the 90-95% of the cases that people use synchronization for (buffers, readers and writers, thread pools, shared caches). It shouldn't be hard, maybe you've done it already, plus you can turn those operations into primitives to make them go fast.
David Chase
David,
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 operation. 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.
Cheers, - Andreas
On Mon, 1 Apr 2002, Andreas Raab wrote:
David,
[snip]
I didn't even listen to this grumbling about Apple and Java.
(Me neither, fwiw.)
I was interested in pointing out some of the positive aspects of Squeak
(Me too)
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 ;-]
Have you checked out Smalltalk MT (either of you?).
"""Robust multithreaded implementation: Smalltalk MT is multithreaded from the ground up, with garbage collection running in a separate thread. A process can have any number of threads. This enables the development of scalable applications on Windows NT, and simplifies considerably the design and implementation of applications that use blocking I/O. There are no restrictions on sharing data between threads (other than application-specific synchronization issues). In addition, all Win32 synchronization mechanisms can be used, which enables a non-Smalltalk thread or process to synchronize with a Smalltalk thread. Starting with version 2.5, fibers and asynchronous procedure calls (APC) are also supported. """
I've heard *lots* of praise for them. To my mind, if one is looking for OS thread support in a Smalltalk, here is the place to look first.
Cheers, Bijan Parsia.
At 02:35 PM 4/1/2002 +0200, Andreas Raab wrote:
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?
None published. I've taken various measurements over the years, I can give you some from memory. This stuff varies from platform to platform -- the one I know well is non-Xeon Pentium.
1. In an experiment, I added a single (call to a) locked-compare-and- swap in the copy-an-object code in a full stop-and-copy collector. GC took 60% longer. Yes, it is that expensive.
2. Embedded in a benchmark, this piece of code takes 875 ms (iterated many times, run with a particular Java VM I know well).
static int mul1(int a, int b) { int result=0; for (int i = 0; i < 32; i++) { result += result; if (a < 0) { gratuitousCounter++; result += b; } a = a + a; } return result; }
If I add synchronization and run on a 2-processor, it takes 5100 milliseconds. (That's what I call expensive.) No contention at all, just one thread running hard.
static int mul6(int a, int b) { int result = 0; for (int i = 0; i < 32; i++) synchronized (a_lock) { result += result; if (a < 0) { gratuitousCounter++; result += b; } a = a + a; } return result; }
If I run that code in 1-processor mode (uses compare-and-swap, but does not lock) it takes 2400 milliseconds. The lock is that costly (that is, 3x the cost of the original loop body, just for the lock).
If I run that code with the lock held outside the loop (the recursive lock is detected and goes much faster) it takes 1640 milliseconds. This is closer to what you might expect with green threads in the uncontended case.
What I've just described here is an honest benchmark, in that I am telling you exactly what optimizations are taking place, and there's nothing hidden. An uncontended lock acquire is a load, some bit-fiddling, a couple of tests, and perhaps a locked compare-and-swap. A release is similar.
I hope this is helpful; I can provide a bit more details, if I know what you want. Other processors have different costs for doing this sort of thing. The difference between plain old Pentium and Xeon is that Pentium locks the whole memory bus, whereas Xeon only locks the relevant cache line in memory.
I'll reply to the other bit later -- I've got a lunch appointment.
David Chase
On Sat, 30 Mar 2002, David Chase wrote:
[snip]
I thought that this list was already pretty much for the converted, or at least the sympathetic. "java sucks", "amen!" is, as they say, preaching to the choir, at least here. It may feel good, you may get a good loud "amen" back, but it's not very productive.
Er....I'd be *wildly* suprised (Java sucks) if *any(Java sucks)one* who said (Java sucks) "Java sucks" on the (Java sucks) Squeak list *imagined* (Java sucks) that saying (Java sucks) "Java sucks" on the (Java sucks) Squeak list was a (Java sucks) bit of (Java sucks) PRODUCTIVE (Java sucks) behavior (and Java sure does suck).
On the (Java sucks) other hand (Java sucks), it's not like it (Java sucks) consumes all *that* (Java sucks) much time or (Java sucks) energy or even (Java sucks) good will. So who (Java sucks) cares?
Squeak's a bit of a fringe language,
Yep. Bothers me not at all. Would I be better off if Squeak ruled the world? Not as far as I can tell. Rather, not *necessarily*. Would more money into Squeak development be nice? Sure. I guess. It depends. I like to think that Squeak is a bit independent of Market Forces in the grand sense, and I like it that way. Other folks don't, or think that Squeak bending to the wind will help make it more the way they want. So, we differ :)
if you could get a slightly bigger bandwagon, that would probably be a good thing.
Eh. First, I think Squeak has a sufficient bandwagon. It and its community has been growing steadily and fairly quickly for the 5 or so years I've been using it. Sometimes there have been growing pains at that speed, as well as "To slowing" pains. Speeding it up won't necessarily make it better.
You might get someone to write "Squeak for dummies".
The chief value of which, afaict, would be that there would be a Squeak book that I would not, and would not *want*, to own.
So, to get to the point, you should either quit whinging about
how much Java sucks and how misguided Apple is, or you should do something about it. And YOU should do something about it;
I see nothing wrong with whinging about Java. If Java can't take it, it should get out of the kitchen and stop wrecking my toaster. *EVERYBODY* whinges about other languages. More importantly *EVERYONE* whinges about Java except those crippled by having to use it all the time :)
I've even (gasp) heard people complain about SQUEAK, if you can imagine!
[snip]
There's at least one Squeak application that made me go "wow!", and that was the player-piano/orchestra. I thought that was really cool. However, I don't know what was underneath it. What would complete the "wow!" is seeing that the code behind it (which I had a hard time finding)
Learning how to explore Squeak from the app into the code is a key "aha" moment, in my experience. Obviously, you haven't gotten there yet. It might be interesting to know what books/articles/whatever you used so we can rectify them a bit.
I say this not to excuse, but there are efforts to make this sort of thing happen. I.e., documentation. And it has gotten better over the years. It's just very much non-trivial.
is not too large, not too crammed full of special cases, easy to reuse, easy to understand, easy to extend.
Some Squeak code is like this, some not. It depends. I think I can speak for everyone when I say that the *aim* is for all to be like that.
In terms of Java versus Squeak, I wouldn't promote Squeak for writing compilers.
I know, but I don't see why not. Squeak is great for writing a wide variety of compliers. You've not done it, I take it.
It's especially nice for dynamic scripting langauges that you want to target to a portable but reasonably nippy VM.
People have used Smalltalk for compiler tech for years, just as they use Prolog, Common Lisp, and other very high level languages.
(Yes, I know some people do, but I know someone who wrote an optimizing compiler in Fortran. We did a vectorizer in PL/1, too. That doesn't mean it's a good idea.)
Sure, just because people *do* doesn't mean it's a good idea. After all, people *do* program in Java ;) But you've not given ONE reason why it's a bad idea, or why you wouldn't recommend it. Indeed, AFAICT, you have *no* experience with this at all.
Java's type system isn't annoying enough there to make a difference
That has to be, in part, a matter of taste.
(and sometimes, it is very helpful to have things statically checked),
AFAIK, the jury is still out.
and a complex optimizing compiler is not an easy thing to to test by pieces.
What? Compilers, including optimizing ones, are among the most modular -- and well understood how to modularize -- sorts of projects. Ergo, you'll have plenty of pieces to test.
Plus, "complex optimizing" compilers doesn't *nearly* exhaust the range of compilers out there. Plus, think about Self for a minute.
Finally, I hardly see Java's type system as a win for compilers, it's not like you can build an algebra in any natural way and apply complex transformations in a type checked manner. I mean, it's still going to be a dynamic OOP like system. (I'm ignoring Java addons that give you generics or the like.)
You've just moved into troll land, as far as I'm concerned.
[snip]
Cheers, Bijan Parsia.
On 3/30/02 3:09 PM, "Bijan Parsia" bparsia@email.unc.edu wrote:
You might get someone to write "Squeak for dummies".
The chief value of which, afaict, would be that there would be a Squeak book that I would not, and would not *want*, to own.
No no no. Free market system alert. I'll buy the book just to: 1) encourage the author to write more Squeak books 2) encourage the publisher to publish more Squeak books 3) to show people that there really are all kinds of Squeak books available when they see my technical reference shelf. Squeak books are top shelf right next to Smalltalk-80.
You know where my Java books are, right?
That's a little bit on the silly side. But I tend to encourage anything that promotes Squeak.
- Steve
On Sat, 30 Mar 2002, Stephan B. Wessels wrote:
On 3/30/02 3:09 PM, "Bijan Parsia" bparsia@email.unc.edu wrote:
You might get someone to write "Squeak for dummies".
The chief value of which, afaict, would be that there would be a Squeak book that I would not, and would not *want*, to own.
No no no. Free market system alert.
No no no. I *am* using the Free market system. I tend to buy/collect Smalltalk books. I strictly avoid "for Dummies" etc. books.
I'll buy the book just to: 1) encourage the author to write more Squeak books
If it's not an author I already know, I would still want to discourage them from writing *such* books.
2) encourage the publisher to publish more Squeak books
Similarly. Really. An O'Reilly book has some cachet. A For Dummies book just sucks. IMHO.
3) to show people that there really are all kinds of Squeak booksavailable when they see my technical reference shelf. Squeak books are top shelf right next to Smalltalk-80.
Yes yes. I own all the Squeak books and most of the Smalltalk books and quite a few Prolog books (oops).
You know where my Java books are, right?
That's a little bit on the silly side. But I tend to encourage anything that promotes Squeak.
I *hope* it is evident that I do to. But that tendancy gets overridden on occasion. I can't see doing all that much for the sake of a For Dummies book.
But that's just me. I really hate the For Dummies type books. Really really. I have no problem with *introductory* books, but I think we can do better in general.
There are flaws in the current set of Squeak books, but at least they exist :) I'm watching the Ruby shelf, and that set of books is growing faster, but I find them, overall, to be rather unpleasent (IMHO). Indeed, a turn off. Python suffered a bit from this too.
We have a good textbook, a really need anthology, and an interesting tutorialy thingy. Just keeping them updated (they aren't!) is a huge task. Churning out a slew of crap books seems a waste.
I, of course, wouldn't *sabotage* a Squeak for Dummies, but I hereby discourage it.
Cheers, Bijan "Java sucks" Parsia.
...former dummies?
...smarties?
-C
-- Craig Latta composer and computer scientist craig.latta@netjam.org www.netjam.org crl@watson.ibm.com To quote is human, to paraphrase divine.
squeak-dev@lists.squeakfoundation.org
-
Aaron J Reichow -
Andreas Raab -
Bijan Parsia -
Craig Latta -
David Chase -
ducasse -
Ned Konz -
Stephan B. Wessels