"Wimpy cores" are coming to Facebook | Hacker News Reader

"Wimpy cores" are coming to Facebook

gigaom.com

34 pointschewymouse16 comments

"Tilera has a the first non-x86 64-bit based server available in the market"

There must be some mistranslation here, because I'm pretty sure that 64-bit SPARC and PPC servers have been around for a while.

That said, after digging a little bit, Tilera's stuff looks really cool. Does anyone know if it's possible for ordinary mortals to get ahold of their hardware?

Supposedly there's this, but it's the old processor: http://www.quantaqct.com/en/01_product/02_detail.php?mid=27&...

They mean low-power 64 bit processor. I think MIPS had embedded 64 bit CPU designs like forever (used in playstation and laser printers).

BTW: Tilera based on MIPS ISA.

I think Tilera is a great solution for IO-bounded applications (i.e. web servers, like in Facebook case), while Xeon Phi is great for CPU-bounded HPC applications.

I'd be interested to understand why you would classify web servers as generally I/O bound, rather than CPU (or memory) bound.

What web application server will usually do is to accept HTTP request via TCP, fetch/update data in database server, render a web page and send HTTP response back via TCP. So essentially it just waiting, either for TCP stack or for database driver. IO-bound.

Facebook photos application for example, can be CPU-bound, because image processing applications had to process millions of pixels efficiently.

Why can't the web server do other work with the CPU and other resources at the same time that it is waiting for those network operations to happen?

Yes, but what the other threads will do? Answer: same stuff.

I can put it another way:

Some Tilera boards have 4x10GbE ports, but have no good floating point support.

On the other hand Xeon Phi has AVX2 (512 bit wide SIMD) with excellent floating point performance, but TCP/IP stack emulated over PCI-express.

So which one will you choose for network server and which for number crunching?

My somewhat circuitous point is that the ability of a server to perform work is bound by something that runs out - CPU (no more CPU time available), disk I/O (can't handle more I/O requests to disk), network I/O (can't put or get any more packets through your network card or some upstream device/pipe), and so forth. Colloquially, whatever runs out first is what you are bound by.

You can either increase the resource (upgrading CPU, adding memory), or use the resource in a different way/trade off one resource against another. For example, compressing data before network or disk I/O might be useful if you have spare CPU. Once you've done that, you may now be bound by something else - maybe available memory. If you have spare resources (CPU, for example), you can then choose to use fewer/less powerful resources in that space if it makes economic sense.

You can also talk about response time being bound by something - disk seek time, network latency, memory latency, and so forth. That affects how fast something can respond, and while that figures into how much work a server can do (per-thread/request memory usage), it doesn't generally largely affect how many machines you have to buy or their configuration (unless you have low-latency options).

(FB employee, tangentially related to this stuff) Everyone, including myself, casually uses the term "CPU-bound", "I/O bound", "Memory-bound" for convenience but the truth is usually more complex. You might actually be CPU-instruction-cache-bound or memory-latency-bound. One app I worked on a long time ago turned out to be random-numbers-bound. :)

In this context boundedness means roughly "the thing that would increase throughput if we had relatively more of it". A pizza shop is going to be fundamentally "oven-bound", because everything else from employees to counter space can be increased more easily than the size of the oven.

Waiting on outside I/O (databases) does not mean that a webserver is I/O bound. The system as a whole might be I/O bound, but not the web layer. Threads stuck waiting for dataz are just put to sleep and others take over the CPU.

Were you running out of entropy? If so, how did you solve it? (If you're allowed to divulge that)

With a Heisenberg Compensator! No. Like with any bottlenecked resource, you first measure how much you are using per "transaction", whatever that may be. Then you see whether you can use what you have more efficiently. Maybe you don't need it at all. Or maybe you can cut corners by using /dev/urandom or something.

But suppose you are generating tons of SSL certificates. You can't --or shouldn't-- cut corners. For example, see

https://freedom-to-tinker.com/blog/nadiah/new-research-there...

So... what do you do? The problem, like almost any bottleneck problem, isn't that you don't have "enough" of the resource, it's that the resource is out of balance with the other resources like CPU or RAM. When you think about it that way a lot of possibilities open up, like installing special cards or dongles that generate entropy, or by buying lots of lower-powered devices that have more entropy relative to their CPU throughput.

Saying that Tilera has 10000 cores in production is the same as saying they have 100-300 chips in production (each Tilera CPU has 36 to 100 cores).

It's hard for me to imagine anyone making the move to arm chips that don't have hardware virtualization support, which I think the cortex a15 will be the first mainstream one.

A lot of webscale people don't use VMs; you're not going to run too many in 4GB of RAM anyway.

Does ARM really need explicit hardware virtualization support? As far as I know, it fits the Popek and Goldberg requirements without it.

Trap-and-emulate virtualization has to use slow shadow paging. Nested page tables are much faster.

Reply on news.ycombinator.com