Paid gig: port 2,200 lines of clean C++ to Rust


#5

Also it’s fun!


#6

If the C++ library had an active maintainer or any kind of sec audit history, I’d be against RIIR, and would just write bindings.

I plan to use this in an image proxy, so unverified C++ isn’t appetizing.

A Rust version is easier to integrate with my build system, easier for me to maintain, and easier for me to audit.

AFAICT, there’s no upstream; Seeta just did a one-time code dump.


#7

Will you be the active maintainer of rusty-face ?


#8

if you need a maintainer. ping me :slight_smile:


#9

I’m so sorry, I didn’t see the code wasn’t maintained!
Go for it then ! This is a perfect occasion, I will look into the code as you progress, but I don’t don’t know anything in this subject and I’m quite occupied.
This will be a cool project.


#10

Good luck being the RIIR Police :policeman:


#11

The C++ Seeta can be built using SSE. Is x86 your target platform as well?
And, a porting would also require some test-vectors that are known to work for the original code.


#12

HAHA! I don’t think I can do it. Actually I was tired when I wrote that, now that I thought about it, I don’t care. People can make what they want, RIIR is just annoying for maintainers of projects that get told: “Why not convert it in Rust, it’s way better than insert language here”.

Thinking about it, I learned Rust by doing this: Taking a project of mine (done in PHP of all things) and converting it to Rust. I now have a backend for my website that can do way more things that it ever could.


#13

Yeah true. Well it depends. It makes sense only when you see a clear advantage of writing something in Rust over another language.


#14

Hey is a nice project!!!

are you using an existing Image processing library for Rust?


#15

I’m thinking that I’ll eventually use this in imageflow (which focuses on server environments).

Imageflow targets x86, x86_64, x86_64 + haswell (AVX) , x86_64 + sandybridge (AVX2), so those are the targets I care the most about.

SIMD acceleration would be great. I haven’t really evaluated any crates for that, but https://github.com/AdamNiederer/faster and the standard SIMD crate seem promising.

I’m up for using any Rust crates that are reasonably safe.

As far as the timeline, within 60 days would be ideal. I’m open to the ideal of a longer deadline at lower cost - I may create a temporary C API and bindings in that case, though.


#16

Since I’m being quoted as the “don’t RIIR” point, I’d like to add a “needlessly” in there :wink:
The quote is from a discussion about giving (massive, countless personyears) IDE’s the rust treatment. This seems to be a very well defined, small task, so my worries are similarly smaller.

Having said that, I’m not sure if it’s already the right time for face detection in Rust. Anything doing image analysis will probably want to wait for stable SIMD to land. SIMD is practically a hard requirement for performance in anything doing image processing. I didn’t check the original code, but if @frehberg says it uses SSE, I believe that qualifies…

Having it in cargo and thread safety might be very valid reasons for the use case, I can’t judge from here :slight_smile:

I AM very happy to see people willing to put their money where their mouth is on Rust. Kudos to @lilith for that!


#17

Use in wasm could be a good reason to port it.


#18

I hear you about timing. I started imageflow way too early in Rust’s development, and it bit me harder than I can politely describe. But this seems comparatively simple.

I’m OK with requiring a nightly compiler, and I can move it over to stable once it’s practical.

A few more notes:

I’m also OK with depending on pre-1.0 third party crates, as long as they are “reasonably safe” - i.e., the scope of thier unsafe bits is easy to verify. SIMD crates would qualify, for example, as they don’t (AFAICT) corrupt lifetimes.

Documentation can be minimal - I would want unexpected and non-obvious things documented. It’s a simple interface.

For testing, pairs of images and result rectangles should be fine. (i.e, we can generate a CSV based on the C++ code and compare it to the rust CSV).

There are many good image sets, but http://mmlab.ie.cuhk.edu.hk/projects/WIDERFace/ seems the most diverse.

The budget is $1,500 USD (most bids have been under this amount anyway).

My suggestion would be to expose a 1 or 2 method C API and bind it so that Rust test code can be reused.

If the bound API is usably functional, then the timeline can be 90 days instead of 60. If the developer is uncomfortable with binding C I can make them.


#19

I can’t commit to doing the project on my own, but if the port is open source I’d at least like to help.

I am much more familiar with C++ than Rust (much to my dismay).


#20

Hi guys, @kornel gave me a link to this topic in response to my request for small project ideas, so I decided to give it a try. Here’s a link to github: https://github.com/atomashpolskiy/rustface. Please disregard the pic for now, I just could not stand the temptation to make it look stylish (kinda) :slight_smile:

On the serious note, the code seems to work, but I haven’t been able to use SSE and OpenMP yet. The tests are also lacking; it should not be difficult to add ITs, which I’m going to address shortly, but creating unit tests might be a bit tricky, considering that in many cases the tested function operates on pointers and binary buffers.


#21

So I spent some time today integrating SIMD support (which required to switch to nightly toolchain, unfortunately), just to find out that, surprisingly, this does not really provide a significant performance boost. Speedup is somewhere around 10%, and cross-checking with the C++ version yields approximately the same results (10-15% performance decrease with SIMD turned off). I suspect that in order to catch up with C++ it would be necessary to also use parallelization (which is achieved in the original by using OpenMP). Does anyone know, what’s considered hip in this regard in contemporary Rust?


#22

Rayon is a popular choice, it mostly uses the same design principles as Intel TBB if you are familiar with that.


#23

Thanks for the advice, parallel iterators seem to be exactly what’s needed


#24

I’ve finally found the problematic place, that have been ruining the performance. Now the Rust version outperforms the original by 4-5%. See for yourself