Announcing Sodium Rust v2.0

[clinuxrulz]

Sodium Rust v2.0 is now available to try out!

Memory management is less of a headache now compared to v1.0.

• No more need to use Gc / NoGc wrappers around values you pass through sodium objects.
• No more need to implement Trace / Finalize traits for the types of values you pass through sodium objects.
• No ranks or priority queue (fast switching switchS / switchC).
• More memory safe. No more false positive cycles causing seg faults. (In case of mistake in memory dependencies passed to lambda1,lambda2,etc.)

[dakom]

I haven't been around in a while... tbh not really doing much Sodium these days... but just jumped on the forum to see what's up.

Nice to see you made progress here, congrats on the release!

[clinuxrulz]

Thanks.

I'm doing the same with C++ at the moment. Hoping to get through it this time.

https://github.com/clinuxrulz/sodium-cxx-alt

Then maybe swift if I feel up to it.

@cubuspl42 has had some luck with his alternative TypeScript implementation with about 50x speed boost for his use case. Just needs to be polished off for production use.

I should switch off logging in the rust version, as it will probably hurt performance. (printf debugging code). Hopefully it can be done with just a flag somewhere, so I can still debug it later.

Maybe I'll add sodium_ctx.set_verbose(true); to the API for debugging. Because I'd still like to debug it for any issues found externally from another application that is using it.

[cubuspl42]

Please note that the mentioned speed boost was only observed with my application. It's quite possible that that solution has some scaling limit. I suspect that the two algorithms (linear one and priority queue based one) can be merged into a hybrid having benefits of both algorithms (smaller constant of the linear one and better big O complexity of the pq-based). I'll reasearch that when I'll have problems in practice.

[clinuxrulz]

What we really need for the long run are some benchmarks, and to abstract away the evaluation strategy so performance comparisons can be made.

JavaScripts v8 engine (chromium browsers) will AOT compile the code into fast native assembly where it is able to infer the types. Parts that can not be inferred get interpreted (well a slower variant type in native). So performance in JS is really unpredictable. The variant typed parts can be 6 times slower than the true proper native types. And maybe the priority queue escaped what can be compiled into native. Not the best explanation.