[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: concurrency research "hot" again?



OS in kilobytes? No, I am not kidding.

Some examples:

- Occam. You might not consider it as an OS, but it has the essential
runtime functions and the people from Kent might give you more concrete
figures. I picked up that the Transterpreter code (and that more a VM) fits
in about 10 KB.

- QNX. I still have a floppy somewhere that boots and brings up a GUI with
browser that connects to the internet. In case, such a floppy has not more
than 1.44 Mbytes. QNX is also a COTS OS that has a message passing based
architecture. Not as pure as CSP but a lot cleaner than these monolithic
monsters like Linux and Windows. For VISTA one now needs 1.5 Gbytes of RAM,
enough to turn you off forever from Windows. QNX has been bought by Decker
and if you happen to have a GPS/multimedia of that brand in your car, it is
likely to run QNX.

- Our own OpenComRTOS is using a CSP-like model and can be made to fit in 1
Kbyte (single processor) and 2 Kbytes (multiprocessor with full topology
transparency). This is the L0 layer and with static linking like in occam.
The L1 layer has more RTOS tradional services and is still being completed,
but it will fit as well in a few Kbytes. The reason for this small size is
that we used formal modeling. The previous RTOS we developed was called
Virtuoso (and was the first preemptive RTOS on the transputer in 1991) was
about 10 times bigger but still around nt more than 50 Kbytes.

I am not a professor, although I do some research. The OSes above are used
in industry. OpenComRTOS is put on smart sensors with an internal 16bit
micro, 32 Kbytes of flash and 2 KB of RAM (for data). It also runs on top of
Windows and ports are underway to e.g. the Cell processor, FPGA (microblaze)
and others.

I am more astonished that most "professors" in computer science (not all,
mind you) keep on teaching about these monolithic socalled OO models
requiring MegaBytes. CSP is unfortunately more or less forgotten. The good
news is that thanks to the upcming multicores, it is being rediscovered out
of necessity. But I find it shocking to see how much elementary knowledge of
the transputer days seems to have been lost. Old geeks like this group is
keeping it alive, ...
 

----------------------  FROM : --------------------------
   Eric.Verhulst@xxxxxxxxxxxxxxxxxxxxxx
   Skype me at: ericverhulstskype
   Mob. +32 477 608339
   Systematic Systems Development Methodologies
   Trustworthy Embedded Components
   http://www.OpenLicenseSociety.org
-----------------------------------------------------------
" "Concept" is a vague concept", L. Wittgenstein 


-----Original Message-----
From: owner-occam-com@xxxxxxxxxx [mailto:owner-occam-com@xxxxxxxxxx] On
Behalf Of Andrzej Lewandowski
Sent: Thursday, February 15, 2007 2:25 AM
To: tjoccam@xxxxxxxxxxx; 'Andrew Delin'
Cc: 'Allan McInnes'; 'occam list'
Subject: RE: concurrency research "hot" again?

"If OS size is in  kilobytes.. " You are kidding, aren't you?... Or,
maybe....  you are a PROFESSOR? This would explain everything...

A.L.

> -----Original Message-----
> From: owner-occam-com@xxxxxxxxxx
> [mailto:owner-occam-com@xxxxxxxxxx] On Behalf Of tjoccam@xxxxxxxxxxx
> Sent: Wednesday, February 14, 2007 1:55 PM
> To: Andrew Delin
> Cc: Allan McInnes; occam list
> Subject: RE: concurrency research "hot" again?
> 
> 
> 
> Maybe I'm sawing the same old violin, but...
> 
> I think the key to breaking out of the "incredibly difficult to 
> program in parallel" conundrum is to dump the baggage of the last 
> couple of decades and go back, not only to CSP, but also to elegant 
> (small) OS constructs. If OS size is in kilobytes, there's hope you 
> can understand COMPLETELY what it is doing, especially if the OS 
> restricts itself to resource loading and leaves run-time concurrency 
> to applications.
> 
> The other thing is to accept a 5 or 10 percent performance hit in 
> order to keep clear, provable, traceable resource usage (i.e. 
> eliminate spaghetti). The "hit" is actually not a hit, because the 
> cost of code tangles is really much more; but if raw specs are 
> applied, you can always do it just a little faster by letting pointers 
> and dynamic constructs go wild.
> 
> Larry Dickson
> 
> > Last week I attended a presentation by BillG where he also
> raised the
> > topic of insufficient semantic richness in today's
> programming models
> > - saying new developments are needed in programming
> languages to use
> > the parallelism of multi-core CPU designs. In the same
> conference, the
> > head of MS Research also talked about these challenges.
> >
> > About 6 months ago I sat through a presentation about options for 
> > parallelism in .NET today, and it wasn't pretty - way too
> much locking
> > litter and thread invocation for my liking. Having to
> understand the
> > behaviour of the compiler so that your process control statements 
> > don't get optimised away, isn't goodness.
> >
> > There is a proposed MS approach which seems to be a form of 'CPU 
> > transaction', where entire blocks of statements effectively compete 
> > for resources and the OS or hardware detects a livelock or
> deadlock or
> > other problematic condition. At this point, blocks of process state 
> > are reversed by hardware. I need to find out more about this. These 
> > techniques will probably need to exist if you want to build
> a robust
> > OS on top of multicore, where applications with different "parallel 
> > heritage" must run together. Nonetheless, the best approach for app 
> > construction is to start along CSP lines, not to rely on
> the system to
> > reverse out of trouble...
> >
> >
> > -----Original Message-----
> > From: owner-occam-com@xxxxxxxxxx
> [mailto:owner-occam-com@xxxxxxxxxx]
> > On Behalf Of Allan McInnes
> > Sent: Wednesday, 14 February 2007 1:25 PM
> > To: occam list
> > Subject: concurrency research "hot" again?
> >
> > It seems that concurrency is again getting "mainstream" attention. 
> > I've seen several articles in the popular press over the
> last few days
> > touting Intel's
> > new 80-core "teraflop-on-a-chip" demonstration chip. Most
> of the articles
> > I've
> > seen have made a big deal out of how difficult programmers
> will find it to
> > program for 80 cores, and how lots of research needs to be
> done to develop
> > new
> > techniques for programming parallel architectures (here's
> one sample of
> > the
> > articles I've seen:
> > 
> http://www.crn.com/sections/breakingnews/dailyarchives.jhtml?a
> rticleId=197005746).
> >
> > At the same time, I've seen several links to "The Landscape of 
> > Parallel Computing Research: A View from Berkeley"
> > 
> (http://www.eecs.berkeley.edu/Pubs/TechRpts/2006/EECS-2006-183.html)
> > show up on various websites that I check regularly. In that report, 
> > the folks from Berkeley say, among other things:
> >
> > "Since real world applications are naturally parallel and
> hardware is
> > naturally parallel, what we need is a programming model, system 
> > software, and a supporting architecture that are naturally
> parallel. 
> > Researchers have the rare
> > opportunity to re-invent these cornerstones of computing,
> provided they
> > simplify the efficient programming of highly parallel systems."
> >
> > So is research into concurrent programming becoming a hot
> topic again? 
> > And how many of these research efforts are simply going to reinvent 
> > the occam wheel?
> > The Berkeley effort, in particular, sounds a lot like the
> occam/transputer
> > approach (at least at a high level). However, the tech
> report in question
> > makes
> > no mention of CSP, occam, or transputers (OTOH, they also
> omit any mention
> > of
> > Berkeley's Prof. Ed Lee, who has done a lot of work on concurrent 
> > programming models via the Ptolemy project).
> >
> > It'll be interesting to see where this goes. Hopefully
> it'll lead to
> > an upswing in funding for projects that can claim to be working 
> > towards support for massive  concurrency - like KRoC/nocc :-)
> >
> > Allan
> > --
> > Allan McInnes <amcinnes@xxxxxxxxxx>
> > PhD Candidate
> > Dept. of Electrical and Computer Engineering Utah State University
> >
> >
> >
> 
> 
> 
>