On 01/10/2013 08:52 PM, Dmitry Olshansky wrote:
09-Jan-2013 15:05, Timon Gehr пишет:
On 01/08/2013 10:06 PM, Philippe Sigaud wrote:
...
Isn't SDC also in D? (Bernard Helyer and friends)
https://github.com/bhelyer/SDC
Also, Timon Gehr spoke of his own front-end (assumed to be in D) in the
past, but did not provide any link to it.
Yes, it is in D. Nothing is released yet. It needs to be polished a
little so that there are no known embarrassing shortcomings anymore.
(eg. the parser cannot parse extern(...) declarations in alias
declarations yet, and I need to finish making a minor tweak to how
template instances are analyzed in order to get circular dependency
detection to work reliably. Furthermore, examples like the following are
currently rejected, while I want it to work:
[snip]
CTFE is basically done (as a portable byte code interpreter, but other
strategies, such as JIT, could be easily plugged). This is a snippet of
my regression test suite:
auto dynRangePrimes(){
DynRange!int impl(int start)=>
dynRange(cons(start,delay(()=>filter!(a=>a%start)(impl(start+1)))));
return impl(2);
}
static assert(array(take(dynRangePrimes(), 20)) ==
[2,3,5,7,11,13,17,19,23,29,31,37,41,43,47,53,59,61,67,71]);
)
Cool! I'd love to take even the very preliminary peek at the speed
profile of this CTFE engine.
If you are interested I'd love to test a small (the code though contains
a lot of static data) CTFE benchmark that is the bottleneck in the
compilation of current ctRegex.
See the attachment here:
http://d.puremagic.com/issues/show_bug.cgi?id=7442
would be nice to see some rough numbers for this vs DMD.
I'll let you know as soon as the example runs. Currently this is blocked
by the missing implementation for the following language features:
- import declarations
- UFCS
- Optional parens on function calls
- Struct literals
- Static struct data
- debug declarations
- Some of the built-in array operations
- Missing object.d (no string, size_t, hash_t alias.)
- (static) foreach
- __ctfe
I will prioritize those features. Except import declarations, they are
mostly easy to implement, but I haven't gotten around to them yet.
For the meantime, maybe these quick measurements are somewhat useful:
int[] erathos(int x){
bool[] p;
for(int i=0;i<=x;i++) p~=true;
for(int i=3;i*i<=x;i+=2){
if(p[i]) for(int k=i*i;k<=x;k=k+i) p[k]=false;
}
int[] r;
if(x>=2) r~=2;
for(int i=3;i<=x;i+=2) if(p[i]) r~=i;
return r;
}
pragma(msg, "erathos: ",erathos(40000).length);
The frontend (32-bit dmd build, without -inline, otherwise DMD ICEs):
$ time ./d erathos.d
erathos: 4203U
real 0m0.077s
user 0m0.076s
sys 0m0.000s
DMD 2.060 (64 bit):
$ time dmd -o- erathos.d
erathos: 4203u
real 0m2.594s
user 0m0.716s
sys 0m1.696s
...
pragma(msg, "erathos: ",erathos(400000)); // (that is one 0 more)
The frontend:
erathos: 33860U
real 0m0.662s
user 0m0.660s
sys 0m0.000s
DMD: brings down the machine
pragma(msg, "erathos: ",erathos(4000000)); // (yet another 0 more)
The frontend:
erathos: 283146U
real 0m6.867s
user 0m6.832s
sys 0m0.016s
// pragma(msg, "erathos: ",erathos(4000000));
void main(){
import std.stdio;
writeln(erathos(4000000).length);
}
$ dmd -O -release -inline -noboundscheck erathos.d && time ./erathos
dmd: module.c:829: void Module::semantic3(): Assertion `semanticstarted
== 2' failed.
(I'll see if it also fails with DMD 2.061.)
$ dmd -O -release -noboundscheck erathos.d && time ./erathos
283146
real 0m0.144s
user 0m0.132s
sys 0m0.008s
So CTFE in the front end seems to be ~50 times slower than a optimized
DMD build of the same code in this case. But note that it is powered by
a simple-minded bytecode interpreter I hacked together mostly during two
weekends. (the array append is the one from druntime) A lot more is
possible. I guess it is already fast enough to power std.regex.
