May/June 2018 issue of acmqueue The May/June issue of acmqueue is out now


  Download PDF version of this article PDF

ITEM not available


Originally published in Queue vol. 7, no. 3
see this item in the ACM Digital Library



Yonatan Sompolinsky, Aviv Zohar - Bitcoin's Underlying Incentives
The unseen economic forces that govern the Bitcoin protocol

Antony Alappatt - Network Applications Are Interactive
The network era requires new models, with interactions instead of algorithms.

Jacob Loveless - Cache Me If You Can
Building a decentralized web-delivery model

Theo Schlossnagle - Time, but Faster
A computing adventure about time through the looking glass


(newest first)

Craig Everett | Mon, 07 Apr 2014 12:02:02 UTC

Excellent article.

The basic rule seems to be that when a separate, intermediate node on the network would be a useful place to offload a task then an NFE makes sense. Whenever that is not the case, the overhead is higher than the payoff so streamlining within the system is the better option. In that context Julian's comment describes an in-place optimization, not a new class of solutions (that software isn't properly taking advantage of multiple cores is the OS's fault; this is an article about hardware design).

I think this issue is really much more broad than hardware interfaces, though. To me it is about process encapsulation and how tasks relate to messages. The difficulty of implementing an NFE in a beneficial way is a symptom of conceptual violation of some basic rules.

Going even farther, I think the time will come when each process carries its basic data along with it -- sort of a mobile closure (I'm sure there is a better word for this, but Alan Kay's term "object" has already been hijacked). Each of these closed bundles will provide themselves with their own basic I/O facilities, and we won't focus so much on where the execution actually happens. We do this to great effect today in, say, the Erlang runtime. Hardware support, not software runtime implementation, for this sort of thing would likely render a lot of the performance concerns we have today moot, and drastically shrink the necessary exposed surface of an OS. That this makes the most sense as a hardware reaction to software is probably what the reconfigurable computing guys were originally getting at.

Of course, none of this would spell a happy future for the "capture everyone's bits so we can sell them back to the user" cloud model, so it won't catch on anytime soon.

Julian Satran | Sun, 26 Dec 2010 06:55:55 UTC

Mike - good overview. However I wonder why you are ignoring a new class of solutions that are a good match for current multicores - dedicating cores for I/O function. I and several colleagues have experimented and published both architectures as well as experimental results (including a protocol stack that is 4-6times "better" than general purpose stack. Those solutions might involve in the long run some (new) hardware but are readily usable now without any additional hardware. And Intel has published similar results (limited to the TCP/IP stack) - and they call this technology "onloading".


Nick Black | Sat, 27 Jun 2009 15:09:44 UTC

That was outstanding! Thanks, Mike!

Simon Kenyon | Wed, 13 May 2009 15:19:54 UTC

insightful as always

Leave this field empty

Post a Comment:

© 2018 ACM, Inc. All Rights Reserved.