[BBC:OSS] On Kamaelia, Concurrency, Networking, Foundation, Components, Extensions, Messaging, Simplicity, BSD, Python, and My Recent LGPL Epiphany

by M. David Peterson

[NOTE: There's a reason for choosing to attach such a lengthy title, so please forgive me for blowing up your feed reader of choice if that feed reader of choice doesn't handle titles that better resemble short stories all that well. ;)]

So instead of attempting to describe the experience I just had, instead, with permission from Sylvain, I am simply going to copy/paste the conversation that just took place that has brought into a whole new light what the Lesser General Public License is all about, and why I think that it flat out ROCKS! (thanks for helping to bring this into a greater understanding for me, Sylvain!)

Firstly, and understanding of what Kamaelia is all about,

A framework providing the nuts and bolts for building components. A library of components built using that framework. Components are implemented at the lowest level as python generators, and communicate by message passing. Components are composed into systems in a manner similar to Unix pipelines, but with some twists that are relevent to modern computer systems rather than just file-like systems.


Secondly, the conversation that lead to my recent epiphany in regards to the greatness (or at least potential greatness) of the LGPL.

7 Comments

Marcel Weiher
2006-10-05 13:33:11
Not sure about Gordon Moore, but Intel does and is promoting the fact heavily.  They phrase it slightly differently, but the actual meaning is the same:  no more free (Hz) upgrades!
M. David Peterson
2006-10-05 14:51:34
@Marcel,


Is this in regards to the actual physical constraints to the medium? I assume yes, and if so, then yeah, I guess I was aware of this. However, from all reports that I have seen, the knowledge of the physical constraints has promoted the development of other medium and methods, and if not mistaken, the result is that of Moore's Law moving forward untouched.


But then again, I have nothing but news reports to base this analysis upon, so for all I know I'm completely in the dark ages of thought in this regard.


Anybody care to help clue me in?

Marcel Weiher
2006-10-05 23:38:55
David,


Moore's law is "moving forward untouched" in terms of number shrinking processes and the resulting increase in numbers of transistors on a chip. However, as tbe original quote says, it has 'ended' in terms of the increases in raw speed (in Hz) of those transistors. So what is happening is that any extra power is coming purely from the extra transistors, not from those transistors being faster as used to be the case. We've also pretty much hit the limit for making a single instruction stream go faster by piling more transistors into executing it.


The upshot of this is that our single cores are not getting any faster, we are just getting more cores on the chip. However, this obviously also means that our single-threaded programs will not be automatically getting faster with the next generation of chip, which always used to be the case.


http://www.theregister.co.uk/2006/09/27/intel_terafied/
http://www.theregister.co.uk/2006/08/22/ramp_mit_fix
http://ramp.eecs.berkeley.edu/about.php



Marcel Weiher
2006-10-05 23:38:55
David,


Moore's law is "moving forward untouched" in terms of number shrinking processes and the resulting increase in numbers of transistors on a chip.  However, as tbe original quote says, it has 'ended' in terms of the increases in raw speed (in Hz) of those transistors.  So what is happening is that any extra power is coming purely from the extra transistors, not from those transistors being faster as used to be the case.  We've also pretty much hit the limit for making a single instruction stream go faster by piling more transistors into executing it.


The upshot of this is that our single cores are not getting any faster, we are just getting more cores on the chip.  However, this obviously also means that our single-threaded programs will not be automatically getting faster with the next generation of chip, which always used to be the case.


http://www.theregister.co.uk/2006/09/27/intel_terafied/
http://www.theregister.co.uk/2006/08/22/ramp_mit_fix
http://ramp.eecs.berkeley.edu/about.php



M. David Peterson
2006-10-05 23:54:13
Ahhh... Okay, cool. I see what you mean now. Thanks for the explanation and the links! Am checking them out now...


Thanks Marcel!

Michael Sparks
2006-10-06 13:43:04
My comment there was heavily qualified there - I specifically mentioned MHz there because people abused Moore's law for some time to mean every 18 months CPU speed as measured in MHz doubles. This held true for a long while, but topped out a few years back. http://kamaelia.sourceforge.net/Challenges/?tab=8 goes into this in more detail, and a nice article that ended up in Dr Dobb's was published last year, but the online version can be found here: http://www.gotw.ca/publications/concurrency-ddj.htm


If you look at the graph of CPU speed vs years, it's clear.


It's why Sun, Intel, AMD, and notably IBM & Sony & co with the CELL are all going multi-core. Why? Whilst the revised formulation - that speed measured in MHz doubles every 18 months, the original formulation (transistor count doubling every 18 months) looks set to continue for a while yet. (At which point I suspect we'll start doubling layers, or some new funky thing :-)


I've always been interested in parallelism, since in many respects you can end up with more natural systems (since the real world is massively parallel!) if you have the right framework (Hence Kamaelia's core approach). However given that the future from hereon appears to be multicore, having tools that make this natural (and easier for the average developer) becomes more and more important. We think we're getting somewhere :)


The main system might be python, but we have a proof of concept in CVS for C++, and ruby should be a trivial conversion.


Finally, I'm glad you found the licensing page clear :-)


My *personal* preference is for the BSD license, but the MPL/GPL/LGPL gives maximum protections for users and interoperability with other libraries, whilst protecting the base code from being closed.

M. David Peterson
2006-10-06 14:26:06
Hi Michael,


Thanks for the follow-up!


I really appreciate you taking the time to provider deeper insite. This makes a TON of sense now. And I agree with you whole heartedly in regards to parallelism.


I'm going to spend some time and research the links you provided, and then follow-up accordingly with anything that seems would provide benefit to those who might read the follow-up. It seems pretty obvious to me that you guys have something pretty spectacular going on here, and I most certainly need to spend some time and really find out what this is all about.


Thanks again for your thoughts! VERY much appreciated!