Test on Apple M1 silicon

[plajjan]

Will it build? Any problems? If successful, we can move to support M1 as a platform I suppose..

[plajjan]

kll@Kristians-Mac-mini acton % dist/bin/actonc --version                                                                                                                                                                                                                                                                                                                                                                                                                       
acton 0.6.4.20211121.23.0.12
compiled by ghc 8.10 on darwin aarch64
cc: Apple clang version 13.0.0 (clang-1300.0.29.3)
kll@Kristians-Mac-mini acton %                                                                                                                                                                                                                                                                                                                                                                                                                                                 

kll@Kristians-Mac-mini examples % ../dist/bin/actonc --root main helloworld.act                                                                                                                                                                                                                                                                                                                                                                                                
kll@Kristians-Mac-mini examples % ./helloworld                                                                                                                                                                                                                                                                                                                                                                                                                                 
Hello, world!
kll@Kristians-Mac-mini examples %                                    

had to change some stuff in the build process. Should have documented what I did :P but I think I remember most of it and will write down.

[plajjan]

Noticed a problem that actonc might get killed by something. It appears to happen if I rebuild actonc. I needed to do that a few times when I updated paths to lib directories. Had to do a make clean && make to fix it.

[plajjan]

First of all, stack must be installed with brew install --HEAD stack to get the latest version which has support for installing GHC on aarch64. Only GHC 8.10.5 and newer have binaries built for aarch64. Fortunately, our stack config already specifies LTS 18.12 which uses GHC 8.10.7 IIRC, newer than 8.10.5 at least. Can we even do this in a brew recipe? Like can we declare a dependency in the Acton formula that depends on a --HEAD install of stack? Maybe that will have to wait, but at least we can have installation instructions that include the --HEAD part.

Without --HEAD, stack just complains and says it cannot install ghc for architecture aarch64.

[plajjan]

Interesting (or not really)... I tried rebuilding and I got a segfault from stack:

kll@Kristians-Mac-mini acton % make clean && make
cd compiler && stack clean >/dev/null 2>&1 || true
rm -f compiler/actonc compiler/package.yaml compiler/acton.cabal
rm -rf dist
rm -f backend/comm.o rts/empty.o backend/db.o backend/queue.o backend/skiplist.o backend/txn_state.o backend/txns.o rts/empty.o backend/client_api.o rts/empty.o backend/failure_detector/db_messages.pb-c.o backend/failure_detector/cells.o backend/failure_detector/db_queries.o backend/failure_detector/fd.o backend/failure_detector/vector_clock.o backend/actondb
rm -f lib/libActon.a lib/libActonRTSdebug.a lib/libActonDB.a builtin/builtin.o builtin/minienv.o stdlib/out/release/math.o stdlib/out/release/numpy.o stdlib/out/release/random.o stdlib/out/release/time.o stdlib/out/release/acton/rts.o stdlib/out/release/numpy.o rts/empty.o rts/rts.o deps/yyjson.o rts/rts-debug.o backend/comm.o rts/empty.o backend/db.o backend/queue.o backend/skiplist.o backend/txn_state.o backend/txns.o rts/empty.o backend/client_api.o rts/empty.o backend/failure_detector/db_messages.pb-c.o backend/failure_detector/cells.o backend/failure_detector/db_queries.o backend/failure_detector/fd.o backend/failure_detector/vector_clock.o stdlib/out/types/math.h stdlib/out/types/numpy.h stdlib/out/types/random.h stdlib/out/types/time.h stdlib/out/types/acton/rts.h stdlib/out/release/math.o stdlib/out/release/numpy.o stdlib/out/release/random.o stdlib/out/release/time.o stdlib/out/release/acton/rts.o stdlib/out/types/math.ty stdlib/out/types/numpy.ty stdlib/out/types/random.ty stdlib/out/types/time.ty stdlib/out/types/acton/rts.ty
cd compiler && stack build --dry-run 2>&1 | grep "Nothing to build" || \
		(sed 's,^version:.*,version:      "0.6.4.20211122.9.48.49",' < package.yaml.in > package.yaml \
		&& stack build --ghc-options -j4 \
		&& stack --local-bin-path=. install 2>/dev/null)
/bin/sh: line 1: 23099 Segmentation fault: 11  stack build --ghc-options -j4
make: *** [compiler/actonc] Error 139
kll@Kristians-Mac-mini acton % 

[plajjan]

When stack crashes as per above, I'm logged into my mac mini over SSH. Building in a local terminal works just fine.

There are some reports of weird behaviour, like commercialhaskell/stack#5607 where stack crashes when run from zsh. I am using zsh (it is standard in new Mac OS X) in that local terminal and it works. Some comment suggests that it works in some terminal emulators but not others, specifically that iTerm2 works while Terminal does not. I have been using iTerm2. Gosh this is so weird.

Anyway, it builds fine using iTerm2 + zsh.

[plajjan]

And just for anyone interested in the speed of M1. On my mac mini M8 with 8 cores, acton builds using time make -j8 in 1:15. On my AMD 5950X with time make -j8 it builds in 36 seconds so while M1 might be fast and power efficient, a classic high powered CPU still runs loops around it. The 8 way parallelism doesn't do much; we can roughly group the acton build into two parts; the compiler (haskell / stack build) and the rest. The rest, like all libraries etc build in a few seconds and while it builds nicely in parallel and might even be able to use more than 8 parallel jobs to build, it doesn't change the end result since going from 4 seconds to 1 second doesn't help when the compiler builds in 1 minute. The compiler is built using stack and we do use some parallelism there, 4 threads currently. I have experimented with this in the past, trying to increase it, but didn't get any better times, so I think this is pretty much the sweet spot. Single core performance is thus much better on this AMD 5950X than on an M1 and it also sports twice as many cores, so it just beats it hands down. To be expected when it has a TDP of what, 130W or so? compared to the M1 which seems to be around 20W!?

This is the original M1 with 16 billion transistors, the M1 max has 57 billion transistors, so that might very well be faster but I suspect most of that is just graphics cores?

[plajjan]

It is not possible to have a Homebrew formula depend on a --HEAD install of a dependency, so that makes it impossible to build a formula roughly along our current outline but working on M1. It would require a rewrite. Not going to do that - which means we will need to wait for a newer stack to hit homebrew.