Domain: stackless.com
Stories and comments across the archive that link to stackless.com.
Comments · 29
-
EVE Online runs Stackless Python
They are using Python 2.7:
http://community.eveonline.com/news/dev-blogs/stackless-python-2.7/Great discussion of pros and cons of Stackless:
http://stackoverflow.com/questions/588958/what-are-the-drawbacks-of-stackless-pythonHere's an interesting page with a few nuggets of info. In the discussion section, some people claim that the game used to crash with space battles as small as 100 ships. Clearly the game has been improved since then.
http://highscalability.com/eve-online-architectureIf you are really interested, here's a talk from PyCon 2009 that goes into some detail on what they do with Stackless. They had some problems that only showed up on the crazy load of a real system, so they had to go live with some code to test it!
http://blip.tv/pycon-us-videos-2009-2010-2011/stackless-python-in-eve-pt-2-1959372P.S. A couple of good trailers:
http://www.youtube.com/watch?v=HrrVDV_NsNo
This one bored me at first but then got much better as the music got going.
http://www.youtube.com/watch?v=euMjOHgb9A8 -
Re:Python
I second Python: just type in the pseudocode you'd write on a piece of paper, and there is a good chance that it will work just like that in Python.
2D gaming using SDL (and OpenGL 3D, but you have to do the hard work yourself): Pygame
3D drawing/animation/gaming: Blender 3D
(I started by gaming, because that's a fun way to learn a language quickly)Web: Django
Co-routines: Stackless Python
Maths: NumPy and SciPy
Networking: TwistedThat just scratches the outside of it, but have a look at the above to get an idea of the language.
And Python's documentation is quite good: brief, but everything you need is there - you just need less than you would expect at first. Here are some good tutorials:
Official Python Tutorial
Dive into Python
How to think like a computer scientist?Hmmm, looks like I've turned into a Python fanboi... Be careful if you try Python, you could fall for it.
-
Re:Is the GIL removed from the interpreter
ha, at least a nice reply. You are not a butt-hurt loud mouth like one of the above poster. Thank yuo
Oh, you wanted an answer. Honestly, it never crossed my mind that you were doing anything but trolling about a difficult problem lots of smart folks are dilligently working on that have been discussed for years.
My apologies, I thought this was yet another insouciant probe along the lines of "Oh, is Perl object-orented?" or "Gosh, do people use OpenBSD?". Sorry to prompt that wounded tone from you there.
Oh, and for reference, your (indirect) response requires "neckbeard" or a veiled reference to the autism spectrum to be canon. Just as mine requires a "My fault for feeding the trolls"
-
Re:Is the GIL removed from the interpreter
ha, at least a nice reply. You are not a butt-hurt loud mouth like one of the above poster. Thank yuo
Oh, you wanted an answer. Honestly, it never crossed my mind that you were doing anything but trolling about a difficult problem lots of smart folks are dilligently working on that have been discussed for years.
My apologies, I thought this was yet another insouciant probe along the lines of "Oh, is Perl object-orented?" or "Gosh, do people use OpenBSD?". Sorry to prompt that wounded tone from you there.
Oh, and for reference, your (indirect) response requires "neckbeard" or a veiled reference to the autism spectrum to be canon. Just as mine requires a "My fault for feeding the trolls"
-
Re:Sad
EVE Online, which has probably done more in terms of scaling/balancing technology than any other commercial MMO, uses a *ton* of Python server-side. One world for all players, with the ability to handle massive battles. A kludge it is not.
-
Used to be based on Stackless Python
http://www.stackless.com/wiki/Applications
Don't know if that is still a core part of their technology; certainly makes sense, as lots of high-performance applications avoid creating lots of threads in order to scale--especially when there's IO involved. Thus, Stackless Python also takes the same approach to logical concurrency as Erlang.
-
Consider Stackless Python
I will usually bend over backward to use Python just because I find it very easy to write self documenting code. I have to maintain my own code and find it easy to work with code that I wrote years ago. In fact, my cow-irkers (who don't use Python at all) can easily follow what I've done. The language is sane enough that I can get help from C++ people if I get into a thinko. (a thinko is like a typo but way way worse) It also means that I can still help people with their C and C++ problems even though I have hardly written a line in those languages in the last couple of years.
If I had to write something concurrent, I would try Stackless Python. I looked at the mailing list archive and the project is active (so you can get help) and there are major projects that use it. It looks like it is worth checking out. (Obviously, I haven't used it yet)
-
Re:Not a leak
A lot of the server code is written in Python as well. They use a Python variant called Stackless Python.
-
Re:'ivory tower academics...' oh please
The ONLY people who think Java is in decline in favor of Ruby or Python are the ivory tower academics who aren't actually developing large scale enterprise applications.
Hmm... heard of a game called 'EVE Online'? Their server -- which serves provides an entire 3D universe to over 33000 users simultaneously (without instancing as in WoW or Guild Wars) -- has the game logic implemented almost entirely in Stackless Python, with shared state across tens of thousands of CPUs. Or what about that small and insignificant search engine, Google? They seem to rely quite heavily on Python too.
Oh, I'm sorry. Perhaps those aren't "large scale" enough for you. What sort of "large scale enterprise applications" did you have in mind?
-
Re:Python is SLOW
Only if you don't know much about python, try looking at stackless python. eve online, the mmorpg with the current world record for concurrent players was written almost entirely in python.
-
Re:Us coders are delaying the Singularity!
Incidentally, what do you think of microthreads, ie. found in Stackless Python and possibly concurrent languages like Erlang?
Quote: "It allows programmers to reap the benefits of thread-based programming without the performance and complexity problems associated with conventional threads" As I understand it, microthreads are more lightweight than threads and far more manageable. -
Re:23k a record?
Is stackless still moving on its own? Looked kinda lame (as in sans legs) last time I gave it a poke.
The thing I dont understand is why stackless... I guess they just mean no C stack really. It seems like many programming languages (Boo for dotnet) can do continuations/generators/&all without going stackless. From the Continuations and Stackless Python doc I count find any compelling "stackless" features that really stuck out. We've had these things in C for a while now, they're called function pointers?
I too was wondering about how Eve was doing w/ stackless. I had a month straight were I flooded CAS (a Gallente noob corp) with chatter on the what Eve was running under & large scale architecting.
Myren -
Re:Python
From the desription it seems like Python stackless.
-
Re:just a nitpick to counter...Well, Stackless itself implements "tasklets" (lightweight threads) using a round-robin scheduler (which does not schedule tasks that are blocked on channel communications) - see here for more. This approach was apparently heavily influenced by things like CSP and occam.
I have to admit that I'm not clear on what the original article means when they talk about using non-preemptive multithreading (do they mean somehow overriding the Stackless tasklet scheduler?). They seem to be worried about the need for locks on shared-state variables. However, the correct approach to building a Stackless-based system would probably be to follow the CSP paradigm of avoiding shared-state completely - such systems are lock-free and can be completely deterministic. But perhaps I am completely misinterpreting what they are trying to get at.
-
Re:Python is nice but consider LUA for game script
The point of using Stackless Python (as opposed to ordinary Python) is that it provides a particularly good system for handling multiple threads and communcation for threads via tasklets and channels. If your game engine works by creating actors as threads then using a scripting language that has a simple to use, efficient, and platform independent threading model is likely of great importance, and Stackless Python offers that.
If you're generally interested in better threading models, and being able to think and reason about threads and their interactions more easily then you really ought to check out CSP. Multithreading is actually easy if you do it right - it's just that most languages don't.
Jedidiah. -
Re:Python is nice but consider LUA for game script
The point of using Stackless Python (as opposed to ordinary Python) is that it provides a particularly good system for handling multiple threads and communcation for threads via tasklets and channels. If your game engine works by creating actors as threads then using a scripting language that has a simple to use, efficient, and platform independent threading model is likely of great importance, and Stackless Python offers that.
If you're generally interested in better threading models, and being able to think and reason about threads and their interactions more easily then you really ought to check out CSP. Multithreading is actually easy if you do it right - it's just that most languages don't.
Jedidiah. -
Re:Python is nice but consider LUA for game script
The point of using Stackless Python (as opposed to ordinary Python) is that it provides a particularly good system for handling multiple threads and communcation for threads via tasklets and channels. If your game engine works by creating actors as threads then using a scripting language that has a simple to use, efficient, and platform independent threading model is likely of great importance, and Stackless Python offers that.
If you're generally interested in better threading models, and being able to think and reason about threads and their interactions more easily then you really ought to check out CSP. Multithreading is actually easy if you do it right - it's just that most languages don't.
Jedidiah. -
Re:"blessing" doesn't matter
It's interesting to note that there are several re-implementation of Python, at various levels of maturity (Jython,stackless Python,PyPy, and IronPython)
-
Re:and how's that working out?
Hey, don't forget Stackless Python, a fork of CPython that removes all dependencies on the C stack (with some very cool results). Too bad that development seems to have stalled, though.
-
stackless..
this makes me wonder what the effect would be on something like stackless python?
the whole state pickling concept is pretty cool, and kind of throws threads all over.. -
Re:parrot?
-
Re:Circular Acronymns - GWU stands for...
Its only recursive if your language has a call stack. If otoh, your langauge is based on graphs then it is indeed a circular (or cyclic) acronym.
-
Lisp bad, python good?
I'd like to see a standardized lisp that I can write and read as quickly and Python.
It's been tried - see Dylan. As near as I can tell, Dylan didn't take off because:
The Lisp people saw no major advantages to it other than the syntax, and they'd already gotten past that barrier
The non-Lisp people apparently didn't understand that it really was better than C++/Java
Lisp does need a better ... community ...
Like the one growing here?
and one standard open source implementation.
Now I'm really confused. Multiple implementations with a common specification hurt Lisp, but Jython and stackless python are not drawbacks for Python? -
Iorn Port is also OSS friendly.
They have funded the continued development of Python with continuations, called Stackless, by hiring the original author part-time.
-
Re:Good times.
-
Re:Scheme -vs- Common LispAs I've said elsewhere in this discussion, Python is basically Lisp without macros. But of course there are other major differences, as you point out. Python is certainly not a dialect of Lisp, as could be said for ScriptX, Dylan, Sk8, Scheme, etc. But it is certainly deeply inspired and enlightened by Lisp, in a way that PHP, Perl, Java and C++ just aren't. Put bluntly: the designers of those "reactionary" languages didn't understand or appreciate or learn from or react to Lisp, while the designers of Python did.
The concept of putting a macro facility into Perl is revolting. It would be much more pathetic that the C preprocessor. (Anyone who thinks the C preprocessor is an acceptable macro facility should stop programmimg immediately before they do any more damage, and go back to CS101 and read Paul Graham's On Lisp.)
Macros are the one most important thing from Lisp that Python is missing. But Python can certainly manipulate code at runtime. The fact that Python code is not literally structured data is alleviated by the fact that the parser and compiler are available as part of the Python runtime, and you can easily manipulate and evaluate strings in Python. Certainly that's nowhere near as useful as Lisp macros, but at least you're not up a creek without a paddle as you would be with Java or C++. Yes I know you can link the Java compiler into Java, or call the C++ compiler as a sub-process from C++, but that's a totally impractical kludge, not a language-level macro facility.
I'm glad that lambdas have been fixed in Python since they had problems in the earlier days, but I don't know what you mean by "severly limited form". If you ask me, it's Java's inner classes that are severly limited and extremely clumsy (and they also weaken the security system).
Continuations are not as useful in every-day programming as most CS grad students with no experience in the real world would have you believe. Just what problem are you actually trying to solve, that you can't solve with threads, exceptions, generators, or better programming techniques?
As a matter of fact, the Python architecture was easily modified to support continuations (called "Stackless Python"). The main purpose for implementing continuations in the interpreter was to get the interpreter's state disentangled from the C stack, which makes it much easier to embed the Python interpreter in other applications that can't relinquish control of the program counter. For example, with stackless python you can call into the Python interpreter every time slice from a timer callback, and Python can block on network input or whatever, and still return to the caller, so the application doesn't have block inside of Python during its timer callback. That makes Python easier to integrate (and therefore more practical), because it removes constraints on how you can call into the interpreter (because the call can return if the interpreter needs to block). It also enables Python to support tail recursion. But hardly anyone uses continuations in their full glory and splendor, for normal everyday programming.
Also, Python now has "generators" (aka "weightless threads" or "coroutines"), which are quite useful for some of the other common uses to which people put continuations, but they are much easier to use and understand.
CLOS is great, but I don't miss it most of the time, because I'm happy with the current object system in Python. Python's object system is quite simple, practical and flexible, and can be easily extended in its own way. ScriptX's object system was a lot like CLOS, as was Dylan's. But again, you usually don't need the enormously powerful generality of CLOS, and it comes at a cost in speed, space and complexity, that most people aren't willing to pay.
I previously worked on ScriptX at Kaleida, and have written lots of ScriptX code. In some ways i
-
micro-/green threads in Python
Are there any VMs currently, for Java, Python or some other language, that can execute each thread one VM instruction at a time?
There are a couple of different options for doing this in Python:
One is to use Christian Tismer's `Stackless Python'--the `uthread' module, if I recall correctly, allows the Python programmer to step op-by-op.
The other method is to use Python 2.3's generators (via the `yield' statement) (via the `from __future__ import generators' statement in Python 2.2).
There's an IBM-developerWorks article on the latter technique. -
microthreads, stackless python
Is there any chance that stackless and microthreads might be integrated into the main python distribution?
- -
Stackless, microthreads
Yup, this port uses Stackless Python to the best of my knowledge (but you could get a more certain answer by going straight to Jeff Collins). Unfortunately they haven't included the continuation module or the microthread module. Chris Tismer has plans eventually to move a lot of the microthread machinery to C, and maybe at that point, it will find its way into the Palm port.