
"Wimpy cores" are coming to Facebook - chewymouse
http://gigaom.com/cloud/wimpy-cores-are-coming-to-facebook-but-which-cores/
======
wtracy
"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?

~~~
nivertech
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.

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

~~~
nivertech
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.

~~~
aristus
(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.

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

~~~
aristus
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...](https://freedom-to-tinker.com/blog/nadiah/new-research-theres-no-
need-panic-over-factorable-keys-just-mind-your-ps-and-qs/)

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.

------
nivertech
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).

------
batgaijin
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.

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

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

