Re: win32 from master: unicode functions by default?
On Thursday, 12 November 2015 at 15:58:53 UTC, Jonathan M Davis wrote: On Thursday, November 12, 2015 05:08:24 Mike Parker via version=Unicode on the compiler command line. It seems pretty wrong for the A versions to be the default though... Still, even in C++ code, I've generally taken the approach of using the W functions explicitly in order to avoid any potential problems with A functions being called accidentally. Regardless, the whole A vs W thing with Win32 is not exactly one of its nicer features. :| - Jonathan M Davis I've gotten into the same habit. But it appears the switch to dynamic loading has made it so that only the A versions or only the W versions are available. You no longer get both. https://github.com/D-Programming-Language/druntime/blob/master/src/core/sys/windows/w32api.d#L85
Re: What does the -betterC switch in dmd do?
On Thu, 12 Nov 2015 19:37:41 +, TheFlyingFiddle wrote: > The description in dmd help says: omit generating some runtime > information and helper functions. > > What runtime information are we talking about here? My > understanding is that it's basically an experimental feature but > when (if) completed what subset of the language would still be > usable? I believe the purpose of the switch is to help folks who are trying to write for bare or embedded systems by not emitting references to the D runtime library and runtime module information. Whether it actually does that in its current implementation is another question.
What does the -betterC switch in dmd do?
The description in dmd help says: omit generating some runtime information and helper functions. What runtime information are we talking about here? My understanding is that it's basically an experimental feature but when (if) completed what subset of the language would still be usable?
Re: my first D program (and benchmark against perl)
On Thursday, 12 November 2015 at 12:49:55 UTC, Daniel Kozak wrote: dmd -O -release -inline -boundscheck=off asciitable.d real0m1.463s user0m1.453s sys 0m0.003s ldc2 -singleobj -release -O3 -boundscheck=off asciitable.d real0m0.945s user0m0.940s sys 0m0.000s gdc -O3 -finline -frelease -fno-bounds-check -o asciitable asciitable.d real0m0.618s user0m0.613s sys 0m0.000s perl: real0m14.198s user0m14.170s sys 0m0.000s Nice! Seems like I can get a further 100% improvement in speed from the last version (so a total of ~8x speedup from my original D version). Now I wonder how C would fare...
Re: win32 from master: unicode functions by default?
On Thursday, November 12, 2015 05:08:24 Mike Parker via Digitalmars-d-learn wrote: > On Thursday, 12 November 2015 at 04:58:42 UTC, Andre wrote: > > Hi, > > > > by using the win32 library from master, the functions aliases > > to the ansi windows functions (...A) instead of the unicode > > functions (...W). > > Is there a way to control this behavior beside using the > > explicit function > > names (A/W)? > > > > Kind regards > > André > > version=Unicode on the compiler command line. It seems pretty wrong for the A versions to be the default though... Still, even in C++ code, I've generally taken the approach of using the W functions explicitly in order to avoid any potential problems with A functions being called accidentally. Regardless, the whole A vs W thing with Win32 is not exactly one of its nicer features. :| - Jonathan M Davis
Re: Compiler doesn't complain with multiple definitions
On Thursday, 12 November 2015 at 15:06:26 UTC, ric maicle wrote: On Thursday, 12 November, 2015 07:50 PM, anonymous wrote: __traits has special syntax. The first "argument" must be from a list of special keywords that only have special meaning in that place. You can't put the name of a struct there, and you can't put the special keyword anywhere else. So there's no ambiguity, and you're not redefining anything. Everything's fine. Thanks for clarifying __traits. On another thing. I'm wondering why the compiler didn't issue a warning on struct isPOD and byte isPOD? Isn't this called 'shadowing' or have I misunderstood the term? If I remember correctly: Shadowing globals is allowed, all other instances of shadowing are not.
Re: Compiler doesn't complain with multiple definitions
On Thursday, 12 November, 2015 07:50 PM, anonymous wrote: __traits has special syntax. The first "argument" must be from a list of special keywords that only have special meaning in that place. You can't put the name of a struct there, and you can't put the special keyword anywhere else. So there's no ambiguity, and you're not redefining anything. Everything's fine. Thanks for clarifying __traits. On another thing. I'm wondering why the compiler didn't issue a warning on struct isPOD and byte isPOD? Isn't this called 'shadowing' or have I misunderstood the term?
Re: my first D program (and benchmark against perl)
On Thursday, 12 November 2015 at 12:49:55 UTC, Daniel Kozak wrote: On Thursday, 12 November 2015 at 12:25:08 UTC, Daniel Kozak wrote: ... auto res = appender(uninitializedArray!(char[])(total)); res.clear(); ... this is faster for DMD and ldc: auto res = appender!(string)(); res.reserve(total); but for gdc(fronend version 2.066) it makes it two times slower (same for dmd, ldc 2.066 and older)
Re: my first D program (and benchmark against perl)
On Thursday, 12 November 2015 at 12:25:08 UTC, Daniel Kozak wrote: V Thu, 12 Nov 2015 12:13:10 + perlancar via Digitalmars-d-learn napsáno: On Wednesday, 11 November 2015 at 14:20:51 UTC, Rikki Cattermole wrote: > I turned it into mostly using large allocations, instead of > small ones. > Although I'd recommend using Appender instead of my custom > functions for this. > > Oh and for me, I got it at 2 secs, 513 ms, 397 μs, and 5 > hnsecs. Unoptimized, using dmd. > When release mode is enabled on dmd: 1 sec, 550 ms, 838 μs, > and > 9 hnsecs. So significant improvement even with dmds awful > optimizer. Hi Rikki, Thanks. With your version, I've managed to be ~4x faster: dmd : 0m1.588s dmd (release): 0m1.010s gdc : 0m2.093s ldc : 0m1.594s Perl version : 0m11.391s So, I'm satisfied enough with the speed for now. Turns out dmd is not always slower. It depends which flags do you use on ldc and gdc ldc (-singleobj -release -O3 -boundscheck=off) gdc (-O3 -finline -frelease -fno-bounds-check) import std.stdio; auto fmttable(string[][] table) { import std.array : appender, uninitializedArray; import std.range : take, repeat; import std.exception : assumeUnique; if (table.length == 0) return ""; // column widths auto widths = new int[](table[0].length); size_t total = (table[0].length + 1) * table.length + table.length; foreach (rownum, row; table) { foreach (colnum, cell; row) { if (cell.length > widths[colnum]) widths[colnum] = cast(int)cell.length; } } foreach (colWidth; widths) { total += colWidth * table.length; } auto res = appender(uninitializedArray!(char[])(total)); res.clear(); foreach (row; table) { res ~= "|"; foreach (colnum, cell; row) { int l = widths[colnum] - cast(int)cell.length; res ~= cell; if (l) res ~= ' '.repeat().take(l); res ~= "|"; } res.put("\n"); } return res.data.assumeUnique(); } void main() { auto table = [ ["row1.1", "row1.2 ", "row1.3"], ["row2.1", "row2.2", "row2.3"], ["row3.1", "row3.2", "row3.3 "], ["row4.1", "row4.2", "row4.3"], ["row5.1", "row5.2", "row5.3"], ]; writeln(fmttable(table)); for (int i=0; i < 100; ++i) { fmttable(table); } } dmd -O -release -inline -boundscheck=off asciitable.d real0m1.463s user0m1.453s sys 0m0.003s ldc2 -singleobj -release -O3 -boundscheck=off asciitable.d real0m0.945s user0m0.940s sys 0m0.000s gdc -O3 -finline -frelease -fno-bounds-check -o asciitable asciitable.d real0m0.618s user0m0.613s sys 0m0.000s perl: real0m14.198s user0m14.170s sys 0m0.000s
Re: How to fix "Error symbol '.....' is already defined"
On Thursday, 12 November 2015 at 08:45:57 UTC, Kagamin wrote: Looks like a bug in the compiler. In this case it means there is a bug inside dmd and gdc (didn't try ldc)...
Re: my first D program (and benchmark against perl)
V Thu, 12 Nov 2015 12:13:10 + perlancar via Digitalmars-d-learn napsáno: > On Wednesday, 11 November 2015 at 14:20:51 UTC, Rikki Cattermole > wrote: > > I turned it into mostly using large allocations, instead of > > small ones. > > Although I'd recommend using Appender instead of my custom > > functions for this. > > > > Oh and for me, I got it at 2 secs, 513 ms, 397 μs, and 5 > > hnsecs. Unoptimized, using dmd. > > When release mode is enabled on dmd: 1 sec, 550 ms, 838 μs, and > > 9 hnsecs. So significant improvement even with dmds awful > > optimizer. > > Hi Rikki, > > Thanks. With your version, I've managed to be ~4x faster: > > dmd : 0m1.588s > dmd (release): 0m1.010s > gdc : 0m2.093s > ldc : 0m1.594s > > Perl version : 0m11.391s > > So, I'm satisfied enough with the speed for now. Turns out dmd is > not always slower. It depends which flags do you use on ldc and gdc ldc (-singleobj -release -O3 -boundscheck=off) gdc (-O3 -finline -frelease -fno-bounds-check)
Re: OSX Foundation framework D binding
On 2015-11-12 09:34, ponce wrote: Opinion. I only ever got problems with bindings that aren't dynamic. For example that problem would not happen with dynamic loading. https://github.com/nomad-software/x11/issues/11 I've never encountered that problem. -- /Jacob Carlborg
Re: my first D program (and benchmark against perl)
On Wednesday, 11 November 2015 at 14:20:51 UTC, Rikki Cattermole wrote: I turned it into mostly using large allocations, instead of small ones. Although I'd recommend using Appender instead of my custom functions for this. Oh and for me, I got it at 2 secs, 513 ms, 397 μs, and 5 hnsecs. Unoptimized, using dmd. When release mode is enabled on dmd: 1 sec, 550 ms, 838 μs, and 9 hnsecs. So significant improvement even with dmds awful optimizer. Hi Rikki, Thanks. With your version, I've managed to be ~4x faster: dmd : 0m1.588s dmd (release): 0m1.010s gdc : 0m2.093s ldc : 0m1.594s Perl version : 0m11.391s So, I'm satisfied enough with the speed for now. Turns out dmd is not always slower.
Re: my first D program (and benchmark against perl)
On Wednesday, 11 November 2015 at 14:26:32 UTC, Andrea Fontana wrote: Did you try rdmd -O -noboundscheck -release yourscript.d ? I just did. It improves speed from 17.127s to 14.831s. Nice, but nowhere near gdc/ldc level. You should try using appender!string rather than concatenate (http://dlang.org/phobos/std_array.html#.Appender) using capacity (http://dlang.org/phobos/std_array.html#.Appender.capacity) to improve performace. You should also switch from for to foreach. Thanks for the above 2 tips.
Re: Compiler doesn't complain with multiple definitions
On 12.11.2015 06:27, ric maicle wrote: I was playing with __traits and tried the code below. Shouldn't the compiler emit a warning that I'm defining isPOD multiple times and/or I'm defining something that is built-in like isPOD? // DMD64 D Compiler v2.069 import std.stdio; struct isPOD { bool status = false; } int main() { byte isPOD = 0; writeln(isPOD); writeln(__traits(isPOD, typeof(isPOD))); return 0; } __traits has special syntax. The first "argument" must be from a list of special keywords that only have special meaning in that place. You can't put the name of a struct there, and you can't put the special keyword anywhere else. So there's no ambiguity, and you're not redefining anything. Everything's fine.
Re: my first D program (and benchmark against perl)
V Thu, 12 Nov 2015 11:03:38 + Tobias Pankrath via Digitalmars-d-learn napsáno: > > or with ~ operator: > > > > import std.stdio; > > > > [...] > > Did anyone check that the last loop isn't optimized out? Yes, it is not optimized out > Could also be improved further if you make the function take an > output range and reuse one appender for every call, but that might be > to far off the original perl solution. I agree, that would be to far off the original solution.
Re: my first D program (and benchmark against perl)
or with ~ operator: import std.stdio; [...] Did anyone check that the last loop isn't optimized out? Could also be improved further if you make the function take an output range and reuse one appender for every call, but that might be to far off the original perl solution.
Re: my first D program (and benchmark against perl)
V Thu, 12 Nov 2015 09:12:32 + Daniel Kozak via Digitalmars-d-learn napsáno: > On Wednesday, 11 November 2015 at 13:32:00 UTC, perlancar wrote: > > Here's my first non-hello-world D program, which is a direct > > translation from the Perl version. I was trying to get a feel > > about D's performance: > > > > ... > > > > While I am quite impressed with how easy I was able to write D, > > I am not so impressed with the performance. Using rdmd (build > > 20151103), the D program runs in 17.127s while the Perl version > > runs in 11.391s (so the D version is quite a bit *slower* than > > Perl's). While using gdc (Debian 4.9.2-10), I am able to run it > > in 3.988s (only about 3x faster than Perl's version). > > > > I understand that string processing (concatenation, allocation) > > is quite optimized in Perl, I was wondering if the D version > > could still be sped up significantly? > > Main problem is with allocations and with stripLeft, here is my > version which is 10x faster than perls even with DMD. With LDC is > 12x faster > > import std.stdio; > import std.array : appender; > import std.range; > > > auto fmttable(T)(T table) { > auto res = appender!(string)(); > res.reserve(64); > > if (table.length == 0) return ""; > > // column widths > auto widths = new int[](table[0].length); > > foreach (rownum, row; table) { > foreach (colnum, cell; row) { > if (cell.length > widths[colnum]) > widths[colnum] = cast(int)cell.length; > } > } > > foreach (row; table) { > res.put("|"); > foreach (colnum, cell; row) { > int l = widths[colnum] - cast(int)cell.length; > res.put(cell); > if (l) >res.put(' > '.repeat().take(l)); res.put("|"); > } > res.put("\n"); > } > > return res.data; > } > > void main() { > > auto table = [ > ["row1.1", "row1.2 ", "row1.3"], > ["row2.1", "row2.2", "row2.3"], > ["row3.1", "row3.2", "row3.3 "], > ["row4.1", "row4.2", "row4.3"], > ["row5.1", "row5.2", "row5.3"], > ]; > > write(fmttable(table)); > for (int i=0; i < 100; ++i) { > fmttable(table); > } > } > > or with ~ operator: import std.stdio; auto fmttable(string[][] table) { import std.array : appender, uninitializedArray; import std.range : take, repeat; import std.exception : assumeUnique; auto res = appender(uninitializedArray!(char[])(128)); res.clear(); if (table.length == 0) return ""; // column widths auto widths = new int[](table[0].length); foreach (rownum, row; table) { foreach (colnum, cell; row) { if (cell.length > widths[colnum]) widths[colnum] = cast(int)cell.length; } } foreach (row; table) { res ~= "|"; foreach (colnum, cell; row) { int l = widths[colnum] - cast(int)cell.length; res ~= cell; if (l) res ~= ' '.repeat().take(l); res ~= "|"; } res.put("\n"); } return res.data.assumeUnique(); } void main() { auto table = [ ["row1.1", "row1.2 ", "row1.3"], ["row2.1", "row2.2", "row2.3"], ["row3.1", "row3.2", "row3.3 "], ["row4.1", "row4.2", "row4.3"], ["row5.1", "row5.2", "row5.3"], ]; write(fmttable(table)); for (int i=0; i < 100; ++i) { fmttable(table); } }
Re: my first D program (and benchmark against perl)
On Wednesday, 11 November 2015 at 13:32:00 UTC, perlancar wrote: Here's my first non-hello-world D program, which is a direct translation from the Perl version. I was trying to get a feel about D's performance: ... While I am quite impressed with how easy I was able to write D, I am not so impressed with the performance. Using rdmd (build 20151103), the D program runs in 17.127s while the Perl version runs in 11.391s (so the D version is quite a bit *slower* than Perl's). While using gdc (Debian 4.9.2-10), I am able to run it in 3.988s (only about 3x faster than Perl's version). I understand that string processing (concatenation, allocation) is quite optimized in Perl, I was wondering if the D version could still be sped up significantly? Main problem is with allocations and with stripLeft, here is my version which is 10x faster than perls even with DMD. With LDC is 12x faster import std.stdio; import std.array : appender; import std.range; auto fmttable(T)(T table) { auto res = appender!(string)(); res.reserve(64); if (table.length == 0) return ""; // column widths auto widths = new int[](table[0].length); foreach (rownum, row; table) { foreach (colnum, cell; row) { if (cell.length > widths[colnum]) widths[colnum] = cast(int)cell.length; } } foreach (row; table) { res.put("|"); foreach (colnum, cell; row) { int l = widths[colnum] - cast(int)cell.length; res.put(cell); if (l) res.put(' '.repeat().take(l)); res.put("|"); } res.put("\n"); } return res.data; } void main() { auto table = [ ["row1.1", "row1.2 ", "row1.3"], ["row2.1", "row2.2", "row2.3"], ["row3.1", "row3.2", "row3.3 "], ["row4.1", "row4.2", "row4.3"], ["row5.1", "row5.2", "row5.3"], ]; write(fmttable(table)); for (int i=0; i < 100; ++i) { fmttable(table); } }
Re: How to fix "Error symbol '.....' is already defined"
Looks like a bug in the compiler.
Re: OSX Foundation framework D binding
On Wednesday, 11 November 2015 at 16:06:57 UTC, Jacob Carlborg wrote: On 2015-11-11 10:29, Daniel Kozak via Digitalmars-d-learn wrote: I find only this one: http://code.dlang.org/packages/derelict-cocoa Also, there's no point in complicate the bindings by using function pointers like this. Opinion. I only ever got problems with bindings that aren't dynamic. For example that problem would not happen with dynamic loading. https://github.com/nomad-software/x11/issues/11
Re: OSX Foundation framework D binding
On 2015-11-12 06:50, Vadim Lopatin wrote: Aren't there any ready set of translated and post-processed files for main OSX foundations in some repository? Could you point at it? I have these 6 years old bindings [1] which uses an old Objective-C bridge. Perhaps it's possible to do some search-and-replace to convert the bindings to use the new Objective-C support. There's the Dive Framework [2] as well. It uses a fork of the compiler which has all the Objective-C interoperability features that the upstream compiler will eventually have. [1] http://dsource.org/projects/dstep/browser/dstep [2] https://github.com/DiveFramework/DiveFramework -- /Jacob Carlborg