0

I need advice on my first D-project . I have uploaded it at :-

https://bitbucket.org/mrjohns/matcher/downloads

IDEA : Benchmarking of 3 runtime algorithms and comparing them to their compile-time variants. The only difference between these is that for the compile time-ones, the lookup tables (i.e. Arrays bmBc, bmGs, and suffixes ) must be computed at compile time( I currently rely on CTFE ) . While for the runtime-ones the lookup tables are computed on runtime.

NB : The pattern matching algorithms themselves need not be executed at compile-time, only the lookup tables.Having stated this the algorithms which run on known( compile-time computed) tables must be faster than the ones which have to compute them at runtime.

My results seem to show something different, only the first pair( BM_Runtime and BM_Compile-time) yields admissible results, the other two pair give higher execution time for the compile-time variants. I think am missing something here. Please help.

Current Results for the pattern="GCAGAGAG" are as below :-

**BM_Runtime**          = 366 hnsecs     position=   513

**BM_Compile-time**     = 294 hnsecs     position   =513

**BMH_Runtime**         = 174 hnsecs     position=   513

**BMH_Compile-time**    = 261 hnsecs     position=   513

**AG_Run-time**         = 258 hnsecs    position=   513

**AG_Compile-time**     = 268 hnsecs    position=   513

Running the code : dmd -J. matcher.d inputs.d rtime_pre.d ctime_pre.d && numactl --physcpubind=0 ./matcher

I would appreciate your suggestions.

Thanking you in advince.

sigod
  • 3,514
  • 2
  • 21
  • 44
Walker
  • 323
  • 1
  • 12
  • Any performance test without activating compiler optimization is not useful. – sibnick Aug 17 '15 at 14:57
  • @sibnick , thanks. But I have never done that before . How could it be done? – Walker Aug 17 '15 at 15:11
  • Note that DMD doesn't produce very efficient code, even with optimizations on. LDC and GDC use the llvm and the GCC backends respectively, which have much more work put into their optimizers. – Colonel Thirty Two Aug 17 '15 at 20:02

1 Answers1

1

Any performance test without activating compiler optimization is not useful. You should add dmd -release -inline -O -boundscheck=off. Also usually performance tests use cycles for repeating calculations. Otherwise you may get incorrect results.

sibnick
  • 3,995
  • 20
  • 20
  • I have tried this : `dmd -J. -release -O -inline -noboundscheck matcher.d inputs.d rtime_pre.d ctime_pre.d && numactl --physcpubind=0 ./matcher` putting `-noboundscheck =off` doesnt work – Walker Aug 17 '15 at 15:24
  • dmd version? I use 2.0.68 – sibnick Aug 17 '15 at 15:36
  • My dmd version is 2.066.1 – Walker Aug 17 '15 at 15:59
  • ` -noboundscheck` is deprecated now, and replaced by ` -boundscheck=[on|safeonly|off] ` in newer dmd versions – sibnick Aug 17 '15 at 16:54
  • The surprising thing is the D-profiler gives plausable results:- `2921 int rtime_pre.bm_rmatch(const(immutable(char)[]), const(immutable(char)[])) 2122 int ctime_pre.bm_cmatch(int[char], int[8]) 1317 int rtime_pre.bmh_rmatch(const(immutable(char)[]), const(immutable(char)[])) 1099 int ctime_pre.bmh_cmatch(int[char]) 3959 int rtime_pre.ag_rmatch(immutable(char)[], const(immutable(char)[])) 2688 pure int ctime_pre.ag_cmatch(const(immutable(char)[]), const(immutable(char)[]), int[char], int[8])` My timer may be wrong... – Walker Aug 17 '15 at 17:49
  • sorry for the poor formatting . This is the compilation command I used :- `dmd -J. -release -O -inline -boundscheck=off -profile matcher.d inputs.d rtime_pre.d ctime_pre.d && numactl --physcpubind=0 ./matcher` incase you wanted to investigate. – Walker Aug 17 '15 at 17:55