slizard

Also the opposite can be true as well (>2x slower); e.g try to rely heavily on shuffle.

> It's always been 10-20% slower than CUDA and frankly NVIDIA doesn't have an incentive to make it faster than that.

Incorrect. Our kernels (GROMACS molecular simulation package) are 2-3x slower implemented in OpenCL vs CUDA.

> On the other hand, I believe Google is working on a CUDA compiler

They were. It's upstream clang by now.

I don't wish you the suffering vendor lock-in can cause after 10 years (hell, even less) of faithfully following the NVIDIA path, but... actually I do because that probably the best way to realize what's wrong with proprietary systems that pitch themselves as "de-facto" standards.

The point where you suggested that x86 PCs are "open systems" (listing it next to "Linux" of all things!) I realized that you don't get it. We are where we are with Intel ripping off the consumers and companies alike exactly because nobody realized that x86 is everything but open.

A similar mistake is about to happen, but luckily on the software side where losses can be cut quick and mistakes can be reversed easier -- though many will suffer when they have to reimplement their precious library from ground up because they did (or could) not take into account the fact that CUDA is as proprietary as it gets.

AMD has no CUDA compiler BTW. And CUDA is not a programming language FYI. ;)

> One problem with showering before cycling is that it takes me a long time to cool down/dry off after a shower.

Does it really have to? I'm sure you can avoid that by not using hot water (or even going with cold-ish) and not spending more than 3-5 minutes in the shower. Also you can turn off the water if washing your hear takes time. Seems simple to address.

While I have not been lucky enough to grow up "on the cycle", just a few years of commuting by bike all year around, I very much feel the same!

On the shittiest day at work, or the most stressful situation at home, there's been nothing better than getting on the bike and just taking a ride wherever I have to be or going for a spin without strong purpose. It allows me to clear my mind, forget about everything else, even if just for a half an hour.

Feeling the spring breeze or even the frosty winter air's bite on my face while pedaling down the street often puts a big smile on my face even at times where otherwise I'd surely not be smiling.

I hope people & politics in the USA (and countries with similarly screwed up infrastructure) realize soon that, on the long run, turning public space, roads and in general (sub)urban infrastructure into a space designated for cars and cars only/mostly rather than for people does on the long run have significant social, health, etc. effects that are not particularly beneficial.

I've no source to cite, but AFAIK similar observations have been made in multiple studies in countries where cycling has been/is becoming quite popular (e.g. Netherlands, Denmark, Sweden) and as far as I remember, they did control for many external factors in at least the Danish study I recall.

I know, vague hand-waving, but hopefully others can pitch in with data.

Very good point!

I commute bi bicycle all year round and admittedly I'm not the chilled kind, so I tend to get soaked (from inside out) quite often, especially if the temperature is >15 C. However, I hate commuting in full bike gear, so having a shower just before leaving has helped tremendously. So does washing in the regular bathroom at work the critical spots where odor develops first (i.e. armpit). All I need is a small towel and a spare t-shit/shirt in case if the ride was too much fun and couldn't keep the speed moderate :)

Oh yes, my biggest pain is that Firefox can't replace the webview browser, so I still get tracked and shown ads if I use the Google app or any other app with the in-app webview browser.

The key idea is already in the second sentence of TFA:

"The product was an unlikely pick for top technology investors, but they were drawn to the idea of an internet-connected device that transforms single-serving packets of chopped fruits and vegetables into a refreshing and healthy beverage."

Keywords: IoT, single-serving refill packs, healthy fuit & veg.

further details reveal that the thing will track you at every single use pinging the central servers. It has a kill-switch to refuse juicing when they don't think you should be juicing anymore (for now expired package, but hey, nothing prevents updated from refining the "feature").

Need I continue?

Overall, it's a product that just rides the hype of juicing and IoT, but it's at least as nasty as the !#@%!# cloudpets [1].

[1] https://arstechnica.com/security/2017/02/creepy-iot-teddy-be...

> Still, I would have very much liked to play around with the 'phi'.

Well, if you're still interested, KNL is a significantly better architecture, so you could just try now.

> That's the kind of deal I was looking at too. Maybe they were massively discounted because they were already EOL'd?

Refreshed my memory and I was wrong; there was some discussion to jump on the $125-$195/card deal Colfax had late 2014 [1] (likely dumping stock due to EOL), but we figured that they are not even worth that much. In comparison, the one card we have was actually bought just 10-11 months before for ~$1500.

[1] http://www.colfax-intl.com/nd/xeonphi/31s1p-promo.aspx

> The inconvenient part of XXX are the false positives when searching.

Would you mind elaborating what kind of source code contains numerous triplets of the uppercase character "X" and why?

I have never seen such code other than produced by extremely inexperienced programmers/students with no imagination to naming symbols and ending up with "x", "xx", "xxx" variable names; even those cases will most likely not be all uppercase.

> ...but actually getting one has so far proved to be impossible.

Where/when did you try buying? I didn't think it was difficult to get the 1st-gen Phi cards while they were selling them -- especially as it seemed like nobody wanted them. Admittedly I never bought any myself, my employer picked up some 31S1P from a local server OEM for testing when they were massively discounted.

Note that the Knights Landing, the current generation is released socketed only for now, so you'd need to buy a server or the ninja dev platforms Intel sells through Colfax.

Pre-, during, or post-burnout?

> Do not mix & match consumer-rated gear with 'professional' gear. (i.e. If you put the K80 in a system with a GTX1080, then the Nvidia drivers restrict the number of available processing cores to 2 per device)

Huh? Not sure what exactly do you mean by "number of processing cores"?

I use two development boxes on a regular basis with Teslas side-by-side with GeForce cards and they all work just fine.

It's a pity they omitted comparing against the Maxwell-gen GPUs like the M40/M4. Those were out already in late 2015 and are also on 28 nm.

Perhaps the reason is simply that they don't have them in their servers, but we'll see if Jeff Dean replies on G+ [1].

[1] https://plus.google.com/+JeffDean/posts/4n3rBF5utFQ?cfem=1

I don't think there's anything illegal in ove-promising and severely under-delivering. Also, given the long delay of the 1st gen product release Intel's massive PR and marketing machinery had plenty of time to rewire many if not most people's expectations. Doesn't have the endurance and the orders of magnitude performance advantage promised? Just focus QD1 performance, feed 3-5-10x instead to the media for long enough, over-provision to be able to deliver an OK consumer product and keep everyone's hopes up that revolution will come "soon".

People have short memory (even tech journalists), especially when there is not enough competition.

Partly it is just marketing fluff, Intel trying to save their face and hoping that most will not remember the promises of revolutionary product while what they released is barely evolutionary.

Can't find a better article right now than this SEmiaccurate rant [1] which is quite inflammatory, but does not push falsehoods AFAICT. But Intel has essentially walked back from the 100-1000x improvements it initially claimed to something that's barely better than NVMe in terms of performance and robustness seems far from initial claims too.

[1] https://semiaccurate.com/2017/03/10/intel-mislead-press-xpoi...

The article extends on the previous articles and claims made by SA, most recently this one discussed in another HN thread: https://news.ycombinator.com/item?id=12562856

Definitely curious to see if Intel will indeed fail as spectacularly as predicted. Given the underwhelming feeling one's left with seeing the backpedaling on the performance claims, this could be yet another example of crappy/barely usable 1st-gen products, usable 2nd gen.

Hypothetical or real? If real, link to source please.

Sadly these gen-1 ThunderX cores are pretty poor in performance and not particularly power-efficient either. Cache performance is especially sucky. https://www.servethehome.com/exclusive-first-cavium-thunderx... http://www.anandtech.com/show/10353/investigating-cavium-thu...

I hope that this is just a rebranded system showing the redyness of System76 and raising awareness about such products so that they're better positioned for the ThunderX2 release later this year.

The CPU has 24 lanes and the chipset can add up to 8 additional lanes, see [1] first table.

It's a pity that they did not include at least 32 lanes on-chip to allow two full x16 GPUs at least on the 1800X, but I hope there is a 1900X in the pipeline with more lanes.

[1] https://arstechnica.com/gadgets/2017/03/amd-ryzen-review/

FTFY: some major parallel workloads are done on the GPU anyway, so parallel work on CPUs is often still relevant. ;)

If you end up buying high TDP chip, you can simply cap the clock either in BIOS or in kernel to save power.

> On all those benchmarks, (i.e. your standard LU matrix decomposition which previously was the basis of the LAPACK benchmarks, though things might have changed in the ~10 years since I've really looked at things) isn't CPU-bound anymore, so of course your instruction-per-cycle load on the CPU isn't where you'll be bottlenecking [...]

That's incorrect, DGEMM and most BLAS3 is way above most if not all processor uarch's aritmetic intensity threshold [1]. Broadwell CPUs are at 10 Flops/byte [1] while e.g. DGEMM is 32 Flops/byte [2], so that's definitely FLOP/instruction bound and not memory.

> Your processor can very easily anticipate from where in that sparse-matrix your next data fetch is going to be. It's the cost of that RAM fetch[1] going along that copper trace which is going to be where you're going to bottleneck on any heavy numerical computation.

You're mixing things up, it seems! LAPACK/BLAS is dense matrix, not sparse, so now you switched topics. Sparse matrix ops are generally >1 Flops/byte (see [2]), so that's indeed memory bound.

[1] https://www.karlrupp.net/wp-content/uploads/2013/06/flop-per... [2] http://www.siam.org/pdf/news/2090.pdf

Sure, in this particular file every year in the interval is listed, but in a large codebase that's not always the case. Always listing every year keeps things simple, consistent, avoids complications around extra statement and clauses, and makes auto-generating headers easier.

This is why: "For software with several releases over multiple years, it's okay to use a range (“2008-2010”) instead of listing individual years (“2008, 2009, 2010”) if and only if every year in the range, inclusive, really is a “copyrightable” year that would be listed individually; and you make an explicit statement in your documentation about this usage."

Source: https://www.gnu.org/licenses/gpl-howto.en.html

Harder in what sense? There is nothing (or very little) that makes OpenCL significantly harder by nature!

OpenCL developer tools and libraries are however a disadvantage compared to NVIDIA's CUDA stack. That's partly thanks to AMD's rather poor tools (I still hope that their OSS initiative might change that). Intel's half-assed attitude towards OpenCL support didn't help either. Most importantly, NVIDIA's attitude of intentionally crippling OpenCL on their hardware by providing piss poor dev tools, only v1.2 support, no extensions that would allow making use of their hardware's features etc. has surely contributed to successful​ly holding back the adoption of the OpenCL standard.

I hope the community wakes up sooner rather than later.