> Scorn: > >> Hi bearophile. Thanks for your advice (i might try out ldc in the future >> but now i need phobos and not tango as standard library). > > I like DMD for some of the D2 features, for its speed, for allowing > exceptions to be used on Windows too, for its built-in profiler and code > coverage analyser that are not present in LDC, and for other small things, > but I like how LDC feels more like a real-world compiler, it has smaller > features like force_inline that look like coming out of a more practical > compiler. > > When I optimize code on LDC, I see predictable improvements of the > performance, while with DMD it's like a shoot in the dark, and I usually have > to avoid several tweaks of the code, otherwise I get a negative improvement. > >
I absolutely understand this :-) That is why i am using gdc at the moment and not dmd (with all of the very nice gcc optimizations flags for the gcc backend which improve speed substantially when comparing to dmd) >> But since all three dmd, ldc and gdc use the same frontend, the question >> from Trass3r still remains: >> Under which conditions are functions/methods inlined ? > > I think LDC doesn't use the inliner of the front-end and just uses the much > better inliner of the back-end. So the inling rules are probably all > different (but in theory the front-end knows more about the D semantics, so > LDC has to work even more to regain the lost semantics). > That would be nice. You nearly convinced me porting my project to tango and ldc. > Those inling rules of C# are nice and tidy (despite it doesn't inline virtual > methods, as Java HotSpot does. Aren't C# programmers complaining? C# > programmers don't look obsessed with performance, this is often positive), > but it's not easy to find them on most C/C++ compilers I know of. I do program a lot in C# myself (besides programming in a lot more languages) and when i program in C# i don't expect top-notch performance. Why ? It's because C#'s main purpose is being a rapid application-development language and it's very good for these kind of things. It's not meant to be used for high-performance numerical computing but astonishingly it is sometimes not so bad when you use it for this purpose. But D as a system-programming language with the ambition to be an alternative to C / C++ has, at least in the long term, to compete with C / C++ regarding these things. So when i consider using D for a project i do it because i am looking for an alternative for doing the same thing in C++ and not C#. And it makes me always very sad when i figure out that i can't use D successfully because of little flaws like this. And that means another chance of using D for a project is lost. That's why i like your posts about benchmarking so much. They might not be liked by parts of the community because they put the hook where it hurts most and might be annoying sometimes but please carry on :-) (you have at least one fan here :-) ). And please make a collection of all the issues you have found so far and but them on a web page somewhere. > Have you ever seen the exact inlining rules of C code compiled with GCC 4.4.3? > No i have not seen yet the exact inlining rules of C code compiled with GCC 4.4.3. But i don't need them and i don't care. Why ? Because gcc does its job well without me knowing anything about the heuristics it uses for inlining. For D it's different. I have found so many times that i can increase the speed of the generate code in D tremendously by just inlining small pieces of code manually (or using mixins). Something i have never found using any C++ compiler (they do it so much better than i ever could). So i think that's why Trass3r and i are so interested in the rules D uses for inlining. > >> Do you know if ldc inlines functions/methods across modules ? (dmd >> doesn't seem to do it and neither does gdc). > > I have just done a test, normally LDC is not able to inline across modules. > This is a shitty situation. You are absolutely right here. That is a shitty situation for all D compilers. Because it basically means that your are not able to do decent software engineering practices (a clean separation of functionality in different modules) without sacrifying performance. That is a situation you have in no other language i know of and this is a big design flaw of the module system making it nearly senseless. > But with LDC you can perform Link-Time Optimization too (but you have to ask > for it!), that in my test I've just seen is able to inline across modules. > Which compiler switches do you need for this ? > >> And that is bad since for an actual project i have made a separate >> module with a lot of small utility math functions which should be >> inlined but don't because of this. When i inline them using mixins or >> manually i get an overall speed up of about 20%. > > If you explain this problem to Walter he will surely tell you that such > inlining can't be done because mumble mumble separate compilation mumble > mumble was done fifteen years ago mumble mumble mumble (even if LDC is > currently doing it) :-) :-) (Big smile.) Yes. That's what i would expect. But the whole thing is easy solvable by not doing just a separate compilation of the modules and then linking them together but by including the source code content of a module file in another module file which does import it (like a C or C++ compiler includes files). Then every function / method needed is visible while compiling the module and the compiler can decide by using its heuristics if a function / method is worth inlining or not. The compile times might be a bit longer but since the grammar of D is much simpler than C++ it would not hurt compile time so much. > > Good luck, > bearophile Thanks. Good luck for you too. But for this project i think i will abandon D and stick to C++ again (even if i hate to do so) because the only options would be using mixins all over the place or put everything in one big file (and both solutions are ugly). Thanks for your help.
