On Monday, 15 January 2024 at 01:10:14 UTC, Sergey wrote:
On Sunday, 14 January 2024 at 17:11:27 UTC, Renato wrote:
If anyone can find any flaw in my methodology or optmise my
code so that it can still get a couple of times faster,
approaching Rust's performance, I would greatly appreciate
that! But for now, my understanding is that the most promising
way to get there would be to write D in `betterC` style?!
I've added port from Rust in the PR comment. Can you please
check this solution?
Most probably it need to be optimized with profiler. Just
interesting how close-enough port will work.
As discussed on GitHub, the line-by-line port of the Rust code is
5x slower than [my latest solution using
int128](https://github.com/renatoathaydes/prechelt-phone-number-encoding/blob/0cbfd41a072718bfb0c0d0af8bb7266471e7e94c/src/d/src/dencoder.d), which is itself 3 to 4x slower than the Rust implementation (at around the same order of magnitude as algorithm-equivalent Java and Common Lisp implementations, D is perhaps 15% faster).
I did the best I could to make D run faster, but we hit a limit
that's a bit hard to get past now. Happy to be given suggestions
(see profiling information in previous messages), but I've run
out of ideas myself.
