Performance and Linux: The Next StepJon maddog Hall (firstname.lastname@example.org)
Whether you are an embedded system trying to cut down on memory usage, a portable system trying to make your batteries last longer, a real-time system trying to do things in "real time", a desktop trying to create that snappy "feel", a server system trying to deliver good database performance or a "Beowulf" (when was the last time you heard that term?) trying to solve the worlds largest problems, performance is the word of the day.
GNU/Linux performs better than some well-known proprietary systems, but does it perform as good as it could? Have some of the pieces of code been written in the dusty dawn of time when memories cost 10,000 USD per megabyte and CPUs were 100,000 USD apiece (or more)? Perhaps they were written when 16 bit address spaces were king, or even 32-bit address spaces, or when gcc only had three optimization switches that you could use?
Perhaps the code has assembly language in it, which inhibits the portability of our favorite code to new architectures, or inhibits the compiler from taking advantage of new optimizations.
Linaro, an association of Linux and Open Source companies specializing in ARM processors has devised a contest to challenge people to optimize their code. This talk will NOT be about that, but will instead give examples of how code optimizations have improved code in the past, how it can improve code in the future, and give examples of how and where you might improve the code that you write or maintain.
The contest rules themselves will be published.