On 02/23/2016 12:12 PM, dextorious wrote:
> Some languages
> feature more accurate options separately, but never as the default, so
> it did not occur to me to specifically check the documentation for
> something like sum() (which is my fault, of course, no issues there).
> Having the more accura
On Wednesday, 24 February 2016 at 19:15:23 UTC, dextorious wrote:
However, there doesn't seem to be any way to specify different
dflags for different compilers
There are examples like in the package format page
"dflags-dmd": ["-vtls"],
"sourceFiles-windows-x86_64-dmd": ["lib/win32/mylib.lib"]
On Wednesday, 24 February 2016 at 03:33:14 UTC, Mike Parker wrote:
On Tuesday, 23 February 2016 at 20:03:30 UTC, dextorious wrote:
For instance, I am still not sure how to make it pass the -O5
switch to the LDC2 compiler and the impression I got from the
documentation is that explicit manual sw
On Tuesday, 23 February 2016 at 20:03:30 UTC, dextorious wrote:
For instance, I am still not sure how to make it pass the -O5
switch to the LDC2 compiler and the impression I got from the
documentation is that explicit manual switches can only be
supplied for the DMD compiler.
If you're refer
On Tuesday, 23 February 2016 at 20:03:30 UTC, dextorious wrote:
Personally, I think a few aspects of documentation for the
various compilers, dub and possibly the dlang.org website
itself could be improved, if accessibility is considered
important.
Couldn't agree more.
Being new to the l
On Tuesday, 23 February 2016 at 14:07:22 UTC, Marc Schütz wrote:
On Tuesday, 23 February 2016 at 11:10:40 UTC, ixid wrote:
We really need to standard algorithms to be fast and perhaps
have separate ones for perfect technical accuracy.
While I agree with most of what you're saying, I don't th
On Tuesday, 23 February 2016 at 11:10:40 UTC, ixid wrote:
On Monday, 22 February 2016 at 15:43:23 UTC, dextorious wrote:
I do have to wonder, however, about the default settings of
dub in this case. Having gone through its documentation, I
might still not have guessed to try the compiler option
On Tuesday, 23 February 2016 at 14:07:22 UTC, Marc Schütz wrote:
On Tuesday, 23 February 2016 at 11:10:40 UTC, ixid wrote:
We really need to standard algorithms to be fast and perhaps
have separate ones for perfect technical accuracy.
While I agree with most of what you're saying, I don't th
On Tuesday, 23 February 2016 at 11:10:40 UTC, ixid wrote:
On Monday, 22 February 2016 at 15:43:23 UTC, dextorious wrote:
I do have to wonder, however, about the default settings of
dub in this case. Having gone through its documentation, I
might still not have guessed to try the compiler option
On Tuesday, 23 February 2016 at 11:10:40 UTC, ixid wrote:
We really need to standard algorithms to be fast and perhaps
have separate ones for perfect technical accuracy.
While I agree with most of what you're saying, I don't think we
should prioritize performance over accuracy or correctness
On Monday, 22 February 2016 at 15:43:23 UTC, dextorious wrote:
I do have to wonder, however, about the default settings of dub
in this case. Having gone through its documentation, I might
still not have guessed to try the compiler options you
provided, thereby losing out on a 2-3x performance i
On Sunday, 21 February 2016 at 16:20:30 UTC, bachmeier wrote:
On Sunday, 21 February 2016 at 14:32:15 UTC, dextorious wrote:
I had heard while reading up on the language that in D
explicit loops are generally frowned upon and not necessary
for the usual performance reasons.
First, a minor poi
On Sunday, 21 February 2016 at 16:20:30 UTC, bachmeier wrote:
First, a minor point, the D community is usually pretty careful
not to frown on a particular coding style (unlike some
communities) so if you are comfortable writing loops and it
gives you the fastest code, you should do so.
On the
First of all, I am pleasantly surprised by the rapid influx of
helpful responses. The community here seems quite wonderful. In
the interests of not cluttering the thread too much, since the
advice given here has many commonalities, I will only try to
respond once to each type of suggestion.
O
On Monday, 22 February 2016 at 07:10:23 UTC, Kapps wrote:
If you do want to test the differences between the range
approach and the loop approach, something like:
auto sumtest4(Range)(Range range) @safe pure {
return range.reduce!((a, b) => a + b);
}
is a more fair comparison. I get resu
If you do want to test the differences between the range approach
and the loop approach, something like:
auto sumtest4(Range)(Range range) @safe pure {
return range.reduce!((a, b) => a + b);
}
is a more fair comparison. I get results within 15% of sumtest2
with this using dmd. I think wi
On Sunday, 21 February 2016 at 16:36:22 UTC, ZombineDev wrote:
On Sunday, 21 February 2016 at 16:29:26 UTC, ZombineDev wrote:
...
And if I use the Kahan algorithm:
106 ms
36 ms
31 ms
The second two results are probably larger due to noise.
I did some more testing and clearly the larger times f
On Sunday, 21 February 2016 at 16:29:26 UTC, ZombineDev wrote:
...
And if I use the Kahan algorithm:
106 ms
36 ms
31 ms
The second two results are probably larger due to noise.
I did some more testing and clearly the larger times for N=1000
were just noise:
[LDC Kahan N=1000]
106 ms
36 ms
31
On Sunday, 21 February 2016 at 14:32:15 UTC, dextorious wrote:
I've been vaguely aware of D for many years, but the recent
addition of std.experimental.ndslice finally inspired me to
give it a try, since my main expertise lies in the domain of
scientific computing and I primarily use Python/Jul
On Sunday, 21 February 2016 at 14:32:15 UTC, dextorious wrote:
I had heard while reading up on the language that in D explicit
loops are generally frowned upon and not necessary for the
usual performance reasons.
First, a minor point, the D community is usually pretty careful
not to frown on
On Sunday, 21 February 2016 at 14:32:15 UTC, dextorious wrote:
Now, seeing as how my experience writing D is literally a few
hours, is there anything I did blatantly wrong? Did I miss any
optimizations? Most importantly, can the elegant operator
chaining style be generally made as fast as the e
So I guess pairwise summation is one to blame here.
Dne 21.2.2016 v 16:56 Daniel Kozak napsal(a):
You can use -profile to see what is causing it.
Num TreeFuncPer
CallsTimeTimeCall
2300 550799875 550243765 23 pure nothrow
You can use -profile to see what is causing it.
Num TreeFuncPer
CallsTimeTimeCall
2300 550799875 550243765 23 pure nothrow @nogc
@safe double std.algorithm.iteration.sumPairwise!(double,
std.experimental.ndslice.slice.Sl
On Sunday, 21 February 2016 at 14:32:15 UTC, dextorious wrote:
Now, seeing as how my experience writing D is literally a few
hours, is there anything I did blatantly wrong? Did I miss any
optimizations? Most importantly, can the elegant operator
chaining style be generally made as fast as the
I've been vaguely aware of D for many years, but the recent
addition of std.experimental.ndslice finally inspired me to give
it a try, since my main expertise lies in the domain of
scientific computing and I primarily use Python/Julia/C++, where
multidimensional arrays can be handled with a gre
25 matches
Mail list logo
