https://benchmarksgame-team.pages.debian.net/benchmarksgame/...
crb-vec-omp //I added some #pragma omp to crb-vec
executable size:
18k
time:
real 0m3.630s
valgrind:
==17703== HEAP SUMMARY:
==17703== in use at exit: 7,408 bytes in 15 blocks
==17703== total heap usage: 20 allocs, 5 frees,
14,790,856 bytes allocated
rsrb_alt_mt.rs
executable size:
426k
time:
real 0m1.630s
valgrind:
==7221== HEAP SUMMARY:
==7221== in use at exit: 43,120 bytes in 216 blocks
==7221== total heap usage: 256 allocs, 40 frees,
11,113,784 bytes allocated
:~# time ./rsrb_alt_mt
./rsrb_alt_mt: /lib64/libc.so.6: version `GLIBC_2.18' not
found (required by ./rsrb_alt_mt)
real 0m0.002s
user 0m0.002s
sys 0m0.000s
:~# time ./crb-vec-omp
real 0m24.234s
user 0m24.160s
sys 0m0.035s
bool hit_sphere(const struct sphere* sp, const struct ray* ray, struct hit* hit)
static bool
hit_sphere(struct sphere sp, struct ray ray, struct hit hit)
which is more than twice as fast as the rust example,
but it didn't create the right output...
if you get bored would you mind taking a stab at adding parallel and modifying crb-vec.c https://github.com/niofis/raybench , I definitely think you might be on to something here.
The difference isn't much. And Rust is more like FORTRAN. Maybe a bit faster than C, but can't do the gymnastics with pointers that C can.
It can if you write the "unsafe" keyword, but there's a pretty strong community norm around not doing that sort of thing, unless you can encapsulate it inside some sort of safe API. And to be fair to C, I think C can close the gap with Rust/Fortran if you use the "restrict" keyword a lot?
Without unsafe, there’s significantly more aliasing information, which helps optimizations.