it's impossible (today, anyway) to make a language perform at a level acceptable for most applications without primitive strings, ints, bools, etc.
His argument doesn't make sense. The performance gain resulting by the use of primitives instead of objets is marginal, simply because these primitives have to be manipulated by calling methods or functions and these operations are not cheap. Fast, maybe, but not dramatically faster.
- Isn't Smalltalk basically competitive with C#? Yeah, it's
slower, but not as much slower as, say, VB has been over the years. And it's not nearly as slow as Python or Ruby, which are currently far more popular.
A while ago, I wanted to write a very simple freehand drawing program using a pen tablet as the main input device. The first version was written with Objective-C and it performed like any other programs I have seen: it was a bit jerky but acceptable on a G3 600 Mhz iBook.
The second version I made was written with a Cocoa-bridge for Ruby: no speed difference with the previous version, granted that it was a carbon copy of the Objective-C version, only with Ruby syntax.
When I wrote a plugin to access HID devices from Squeak, I made an example with code stripped from the previous support for pen tablets. This example is interesting because it keeps an history of the pressure put on the tip of the pen and does some computation to create a calligraphic-like effect, something missing in my previous attempts. And while a lot of messages are sent (Collection, Array, Morphic, plugin access), it is not slower than the Cocoa version, which is using primitives for handling the numbers.
- Doesn't Smalltalk have primitive strings, ints, bools, etc?
Yes and no. Squeak has primitives for objects requiring heavy computation, or more exactly, plugins called by methods wanting a bit more punch from the processor. The plugins can be internal or external to the VM.
On Wed, 10 Aug 2005 06:04:49 -0700, Dominique Dutoit dominiqued@versateladsl.be wrote:
His argument doesn't make sense. The performance gain resulting by the use of primitives instead of objets is marginal, simply because these primitives have to be manipulated by calling methods or functions and these operations are not cheap. Fast, maybe, but not dramatically faster.
Well, he's working for Microsoft now; he has a lot of apologizing to do for .NET.<S>
When I wrote a plugin to access HID devices from Squeak, I made an example with code stripped from the previous support for pen tablets. This example is interesting because it keeps an history of the pressure put on the tip of the pen and does some computation to create a calligraphic-like effect, something missing in my previous attempts. And while a lot of messages are sent (Collection, Array, Morphic, plugin access), it is not slower than the Cocoa version, which is using primitives for handling the numbers.
Like my daddy used to say, you never know where the bottlenecks are until you've tested.
- Doesn't Smalltalk have primitive strings, ints, bools, etc?
Yes and no. Squeak has primitives for objects requiring heavy computation, or more exactly, plugins called by methods wanting a bit more punch from the processor. The plugins can be internal or external to the VM.
That's what I thought. I knew the "can't use pure objects" thing was malarkey. I remember getting acceptable (but not great) results from VisualAge Smalltalk back in '94.
- Doesn't Smalltalk have primitive strings, ints, bools, etc?
Yes and no. Squeak has primitives for objects requiring heavy computation, or more exactly, plugins called by methods wanting a
bit
more punch from the processor. The plugins can be internal or
external
to the VM.
That's what I thought. I knew the "can't use pure objects" thing was malarkey. I remember getting acceptable (but not great) results from VisualAge Smalltalk back in '94.
Hang on, it seems that someone might be getting confused here. We need to differentiate between primitive types (like java has) and primitives- as-in-code that Smalltalk has.
Primitive types that are exposed to the programmer are not a good thing. Making there be two utterly separate ways of dealing with integer values, one as a variety of Object and the other as mere bits is, in my extremely strong opinion, bloody stupid. I've always maintained that if one is going to do objects (or any other paradigm) you should do it properly. Mixed styles (object FORTRAN, ghu help us) are an almost solid guarantee of disaster. An object system that allows pointers into memory locations is so stupid that...well I can't think of anything adequate to the comparison.
I'll also point out that Smalltalk primitive routines are mostly useful for work where there is no real benefit in doing it in Smalltalk (you could implement addition via message sends to extract bits, shift and merge but why do something the complicated way when an easy way is sensible) or where something simple and repetitive (scanning a string for a character) has to be done. There are also cases where a primitive is useful for engaging control of the virtual system (process management) or making an operation effectively atomic (signalling a sempahore). We also find primitives a convenient way of accessing much platform specific behaviour since it makes for a pretty solid encapsulation and abstraction. Note that we could build all the functionality of plugin primitives such as the FilePlugin set from Smalltalk code and an FFI analogue. I know this for certain since the old BrouHaHa/Archimedes/ActiveBook systems did exactly that and reliedupon good Smalltalk coding to encapsulate the functionality properly.
tim -- Tim Rowledge, tim@rowledge.org, http://www.rowledge.org/tim Strange OpCodes: LTT: Lose Timing Track
squeak-dev@lists.squeakfoundation.org
-
Blake -
Dominique Dutoit -
Tim Rowledge