You asked. we listed! In this release, we are doubling all our Linux SaaS runners' vCPU & RAM with no increase in cost factor in our efforts to be best-in-class for ci build speed.
We are excited to see your pipelines run faster and boost productivity. Be sure to check out our updated Linux SaaS runners.
Darren Eastmanchanged title from Upgrade the compute class for GitLab Runner Small to 2vCPUs to Upgrade the compute class for GitLab SaaS Runners small to 2vCPUs
changed title from Upgrade the compute class for GitLab Runner Small to 2vCPUs to Upgrade the compute class for GitLab SaaS Runners small to 2vCPUs
Darren Eastmanchanged the descriptionCompare with previous version
changed the description
Darren Eastmanchanged title from Upgrade the compute class for GitLab SaaS Runners small to 2vCPUs to Upgrade the machine type for GitLab SaaS Runners small to 2vCPUs
changed title from Upgrade the compute class for GitLab SaaS Runners small to 2vCPUs to Upgrade the machine type for GitLab SaaS Runners small to 2vCPUs
Hey @DarrenEastman@gabrielengel_gl any updates on this issue? For reference, GitHub has had this proposed spec for over 2 years at least for their standard runner.
We are currently working to get macOS on M1 and GPU runners out the door.
Right after that, we will tackle our Linux offering. I hope we can get this done in Q2 this year.
Has anything else changed in shared runners? I'm encountering some failures (due to too large numerical differences) in jobs running shared runners with MKL, which I cannot reproduce locally or in specific runners. Jobs that passed earlier (May 16th) now fail (no code change, just re-running the job).
Hi @Jellby, yes we have adopted a more performant machine type for the small runners as you can see here which results in a switch from Intel to AMD hardware. It's the same machine type as we use for our other runners on Linux so this comes as a surprise. You may test on medium and large models. I would guess the errors still appear there.
Looking at your Duration: 58 minutes 25 seconds you might consider choosing a bigger machine in any way
Is it important for your tests to run on very specific platform and architecture? If so, self-managed runners would be a more viable alternative. SaaS runners on Linux | GitLab does not guarantee a specific CPU architecture as far as I can see.
I would back up @dnsmichi's statement from the forum. Is there an option you can test without being dependent on the underlying architecture?
Well, I was not using medium and large before, so it's no surprise I hadn't noticed the problematic behaviour with AMD.
Looking at your Duration: 58 minutes 25 seconds you might consider choosing a bigger machine in any way
I'd expect a performance gain of at most a couple of minutes, for twice the "price"
Is it important for your tests to run on very specific platform and architecture? If so, self-managed runners would be a more viable alternative. SaaS runners on Linux | GitLab does not guarantee a specific CPU architecture as far as I can see.
I would back up @dnsmichi's statement from the forum. Is there an option you can test without being dependent on the underlying architecture?
The point is we don't want to be dependent on the architecture, we just want to know why it fails when it fails, and how to fix it. So, for now, I'll call the issue closed with the following:
Yes, shared runners were by default Intel machines before and now they're AMD.
The MKL library apparently gives different result (in some cases) on Intel and AMD.
We should modify our code and/or tests to avoid those cases.
This is exactly why we want to test our code with different compilers, hardware and options.
@gabrielengel_gl One thought about the architecture - maybe document the CPU type for the runners. I never cared about it because it is "just a CPU that runs my tests". I could imagine that with different CPU instruction sets, folks can read the docs and decide to run their own self-managed runners if they prefer to run Intel CPUs.
I never heard of MKL but now googled for it. Intel seems to not support AMD well, or the code does not run that fast, requiring workarounds.