On Wednesday, 19 October 2016 at 07:11:24 UTC, Nordlöw wrote:
> On Sunday, 25 September 2016 at 20:47:41 UTC, Stefan Koch wrote:
>> If all goes well there will be a separate nightly release build from the newCTFE branch,  sometime in October.
>>
>> I hope to get alpha bug reports that way.
>
> Have you benchmarked CTFE-heavy projects like Pegged?

It is not yet able to handle pegged.
And I suspect alot of slowness is caused by templates not by CTFE.

On 19 Oct 2016 17:46, "Stefan Koch via Digitalmars-d-announce" < digitalmars-d-announce@puremagic.com> wrote:
>
> On Wednesday, 19 October 2016 at 07:11:24 UTC, Nordlöw wrote:
>>
>> On Sunday, 25 September 2016 at 20:47:41 UTC, Stefan Koch wrote:
>>>
>>> If all goes well there will be a separate nightly release build from
the newCTFE branch,  sometime in October.
>>>
>>> I hope to get alpha bug reports that way.
>>
>>
>> Have you benchmarked CTFE-heavy projects like Pegged?
>
>
> It is not yet able to handle pegged.
> And I suspect alot of slowness is caused by templates not by CTFE.

diet-ng is probably a better "complex" benchmark.

On Sunday, 16 October 2016 at 00:27:50 UTC, Uplink_Coder wrote:
>
> Little update here:
> The LLVM backend is almost on feature parity.
> Meaning that that soon the new CTFE engine is a real jit.
> In the process I discoverd quite a few horrible bugs and inconsistency in the API.
> I am quite astonished that it ever ran before :)

Hey Guys,

I am still dealing with the many bugs that have surfaced.
It is really crazy how something so broken could have worked that well.

Originally I planned adding a ton of features, but that can only happen If the fundamental issues are fixed.

On Monday, 24 October 2016 at 05:57:42 UTC, Stefam Koch wrote:
> On Sunday, 16 October 2016 at 00:27:50 UTC, Uplink_Coder wrote:
>>
>> Little update here:
>> The LLVM backend is almost on feature parity.
>> Meaning that that soon the new CTFE engine is a real jit.
>> In the process I discoverd quite a few horrible bugs and inconsistency in the API.
>> I am quite astonished that it ever ran before :)
>
> Hey Guys,
>
> I am still dealing with the many bugs that have surfaced.
> It is really crazy how something so broken could have worked that well.
>
> Originally I planned adding a ton of features, but that can only happen If the fundamental issues are fixed.

However at the D Meetup in Berlin, I have gotten some positive feedback concerning my ByteCode-Layer.
Once the bugs are fixed and the edges are smoothed over I can see finding it's way into other parts of the compiler.

On Mon, Oct 24, 2016 at 8:17 AM, Stefam Koch via Digitalmars-d-announce < digitalmars-d-announce@puremagic.com> wrote:

> On Monday, 24 October 2016 at 05:57:42 UTC, Stefam Koch wrote:
>
>> On Sunday, 16 October 2016 at 00:27:50 UTC, Uplink_Coder wrote:
>>
>>>
>>> Little update here:
>>> The LLVM backend is almost on feature parity.
>>> Meaning that that soon the new CTFE engine is a real jit.
>>> In the process I discoverd quite a few horrible bugs and inconsistency
>>> in the API.
>>> I am quite astonished that it ever ran before :)
>>>
>>
>> Hey Guys,
>>
>> I am still dealing with the many bugs that have surfaced.
>> It is really crazy how something so broken could have worked that well.
>>
>
So true of computer programming. Particularly if the documentation for the API is awol.


>
>> Originally I planned adding a ton of features, but that can only happen If the fundamental issues are fixed.
>>
>
> However at the D Meetup in Berlin, I have gotten some positive feedback
> concerning my ByteCode-Layer.
> Once the bugs are fixed and the edges are smoothed over I can see finding
> it's way into other parts of the compiler.
>
>
Cool, thanks for the feedback.

On Monday, 24 October 2016 at 06:37:12 UTC, Rory McGuire wrote:
> Cool, thanks for the feedback.


I have take care of the blocker for now.
I turns out my tests contained wrong code that reused a register for multiple purposes.
LLVM does not like that.
So it assumed the wrong things while optimising and went into the wrong direction makeing complete bogus out of valid code.

On Tuesday, 25 October 2016 at 09:36:12 UTC, Stefam Koch wrote:
> On Monday, 24 October 2016 at 06:37:12 UTC, Rory McGuire wrote:
>> Cool, thanks for the feedback.
>
>
> I have take care of the blocker for now.
> I turns out my tests contained wrong code that reused a register for multiple purposes.
> LLVM does not like that.
> So it assumed the wrong things while optimising and went into the wrong direction makeing complete bogus out of valid code.

First perf data is in

The is measured with time src/dmd -c -ctfe-bc

old interpreter (without -ctfe-bc) :

real	0m6.839s
user	0m6.423s
sys	0m0.407s

new interpreter (-ctfe-bc)

real	0m0.549s
user	0m0.547s
sys	0m0.000s

LLVM Backend (-ctfe-bc -version=UseLLVMBackend) :

real	0m0.039s
user	0m0.027s
sys	0m0.010s


The compiled code was :
int bug6498(int x)
{
    int n = 0;
    while (n < x)
        ++n;
    return n;
}
static assert(bug6498(10_000_000)==10_000_000);

On Tuesday, 25 October 2016 at 12:36:56 UTC, Stefam Koch wrote:
> LLVM Backend (-ctfe-bc -version=UseLLVMBackend) :
>
> real	0m0.039s
> user	0m0.027s
> sys	0m0.010s

I think 20,000% is a pretty good speedup! ;)  Great stuff.

Now that JIT works, are you returning to focusing on feature coverage?

-Wyatt

On Tuesday, 25 October 2016 at 15:57:33 UTC, Wyatt wrote:
> On Tuesday, 25 October 2016 at 12:36:56 UTC, Stefam Koch wrote:
>> LLVM Backend (-ctfe-bc -version=UseLLVMBackend) :
>>
>> real	0m0.039s
>> user	0m0.027s
>> sys	0m0.010s
>
> I think 20,000% is a pretty good speedup! ;)  Great stuff.
>
> Now that JIT works, are you returning to focusing on feature coverage?
>
> -Wyatt

Yes I have already started on solidifying struct, string and slice support.
Once this is done, most of the ctfe system is in place.
The rest will be costmetics.
Make no mistake structs and slices may seem trivial but there are a few complxities hiding involved.
Particularly handling of the this pointer and accsess to member-variables.
Slices require a proper memory mangament system to be in place.
All of this needs to be platform agnostic and representable in bytecode.

On 2016-10-25 14:36, Stefam Koch wrote:

> First perf data is in
>
> The is measured with time src/dmd -c -ctfe-bc
>
> old interpreter (without -ctfe-bc) :
>
> real    0m6.839s
> user    0m6.423s
> sys    0m0.407s
>
> new interpreter (-ctfe-bc)
>
> real    0m0.549s
> user    0m0.547s
> sys    0m0.000s
>
> LLVM Backend (-ctfe-bc -version=UseLLVMBackend) :
>
> real    0m0.039s
> user    0m0.027s
> sys    0m0.010s
>
>
> The compiled code was :
> int bug6498(int x)
> {
>     int n = 0;
>     while (n < x)
>         ++n;
>     return n;
> }
> static assert(bug6498(10_000_000)==10_000_000);

Very impressive :)

-- 
/Jacob Carlborg