07-Dec-2013 13:32, Johannes Pfau пишет:
Am Sat, 07 Dec 2013 03:12:02 +0400
schrieb Dmitry Olshansky <dmitry.o...@gmail.com>:
07-Dec-2013 02:20, Walter Bright пишет:
"there is no way proper C code can be slower than those languages."
3. Function inlining has generally been shown to be of tremendous
value in optimization. D has access to all the source code in the
program, or at least as much as you're willing to show it, and can
inline across modules.
Uh-oh. I'd avoid advertising this particular point until after a
critical bug is fixed:
https://d.puremagic.com/issues/show_bug.cgi?id=10985
Applies to all 3 compilers.
Otherwise - it's spot on. D has many ways to be typically "faster
then Cee" ;)
But cross-module inlining can't be done if you have shared libraries
cause you can not know if the other module is in a shared library right?
I've no idea how would compiler do inlining of a shared library
internals. I believe it can inline everything in the same library that
is not exported, right? (Is that your point (1) ?)
If you inlined such code it wouldn't get updated if the shared library
was updated and you'd have two versions of the code around...
Then some critical stuff simply must not be called via shared library
and better be translated to ... 0-argument templates.
Use cases: std.ascii and not only that. Checking ASCII isAlpha as a
_function call_ is madness.
I see only 2 solution to avoid this:
(1) If the source files are compiled at once it's safe to assume they
must be part of the same library and inlining is safe
(2) The linker of course knows how objects fit together, so LTO.
--
Dmitry Olshansky
