Live data from Hacker News

CPU.fail

cpu.fail

11–20 of 33 posts

Re: CPU.fail

#12
Is it time to just write an X86 API on top of GPUs and get rid of CPUs? Seems like the shortcuts we've been taking to get sequential speed are all blowing up in our faces, and fixes aren't possible without huge performance regressions.

Re: CPU.fail

#14
post #12

Is it time to just write an X86 API on top of GPUs and get rid of CPUs? Seems like the shortcuts we've been taking to get sequential speed are all blowing up in our faces, and fixes aren't possible without huge performance regressions.

"Is it time to just write an X86 API on top of GPUs and get rid of CPUs?"

How many days are you willing to wait for your computer to boot?

GPUs aren't "better" that CPUs, they're different. Between the two, CPUs probably make better GPUs than GPUs make CPUs, but it's a tough call; neither of them are very good at the other!

Re: CPU.fail

#16
Submissions of lists, like this home page, lead to lowest-common-denominator discussions. People focus on what the list items have in common and its gravity prevents specific items from gaining liftoff. Specific discussions tend to go deeper than generic ones, so we're going to unmerge these threads and have a separate one for each major disclosure:

Zombieload: https://news.ycombinator.com/item?id=19911341

MDS: https://news.ycombinator.com/item?id=19911277

This will take several minutes, so if you see weird incongruities or disappearances, hold your fire.

Edit: Ok, I've done as much of this as I'm going to do. If you notice anything wrong, can you let us know at hn@ycombinator.com so we can fix it?

Re: CPU.fail

#17
post #15
post #9

The worst thing about heartbleed is that it introduced marketing into vulnerability disclosures :(.

How is that a bad thing?

It isn't. Some people just think "marketing" is the root of all evil, when done right, it's actually just effective communication.

Re: CPU.fail

#18
post #9

The worst thing about heartbleed is that it introduced marketing into vulnerability disclosures :(.

In some cases I agree, but these are very interesting attacks, and having a nice, informative landing page about it is very welcome.

Re: CPU.fail

#19
post #14
post #12

Is it time to just write an X86 API on top of GPUs and get rid of CPUs? Seems like the shortcuts we've been taking to get sequential speed are all blowing up in our faces, and fixes aren't possible without huge performance regressions.

"Is it time to just write an X86 API on top of GPUs and get rid of CPUs?" How many days are you willing to wait for your computer to boot? GPUs aren't "better" that CPUs, they're different . Between the two, CPUs probably make better GPUs than GPUs make CPUs, but it's a tough call; neither of them are very good at the other!

We've been building personal computers around GPUs for a long time now. The CPU based computer was kind of an oddball IBM "thing". Old MOS (nintendo, commodore) and ARM for example seem to have the CPU serve the GPU in most configurations I've seen.
Post reply on HN