Marlabs Blog

An important topic related to both Ruby & Python is the Global Interpreter Lock (GIL). Because of GIL, pure Ruby/Python languages can use only one CPU (1 core) regardless of the available number of CPUS/Cores.

But GIL is a non-issue in at least three ways:

1> Common automatically eliminates GIL Language Runtime /Java Virtual Machine (CLR/JVM)
IronRuby/IronPython/JRuby/Jython/MacRuby have “no GIL” issues, because they map corresponding “green threads” to CLR threads or JVM threads or native threads.

2> Asynchronous Programming Approach

Even if using pure Ruby/Python, using a library like Twisted (for Python) or EventMachine (for Ruby) eliminates GIL/concurrency issues.

http://www.artima.com/weblogs/viewpost.jsp?thread=230001

http://www.igvita.com/2008/05/27/ruby-eventmachine-the-speed-demon/

3> Using Separate Libraries

http://pypi.python.org/pypi/processing

http://www.parallelpython.com/

http://github.com/grosser/parallel

When I first saw the .NET MicroFramework a while back, I dismissed it thinking it’s yet another Microsoft ‘marketing gimmick’ for expanded Windows CE packaging! While I was appreciative of the NET CompactFramework, for me, it still ranked behind either Linux or J2ME.

But all this changed when a colleague sent across a note to take a second look at the .NET “MicroFramework” revision introduced in 2007.
http://www.tinyclr.com/

Boy was I wrong! The .NET MicroFramework is a complete, miniature .NET stack that can run in an embedded environment with no Real-Time Operating System (RTOS) support and with just 300KB of memory! With such capabilities, NET MicroFramework can seriously impact BusyBox (Linux) as well as the entire RTOS market. It may not be much of an exaggeration to say that Microsoft has turned the world of embedded development upside down.

Bye Bye, VxWorks/Windriver, Micro C, and all the different flavors of embedded Linux.

“Absolutely no need for C/C++ any more even at the systems level.” A logical next step would be a miniature Dynamic Language Runtime (DLR) running on top of MicroFramework, with embedded development in Python & Ruby. This is the future!

2001- The typical compiled size of Busybox on the i386 architecture is 256K to 500K total for all tools, depending on the C library used and how it is linked.

http://www.linuxjournal.com/article/4335

2007 – The .NET Micro Framework running directly “on the metal” requires only about 300KB of RAM. A bootable CLR that can run directly on hardware without an operating system.

http://74.125.93.132/search?q=cache:ndtGBTxFyqgJ:download.microsoft.com/download/a/9/c/a9cb2192-8429-474a-aa56-534fffb5f0f1/.NET%2520Micro%2520Framework%2520White%2520Paper.doc+.net+micro+framework+size&cd=2&hl=en&ct=clnk&gl=us

2010 – There is this JamVM for java @ 200K

http://jamvm.sourceforge.net/

Yes there is the JamVM, but the .NET Microframework has us looking at Microsoft and their stack in an entirely new light. This signals many things:

• ‘C’ is no longer the most ‘performance oriented’ language.

• By redefining the concept of frameworks and by eliminating the operating system (OS), Microsoft has effectively ended the Unix era!

• No OS needed!

• Oracle may own Sun, but Microsoft has prove that it doesn’t need to own a hardware platform to be a winner in the market.

• Microsoft will target Google, since it has won the war in embedded systems.

• The next battlefront is ‘Scalability’

2 major engineers who ‘disappeared’ into Microsoft:

Moshe Pasumansky – The inventor of MDX

http://sqlblog.com/blogs/mosha/archive/2009/12/29/good-bye-bi.aspx

John Lam – The inventor of IronRuby

http://www.iunknown.com/2009/11/passing-the-torch.html