> a "low-overhead" parallelization library Who is out here building high-overhead parallelization libraries?
Relatively, Rayon is higher overhead
Show HN: Chili. Rust port of Spice, a low-overhead parallelization library
21–30 of 45 posts
Re: Show HN: Chili. Rust port of Spice, a low-overhead parallelization library
#22> a "low-overhead" parallelization library Who is out here building high-overhead parallelization libraries?
I have almost certainly built high overhead parallelization primitives during my junior years.
Re: Show HN: Chili. Rust port of Spice, a low-overhead parallelization library
#23Is there anything like ray.io in rust? Nobody running computations on clusters in rust?
Re: Show HN: Chili. Rust port of Spice, a low-overhead parallelization library
#24I would love to see a blog post or more detail about how this implementation works and why it can beat rayon in some cases.
The README of Spice has detailed explanation of the approach: https://github.com/judofyr/spice
Re: Show HN: Chili. Rust port of Spice, a low-overhead parallelization library
#25> a "low-overhead" parallelization library Who is out here building high-overhead parallelization libraries?
Yeah, why are those bastards writing slow code? They should just write fast code instead
Re: Show HN: Chili. Rust port of Spice, a low-overhead parallelization library
#26Out of curiosity, how do Spice/Chili/Rayon compare against the boring answer, OpenMP? I guess they must have some really neat capabilities.
Well, for one thing OpenMP is a c/c++ library, and chili and rayon are rust libraries.
It's probably possible to use openmp from rust, but the interface probably isn't as nice, you would need some kind of translation layer from rust closures and iterators to the OpenMP API
Re: Show HN: Chili. Rust port of Spice, a low-overhead parallelization library
#27Not related to the content, but as a port of "spice" -- being from New Mexico, we would usually refer to a spicy pepper as (eg green) "chile," or a chunky dish with beans and meat as (eg Texas) "chili." Looks like the AP Stylebook agrees, though Webster's makes it seem less clear, so you can probably get away with it either way.
> or a chunky dish with beans and meat as (eg Texas) "chili."
My understanding was that the name of the dish was short for "chili con carne" i.e. chili (the pepper) with meat
Re: Show HN: Chili. Rust port of Spice, a low-overhead parallelization library
#28Out of curiosity, how do Spice/Chili/Rayon compare against the boring answer, OpenMP? I guess they must have some really neat capabilities.
That’s what I was wondering. Iiuc openmp uses work stealing and the spice readme talks about the inefficiency of that:
https://github.com/judofyr/spice?tab=readme-ov-file#work-ste...
so I’d be interested in seeing a benchmark.
Re: Show HN: Chili. Rust port of Spice, a low-overhead parallelization library
#29Out of curiosity, how do Spice/Chili/Rayon compare against the boring answer, OpenMP? I guess they must have some really neat capabilities.
That’s what I was wondering. Iiuc openmp uses work stealing and the spice readme talks about the inefficiency of that: https://github.com/judofyr/spice?tab=readme-ov-file#work-ste... so I’d be interested in seeing a benchmark.
Reading the implementation details kinda got me wanting to do a c11 threads based port.
Re: Show HN: Chili. Rust port of Spice, a low-overhead parallelization library
#30Out of curiosity, how do Spice/Chili/Rayon compare against the boring answer, OpenMP? I guess they must have some really neat capabilities.
Well, for one thing OpenMP is a c/c++ library, and chili and rayon are rust libraries. It's probably possible to use openmp from rust, but the interface probably isn't as nice, you would need some kind of translation layer from rust closures and iterators to the OpenMP API
Plus Fortran!
There’d definitely be some work translating Rust concepts over. It might be impossible/not worth it. But maybe it would be nice to have Rust, C, and Fortran all talking to the same runtime?