Most active commenters
  • hajile(3)

←back to thread

499 points baal80spam | 28 comments | | HN request time: 0.001s | source | bottom
Show context
gautamcgoel ◴[] No.42055008[source]
Damn, first Intel missed out on Mobile, then it fumbled AI, and now it's being seriously challenged on its home turf. Pat has his work cut out for him.
replies(6): >>42055079 #>>42055125 #>>42055190 #>>42055260 #>>42055329 #>>42057153 #
kevin_thibedeau ◴[] No.42055329[source]
They didn't miss out. They owned the most desirable mobile platform in StrongARM and cast it aside. They are the footgun masters.
replies(4): >>42055469 #>>42055486 #>>42056360 #>>42057167 #
1. hajile ◴[] No.42055486[source]
They killed StrongARM because they believed the x86 Atom design could compete. Turns out that it couldn't and most of the phones with it weren't that great.

Intel should be focused on an x86+RISC-V hybrid chip design where they can control an upcoming ecosystem while also offering a migration path for businesses that will pay the bills for decades to come.

replies(5): >>42055656 #>>42055769 #>>42057190 #>>42057359 #>>42057715 #
2. kimixa ◴[] No.42055656[source]
I'd argue that the Atom core itself could compete - it hit pretty much the same perf/watt targets as it's performance-competitive ARM equivalents.

But having worked with Intel on some of those SoCs, it's everything else that fell down. They were late, they were the "disfavored" teams by execs, they were the engineer's last priority, they had stupid hw bugs they refused to fix and respin, they were everything you could do to set up a project to fail.

replies(3): >>42056070 #>>42056414 #>>42057368 #
3. Keyframe ◴[] No.42055769[source]
Maybe I'm just spitting out random BS, but if I understood Keller correctly when he spoke about Zen that (for it) it's not really a problem to change frontend ISA as large chunk of work is on the backend anyways. If that's the case in general with modern processors, would be cool to see a hybrid that can be switched from x86_64 to RISC-V and, to add even more avangarde to it, associate a core or few of FPGA on the same die. Intel, get on it!
replies(6): >>42055814 #>>42055834 #>>42056028 #>>42056855 #>>42057558 #>>42057660 #
4. vel0city ◴[] No.42055814[source]
There were consumer devices with a processor designed to be flexible on its instruction set presented to the user.

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

https://youtu.be/xtuKqd-LWog?t=332

replies(1): >>42055856 #
5. formerly_proven ◴[] No.42055834[source]
"not really a problem to change" in the context and scope of a multi-billion dollar project employing thousands of people full time.
6. Keyframe ◴[] No.42055856{3}[source]
aka the company where Linus worked!
replies(1): >>42056731 #
7. dwattttt ◴[] No.42056028[source]
If you think about it, that's what Thumb mode on ARM is.
replies(1): >>42057417 #
8. RussianCow ◴[] No.42056070[source]
> They were late

This was the main thing, as by that point, all native code was being compiled to Arm and not x86. Using x86 meant that some apps, libraries, etc just didn't work.

replies(1): >>42056304 #
9. mkl ◴[] No.42056304{3}[source]
Intel and Google developed libhoudini to do binary translation of the native code to solve that problem. https://github.com/SGNight/Arm-NativeBridge, https://www.anandtech.com/show/5770/lava-xolo-x900-review-th..., http://blog.apedroid.com/2013/05/binary-translation-vs-nativ...
10. hajile ◴[] No.42056414[source]
Medfield was faster than A9 and Qualcomm Krait in performance, but not so much in power (see Motorola Razr i vs M where the dual-core ARM version got basically the same battery life as the single-core x86 version).

Shortly after though, ARM launched A15 and the game was over. A15 was faster per clock while using less power too. Intel's future Atom generations never even came close after that.

11. nineteen999 ◴[] No.42056731{4}[source]
that also kinda failed to reach their goals unfortunately.
replies(1): >>42082570 #
12. mschuster91 ◴[] No.42056855[source]
> and, to add even more avangarde to it, associate a core or few of FPGA on the same die

The use cases for FPGAs in consumer devices are ... close to zero unless you're talking about implementing copy protection since reverse engineering FPGA bitstreams is pretty much impossible if you're not the NSA, MI6 or Mossad with infinite brains to throw at the problem (and more likely than not, insider knowledge from the vendors).

13. arcanemachiner ◴[] No.42057190[source]
> Intel should be focused on an x86+RISC-V hybrid chip design where they can control an upcoming ecosystem while also offering a migration path for businesses that will pay the bills for decades to come.

First I've heard of this. Is this actually a possibility?

replies(1): >>42057546 #
14. raverbashing ◴[] No.42057359[source]
Sounds like Intel has a big boomer problem
15. raverbashing ◴[] No.42057368[source]
Maybe the Atom core itself was performant, but I doubt they could take all the x86 crap around it to make it slim enough for a phone
replies(1): >>42057555 #
16. kevin_thibedeau ◴[] No.42057417{3}[source]
Plus the original Jazelle mode.
17. mshockwave ◴[] No.42057546[source]
RP2350 is using a hybrid of ARM and RISCV already. Also it's not really hard to use RISCV not as the main computing core but as a controller in the SoC. Because the area of RISCV cores are so small it's pretty common to put a dozen (16 to be specific) into a chip.
18. kimixa ◴[] No.42057555{3}[source]
They were SoCs, fundamentally the same as any ARM-based phone SoC - some atom SoCs even had integrated modems.

The BoM was pretty identical to other devices.

replies(1): >>42060807 #
19. mshockwave ◴[] No.42057558[source]
Reminds me that's also many people's speculation on how Qualcomm builds their RISCV chips -- swap an ARM decoder for a RISCV one.
replies(1): >>42068002 #
20. neerajsi ◴[] No.42057660[source]
From what I gather the one time I got to speak with chip engineers is that real estate is still at a premium. Not necessarily the total size of the chip, but certain things need to be packed close together to meet the timing requirements. I think that means that you'd be paying a serious penalty to have two parallel sets of decoders for different ISAs.
21. deelowe ◴[] No.42057715[source]
They killed strongarm because of nepotism. That's been the issue at Intel for decades. They are the epitome of ego over merit and x86 was king.
replies(1): >>42059895 #
22. DanielHB ◴[] No.42059895[source]
Nepotism? Like execs from different divisions fighting each other?

To me it seems they just want to keep their lock-in monopoly because they own x86. Very rational albeit stupid, but of course the people who took those decisions are long gone from the company, many are probably retired with their short-term focused bonuses.

replies(1): >>42079924 #
23. ksec ◴[] No.42060807{4}[source]
Exactly. Most people still dont get it. What killed Atom on Phone wasn't x86. It was partly software and mostly hardware and cost. It simply wasn't cost competitive, especially when Intel were used to high margin business.
24. hajile ◴[] No.42068002{3}[source]
That's not speculation.

Qualcomm made a 216-page proposal for their Znew[0] "extension".

It was basically "completely change RISC-V to do what Arm is doing". The only reason for this was that it would allow a super-fast transition from ARM to RISC-V. It was rejected HARD by all the other members.

Qualcomm is still making large investments into RISC-V. I saw an article estimating that the real reason for the Qualcomm v Arm lawsuit is that Qualcomm's old royalties were 2.5-3% while the new royalties would be 4-5.5%. We're talking about billions of dollars and that's plenty of incentive for Qualcomm to switch ISAs. Why should they pay billions for the privilege of designing their own CPUs?

[0] https://lists.riscv.org/g/tech-profiles/attachment/332/0/cod...

25. deelowe ◴[] No.42079924{3}[source]
The opinion that x86 would always be king is nepotism/ego. It was obvious nearly 2 decades ago where compute was headed with cloud and mobile becoming the dominant areas. Neither of which x86 was well positioned for.
replies(1): >>42080926 #
26. tremon ◴[] No.42080926{4}[source]
There was a story here a few days ago about the exact opposite: that Intel lost out to AMD on x86-64 because they were betting on Itanic to take over the 64-bit market.

edit: https://news.ycombinator.com/item?id=41890779

> Intel could have beaten AMD to the x86-64 punch if the former wasn't dead-set on the x64-only Itanium line of CPUs

27. panick21_ ◴[] No.42082570{5}[source]
The failed because contract chip manufacturing was a huge issue back then. And the bet on slightly the wrong implementation as well. The fundamentally ideas weren't broken.
replies(1): >>42110765 #
28. nineteen999 ◴[] No.42110765{6}[source]
Yeah, I didn't ascribe any particular reason for it. I was dissapointed to hear the news, it came quietly after a long period of silence, which came after a much longer period of hype.