On Thursday, 8 December 2016 at 19:49:47 UTC, Faux Amis wrote:
> Any reason for the infinite depth update posting style?
> I would have loved to see each update to be a child of the root post with its own discussions tree.
> Currently, the posts are quite unreadable in tree view (thunderbird).
>
>
> On 2016-10-31 14:29, 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.

The reason it that I don't use the tree view.
I just answer to myself every time I have an update.
It looks fine on the web-frontend.

On 12/08/2016 04:24 PM, Stefan Koch wrote:
> Results are obtained running the following code
> uint MakeInitAndSumArray(uint length)
> {
>     uint result;
>     uint[] arr;
>     arr.length = length;
>
>     while(length--)
>     {
>         arr[length] = length;
>     }
>     foreach(e;arr)
>     {
>       result += e;
>     }
>
>     return result;
> }
>
> pragma(msg, MakeInitAndSumArray(ushort.max));
> pragma(msg, MakeInitAndSumArray(ushort.max/2));
> pragma(msg, MakeInitAndSumArray(ushort.max*2));

That's pretty awesome. The new CTFE engine release will soon rival Tesla Model 3 in terms of interest raised :o).

In addition to artificial corpora like the above, I suggest comparing against real-world code - starting with simpler things such as bitfields instantiations.


Andrei

On Friday, 9 December 2016 at 02:10:58 UTC, Andrei Alexandrescu wrote:
> On 12/08/2016 04:24 PM, Stefan Koch wrote:
>> Results are obtained running the following code
>> uint MakeInitAndSumArray(uint length)
>> {
>>     uint result;
>>     uint[] arr;
>>     arr.length = length;
>>
>>     while(length--)
>>     {
>>         arr[length] = length;
>>     }
>>     foreach(e;arr)
>>     {
>>       result += e;
>>     }
>>
>>     return result;
>> }
>>
>> pragma(msg, MakeInitAndSumArray(ushort.max));
>> pragma(msg, MakeInitAndSumArray(ushort.max/2));
>> pragma(msg, MakeInitAndSumArray(ushort.max*2));
>
> That's pretty awesome. The new CTFE engine release will soon rival Tesla Model 3 in terms of interest raised :o).
>
> In addition to artificial corpora like the above, I suggest comparing against real-world code - starting with simpler things such as bitfields instantiations.
>
>
> Andrei

That will not work currently.
Since function and methods calls are still "in the works".
They will require another restructuring as well.
Therefore artificial tests are the best I can do to gunge performance.

On 2016-12-09 00:00, Stefan Koch wrote:
> On Thursday, 8 December 2016 at 19:49:47 UTC, Faux Amis wrote:
>> Any reason for the infinite depth update posting style?
>> I would have loved to see each update to be a child of the root post
>> with its own discussions tree.
>> Currently, the posts are quite unreadable in tree view (thunderbird).
>>
>>
>> On 2016-10-31 14:29, 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.
>
> The reason it that I don't use the tree view.
> I just answer to myself every time I have an update.
> It looks fine on the web-frontend.

Might you consider making use of the tree data structure?
It really has quite nice properties with regard to discussions..
(check the threaded view mode, everybody else seems to use it like that)
Anyway, I kinda missed the updates because I thought it was just a very deep discussion until I noticed it was mostly you posting ;)

On Friday, 9 December 2016 at 03:06:49 UTC, Stefan Koch wrote:
> On Friday, 9 December 2016 at 02:10:58 UTC, Andrei Alexandrescu wrote:
>> That's pretty awesome. The new CTFE engine release will soon rival Tesla Model 3 in terms of interest raised :o).
>>
>> In addition to artificial corpora like the above, I suggest comparing against real-world code - starting with simpler things such as bitfields instantiations.
>>
>>
>> Andrei
>
> That will not work currently.
> Since function and methods calls are still "in the works".
> They will require another restructuring as well.
> Therefore artificial tests are the best I can do to gunge performance.

Progress has been made on this front.
However I discovered that some math is translated incorrectly.
This means I have to fix the code-gen again.
So you'll have to wait a bit until this works :).

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.

FunctionPointers and plain function calls are currently in progress!
Also I made further performance improvements to the Bytecode-generator.
As of now it needs around 50 nano-seconds per generated instruction.
Generation + Interpretation execution of trivial functions now takes LESS then a microsecond on contemporary machines!

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.

I just fixed a really nasty bug  that prevented the following code from working in newCTFE.

int computeFib(int n)
{
    int t = 1;
    int result = 0;

    while(n--)
    {
        result = t - result;
        t = t + result;
    }

   return result;
}

static assert(computeFib(12) == 144);

The line result = t - result is the one triggering the bug.
Because newCTFE broke it down like this
result = t;
result -= result;

This was not found by the compilers testsuite!
I guess we should add it.

On Saturday, 10 December 2016 at 11:03:11 UTC, Stefan Koch wrote:
> This was not found by the compilers testsuite!

Have you already thought to use fuzz testing ?

I'm sure it would find some weird failure cases. The other day I've found that `enum a=null+null;` triggers a CTFE ICE. It's on the old engine but a tool with a "mean and nasty" approach could have found it.

On Saturday, 10 December 2016 at 07:24:10 UTC, Stefan Koch wrote:
>
> FunctionPointers and plain function calls are currently in progress!
> Also I made further performance improvements to the Bytecode-generator.
> As of now it needs around 50 nano-seconds per generated instruction.
> Generation + Interpretation execution of trivial functions now takes LESS then a microsecond on contemporary machines!

Function-call support has broken the bailout capability.
I am working on restoring it.

On Saturday, 10 December 2016 at 18:51:32 UTC, Stefan Koch wrote:
> On Saturday, 10 December 2016 at 07:24:10 UTC, Stefan Koch wrote:
>>
>> FunctionPointers and plain function calls are currently in progress!
>> Also I made further performance improvements to the Bytecode-generator.
>> As of now it needs around 50 nano-seconds per generated instruction.
>> Generation + Interpretation execution of trivial functions now takes LESS then a microsecond on contemporary machines!
>
> Function-call support has broken the bailout capability.
> I am working on restoring it.

I just fixed the bailout.
certain switch-statements.
And made the creation of bytecode even cheaper.