August 22, 2020
On 8/22/20 3:34 PM, Avrina wrote:
> On Saturday, 22 August 2020 at 19:20:34 UTC, Andrei Alexandrescu wrote:
>> On 8/22/20 1:40 PM, kinke wrote:
>>> On Saturday, 22 August 2020 at 16:15:14 UTC, H. S. Teoh wrote:
>>>> 3) std.math.fmax calling the C library (involving a PIC indirection to a
>>>> shared library as opposed to inlineable native D code).
>>>
>>> Yes, and that's because there's only a `real` version for fmax.
>>>
>>> If upstream Phobos had proper double/float overloads, we could uncomment the LDC-specific implementations using LLVM intrinsics, which use (obviously much faster) SSE instructions:
>>>
>>> https://github.com/ldc-developers/phobos/blob/1366c7d5be65def916f030785fc1f1833342497d/std/math.d#L7785-L7798 
>>>
>>>
>>>
>>> Number crunching in D could be significantly accelerated if the people interested in it showed some love for std.math, but we've had this topic for years.
>>
>> Ow, do we still suffer from that? Sigh.
>>
>> https://github.com/dlang/phobos/pull/7604/files
>>
>> It's 10 minutes of work - as much as writing a couple of posts, and much more satisfactory.
> 
> Cos, sin, tan, asin, acos, atan, etc.. There's still more, putting in the actual work that std.math needs is going to take more than 10 mins.

1. Linear time for small n is fine and does not affect the argument.

2. Incremental is still fine.

3. Work has actually be done by Nick Wilson in https://github.com/dlang/phobos/pull/7463.
August 22, 2020
On Saturday, 22 August 2020 at 19:34:42 UTC, Avrina wrote:
> Cos, sin, tan, asin, acos, atan, etc.. There's still more, putting in the actual work that std.math needs is going to take more than 10 mins.

These functions are a lot more involved indeed; I've taken care of a few of these some years ago, porting from the Cephes C library, see https://github.com/dlang/phobos/pull/6272. The main difficulty is the need to support 4 floating-point formats - single, double, x87 extended and quadruple precision.
August 22, 2020
On Saturday, 22 August 2020 at 21:20:36 UTC, Andrei Alexandrescu wrote:
> On 8/22/20 3:34 PM, Avrina wrote:
>> On Saturday, 22 August 2020 at 19:20:34 UTC, Andrei Alexandrescu wrote:
>>> On 8/22/20 1:40 PM, kinke wrote:
>>>> On Saturday, 22 August 2020 at 16:15:14 UTC, H. S. Teoh wrote:
>>>>> 3) std.math.fmax calling the C library (involving a PIC indirection to a
>>>>> shared library as opposed to inlineable native D code).
>>>>
>>>> Yes, and that's because there's only a `real` version for fmax.
>>>>
>>>> If upstream Phobos had proper double/float overloads, we could uncomment the LDC-specific implementations using LLVM intrinsics, which use (obviously much faster) SSE instructions:
>>>>
>>>> https://github.com/ldc-developers/phobos/blob/1366c7d5be65def916f030785fc1f1833342497d/std/math.d#L7785-L7798
>>>>
>>>>
>>>>
>>>> Number crunching in D could be significantly accelerated if the people interested in it showed some love for std.math, but we've had this topic for years.
>>>
>>> Ow, do we still suffer from that? Sigh.
>>>
>>> https://github.com/dlang/phobos/pull/7604/files
>>>
>>> It's 10 minutes of work - as much as writing a couple of posts, and much more satisfactory.
>> 
>> Cos, sin, tan, asin, acos, atan, etc.. There's still more, putting in the actual work that std.math needs is going to take more than 10 mins.
>
> 1. Linear time for small n is fine and does not affect the argument.

What argument?

> 2. Incremental is still fine.

It can introduce subtle bugs and problems with precision, flip flopping between float, double, and real. If it is done all at once, it will only happen once, not every time someone feels like spend 10 mins doing a little bit of work to change one function. It really shouldn't have been implemented this way in the first place.

> 3. Work has actually be done by Nick Wilson in https://github.com/dlang/phobos/pull/7463.

A dead pull request? Not unusual.

August 22, 2020
On 8/22/20 6:09 PM, Avrina wrote:
> On Saturday, 22 August 2020 at 21:20:36 UTC, Andrei Alexandrescu wrote:
>> On 8/22/20 3:34 PM, Avrina wrote:
>>> On Saturday, 22 August 2020 at 19:20:34 UTC, Andrei Alexandrescu wrote:
>>>> On 8/22/20 1:40 PM, kinke wrote:
>>>>> On Saturday, 22 August 2020 at 16:15:14 UTC, H. S. Teoh wrote:
>>>>>> 3) std.math.fmax calling the C library (involving a PIC indirection to a
>>>>>> shared library as opposed to inlineable native D code).
>>>>>
>>>>> Yes, and that's because there's only a `real` version for fmax.
>>>>>
>>>>> If upstream Phobos had proper double/float overloads, we could uncomment the LDC-specific implementations using LLVM intrinsics, which use (obviously much faster) SSE instructions:
>>>>>
>>>>> https://github.com/ldc-developers/phobos/blob/1366c7d5be65def916f030785fc1f1833342497d/std/math.d#L7785-L7798 
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> Number crunching in D could be significantly accelerated if the people interested in it showed some love for std.math, but we've had this topic for years.
>>>>
>>>> Ow, do we still suffer from that? Sigh.
>>>>
>>>> https://github.com/dlang/phobos/pull/7604/files
>>>>
>>>> It's 10 minutes of work - as much as writing a couple of posts, and much more satisfactory.
>>>
>>> Cos, sin, tan, asin, acos, atan, etc.. There's still more, putting in the actual work that std.math needs is going to take more than 10 mins.
>>
>> 1. Linear time for small n is fine and does not affect the argument.
> 
> What argument?
> 
>> 2. Incremental is still fine.
> 
> It can introduce subtle bugs and problems with precision, flip flopping between float, double, and real. If it is done all at once, it will only happen once, not every time someone feels like spend 10 mins doing a little bit of work to change one function. It really shouldn't have been implemented this way in the first place.
> 
>> 3. Work has actually be done by Nick Wilson in https://github.com/dlang/phobos/pull/7463.
> 
> A dead pull request? Not unusual.

You seem to derive good enjoyment out of making unkind comments.
August 24, 2020
On Sunday, 23 August 2020 at 02:18:19 UTC, Andrei Alexandrescu wrote:
> On 8/22/20 6:09 PM, Avrina wrote:
>> On Saturday, 22 August 2020 at 21:20:36 UTC, Andrei Alexandrescu wrote:
>>> On 8/22/20 3:34 PM, Avrina wrote:
>>>> On Saturday, 22 August 2020 at 19:20:34 UTC, Andrei Alexandrescu wrote:
>>>>> On 8/22/20 1:40 PM, kinke wrote:
>>>>>> On Saturday, 22 August 2020 at 16:15:14 UTC, H. S. Teoh wrote:
>>>>>>> 3) std.math.fmax calling the C library (involving a PIC indirection to a
>>>>>>> shared library as opposed to inlineable native D code).
>>>>>>
>>>>>> Yes, and that's because there's only a `real` version for fmax.
>>>>>>
>>>>>> If upstream Phobos had proper double/float overloads, we could uncomment the LDC-specific implementations using LLVM intrinsics, which use (obviously much faster) SSE instructions:
>>>>>>
>>>>>> https://github.com/ldc-developers/phobos/blob/1366c7d5be65def916f030785fc1f1833342497d/std/math.d#L7785-L7798
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> Number crunching in D could be significantly accelerated if the people interested in it showed some love for std.math, but we've had this topic for years.
>>>>>
>>>>> Ow, do we still suffer from that? Sigh.
>>>>>
>>>>> https://github.com/dlang/phobos/pull/7604/files
>>>>>
>>>>> It's 10 minutes of work - as much as writing a couple of posts, and much more satisfactory.
>>>>
>>>> Cos, sin, tan, asin, acos, atan, etc.. There's still more, putting in the actual work that std.math needs is going to take more than 10 mins.
>>>
>>> 1. Linear time for small n is fine and does not affect the argument.
>> 
>> What argument?
>> 
>>> 2. Incremental is still fine.
>> 
>> It can introduce subtle bugs and problems with precision, flip flopping between float, double, and real. If it is done all at once, it will only happen once, not every time someone feels like spend 10 mins doing a little bit of work to change one function. It really shouldn't have been implemented this way in the first place.
>> 
>>> 3. Work has actually be done by Nick Wilson in https://github.com/dlang/phobos/pull/7463.
>> 
>> A dead pull request? Not unusual.
>
> You seem to derive good enjoyment out of making unkind comments.

I am an observer of truth, if you don't like the truth, look away; as it seems to be common place here anyways.
August 24, 2020
On Saturday, 22 August 2020 at 16:15:14 UTC, H. S. Teoh wrote:
> On Sat, Aug 22, 2020 at 02:08:40AM +0000, bachmeier via Digitalmars-d wrote: [...]
>> I have no desire to dig into it myself, but I'll just note that if you check the CLBG, you'll see that it's not hard to write C and C++ programs for this benchmark that are many times slower than Node JS. The worst of them takes seven times longer to run.
>
> As described in my other post, my analysis of James' code reveals the following issues:
>
> 1) Using class instead of struct;
>
> 2) Using real instead of double;
>
> 3) std.math.fmax calling the C library (involving a PIC indirection to a
> shared library as opposed to inlineable native D code).
>
> Addressing all 3 issues yielded a 67% improvement (from class + real + C
> fmax -> struct + double + native fmax), or 37% improvement (from class +
> double + C fmax -> struct + double + native fmax).
>
> I don't have a Node.js environment, though, so I can't make a direct comparison with the optimized D version.
>
> I will note, though, that (1) and (2) are well-known performance issues; I'm surprised that this was not taken into account in the original comparison. (3) is something worth considering for std.math -- yes it's troublesome to have to maintain D versions of these functions, but they *could* make a potentially big performance impact by being inlineable in hot inner loops.

Well, I'm not going to debate the possibility that D will outperform Node with appropriate optimization. It's clear from the C and C++ timings, though, that you can't just type out a C, C++, or D program and expect to beat Node - it's going to take some care and knowledge that you really don't need with Node.

1 2 3
Next ›   Last »