On Mar 1, 2012, at 8:38 AM, Guido Stepken wrote:

Sooner or later Pharo Smalltalkers will have to read into this paper:

http://www.lemis.com/grog/SMPng/USENIX/paper.ascii

Why? Pharo is a OS on top of another OS. The same principles apply here. Without considering these principles or algorithms (no more or as little semaphores as possible, replaced by wait_queues with adjustable priorities), Pharo will suffer those problems.

tnx 4 understanding, Guido Stepken

I could enumerate the ways you are off target in this context, but that would be wasting my time. thx 4 the laugh, Henry p.s. The paper itself is indeed quite good and worth reading :D

On Mar 1, 2012, at 10:03 AM, Guido Stepken wrote:

As long as GC, recompile, (see blocked UI during updates), ffi database drivers completely block Smalltalk execution or do not access external databases smoothly in parallel (also see async I/O, MP) i see only one laugh here - that's indeed you!

Have fun!

Guido Stepken

Aaah, the good ol' "If you can't hit with a rifle, switch to a shotgun" approach, haven't seen that in a while. Have fun! Henry

On 1 March 2012 11:41, Guido Stepken <gstepken@googlemail.com> wrote:

No. I just tried to teach Pharo to do several things in parallel: Seaching stings in several 1 GB files, opening and reading several databases at once in parallel, handing results over sockets to several clients. Try it yourself. Whatever you do with Pharo, you won't get any smooth IO, even if you use COGMT. Smalltalk code is not yet adapted, it seems. Same with eventhandlers. Try editing while copying and filtering a file in background. Happy waiting!

I had much success with Smalltalk MT, LUAJit, medium success with node.js ...

Don't get me wrong, but business develops to realtime filtering of concurrent information streams coming from different sources (twitter, facebook, mail, irc, p2p, databases, homepages, rss, XML, Soap ) and that intelligently presented in realtime on my Desktop.

We did intensive testing of several interpreters.

I personally really prefer Pharo, because it offers a outstanding, very complex construction kit for doing marvellous things, beginning from "abstract connectors" that combine filters with editors with gui, web, streams, databases, over to very good IDE up to certain (decreasing) compatibility to squeak and its mass of "toy apps".

I think, that, when a deeper understanding of how to acheive parallelism, realtime, concurrency comes to Smalltalk programmers (not just starting coroutines and hoping, the kernel gets it right, claiming everything is multithreaded), Pharo very soon could be business ready! :-)

And it is good to understand, *why* Wikipedia now uses LUAJit (a highly dynamic language, like Smalltalk), Blizzard (World of Warcraft), Steam (realtime control of complex game worlds) use LUAJit, EVE uses Stackless Python with continuations. Smalltalk would be very well suited, but its implementations are missing important features, realtime qualities, real concurrency, not just one at the surface, claiming apps being "multithreaded".

Seaside, e.g. immediately drops to under 1/second, at even 10 simulaneous clients, when data comes from SQL or even OODB, means case of cache misses. Pharo becomes unresponsive.

For me, good architectures can be recognized, when they smoothly go on serving, even at 50 times overload, still keeping small memory footprint. Compare to Linux at high loads (sshd, telnetd not answering) and FreeBSD (you can still login, even if 50.000 clients connected).

You might still laugh at me... i don't.

Finally something worth replying. Back in 2007 i did a HydraVM, which were capable of running multiple interpreters in parallel on separate native threads. It was a proof-of-concept. Showing that things are doable. What is hard to do is to make everything in image side to be instantly aware of new feature and make use of it. You need to develop tools around it, like inter-image communication, remote debugging, and last but not least figuring out how you can spawn a dozens of micro-images which are not full-blown multimegabyte image as we usually having, but contain only some small algorithm, which will be running on given thread. There's also a RoarVM, which attacking the same problem but at slightly different angle than HydraVM. So, indeed, there's nothing to laugh at. The sad thing is that you have to rewrite a lot in kernel to use new architecture in vm, and there's no way back: no way how it can be backwards compatible. In case if you insist of backward compatibility, the adoption will never be as good as design based on new concepts. It also requires a lot of study, in multiple areas as well as evaluating different approaches. Another sad thing is that you just trolling, thinking that only you know how to do things right and treating people here either blind or stupid idiots.

Have fun, Guido Stepken

Am 01.03.2012 10:29 schrieb "Henrik Johansen" <henrik.s.johansen@veloxit.no>:

...

On Mar 1, 2012, at 10:03 AM, Guido Stepken wrote:

As long as GC, recompile, (see blocked UI during updates), ffi database drivers completely block Smalltalk execution or do not access external databases smoothly in parallel (also see async I/O, MP) i see only one laugh here - that's indeed you!

Have fun!

Guido Stepken

Aaah, the good ol' "If you can't hit with a rifle, switch to a shotgun" approach, haven't seen that in a while.

Have fun! Henry

-- Best regards, Igor Stasenko.