User avatar
paddyg
Posts: 2161
Joined: Sat Jan 28, 2012 11:57 am
Location: UK

rust version of pi3d (python graphics & 3D)

Mon Jun 04, 2018 7:03 pm

Anyone curious about rust (maybe after seeing the significant increase in speed with firefox quantum, or hearing that it will be the replacement for C/C++...!)?

As an experiment I've started converting the python module pi3d to rust. I'm trying to keep the structure of the code as much in step as possible so the differences are clear. Generally a surprising amount can be transferred over by swapping colons for curly brackets and putting semicolons at the ends of lines. lists become Vec<..> and dicts HashMap<.., ..>. The hardest aspect is not being able to create objects willy-nilly and rely on the garbage collector to tidy up at the end of the day - but that's one of the selling points of rust.

If anybody wants to see the code, or even better wants to help convert it, the original is at github.com/tipam/pi3d with demos at github.com/pi3d/pi3d_demos and the rust is at github.com/paddywwoof/rust_pi3d

I will start to add more documentation and bloglike narrative of the process.
link to youtube video
Attachments
rust_v_python_pi3d.jpg
rust_v_python_pi3d.jpg (50.81 KiB) Viewed 533 times
also https://groups.google.com/forum/?hl=en-GB&fromgroups=#!forum/pi3d

ejolson
Posts: 1840
Joined: Tue Mar 18, 2014 11:47 am

Re: rust version of pi3d (python graphics & 3D)

Tue Jun 05, 2018 2:36 am

paddyg wrote:
Mon Jun 04, 2018 7:03 pm
Anyone curious about rust (maybe after seeing the significant increase in speed with firefox quantum, or hearing that it will be the replacement for C/C++...!)?
Converting some Python code sounds like a nice way to learn rust.

I think one of the reasons Firefox quantum is faster is because of efficient multithreading. Have you thought how to parallelize the Python code?

User avatar
paddyg
Posts: 2161
Joined: Sat Jan 28, 2012 11:57 am
Location: UK

Re: rust version of pi3d (python graphics & 3D)

Tue Jun 05, 2018 7:26 am

good point. It depends, of course on where the bottlenecks are. Which is probably my next step (ie profiling). After a superficial test (varying polygons, pixels and number of objects to draw) The slow part on the RPI, at any rate, seems to be inside the new GL driver so building SDL to use the broadcom libbcm.so etc. files directly is something else that has to be investigated.

I suspect also that the GL function calls will have to stay in the main thread, so that leaves the matrix multiplication and so on required for each object... which immediately leads to a rethink of the ownership and mutable lending of the camera object to the shape objects in the draw function.
also https://groups.google.com/forum/?hl=en-GB&fromgroups=#!forum/pi3d

Return to “Other programming languages”

Who is online

Users browsing this forum: No registered users and 1 guest