On Tuesday, 22 July 2014 at 21:23:33 UTC, Timon Gehr wrote:
> On 07/22/2014 09:42 PM, Walter Bright wrote:
>> The point was not at all to criticize Haskell. The point was that D does
>> not need tail recursion because D supports writing loop constructs.
>
> Tail call support is still useful. Looping is not the main reason for supporting tail calls. Eg. a tail call might be indirect and only sometimes recurse on the same function and sometimes call another function.

Indeed, I recall Matthias Felleisen wrote that OOP makes no sense without TCO because methods will indirectly call each other. See

https://blogs.oracle.com/jrose/entry/tail_calls_in_the_vm#comment-1259314984000
http://www.eighty-twenty.org/index.cgi/tech/oo-tail-calls-20111001.html

While I don't care much for OOP, D is supposed to support that style.

21-Jul-2014 02:29, Walter Bright пишет:
> On 7/20/2014 3:10 PM, Dmitry Olshansky wrote:
>>> The computed goto is faster for two reasons, according to the article:
>>>
>>> 1.The switch does a bit more per iteration because of bounds checking.
>>
>> Now let's consider proper implementation of thread-code interpreter.
>> where *code pointer points to an array of addresses. We've been
>> through this
>> before and it turns out switch is slower because of an extra load.
>>
>> a) Switch does 1 load for opcode, 1 load for the jump table, 1
>> indirect jump to
>> advance
>> (not even counting bounds checking of the switch)
>>
>> b) Threaded-code via (say) computed goto does 1 load of opcode and 1
>> indirect
>> jump, because opcode is an address already (so there is no separate
>> jump table).
>
> True, but I'd like to find a way that this can be done as an optimization.
>
I found a way but that relies on tail-call optimization, otherwise it would overflow stack. I would rather find some way that works without -O flag.

In fact it brings another unrelated problem with Phobos: any template-heavy libraries have amazingly awful speeds w/o inlining & optimization enabled _by the client_. It should be the same with C++ though.

>> I'm certain that forced tail call would work just fine instead of
>> computed goto
>> for this scenario. In fact I've measured this with LDC and the results
>> are
>> promising but only work with -O2/-O3 (where tail call is optimized).
>> I'd gladly
>> dig them up if you are interested.
>
> I'm pretty reluctant to add language features that can be done as
> optimizations.

The point is - software that only works in release build is kind of hard to develop, even more so with libraries. Thus I'm in opposition to labeling such things as optimization when they, in fact, change semantics.

-- 
Dmitry Olshansky

On 7/23/2014 1:06 PM, Dmitry Olshansky wrote:
> The point is - software that only works in release build is kind of hard to
> develop, even more so with libraries. Thus I'm in opposition to labeling such
> things as optimization when they, in fact, change semantics.

-release, -inline, -O and -g are all separate flags for good reasons. You can mix and match as convenient for what you're trying to accomplish.

24-Jul-2014 00:14, Walter Bright пишет:
> On 7/23/2014 1:06 PM, Dmitry Olshansky wrote:
>> The point is - software that only works in release build is kind of
>> hard to
>> develop, even more so with libraries. Thus I'm in opposition to
>> labeling such
>> things as optimization when they, in fact, change semantics.
>
> -release, -inline, -O and -g are all separate flags for good reasons.
> You can mix and match as convenient for what you're trying to accomplish.
>

Unless you are library writer, and then it's user who mixes and matches flags and you are foobared unless it works with them all :)

-- 
Dmitry Olshansky

On 7/23/2014 1:20 PM, Dmitry Olshansky wrote:
> Unless you are library writer, and then it's user who mixes and matches flags
> and you are foobared unless it works with them all :)

I think it's a generally unworkable rabbit hole if we add language features to turn on/off various optimizations.

24-Jul-2014 00:43, Walter Bright пишет:
> On 7/23/2014 1:20 PM, Dmitry Olshansky wrote:
>> Unless you are library writer, and then it's user who mixes and
>> matches flags
>> and you are foobared unless it works with them all :)
>
> I think it's a generally unworkable rabbit hole if we add language
> features to turn on/off various optimizations.
>
That's true. I'm thinking of how to solve things with minimal extension to the language that is generally useful (unlike compute-goto which is very niche and dangerous).

Obviously optimizations won't solve this problem, with that said it would be awesome to have your 2 final switch enhancements.

-- 
Dmitry Olshansky

Dmitry Olshansky:

>(unlike compute-goto which is very niche and dangerous).

It's a niche that system languages are the few fit for. Even CPython (and other interpreters) are using that feature.

Bye,
bearophile

24-Jul-2014 01:05, bearophile пишет:
> Dmitry Olshansky:
>
>> (unlike compute-goto which is very niche and dangerous).
>
> It's a niche that system languages are the few fit for. Even CPython
> (and other interpreters) are using that feature.
>

All of fast portable interpreters i.e. not JITs.
It's still a niche, and a feature should have uses beyond that or be better tailored for this use case.

Forced tail call was my best shot - it's useful for functional programming and it works for fast interpreters.

-- 
Dmitry Olshansky

On 7/23/14, 1:14 PM, Walter Bright wrote:
> On 7/23/2014 1:06 PM, Dmitry Olshansky wrote:
>> The point is - software that only works in release build is kind of
>> hard to
>> develop, even more so with libraries. Thus I'm in opposition to
>> labeling such
>> things as optimization when they, in fact, change semantics.
>
> -release, -inline, -O and -g are all separate flags for good reasons.
> You can mix and match as convenient for what you're trying to accomplish.

... and -noboundscheck. -- Andrei

On 7/23/2014 1:53 PM, Dmitry Olshansky wrote:
> Obviously optimizations won't solve this problem, with that said it would be
> awesome to have your 2 final switch enhancements.

Yes. Feel free to ping me if I forget about them.

Also, I particularly like the first of them because it's not available to C/C++.