The blacklisted functions are now down to only two.

Those are the bitswap function in druntime.
Because the interpreter does handle all values as 64bit internally it tends to miscompile code that uses xor on 32bit values.

And the second one is the "to" template from std.conv;
Because of the aforementioned UTF issues.

NOTE: that the blacklist is by nature transitive meaning a function that calls a blacklisted function will also not be interpreted by newCTFE

On Tuesday, 24 January 2017 at 06:35:56 UTC, Stefan Koch wrote:
> And the second one is the "to" template from std.conv;
> Because of the aforementioned UTF issues.
>
> NOTE: that the blacklist is by nature transitive meaning a function that calls a blacklisted function will also not be interpreted by newCTFE

`to` is so common that I suspect you'll see a wave of bugs when you fix the UTF issues, yes?

Either way, thanks for spending so much time on this, I'm excited about these improvements both from a professional and personal standpoint.

On Tuesday, 24 January 2017 at 09:27:52 UTC, John Colvin wrote:
> On Tuesday, 24 January 2017 at 06:35:56 UTC, Stefan Koch wrote:
>> And the second one is the "to" template from std.conv;
>> Because of the aforementioned UTF issues.
>>
>> NOTE: that the blacklist is by nature transitive meaning a function that calls a blacklisted function will also not be interpreted by newCTFE
>
> `to` is so common that I suspect you'll see a wave of bugs when you fix the UTF issues, yes?
>
> Either way, thanks for spending so much time on this, I'm excited about these improvements both from a professional and personal standpoint.

NEW CTFE IS GREEN ON 64 BIT!
GREEN!

On Tuesday, 24 January 2017 at 09:52:13 UTC, Stefan Koch wrote:
> NEW CTFE IS GREEN ON 64 BIT!
> GREEN!

I felt first a bit surprised about that "green" thing, but somehow if the new-ctfe engine consumes less CPU, it means it consumes less power, and therefore less carbone dioxyde is released into the atmosphere.
So indeed, we can assert that new-ctfe is eco-friendly!

Good job! :)

I really enjoy reading this thread everyday. It's kind of like a Dungeon & Dragon novel where the hero slashes its way through monsters, and bugs and features, up to the Holy Grail: the New-CTFE Engine implementation!

This is awesome work! Thanks.

On Tuesday, 24 January 2017 at 10:34:58 UTC, Claude wrote:
> On Tuesday, 24 January 2017 at 09:52:13 UTC, Stefan Koch wrote:
>> NEW CTFE IS GREEN ON 64 BIT!
>> GREEN!
>
> I felt first a bit surprised about that "green" thing, but somehow if the new-ctfe engine consumes less CPU, it means it consumes less power, and therefore less carbone dioxyde is released into the atmosphere.
> So indeed, we can assert that new-ctfe is eco-friendly!
>
Green means it passes all tests on auto-tester.

On Tuesday, 24 January 2017 at 11:01:46 UTC, Stefan Koch wrote:
> Green means it passes all tests on auto-tester.

Wonderful! Time to try out Pegged with newCTFE, then!

On Tuesday, 24 January 2017 at 11:01:46 UTC, Stefan Koch wrote:
> Green means it passes all tests on auto-tester.

Yes, I understood. I was playing with the idea of eco-friendliness as well... :)

On Tuesday, 24 January 2017 at 12:43:28 UTC, Nordlöw wrote:
> On Tuesday, 24 January 2017 at 11:01:46 UTC, Stefan Koch wrote:
>> Green means it passes all tests on auto-tester.
>
> Wonderful! Time to try out Pegged with newCTFE, then!

There will be NO permanence improvement for pegged.
For the 7th time.

It is bogged down by templates, ctfe is not the problem there.

On Tuesday, 24 January 2017 at 14:16:10 UTC, Stefan Koch wrote:
> There will be NO permanence improvement for pegged.
> For the 7th time.
>
> It is bogged down by templates, ctfe is not the problem there.

Sorry for that. Got it.

What's the essence of this suboptimal performance when using templates?

Non-O(1) lookup times?

Mangling?

On Tuesday, 24 January 2017 at 15:16:29 UTC, Nordlöw wrote:
> On Tuesday, 24 January 2017 at 14:16:10 UTC, Stefan Koch wrote:
>> There will be NO permanence improvement for pegged.
>> For the 7th time.
>>
>> It is bogged down by templates, ctfe is not the problem there.
>
> Sorry for that. Got it.
>
> What's the essence of this suboptimal performance when using templates?
>
> Non-O(1) lookup times?
>
> Mangling?

The lookup time is one issue but not the most important,
The instanciation of a template is a non-trivial operation within the compiler.
Type-deduction ast rewriting expression expansion
all of that takes time and a huge chunk at that.
Also binary code needs to be generated and that code is generated for every instance regardless of how similar they are.