Hacker Newsnew | past | comments | ask | show | jobs | submit | jakobson14's commentslogin

apple: "Out latest laptop has <magic maguffin>!"

consumer, at the store: "why doesn't this thing have <magic maguffin>!? bring me something that has <magic maguffin>!!!"


Intel has spent the last 25 years training consumers to look for the "intel inside" sticker. It's the only thing that's kept intel afloat while they butcher their engineering tallent.

People shouldn't care, but they do.


Guy is an employee of raspi, so of course he's going to write code that ships chips.


No there isn't. Let's take pytorch as an example.

CUDA is an API. OpenCL is an API. Pytorch is not.

Pytorch is very firmly GLUED to CUDA. It will probably NEVER support anything else beyond token inference on mobile devices. The only reason Pytorch supports AMD at all is because of AMD's "I can't beleive it's not CUDA" HIP translation layer.

OpenCL is a real cross-platform API and with 3.0 it's finally "good" and coincidentally, intel is....half-heartedly interested in it, except they're shooting themselves in the foot by trying to also cover useless CPUs for inference/training and spreading themselves too thin (OneAPI). Because all intel can think about are CPUs. Everything must drive sales of CPUs.

At this rate just about the only think that might save us from CUDA is rusticl. If a real, full-fat, high-quality openCL 3.0 driver sudently popped into existence on every GPU platform under the sun, maybe pytorch et al could finally be convinced to give a shit about an API other than CUDA.


They are only moving because AMD is finally providing that competition, but it's not fair to say that "if only AMD had gotten their act together sooner, intel would be a better comapny."

Ultimately, intel chose to let intel rot while AMD was out of the picture. (ignoring that intel's backroom deals with Dell and co. are a big part of what pushed AMD out)


AMD and ARM-based solutions too. I can't picture wanting to run Windows on ARM for a few product generations but for server use I'd have no problem w/ Linux on ARM.


ultimately it was a focus on marketing that led them to kill engineering

(if itanium and the many failures and lucky breaks that led up to it hadn't already convinced you that intel might never have had good engineering)


Intel tried to get away from x86 over and over again with radically overengineered architectures that didn't work (as well as mainstream architectures) and failed:

https://en.wikipedia.org/wiki/Intel_iAPX_432

https://en.wikipedia.org/wiki/Intel_i860

https://en.wikipedia.org/wiki/Itanium


Honestly, they'd probably be better off if they ditched all the sed/awk/macro BS and just went back to bash scripts (or perl/TCL, if you don't like weird syntax issues) that spat out C code. Rust saw the writing on the wall and implemented proc macros.

Stop using tiny hammers and get a big one.


Continue forever? no. Be performed once at no cost? maybe.

I'm kinda sceptical that a computation to which the 2nd law is indifferent would occur spontaneously without immediately reversing. The 2nd law is what determines the direction that things typically progress.


Congratulations on supplementing one impossible thing we can't do yet with three more.

There are very good reasons these artificial hearts are strictly temporary while waiting for a donor.


The heart is massively more efficient. Just about everything in all of biology is massively more efficient.

Take a moment to consider that your entire body runs on an energy budget of only around 100 watts, of which your brain only uses a measly 20 watts.


Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: