Jack of all trades, master of none

Alan Shimel applauded a recent blog post by Eric Ogren regarding the "Advances by Intel and AMD in compute power with multi-processors and management with virtualization" claiming that these advances "have shifted the game for security vendors who are bringing their products to market as a high performance appliance."

Nevis Networks posted a rebuttal, and the comments responding to Eric's post were generally of the same bent: ASICs are not likely to be replaced by general purpose (commodity) processors, regardless of their capabilities.

While this current debate is focused on the security market and security-specific ASICs, this isn't a new argument at all. We heard similar arguments over core network processing ASICs in the early days of high-speed switches, and have continued to hear said arguments even today in the layer 4-7 switching arena. There are those who (mistakenly) believe that ASICs are unnecessary due to the increasing power of general purpose CPUs. 

This is simply not true. Those who buy into such statements are generally software-focused product vendors who want to believe it because it sounds good and justifies their decision to deploy on a standard computing platform with off-the-shelf hardware. But anyone who's studied operating system design and engineering understands that a general purpose CPU is just that - general purpose. It specializes in nothing because it has to support everything. It's a jack of all trades, and master of none. At its core, its circuitry is necessarily generalized whereas an ASIC is necessarily specialized. An ASIC is designed to perform a specific task, and to perform that task at the greatest possible speed.It is generally self contained, and non-interruptible. Once the order is given to "do its thing", it does it, and does it fast.

Eric claims that "It is becoming increasingly harder to justify large engineering investments in custom-built ASICs or hardware that is not built on a standard platform." I disagree. There is just too much overhead that comes with standard platforms - including the operating system - that degrades performance well below that of a custom built platform. There's a couple of good reasons we have custom hardware driving devices such as routers and switches and application delivery controllers - speed and capacity. The reasons custom built hardware platforms evolved in the first place are still valid - general purpose CPUs just aren't fast enough for some computing processes. A standard platform will always be limited not only by its use of general purpose CPUs, but by the general purpose operating system which stands between a product and that CPU.

There are certainly some tasks for which building an ASIC would be financially prohibitive and unjustifiable. Network and customized processing are tasks for which ASICs make a great deal of sense, financially and technically. One of the best examples of late involves XML processing, which requires the same deep packet inspection capabilities that Eric is claiming can be done efficiently in a general purpose CPU. That's simply not true, as evidenced by benchmarks and anecdotal evidence from implementations that rely heavily upon XML messaging.  XML processing on general purpose CPUs is terribly slow, and the only thing that's improved that performance has been ASICs and custom built hardware. Bulk encryption is another good example. Even today the general purpose CPU cannot match the performance of an SSL acceleration card (i.e. custom hardware). Any network device worth its salt uses one, to do otherwise is considered simply foolish. And dare we even try to pit a standard platform running a standard operating system with a standard network card against the purpose built hardware in a router or switch? There is no performance comparison necessary - general purpose loses to purpose built every time. That's why you've got a core router handling your traffic and not a Linux or Windows server performing the task.

ASICs are not going anywhere, nor are custom-built appliances. The architectures necessary to support wire-speed processing of application traffic are different than those needed for general purpose computing and require a custom-built system.

Imbibing: Water

Technorati tags: MacVittie, hardware, performance, ASIC, F5
Published Nov 27, 2007
Version 1.0

Was this article helpful?

1 Comment

  • Alan,

     

     

    Back in my publishing days we used to try to distinguish between the type of "appliance" you point out and purpose-built hardware by calling software shipping on off-the-shelf-hardware "softpliances". I agree, there is very little difference between shipping software and shipping software installed on off-the-shelf-hardware with the exception of eliminating installation tasks from the deployment.

     

     

    Deploying these "softpliances" is more about ease of installation and rarely has additional benefits aside from perhaps the ability of the vendor to harden the underlying operating system - a task many customers don't have time/desire/skill sets to perform.

     

     

    As far as performance goes, there's no advantage to a "softpliance" versus software deployed on customer provided hardware. The gains come when you move to a true purpose-built hardware platform, which is a completely different ballgame and may not be applicable to all types of software.

     

     

    Good point there, thanks!!

     

    Lori