Gmic on new macs ARM SoC

Software G'MIC
1

Hi, the M1 chip looks quite promising and gmic is one of the few tools I used that I am not entirely sure will work out of the box. So I wonder

  • Can gmic be compiled for ARM architecture ?
  • Is their any reason why it would not work with Rosetta 2, the translation layer ?

Cheers!

2

Hi & welcome!

You’re likely one of the few in the community that’ll have one.

3

Debian -- Package Search Results -- gmic debian does compile it for arm64 so it definitely can be compiled.

I think the only way to answer that question is to test it. But from all I recall gmic doesn’t contain crazy jit, virtualization. I don’t think it contains any hand optimized code using intrinsics either which might not be supported. So it might at least work.

4

I was a brief Apple user. Rosetta (1) worked really well, so there is no reason to doubt 2’s capability.

This I am certain won’t be the case. Any cross-compiling takes a bit of work. It depends on how resourceful you are. Maybe you are someone who can do this without blinking. :stuck_out_tongue:

5

I’m not sure that really holds. Cross compiling go code is pretty much trivial, rust is often easy.

But why would he need to cross compile in this case? If he has the Machine he can just compile it natively.

6

Sorry, my insomnia talking. :sweat_smile: What I meant to say is that compiling in a new environment on new hardware may have gotchas. Like you say

7

So who wants to try and tell us what happens ? :smiley:

8

Sorry folks for making noise and essentially saying nothing. :stuck_out_tongue:

@Philippe_covoit We anticipate your findings. PS I suggest you wait for a point release for a stabler environment. I read somewhere that there were weird bugs such as not being able to factory restore the system successfully.

9

It’s gotten much easier over the years. How difficult depends on a bunch of variables though:

  1. Compiler maturity. arm64 is fine, CPU-specific optimizations might take a while
  2. Dependence on nonportable techniques such as hand-optimized SSE. Almost any FOSS software has non-SIMD fallback code paths for everything, but you lose performance
  3. Dependence on acceleration frameworks like OpenCL. Anything that wants OCL will be problematic due to Apple not supporting any cross-platform standards going forward
  4. This has come up in another thread, but x86->ARM is less likely to be a problem than current->Big Sur - Apple has a bit of a history of recent OS updates being headaches for FOSS developers due to breaking backwards compatibility
10

Well, quite a long while sometimes. I just made a test using a very simple algorithm (accumulation of millions of floats using more than one accumulator) and making a native build for my old AMD FX 8350. While latest gcc didn’t vectorize the algorithm, latest clang vectorized it.
Though gcc added some prefetches, which made it perform better than clang (which didn’t add prefetches, but vecorized it). Optimizing code for a special architecture seems to be an art…

RT has a non-SIMD fallback code path for everyting, but also some parts, which are coded to allow auto-vectorization by the compiler (IMHO that’s the way for CPU code paths)

11

Thanks for the insights, very interesting conversation. As for me, I am sorry I won’t be able to help further as I am chickening out and will probably order an intel version. It is a work laptop, and, for at least a few key softwares in my workflow, I have no guarantee it will work out.