[Stackless] Is Stackless single core by nature
bob at redivi.com
Mon Jul 13 04:13:33 CEST 2009
On Sun, Jul 12, 2009 at 5:12 PM, OvermindDL1<overminddl1 at gmail.com> wrote:
> On Sat, Jul 11, 2009 at 1:18 PM, Andrew Francis<andrewfr_ice at yahoo.com> wrote:
>> Message: 3
>> Date: Thu, 9 Jul 2009 22:09:57 -0700
>> From: Bob Ippolito <bob at redivi.com>
>> To: Henning Diedrich <hd at authentic-internet.de>
>> Cc: Richard Tew <richard.m.tew at gmail.com>, stackless at stackless.com
>> Subject: Re: [Stackless] Is Stackless single core by nature?
>> <6a36e7290907092209m5393ff4aw425e2a810e1a25fe at mail.gmail.com>
>> Content-Type: text/plain; charset=UTF-8
>>>I still use Python every day for lots of things, but all of our high
>>>concurrency/performance stuff has been written in Erlang since about
>>>the time of that thread, so we have a few years of experience with it.
>>>We build primarily a lot of the sorts of systems that you'd build in a
>>>game (Mochi is a platform for Flash gaming). If I were writing
>>>something massive and game-like I'd probably write the part that talks
>>>to clients and does bookkeeping in Erlang, and have it speak
>>>bidirectionally over JSON or something to pools of Python or
>>>think many people would enjoy coding lots of game logic in Erlang.
>> I just started reading the Joe Armstrong Erlang book and trying the examples....
>> You are probably right about the typical programmer not wanting to use Erlang for game logic. However I thought the main advantage of Erlang would be one could use its multi-processing support to help with compute bound tasks (i.e, parts of the game logic). That said, I don't see why Erlang should be vastly or intrinsically better performing than Stackless Python (with the right networking library) at low level networking and concurrency.
The reason why Erlang is better at networking is because networking is
built-in to the VM. Building socket multiplexing into Python is
difficult and slow (if you write it in Python). If you write it in C
then it's just difficult :)
>> Again, I am still learning Erlang. And I haven't looked much at multi-core processing (I am more interested hot swapping). But I am under the impression that Erlang dedicates a scheduler per core/thread and has a
>> dispatcher mechanism that makes this transparent to the processes. If this is the case, which couldn't Stackless Python adopt a similar approach, keeping in mind, fundamental differences between the languages and the message passing systems?
In theory Python can do everything that Erlang can. In practice it's
not practical to do some of the things that Erlang does in Python and
> As stated in another email, I did make a library on top of stackless
> that emulated Erlang quite well, including the transparent dispatching
> across a network.
> And Erlang's network stack could actually be a lot better, on last
> check (admittedly many years ago) it used TCP/IP, UDP could be better,
> however it is pluggable so you can put in your own networking
> interface for it. You can 'technically' hot-swap in python too, just
> with a bit more work. :)
The Erlang distribution protocol is TCP, but you can write UDP code on
your own. Either way it's still generally better than the status quo
in other languages. In practice most of what we do communicates with
other systems with standard protocols (e.g. HTTP), not the built-in
transparent distribution protocol.
Yes you can reload a module, but it's not the same experience in
Python in any way shape or form. The big difference is that *all* of
Erlang is written in such a way that reloading is easy, but *none* of
Python is. You'd have to reinvent the Python standard library to do
what Erlang does, even though the language and VM could technically
support that behavior.
More information about the Stackless