Pressed the button to show the full article and was greeted with a full screen demand to download their stock news app.

> Welcome to Seeking Alpha, please complete your setup with our FREE app

Do the metrics really say that these approaches gain more users than they lose?

That and breaking the article into 6 pages. If NYT, WaPo, and Medium can fit longform text into one page this site can too.

You can't measure lost users, only installs. 1 > 0 so it's inevitable to show an increased number of installs with popup vs without.

You can with A/B testing though?

I get a popup for "Register for FREE to finish reading this article" when trying to go beyond page 2 (I didn't).

Maybe they had this switched off but just switched it on when they submitted their website to HN?

Here’s the tl;dr:

On the server, AMD is making a security play w/ EPYC arch.

- AMD not vulnerable to Meltdown

- SEV allows encryption of a VM’s memory, further mitigating read attacks

On the consumer side, AMD is selling on-package Vega to Intel. This should increase market penetration, and thus get more games optimized for the AMD arch.

It claims that Meltdown can be used to read from other memory address spaces and break cross VM boundaries which is categorically false. Spectre v2 does allow you to execute intra VM and VM to host attacks Meltdown does not.

SeV will not help in this regard.

Games are already optimized for AMD GPUs and pretty darn well due to consoles I’m not entirely sure how much difference would the KBL-G provide considering that at least in the mobile space it’s going after the MX150 it needs 100W to compete with the 1050 so that would be on desktop only.

May be he meant docker instances? I heard that Meltdown allows one docker instance to access another one even without permission.

Don’t know what they meant but it surely doesn’t affect the serverless model or PASS/IASS nearly as bad as Spectre.

Spectre is also much much harder to mitigate against Meltdown sucked but it was easily fixed and it will also be easily fixed in silicon Spectre especially variant 1 will be with us for a long time and no one knows what still is lying hidden.

AMDs main advantage is that none of the researchers really bothered reversing their branch predictor so none of the BP training reliant PoCs work on their hardware but there is nothing in their design that mitigates against Spectre specifically.

And judging by the guide they’ve released for how to manage branch prediction post Spectre at least the technical team is worried about what would happen when someone starts paying attention to them.

Apparently their branch predictor doesn't alias the branch addresses, so it's much more difficult to "train" it in the fashion necessary for Spectre.

This would also be a pretty straightforward mitigation for Intel, so the whole "they need to redesign the whole core from the ground up!" thing may be a bit overblown. Cache behavior will need to change a bit, for sure, but we probably don't need to smash the looms and go back to using non-speculative ARM cores.

I tend to think AMD probably has some vulns lurking in their uarch as well, the difference is that Intel has a massive amount of marketshare in the server world and their hardware gets shaken down first as a result. I'm just a random internet nobody but Anders Fogh said the same thing in an interview with Gamers Nexus: Spectre is not much less severe for AMD than Intel, these are the opening shots of a whole new class of attacks and there are more to come now that we are looking for them.

> SEV allows encryption of a VM’s memory, further mitigating read attacks

This is incorrect. Spectre works at a cache level, memory is decrypted by that point - if it were encrypted you couldn't use it for the good kind of speculation either. This means SEV doesn't do anything in particular here, effectively the victim is decrypting its RAM for you.

The point of SEV is to make memory inaccessible after shutdown, whether that's physical (cold boot attacks) or virtual (VM instances reusing host memory). Not for Spectre.

Vega M ( On package Vega ). I dont understand how this will work.

Let say AMD makes a profit on their Vega Chip sold to Intel.

Intel will now have to sell this CPU+Vega chip ( Raw Cost ) @ Intel Margin.

So Intel either sell a very expensive package, or sell it at the same cost ( or slightly higher ) to customer as if they were to buy them separately, which hurts Intel margin. ( Because Intel earn less on Vega )

And it has been a long time Intel dont care about margin at all.

Contrary to how the article frames it, the play here is to starve Nvidia of oxygen by hitting their gaming business. Intel's biggest worry now is that they lose whole market segments to ARM-based systems with Nvidia GPUs. Nvidia has long had ambitions to own more of the platform, and there is a serious threat of them running away with the market by being the best at GPU performance and good enough everywhere else.

Intel has already made a move to rework their GPU development by effectively starting over(see: recruiting Raja Koduri to work in the same kind of leadership position he had at AMD previously while developing Vega). But they need a stopgap for the coming years, and this is one way to attack.

The Vega M package is a technically interesting product(size, integration, possible economies of scale), but it's primarily a win for market share because Intel can cram it down the throat of OEMs to stop them from using Nvidia. They would happily cut their margins to do so.

>They would happily cut their margins to do so.

Let hope they do.

Vega M GL/GH are a different die from Vega 56/64, if that's what you're implying here. It's smaller (yields decrease geometrically with size) and will be cheaper to produce, and Intel probably gets a reasonably good deal if they buy in bulk.

But yes, even still, Kaby-G is a very expensive part. I've heard ballpark like $500-600 for just the package. You can pretty much buy a whole Ryzen 2500U laptop for just that one item on the BOM. But it's also much faster - roughly 4x as fast as a 2500U.

Considering that Intel can pretty much raise the end price as much as they want and consumers will still make a bee line for it, I'd say Intels margin is secure here.

Customer, Could buy Intel Kaby + AMD GPU separately. So no, Intel' margin is not secure.

Yes. They say they're long AMD, and AMD is doing great right now, and should in the future.

AMP version without login required https://www.google.com/amp/s/seekingalpha.com/amp/article/41...

It un-amps itself when I load this.

Even the print trick doesn't work, it just prints the current page, so for a 6-page article you'd have to print 6 times (and each virtual page probably takes up 1 full paper page + 1 line of a 2nd paper page...). Although, who still prints articles anyway?

Guess whose article won't be read past page 1...

Firefox reader view.

I found it very surprising that the article didn't mention machine learning applications. Machine learning and scientific computing is where a company like NVIDIA really shines. The reason for this is CUDA. Nearly all deep learning frameworks, such as tensorflow, use CUDA to run on GPUs. Until AMD comes up with their version of CUDA, and convinces the authors of deep learning frameworks to support it, they will be behind. NVIDIA.

>"Until AMD comes up with their version of CUDA, and convinces the authors of deep learning frameworks to support it, they will be behind."

I agree AMD needs to do this badly, but don't think it will take much convincing as long as it works. You can read reddit/etc ml forums and see people are desperate for some alternative (AMD or otherwise) due to Nvidia's abuses of its monopoly.

I would definitely like to see more competition.

AMD has been working on CUDA for a while now, it's called HIP.

Here's Tensorflow for it: https://github.com/ROCmSoftwarePlatform/hiptensorflow

I have no experience so can't comment on how production-ready it is.

HIP is fine for very basic programs but you have always been able to convert those pretty trivially with find-and-replace.

The bigger problem has always been middleware. Effectively, HIP needs to duplicate everything that NVIDIA provides, 1:1, and it doesn't. More complex libraries (particularly ones that touch hardware features like texture units/etc) cannot be insta-converted with HIP either.

It's impractical, for the most part. I've always been of the opinion that what AMD needs is something like GPU Ocelot that can transpile PTX rather than working at a source level. Unfortunately I'm sure that would be legally frought for AMD.

I'm just getting started with machine learning and deep learning, so I'm certainly no expert. I wonder if building frameworks on top of OpenCL would be a viable alternative?

Sure. And like I said, for relatively trivial stuff you can almost do a find-and-replace of CUDA keywords with OpenCL keywords and get something that will run with relatively minimal tweaking.

The problem is the middleware - i.e. when you go to write a program, you want to write your financial simulation or whatever, not a RNG library. Once that stuff gets written, OpenCL will be perfectly viable. It's just sort of a slog now, vs a huge amount of stuff available for CUDA, both from NVIDIA and from others.

Another, more general problem is that OpenCL is not really a GPGPU language, it's a general framework for dispatching tasks to heterogeneous processors. You can hypothetically use OpenCL to dispatch tasks to a FPGA or a DSP or anything else. This means there's a relatively silly amount of boilerplate compared to CUDA, which is stylistically annoying but not really complex. But in general it's also up to the vendor to implement their own SDK, compiler, etc, and there's no guarantee that what runs on one OpenCL platform will run on another. What is commonly referred to as "OpenCL" is actually the AMD APP SDK and the NVIDIA OpenCL SDK, which both implement their own version of parallel C++ dispatched according to the OpenCL function interface/semantics.

So in other words, OpenCL suffers from a bit of Architecture Astronaut syndrome. AMD solved the problem of making a framework that can dispatch tasks to any coprocessor that implements their interface, NVIDIA solved the problem of making a GPGPU language. As such, AMD sometimes struggles to fulfill the cross-platform promise of their language and suffers in conciseness.

For learning CUDA, I really like the Thrust language. You can write GPGPU programs that are literally 10 lines or less. It looks like regular C++ STL but you can execute it on the GPU. You can easily call __device__ functions using functors iterating across your dataset, or get raw_pointers into a device_vector and then pass them into a normal kernel launch, so there's a lot of flexibility there to tune stuff as you want to make it more complex.

http://docs.nvidia.com/cuda/thrust/index.html

For a non-trivial program, here's my master's thesis, which I did in Thrust. Not really machine learning but at least you can see what you're getting into.

https://github.com/pholvs/PandemicThrust

For AMD, there is supposedly an equivalent called "Bolt Framework" but I have not used it personally. As is customary for AMD's libraries, after release it was abandoned and it has not been updated in several years, best of luck.

https://hsa-libraries.github.io/Bolt/html/

https://github.com/HSA-Libraries/Bolt

Can anyone comment on mainline kernel drivers for an entire AMD based laptop? For example if you get a Thinkpad you get Intel CPU and GPU, but other parts like wifi and bluetooth are Intel too. All of these are covered by mainstream Linux kernel drivers.

(I'm thinking of years past when Broadcom wifi etc were a problem under Linux.)

I have a Kaveri era HP laptop (read: old). No issues with wifi. Fairly sure it had an Atheros chip which has amazing Linux support.

Note that if you don't make it to page 6, there is a disclaimer that the author is long AMD.