On 4/1/15 3:49 PM, Martin Nowak wrote:
> On 03/31/2015 08:20 PM, cym13 wrote:
>> https://github.com/kostya/benchmarks
>
> We made a massive jump towards the upper ranks.
[snip]

This is amazing work. Thanks! -- Andrei

On 04/02/2015 01:39 AM, bearophile wrote:
> built-in functions for arithmetics with overflow checking

Your persistent interest in integer overflow checks make we wonder if
you were responsible for this?
http://www.around.com/ariane.html

On Wednesday, 1 April 2015 at 22:49:55 UTC, Martin Nowak wrote:
> On 03/31/2015 08:20 PM, cym13 wrote:
>> https://github.com/kostya/benchmarks
>
> We made a massive jump towards the upper ranks.
>
> #4  ¹
> https://github.com/kostya/benchmarks/tree/master/brainfuck#user-content-benchmark-benchb
> #2
> https://github.com/kostya/benchmarks/tree/master/brainfuck#user-content-benchmark-mandelb
> #1
> https://github.com/kostya/benchmarks/tree/master/base64#user-content-benchmark
> #13 ²
> https://github.com/kostya/benchmarks/tree/master/json#user-content-benchmark
> #2  ³
> https://github.com/kostya/benchmarks/tree/master/matmul#user-content-benchmark
> #4
> https://github.com/kostya/benchmarks/tree/master/havlak#user-content-benchmark
>
> https://github.com/kostya/benchmarks
>
> ¹: Nim outperforms anything else on brainfuck by a large margin because
> it has the fastest hash table (open addressing, storing values in head).
> https://github.com/Araq/Nim/blob/57fa8c6d3f535acc79ef8a67a6ef7aef0c7519da/lib/pure/collections/tables.nim#L73
>
> ²: D would probably be #1 with the json pull parser from
> http://code.dlang.org/packages/std_data_json.
>
> ³: Places 2, 3, and 4 thanks to std.numeric.dotProduct. An optimized
> dense matrix multiplication would get us #1.

the benchmark pointed out two sore areas in D(AA and std.json,) would be nice to see AA get updated as I often completely avoid using the built-in AA.

On 04/02/2015 03:35 AM, weaselcat wrote:
> 
> the benchmark pointed out two sore areas in D(AA and std.json,) would be nice to see AA get updated as I often completely avoid using the built-in AA.

I filed two ERs already, both are pretty isolated and not too hard to implement. I hope I don't have to do that myself.

https://issues.dlang.org/show_bug.cgi?id=14385 https://issues.dlang.org/show_bug.cgi?id=14386

The real fix a.k.a. library AA is a much harder problem.

On Thursday, 2 April 2015 at 03:55:53 UTC, Martin Nowak wrote:
> On 04/02/2015 03:35 AM, weaselcat wrote:
>> 
>> the benchmark pointed out two sore areas in D(AA and std.json,) would be
>> nice to see AA get updated as I often completely avoid using the
>> built-in AA.
>
> I filed two ERs already, both are pretty isolated and not too hard to
> implement. I hope I don't have to do that myself.
>
> https://issues.dlang.org/show_bug.cgi?id=14385
> https://issues.dlang.org/show_bug.cgi?id=14386
>
> The real fix a.k.a. library AA is a much harder problem.

was it a conscious decision to make the AA [] operator not work like map/etc in C++?

On Thursday, 2 April 2015 at 04:11:02 UTC, weaselcat wrote:
> was it a conscious decision to make the AA [] operator not work like map/etc in C++?

What do you mean?

On Thursday, 2 April 2015 at 04:32:26 UTC, Martin Nowak wrote:
> On Thursday, 2 April 2015 at 04:11:02 UTC, weaselcat wrote:
>> was it a conscious decision to make the AA [] operator not work like map/etc in C++?
>
> What do you mean?

accessing a non-existing element in C++'s map/unordered_map inserts the default instead of raising an exception

int main(int argc, char *argv[])
{
    std::unordered_map<std::string, int> test;
    std::cout << test["hello"] << std::endl;
    return 0;
}

prints 0

void main()
{
    int[string] test;
    writeln(test["hello"]);
}

core.exception.RangeError@source/main.d(9): Range violation

On Wednesday, 1 April 2015 at 22:49:55 UTC, Martin Nowak wrote:
> ³: Places 2, 3, and 4 thanks to std.numeric.dotProduct. An optimized
> dense matrix multiplication would get us #1.

According to
https://github.com/JuliaLang/julia#Required-Build-Tools-External-Libraries
building Julia requires OpenBlas or Intel MKL. So the native
julia matrix-matrix-multiplication is most probably just a call
to a highly optimized BLAS gemm + some overhead.
  => beeing faster than Julia native would require to be as least
fast as openBLAS/Intel MKL gemm.

It would be nice to have such a good matrix multiplication in
Phobos but I think there are more important things to work on
(GC, AA, ...),

Dstep + cblas.h works quite well although code calling it
involves pointers :)

weaselcat:

>>> was it a conscious decision to make the AA [] operator not work like map/etc in C++?
>>
>> What do you mean?
>
> accessing a non-existing element in C++'s map/unordered_map inserts the default instead of raising an exception
>
> int main(int argc, char *argv[])
> {
>     std::unordered_map<std::string, int> test;
>     std::cout << test["hello"] << std::endl;
>     return 0;
> }
>
> prints 0
>
> void main()
> {
>     int[string] test;
>     writeln(test["hello"]);
> }
>
> core.exception.RangeError@source/main.d(9): Range violation

Yes, it was a conscious decision, because here C++ behaves in a very bug-prone way. Sometimes C++ is a bad example to follow (like with permutations generations, that currently is not a Range in Phobos for the wrong reasons).

Bye,
bearophile

Martin Nowak:

> Your persistent interest in integer overflow checks make we wonder if you were responsible for this?
> http://www.around.com/ariane.html

I am not responsible for that, but I try to not be responsible for future molecular biology mistakes equivalent to that Ariane fiasco.

Bye,
bearophile