Hacker News

Top stories

Live mirror
30 storiesupdated just nowView source snapshot
  1. Vectorized and performance-portable Quicksort(googleblog.com ↗)
    19comments
  2. Training a 4B model to produce 81% faster query plans than Postgres(rohanbansal.com ↗)
    11comments
  3. Small programming tricks(will-keleher.com ↗)
    128comments
  4. Accurate Models of AMD Matrix Cores(arxiv.org ↗)
    1comments
  5. Dream-RSI: Recursive Self-Improvement through Evolving Worlds(arxiv.org ↗)
    44comments
  6. Fed hikes rates as inflation worries push up bond yields(reuters.com ↗)
    38comments
  7. Mistral X Mozilla: Private, Multilingual AI Browsing(mistral.ai ↗)
    166comments
  8. Tell the speakers that you liked their talks(ohhelloana.blog ↗)
    54comments
  9. Show HN: An e-ink frame that hears birds and draws them as 1800s illustrations(github.com/arnegiacomo ↗)
    230comments
  10. GitHub is having trouble counting things(chuckgreenman.com ↗)
    30comments
  11. The Siberian Ice Maiden and the Scythian World(patrickwyman.substack.com ↗)
    discuss
  12. Learning Programming in an Age of LLMs(ploeh.dk ↗)
    151comments
  13. How big are factorials?(thegreenplace.net ↗)
    25comments
  14. Claude Cowork and chat are now one Claude(claude.com ↗)
    168comments
  15. The DeepMind Institute(deepmind.com ↗)
    24comments
  16. The Google Play app review process now regularly takes longer than a week(gultsch.social ↗)
    295comments
  17. Hackers Got Inside a Flock Camera(wired.com ↗)
    181comments
  18. Can we stop with the uptime percentages?(jim-nielsen.com ↗)
    88comments
  19. Show HN: How Stale Is Your AI? Release age and training cutoff for 20 models(stale.jock.pl ↗)
    39comments
  20. ER visits for gambling disorders doubled after expanded online gambling market(utoronto.ca ↗)
    92comments
  21. Kyber (YC W23) Is Hiring a Forward Deployed Engineer(ycombinator.com ↗)
    discuss
  22. Why a fast-growing German AI startup is moving its parent company from the US(euronews.com ↗)
    3comments
  23. How good are frontier models at physics?(arxiv.org ↗)
    3comments
  24. Salesforce Global Outage(salesforce.com ↗)
    150comments
  25. This Code Is CRAP (2011)(googleblog.com ↗)
    45comments
  26. Show HN: I made a flight simulator, except you're just a passenger(inflightsimulator.com ↗)
    197comments
  27. Anatomy of a Texture(agentlien.github.io ↗)
    9comments
  28. A warning about 'model welfare'(mustafa-suleyman.ai ↗)
    313comments
  29. Scaling Golang CI by Replacing actions/setup-go(cloudx.ai ↗)
    17comments
  30. Original Sony PlayStation 2 security chip 'broken wide open' after 26 years(tomshardware.com ↗)
    68comments

Accurate Models of AMD Matrix Cores

19 pointsby 1h agoarxiv.org
1 comments
14m agoHN ↗

"Features of matrix multipliers differ across vendors and architectures of the same vendor [...] As a result, reproducibility of small matrix multiplier results [differences] across devices is not possible and cannot be achieved by software control. Implementation details of matrix multipliers are not documented, making it difficult to interpret discrepancies in the computed results."

I'm guessing (but not knowing) that small subtle differences in matrix multiply across different vendor's architectures (and product generations of an individual vendor's architecture) is responsible for a good portion of software crashes when trying to run a local LLM on a different architecture or with a different stack (ROCm vs. CUDA, for example) than the ones it has been explicitly tested on.

As such, this marks a rather significant problem for the future, which can basically be stated as:

There needs to be a standard matrix multiply specification (much like IEEE-754 is/was for floating point operations) that all future vendors of AI accelerators (any GPU, CPU, NPU or IC manufacturer whose circuits implement matmul) adhere to, such that the matmul of one vendor is exactly and precisely compatible with the matmul of another.

Hardware vendors of course, are free to compete in terms of speed, power efficiency, number of matmul engines on a given piece of silicon, parallelization optimizations, etc., but the basic matmul operation should be exactly and precisely compatible across vendors and across future product versions.

Step 1: We need a spec for this... (Maybe IEEE is already working on one? If so, that's a good step forward!)

Step 2: Hardware vendors need to implement it, to be universally compatible in all of their IC's that use matmul, in the future...