std.d.lexer performance (WAS: std.d.lexer : voting thread)

[Dmitry Olshansky]

11-Oct-2013 13:07, Jonathan M Davis пишет:
> On Friday, October 11, 2013 12:56:14 Dmitry Olshansky wrote:
>> 04-Oct-2013 15:28, Brian Schott пишет:
>>> On Thursday, 3 October 2013 at 20:11:02 UTC, Andrei Alexandrescu wrote:
>>>> I see we're considerably behind dmd. If improving performance would
>>>> come at the price of changing the API, it may be sensible to hold off
>>>> adoption for a bit.
>>>>
>>>> Andrei
>>>
>>> The old benchmarks measured total program run time. I ran a new set of
>>> benchmarks, placing stopwatch calls around just the lexing code to
>>> bypass any slowness caused by druntime startup. I also made a similar
>>> modification to DMD.
>>>
>>> Here's the result:
>>>
>>> https://raw.github.com/Hackerpilot/hackerpilot.github.com/master/experimen
>>> tal/std_lexer/images/times5.png
>>>
>>>
>>> I suspect that I've made an error in the benchmarking due to how much
>>> faster std.d.lexer is than DMD now, so I've uploaded what I have to
>>> Github.
>>>
>>> https://github.com/Hackerpilot/lexerbenchmark
>>
>> I'm suspicious of:
>> printf("%s\t%f\n", srcname, (total / 200.0) / (1000 * 100));
>>
>> Plus I think clock_gettime often has too coarse resolution (I'd use
>> gettimeofday as more reliable).
>> Also check core\time.d  TickDuration.currSystemTick as it uses
>> CLOCK_MONOTONIC on *nix. You should do the same to make timings meaningful.
>
> Why not just use use std.datetime's benchmark or StopWatch? Though looking at
> lexerbenchmark.d it looks like he's using StopWatch rather than clock_gettime
> directly, and there are no printfs, so I don't know what code you're referring
> to here. From the looks of it though, he's basically reimplemented
> std.datetime.benchmark in benchmarklexer.d and probably should have just used
> benchmark instead.

Cause it's C++ damn it! ;)
>
> - Jonathan M Davis
>


-- 
Dmitry Olshansky