RasPi 400 bonus benchmarks

Follow-up to Ruby raytracer on M1

While doing something else than I was planning to, I accedentally came back to the raytracer I once wrote in Ruby, and decided that the important thing just now is to benchmark my MacBook Pro M1 against those old results. I guess this will actually be Ruby 3 on M1 vs Ruby 2 on i7, because time happened.

I didn’t quite finish the bonus benchmarks, so for the sake of completeness, here we go. The missing ones for the RasPi 400.

Hard shadows

The Raspi only got a chance to show off with the heaviest of the benchmarks, so let’s see how it does in the lower end of teapot image quality.

Raspberry Pi 400 OC 2.2GHz (single threaded)

Single threaded performance still tracks at about the same ratio of 1/9 M1.

[1] pry(#<GlisteningRuby::DSL::Scene>)> render verbose:true
 Setup time: 1.375927773 s
Render time: 852.156157512 s
 Total time: 853.532085285 s

Raspberry Pi 400 OC 2.2GHz (multi-threaded)

This one would seem a bit unfair, because the RasPi 400 only gets 4 threads to do the work, instead of 8 threads for the other ones.

[2] pry(#<GlisteningRuby::DSL::Scene>)> render verbose:true, threads:4
 Setup time: 1.379623305 s
Render time: 292.012566677 s
 Total time: 293.392189982 s

The huge falloff in performance for those last 4 threads shows pretty clearly here. The RasPi 400 performance/thread scales pretty well at 3/4, given the huge overhead of the threaded renderer, but the M1 only did 4/8, and the i7 was even worse with 3/8.

Still, 4x M1 is more than 3x RasPi 400, so the total performance ratio when using every single bit of crunch there is, is less than 1/10 M1.

More interesting is that the RasPi 400 did the soft-shadows render at only 19x the time for hard-shadows, but the M1 took more than 21x the time. The passive thermal design of the RasPi 400 continues to amaze me, especially given the long history of overheated pies.

Next related

Ruby Raytracer on M2 Max

Tuesday, 2024-01-02 in discord about #raytracerchallenge, #raytracing, #ruby

A few years — and iterations of the Apple M-series — has passed, and I recently found myself in possession of a Mac Studio M2, in its base configuration of 8P + 4E CPU cores, and even more ridiculous1 amounts of cache. This monster has 87 MiB L1+L2+L3 cache in total. It can fit my entire first hard-drive (52 MB) in CPU cache. ↩

Previous related

Messy shadows

Sunday, 2019-12-08 in devlog about #devember, #devember2019, #hourofcode, #swift, #raytracing

Apparently, I messed up some more vector algebra. Ray / surface hits currently record the event in surface space, which works just fine for shading a unit sphere still positioned at origin. When we transform things around, and try to cast the secondary shadow rays, it becomes painfully obvious that surface space and world space no longer coincide.

All the things

Saturday, 2019-12-07 in devlog about #devember, #devember2019, #hourofcode, #swift, #raytracing

One limitation so far was that there could only be one surface in a scene. To get past that, we add the Group meta-surface, that contains a number of surfaces, and intersects with rays on their behalf. To make this actually useful, surfaces also need transforms to translate them out of their shared origin.

Light and Magic

Friday, 2019-12-06 in devlog about #devember, #devember2019, #hourofcode, #swift, #raytracing

The next natural step after getting basic shading to work is to have actual light sources, that can be tinted and positioned in the scene.