Become a MacRumors Supporter for $50/year with no ads, ability to filter front page stories, and private forums.

name99

macrumors 68020
Jun 21, 2004
2,410
2,318
[they make these users (and LLVM) aware of their MUL53 extension (instruction that's not present in base ARM) that allows for substantially faster bignums.]

I'm sure Apple has included that in their LLVM fork.

Unlikely. How do you access such an instruction without a natural 53bit integer type in the language?
The technical decision is obvious (you have a 53b multiplier there anyway; Intel made the same decision for AVX512). But in both cases, the instruction is only useful as an assembly language primitive for a bignum library like GMP.

Presumably it's used by Accelerate's vBigNum library, but Apple seems to be doing a lousy job of evangelizing that to the natural consumers (like Mathematica or Octave). It would be interesting to see if you can wrap GMP around Accelerate vBigNum and pick up Apple performance that way. But maybe the underlying data structures are too different to allow for such a very lightweight translation?
 
  • Like
Reactions: Xiao_Xi

Xiao_Xi

macrumors 68000
Oct 27, 2021
1,627
1,101
Unlikely. How do you access such an instruction without a natural 53bit integer type in the language?

By the way, Apple compiler engineer Tim Northover has contributed the Apple M2 / A15 / A16 CPU targets to the upstream code-base for LLVM/Clang.

Apple seems to be doing a lousy job of evangelizing that to the natural consumers (like Mathematica or Octave).
It would be amazing if Apple would help the Julia language as it is helping Blender.
 
Last edited:

name99

macrumors 68020
Jun 21, 2004
2,410
2,318


It would be amazing if Apple would help the Julia language as it is helping Blender.
Hmm. It would depend on how Julia represent bignums right now. But if someone in Julia wants to work on this, the details are at:

Apple's vBigNum is described at https://developer.apple.com/documentation/accelerate/veclib/vbignum but is not completely generic (not arbitrary sized bignums).
 
  • Like
Reactions: Xiao_Xi

Boil

macrumors 68040
Oct 23, 2018
3,477
3,173
Stargate Command
Music? Add some PCI slots to the Ultra for suitable special hardware in regard to music production-should be enough

Pro Tools HDX scales up to three cards...

Video? The Ultra is pretty good but I expect that some might need PCI as well for special hardware

Single PCIe slot (2-slot width at the brackets) should cover this...?

3D? Are we talking about rendering, shading, modelling, simulations or animations? Each of these tasks does not need the same kind of computer. For some of these tasks the Ultra is sufficient. Do Apple want to address the whole stack?

This is where an Apple add-in GPU/GPGPU cards would come in handy; real-time ray-tracing in the viewport (iGPU) and an "onboard render farm" (add-in cards) would be cool...

Science: sky is the limit here and price/performance will be key (guess why gamings cards are so popular to use). Price/performance ratio is not Apples strong point.

I am quite confident that Apple solve "how" to beat 2X 4090 but can they also do it at a competitive price?

MSRP of $3200 for a pair of 4090 cards, a goodly bit more for the Quadro or A-series variants; and the Quadro or A-series variants would be the better comparison...?

RAID/Storage cards & networking cards would be the final few things an ASi Mac Pro might need PCIe slots for...?

So an eight slot ASi Mac Pro could still make sense; if fully loaded with three audio i/o cards, one video i/o card, one RAID/M.2 storage card, one 40GbE networking card, & two Apple GPGPU cards...

But only four of those slots would need to be x16 slots, the audio cards are x4 & the video card is x8...

Still a lot of PCIe lanes; but maybe they are Gen5 lanes, breaking down to Gen4 lanes for the x16 slots and maybe even Gen3 lanes for the x4 & x8 slots...?

We continue to wait on Apple to see what the first ASi Mac Pro will actually be...! ;^p
 
Register on MacRumors! This sidebar will go away, and you'll see fewer ads.