this post was submitted on 12 Jul 2024
342 points (93.0% liked)

Technology

58303 readers
6 users here now

This is a most excellent place for technology news and articles.


Our Rules


  1. Follow the lemmy.world rules.
  2. Only tech related content.
  3. Be excellent to each another!
  4. Mod approved content bots can post up to 10 articles per day.
  5. Threads asking for personal tech support may be deleted.
  6. Politics threads may be removed.
  7. No memes allowed as posts, OK to post as comments.
  8. Only approved bots from the list below, to ask if your bot can be added please contact us.
  9. Check for duplicates before posting, duplicates may be removed

Approved Bots


founded 1 year ago
MODERATORS
you are viewing a single comment's thread
view the rest of the comments
[–] [email protected] 76 points 4 months ago (3 children)

Anyone willing to summarize those mistakes here, for those who can't watch the video rn?

[–] [email protected] 134 points 4 months ago* (last edited 4 months ago) (1 children)

He doesn't list what the mistakes will be. He said that he fears that because hardware people aren't software people, that they will make the same mistakes that x86 made, which were then made by Arm later.

He did mention that fixing those mistakes was faster for Arm than x86, so that brings hope that fixing the mistakes on Risc V will take less time

[–] [email protected] 27 points 4 months ago* (last edited 4 months ago) (2 children)

I think it was something with instruction sets? Pretty sure i read something about this months ago.

[–] [email protected] 6 points 4 months ago (2 children)

No, it was about the prediction engines that contain security vulnerabilities. Problem is that software has no control over that, because hardware does future predictions for performance optimization.

[–] [email protected] 1 points 4 months ago

Aah, right, that.

[–] [email protected] 1 points 4 months ago

Prediction is a hard problem when coupled with caches. It relatively easy to say that no speculative instruction has any effect until it's confirmed taken if you ignore caches. However caches need to fetch information from memory to allow an instruction to evaluate, and rewinding a cache to it's previous state on a mispredict is almost impossible. Especially when you consider that the amount of time you're executing non-speculative code on a modern processor is very low.

Not having predictions is consigning yourself to 1990s performance, with faster clocks.

[–] [email protected] 4 points 4 months ago

I mean, that's all chip architectures are, so yes.

[–] [email protected] 23 points 4 months ago* (last edited 4 months ago)

Basically, his concern is that if they are not cooperating with software engineers that the product won't be able to run AAA games.

It's more of a warning than a prediction.

[–] [email protected] 11 points 4 months ago (2 children)

Instruction creep maybe? Pretty sure I've also seen stuff that seems to show that Torvalds is anti-speculative-execution due to its vulnurabilities, so he could also be referring to that.

[–] [email protected] 4 points 4 months ago (1 children)

Counterintuitive but more instructions are usually better. It enables you (but let's be honest the compiler) to be much more specific which usually have positive performance implications for minimal if any binary size. Take for example SIMD which is hyper specific math operations on large chunks of data. These instructions are extremely specific but when properly utilized have huge performance improvements.

[–] [email protected] 1 points 4 months ago

I understand some instruction expansions today are used to good effect in x86, but that there are also a sizeable number of instructions that are rarely utilized by compilers and are mostly only continuing to exist for backwards compatibility. That does not really make me think "more instructions are usually better". It makes me think "CISC ISAs are usually bloated with unused instructions".

My whole understanding is that while more specific instruction options do provide benefits, the use-cases of these instructions make up a small amount of code and often sacrifice single-cycle completion. The most commonly cited benefit for RISC is that RISC can complete more work (measured in 'clockcycles per program' over 'clockrate') in a shorter cyclecount, and it's often argued that it does so at a lower energy cost.

I imagine that RISC-V will introduce other standards in the future (hopefully after it's finalized the ones already waiting), hopefully with thoroughly thought out instructions that will actually find regular use.

I do see RISC-V proponents running simulated benchmarks showing RISC-V is more effective. I have not seen anything similar from x86 proponents, who usually either make general arguments, or worse , just point at the modern x86 chips that have decades of research, funding, and design behind them.

Overall, I see alot of doubt that ISAs even matter to performance in any significant fashion, and I believe it for performance at the GHz/s level of speed.

[–] [email protected] 1 points 4 months ago

This is probably correct.