Slashdot Mirror
OLPC Inspires Open Source Projects
Don Marti writes "A loose network of developers representing many commonly used open source projects are working to develop a new generation of low-memory, efficient code. This targeted code is being designed for a system, of which only 500 prototype boards now exist:
the 'Children's Machine 1' from the One Laptop Per Child project." From the article: "Gettys says measuring existing performance has to come before trying those changes. 'We've been pulling in every decent performance tool Linux has so we can optimize when and where it really matters,' he says. A key automated testing tool is Tinderbox, a build and test management tool originally developed for Mozilla, that new OLPC developer Chris Ball has installed, to build and test OLPC software. And, after Red Hat kernel developer Dave Jones gave a standing-room-only talk at the 2006 Linux Symposium titled, Why Userspace Sucks (Or, 101 Really Dumb Things Your App Shouldn't Do), his reports of suckiness, which include kernel-based measurements of wasteful behavior, are helpful, Blizzard says."
Finally, an antidote for sloppy bloated code - exploit child labor in 3rd world countries to test your product. Its elitist, I tell ya!
Give a man a fish and you have fed him for today. Teach a man to fish, and he'll say "WHERE'S MY FISH, YOU IDIOT?"
Better download just the paper itself instead of the full proceedings.
BTW, newsforge has a report about the presentation as well.
--
Ademar http://www.ademar.org/
AFAIK, the userspace app framework for OLPC is Sugar, which is Python based.
On what is basically an embedded computing platform with 128MB RAM, ~500MB permanent storage, and a CPU that doesn't have a L2 cache (last I checked), how much of these performance tuning would actually matter if all of these userspace apps depends on a language with an interpreter that you couldn't even fit 1/10 into the 16K of L1 instruction cache?
Don't get me wrong, me and my fellow students at the university are working on performance tuning, but as I look in to the Geode chip more and more, I believe that Sugar is poison for OLPC.
If you want a smaller footprint, hire someone with smaller feet!
I for one welcome our new prepubescent, code-writing overlords.
Well, yes, OLPC inspires Open Content as well. We are already working on a dictionary for Children on WiktionaryZ, the OLPC Children's Dictionary. What you can do for us? You can contribute to the translations of the defined meanings - just ten words + definition to translate in any of the many languages of the worls. No... it's not a joke ... we need your help and if you cannot help us, please tell other people. Thank you!!!
>>Even simple programs use up way more memory than needed.
Agreed. It's obscene to write a simple "Hello, world" and look at the memory usage. I used to fret about a few dozen bytes... now I allocate megs and don't even thing about it. Such is progress. Some people (such as Steve Gibson at GRC.com) are still coding Windows apps in assembly. I know people here aren't too impressed with Gibson (for all his showboating) but I've gotta say it's damned impressive seeing a real honest full-featured Windows app that's smaller than the Slashdot.gif picture in the upper left corner of this page. That's just cool.
Also, look at the Demo world. There are some absolutely stunning apps being written that use procedural rendering to accomplish stunning skeletal character animation with inverse kinematics, with soundtracks and advanced effects, in just a few hundred K bytes. Amazing stuff.
So coding for efficiency is happening, but it's rare -- a case of someone showing off. Or is it?
This brings up an interesting point: due to changes in architecture and hardware, coding for efficiency (usually performance) is already resulting in smaller code size. Let me explain.
In the early days of microcomputers (C64, Apple ][, TRS80), where system resources were extremely limited and cpu power was slight (e.g. 6502/8088, 8bit, 1mhz, 32k RAM, 40k floppies, no HDD or only tape for storage) and programmers had no choice but to code for efficient 1) performance within the boundaries of storage limitations.
Then around the days of the M68000 Macintosh and the 386, with its extended memory addressing, coding for performance meant pre-computing tables and looking up values as needed. Memory was cheaper than CPU.
This trend reversed in the early 90s when storage became cheap and bus speed increased, but couldn't keep pace with CPU speed advances. Suddenly, it was "cheaper" to compute values at the time they were needed b/c bus speeds imposed a huge penalty on looking up values. Breaking the on-chip ram cache could make-or-break a tight graphics rendering loop, so that was priority. (remember, at this point, software rendering was still common).
Introduce the extremely high-power GPU video cards we have today and the situation changes again. Offloading huge computational loads onto a deidcated graphics engine, the system CPU is somewhat of a traffic cop, ensuring subsystems have a steady flow of sound, textures, geometry, and network packets, oh... and occasionally performing game logic.
So it appears we've come full circle.
The bad news is now you guys have to listen to dinosaurs like me who cut their teeth coding in 6502 assembly ramble on about "well, sonny, back in MY day..."
If you speed up a computer's boot time by one second. And every PC in the world (aprox a billion) starts up every day. You would save ~12000 human years every year. Every year you would save ~150 lifes!
Every millisecond speed increase a day of software everybody uses every day would save 12 lives!
NOW GO BACK TO WORK! You murderer!
If you mod this up, your slashdot background will turn into a beautiful sunset!
There are quite a few open source apps that are full of code that no one ever runs at all but it rarely gets yanked out because no one is certain that the code isn't used.
I would like to see a library that can be linked in like the profiler libraries that will record what functions get called in such a way that the data can be shared with others in a massively distributed profiling system so the data can get back to the developers so they can look at the data say "we have 3 million people using this code and not one of them ever used this feature...time to purge it"
I don't think that the PS/2 Auxiliary Device Port is designed to generate an interrupt when something is hot plugged into it..
BTW -- notwithstanding what your computer science teachers taught you, polling is quite efficient if loads are predictable. Polling is usually much less resource intensive than interrupts ... if the polls have a high hit rate. And it's much less subject to wierd, difficult to reproduce problems and to race conditions. Across the broad spectrum of computing, there are probably far more cases where interrupts are used when polling would work better than vice versa.
That said, 20 polls per second seems excessive for a detecting a new device on a port that is rarely used except for mice. Once every 5 seconds would seem more appropriate.
You can't see ANYTHING from a car, You've got to get out of the goddamned contraption and walk...Edward Abbey