botan icon indicating copy to clipboard operation
botan copied to clipboard

Slow build using DMD with release switch

Open tchaloupka opened this issue 9 years ago • 5 comments

dub build --config=32mscoff -b release

It takes over 3 minutes to build for me.

dmd params are: -m32mscoff -lib -release -inline -O -w

if -inline is removed, it builds within 12s. On the linux it is a similar story.

DMD version: 2.068.0 OS: Windows 8.1 x86_64

I've posted this upstream: https://issues.dlang.org/show_bug.cgi?id=14939 But as an user only, I have no idea what's wrong or how can I help with it.

I guess that botan is so complex that dmd optimisations in release slows it down too much, but.. I event thought originally, that it is stuck, because dmd used just about 15% of CPU, but it actually compiled with enough time..

tchaloupka avatar Sep 01 '15 18:09 tchaloupka

I've come to the conclusion that DMD release will not be a good target considering the performance implications. Once LDC compatibility is completed, I will be issuing warnings during compilation if DMD release is used.

Ideally, an LDC release built library can work with DMD debug/plain build applications.

etcimon avatar Sep 01 '15 19:09 etcimon

dmd spends most of it's time in accumaecpx which is know to be quadratic, maybe it is easy to workaround by splitting a few functions. Issue 7157 – Optimiser is O(n^2) w.r.t. function length

MartinNowak avatar Nov 07 '15 19:11 MartinNowak

I currently can't get it working with the new botan_math in release or plain, but in build debug it works fine. It's easy to replace the .a file when linking the test, it should have helped optimize the bottleneck but no luck here. Any idea how to debug this? The problem would be in one of the assembly operations

etcimon avatar Nov 07 '15 21:11 etcimon

Yes, compile with -v and see where dmd hangs.

DFLAGS='-O -release -inline -v' dub build

botan.block.serp_simd.serpent_encrypt_4 botan.block.serp_simd.serpent_decrypt_4

MartinNowak avatar Nov 07 '15 22:11 MartinNowak

DMD 2.047.1 also stucks (for a shorter period) at sha2_64.compress.

nametoolong avatar Jun 04 '17 09:06 nametoolong