Would it ever be possible to program an fpga to run your HTTP server? So you'd have hardware that was specially designed for your program. Deploying code would just be about reprogramming the FPGA.
It's not a good idea to think of "programming" an FPGA to do anything. You're creating dedicated hardware. You tell a CPU what to do, while you tell an FPGA what to be.
When you're faced with a problem and you catch yourself thinking, "I wish I had an ASIC for this," your problem may be a good candidate for FPGA implementation. If what you're itching for is a faster CPU, or one that costs less or uses less power, then it probably isn't.
FPGAs are vital for interfacing to high-bandwidth custom hardware -- at least for those who don't have ASIC budgets -- and they're also useful for certain types of "embarrassingly parallel" problems that GPUs aren't well-suited for, especially where precision timing requirements and low latency are involved.
So, while you wouldn't typically resort to FPGAs when you're implementing an ordinary HTTP server, you might want to use them to build a dedicated TCP/IP offload engine, packet filter, or even a specialized memory controller. They are never going to be mainstream parts, even to the extent GPUs are. If and when you need an FPGA in your project, you'll know it.
> You tell a CPU what to do, while you tell an FPGA what to be.
That is the shortest and best description for the difference I've ever read. Kudos. From now on I'll use it to answer questions about FPGAs for accelerating.
I used to tell people that you don't design algorithms but a network of operations and pipelines where you stream your data through.
Err, I think the question is a little bit more complicated than that. You can run various "Soft IP" cores on FPGAs, and then run Linux, or whatever you want on that. I believe right now, OpenRISC, and RISC-V cores are some of the most exciting developments in the field, although you can get OpenSPARC, and MIPS cores as well.
If you want to have "hardware-optimization" in your HTTP server, I think you'd probably, rather than implement a Ethernet, TCP, L7 HTTP/1.1 stack from scratch use a combination of hard IP and soft IP. I imagine the places where a webserver is bottlenecked is well known -- you could extend the ISA, or have additional cores to help out with that part of the workload, and then run the rest on hard IP.
I think the biggest problem right now is programmability, and moving bits between x86 processors and FPGAs. I hope Intel's acquisition is fruitful and we see some FPGA on CPUs.
FPGA clocks run at about 1/10th of the speed of a general purpose CPU (very very roughly).
They can do more work per clock-cycle either using dedicated processing logic for a particular operation (some bit twiddling stuff like crypto can take advantage of this), pipelining multiple requests in serial, or processing multiple different requests at exactly the same time in parallel.
Crucially, whichever method(s) you use, you need to achieve more than 10 times the work-per-clock to make up for the clock being 10 times slower.
FPGAs are harder to program, have fewer and less well-rounded toolchains and are much much much harder to debug than other software. A bug tends to simply freeze the system completely for example.
An HTTP server on an FPGA where the FPGA isn't just emulating a general purpose CPU (a so-called "soft core") at a slow clock speed? Yes it's do-able: https://news.ycombinator.com/item?id=11776190, but it's questionable whether it would ever be faster than something written on an x86 CPU.
Possible? Yes, but it isn't a smart move to do so. Implementing the whole HTTP spec will be a waste of space and time.
Also, 'reprogramming' isn't as simple as it sounds. It is a pain staking process to test RTL you want to put into production. Even simple projects I'm working on, simple tests and synthesis take a lot of time.
Inconsequential niggle: the word/phrase is painstaking, which breaks up as pains-taking (rather than pain-staking). As in "I am taking pains to do this correctly". Back when I were a wee lad, one often took pains; kids these days are more likely to attach the phrase to the task rather than the performer, so the adjectival inversion is more common, and it's easy to rebracket.
(Rebracketing in language is the process by which you now may find yourself eating an orange rather than a narange, cutting a notch in something rather than cutting an otch, or feeling a bit more alone than all one. Sometimes it results in language change, but there's that awkward period where it's wrong first.)
I noticed that too, mentally paused for a moment, and then wondered if maybe it was an autocorrect fail. It'd be an eyebrow-raising one (a bug), but I don't put much past autocorrect...
But while I'm on this subtopic, if you've never heard of it, "france is bacon" is fun to google.
An HTTP server is an unimaginative application of an FPGA. What a specialized chip in the cloud is more likely to do is accept requests in a specific (but not generic like HTTP) way and perform equally specialized computation.
If memory bandwidth / transfer speeds between CPU and FPGA wasn't a concern, I can see using an FPGA to "accelerate" some aspects of HTTP protocol parsing -- string tokenizing for headers and the like, being of some small minor value. Or as others have said, further down the protocol layers, handling aspects of TCP/IP and network frames the like.
But that "if" is the problem -- you'll spend more time and CPU shuttling data back and forth than you would gain by specializing the problem in an FPGA.
When you're faced with a problem and you catch yourself thinking, "I wish I had an ASIC for this," your problem may be a good candidate for FPGA implementation. If what you're itching for is a faster CPU, or one that costs less or uses less power, then it probably isn't.
FPGAs are vital for interfacing to high-bandwidth custom hardware -- at least for those who don't have ASIC budgets -- and they're also useful for certain types of "embarrassingly parallel" problems that GPUs aren't well-suited for, especially where precision timing requirements and low latency are involved.
So, while you wouldn't typically resort to FPGAs when you're implementing an ordinary HTTP server, you might want to use them to build a dedicated TCP/IP offload engine, packet filter, or even a specialized memory controller. They are never going to be mainstream parts, even to the extent GPUs are. If and when you need an FPGA in your project, you'll know it.