Hi Gloria,
As noted elsewhere I've been playing catch up a bit here...
On Saturday 11 April 2009 20:50:21 Gloria W wrote:
> Hi Michael,
>
> Attached are my PyCon 2009 slides for the Kamaelia toturial I gave.
This is really helpful. The actual video taken at the time is now up at
the pycon video website here:
Part one: (1 hour)
* http://pycon.blip.tv/file/2022798/
Part two: (18 minutes)
* http://pycon.blip.tv/file/2022853/
Incidentally, I love the fact that this tutorial is helping underprivileged
kids - that's fantastic :-D
Downside of the video though is that I think that this is missing about
an hour and quarter from the middle of your tutorial - that said it's really
really cool to see :-)
> The
> first hour was spent reviewing current concurrency solutions, from
> simple xargs bash, to subprocess, to the Python 2.6 processing module, a
> bit about Twisted, some code samples, etc.
I really liked this. Setting context like this is important, and actually
starting off with bash is great. In a way, as I think I've mentioned before,
kamaelia is kinda based on the idea "if only you could do more bash like
stuff with normal code" - largely because I use bash a lot as well :)
> The rest of the time was
> spent going through Kamaelia basics, showing examples of different
> component types, looking at the epydocs (I ran httpd on my laptop, and
> exposed the epydoc output generated from your code. I asked people to
> look at it while we reviewed code), and writing small examples on the
> fly. The slides do not properly represent the free-form coding and
> review we did. I hope the tutorial is somewhere online.
I liked what I saw - for maybe obvious reasons I'd never thought of
attaching PDB to various kamaelia systems - and I was rather suprised
at how clean it worked out - making me think that a PDB chassis would
be interesting to have. (Not sure how that'd work out but being able to
trace specific components would probably be quite interesting - especially
given you could potentially wrap components on the fly with an appropriate
console.).
> One person who attended is a scientist who does data modeling for cancer
> research. She wants to try to use Kamaelia to distribute this this, and
> I offered to help set her up if she can get scrubbed data to pass my
> way. I have CC'd her on this email. If she is able to get scrubbed
> data, I'd love to post it to the list and have us all think about how to
> help he effective distribute the computations and other data operations.
That would be great. That part of the discussion is missing from the video
(it jumps from the end of looking at the slides/presentation tool/graphline
to the end of looking at introspecting the dining philosophers example).
> At PyCon I also spoke to the game developers who wrote EVE, about
> Kamaelia vs. Stackless, and they gave me some charts comparing
> performance of the two tools, and said they chose Stackless because of
> the performance. I still like the Kamaelia interface and overall
> paradigm much better, and wanted to ask you about this. Is the
> performance problem predominantly in the scheduler, and under what
> circumstances would we see it?
Well, some benchmarking was recently done by Steve Wittber, who has been
working on a library called "fibra" for a while, since his library grew what he
calls "tubes" which are kinda equivalent to kamaelia linkages and stackless's
channels.
Without beating about the bush, he benchmarked Fibra, Kamaelia, Stackless
and plain old threads. The good news is all 3 of us beat plain old threads
hands down. The unsuprising news is that stackless was the hands down
winner - for reasons I'll come back to, and the "bad" news was that Fibra
was 10 times faster than Kamaelia... (according to this benchmark)
He's since removed the threaded line, which makes the graph look even worse,
but you can find that benchmark post here:
http://entitycrisis.blogspot.com/2009/03/benchmarking-stackless-kamaelia-and.html
And graphs here:
http://entitycrisis.blogspot.com/2009/03/concurrent-scaling-benchmarks.html
That's a really nasty benchmark to wake up to, but on the flip side gives you
something to shoot for, which means its also a good benchmark to wake up
to.
The issue though with the benchmark is that what it specifically measures is
the overhead of passing a message. Now, if you're sending lots of messages -
eg one message per mouse move event - then this will cause you pain.
If however you recognise that and aggregate your small messages into a single
bundle and code your code to deal with all outstanding messages (something
that is good practice anyway - unless you like memory leaks!), then this
problem becomes more of a benchmarking artefact, than one that is actually
indicative of problems in real world usage.
A concrete example where this showed up for example is in the whiteboard
code. When that was sending individual mouse move events to the canvas
drawing component it ran much slower than you'd like. When we aggregated
them, the entire system sped up.
Whilst this seems a trivial detail, when you factor in the whiteboard was
sending messages over the network to other connected whiteboards, changing
the processing behaviour to aggregate data also sped up the networked
behaviour in addition to local responsiveness.
Stepping beyond that, Simon's post has also spurred me on to work on seeing
if I can create a miniaxon - or something slightly newer from scratch - which
I have done, and that's now able to run over 20-30 times faster on this
particular benchmark.
I'm not ready to merge it onto mainline Kamaelia yet, but the code for it is
currently sitting in a scratch code.google project here:
http://kamaelian.googlecode.com/svn/sketches/Axon
The figures I've got for this Axon2 implementation at present are pretty
neat:
python -OO /usr/lib/python2.5/timeit.py -s "import Hackysacker"
"Hackysacker.runit(1000,10000,0)"
10 loops, best of 3: 240 msec per loop
python -OO /usr/lib/python2.5/timeit.py -s "import Hackysacker"
"Hackysacker.runit(10000,1000,0)"
10 loops, best of 3: 168 msec per loop
python -OO /usr/lib/python2.5/timeit.py -s "import Hackysacker"
"Hackysacker.runit(10000,10000,0)
"
10 loops, best of 3: 373 msec per loop
python -OO /usr/lib/python2.5/timeit.py -s "import Hackysacker"
"Hackysacker.runit(100000,100000,
0)"
10 loops, best of 3: 4.63 sec per loop
What this says is "kick a hacky sack around between X hackysackers, and do
that Y times". ie X is the number of concurrent objects in the system, and Y
is the number of times a message is passed.
What should be visible here is that the runtime of this scheduler is now
proportional to the amount of operations to be executed, and not proportional
to the number of concurrent objects in the system - ie precisely what you'd
want.
The same figures for Fibra on my machine are:
python -OO /usr/lib/python2.5/timeit.py -s "import hackysack"
"hackysack.runit(1000,10000,0)"
10 loops, best of 3: 71.2 msec per loop
python -OO /usr/lib/python2.5/timeit.py -s "import hackysack"
"hackysack.runit(10000,1000,0)"
10 loops, best of 3: 604 msec per loop
python -OO /usr/lib/python2.5/timeit.py -s "import hackysack"
"hackysack.runit(10000,10000,0)"
10 loops, best of 3: 843 msec per loop
python -OO /usr/lib/python2.5/timeit.py -s "import hackysack"
"hackysack.runit(100000,100000,0)"
10 loops, best of 3: 15 sec per loop
Putting these figures side by side gives this:
--------------------------------------
X, Y, Axon2, Fibra
1000,10000 240 msec 71.2 msec
10000,1000 168 msec 604 msec
10000,10000 373 msec 843 msec
100000,100000 4.63 sec 15 sec
(I don't have stackless installed, but stackless was about 7x faster than
fibra on Simon's machine, and Axon2 is generally quicker byt about 2-3
times faster.
In fairness I've shared these figures with Simon first and he's posted
this since:
http://entitycrisis.blogspot.com/2009/04/141-am.html
* "Well, I think Fibra is 50% faster now."
The neat thing is this means we both now have comparable speed to each
other, and have both gained speed ups.
Not only that this new implementation of Axon (Axon2) is now using the STM
code inside the core for picking up which scheduler to use etc, and safely
managing that.
We're contemplating at the moment how to make the two codebases work
together better. Friendly competition is great, but friendly co-operation is
even better :)
However, stackless will still with a narrowing margin. The reason is really
simple - stackless is 2 things - a modification of the python implementation
with regard to the way the stack is handled. Armin Rigo gave a great
presentation about this a few years back if you can find it on the web.
However, it also enables the creation of tasklets and channels, which
are effectively optimised in C.
At present I'm happy with a 20-30 fold overall speedup though - especially
given the new scheduler actually enables a far faster implementation of the
benchmark which is faster than stackless but is kinda unfair in the way the
hackysackers work :)
However, as noted, this particular benchmark is very much an abberation of
the way Kamaelia generally operates. Whilst we do have a lot of message
passing, it's not generall excessive, and often network or device overheads
tend to dominate.
> Also, I've been invited to speak at Open Web in Vancouver, which is
> traditionally a PHP gathering. They are trying to make it more diverse,
> and I will most likely be one of the very few/first Python speakers
> there. But I would still like to go, and I think I'd like to demonstrate
> an example of Kamaelia speaking via socket I/O to a PHP application. The
> reason for this is entirely selfish. I want to propose a different way
> of writing plugins for Drupal, Pligg, and other PHP web frameworks and
> wikis. I am proposing that we write plugins in Python, based on HTTP or
> other protocols, to standalone services, so they can be used by PHP
> frameworks, or any framework for that matter.
>
> My inspiration for this is my recent contract work with Drupal and
> Wordpress. I am asked by friends to help them get their PHP framework
> sites working correctly, which is not hard in these frameworks. But
> maintenance, upgrades, and advanced plugins which modify the core
> database schema, cause all sorts of havoc in these frameworks. PHP is
> already lacking in some serious ways, but the framework code written in
> PHP seems to cause even more problems. The only way I can think of
> migrating existing users away from these impossible to maintain
> frameworks is to provide network/service pluggable components for them.
> For example, if the entire database back end could be replaced with a
> Python ReST based HTTP CRUD calls (GET/POST/PUT/DELETE) to the MySQL db,
> it would decouple the front end PHP services from the back end
> authentication and DB model. This alone would open the possibilities of
> serving plugins written in any language, as supplemental tools to Drupal.
>
> This monolithic PHP model just isn't sustainable, and may end-users
> don't realize it until (1) they're in the thick of it and need to
> upgrade a year later, or (2) they try to do something very advanced in
> this framework. I think Python and Kamaelia can get us out of this mess,
> and I want to put together a simple example for the Open Web conference
> to demonstrate this.
Sounds interesting - probably worth having a seperate thread for though I
suspect.
> That being said, I'm looking at the HTTP server request header code, and
> I'm going to write a CRUD component for it, detecting
> GET/POST/PUT/DELETE from the request header. I am tempted to write it as
> a graphline, accepting the four different inputs, issuing a response
> header and body output. Does this sound correct to you?
It sounds reasonable, but it's a little late here, and I've seen there's a
follow
up and will play further catchup tomorrow :-)
> Thanks again, and please excuse the rambling.
You're welcome, and many thanks for giving the tutorial. I found it
extremely interesting to listen to and have made a bunch of notes
regarding how to improve the project docs, splitting things up, a clearer
idea about the sorts of examples that would be useful etc.
One thing I do find amusing was the repeated "criticism" (and I use the term
loosely!), that Kamaelia can be hard because it appears to be too simple to
work. My immediate thought regarding that was "well, why would I create
a system that makes my life harder?", and as you say it's a good problem
to have.
However, the more I thought about it and listened the more I realised also
that this is actually a crucial problem that the examples need to overcome.
As a result, I've decided that at some point soon, I'll put together a
relatively large example regarding a complex useful application which was
put together in a day (about 8 hours really), but exercises a large
collection of components, preferably from the ground up.
Specifically I'm actually thinking of this application:
* http://www.kamaelia.org/SpeakAndWrite
... which is designed to assist a small child to learn to read and write.
(I had a specific small child in mind - who loves it incidentally. Writing
words on a tablet PC, and getting yes/no & what you wrote said back to
you is _really_ fun if you're 5 :)
As you can see from the diagram at the bottom of the page it's a relatively
complex application, and describing the design/build process I suspect
would be helpful - since as you can imagine I didn't just throw it all
together as one lump and hope it just worked! :)
Regards,
Michael.
--
http://yeoldeclue.com/blog
http://twitter.com/kamaelian
http://www.kamaelia.org/Home
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"kamaelia" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to
[email protected]
For more options, visit this group at
http://groups.google.com/group/kamaelia?hl=en
-~----------~----~----~----~------~----~------~--~---
