Pinderkent

James Hamilton recently wrote about the use of low-cost and low-power servers, with a focus on ARM-based systems running Linux. He points out that the linux-arm.org site itself is running on such a setup. Looking at the specs of their systems reminds me of the servers we used in the mid-to-late 1990s, and even into the 2000s. Having been involved with software development for many years now, with much of my work revolving around networked business applications and server applications, I find this to be an interesting topic.

Clearly, a huge part of the problem today is the software we'd be running on such hardware. With the rise of Java, and especially frameworks like Ruby on Rails, far less of our hardware resources are used for actually performing the work of our software applications, and instead go towards powering the numerous frameworks, virtual machines, and platforms typically underlying our applications. Indeed, it has gotten so bad that some people are surprised when their Ruby on Rails-based Web application can handle "multiple requests per second", on modern hardware, without exhibiting performance problems.

Most recently, I wrote about Stack Overflow's outrageous hardware usage. Give the generally simplistic nature of that site, and the huge amount of processing power offered by today's low-end hardware, it's almost absurd to see how much they're apparently using.

When discussing lightweight servers, we shouldn't forget to consider the use of NetBSD instead of Linux. Aside from it already offering several ports to various ARM-based platforms, NetBSD is among the highest-quality open source software out there. I know of one person who used NetBSD on old PCs to serve images. I've also advocated it as an alternative to lightweight Ubuntu Linux distributions, as well as for use on low-power systems like Intel's classmate PC.

People today seem to forget just how powerful a typical server is today. Even the ARM-based servers that James mentions, or those powering the linux-arm.org Website, sound much more powerful than what we used a decade ago. That's not unexpected, of course. The cost of hardware rapidly drops, while its capabilities rapidly increase. Unfortunately, our software systems seem to eat up those gains rather quickly.

The main barrier to the widespread use of low-power and low-cost servers will likely be our existing software, frameworks, and platforms that use hardware resources very inefficiently. Instead of trying to salvage those, many of which are already a lost cause, perhaps we should be more willing to start from scratch, strip out all of the unnecessary layers of software that have accumulated, and make better use of functional programming languages like Erlang and Haskell. So not only would we get the benefits of using more efficient hardware, but we'd also get a much simpler and efficient software platform upon which to build our applications.

Last week, a colleague forwarded me the link to one of the most blatantly incorrect computing articles he had ever seen. It's entitled C# vs C/C++ Performance, and after reading it, I must agree with my colleague. It isn't often that we get to see an article so full of misinformation.

We see the first major mistakes within the "Point 1" discussion. The author clearly has some serious misunderstandings about hyper-threading and instruction sets. One of the gems we see is: ... a C++ program will not be able to take the advantages of the "Hyper Threading" instruction set of the Pentium 4 HT processor.

Of course, no such instruction set exists. Hyper-threading, as implemented by Intel up to this point, is transparent to userland applications.

Immediately after that, we read: Of course HT is outdated now....

That is, of course, absolutely false. Intel's recent Core i7 processor makes use of hyper-threading, with each of its four cores supporting two simultaneous threads. It's not an "outdated" technique.

It gets better as we read on: It will also not be able to take advantages of the Core 2 duo or Core 2 Quad's "true multi-threaded" instruction set as the compiler generated native code does not even know about these instruction sets.

Again, we see more ignorance regarding instruction sets and hyper-threading. While newer CPUs do often include new instructions, the supposed "true multi-threaded" instruction set that the author of that article writes about is bunk.

The next misleading claims we see are as follows: In the earlier days, not much changes were introduced to the instruction set with every processor release. The advancement in the processor was only in the speed and very few additional instruction sets with every release. Intel or AMD normally expects game developers to use these additional instruction sets.

We can see how wrong this is by looking at Wikipedia's x86 Instruction Listings page. It shows the original 8086/8088 instruction set, along with the instructions added with each processor generation. Based on that information, we can see that older processors such as the 80386 and the Pentium Pro each added quite a few new instructions. And the claim that new instructions are typically added for "game developers" is laughable. Games are just a small subset of the multimedia applications which benefit the most from the newer instruction sets. And that's not to mention the scientific and engineering applications which benefit significantly, as well.

Next we move on to the "Point 2" discussion. It almost immediately starts off with a five-line snippet of completely unrealistic code. It's not even a remotely valid microbenchmark, which themselves are often bad enough when they actually can compile and actually can be executed. Yet from this code, which consists of an undefined function that performs a "really time consuming operation" being called 100,000,000 times, the author of that article comes to the conclusion that "C++ is faster by a order of magnitude." Huh?

The next sentence reads: Nearly all the threads I've seen that claims C++ is faster writes a small application like this a prove that C++ is atleast n times faster than an equivalent c++ program and yes it's true.

So we find out that the claims of the author's article aren't even based on personal experience, let alone more rigorous approaches. They're based on what was read in some message board or mailing list. And beyond that, we can see statements that don't make even the slightest bit of sense as written, such as "C++ is atleast n times faster than an equivalent c++ program." The second "c++" should apparently read "C#".

The "Point 3" discussion focuses on memory management. While the author is somewhat correct in pointing out that memory management is more involved when using C++, there is no mention of Boost's smart pointers, the Boehm-Demers-Weiser garbage collector, Valgrind and the various other technologies that greatly help to prevent or track down memory leaks in C and C++ applications. I've seen first-hand how these technologies can be used to develop long-running systems in C++ that contain millions of lines of source code, yet don't suffer from obvious or significant memory leaks.

Further along, we get to read: Everyone knows that page fault is one of the most time-consuming operation as it requires a hard disk access. One page fault and you are dead.

While excessive page faults are typically bad for performance, they're not the evil that the author of that article portrays them to be. A single page fault won't typically harm performance as badly as the author suggests. And with most modern operating systems, we often see demand paging used. In such a scenario, we don't load a page from disk until it's actually referenced, which can lead to improved application startup times and reduced memory usage. So some page faults are to be expected.

The next misunderstanding is: A lot of classical applications including Google Picasa suffers from memory management problems. After about two or three days, you can notice that these applications become slower necessitating a Windows Restart. This problem is completely alleviated in C#. the Framework comes with a broom behind you and sweeps your drop during the course of the execution and as a result your working set never grows (unless you really use it) which means lesser page faults.

While many desktop applications today do leak memory, it doesn't make sense for the author of that article to suggest that we need to perform a full reboot of the operating system. Killing the application process should, under most modern operating systems (including most versions of Windows still in use), be sufficient to free whatever memory it may have been using. Furthermore, it's incorrect to suggest that such problems will be "completely alleviated" while using a language like C#. It's quite possible for an application to have code that maintains references to objects that are no longer needed, thus preventing them from being garbage collected. Carelessness can cause problems regardless of which programming language is being used.

The author of that article comes to the conclusion that the best thing to do is take a hybrid approach; write most of the application in C#, and have it call out to performance-critical code written in C++. While this is an option, a better approach is to first profile your code to see where and why it is actually slow. Don't just assume it's the language. Often times, we see poor algorithms being used, or unnecessary computation being performed. Based on my years of experience, I'd say that fixing such issues will typically give a much greater performance boost than changing programming languages.

Every author, myself included, will no doubt make minor mistakes here and there while writing. They're expected, and forgiven. However, the article that my colleague linked me to was incorrect from top to bottom. What is perhaps the most disturbing thing about that article is that some people may very well believe what it is saying to be true. Perhaps articles like that one are why so much software is so poorly written. To those who don't know better, such articles sound legitimate and sensible. But after even the slightest bit of analysis, we see such articles fall apart almost completely. Unfortunately, there are a lot of people out there who can't or won't perform such analysis.

Anand Iyer recently wrote an article that transcribes a portion of a video in which Joel Spolsky is discussing the hardware and software that is backing the very useful and increasingly-popular Stack Overflow Web site. It's mentioned that there is one Web server and one database server, both running on "eight core Xeons" and serving "16 million" pages a month. At first, that sounds impressive. But thinking about it more, I'm not so sure it really is.

First, we should convert that value of 16 million pageviews into something we can comprehend better. Assuming a month of just 30 days, a quick bit of math shows that to be 2,592,000 seconds. Sixteen million pages over that number of seconds ends up being a mere 6.2 pages per second. Now, that's probably not a totally accurate picture. There are no doubt times when the traffic is much higher than that, and other times when it's lower. But even if their overall pageview traffic were to triple or quadruple, we're still not seeing huge numbers of simultaneous page requests.

I don't think people today truly realize the power of today's hardware. Even the low-cost, consumer-grade PCs you can buy for a few hundred dollars are significantly more powerful than the servers of just a few years ago. So I don't think we should get too excited about Stack Overflow being able to serve 6 or 7 pages per second, if not many times that during periods of heavy load, over what's essentially 16 very powerful CPUs.

Thinking back to some of the database-backed intranet Web sites I've worked on in the past, we were able to reasonably handle sustained traffic of 30+ pages per second at times on far inferior hardware. This was even when we still used CGI scripts written in Perl, which have not only the overhead of starting up the interpreter process with each request, but also the overhead of the program interpretation itself.

I recall one job in particular because of how rushed it was. The company had several call centers located throughout the world, and was moving towards a custom Web-based solution for the call center operators to use. Expecting up to 30 simultaneous users per second at peak hours, they had placed an order for some significantly powerful hardware at that time. The order was delayed for some reason, but management wanted the site to go live. So the decision was made to temporarily use some older, unused Sun workstations as servers. I recall spending a night getting two workstations set up as Web servers, and one as a database server, so the system could go live the following morning. It went live, and everyone was very surprised to find that even under higher than expected load, running on older Sun workstation hardware and using Perl CGI scripts, the responsiveness of the Web site was quite acceptable.

Now, I don't expect that to be the case all of the time. Like Joel points out in his talk, there are many sites even today that use significantly more hardware than they probably should. But with some sensible caching policies and a small degree of care while programming, it really wasn't overly difficult to get high-traffic sites running on a small amount of lower-end hardware. Even in Stack Overflow's case, it sounds like they could get by very easily with a small fraction of their current infrastructure. However, it is good to have room to grow, as the traffic to that site likely will.

Computer hardware today is extremely powerful. For most Web sites, even those getting millions upon millions of pageviews per month, scalability just shouldn't be an issue. If it is, it's likely that there have been some pretty significant programming mistakes made when developing the software powering the Web site. And with low-end servers today typically coming with eight or more logical processors and many gigabytes of memory, servicing hundreds of requests per second from a single system should be considered routine.

Today I read an article that discussed a variety of issues relating to Microsoft Windows today, including the general disappointment surrounding Windows Vista, and the apparent lack of interest in Windows 7, especially in the enterprise. It goes on to suggest that Microsoft themselves are responsible for this, and Apple will gain the most from this situation.

I don't think we're really seeing Microsoft tarnishing the Windows brand. In some sense, it's not even possible for them to do that. Many people, and not just Mac users, have an extremely low opinion of Windows to begin with, along with many of Microsoft's other software products. Although the NT-based systems typically don't suffer as badly from the chronic crashes and security flaws that plagued Windows 95, Windows 98 and Windows ME, users of those earlier versions will forever associate the names "Microsoft" and "Windows" with poor-quality software. Even today, I rarely meet people who outright like Windows. Most of its users just seem to tolerate it.

If anything is causing Windows to become more irrelevant, it's the widespread move towards Web-based applications. This isn't a novel observation, by any means. It has been obvious for some time now that many applications that were formerly desktop apps have been replaced by Web-based alternatives for a large number of people. People using Web-based email services like Microsoft's own Windows Live Hotmail and GMail instead of desktop mail clients is one significant example.

The move towards Web-based applications is a trend that has been common within enterprise software development for years now. More and more companies are replacing what were traditionally desktop applications with Web-based alternatives. Now this often isn't a good idea; there are some applications that are much better left as standalone apps. But in many domains, the software the users are interacting with is solely browser-based, and thus the underlying desktop operating system is essentially irrelevant.

When the user is interacting mainly with a Web browser, it really doesn't matter what operating system is underlying it. Mozilla Firefox and Opera alone are typically good enough for using most Web-based apps. So the need for Microsoft's software is diminished. This is why GNU/Linux has become more appealing for many enterprise users. It's not about GNU/Linux being more capable than Windows, but rather the opposite; it's easier and cheaper to strip GNU/Linux down to provide just the bare essentials for running the browser used to access the Web applications.

Microsoft saw the threat that Web-based apps posed to desktop applications, and put forth their Windows Live and Office Live initiatives. I'm not sure if these have been as successful as Microsoft would have hoped. In my experience, I've seen little to no serious adoption of these technologies in enterprise settings. This is one area where Web-based applications typically aren't as useful or acceptable. Many enterprise users want greater control over their documents, namely where they are stored and who can access them.

I think it's doubtful that Apple will truly make significant inroads into the enterprise. While some such users will likely switch to Apple's hardware and software, and others will no doubt consider it, given the current cost of Apple's offerings I don't see it happening on a wide scale. Much enterprise computing has been driven by large purchases of lower-quality and very low-cost PCs. As mentioned before, with many organizations moving towards Web-based applications, the need for overly powerful PCs is diminished. With low-end PCs still being suitable, many IT managers will need to cut costs by using GNU/Linux instead of Windows, rather than purchasing more expensive hardware/software combinations from Apple.

So we're likely looking at a more diversified computing world, with some users using desktop apps, others mainly using Web-based apps, and many using a mix of both. It's very unlikely that we'll see Apple's products, or any other company's products, achieve the same market share that Windows holds. There's just too much impetus at this time for such significant changes, even if future versions of Windows are as poor as Windows Vista was.

Today we finally heard the sad news about what's probably going to be the end of SGI. This doesn't come as a surprise to anyone who follows the industry, of course. SGI's fortunes have been steadily declining for the past decade. But it's still humbling to think of how what was once a great company could fall so far.

The Silicon Graphics of the 1980s and 1990s can perhaps best be compared to Apple today. There was always a certain excitement around SGI's offerings, often due to their quality and power, but also due to their unique flair. This really isn't surprising; they were at the forefront of computer graphics technology. Their systems allowed for the creation of what were, at the time, very spectacular visual effects. Seeing an SGI system at work didn't just leave a strong visual impression of whatever was rendered, however. The unique designs of many of their systems also left an impression.

SGI is best known for their MIPS-based systems, their IRIX operating system, and OpenGL. In terms of hardware, SGI was typically at the forefront of the market. For instance, they offered 64-bit MIPS systems in the early 1990s. This may not seem like much now, but it wasn't until a decade later that we saw the x86 world start to move towards 64-bit computing. And in terms of advanced graphics hardware, they led the way for many years.

Although I didn't work with companies who used SGI workstations for their high-end graphics capabilities, I did use an Indy workstation for some time during the 1990s, and was able to work with some companies who used SGI systems as servers because of their power and flexibility. And as servers, they were always very reliable, and often a pleasure to work with compared to the UNIX-based offerings of various other vendors.

Their IRIX operating system was always interesting to work with. During the time when I worked with such systems, they'd already moved to X and 4Dwm. While I always sort of preferred CDE, 4Dwm nevertheless did provide a unique desktop experience.

Aside from its graphical nature, IRIX was always known for scaling quite well. Given the needs of many of SGI's customers, high performance was always a necessity, and scaling well was typically the only way to get that sort of performance given the hardware of the day. One aspect of IRIX that was particularly interesting was its XFS filesystem. Being a 64-bit journaled filesystem, it was always capable of reliably storing huge amounts of data. While this was necessary for those doing video capture and editing, for instance, it nevertheless proved very useful for others who needed to store huge amounts of non-graphical data. Thankfully, XFS was released as open source software, and has been integrated with the Linux kernel. Even today, fifteen years after it was first released, XFS is still a very usable and practical filesystem, employed by many.

For some time, SGI had many of the brightest minds in the field of computer graphics working for them. OpenGL was one of their notable achievements. Like XFS, they were quite open with OpenGL, and thus it flourished, with it now being well-supported on many modern operating systems and graphics hardware. Just over a week ago the Khronos Group announced the release of the OpenGL 3.1 specification.

One thing about some SGI workstations is that they had a distinct appearance. Take their O2 and Octane systems, for instance. Both offered curved designs with uniquely powerful color schemes. It was easy to recognize such systems, even from a distance, in much the same was as many of Apple's designs stand out. And for their systems with a less-remarkable appearance, the 3D wire cube logo they used to use always made their systems identifiable.

It's unfortunate to see SGI end like this. Even if their products were expensive, they were typically quite innovative, and were the sort of products that one could get genuinely excited about. Not only did they give their systems a unique appearance, but they followed through and produced systems that were very capable, extremely powerful for the time, and generally quite reliable. Unfortunately, market pressure from below took its toll on SGI. Many of their higher-end customers reportedly moved towards commodity hardware. The loss of talent to companies like NVIDIA and ATI didn't help the situation, either. And although their future may be limited, it's likely that we'll see at least some of their work live on for some time in the form of XFS and OpenGL. Hopefully it's not forgotten where such achievements originated.