slizard

The real problem starts with the idea/wording of "one / two income family". It trivializes the issue and is likely rooted in the dated "housewife" concept that forces people into a permanent role, dependence, and general lack of choice, a social structure that really needs reform (and has been to a great extent in many countries).

Why can't parents work (earn) and take care of their kids at the same time? Why assign a (permanent) role of stay-at-home-parent to essentially half of the adults (with children) risking unnecessarily trapping them in roles and financial state that's unfair.

Support for a lot of the statements can be found in the refs of this Science VS podcast episode [1] which, in its 3rd part, deals specifically with the environmental impact of organic farming.

[1] https://gimletmedia.com/episode/5-organic-food/

Note that this is biomedicine. I doubt many other fields will show wildly different trends, but some will likely have less grim trends (e.g. engineering sciences, computing).

The concept that a job gives meaning and structure to life, builds character, etc." is not sustainable in the future.

Related, interesting read: https://aeon.co/essays/what-if-jobs-are-not-the-solution-but...

> I don't understand why we expect people to be paid the same for less work.

Because the "standard" work week is an artificial construct that has arbitrary definition. Also because this is a way to bridge the gap between accepting universal income and re-evaluating what is the role and importance of work/job in the society.

Even if it is not found to be acceptable now (which might sadly turn out to be the case even in Sweden), at least when jobs start to dry out, people will realize that an intermediate solution to increasing unemployment is letting people work less -- hopefully for similar pay.

> But it's interesting to consider why HIP doesn't support compiling to OpenCL.

It's not HIP that will support compiling _to_ OpenCL, but rather the compiler toolchain will have an OpenCL compiler that will compile down to ISA [1], promised to be released for the ROCm stack in the coming weeks [2].

[1] https://www.phoronix.com/forums/forum/linux-graphics-x-org-d... [2] https://github.com/RadeonOpenCompute/ROCm/issues/30

> GM1XX is Maxwell 1st Gen, which was the 750ti, the Gefore 800M series, Tegra K1 and Tesla M10, GM2XX is Maxwell 2nd Gen.

My bad, forgot about 5.0 devices being called GM1xx. Still, AFAIR there was little practical difference (in particular instruction set) between all but the compute capability 5.3 Tegra.

> Maxwell wasn't 1/3 it was 1/32 (no this isn't a typo) ;) this is the same (or even worse IIRC it's 1/64 now) with Pascal with the exclusion of the GP100, the Pascal Titan and Quadro cards are 1/32 or 1/64.

I did not say Maxwell had 1/3 DP flop rate, I said Kepler had that, but Maxwell was pushed by the 28 nm process (so they had to get rid of all DP ALUs).

> As I said NVIDIA keeps this for very limited silicon if you buy a desktop/workstation GPU even with Pascal don't expect DP/HP performance.

Never disagreed, but they can only do that because their professional compute division has grown big enough that it it worth designing different silicon; that shift happened in fact after Kepler, GK110 was more or less the same on GeForce and Tesla (e.g. 780 Ti and K40). They're also trying to find a good way to do market segmentation and DP ALU die area is an obvious candidate to play with. Still, no HP on GP102/104 is a curious thing, especially as the Tesla P4/P40 that oficially target ML/DL would really need it. My bet is they won't "forget" HP on lower-end Volta; not all consumer chips will support it, but unless they'll design different dies for GV102/104 (or whatever they'll call the non-DP Tesla uarch), which I doubt, some desktop parts will also support it.

> Not sure if Maxwell came out of the blue, Maxwell 1 was designed for mobile, embedded and tesla, Maxwell 2 came out most likely because Pascal at large was delayed.

First off not sure what you are referring to by "Maxwell 1" and "Maxwell 2"; there's GM204, GM206, GM200 all very similar, and GM20B the slight outlier.

Maxwell was an arch tweak on Kepler which, due to everyone but Intel stuck at 28 nm, had to cut down on all but the gaming-essential stuff to deliver what the consumers expected (>1.5x gen-boost). For that reason, and because HPC has traditionally been thought to need DP, IIRC no public roadmap mentioned Maxwell Tesla at all. Instead, the GK210 (K80) was the attempt to be the bridge-gap chip for HPC until Pascal; it was released just a few months before the big GM200 consumer chips came out. That is until fall '15 when the late arriving M40 and M4 were pitched as "Deep learning accelerators" (though GRID/virtualization version were released a little earlier in August). Quite obvious naming, plus no sane HPC shop would buy a crippled (no DP) chip <1 year before the promised miracle-chip, Pascal was planned to be released. Let's not forget that P100 was known to be quite late, K80 was insufficient for the needs of many customers, so another bridge-gap was necessary, and that what the M Teslas were: bridge-gap ML/DL cards that Google/FB/Baidu and the like wanted, and picked up pretty quickly e.g. see [1].

> As for the half precision, it's pretty much the same thing NVIDIA been doing since Kepler dumping FP64 and FP16, especially FP16 due to the silicon costs.

Not really. In Kepler they experimented with the SP/DP balance a bit (1/3), in Maxwell they were pushed by 28 nm, in Pascal they returned to the DP = 1/2 SP throughput.

Also, FP16 is not completely separate silicone, AFAIK FP16 instructions are dual-issued on the SP hardware.

> NVIDIA came out with the Titan and Titan Black with baller FP16 performance and no one seem to care

Source? AFAIK earlier FP16 was only supported natively by textures and by some conversion instructions. First chip was the GM20X/Tegra X1 with native FP16.

> As for Google and Baidu while they are huge I'm not sure how "important" they are, Google can pretty much design their own hardware at this point,

Some hardware that allows large benefits, but definitely not all hardware. They're happily relying heavily on GPUs, are planning to pick up Power8+NVlink, etc. Designing chips is expensive, especially if there isn't a huge market to pay for it.

> and as you mentioned they don't really use the software ecosystem that much as they can write everything from scratch even the driver if need be.

Note that they "only" wrote the fronted and IR optimizer, the code generator is NVIDIA's NVPTX [3]!

To wrap up because this is getting long, to your last points I'd say the big DL players are very important for NVIDIA because they are the trendsetters leading in many aspects of AI/DNN research with OSS toolkits for GPUs, and they'd be silly to not use GPUs in-house for their own needs which they're happy to talk about at various conferences and trade shows (e.g. both keynotes GTC 2015 [3] [4]).

[1] http://arstechnica.com/information-technology/2015/12/facebo... [2] http://llvm.org/devmtg/2015-10/slides/Wu-OptimizingLLVMforGP... [3] http://www.ustream.tv/recorded/60071572 [4] http://www.ustream.tv/recorded/60071572

NVIDIA is playing catch-up with themselves and the shifting market too!

Just look at the Maxwell-based Tesla cards that came out of the blue (as if they were an afterthought); I bet Facebook, Baidu, Google, etc. told NVIDIA that Kepler was shit for their use-cases and they did not want to wait for Pascal.

Or look at the bizarre Pascal product line where the GP100 does support half precision, but the others don't, not even the P4 or P40. Strange, isn't it?

Things are changing so quickly that it isn't hard at all to find footing as long as you have something useful to offer. At the same time, I agree, a robust software stack is an advantage, but for the likes of Google or Baidu even that is not so big of a deal (Google wrote their own CUDA compiler!).

It's clearly indicated on the slide that those are Deepbench [1] GEMM and GEMM-convolution numbers. Data for M40, TITAN Maxwell/Pascal and Intel KNL is actually provided by Baidu in their Github repo.

[1] https://github.com/baidu-research/DeepBench

> So it's a headless passively cooled server version of the R9 Fury X? I figured this was a faster and improved version.

Almost. My guess is R9 Nano [1] given the same 8.2 Tflops (SP) Flop rate [2].

[1] http://www.anandtech.com/show/9621/the-amd-radeon-r9-nano-re... [2] http://images.anandtech.com/doci/10905/AMD%20Radeon%20Instin...

> Not sure if AMD is going to go all HBM on all it's high performance GPUs in 2017, or only offer one or two models with it.

It would make perfect sense to have some GDDR5X-based medium-range GPUs. HBM2 will be expensive, too expensive for the top of the medium range (and the same applies for NVIDIA). GDDR5X has plenty of room for improvement over GDDR5 and by next year they should have it figured out better.

The tricky, but fun parts. It's certainly not trivial to port those, but I'm not too worried about it as long as there is solid runtime support in ROCm. More fun work for perf engineers like me. ;)

Massive amount of boilerplate, heavy APIs or crappy software stack are more dangerous IMO than having to drop in replacements for NVIDIA-specific optimizations of GPU-to-NIC or GPU-to-GPU communication.

The ML/deep learning technologies are peaking or will peak in the coming years on the hype curve [1], so it is not too late for AMD to join the show, there is plenty of newcomers and growing entities to buy hardware. So even though the CUDA ecosystem is far more established, let's not forget how much room for growth there is under an exponential growth curve!

Even Intel is late to the game (and so far can't even compete with AMD in terms of hardware).

[1] https://www.gartner.com/newsroom/id/3412017

> can't interop the "operational" CUDA features

What exactly do you that mean?

What's particularly interesting here is that the Fiji card they propose is a very different beast than any of the NVIDIA offerings.

The MI8 card's HBM has a great power and performance advantage (512 GB/s peak bandwidth) even if it's on 28 nm. NVIDIA has nothing that has even remotely comparable bandwidth in this price/perf/TDP regime. None of the NVIDIA GP10[24] Teslas have GDDR5X -- not to surprising given that it was rushed to marked, riddled with issues, and barely faster than GDDR5. Hence, the P4 has only 192 Gb/s peak BW; while the P40 does have 346 GB/s peak, it is far higher TDP, different form factor and not intended for cramming in into custom servers.

[I don't work in the field, but] To the best of my knowledge inference is often memory bound (AFAIK GEMV-intensive so low flops/byte), so the Fiji card should be pretty good at inference. In such use-cases GP102 can't compete in bandwidth. So the MI8 with 1.5 the Flop rate, 2.5x bandwidth and likely ~2x higher TDP (possibly configurable like the P4) offers an interesting architectural balance which might very well be quite appealing for certain memory-bound use-cases -- unless of course the same cases are also need large memory.

Update: should have looked closer at the benchmarks in the announcement; in particular the MIOpen benchmarks [1] MI8 clearly beating even TitanX-Pascal which has higher BW than the P40 indicates that this card will be pretty good for latency-sensitive inference as long as stuff fits in 4 GB.

[1] http://images.anandtech.com/doci/10905/AMD%20Radeon%20Instin...

Additionally, here's an example of how Caffe was porting using HIP [1]. To be honest, if the approach really does work, you might see a very quick increase in the number of applications ported.

All in all, given how elegant HIP is and that HCC seems to make GPUs more approachable than CUDA (and less silly than OpenACC), there is a great potential for AMD to gain some traction. My greatest concern is the quality and robustness of their software stack, their overly optimistic view (at least from the outside), and their relationship with the rest of the OSS world, especially given the conflicts that they seems to be running into with upstream contrib [2].

[1] https://www.youtube.com/watch?v=I7AfQ730Zwc [2] https://news.ycombinator.com/item?id=13136426

Preemptive move to avoid having to work with Trump and friends? Or perhaps the Clinton investigation's side-effects affected him (rather than Comey)?

Admittedly wild guesses and I'm not very familiar with the, politics and internals of the US intelligence, but the timing is quite interesting!

The excitement comes from the fact that some workloads benefit greatly from GPUs -- mostly those where the GPU arch offers some niche-advantage that can give GPUs >=10x perf[/W]. A good example is deep learning where Intel is struggling to compete [1], and even in linear algebra there is a 4-5x power efficiency difference [2, slide 6].

At the same time, in many other complex applications the performance/W/$ advantage has not been all that clear, especially since GPUs have been quite behind in process technology. A good example is a simulation code I work on where a 2-4x speedup from GPUs, which (due to inherent overhead of using accelerators) gradually vanishes in strong scaling, means that when price is considered, only cheap consumer cards can imrpove the performance/buck metric significantly (that's time-to-solution/buck in our case), professional cards don't offer significant significant improvements other than performance density [3, figures 6,7].

There are plenty more examples that NVIDIA collects [4], but always take the claims with a grain of salt, especially the ones with "incredible" >10x speedup claims :)

Last, I'd note that with the recent 14-16nm jump, the gap between the traditional CPUs and the simpler accelerator architectures has increased (I've just seen MAGMA BLAS on Tesla P100 results which show >10x GFlops/W, more than double that of the previous arch) and I expect it to keep increasing partly due to the manufacturing/process technology gap shrinking between Intel and the rest and partly due to architecture and programmability improvements of accelerators.

[1] https://www.nvidia.com/object/gpu-accelerated-applications-t... [2] http://on-demand.gputechconf.com/gtc/2015/presentation/S5476... [3] https://www.academia.edu/13753737/Best_bang_for_your_buck_GP... [4] https://www.nvidia.com/object/gpu-applications.html

Thanks for the explanation, that's what I guessed -- which has both good & bad aspects. The good is the flexibility, the bad is that:

> If those bytes happen to be Debian 8 with some AMD driver that supports the 9300, awesome ;).

happens to support might alone not be enough given how much difficulties AMD has been having. I just hope that there will be enough customer demand for their SPFlop cruncher GPUs for interested parties -- including Google -- to pitch and contribute to their ROCm stack.

Kudos for Google and happy to see that at least in principle AMD is still an option.

I wonder what kind of device driver does GCE use with AMD, the new ROCm?

What about Power8 + NVLink harware? Does anybody know if the current NVIDIA GPUs, in particular the P100s are all on x86?

Still no OpenCL, still only promised as a "preview" for mid Dec.

I'm still very worried that AMD will fail, not because of the hardware, but due to their lacking software stack.

I'd be curious how did they install the 124 4U servers that pull >3kW each. Certainly not 9-10 of them per rack, that would be hard to power in standard racks let alone cooling them. Maybe instead of wasting half a rack, they interleaved the DGX-1 something like 3-4:1 with the other machines they have?

Will it blend?

One might argue that it's clickbait, but the original title does not claim anything that's particularly nonsensical. All that it claimed was that a data-breach affecting Telegram users (considerable number of) has been identified.

If they rely to a great extent on an unsafe protocol which ultimately leads to the theft of sensitive data, that does represent a problem _within_ Telegram, doesn't it?

What about benchmarks and performance updates/regression/etc.? I'm sure the CUDA to OCL switch was a preformance hit at least in some cases (and compared to the equivalent CUDA code). Has anybody worked on something comprehensive?

Would be good to convince he Phoronix guy to add it to his standard set of OpenCL benchmarks. He has the hardware and a good benchmarking/reporting tool, but somebody will need to pester him to do the benchmarks right.

Good launch pace, if they keep it up, they'll surely build up a positive reputation quickly.

Good idea, but good lucking finding wide enough support for it. I think national and commercial interest will fight fiercely to keep the event moving because otherwise how would they "keep fostering investment" (producing lots of waste)?

I'm glad this came out. Now there should be more concrete information to use in lobbying against these nasty deals WIP.