Re: Battle-plan for CTFE
On Tuesday, 25 October 2016 at 17:19:26 UTC, Jacob Carlborg wrote:
Very impressive :)
Thanks.
I just got the following code to compile and execute correctly.
bool strEq(string a, string b)
{
if (a.length != b.length)
{
return false;
}
uint length = cast(uint) a.length;
while(length--)
{
auto c1 = a[length];
auto c2 = b[length];
if (c1 != c2)
{
return false;
}
}
return true;
}
static assert(!strEq("Hello","World"));
static assert(strEq("World","World"));
I used the generated bytecode to make == for strings work.
Re: The DLang UPB Languages and Systems Research Scholarship
On Tuesday, 25 October 2016 at 22:15:38 UTC, Andrei Alexandrescu wrote: The D Language Foundation is proud to announce its first scholarship, offered to CS and EE students at University "Politehnica" Bucharest in Romania. More details here: http://dlang.org/dlangupb-scholarship.html For anyone tempted to share this on /r/programming, please wait! I hope to do a blog post about this on Friday, so I'll post to reddit then. Thanks!
The DLang UPB Languages and Systems Research Scholarship
The D Language Foundation is proud to announce its first scholarship, offered to CS and EE students at University "Politehnica" Bucharest in Romania. More details here: http://dlang.org/dlangupb-scholarship.html We are very excited about this program and hope to extend it to other universities in the future. Thanks, Andrei
Re: Battle-plan for CTFE
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) :
real0m6.839s
user0m6.423s
sys0m0.407s
new interpreter (-ctfe-bc)
real0m0.549s
user0m0.547s
sys0m0.000s
LLVM Backend (-ctfe-bc -version=UseLLVMBackend) :
real0m0.039s
user0m0.027s
sys0m0.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
Re: Battle-plan for CTFE
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) : real0m0.039s user0m0.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.
Re: Battle-plan for CTFE
On Tuesday, 25 October 2016 at 12:36:56 UTC, Stefam Koch wrote: LLVM Backend (-ctfe-bc -version=UseLLVMBackend) : real0m0.039s user0m0.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
Re: Battle-plan for CTFE
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) :
real0m6.839s
user0m6.423s
sys 0m0.407s
new interpreter (-ctfe-bc)
real0m0.549s
user0m0.547s
sys 0m0.000s
LLVM Backend (-ctfe-bc -version=UseLLVMBackend) :
real0m0.039s
user0m0.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);
Re: Battle-plan for CTFE
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.
