[Issue 14758] TypeInfo causes excessive binary bloat
https://issues.dlang.org/show_bug.cgi?id=14758 --- Comment #7 from Dmitry Olshansky dmitry.o...@gmail.com --- (In reply to Mike from comment #6) (In reply to Sobirari Muhomori from comment #5) And compile with -O2 or -Os Doesn't work. See http://forum.dlang.org/post/quemhwpgijwmqtpxu...@forum.dlang.org Yes, but try without classes. --
[Issue 14939] New: dmd slow build of botan library with -inline and -O
https://issues.dlang.org/show_bug.cgi?id=14939 Issue ID: 14939 Summary: dmd slow build of botan library with -inline and -O Product: D Version: D2 Hardware: x86_64 OS: Windows Status: NEW Severity: normal Priority: P1 Component: dmd Assignee: nob...@puremagic.com Reporter: chalu...@gmail.com Just clone the https://github.com/etcimon/botan library Run 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 --
[Issue 14758] TypeInfo causes excessive binary bloat
https://issues.dlang.org/show_bug.cgi?id=14758
--- Comment #2 from Mike slavo5...@yahoo.com ---
(In reply to Dmitry Olshansky from comment #1)
I'd just go for structs + template mixins for inheritance. It's not like you
do any of virtual calls/typeinfo/object factory/whatever.
mixin template Register(blah...){ }
struct Peripheral{
mixin Register!(x,y,z,...);
mixin Register!(q,w,e,...);
}
Makes any sesne?
Yes, it makes sense, but it is not my preference, and is beside the point of
this issue. Furthermore, with your suggestions, you will still have a new type
for each peripheral, and therefore unwanted TypeInfo bloat for each and every
one of those peripherals.
The compiler/linker should generate efficient code using my pattern, and I
shouldn't have to compromise. Nor should I have to add stubs for runtime
features that have no hope of every being used. Rust does a good job with
this, and I don't see why I should have to lower my expectations for D.
--
[Issue 14758] TypeInfo causes excessive binary bloat
https://issues.dlang.org/show_bug.cgi?id=14758 --- Comment #3 from Sobirari Muhomori dfj1es...@sneakemail.com --- I have an impression that LDC doesn't generate TypeInfo for structs for me (because when it does, linking fails), if I don't use array comparisons and disable opEquals. The Rust argument is valid though :) --
[Issue 14758] TypeInfo causes excessive binary bloat
https://issues.dlang.org/show_bug.cgi?id=14758 --- Comment #8 from Sobirari Muhomori dfj1es...@sneakemail.com --- I mean -O0 leaves all junk intact, so at least with LDC -Os is required for successful linking (or maybe it was required before I wrote needed druntime functions? will see). I didn't try to use classes yet (wonder what I would do when I need polymorphism). --
[Issue 14758] TypeInfo causes excessive binary bloat
https://issues.dlang.org/show_bug.cgi?id=14758 Walter Bright bugzi...@digitalmars.com changed: What|Removed |Added Keywords||performance CC||bugzi...@digitalmars.com --- Comment #9 from Walter Bright bugzi...@digitalmars.com --- Partial fix: https://github.com/D-Programming-Language/dmd/pull/4912 --
[Issue 14758] TypeInfo causes excessive binary bloat
https://issues.dlang.org/show_bug.cgi?id=14758 --- Comment #5 from Sobirari Muhomori dfj1es...@sneakemail.com --- And compile with -O2 or -Os --
[Issue 14758] TypeInfo causes excessive binary bloat
https://issues.dlang.org/show_bug.cgi?id=14758
Dmitry Olshansky dmitry.o...@gmail.com changed:
What|Removed |Added
CC||dmitry.o...@gmail.com
--- Comment #1 from Dmitry Olshansky dmitry.o...@gmail.com ---
I have modeled these statically with D's fantastic modelling features to
produce an object-oriented, easily-navigable hierarchy of the hardware memory
map (example:
https://github.com/JinShil/stm32f42_discovery_demo/blob/master/source/stm32f42/gpio.d).
It is an excellent model that generates fast code and plays very well with
tooling. The only problem is the TypeInfo bloat.
I'd just go for structs + template mixins for inheritance. It's not like you do
any of virtual calls/typeinfo/object factory/whatever.
mixin template Register(blah...){ }
struct Peripheral{
mixin Register!(x,y,z,...);
mixin Register!(q,w,e,...);
}
Makes any sesne?
--
[Issue 14943] dmd should inline more aggressively
https://issues.dlang.org/show_bug.cgi?id=14943 --- Comment #1 from hst...@quickfur.ath.cx --- Further notes: - gdc not only inlines the call trees of .empty, .front, .popFront, it also applied other loop optimizations like strength reduction to refactor the a = a*7 into a += b; b += 7. Not sure if dmd is capable of doing this, but in any case the opportunity is missed because .popFront was not inlined, so the optimizer wouldn't have been able to apply strength reduction. - gdc's aggressive inlining also allowed various loop counters and accumulators to be completely held in registers, while the function calls generated by dmd necessitated dereferencing addresses to stack variables, which is an extra layer of indirection. Again, a missed opportunity due to not inlining aggressively enough. For reference, here's the inner loop produced by gdc: 403b80: 89 d7 mov%edx,%edi 403b82: c1 ef 1fshr$0x1f,%edi 403b85: 8d 34 3alea(%rdx,%rdi,1),%esi 403b88: 83 c2 07add$0x7,%edx 403b8b: 83 e6 01and$0x1,%esi 403b8e: 39 fe cmp%edi,%esi 403b90: 75 1e jne403bb0 int test.fun(int)+0x80 403b92: 89 c6 mov%eax,%esi 403b94: 8d 14 cd 00 00 00 00lea0x0(,%rcx,8),%edx 403b9b: c1 ee 1fshr$0x1f,%esi 403b9e: 01 f0 add%esi,%eax 403ba0: 29 ca sub%ecx,%edx 403ba2: d1 f8 sar%eax 403ba4: 01 d0 add%edx,%eax 403ba6: 83 c2 07add$0x7,%edx 403ba9: 0f 1f 80 00 00 00 00nopl 0x0(%rax) 403bb0: 83 c1 01add$0x1,%ecx 403bb3: 39 cb cmp%ecx,%ebx 403bb5: 75 c9 jne403b80 int test.fun(int)+0x50 --
[Issue 14938] std.net.curl tests should use localhost or stub any networking
https://issues.dlang.org/show_bug.cgi?id=14938 --- Comment #2 from Martin Nowak c...@dawg.eu --- Though std.socket mostly does DNS resolution. Maybe use HOSTALIASES on non-Windows systems. It doesn't make much sense to test the actual DNS resolution anyhow, as the purpose is to test the correct usage of gethostbyname et. al. --
[Issue 14925] replaceInPlace fail compilation
https://issues.dlang.org/show_bug.cgi?id=14925 --- Comment #5 from github-bugzi...@puremagic.com --- Commits pushed to master at https://github.com/D-Programming-Language/phobos https://github.com/D-Programming-Language/phobos/commit/ea811edab97021c9328dd2e81c49bba23c414b4d Supplemental fix for issue 14925 - remove redundant conditions https://github.com/D-Programming-Language/phobos/commit/de2df2bb04dfc4667ab0bac30425b9c14d6cb699 Merge pull request #3565 from 9rnsr/fix14925 Supplemental fix for issue 14925 --
[Issue 13936] groupBy must be redone
https://issues.dlang.org/show_bug.cgi?id=13936 hst...@quickfur.ath.cx changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #50 from hst...@quickfur.ath.cx --- Since nobody objects, I'm going to resolve this now. --
[Issue 14943] New: dmd should inline more aggressively
https://issues.dlang.org/show_bug.cgi?id=14943
Issue ID: 14943
Summary: dmd should inline more aggressively
Product: D
Version: D2
Hardware: x86_64
OS: Linux
Status: NEW
Severity: enhancement
Priority: P1
Component: dmd
Assignee: nob...@puremagic.com
Reporter: hst...@quickfur.ath.cx
/* Crude benchmark for comparing dmd/gdc output. */
import std.algorithm : map, filter, reduce;
import std.conv : to;
import std.range : iota;
import std.stdio : writeln;
auto fun(int n)
{
return iota(n)
.map!(a = a*7)
.filter!(a = a % 2 == 0)
.reduce!((a,b) = a/2 + b);
}
void main() {
writeln(fun(100_000_000));
}
/* RESULTS:
Compiled with:
dmd -release -O -inline test.d -oftest.dmd
gdc -frelease -finline -O3 test.d -o test.gdc
(dmd git HEAD, gdc 5.2.1)
Execution times:
% time test.dmd ; time test.gdc
139944
real0m0.628s
user0m0.627s
sys 0m0.001s
139944
real0m0.168s
user0m0.167s
sys 0m0.000s
%
As can be seen, the executable produced by gdc runs about 3.7 times faster than
the executable produced by dmd. Why?
Looking at the disassembly, the first thing that stands out is that gdc has
inlined the call to writeln, whereas dmd calls a separate function. While this
isn't the bottleneck, it gives a hint of the things to come. We look next at
fun(), which in both cases are standalone functions.
The dmd version of fun() is pretty straightforward: it calls iota() to create
the range, then map(), then filter(), and finally reduce() where most of the
work takes place. This is pretty much a direct translation of the code.
The gdc version of fun() is markedly different. We immediately notice that the
only function call in it is a call to enforce(). Not only the first level calls
to iota, map, filter, reduce have been inlined, pretty much their *entire* call
trees have been inlined, except for the call to enforce().
Here I'd like to highlight the fact that in the dmd version of the code, the
call to iota() has another function call to the ctor of the returned range. So
we see that gdc has inlined two levels of function calls where dmd has inlined
none, even though one would expect that with -inline, at least the call from
iota() to the ctor of the range should have been inlined, since it's the only
place where that ctor would be called; iota() itself being merely a thin
wrapper around it. (The ctor itself is also pretty simple; I'm not sure why dmd
fails to inline it.)
Similar remarks apply to the calls to map() and filter() as well.
Now let's look at reduce(), which is where the actual action takes place. The
dmd version, of course, involves a separate function call, which in the grand
scheme of things isn't all that important, since it's only a single function
call. However, a look at the disassembly of reduce() shows that dmd has not
inlined the calls to .empty, .front, and .popFront. In fact, the function calls
yet another function -- reduceImpl -- where the main loop sits. Inside this
main loop, .empty, .front, and .popFront are again called with no inlining --
even though .empty has a trivial body, .front involves only 1 multiplication,
and .popFront only 1 multiplication and a single odd/even test. On top of
this, each of these nested function calls involve a certain amount of
boilerplate: twiddling with the stack registers, shuffling call arguments
about, etc., that add up to quite a large overhead in reduceImpl's inner loop.
The gdc version, by contrast, inlines *everything*, except the call to
enforce() which is outside the inner loop. This aggressive inlining allowed gdc
to trim the loop body down to about only 18 instructions with no function
calls. While the dmd inner loop itself has only 15 instructions, it involves 3
function calls, with .front having 8 instructions, .empty also 8 instructions,
and .popFront 13 instructions, making a total of 44 instructions per iteration.
A significant percentage of these instructions are function call boilerplate.
The entire inner loop in the gdc version would fit in about 4-5 CPU cache
lines, whereas the dmd version would require a lot more.
To dmd's credit, it did manage to inline the nested calls in .empty, .front,
and .popFront(), which would have involved more function calls when no inlining
at all is done (each wrapper range forwards the calls to the next). This
probably helped to reduce the cost of running their respective function bodies.
However, this isn't quite enough, since the overhead of 3 function calls in the
inner loop is pretty expensive when the cost could have been eliminated
completely, as gdc had done.
*/
--
[Issue 14943] dmd should inline more aggressively
https://issues.dlang.org/show_bug.cgi?id=14943 hst...@quickfur.ath.cx changed: What|Removed |Added Keywords||performance --
[Issue 14940] Can't call logger with more complex objects
https://issues.dlang.org/show_bug.cgi?id=14940 --- Comment #1 from Marenz dmdtrac...@supradigital.org --- Other problems are for example when trying to print the json object that vibe.d gives the handler. Results in the same error. --
[Issue 14935] [Operator Overloading] Wrong description on overloading a[]
https://issues.dlang.org/show_bug.cgi?id=14935 --- Comment #6 from Ryuichi OHORI r.97...@gmail.com --- I agree with you on closing this as invalid. The main problem was that I missed opIndexOpAssign and tried to use opIndex/opSlice (of a struct S) + opOpAssign (of the returning Voldemort type of S.opIndex). While I went wrong, the error message cannot be sliced with [] is not so helpful as to help me figuring out the problem. One of the reasons I missed opIndexOpAssign was that it is categorized under Op Assignment Operator Overloading. I'd like to place it under Array Indexing and Slicing Operators Overloading. --
[Issue 14940] New: Can't call logger with more complex objects
https://issues.dlang.org/show_bug.cgi?id=14940
Issue ID: 14940
Summary: Can't call logger with more complex objects
Product: D
Version: D2
Hardware: x86_64
OS: Linux
Status: NEW
Severity: enhancement
Priority: P1
Component: phobos
Assignee: nob...@puremagic.com
Reporter: dmdtrac...@supradigital.org
I can't call the logger with any more complex objects. It used to work in the
older version in the dedicated repository before it was merged into phobos.
Example code:
import std.experimental.logger.filelogger;
import std.typecons: Nullable;
import std.stdio;
void main ( )
{
Nullable!int a = 1;
auto l = new FileLogger(stdout);
l.infof(log: %s, l);
}
Error:
phobos/std/experimental/logger/core.d(1121): Error: safe function
'std.experimental.logger.core.Logger.memLogFunctions!cast(LogLevel)cast(ubyte)64u.logImplf!(11,
main.d, main.main, void main.main(), main, FileLogger).logImplf' cannot
call system function 'std.format.formattedWrite!(MsgRange, char,
FileLogger).formattedWrite'
main.d(11): Error: template instance
std.experimental.logger.core.Logger.memLogFunctions!cast(LogLevel)cast(ubyte)64u.logImplf!(11,
main.d, main.main, void main.main(), main, FileLogger) error
instantiating
--
[Issue 14942] New: dmd linking error with SHA and SSSE3
https://issues.dlang.org/show_bug.cgi?id=14942
Issue ID: 14942
Summary: dmd linking error with SHA and SSSE3
Product: D
Version: D2
Hardware: x86_64
OS: Linux
Status: NEW
Severity: normal
Priority: P1
Component: dmd
Assignee: nob...@puremagic.com
Reporter: chalu...@gmail.com
I have a strange problem with building vibe.d in debug[0]
As I updated to dmd-2.068 and the problem remains, I tried to minimize the test
case and here it is.
Code:
import std.digest.sha;
void main() {
SHA1 hash;
hash.put(cast(ubyte)0);
hash.finish();
}
And now with commands generated by dub:
dmd -c -oftest.o -debug -g -w app.d
dmd -oftest test.o -L--no-as-needed -g
Results in:
test.o: In function `std.digest.sha.SHA!(512, 160).SHA._sharedStaticCtor330()':
/opt/dmd-2.068/import/std/digest/sha.d:224: undefined reference to
`std.internal.digest.sha_SSSE3.transformSSSE3(uint[5]*, const(ubyte[64])*)'
In release, problem does not occur. It's also ok with ldc2-0.15.1
DMD version: v2.068.0
OS: Gentoo linux x86_64
CPU: i5-2500K SandyBridge (with SSSE3)
Config [/opt/dmd-2.068/bin/dmd.conf]:
[Environment]
DFLAGS=-I/opt/dmd-2.068/import -L--export-dynamic -defaultlib=phobos2
-L--demangle=dlang
[Environment32]
DFLAGS=%DFLAGS% -L-L/opt/dmd-2.068/lib32 -L-rpath -L/opt/dmd-2.068/lib32
[Environment64]
DFLAGS=%DFLAGS% -L-L/opt/dmd-2.068/lib64 -L-rpath -L/opt/dmd-2.068/lib64
[0] https://github.com/rejectedsoftware/vibe.d/issues/1097
--
[Issue 14942] dmd linking error with SHA and SSSE3
https://issues.dlang.org/show_bug.cgi?id=14942 --- Comment #1 from Tomáš Chaloupka chalu...@gmail.com --- linking output with -v switch: binarydmd version v2.068.0 config/opt/dmd-2.068/bin/dmd.conf gcc test.o -o test -g -m64 -Xlinker --no-as-needed -Xlinker --export-dynamic -Xlinker --demangle=dlang -L/opt/dmd-2.068/lib64 -Xlinker -rpath -Xlinker /opt/dmd-2.068/lib64 -lphobos2 -lpthread -lm -lrt test.o: In function `std.digest.sha.SHA!(512, 160).SHA._sharedStaticCtor330()': app.d:(.text._D3std6digest3sha20__T3SHAVii512Vii160Z3SHA20_sharedStaticCtor330FNbNiNfZv+0x45): undefined reference to `std.internal.digest.sha_SSSE3.transformSSSE3(uint[5]*, const(ubyte[64])*)' --
[Issue 14941] dmd rejects op assignment to opIndex expression
https://issues.dlang.org/show_bug.cgi?id=14941 Kenji Hara k.hara...@gmail.com changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |DUPLICATE --- Comment #1 from Kenji Hara k.hara...@gmail.com --- *** This issue has been marked as a duplicate of issue 14624 *** --
[Issue 14624] The array operator overloading fallback is not correct
https://issues.dlang.org/show_bug.cgi?id=14624 Kenji Hara k.hara...@gmail.com changed: What|Removed |Added CC||ag0ae...@gmail.com --- Comment #2 from Kenji Hara k.hara...@gmail.com --- *** Issue 14941 has been marked as a duplicate of this issue. *** --
[Issue 10378] Local imports hide local symbols
https://issues.dlang.org/show_bug.cgi?id=10378 Sobirari Muhomori dfj1es...@sneakemail.com changed: What|Removed |Added Keywords||spec URL||http://dlang.org/module.htm ||l --- Comment #13 from Sobirari Muhomori dfj1es...@sneakemail.com --- Currently documented to work this way. --
[Issue 14758] TypeInfo causes excessive binary bloat
https://issues.dlang.org/show_bug.cgi?id=14758 --- Comment #6 from Mike slavo5...@yahoo.com --- (In reply to Sobirari Muhomori from comment #5) And compile with -O2 or -Os Doesn't work. See http://forum.dlang.org/post/quemhwpgijwmqtpxu...@forum.dlang.org --
[Issue 14941] New: dmd rejects op assignment to opIndex expression
https://issues.dlang.org/show_bug.cgi?id=14941
Issue ID: 14941
Summary: dmd rejects op assignment to opIndex expression
Product: D
Version: D2
Hardware: x86_64
OS: Linux
Status: NEW
Keywords: rejects-valid
Severity: normal
Priority: P1
Component: dmd
Assignee: nob...@puremagic.com
Reporter: ag0ae...@gmail.com
Found by Ryuichi OHORI, see issue 14935.
struct V
{
void opOpAssign(string op)(int x) {}
}
struct S
{
V opIndex() {return V();}
}
void main()
{
S s;
auto v = s[];
v += 2; /* no error */
s.opIndex() += 2; /* no error */
s[] += 2; /* Error: S cannot be sliced with [] */
}
Clearly, S can be sliced with []. And a V can be add-assigned. The compiler
seems to give up when there's opIndexOpAssign for S, but it should try
opIndex+opOpAssign, too.
Also fails in the same manner when S.opIndex returns e.g. `ref int`.
If nothing else, the error message should be improved.
--
[Issue 14935] [Operator Overloading] Wrong description on overloading a[]
https://issues.dlang.org/show_bug.cgi?id=14935
--- Comment #7 from ag0ae...@gmail.com ---
(In reply to Ryuichi OHORI from comment #6)
I agree with you on closing this as invalid. The main problem was that I
missed opIndexOpAssign and tried to use opIndex/opSlice (of a struct S) +
opOpAssign (of the returning Voldemort type of S.opIndex).
While I went wrong, the error message cannot be sliced with [] is not so
helpful as to help me figuring out the problem.
If I understand correctly, you're describing something like this:
struct V
{
void opOpAssign(string op)(int x) {}
}
struct S
{
V opIndex() {return V();}
}
void main()
{
S s;
s[] += 2; /* Error: S cannot be sliced with [] */
}
That error message really doesn't help. And it actually works when you use a
temporary variable to hold the result of s[]:
S s;
auto v = s[];
v += 2; /* no error */
So I'd say that's a rejects-valid bug. I filed issue 14941 for that.
One of the reasons I missed opIndexOpAssign was that it is categorized under
Op Assignment Operator Overloading. I'd like to place it under Array
Indexing and Slicing Operators Overloading.
I don't know where it fits best. Maybe just make a pull request and see how it
goes.
--
[Issue 14383] [ddoc] documented unittests don't work for module declaration
https://issues.dlang.org/show_bug.cgi?id=14383 hst...@quickfur.ath.cx changed: What|Removed |Added Keywords||ddoc CC||hst...@quickfur.ath.cx Summary|documented unittests don't |[ddoc] documented unittests |work for module declaration |don't work for module ||declaration --
