On Monday, 31 October 2016 at 13:29:01 UTC, Stefan Koch wrote:
> Hi Guys, since I got a few complaints about giving minor status updates in the announce group, I am opening this thread.
>
> I will start with giving an overview of what works and what does not work.
>
> Currently the only basic type you can do arithmetic on is int.
> Altough you can compare longs since a few days.
>
> These are the constructs that will work.
>
> - foreach on static arrays strings and range-foreach  (those kinds (0 .. 64)).
> - switches (even deeply nested ones)
> - for and while loops
> - ternary expressions (? :)
> - if and else statements (as long as you don't use && and || )
> - lables and gotos
> - arithmetic expressions as well as post and pre increment and decrement
>
> Constructs that will not work (but are actively worked on)
>
> - assignment to static array cells
> - long ulong arithmetic.
> - function calls
> - dynamic arrays and slices
> - pointers
> - structs
> - && and ||
> - sliceing
>
> Constructs that will not work and are futher down the list.
>
> - classes
> - closures
> - boundschecks
> - asserts
>
> Please note that there will probably be bugs all over the place.
> So even the working features might not be working completely.

Remember those numbers ?
[root@localhost dmd]# time src/dmd -c testSettingArrayLength.d  -bc-ctfe
2147385345u
536821761u
4294639619u

real	0m0.114s
user	0m0.110s
sys	0m0.003s

This is how they look like after my performance fixes:

real	0m0.047s
user	0m0.043s
sys	0m0.000s

On Sunday, 11 December 2016 at 08:33:49 UTC, Stefan Koch wrote:
> On Monday, 31 October 2016 at 13:29:01 UTC, Stefan Koch wrote:
>> Hi Guys, since I got a few complaints about giving minor status updates in the announce group, I am opening this thread.
>>
>> I will start with giving an overview of what works and what does not work.
>>
>> Currently the only basic type you can do arithmetic on is int.
>> Altough you can compare longs since a few days.
>>
>> These are the constructs that will work.
>>
>> - foreach on static arrays strings and range-foreach  (those kinds (0 .. 64)).
>> - switches (even deeply nested ones)
>> - for and while loops
>> - ternary expressions (? :)
>> - if and else statements (as long as you don't use && and || )
>> - lables and gotos
>> - arithmetic expressions as well as post and pre increment and decrement
>>
>> Constructs that will not work (but are actively worked on)
>>
>> - assignment to static array cells
>> - long ulong arithmetic.
>> - function calls
>> - dynamic arrays and slices
>> - pointers
>> - structs
>> - && and ||
>> - sliceing
>>
>> Constructs that will not work and are futher down the list.
>>
>> - classes
>> - closures
>> - boundschecks
>> - asserts
>>
>> Please note that there will probably be bugs all over the place.
>> So even the working features might not be working completely.
>
> Remember those numbers ?
> [root@localhost dmd]# time src/dmd -c testSettingArrayLength.d  -bc-ctfe
> 2147385345u
> 536821761u
> 4294639619u
>
> real	0m0.114s
> user	0m0.110s
> sys	0m0.003s
>
> This is how they look like after my performance fixes:
>
> real	0m0.047s
> user	0m0.043s
> sys	0m0.000s

Disregard That!
I wasn't paying attention
The lower numbers are produced by ldc!
The performance fixes did lower the overall overhead even more though.
Which means bytecode generation will not even show up among the top 50 functions in dmd,

On Sunday, 11 December 2016 at 08:37:28 UTC, Stefan Koch wrote:
> Disregard That!
> I wasn't paying attention
> The lower numbers are produced by ldc!
> The performance fixes did lower the overall overhead even more though.
> Which means bytecode generation will not even show up among the top 50 functions in dmd,

Would you say it has ended up being more or less (or roughly equal) work than you initially expected?

And keep up the good work!

On Sunday, 11 December 2016 at 09:05:26 UTC, Anonymouse wrote:
>
> Would you say it has ended up being more or less (or roughly equal) work than you initially expected?
>
> And keep up the good work!

I did expect a lot of work.
But with debugging it exceeded my expectations.
Originally I planned for this to over in 3 months.
Now I am going finish the 6th month and it won't be done completely.

I am just happy that I could keep the bytecode-overhead so low that no one will notice a slow-down when we switch engines.

Work on function-calls is still progressing.

On Sunday, 11 December 2016 at 09:13:41 UTC, Stefan Koch wrote:
> Originally I planned for this to over in 3 months.
> Now I am going finish the 6th month and it won't be done completely.

I hear that.

As an anecdote, by Binderoo work has been functional for months; but it's only now becoming usable by normal people. And then once normal people use it, there's gonna be tons of bugs and edge cases that I need to blitz through. But I will have a framework that people can use to do Unity-style development of code using D as their rapid iteration language at the end of it.

I've been moving more stuff out of templates and in to CTFE in anticipation for this work hitting main.

On Sunday, 11 December 2016 at 09:13:41 UTC, Stefan Koch wrote:
> On Sunday, 11 December 2016 at 09:05:26 UTC, Anonymouse wrote:
>>
>> Would you say it has ended up being more or less (or roughly equal) work than you initially expected?
>>
>> And keep up the good work!
>
> I did expect a lot of work.
> But with debugging it exceeded my expectations.
> Originally I planned for this to over in 3 months.
> Now I am going finish the 6th month and it won't be done completely.
>
> I am just happy that I could keep the bytecode-overhead so low that no one will notice a slow-down when we switch engines.
>
> Work on function-calls is still progressing.

I just fixed labled for and foreach!

uint fn1()
{
    uint result;
    L: foreach (i; 0 .. 24)
    {
        if (i != 4)
            continue L;
        result += i;
    }
    return result;
}

static assert(fn1() == 4);

This will work now.
Whereas before it ignored the continue.

Hi Guys, I just fixed the LLVM-Backend a little.
It's about 4000 times slower to start up then the interpreter.
And has 1000 microseconds overhead per evaluation.

If you don't want to run a raytracer at compiletime I doubt that the llvm backend is the right one for you.

That said, it's a great fit for getting started in compiler development.
It can also be used to show potential optimization our own peephole optimizer could do.

The llvm backend will currently not run the whole test-suite because it fails on ++ (because of a missing load-store cycle I suspect)...
The strange thing here is, that it only fails sometimes :)

On 2016-12-13 08:21, Stefan Koch wrote:
> Hi Guys, I just fixed the LLVM-Backend a little.
> It's about 4000 times slower to start up then the interpreter.
> And has 1000 microseconds overhead per evaluation.
>
> If you don't want to run a raytracer at compiletime I doubt that the
> llvm backend is the right one for you.

IIRC, the Higgs JavaScript JIT compiler doesn't always use JIT because sometimes it faster to interpret because JIT has some overhead. Not sure if this is still the case and how it chooses when to interpret or when to JIT.

-- 
/Jacob Carlborg

On Tuesday, 13 December 2016 at 07:53:56 UTC, Jacob Carlborg wrote:
> On 2016-12-13 08:21, Stefan Koch wrote:
>> Hi Guys, I just fixed the LLVM-Backend a little.
>> It's about 4000 times slower to start up then the interpreter.
>> And has 1000 microseconds overhead per evaluation.
>>
>> If you don't want to run a raytracer at compiletime I doubt that the
>> llvm backend is the right one for you.
>
> IIRC, the Higgs JavaScript JIT compiler doesn't always use JIT because sometimes it faster to interpret because JIT has some overhead. Not sure if this is still the case and how it chooses when to interpret or when to JIT.

Higgs IR is high-level which makes a translation step to a lower ir and then x86 unavoidable.

My architecture allows to emit assembly directly (while everything is still hot and steamy in the cache).
Therefore JIT will _ALWAYS_ be faster then interpretation.
Given that a executeble-page is already allocated.
Since getting the page from the OS can take a long time.

I made good progress on function calls today.
By deferring them we get both better bytecode-generator performance and simpler code.
Since the deferring step seems to work, you can expect calls to work by the end of next week.

When function-calls work, I will direct efforts towards correct handling of || and &&,
since it is very annoying to work around the lack of them :)

Also start-up times for ctfe are still dropping.
When the old ctfe is completely replaced, (hopefully around February)
I can reasonably expect compile-times to be reduced by over 65% (given that ctfe was the bottleneck)

Cheers,
Stefan