[Pharo-project] leaking semaphores

Igor Stasenko siguctua at gmail.com
Thu Mar 1 06:05:30 EST 2012


On 1 March 2012 11:41, Guido Stepken <gstepken at 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 at 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.




More information about the Pharo-dev mailing list