On Sun, Jul 17, 2016 at 6:08 PM, Stefan Koch via Digitalmars-d-announce < digitalmars-d-announce@puremagic.com> wrote:

> On Sunday, 17 July 2016 at 15:57:28 UTC, Rory McGuire wrote:
>
>>
>> Thanks that would be great, however I think its a while off before it can work on your ctfe implementation. It uses Pegged, so getting the Pegged JSON parser or pegged.peg working would be a first step.
>>
>
> pegged uses templates.
> There is an intersection on which it can profit from CTFE improvments. But
> for the most part, it's a different sub-system in the compiler.
>
> That said, templates are next on my TODO list.
>

Nice, so I'll be able to see separate improvements in my CTFE stuff vs the pegged template stuff once structs,  classes, etc.. are handled in your new ctfe.

On Sunday, 17 July 2016 at 16:43:18 UTC, Rory McGuire wrote:
>
> Nice, so I'll be able to see separate improvements in my CTFE stuff vs the pegged template stuff once structs,  classes, etc.. are handled in your new ctfe.

Yes.
Btw while working on printing template-instantiations I discovered that ctfe improvements will most likely have a much higher impact in template heavy code then I fist expected.

Hi,

I have fresh performance statistics:
The test[1] involved running an empty while loop.

Machine 1 Linux :
DMD release : Interpreted : 3400 ms || Pseudo-Jited 230 || 50ms Native
DMD Debug : Interpreted 4560 || Pseudo-Jited 260ms || Native 230 ms

LDC release : Interpreted 2400 ms || Pseudo-Jited 0 ms || Native 0 ms
LDC debug : Interpreted 8700 ms || Pseudo-Jited 330 ms || Native 250 ms

Machine 2 Windows :

DMD release : Interpreted : 5500 ms || Pseudo-Jited 180ms || 40ms Native
DMD Debug : Interpreted 5500 || Pseudo-Jited 320ms || Native 180 ms


Pay attention to the ratio (~4.5) between (pseudo)jit[2] and native.
This slowdown inherent in the VM design I choose.

please share your thoughts.

[1] https://github.com/UplinkCoder/dmd/blob/newCTFE/bcPerf.d
[2] https://github.com/UplinkCoder/dmd/blob/newCTFE/src/bc_c_backend.d

On Friday, 29 July 2016 at 11:30:20 UTC, Stefan Koch wrote:
> please share your thoughts.

When is this moving into dmd master?

On Friday, 29 July 2016 at 11:30:20 UTC, Stefan Koch wrote:
> I have fresh performance statistics:

Is there any improvement in memory usage?

On Friday, 29 July 2016 at 13:07:12 UTC, Edwin van Leeuwen wrote:
> On Friday, 29 July 2016 at 11:30:20 UTC, Stefan Koch wrote:
>> I have fresh performance statistics:
>
> Is there any improvement in memory usage?

Yes!
There memory usage is the same as run-time execution.
plus about 16k for the interpreter state.

On Friday, 29 July 2016 at 12:47:55 UTC, Robert burner Schadek wrote:
> On Friday, 29 July 2016 at 11:30:20 UTC, Stefan Koch wrote:
>> please share your thoughts.
>
> When is this moving into dmd master?

As soon as it passes the test-suite.
And can execute diet-ng on the fast-path.

Currently I have issues with chained binary expressions.
such as

if ((a && b) || (a && c)) {//bla}

On Friday, 29 July 2016 at 14:28:03 UTC, Stefan Koch wrote:
>
> if ((a && b) || (a && c)) {//bla}

This is now solved although quite naively at the cost of inserting twice the number of instructions for thoose cases.
Then agian we are still much faster then the old interpreter.
And I can still optimize this if it should turn out to be a bottleneck.

Tomorrow I will fix the regressed string handling.

I am very happy to announce that calls are almost working now.
And the code-gen-interface[1] is near finalization.

It should be very easy to provide different back-ends such as LLVM or libJIT now.
The missing pieces well be added during next week.

I invite everyone to comment on the interface and code.

Don't be shy and feel free to comment

[1] https://github.com/UplinkCoder/dmd/blob/newCTFE/src/bc_common.d#L313

So far the strong decoupling between dmd and the bytecode has worked out pretty well.

Being able to debug and test the bytecode component independently from the AST-processing makes for a faster development process and allows insight into the code-gen behavior.

Time for an update.
(ASCII)-Strings work reasonably well.

I am now working on supporting general Sliceing and Appending.
The effort on function calls is also still ongoing.

I added a switch to my version of dmd which allows to toggle the ctfe engine.
So now I can compare apples to apples when posting perf data.

A nice weekend to all of you.