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.
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.
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.
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.
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.
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.
(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.)
But while I'm on this subtopic, if you've never heard of it, "france is bacon" is fun to google.
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.