No Free Lunch for Intel MIC (or GPU’s) | Hacker News Reader

No Free Lunch for Intel MIC (or GPU’s)

blogs.nvidia.com

68 pointsajdecon22 comments

Thanks for posting this. I love to see hardware stuff on the front page, especially such a relevant topic.

I actually sat down with the director of a HPC shop a few months ago and discussed the MIC question.

He was hopeful, but said nearly everything about MIC isn't as mature as it needs to be to warrant adoption. His best case scenario was adopting MIC for his 2016 build.

I think this article is a bit off target. Yes, it's true that a simple recompile of an OpenMP app won't give you peak performance, but it's still nice to be able to do it as a starting point for incremental porting.

Furthermore, while OpenMP apps probably will have scaling issues at 50+ cores, I think the bigger issue that the article hardly mentions is the new wide vector unit in the MIC cores. That's where all the FLOPS happen, and it's a completely new instruction set. x86 is a sideshow. Apps will need to be rewritten for the vector unit to get anywhere near peak performance on MIC.

Since apps need to be rewritten anyway, what's the value of doing the simple recompile using OpenMP? It doesn't offer sufficient performance and it doesn't function as a template for the rewritten app.

The whole thing seems like a marketing-driven exercise in fake compatibility. Imagine a company with an old PalmOS app which needs to be ported to iPad if the company wants to stay relevant. They can't just wrap the Palm app inside an emulator and sell that -- it's just not good enough for a port because it doesn't leverage any of the new platform's strengths. That's pretty much what Intel is proposing.

I disagree that all apps need to be entirely rewritten. I think it would be perfectly reasonable to use an existing OpenMP app as a starting point, and it's likely that some parts would work fine. Even if the MIC chip runs some parts of the app slower than a Xeon would, it could still be worth running those parts on the MIC chip to avoid sending intermediate results through the PCIe bottleneck.

Nice try, Nvidia. This article is some fact and the rest FUD.

  "If you currently have access to MIC chips and have been testing
  real applications, I would love to hear from you"

The information that was used to judge Intel's solution was based only on press releases and not any practical working knowledge.

  "We can no longer reduce voltage in proportion to transistor size"

The "we" here refers to Nvidia, and not Intel, because Nvidia uses TSMC to fab their GPU chips.

  "there is no such thing as a “magic” compiler that will
  automatically parallelize your code"

That is funny because Nvidia's newest GPU design offloads scheduling decisions on to the compiler instead of handling it dynamically on-core.

So perhaps Nvidia is warming up the FUD machines because of their newest range of GPUs which focus on gaming at the expense of computing.

eg. the Double Precision FLOP/s is now less than 10% of the Single Precision FLOP/s performance

For GTX 680 the double precision is actually 1/24 of the single precision so it is closer to 4%. Pretty sad when comparing the performance to similar priced Radeon cards.

This is a silicon surface area trade off between gaming and number crunching. It's a decision, not a flaw.

It not a trade-off. Consumer and HPC GPUs are using the exact same silicon... Nvidia artificially cripples, in software/firmware, the double precision performance of consumer GPUs: http://forums.nvidia.com/index.php?showtopic=204025

Artificial crippling is a bad practice, which I dislike. However, note that the GPU mentioned in your link is a low-end device.

Sometimes (I don't know about this case) the low end CPU's and GPU's are chips that have manufacturing errors in them and don't pass full quality control checks. The defective parts of the chip are then disabled with microcode (or equivalent) and sold as low-end chips. That's a good practice, a lot better than simply throwing the slightly defective chips to waste.

Even the high end consumer GPUs are crippled. For example the GTX 580 is identical to the Tesla M2090 (both 512 shaders, same GF110 chip), but the first has only a fraction of the DP performance of the second. What I am telling you is a pretty well-known fact...

All of you who want inexpensive DP performance should look at AMD Radeon cards. AMD does not cripple any of its GPUs.

Yes, they have disabled parts because NVidia was having serious yield issues that generation and didn't have enough perfect chips to make a product line from them. If you want to be an AMD partisan, just say that NVidia cripples their cards because their silicon engineers aren't good enough to get acceptable chip yields without doing so.

No, they did not disable it because of yield issues... The double precision logic is there, on the consumer GTX line, not disabled. Nvidia just limits the rate of DP instructions per clock for merely differentiating it from the enterprise Tesla line. Even Nvidia admits doing so.

I hate that, but I guess it makes sense from a business perspective.

Oh, I thought you were talking about the fused off shader groups. Yeah, you're totally right about the DP stuff.

Your reply contains some weird non-sequiters. Nvidia is right on target when they say there is no "magic" autoparallelizing compiler. The autoparallelization they talk about, and the scheduling issues you talk about, are completely unrelated except that they both contain the word "compiler" :/

As for double-precision performance, it is also well known that the GTX 680 is only for consumers. The HPC version of Kepler is due later this year and I will not be surprised to see it offer much improve double precision performance compared to current Teslas. Intel MIC is not a consumer product, so it is unfair to compare it to consumer products like GTX 680.

The compiler comment is pretty strange for a company that is (or was) aggressively Pushing OpenACC [1].

[1] http://www.nvidia.com/object/openacc-gpu-directives.html

Not my area of expertise, so I'm sorry if this doesn't make much sense:

Wouldn't it possible to have a virtual machine that presents itself as a single CPU and distributes the job efficiently across the many cores that it is running on?

What you've described sounds like the existing hardware abstraction present in virtual machine monitors.

http://en.wikipedia.org/wiki/Hypervisor

In my very layman's opinion, this is a much different problem. Specifically the cost-benefit of discrete vs. MIC for calculations. HPC guys have tooled with it for a while trying to come up with a fast, yet cost effective method of crunching more data. Floating point acceleration specifically offers huge increases in speed for scientific modeling, but comes at a significant cost in terms of design, implementation and execution.

This NVIDIA fluff PR piece was trying to prove something to the effect of, "Don't use on-processor floating point, use our discrete solution!"

How would you distribute the work of a virtual machine? It has to execute instructions in sequence, just like a non-virtual machine. Any parallelism needs to be extracted at a much higher level of algorithmic abstraction, i.e. by a programmer.

Imagine trying to make a virtual machine that would rewrite any bubble sort as a quicksort. Parallelizing algorithms is much more difficult than even that.

But we are already able to extract parallelism deep down in the instruction level with out of order execution.

Imagine some layer in between an abstract syntax tree and micro-ops. Again, just thinking out loud.

We can extract a little bit of parallelism that way, but nothing even close to the scale of what a GPU does.

relevant: http://news.ycombinator.com/item?id=3816771

dont overlook the power of a brand. In this case its x86 which means brand intel, which is about as strong as it gets in Tech.

Alot of decisions are made by non-technical or are technical but lack the depth of understanding.

e.g. propose intel MIC vs Telira (similar thing but with MIPS cores)

Reply on news.ycombinator.com