4 ms·

There's a big difference between Smalltalk implementations being relatively slow and Smalltalk being intrinsically slow. If Smalltalk VMs had the same resource

There's a big difference between Smalltalk implementations being relatively slow and Smalltalk being intrinsically slow. If Smalltalk VMs had the same resources thrown at them as other VMs/compilers/etc. they could be more competitive speed-wise. Noting, of course, that Smalltalk systems can be plenty fast-enough. Smalltalk-as-glue is also perfectly reasonable, interfacing with multiple back-end systems, controlling business logic, etc.

nickm12 9y ago
What I'm saying is that the "lots of little objects" model of Smalltalk goes against the grain of modern machines and how they access memory. I'm not sure what it takes for something to be _intrinsically slow_ but it appears physics is against us. If we could build machines that had fast uniform access to memory we probably would have.
- fulafel 9y ago
  I think the current mindset of taking data layout as fixed is a big illusion that we just haven't broken out of. Optimizers should make data layout optimizations. For example, a JIT could do AoS->SoA optimizations on an array containing multi-field objects and vectorize loops that manipulate a small subset of the fields. Or replace object representations with limited, live data-specialized versions that consume a fraction of the space. There may be some changes to language semantics needed of course, but doesn't preclude Smalltalky languages. Another property of the current software/hardware world is that the vast majority of programs don't care about performance at this level. There is a vast size difference between the oceans of production code in the world, and the amount of "hot" code that people pay money to make faster. (And the levels of "make faster" are usually more low hanging fruit than switch of programming language)
- abecedarius 9y ago
  Consider Concurrent Smalltalk on the http://cva.stanford.edu/projects/j-machine/ http://cva.stanford.edu/projects/j-machine/ -- a processor-in-memory massively parallel architecture. This seems like a better match to physics than a Von Neumann architecture with a few fast processors separated from a giant memory, because physics is local. I suspect systems like the J-machine haven't gotten very far for historical path-dependent reasons more than intrinsic ones. It's true though that a parallel object language like Concurrent Smalltalk isn't the historical Smalltalk we usually mean.

nickm12 9y ago

What I'm saying is that the "lots of little objects" model of Smalltalk goes against the grain of modern machines and how they access memory. I'm not sure what it takes for something to be _intrinsically slow_ but it appears physics is against us. If we could build machines that had fast uniform access to memory we probably would have.

fulafel 9y ago
I think the current mindset of taking data layout as fixed is a big illusion that we just haven't broken out of. Optimizers should make data layout optimizations. For example, a JIT could do AoS->SoA optimizations on an array containing multi-field objects and vectorize loops that manipulate a small subset of the fields. Or replace object representations with limited, live data-specialized versions that consume a fraction of the space. There may be some changes to language semantics needed of course, but doesn't preclude Smalltalky languages. Another property of the current software/hardware world is that the vast majority of programs don't care about performance at this level. There is a vast size difference between the oceans of production code in the world, and the amount of "hot" code that people pay money to make faster. (And the levels of "make faster" are usually more low hanging fruit than switch of programming language)
abecedarius 9y ago
Consider Concurrent Smalltalk on the http://cva.stanford.edu/projects/j-machine/ http://cva.stanford.edu/projects/j-machine/ -- a processor-in-memory massively parallel architecture. This seems like a better match to physics than a Von Neumann architecture with a few fast processors separated from a giant memory, because physics is local. I suspect systems like the J-machine haven't gotten very far for historical path-dependent reasons more than intrinsic ones. It's true though that a parallel object language like Concurrent Smalltalk isn't the historical Smalltalk we usually mean.