Preparing for my #ARM #Chromebook mainlining project.

Is my old main laptop faster than a new-ish Chromebook?

In left corner current 2-core champion: Lenovo X230, i5-3380M! Opposite, ASUS Chromebook Flip CM3200FVA with 8 cores! 4xA73 and 4xA53!

The challenge is... compiling #bevy !

> time cargo build --example bevymark

X230's 2 cores try hard:
real 24m25.782s
user 33m34.125s
sys 1m56.381s

But Chromebook wins!
real 17m51.922s
user 99m29.030s
sys 3m49.953s

#rustlang

The #Chromebook model is google-damu (google-kukui), with the MT8183 #Mediatek SoC.

The speed is actually kind of embarassing, look at that user time. 33min vs 99min! But what else to expect from in-order cores?

Hey you, reader! Do you have an #ARM Chromebook? Could you benchmark it, too?

git clone https://github.com/bevyengine/bevy/
cd bevy
git checkout 3dd5d7037
cargo fetch
time cargo build --example bevymark

If you send me the results, I'll publish them on my blog!

#benchmarking #linux #mainline

@dcz IO may take a long time too, so the real time does not imply much about the CPU. If you have enough RAM, you can try to build in /dev/shm to reduce IO time.

@tuxmain The test was meant more as a benchmark of the entire system. You rarely get those cores paired with NVMe storage.

But you're right. The storage on the X230 is the fastest at random writes across tested computers.

@dcz Well. You are building x86 code on one side and arm code on other. More fair benchmark would be to cross-build same demo for, dunno, powerpc.

@pavel Fairness depends on what you're measuring. The goal of this test is to check how suitable the machine is for the write, build, test cycle.

If I was cross-compiling, that benchmark would be misleading for the "test" part of the cycle.

Even when journalists test hardware, they typically run a browser benchmark, which is the same thing: JIT engines will do different things on diffrent architectures.
But that's actually what matters to the user.

@dcz You are partly right.

OTOH JITs are optimized for speed, while cargo build is optimized, well, for best optimized result. If you can get 2% faster output executable for 30% slower compilation, compiler might do it.

@pavel I benchmarked on a debug build, which should be about speed as well. Also that's the typical usage when coding. So I think it still checks out.