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?"
No Java then, I take it?
So you dont have to dig...
_ procv1.pdf
"Why user space sucks" is at:
Pages 441-449 of http://www.linuxsymposium.org/2006/linuxsymposium
- Adam L. Beberg - The Cosm Project - http://www.mithral.com/
I swear, it's about time people got away from the "aww, we got as much memory as we need! No need to worry if this is way to big for our needs!
Cliff Claven
K.E.G. Party Chairman
Founding Leader of: Koncerned for Egalitarin Governance
I do hope that the one laptop per child project will succeed in setting benchmarks for what a laptop should be and also how the applications which run on that laptop should behave (efficiently using memory being one of them).
Linux Help
for all things on Linux
It's Christopher Blizzard
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..."
I'm not exactly sure where you get that impression from - certainly Forth can be pleasantly efficient when it comes to memory use, but I would suggest "roughly on par with C" is about the best you can claim. Now, while the Debian Computer Language Shootout benchmarks are hardly ideal, particularly since they are all very small programs, they can give at least an idea of roughly comparable memory use in a variety of different languages. In this case, glancing through a few different benchmarks, we see that Forth certainly holds its own (doing quite well in the k-nucleotide benchmark) but is at best on par with the other memory efficient languages, and is down the list in several benhmarks. The winner is often C (unsurprisingly), though Pascal, D, Eiffel and Fortran all do remarkably well as well. Given those options, and presuming you were going to move away from C for some reason, I'd have to say D and Eiffel are the most attractive options.
Craft Beer Programming T-shirts
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