Recent Posts:
Cache: the key to multicore performance - Posted to Open Device, Insert Code by Brad Dixon on October 10th, 2008
If you attended my multicore webinar last month then you know that I'm a big fan of looking out the window at existing open source applications and seeing how they tackle performance issues. The webinar used the Apache HTTP server as an example. A recent Intel engineering study uses a modified version of snort as a test application for improving multicore performance. The Intel study, commented extensively on by Lori Matassa, indicated performance scaling on a 4 core system of 6.2x. This is notable because the generally expected benefit from adding a core is typically slightly under 1. For example moving an application to a 4 core system and then getting a 3.8x performance boost would be expected and would likely require some work to attain. The Intel engineering study is notable because it indicates something that experienced practitioners have always known: efficient cache usage is a critical factor in multicore performance. It simply makes no sense to play games elsewhere until you've got a grasp on cache efficiency and have maximized that aspect of your system performance. The Intel engineering study did something interesting with "flow pinning". Each TCP flow through the system was handled, for the lifetime of.. (Read More)
Someone Needs an Antacid - Posted to Off the Shelf by Jim Ready on June 19th, 2008
Bruce Webster has an interesting blog post about "Project FUBAR," an IT project gone bad, really bad. Although Bruce describes what appears to be the IT software project from hell, it is a real world example of some of the things that I described in my last blog post. I recommend that you read Bruce's entire post, but I wanted to highlight a couple of thing that stood out. Take this part of his memo, for instance: The code base is very fragile. A lot of it is bad old code that BigFirm didn't have time to rewrite two years ago, but now is five times its original size and even worse. One consultant said he took a code listing, picked pages at random, and found problems on every page he selected. There is pervasive hard coding of what should be adjustable parameters or at least meaningfully named constants (e.g., # of [key items] hard-coded throughout with the literal value '3', a constant named 'ninety_eight'). Builds take all night. App releases don't run acceptably, if at all, in a production environment. Developers check in files that won't even compile. Granted, this is an IT project and not an embedded project,.. (Read More)
