Help optimize D solution to phone encoding problem: extremely slow performace.

evilrat evilrat666 at gmail.com
Fri Jan 19 10:15:57 UTC 2024


On Friday, 19 January 2024 at 09:08:17 UTC, Renato wrote:
>
> I forgot to mention: the Java version is using a Trie... and it 
> consistently beats the Rust numeric algorithm (which means it's 
> still faster than your D solution), but the Java version that's 
> equivalent to Rust's implementation is around 3x slower... i.e. 
> it runs at about the same speed as my current fastest numeric 
> algorithm in D as well.
>
> This is what I would like to be discussing in this thread: why 
> is D running at Java speeds and not at D speeds when using the 
> same algorithm? I know there's small differences in the 
> implementations, they are different languages after all, but 
> not enough IMO to justify anything like 3x difference from Rust.
>

My guess is that's because int128 is not that much optimized due 
to being not so popular type, though to answer what's wrong would 
require to look at assembly code produced for both D and Rust.

Additionally if you comparing D by measuring DMD performance - 
don't.
It is valuable in developing for fast iterations, but it lacks 
many modern optimization techniques, for that we have LDC and GDC.


More information about the Digitalmars-d-learn mailing list