slizard

AMD's new Boltzmann initiative includes an LLVM-based compiler which has been posted online. I'm not sure what are the plans around an OpenCL fronted, but the backend should be there, so I think an OpenCL support in LLVM for AMD GPUs could be a realistic goal.

http://gpuopen.com/compute-product/hcc-heterogeneous-compute... https://github.com/RadeonOpenCompute/hcc

Does anybody known whether they disclosed how sensitive was the information that they the intruder could have gotten hold of -- especially the passwords, were they stored XOR'd or encrypted+salted?

I take your point about FreeBSD's benefits, but we need to be realistic.

People want working devices/peripherals (admittedly, I'm not very familiar with the state of the drivers on FreeBSD today, but I know it has been an issue) and many prefer to be productive too rather than hack away at their OS. These OSes have moved out of the garage and are running a large part of this damn Internet :)

FreeBSD is certainly perfect for some niche uses but, I believe, it isn't realistic for many if not most GNU/Linux server uses today.

And that's where I'd come back to your initial point on Ubuntu's lacking server benefits: you may not see them, but many do, and for better or worse they vote with their choice. Even if many don't like it, let's be honest, many do benefit from it indirectly.

While the point about the different level of support of different repos is a good one and it does deserve more awareness, without the right context the claims of the article are easy to mis- or over-interpret.

I think a fair comparison would be to show other distros too rather than judge Ubuntu based on a single data-point.

For instance, a user stuck with ancient packages on CentOS may quickly reach out to alternative repos and pull in tons of packages with questionable security.

A large fraction of users seem to disagree! Ubuntu is the most popular server distro in the cloud, by far.

http://fossbytes.com/ubuntu-linux-is-the-most-popular-operat... https://duh6oa3w9hopv.cloudfront.net/uploads/pdfs/RightScale... etc.

The must be doing something right, but of course as quickly as they rose, they could loose the market equally quickly. I do see interesting directions, though: Ubuntu seems to be the default choice on OpenPOWER servers (at least for now) and it will likely be a strong contender; see e.g. https://www-03.ibm.com/press/us/en/pressrelease/47791.wss

One group that has certainly contributed and needs to be given credit is Debian!

Depends what you want to gain? You want to do scientific computing? Interested in mobile platforms? Or just curious about GPUs?

Without knowing the answer to that, I won't attempt to go into more details, but will give two examples: * If you want to have transferable knowledge (e.g. to be able to jump into mobile development on ARM), choose OpenCL. * If you're curious to learn and try stuff out mostly to get a taste of GPU computing, consider using CUDA (as it has better dev tools), but if you find it fun/useful, do consider switching to OpenCL.

> The main problem is OpenCL seems an order of magnitude more complex than CUDA.

Do you have any experience to back that up with? I've worked with both and I know that there are areas where your "order of magnitude" (which BTW I'd like to see on paper, quantified) does hold up, e.g. dev tools, but in general your claim is simply false.

> To be honest, Cuda seems semi-portable just because (according to documentation and tutorials I've read) you do little more than allocate memory, tag functions, write loops and the compiler figures out the rest.

Nonsense, you're likely confusing OpenACC with CUDA, the CUDA runtime API is in many cases considerably more simple than OpenCL, but it requires a compiler, and frankly often times is screams rushed design/implementation. In contrast, the CUDA driver API is quite similar to OpenCL.

...and BTW OpenACC is "open" only on paper and in fact it is a very divisive move that has created conflicts, polarized the community, and undermined collaboration between multiple parties (in particular with the OpenMP proponents).

> Also, the latest pdf-pamphlet of the Khronos Group on opencl 1.2 just says they're "exploring" an open source implementation of the spec, which doesn't encourage one to imagine the spec as available.

The latest spec is 2.0 FYI; can you explain my how on earth does one's imagination go astray so badly to believe that just because there is no reference implementation one would consider the spec "not available". Don't get me started with the examples of standards that exist without an official reference implementation.

> Edit: Researching this, it seems that the CUDA compiler actually has been integrated into clang/llvm. An open spec with open compiler seems as open as one can get with software - it only targets NVidia but you can just complain Linux was proprietary when it originally only targeted Intel.

BS. Show me the "open spec of CUDA". Even if one did exist, good luck trying to influence the design of it if you're not an big oil company, Google, Audi or GM. Also, try to use the CUDA name without having to pay a ton of money. And you seem to forget that the "open compiler" does not actually generate byte-code (that's done by the propritary JIT compiler) and even if did, you still nee NVIDIA's proprietary driver to run it.

> CUDA is designed to help NVidia to sell more chips so I don't see it as a big risk.

Don't you see it as a risk to marry your project to a proprietary API of a company that actively and intentionally cripples their implementation of the standard for no other apparent reason but to hold back progress of OpenCL and essentially ensure vendor lock-in and create a disadvantageous situation for competitors relying on the aforementioned standards?

> My bold guess is because there are more training machines run on Nviada GPUs as opposed to AMD's.

Likely not so bold. AMD GPUs are good, but a quite a bit more pain to program compared to NVIDIA with CUDA (OpenCL on NVIDIA is more or less useless).

While this is nice in that it sets the example (and provides publicity to bioarxiv) it's not a couple of Nobel laureates that post one out of dozen(s) of papers/year published that will make the real difference.

The system is aged and inefficient (some would even argue it's rotten) and IMO comprehensive changes are needed. Like racial or gender discrimination can't be addressed without changing the social rules people live by, the current academic system that's rather elitist, non-inclusive, discriminatory, often more biased and less fair than many think needs to change substantially.

Such change will be aided by important people setting examples (and often going back to their old ways). However more substantial change is needed on multiple levels, most importantly: academic leaders and funding agencies (run by the former) need to stop looking at who's who and how many Nature/Science/insert-your-fancy-journal papers does the person have. For instance, the culture of applying for grant money with work that's half done to maximize one's chances needs to stop and so should the over-emphasis of impressive and positive results.

Additionally, publishers exploiting everyone need to die out and as long as these researchers "go rogue" with a single paper (rather than for instance committing to publish 100% preprints and >75% open access), not much will change.

I think the comparison is still quite dangerous: possibly unfair, probably telling little about current hardware.

The power efficiency and core count has increased tremendously on Intel CPUs with Sandy Bridge first and late with Haswell. For the same TDP you easily get 8-12 HSW cores these days.

ARM CPUs have likely improved to a similar extent, but given that CPUs are getting "wider" and more sophisticated in terms of caches, power efficiency, etc. it is very hard to extrapolate from assessments made based on hardware that uses >5y old technology.

In the project I work on our style also requires block-parens. Sometimes it feels unnecessary, but it does make up in terms of consistency: it's easy to glance through the code and inspect the conditions only.

I got used to this quite a bit and these days if I write code outside the project I work on, I d sometimes omit the block-parens, but I always add extra indentation to ensure the condition is visually well-separated, e.g.:

  if (condition1 || condition2)    execute_foo1(with_bar);
  if (condition3)                  exectute_foo2();

Not sure if they fixed it in the meantime, but it work for me right now with client version 4.3.0.37.

The Boost-ed frequency depends on multiple factors, including the number of cores used, power consumption, current, temperature and even the type of instructions executed (e.g. AVX instructions trigger a drop in frequency on Xeon cores, not sure about Xeon D, though).

The boost levels are typically defined as "bins", i.e. the max clock if 1, 2, 3, etc. cores are active. Can't find Xeon-specific info, but this page shows some general information on the topic: https://www-ssl.intel.com/content/www/us/en/support/processo...

Apparently the judge is ordering Apple to essentially disable all features that prevent or slow down brute-forcing, updates and quotes here: https://www.techdirt.com/articles/20160216/17393733617/no-ju...

Performance/watt is improving greatly! Look at this plot [1] from about 2013 showing the theoretical perf/w of CPUs up to Ivy Bridge, and GPUs up to NVIDIA Kepler GK110 and AMD Hawaii XT. Since than both Intel with Haswell (and Skylake on Desktop) as well as NVIDIA Maxwell and AMD Fiji have improved tremendously

The same article [3] shows clearly [2] that max TDP has increased a bit.

[1] https://www.karlrupp.net/wp-content/uploads/2013/06/gflops-p...

[2] https://www.karlrupp.net/wp-content/uploads/2013/06/tdp.png

[3] https://www.karlrupp.net/2013/06/cpu-gpu-and-mic-hardware-ch...

Not just thermal reasons! For instance, keeping caches coherent across so many cores is a great challenge. That's what Intel was experimenting with on Knights Corner - and many think they screwed it up quite a bit - with the ring bus + L2 implementation. However, they did learn a lot and a very similar ring bus based cache coherence implementation works quite well on Xeons for up to 18C - although it's worth noting that for >8C there are actually two rings -, and it should work pretty well on "regular" Xeons for at least a couple of more generations. However, not unexpectedly, KNL is switching to a 2D mesh (see http://goo.gl/SE8pZV).

That may be true for simple operations on aligned buffers, and nice regular computation in general. Anything slightly complex will throw off the compiler and result in suboptimal performance in the best case, none or stupid vectorization the worst (and quite common) case.

How do I know? We have some experience with vectorization in the team I work in (www.gromacs.org), our code has support for at about 10-12 SIMD instruction sets ;)