stuntprogrammer

For your 128GF I take it you are assuming 1:4 with FP32. That would be unexpected. E.g. in contrast to AMD parts, the recent NV parts based on Maxwell2 (such as GM204 in the gtx980) are 1:32 for FP64:FP32. I would expect that ratio to hold in this part, and the SMs are likely highly similar, giving the ~16GF number I used.

I haven't seen the automotive workloads, but they strike me as repetitive and regular enough that a Denver style part would do ok. That said, I'm not shocked by the use of A57+A53.

(Disclaimer: I worked on an early version of Denver on the code morphing software, and at an ARM server vendor on A57 based SOC).

In this case, I believe it's 1TF of FP16, or 500GFlops FP32. You're likely looking at 16GF FP64.

I've also heard, though unconfirmed, that on the CPU side it's quad A57 + quad A53 rather than Denver derivatives.

It's been a while since I've been an insider, and these comments are purely from an outside perspective, interacting with such users.

Vertica is seeing use for more historical stuff, and where the time series queries are pretty simple. Informix time series is doing ok, and has better support for rich queries, but isn't really playing realtime. MemSQL has the realtime perf (hi guys!) but needs to beef up on expressiveness. SAP HANA could do it, but not seeing major uptake there.

Still seeing lots of ad hoc solutions, and the expected experimentation with the usual hadoop menagerie (spark is helping make that practical).

The sensor stuff gets interesting at scale. Individual sources may not be producing data that quickly, but in aggregate it can be entertaining volume. Esp. when it comes to mobile things, and correlations become interesting to look at.

Deep thoughts need to wait for the coffee to kick in.

I suspect we'll see a lot of reinvention of technology to cope with these problems; perhaps even open source..

Disclaimers: I was CTO@Kx for a while, but also like InfluxDB :-)

It is definitely more finance oriented, though Kx are making moves towards other application areas. Another difference I'd highlight is that Kx concentrate on the core database itself, esp. performance and expressiveness of the query language, and leave things like GUIs and admin add-on tools to partners (like first derivatives and aquaq).

kdb does just fine with metrics and sensor data. Personally, I would argue that it's weaker on string handling though, which can hurt in certain use cases.

I doubt it'll go open source any time soon. However, it being around a long time is something salescritters can spin to wonderful effect re stability, support, etc etc. ;-)

I think there are fine application areas in finance that you should consider -- just consider the many areas where the core problem isn't related to juggling TB of market data ticks coming off the exchanges.

From what I've seen, this is true in the middle and lower end but not the higher end.

No, I wouldn't go back. That said, it has made it rather difficult to fit comfortably in standard settings. I've been successful so far but taking Arthur's lessons and applying from various domains, to software, and into cluster/system/soc arch in my case, has been viewed as rather unorthodox.

I find that especially in the valley, adherence to buzzwords and fashion of the day is a little too common for my taste now.

Yes, he is that good. I worked directly with him for a few years and it deeply changed my long term approach. Side effect is that it became harder to deal with the "normals" ;-) seriously though, it made me very impatient with the sorry state of the "state of the art" in the valley.

Is there a cost? Of course. But arguably it's in the noise on these chips. Knights Ferry and Corner are using a scalar x86 core derived from the P54C. How many transistors was that? About 3.3 million. By contrast, Nvidia's 16-core Fermi is a 3 billion transistor design. (No, Fermi doesn't have 512 cores, that's a marketing number based on declaring that a SIMD lane is a "cuda core", if we do the same trick with MIC we start doing 50+ cores * 16 wide and claiming 800 cores).

How can we resolve this dissonance? Easy -- ignoring the fixed function and graphics only parts of Fermi, most of the transistors are going to be in the caches, the floating point units and the interconnect. These are places MIC will also spend billions of transistors but they're not carrying legacy dead weight from x86 history -- the FPU is 16 wide by definition must have a new ISA. The cost of the scalar cores will not be remotely dominant.

I'm not sure why you are concerned about the pin count on the processor, except perhaps if you are complaining about changing socket designs which is a different argument. The i7 2600 would fit in a LGA 1155 (i.e. 1155 pins) whereas Fermi was using a 1981 pin design on the compute SKUs. The sandy bridge CPU design is a fine one. The GPU is rapidly improving (e.g. ivy bridge should be significantly better, and will be a 1.4 billion transistor design in the same 22nm as Knights Corner).

We should distinguish between designing for a benchmark and designing for a set of workloads. Everyone choices representative workloads they care about and evaluate design choices on a variety of metrics from simulating execution of parts of those workloads.

Linpack is a common go-to number because, for all the flaws, it's a widely quoted number. E.g. used in the top500 ranking. It tends to let the cpu crank away and not stress the interconnect, and is widely viewed as an upper bound on perf for the machine. In the E5 case it'll be particularly helped by the move to AVX enabled cores, and take more advantage of that than general workloads. Realistic hpc workloads stress a lot more of the machine beyond the cpu. Interconnect performance in particular.

People like to dump on x86 but it's not that bad. There are plenty of features no one really uses and we still have around, but those features will often end up being microcoded and not gunking up the rest of the core. The big issue is decoder power and performance. x86 decode is complex. On the flipside, the code density is pretty good and that is important. Secondly, Intel and others, have added various improvements that help avoid the downsides. E.g. caching of decode, post-decode loop buffers and uop caches etc. Plus the new ISA extensions are much kinder..

Sustaining 1TF on DGEMM was explicitly mentioned by Intel in the presentation/briefing.

It's also mentioned in the press release:

http://newsroom.intel.com/community/intel_newsroom/blog/2011...

"The first presentation of the first silicon of “Knights Corner” co-processor showed that Intel architecture is capable of delivering more than 1 TFLOPs of double precision floating point performance (as measured by the Double-precision, General Matrix-Matrix multiplication benchmark -- DGEMM). This was the first demonstration of a single processing chip capable of achieving such a performance level."

Does it mean much? It means something to me, and is a great first step for those of us running compute intensive codes. They really wouldn't get far if they designed the chip only around being able to do this.

As I mentioned elsewhere in the thread, the article text is incorrect. The chip we're discussing is Knights Corner not Knights Ferry. The latter has been in early user hands for quite some time now and I've spent plenty of time hacking on it. Knights Corner is the new chip that is working it's way to production via the usual process with ship for revenue in 2012.

The 2018 target is for an exascale machine, not shipment of initial MIC devices. TACC have already announced they'll be building out a 10 petaflop MIC based system next year to go operational by 2013.

Yes, I'm comparing a chip that has not shipped, but given the perf advantage, given the tools and productivity advantage, given the multiyear process advantage Intel is sustaining, this is not a chip to be ignored. Knights Corner is shipping on 22nm. Other vendors have notoriously had difficultly on previous processes, depend on fabs like TSMC who are doing 28nm for them, and will be later to 14nm etc.

It's doing 1TF sustained and no one ever sustains 100% of their theoretical peak, so we know the peak is higher than 1TF. Consider also the sandbagging of number of cores as "50+". How big is the "+"? In reality the design will have a larger number that is then binned by yield and so forth to give a range of SKUs, as usual.

Next, you're comparing a sustained number on DGEMM with theoretical peaks on other machines. Nvidia sustains <225GF on DGEMM with Fermi so this is 4-5x. Last I looked, AMD were sustaining ~500GF with Cayman, so this is 2x, and a much easier machine to sustain perf on for other codes compared to Cayman. If you consider a potentially sandbagged 2x sustained perf to be "relatively minor" then so be it.

There are few public details provided but many of us have been programming with the Knights Ferry SDV kit in preparation for this part. So we have experience with the tools, with the use of lots of similar cache coherent x86 cores, etc. I can tell you this -- it's much easier to work with this than GPUs, and I've written a ton of code on all kinds of whacky machines, production compute code on GPUs included.

A few problems in your comment:

1) The article text is wrong (and doesn't match the pics of the slides). The chip demonstrated today is Knights Corner which is a new part, not the older Knights Ferry SDV.

2) When counting flops we need to distinguish between single precision flops and double precision flops. You're comparison isn't valid -- Knights Corner was shown sustaining over 1TF on a double precision code. Nvidia's most recent flagship GPU has a theoretical peak of 515GF/s but sustains less than 225GF/s on the same DGEMM operation. Knights Corner is sustaining 4-5x that, and this implies that it's theoretical peak is higher again. AMD's GPUs also cannot touch this with a single chip. Their dual chip 6990 has what looks like the same theoretical peak but far lower practical performance due to being more of a graphics part than a compute part (e.g. look at the cache structures).

You are correct that these are real cores, each with a wide vector unit. If we wanted the equivalent of GPU "cores" we should multiply out by the vector width per core.

The AMD 6990 has ~1.37TF double precision, but uses 2 GPU chips to do it, where this chip is that perf level.

It is difficult to get good performance out of the GPUs for a very wide range of highly parallel programs. Effectively, you are programming a part that is trying to give you mainly a graphics part, since that is where the volume is, with enough compute compromises to try to grow that market. MIC is designed to be a compute processor from the get go. How about this for a difference: it can boot linux all on its own! You can ssh into it and run programs. You can even run 'reverse offload' programs that call out to code on the CPU! Trying doing any of that with a GPU.

BTW, this MIC chip has a large number of cores (50+), these are real cores, and they're not doing the GPU marketing trick of counting SIMD lanes as "cores". You could multiply 50+ * 16 to get the equivalent number of GPU "cores". Each core is cache coherent, with a decent memory hierarchy designed for compute. There's no graphics tax on here.

I have much more expectation that Intel can leverage their massive process advantage to keep MIC ahead on compute performance each generation. It'll be a relief to have compute parts rather than repurposed GPUs.

See my answer just above.

tl;dr no more or less than other silicon valley jobs I've had, but then again, I don't expect it to compare to the important stuff in life.

Hmm, I think it depends on what "meaningful" means. I don't mean to break out the Clintonisms but it depends on what you are looking for. I've worked in hardware product firms, software product firms, and trading firms.

Is it "meaningful" to spend my days figuring out ways to get more people to click on more adverts? Not really. Build a social network for dogs' left testicles? Not really. Squeeze another dollar out of the equity markets? Not really. Build a faster database? Build a web analytics tool so people can squeeze out a few more conversions? Take a few cycles out of a market data feed handler to lower latency for a trading algorithm? No, no, and nope.

Are there good side effects from the above? Sure, we can come up with examples. For finance, you can take a look at the tightening of spreads (e.g. hft tends to make spreads go to their minimum making trades cheaper for everyone). Or adding liquidity in regular conditions so when someone small like a retail user comes along to sell some stock they get a good price quickly (not always of course, I mean really, you expect smart teams to take obviously dumb trades in an illiquid market?). Or more rapid price discovery (i.e. if something is mispriced it tends to get arb'ed away pretty rapidly, so that is faster info dissemination).

Can it be fun? Sure. Is it more good for the world than bad? Yup, I think so. Is it /meaningful/? Is it bollocks.

None of the above is meaningful compared to other things in my life. Important things like my family and trying to leave the world a better place than I found it (e.g. I give to charity -- probably more than most will ever earn).

That, and I'm with Vonnegut. "We are here on Earth to fart around. Don't let anybody tell you any different.".

I agree there isn't a perception of them being an enjoyable place to work; I think that is more due to the fact that one isn't really encouraged to talk about it, and the most successful actively avoid the limelight! Now there are plenty of sweatshops out there, but there are also plenty of tech companies I wouldn't touch with a barge pool.

Many people, even at Google, will be writing coding that isn't The Product. Having spoken to people at such firms, and their competitors, there are plenty of dev jobs there that sound boring as all hell, alongside the fun ones.

Pushing money around does sound boring, just like "pushing web pages around" or "pushing 140 char messages around". yawn ;-) In the last 12 months I've worked on custom languages/compilers, custom databases, kernel hacking, oddball processors, little visualization hacks, and have a giant stack of as yet unreleased hardware piled up to experiment with. I get to program against millions of events per second with minimal latency, giant result data sets for batch work, and points on the spectrum in between. The data itself is finance related and it's fun to munge and experiment with trading algorithms on it.

So far I have, over time, swung between product companies and trading companies. Fun to be had on both sides, among many other places. Actually, one of the more surprising things I've learned over time is how little most programmers realize about the variety of fun things out there. And how conservative and fad following most programmers are, funnily enough.

A /lot/ depends on the fund. I know some that are extremely tech focused as it makes the difference between profitable and not.

CS/STEM. Need not be Ivy League but it certainly doesn't hurt-- though I know a team or two in the top tier that almost have a preference for non-ivy league :-)

To be a quantdev or quant, an MFE is far more useful than an MBA.

This is certainly true (I've worked both sides of the fence in terms of types of firm).

To add a generalization, my rule of thumb is the variable part of compensation varies most for the domain experts. So in technology for the sake of technology style companies like Google, total comp shoots up based on stock/bonuses. In reality, Google is an advertising company so presumably the ad sales folks bringing in whales aren't hurting either. Naturally numbers get skewed by overpaying to keep certain people (i.e. overshoot on retention packages), and given large scale, there are always some overpaid due to lucky timing/placing. Such is life! In hedge funds, the traders get the big bonuses, but the programmers get a solid salary so lower bonuses don't hurt quite so much. Luck also plays a part for those folks var comp. For those in hft, I'm aware of a few places where given the right mix of skills, someone who likes to think of themselves as a programmer can get the trader style bonuses.

Yes; it's a properly server oriented processor, with ECC, fast interconnect, large cache, etc.

You can get details on the underlying server architecture from Calxeda's pages describing the system on chip, and the quad server boards that are in the initial HP design:

http://calxeda.com/products

In haskell you could write something like this: parMap rseq (\x->/some long computation/) [1..4]

using the standard Control.Parallel.Strategies library (use rwhnf instead of rseq unless you are using v3).

Granted, but it can make sense at even smaller scale. Say 8 servers. Or, I know one group of folks that were tempted by a beefier database machine and instead happily moved to such an appliance. There's a lot of ways to spend dollars that makes sense depending on what you are trying to do. (Trading dev cycles off against hardware etc).

Personally, I don't use the appliances because for our extremely latency-sensitive apps we do it all from scratch for various reasons. For large scale storage we build off commodity machines. One of our prototypes runs very happily off machines from scalableinformatics.com - highly recommended.

Horses for courses and all that..

Well lets say you are operating at small scale and you can reduce your 32 servers sucking 20 kilowatts to 4 appliances sucking 5kW. Much reduced footprint, power cost, admin cost (at small scale your per server cost is going to be higher than the large scale guys). Plus someone else will have done the integration and tuning work.

I think even on a small scale, or perhaps that should be especially on a small scale, people could profitably look at the mysql/nosql/memcached (the latter optionally with persistence via flash) from some of the appliance vendors.

I have no financial interest or direct experience, but the data sheet on this:

http://www.schoonerinfotech.com/datasheets/Schooner_DS_Memca...

looks worthy of a closer read.

For a fleet of "scale-down" servers to be practical the first problem is that the admin cost per server must be very low. With, ohhh guesstimate 70,000+ servers, Facebook presumably has that metric under control.

Next, certain types of workloads don't make sense. Anything CPU-bound or poorly scalable (eg. traditional database workloads). Again FB should have plenty of work that scales out relatively effortlessly (note the relatively) and have moderate memory and bandwidth requirements per process. Though in the aggregate you'd expect very large usage of both!

For suitable workloads, working back of the envelope, ARM will hopefully lead to some highly competitive, if not new record, scores on metrics like requests/joule or requests/$. Enery consumption and server cost being important at that scale..

Now for the in-memory caching or database workloads, which want either more memory or faster CPUs, Flash can be used to address capacity at the cost of a couple of orders of magnitude extra latency - albeit a couple less than hitting disk. Back of the envelope, anything that looks too much like a traditional database workload I'd leave on grunty x86 machines. Ditto for any CPU-bound.

So, lets speculate on how to build a machine based on ARM for the types of workloads we care about. Lets assume we don't design a new core but work with a vendor on a System-on-Chip using ARM hard macros. This is very back of the envelope and we'd need to break out spreadsheets to get this nailed down right.. but lets have some fun..

Our hypothetical SoC would be

. Cache-coherent quad-core Cortex A-9 @ 2GHz . PCIe interface on chip . 1Gb ethernet interface on chip . SATA ports on chip . Memory controller

connected to 4GB ECC memory per server. I'll get back to storage.

Now, this should be small and quite low power server. Within a 1U sled we should be able to pack say 6 or perhaps 8 of these, along with dual power supplies (for the entire sled of machines). If possible I'd have distributed power redundancy by including a battery in the sled rather than hooking up to external UPS.

I'd use an internal 1Gb switch which itself is connected to the top of rack switch. We get local cheap communication between the servers, plus we make cabling significantly easier and keep the cost of the top-of-rack switch down. A more whacky alternative would be to use short-range radio. Fewer wires, potentially more bandwidth, but something I'd like to hammer on in the lab before going anywhere near the datacenter.

Now, for the pesky 4GB per server memory limit and storage. We have a few interesting options. We can add flash per server, or, given the $/GB perhaps one machine in the sled gets it and acts as a local memcached server with the ability to fall back to accessing remote ones. We could also have a local file server with, for example, 1TB of storage via 2 flash-augmented disks (eg. seagate momentus xt disks). With good staging of data, we could even make this sled a good building block for throughput-oriented data-intensive work (eg. mapreduce type work). We have lower IO bandwidth but we've also kept the CPU performance down to levels where we have a fighting chance of feeding them.

Obviously, you need your software to run there. Chalk one up for relatively easily ported open source code without being dependent on a slow-moving vendor.

The above is rampant speculation and there are many interesting design points - it's great to see someone trying new things and taking advantage of changing hardware ratios to profit.

Well just in case you wanna cry into your beer over that font - you can get it here for old times sake.

http://www.aplusdev.org/Download/x11fonts.tar.gz

True - joel kaplan's group in FID was the source iirc.

Historically there has been some truly awful code, no doubt, and much still being written.

There is a growing breed of trader though who can code well. Coding well in a variety of languages is becoming a basic skill along with advanced math & stats for certain types of trading jobs.

APL isn't all that weird once you spend a little time with it. It's "just" a dynamically typed collection-oriented language. I think people look at some screenshots, make a stupid joke since they aren't familiar with the notation, and move on rather than digging in. I highly recommend Dyalog's dialect for a comfortable IDE, OO support, .NET support for GUIs on Windows etc.

For MS' APL dialect, you can get the whole thing from: http://www.aplusdev.org/

My understanding is that they still have many many lines of code written in this language running. They also use a commercial intellectual successor of this language called q from kx systems. Many other firms do as well, but I won't name them since I don't know which ones are public about it.

I'm pretty sure that the firms I know creating new languages are not public about it, but there are at least 3 very very large ones doing so. Aiming for a functional flavor, large-scale parallelism, streaming, low-latency processing of large data sets, high-quality compilation and leveraging new hardware are common themes.

There's a long history of using alternative in-house languages at Wall St. firms (and new ones are being developed at a few large firms I know).