On Tuesday, 15 July 2014 at 16:20:34 UTC, Andrei Alexandrescu wrote:
> http://www.reddit.com/r/programming/comments/2aruaf/dconf_2014_keynote_high_performance_code_using_d/
>
> https://www.facebook.com/dlang.org/posts/885322668148082
>
> https://twitter.com/D_Programming/status/489081312297635840
>
>
> Andrei

http://youtu.be/eh8WETRT7q4

On Tuesday, 15 July 2014 at 19:00:35 UTC, Walter Bright wrote:
> On 7/15/2014 11:28 AM, John wrote:
>> At the end of this video, it sounds like it ends abruptly..
>> While answering a question, Walter says.. 'it turns out..' and the video ends
>> there.
>
> That's when my time ran out and I vanished in a puff of greasy black smoke.

:D

On 7/16/2014 5:15 AM, Jaroslav Hron wrote:
> On Tuesday, 15 July 2014 at 16:20:34 UTC, Andrei Alexandrescu wrote:
>> http://www.reddit.com/r/programming/comments/2aruaf/dconf_2014_keynote_high_performance_code_using_d/
>>
>>
>> https://www.facebook.com/dlang.org/posts/885322668148082
>>
>> https://twitter.com/D_Programming/status/489081312297635840
>>
>>
>> Andrei
>
> Is the presentation itself available somewhere?

https://archive.org/details/dconf2014-day03-talk01

On 7/16/2014 7:21 AM, dennis luehring wrote:
> can you give an short (working) example code to show the different resulting
> assembler for your for-rewrite example - and what compilers your using for
> testing - only dmd or gdc?

I used dmd.

Am 18.07.2014 04:52, schrieb Walter Bright:
> On 7/16/2014 7:21 AM, dennis luehring wrote:
>> can you give an short (working) example code to show the different resulting
>> assembler for your for-rewrite example - and what compilers your using for
>> testing - only dmd or gdc?
>
> I used dmd.
>

i sometimes got the feeling that you underestimate the sheer power of todays clang or gcc optimizers - so partly what gdc/ldc can do with your code

reminds me of brian schotts exmaple of his sse2 optimized version of his lexer - the dmd generated was much faster then the normal version, but gdc/ldc results of the unoptimized versions are still 50% faster

i understand your focus on dmd - but talking about fast code and optimizing WITHOUT even trying to compare with other compiler results is just a little bit strange for someone who stated speed = money

On 7/17/2014 9:40 PM, dennis luehring wrote:
> i understand your focus on dmd - but talking about fast code and optimizing
> WITHOUT even trying to compare with other compiler results is just a little bit
> strange for someone who stated speed = money

The point was to get people to look at the asm output of the compiler, as results can be surprising (as you've also discovered).

Am 18.07.2014 07:54, schrieb Walter Bright:
> On 7/17/2014 9:40 PM, dennis luehring wrote:
>> i understand your focus on dmd - but talking about fast code and optimizing
>> WITHOUT even trying to compare with other compiler results is just a little bit
>> strange for someone who stated speed = money
>
> The point was to get people to look at the asm output of the compiler, as
> results can be surprising (as you've also discovered).

...of the compilerS - please :)

can you post your (full, closed) D array access example from the talk
so i don't need to play around with the optimizer to get your asm results

On 7/17/2014 11:42 PM, dennis luehring wrote:
> Am 18.07.2014 07:54, schrieb Walter Bright:
>> On 7/17/2014 9:40 PM, dennis luehring wrote:
>>> i understand your focus on dmd - but talking about fast code and optimizing
>>> WITHOUT even trying to compare with other compiler results is just a little bit
>>> strange for someone who stated speed = money
>>
>> The point was to get people to look at the asm output of the compiler, as
>> results can be surprising (as you've also discovered).
>
> ...of the compilerS - please :)
>
> can you post your (full, closed) D array access example from the talk
> so i don't need to play around with the optimizer to get your asm results
>

It's the Warp source code. I don't have a reduced test case.

On Friday, 18 July 2014 at 04:40:52 UTC, dennis luehring wrote:
> Am 18.07.2014 04:52, schrieb Walter Bright:
>> On 7/16/2014 7:21 AM, dennis luehring wrote:
>>> can you give an short (working) example code to show the different resulting
>>> assembler for your for-rewrite example - and what compilers your using for
>>> testing - only dmd or gdc?
>>
>> I used dmd.
>>
>
> i sometimes got the feeling that you underestimate the sheer power of todays clang or gcc optimizers - so partly what gdc/ldc can do with your code
>
> reminds me of brian schotts exmaple of his sse2 optimized version of his lexer - the dmd generated was much faster then the normal version, but gdc/ldc results of the unoptimized versions are still 50% faster
>
> i understand your focus on dmd - but talking about fast code and optimizing WITHOUT even trying to compare with other compiler results is just a little bit strange for someone who stated speed = money

I think this somewhat misses the point of the example, which I would say was - in academia-speak - purely illustrative.

The point still stands, which is "unless you understand the compiler and the architecture, stop trying to second guess performance on the micro-level"

On 7/16/14, 3:22 AM, bearophile wrote:
> Andrei Alexandrescu:
>> http://www.reddit.com/r/programming/comments/2aruaf/dconf_2014_keynote_high_performance_code_using_d/
>>
>
> Despite Walter is used to "pipeline programming", so the next step is to
> also handle failures and off-band messages in a functional way (without
> exceptions and global error values) with two "parallel pipelines", here
> named "Railway-Oriented Programming". This is one of the simplest
> introductions (and he can skip the slides 19-53) that I have found of
> this topic (that in the Haskell community is explained on the base of
> monads):
>
> http://www.slideshare.net/ScottWlaschin/railway-oriented-programming

Just read the slides, very interesting. I think it would be interesting to experiment with an Expected!T that holds an Algebraic!(T, Exception) as state, and a template like this (warning no slides no understanding, this is very sketchy):

template bind(alias fun) { ... }

such that given a function e.g.

int fun(string a, double b);

bind!fun is this function:

Expected!int bind!fun(Expected!string a, Expected!double b) {
  if (a.sux || b.sux) return composeExceptions(a, b);
  return fun(a.rox, b.rox);
}

There would also be bindNothrow:

Expected!int bindNothrow!fun(Expected!string a, Expected!double b) {
  if (a.sux || b.sux) return composeExceptions(a, b);
  try return fun(a.rox, b.rox);
  catch (Exception e) return e;
}

> In Bugzilla there are already requests for some Railway-Oriented
> Programming:
>
> https://issues.dlang.org/show_bug.cgi?id=6840

Nice, but I think we need Expected!T in addition to Nullable!T.

> https://issues.dlang.org/show_bug.cgi?id=6843

This is not good; trying to see if conversion would succeed is almost as much work as doing it. We need a

Expected!To tryTo(From, To)(From source);

which produces the error but doesn't throw it.

> I think no language extensions are needed for such kind of programming,

Agreed.

> but of course built-in tuple syntax and basic forms of pattern matching
> in switch (https://d.puremagic.com/issues/show_bug.cgi?id=596 ) improve
> the syntax and make the code more handy, handy enough to push more D
> programmers in using it.

No :o).

> For some examples of those things in a system language, this page shows
> some little examples of functional syntax for Rust:
> http://science.raphael.poss.name/rust-for-functional-programmers.html

We, too, could use a couple of full-time library designers on the roster...


Andrei