Y
HN Search
Hacker News Search
new
|
comments
|
top
|
jobs
hajile
searching PlanetScale…
1.
▲
2.
▲
3.
▲
4.
▲
5.
▲
6.
▲
36 ms
·
541.
▲
by
hajile
2y ago
Who said I was comparing multithreaded loads? AMD will hit that on just one core with those boost clocks.
542.
▲
by
hajile
2y ago
For the same node, you aren't cutting power by 40% while increasing clockspeeds. At best, they could be aggressively cutting clockspeeds, but that means lower overall performance. Marketing seems a more likely reason (and I don't
543.
▲
by
hajile
2y ago
Apple themselves have around 10% IPC uplift with M4 too. The real issue is that most code people run doesn't use very much SIMD and even less uses AVX-512.
544.
▲
by
hajile
2y ago
I think there's a market for a 7950E with a specific binning for lower power rather than highest possible clocks.
545.
▲
by
hajile
2y ago
M4 is looking pretty interesting. Near 10% IPC uplift and they bumped the e-core on the base M4, so we're probably looking at the same 12 p-cores for the M4 max, but likely going from 4 to 12 e-cores (two of the 6-core complexes). In m
546.
▲
by
hajile
2y ago
Apple's M3 Max CPU cores peak out at 55w for 16 cores (12p+4e). AMD's 8-core U-series chips peak out at 65-70w on CPU-only workloads and still loses out massively in pretty much every category. If you downclock that AMD chip, it d
547.
▲
by
hajile
2y ago
Or if you don't want to blow out the power bill. A 7950x system at IDLE uses 50% more power than an M3 Max going all-out on a CPU workload. https://www.guru3d.com/review/amd-ryzen-9-7950x-review/page-...
548.
▲
by
hajile
2y ago
There's something wrong with your M3 Max stuff. I believe it comes in 14 and 16-core variants while the M3 Pro comes in 11 and 12-core variants. In any case, M3 Max uses less than 55w of power in CPU-only workloads while a desktop 7950
549.
▲
by
hajile
2y ago
AMD used to give decently accurate TDP, but Intel started giving unrealistically optimistic TDP ratings, so AMD joined the game. Their TDP is more of an aspiration than a reality (ironically, Intel seems to have gotten more accurate with th
550.
▲
by
hajile
2y ago
Does Zen5 do FP math in a single cycle?
551.
▲
by
hajile
2y ago
There's so much wrong here: * 12 big cores vs 4p+4e CPU * active vs passive cooling * Ignoring that M4 exists * completely avoids single-thread performance even though that's what is most important to laptop users.
552.
▲
by
hajile
2y ago
I believe it requires the ARMv8.5 instruction sets (but maybe some of those are optional too?)
553.
▲
by
hajile
2y ago
I'd say that the theoretical ability to gang units together would be appealing. If you have four 128-bit packed SIMD, you must execute 4 different instructions at once or the others go to waste. With SVE, you could (in theory) use all
554.
▲
by
hajile
2y ago
SVE2 is an extension on top of SVE which some stuff already implements. The issue is more likely to be the politics of moving to ARMv9 than anything else. As to SVE though, I'd guess variable execution time makes the implementation req
555.
▲
by
hajile
2y ago
Oryon was designed to compete with M1 then the clockspeeds were ramped up to compete with M2. M3 clearly beat it out and M4 has only furthered that lead. Oryon will still probably beat x86 designs massively in performance per watt which is
556.
▲
by
hajile
2y ago
ARMv9 is just ARMv8.5 with 4 extra extensions. It's not a complete overhaul like the ARMv7 to ARMv8 change was. It's more comparable to x86 chips with AVX-512 and chips without AVX-512. 99% of your code is the same, but the compil
557.
▲
by
hajile
2y ago
ARMv9.0 is very similar to ARMv8.5 (9.0 supersets 8.5 with SVE2, TME, TLA, and CCA), so it's not a massive deal. SME implies v8.7 which is basically identical to v9.2 except for those couple extensions previously mentioned. I wonder if
558.
▲
by
hajile
2y ago
StandardML is the most practical functional programming language IMO. It concedes that mutation improves performance, laziness is hard for humans to optimize, and side effects exist. At the same time, it has avoided the weirdness of Ocaml o
559.
▲
by
hajile
2y ago
Don't forget 751 pregnant women given radioactive vitamins. They claim only 3 kids died, but destroyed a bunch of documentation in the 70s, so the actual conclusions were probably far more damning.
560.
▲
by
hajile
2y ago
VisX starts with low-level primitive components that match very closely to D3 primitives. It then builds some chart primitives on top of those and then builds some charts on top of that. You can build pretty much anything using the lowest-l
561.
▲
by
hajile
2y ago
Learn D3 then (assuming you're doing something chart-like as most of us are) move to something like VisX or some non-React equivalent and never look back. I view D3 and jQuery as being somewhat similar and both are very prone to spaghe
562.
▲
by
hajile
2y ago
They already released all their macbooks and latest iphone on N3B which is the worst-yielding 3nm from TSMC. I doubt yields are the issue here. It's suspected that the fast release for M4 is so TSMC can move away from the horrible-yiel
563.
▲
by
hajile
2y ago
As far as the spec is concerned, JS arrays are actually JS objects. The keys of JS arrays are technically stringified numbers. Because it is essentially a hashtable, there is no guarantee that the array is contiguous. It's not commonly
564.
▲
by
hajile
2y ago
If you want complete type erasure, then a system that ensures monomorphism is critical to good JS performance. If you can leave the type system in place, then you could move toward an ML-style type system and see massive improvements within
565.
▲
by
hajile
3y ago
That would upset the church of emacs though.
566.
▲
by
hajile
3y ago
I believe the first cores in chisel which is a Haskell/ML type HDL, so SAIL fits right in. Just because people are used to other ways of doing things doesn’t make those ways better. “I don’t want to learn something new“ certainly isn’t
567.
▲
by
hajile
3y ago
EUV was supposed to ship in the early 2000s and the work on it started in earnest the 90s. It turned out that EUV is way harder than anyone imagined. The only reason we did stuff like immersion DUV was because we couldn’t get EUV to work.
568.
▲
by
hajile
3y ago
Your argument is that this is the only difference. If so, then Tenstorrent should have chosen x86. They could support all the way through SSE3 without patent negotiations and maintain backward compatibility rather than risking it on a new I
569.
▲
by
hajile
3y ago
There isn't a pushback against new instructions. Look at the large number of extensions being worked on at the moment let alone all the extensions already finalized and required for current profiles. The only issue is adding bad extens
570.
▲
by
hajile
3y ago
AMD and Intel are high-margin rather than high-volume products. AMD shipped 8M chips in Q4 of 2023 and Intel shipped 50M (not what the tech press would have you believe given how they rave about Zen). Even if we assume they shipped that man
More ›