Hello team,
I want to preface this by saying I have 0 expectations for the externals to work and I chose to go with the new processors for various reasons, mostly financial and extracting the last bit of value I can from my 7 year old laptop. I thought I might post my experience here trying to get the externals to work as I’ve had success with others (mubu for example which I expected to instantly crash).
I’ve de-quarantined the externals (but not built from source) with xattr -d -r ~/Documents... which worked fine. Creating instances of the objects prompts an instant crash of Max. The objects I have tested exhibit the same pattern in the crash log.
crash.txt.zip (31.8 KB)
I will try building the externals from source and see how that goes.
Just moved this into the toolbox 2 bugs rather than the other public facing one.
are other (intel) externals behaving the same?
No, mubu stuff is fine. I can test more packages if that helps.
fluid::client::FluidMaxWrapper<fluid::client::ClientWrapper<fluid::client::AmpSliceClient> >::makeClass(char const*) + 436
Well, that means it at least goes down early, but impossible to say why without debug symbols. If I send you a debug build of an object at some point, could you make it die with that and we can check a more informative report?
Meanwhile, perhaps I misunderstood, but I thought that yesterday you successfully built the CLI on your new box? That narrows down the badness (maybe)
Yep. I built and was able to use compiling to an arm target.
That’s undeservedly good news
After attempting to make the object you sent me with debug build.
@jamesbradbury has been patiently helping me try and figure this out remotely.
A possible cause (waiting to hear back) is that it turns out that Rosetta 2 – the translation layer Apple use to run x64 binaries on the M1 – doesn’t support AVX instructions. See the link below, under the heading What Can’t Be Translated? (@a.harker, if he didn’t already know this, might be interested in case it comes up with FrameLib. )
Irrespective of whether this is the specific cause of the problem here (I kinda suspect it is), it means that current x64 builds of FluCoMa stuff aren’t going to run cheerfully under Rosetta 2. I’m seeing if an SSE4 build is happier. Longer term, it looks like supporting a range of Apple hardware / OS’s is going to necessitate multiple binaries.
I’m not sure if the flucoma Mac binaries are in the old universal binary format, but the new way forward is UB2. I’d hope a cross compile would be possible, but if not you can lip binaries together pretty easily (I have done this when building skia as a UB for instance).
As Eigen supports NEON on arm I’m not sure how much work would be involved in a full port, but one would be hopeful that it’s mostly just a case of compiling on the right platform.
With the SSE4 build I got from Owen it worked without a hitch. Without benchmarks and comparisons it would be hard to tell how hard this affects the performance if at all.
Mac OS FluCoMa builds pre XCode 10 are old style UBs with both 32 and 64 bit binaries.
The wrinkle is continuing to support x86 as well as x64 and M1. It looks like XCode 12 might let us cross compile x64 and ARM, but 32-bit builds aren’t possible from Xcode 10. I’m assuming that, lipo or not, we won’t be able to glue a 32 bit, 64 bit and M1 thing together in a single package (but who knows, haven’t really looked). It’s still going to require two compilers, whatever else. I haven’t yet checked to see if Catalina will let me run XCode 9 alongside XCode 11, but I could at least do this on Mojave.
Personally, I think that supporting 32 bit is probably not worth it and this is as good a time to make the break as any.
Max has been 64 bit since 6.1 and I imagine SC has been 64 bit for a pretty long time.
However, I’m pretty sure that you can put as many architectures as you like in a binary:
2 Likes
Did you compile with SSE4.2/.1 to get the FluCoMa objects to function for me?
I am looking at compiling FrameLib now but curious what you used as I’m trying to dissect the build settings of Xcode pictured below:
Our build settings are generated by CMake, and I’m just passing -msse4 as a compiler flag which is apparently the same as -msse4.2
Any chance @weefuzzy you would be up for trying a second toolbox build for my lowly ARM processor?
