Primes
Primes copied to clipboard
PlummersSoftwareLLC
Added arch files
Running the benchmark under my M1 machine yielded quite a few errors on the following solutions:
error: [PrimeCSharp][solution_2] Failed building solution!
error: [PrimeDart][solution_1] Failed building solution!
error: [PrimeHaskell][solution_1] Failed building solution!
error: [PrimeJulia][solution_1] Failed building solution!
error: [PrimeJulia][solution_2] Failed building solution!
error: [PrimeSwift][solution_1] Failed building solution!
error: [PrimeZig][solution_1] Failed building solution!
error: [PrimeZig][solution_3] Failed building solution!
error: [PrimeJava][solution_2] Failed building solution!
error: [PrimeFortran][solution_2] Failed building solution!
warn: [PrimeLua][solution_2] Exited with abnormal code: 1. Results might be partial... (can be fixed)
warn: [PrimePascal][solution_1] Exited with abnormal code: 217. Results might be partial...
warn: [PrimeWren][solution_1] Exited with abnormal code: 255. Results might be partial...
I've added the arch-amd64 flag for these since they fail to build/run under arm64.
Any indication as to why these solutions might not build?
Could you provide docker output so that people without suitable hardware to test on may suggest fixes based on the error messages?
@tjol Not all Docker images are suitable for ARM64. Also, some of the solutions specifically target x86_64.
Some of those are clear. Lol @ Apple not providing a Docker image for Swift that runs on M1. Others, less so. I'm puzzled why Fortran solution 2 should fail when Fortran solution 1 works, as they run in the same environment
Some of those are clear. Lol @ Apple not providing a Docker image for Swift that runs on M1. Others, less so. I'm puzzled why Fortran solution 2 should fail when Fortran solution 1 works, as they run in the same environment
Indeed the fact that Swift doesn't have an am64 Docker image is quite funny.
As for Fortran solution_2 that can probably be fixed. We'll probably do a review at some point and signal to the authors to improve their solutions.
A detail that shouldn't matter (but who knows) is that the first RUN directive in Fortran/solution_2's Dockerfile is spelled as RUn.
As I said. it shouldn't. :) What's interesting is that the solution does (docker) build and run on my rpi 4.
Hmm, that’s interesting, maybe is the virtualization engine for Docker under M1, let me switch that around and try again. Will do a comparison between the M1 and the Pi to see if the same solutions fail.
For the Julia solutions, Julia does provide an arm64v8 Docker image, but only for 1.6.1-buster while the Julia solutions use 1.6.1-alpine3.13.
How do you suppose we handle this? Should we use 1.6.1-buster for all architectures?
We should also probably check the other solutions for similar issues.
Ideally, we should use images that support both x86_64 and arm64 solutions, but that shouldn't be mandatory. We support the arch files for this exact reason. If the developer decides to support both platforms, they should choose whatever images they think are suitable. For example, I chose to go with the Alpine 3.13 image on the Crystal implementation as it supports multiple platforms. The Crystal compiler is installed from the package manager as the official images do not run under arm64.
Hmm, that’s interesting, maybe is the virtualization engine for Docker under M1, let me switch that around and try again. Will do a comparison between the M1 and the Pi to see if the same solutions fail.
I'm curious what your conclusions are, when you've had the time to look into this.
Hmm, that’s interesting, maybe is the virtualization engine for Docker under M1, let me switch that around and try again. Will do a comparison between the M1 and the Pi to see if the same solutions fail.
Heya have you been able to look into this?
