Am 09.04.2015 um 21:40 schrieb Sönke Ludwig:
> Am 09.04.2015 um 21:37 schrieb weaselcat:
>> On Thursday, 9 April 2015 at 19:35:24 UTC, Sönke Ludwig wrote:
>>> Am 09.04.2015 um 21:26 schrieb weaselcat:
>>>> On Thursday, 9 April 2015 at 19:17:48 UTC, Sönke Ludwig wrote:
>>>>
>>>>> Not sure, but that may also have been my recent optimizations.
>>>>
>>>> Just tried it with your recent optimizations and it doesn't build with
>>>> LDC 0.15.1.
>>>
>>> Should work now. I just tested LDC with -singleobj and it's faster
>>> than RapidJSON! Now the DOM parser gets interesting.
>>
>> What flags are you using? RapidJSON is still a lot faster for me.
>> also, I just realized the build script has the wrong inline flag for
>> LDC(it's using -enable-inlining instead of -inline)
>
> I'll have to test with that exact version, because I've used my own
> main() function for the test. The flags were: -singleobj -release -O5
> -enable-inlining -disable-bondscheck (-disable-boundscheck is only a
> little faster).

One thing about the D benchmark is that it uses readText(). To be a fair comparison with Rapid it would have to use cast(string)read() instead.

On Thursday, 9 April 2015 at 19:43:13 UTC, Sönke Ludwig wrote:
> Am 09.04.2015 um 21:40 schrieb Sönke Ludwig:
>> Am 09.04.2015 um 21:37 schrieb weaselcat:
>>> On Thursday, 9 April 2015 at 19:35:24 UTC, Sönke Ludwig wrote:
>>>> Am 09.04.2015 um 21:26 schrieb weaselcat:
>>>>> On Thursday, 9 April 2015 at 19:17:48 UTC, Sönke Ludwig wrote:
>>>>>
>>>>>> Not sure, but that may also have been my recent optimizations.
>>>>>
>>>>> Just tried it with your recent optimizations and it doesn't build with
>>>>> LDC 0.15.1.
>>>>
>>>> Should work now. I just tested LDC with -singleobj and it's faster
>>>> than RapidJSON! Now the DOM parser gets interesting.
>>>
>>> What flags are you using? RapidJSON is still a lot faster for me.
>>> also, I just realized the build script has the wrong inline flag for
>>> LDC(it's using -enable-inlining instead of -inline)
>>
>> I'll have to test with that exact version, because I've used my own
>> main() function for the test. The flags were: -singleobj -release -O5
>> -enable-inlining -disable-bondscheck (-disable-boundscheck is only a
>> little faster).
>
> One thing about the D benchmark is that it uses readText(). To be a fair comparison with Rapid it would have to use cast(string)read() instead.

I saw that commit to the benchmark and changed it locally.
They're about the same performance now comparing clang to LDC, with -inline -boundscheck=off -singleobj flags

Nice.

On Thursday, 9 April 2015 at 19:40:31 UTC, Sönke Ludwig wrote:
> Am 09.04.2015 um 21:37 schrieb weaselcat:
>> On Thursday, 9 April 2015 at 19:35:24 UTC, Sönke Ludwig wrote:
>>> Am 09.04.2015 um 21:26 schrieb weaselcat:
>>>> On Thursday, 9 April 2015 at 19:17:48 UTC, Sönke Ludwig wrote:
>>>>
>>>>> Not sure, but that may also have been my recent optimizations.
>>>>
>>>> Just tried it with your recent optimizations and it doesn't build with
>>>> LDC 0.15.1.
>>>
>>> Should work now. I just tested LDC with -singleobj and it's faster
>>> than RapidJSON! Now the DOM parser gets interesting.
>>
>> What flags are you using? RapidJSON is still a lot faster for me.
>> also, I just realized the build script has the wrong inline flag for
>> LDC(it's using -enable-inlining instead of -inline)
>
> I'll have to test with that exact version, because I've used my own main() function for the test. The flags were: -singleobj -release -O5 -enable-inlining -disable-bondscheck (-disable-boundscheck is only a little faster).

I can't remember which -O level inlining is enabled, but there's definitely no need to explicitly ask for it at -O5.

On Thursday, 9 April 2015 at 19:44:57 UTC, weaselcat wrote:
>
> I saw that commit to the benchmark and changed it locally.
> They're about the same performance now comparing clang to LDC, with -inline -boundscheck=off -singleobj flags
>
> Nice.

Also, since an LDC dev might read this - is there a reason -singleobj isn't on by default when creating an executable?

On Thursday, 9 April 2015 at 20:00:28 UTC, John Colvin wrote:
> I can't remember which -O level inlining is enabled, but there's definitely no need to explicitly ask for it at -O5.

-enable-inlining(enabled at -O2) and -inline do different things and -inline isn't automatically enabled.

Am 09.04.2015 um 15:11 schrieb Sönke Ludwig:
> Am 09.04.2015 um 14:25 schrieb Martin Nowak:
>>
>> (...)
>>
>> There are 2 very nice alternative approaches in the benchmark repo.
>>
>> https://github.com/kostya/benchmarks/blob/master/json/test_pull.cr
>> https://github.com/kostya/benchmarks/blob/master/json/test_schema.cr
>>
>
> That would be a nice intermediate level parser. However, the range based
> parser as it is now is also useful for things like automated
> deserialization (which I don't want to include at this point) where you
> don't know in which order fields come in and where you have to use that
> style of filtering through the data anyway.
>
> But if inlining works properly, it should be no problem to implement
> other APIs on top of it.

https://github.com/s-ludwig/benchmarks/blob/master/json/test_new_lazy.d

On Thursday, 9 April 2015 at 20:11:07 UTC, weaselcat wrote:
> On Thursday, 9 April 2015 at 20:00:28 UTC, John Colvin wrote:
>> I can't remember which -O level inlining is enabled, but there's definitely no need to explicitly ask for it at -O5.
>
> -enable-inlining(enabled at -O2) and -inline do different things and -inline isn't automatically enabled.

Sorry Sönke for polluting your thread, but I did some reading of the LLVM manual - -inline is a specific LLVM pass and not a frontend flag. Using the -partial-inliner pass instead it(the benchmark) becomes faster than rapidJSON.

Bye.

Am 09.04.2015 um 23:14 schrieb weaselcat:
> On Thursday, 9 April 2015 at 20:11:07 UTC, weaselcat wrote:
>> On Thursday, 9 April 2015 at 20:00:28 UTC, John Colvin wrote:
>>> I can't remember which -O level inlining is enabled, but there's
>>> definitely no need to explicitly ask for it at -O5.
>>
>> -enable-inlining(enabled at -O2) and -inline do different things and
>> -inline isn't automatically enabled.
>
> Sorry Sönke for polluting your thread, but I did some reading of the
> LLVM manual - -inline is a specific LLVM pass and not a frontend flag.
> Using the -partial-inliner pass instead it(the benchmark) becomes faster
> than rapidJSON.
>
> Bye.

Hm interesting, but for me LDC unfortunately crashes when adding -partial-inliner. What else did you specify?

On Thursday, 9 April 2015 at 21:52:08 UTC, Sönke Ludwig wrote:
> Am 09.04.2015 um 23:14 schrieb weaselcat:
>> On Thursday, 9 April 2015 at 20:11:07 UTC, weaselcat wrote:
>>> On Thursday, 9 April 2015 at 20:00:28 UTC, John Colvin wrote:
>>>> I can't remember which -O level inlining is enabled, but there's
>>>> definitely no need to explicitly ask for it at -O5.
>>>
>>> -enable-inlining(enabled at -O2) and -inline do different things and
>>> -inline isn't automatically enabled.
>>
>> Sorry Sönke for polluting your thread, but I did some reading of the
>> LLVM manual - -inline is a specific LLVM pass and not a frontend flag.
>> Using the -partial-inliner pass instead it(the benchmark) becomes faster
>> than rapidJSON.
>>
>> Bye.
>
> Hm interesting, but for me LDC unfortunately crashes when adding -partial-inliner. What else did you specify?

ldc2 -partial-inliner -boundscheck=off -singleobj -ofjson_d_new_lazy_ldc -O5 -release -w -oq -Istd_data_json/source/ std_data_json/source/stdx/data/json/*.d test_new_lazy.d

it seems to segfault with -O0 optimization

./json_d_new_lazy_ldc  0.95s user 0.08s system 99% cpu 1.025 total
(clang)./json_rapid_cpp  0.98s user 0.30s system 99% cpu 1.282 total
(gcc)./json_rapid_cpp  0.80s user 0.31s system 99% cpu 1.108 total

These are my results (a little bit flaky timings because it's a tablet PC which seems to throttle the turbo boost to not exceed the TDP):

std.json (DMD): 27.7
std.json (LDC): 72.4
stdx.data.json DOM (DMD): 8.2
stdx.data.json DOM (LDC): 3.96
stdx.data.json PULL (DMD): 2.96
stdx.data.json PULL (LDC): 1.61
RapidJSON: 1.21

I'd say these start to look good enough for a first fitness test.