www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Atila Neves: "C IS NOT MAGICALLY FAST, PART 2"

reply Saurabh Das <saurabh.das gmail.com> writes:
Posted on Atila's blog yesterday:

https://atilanevesoncode.wordpress.com/2016/07/18/c-is-not-magically-fast-part-2/
Jul 18 2016
next sibling parent reply deadalnix <deadalnix gmail.com> writes:
On Tuesday, 19 July 2016 at 02:54:37 UTC, Saurabh Das wrote:

 Posted on Atila's blog yesterday:

 https://atilanevesoncode.wordpress.com/2016/07/18/c-is-not-magically-fast-part-2/


Where is the part one ?
Jul 18 2016
next sibling parent Meta <jared771 gmail.com> writes:
On Tuesday, 19 July 2016 at 03:03:38 UTC, deadalnix wrote:

 On Tuesday, 19 July 2016 at 02:54:37 UTC, Saurabh Das wrote:

 Posted on Atila's blog yesterday:

 https://atilanevesoncode.wordpress.com/2016/07/18/c-is-not-magically-fast-part-2/


 Where is the part one ?


https://atilanevesoncode.wordpress.com/2015/08/24/c-is-not-magically-fast/
Jul 18 2016
prev sibling parent Craig Dillabaugh <craig.dillabaugh gmail.com> writes:
On Tuesday, 19 July 2016 at 03:03:38 UTC, deadalnix wrote:

 On Tuesday, 19 July 2016 at 02:54:37 UTC, Saurabh Das wrote:

 Posted on Atila's blog yesterday:

 https://atilanevesoncode.wordpress.com/2016/07/18/c-is-not-magically-fast-part-2/


 Where is the part one ?


https://atilanevesoncode.wordpress.com/2015/08/24/c-is-not-magically-fast/
Jul 19 2016
prev sibling next sibling parent reply Atila Neves <atila.neves gmail.com> writes:
On Tuesday, 19 July 2016 at 02:54:37 UTC, Saurabh Das wrote:

 Posted on Atila's blog yesterday:

 https://atilanevesoncode.wordpress.com/2016/07/18/c-is-not-magically-fast-part-2/


So, about D vs C++ there... last night for reasons I forget I 
tried replacing std::string with const char* in the C++ version, 
and then it got faster than D. I don't know why.

At first I thought std::string was being copied instead of being 
moved, but some static_asserts made me doubt that. Either way, 
there's no good reason I can think of for C++ to magically speed 
up for const char*. Hmm :(

Atila
Jul 19 2016
next sibling parent reply Jakob Bornecrantz <wallbraker gmail.com> writes:
On Tuesday, 19 July 2016 at 10:07:11 UTC, Atila Neves wrote:

 On Tuesday, 19 July 2016 at 02:54:37 UTC, Saurabh Das wrote:

 Posted on Atila's blog yesterday:

 https://atilanevesoncode.wordpress.com/2016/07/18/c-is-not-magically-fast-part-2/


 So, about D vs C++ there... last night for reasons I forget I 
 tried replacing std::string with const char* in the C++ 
 version, and then it got faster than D. I don't know why.

 At first I thought std::string was being copied instead of 
 being moved, but some static_asserts made me doubt that. Either 
 way, there's no good reason I can think of for C++ to magically 
 speed up for const char*. Hmm :(

 Atila


What is the sizeof(Foo) for all of the cases?

What does "charPtr < charPtr" do in C++ compared to std::string?

Cheers, Jakob.
Jul 19 2016
parent Atila Neves <atila.neves gmail.com> writes:
On Tuesday, 19 July 2016 at 10:39:26 UTC, Jakob Bornecrantz wrote:

 On Tuesday, 19 July 2016 at 10:07:11 UTC, Atila Neves wrote:

 On Tuesday, 19 July 2016 at 02:54:37 UTC, Saurabh Das wrote:

 Posted on Atila's blog yesterday:

 https://atilanevesoncode.wordpress.com/2016/07/18/c-is-not-magically-fast-part-2/


 So, about D vs C++ there... last night for reasons I forget I 
 tried replacing std::string with const char* in the C++ 
 version, and then it got faster than D. I don't know why.

 At first I thought std::string was being copied instead of 
 being moved, but some static_asserts made me doubt that. 
 Either way, there's no good reason I can think of for C++ to 
 magically speed up for const char*. Hmm :(

 Atila


 What is the sizeof(Foo) for all of the cases?


C and C++ const char*: 16
C++ std::string: 64
D: 24


 What does "charPtr < charPtr" do in C++ compared to std::string?


I used strcmp for const char* in C++.

Atila
Jul 19 2016
prev sibling next sibling parent bigsandwich <bigsandwich gmail.com> writes:
On Tuesday, 19 July 2016 at 10:07:11 UTC, Atila Neves wrote:

 On Tuesday, 19 July 2016 at 02:54:37 UTC, Saurabh Das wrote:

 Posted on Atila's blog yesterday:

 https://atilanevesoncode.wordpress.com/2016/07/18/c-is-not-magically-fast-part-2/


 So, about D vs C++ there... last night for reasons I forget I 
 tried replacing std::string with const char* in the C++ 
 version, and then it got faster than D. I don't know why.

 At first I thought std::string was being copied instead of 
 being moved, but some static_asserts made me doubt that. Either 
 way, there's no good reason I can think of for C++ to magically 
 speed up for const char*. Hmm :(

 Atila


C++ Swap may be specialized for POD.
Jul 19 2016
prev sibling next sibling parent reply =?UTF-8?Q?S=c3=b6nke_Ludwig?= <sludwig outerproduct.org> writes:
Am 19.07.2016 um 12:07 schrieb Atila Neves:

 On Tuesday, 19 July 2016 at 02:54:37 UTC, Saurabh Das wrote:

 Posted on Atila's blog yesterday:

 https://atilanevesoncode.wordpress.com/2016/07/18/c-is-not-magically-fast-part-2/


 So, about D vs C++ there... last night for reasons I forget I tried
 replacing std::string with const char* in the C++ version, and then it
 got faster than D. I don't know why.

 At first I thought std::string was being copied instead of being moved,
 but some static_asserts made me doubt that. Either way, there's no good
 reason I can think of for C++ to magically speed up for const char*. Hmm :(

 Atila


One thing that the D version does and the others don't is comparing UTF 
code points instead of bytes.
Jul 19 2016
next sibling parent reply Kagamin <spam here.lot> writes:
On Tuesday, 19 July 2016 at 14:39:54 UTC, Sönke Ludwig wrote:

 One thing that the D version does and the others don't is 
 comparing UTF code points instead of bytes.


Are you sure? Autodecoding is a phobos feature, but here druntime 
is used for string comparison, and it usually doesn't provide 
autodecoding.
Jul 19 2016
parent Jack Stouffer <jack jackstouffer.com> writes:
On Tuesday, 19 July 2016 at 15:05:30 UTC, Kagamin wrote:

 On Tuesday, 19 July 2016 at 14:39:54 UTC, Sönke Ludwig wrote:

 One thing that the D version does and the others don't is 
 comparing UTF code points instead of bytes.


 Are you sure? Autodecoding is a phobos feature, but here 
 druntime is used for string comparison, and it usually doesn't 
 provide autodecoding.


Yeah, auto-decoding isn't at play here.
Jul 19 2016
prev sibling parent Atila Neves <atila.neves gmail.com> writes:
On Tuesday, 19 July 2016 at 14:39:54 UTC, Sönke Ludwig wrote:

 Am 19.07.2016 um 12:07 schrieb Atila Neves:

 On Tuesday, 19 July 2016 at 02:54:37 UTC, Saurabh Das wrote:

 Posted on Atila's blog yesterday:

 https://atilanevesoncode.wordpress.com/2016/07/18/c-is-not-magically-fast-part-2/


 So, about D vs C++ there... last night for reasons I forget I 
 tried
 replacing std::string with const char* in the C++ version, and 
 then it
 got faster than D. I don't know why.

 At first I thought std::string was being copied instead of 
 being moved,
 but some static_asserts made me doubt that. Either way, 
 there's no good
 reason I can think of for C++ to magically speed up for const 
 char*. Hmm :(

 Atila


 One thing that the D version does and the others don't is 
 comparing UTF code points instead of bytes.


I considered that too so I cast them to ubyte[]. No difference.
Jul 19 2016
prev sibling next sibling parent reply Johan Engelen <j j.nl> writes:
On Tuesday, 19 July 2016 at 10:07:11 UTC, Atila Neves wrote:

 On Tuesday, 19 July 2016 at 02:54:37 UTC, Saurabh Das wrote:

 Posted on Atila's blog yesterday:

 https://atilanevesoncode.wordpress.com/2016/07/18/c-is-not-magically-fast-part-2/


 So, about D vs C++ there... last night for reasons I forget I 
 tried replacing std::string with const char* in the C++ 
 version, and then it got faster than D. I don't know why.


Very interested to hear why one is faster than the other.


 At first I thought std::string was being copied instead of 
 being moved, but some static_asserts made me doubt that. Either 
 way, there's no good reason I can think of for C++ to magically 
 speed up for const char*. Hmm :(


The strings seem a little short, e.g. "foo1234foo" if I 
understand correctly.
Could there be a performance hit in C++ due to small-string 
optimization ? (Don't know if it is done at all, nor what the 
threshold is)
Jul 19 2016
parent reply Atila Neves <atila.neves gmail.com> writes:
On Tuesday, 19 July 2016 at 15:28:45 UTC, Johan Engelen wrote:

 On Tuesday, 19 July 2016 at 10:07:11 UTC, Atila Neves wrote:

 [...]


 Very interested to hear why one is faster than the other.


 [...]


 The strings seem a little short, e.g. "foo1234foo" if I 
 understand correctly.
 Could there be a performance hit in C++ due to small-string 
 optimization ? (Don't know if it is done at all, nor what the 
 threshold is)



Small string optimization should _help_ std::string, no?

Atila
Jul 19 2016
next sibling parent reply Lodovico Giaretta <lodovico giaretart.net> writes:
On Tuesday, 19 July 2016 at 15:48:26 UTC, Atila Neves wrote:

 Small string optimization should _help_ std::string, no?

 Atila


Small string optimization will make the struct bigger, thus 
making swapping slower. If the struct is no bigger than 2 
pointers, swapping it is ultra fast.
Jul 19 2016
parent reply Atila Neves <atila.neves gmail.com> writes:
On Tuesday, 19 July 2016 at 16:01:01 UTC, Lodovico Giaretta wrote:

 On Tuesday, 19 July 2016 at 15:48:26 UTC, Atila Neves wrote:

 Small string optimization should _help_ std::string, no?

 Atila


 Small string optimization will make the struct bigger, thus 
 making swapping slower. If the struct is no bigger than 2 
 pointers, swapping it is ultra fast.


Interesting. Read up on it and tried changing the strings to be 
~50 chars long. C++/std::string gets better, but C++/const char* 
still beats D by a small margin:

C: 1.852s
C++/std::string: 1.489s
C++/const char*: 1.034s
D: 1.188s

Could be the cost of swapping the "fat" in "fat pointer", in 
which case: worth it.

Atila
Jul 19 2016
parent Jakob Bornecrantz <wallbraker gmail.com> writes:
On Tuesday, 19 July 2016 at 16:13:21 UTC, Atila Neves wrote:

 On Tuesday, 19 July 2016 at 16:01:01 UTC, Lodovico Giaretta 
 wrote:

 On Tuesday, 19 July 2016 at 15:48:26 UTC, Atila Neves wrote:

 Small string optimization should _help_ std::string, no?

 Atila


 Small string optimization will make the struct bigger, thus 
 making swapping slower. If the struct is no bigger than 2 
 pointers, swapping it is ultra fast.


 Interesting. Read up on it and tried changing the strings to be 
 ~50 chars long. C++/std::string gets better, but C++/const 
 char* still beats D by a small margin:

 C: 1.852s
 C++/std::string: 1.489s
 C++/const char*: 1.034s
 D: 1.188s

 Could be the cost of swapping the "fat" in "fat pointer", in 
 which case: worth it.


You are swapping different amount of data.
For C++/const char* vs D, you are swapping 75% more data.
For D vs C++/std::string, you are swsapping 129% more data.

I would expect you getting the same numbers if you did 
"const(char)*" version in D?

And if you used a inline sort[1] in the C version it would 
probably be just as fast as the C++/const char* version.

Also it was a bit hard to find out what N you where using.

Cheers, Jakob.


[1] http://www.corpit.ru/mjt/qsort.html
Jul 19 2016
prev sibling parent Steven Schveighoffer <schveiguy yahoo.com> writes:
On 7/19/16 11:48 AM, Atila Neves wrote:

 On Tuesday, 19 July 2016 at 15:28:45 UTC, Johan Engelen wrote:

 On Tuesday, 19 July 2016 at 10:07:11 UTC, Atila Neves wrote:

 [...]


 Very interested to hear why one is faster than the other.


 [...]


 The strings seem a little short, e.g. "foo1234foo" if I understand
 correctly.
 Could there be a performance hit in C++ due to small-string
 optimization ? (Don't know if it is done at all, nor what the
 threshold is)



 Small string optimization should _help_ std::string, no?


You can use strncmp, or strcmp and ensure a null terminator is always 
there in your C++ version.

That will use std::string semantics for swapping, but strcmp for comparison.

-Steve
Jul 19 2016
prev sibling parent reply deadalnix <deadalnix gmail.com> writes:
On Tuesday, 19 July 2016 at 10:07:11 UTC, Atila Neves wrote:

 On Tuesday, 19 July 2016 at 02:54:37 UTC, Saurabh Das wrote:

 Posted on Atila's blog yesterday:

 https://atilanevesoncode.wordpress.com/2016/07/18/c-is-not-magically-fast-part-2/


 So, about D vs C++ there... last night for reasons I forget I 
 tried replacing std::string with const char* in the C++ 
 version, and then it got faster than D. I don't know why.

 At first I thought std::string was being copied instead of 
 being moved, but some static_asserts made me doubt that. Either 
 way, there's no good reason I can think of for C++ to magically 
 speed up for const char*. Hmm :(

 Atila


What compiler are you using ? If it is LLVM based, could you post 
IR ?

Also:

if(i < other.i) return -1;
if(i > other.i) return 1;

Should be

(i > other.i) - (i < other.i)

Surprisingly, LLVM was unable to optimize one into the other in 
my tests.
Jul 19 2016
parent reply =?UTF-8?Q?Ali_=c3=87ehreli?= <acehreli yahoo.com> writes:
On 07/19/2016 10:41 AM, deadalnix wrote:

 On Tuesday, 19 July 2016 at 10:07:11 UTC, Atila Neves wrote:

 On Tuesday, 19 July 2016 at 02:54:37 UTC, Saurabh Das wrote:

 Posted on Atila's blog yesterday:

 https://atilanevesoncode.wordpress.com/2016/07/18/c-is-not-magically-fast-part-2/


 So, about D vs C++ there... last night for reasons I forget I tried
 replacing std::string with const char* in the C++ version, and then it
 got faster than D. I don't know why.

 At first I thought std::string was being copied instead of being
 moved, but some static_asserts made me doubt that. Either way, there's
 no good reason I can think of for C++ to magically speed up for const
 char*. Hmm :(

 Atila


 What compiler are you using ? If it is LLVM based, could you post IR ?

 Also:

 if(i < other.i) return -1;
 if(i > other.i) return 1;

 Should be

 (i > other.i) - (i < other.i)

 Surprisingly, LLVM was unable to optimize one into the other in my tests.


Additionally, the string may be traversed twice in opCmp. The following 
change makes D example faster:

         import std.algorithm : cmp;
         return cmp(s, other.s);
//        return s < other.s
//            ? -1
//            : (s > other.s ? 1 : 0);

Ali
Jul 19 2016
parent =?UTF-8?Q?Ali_=c3=87ehreli?= <acehreli yahoo.com> writes:
On 07/19/2016 12:00 PM, Ali Çehreli wrote:

 On 07/19/2016 10:41 AM, deadalnix wrote:



 if(i < other.i) return -1;
 if(i > other.i) return 1;

 Should be

 (i > other.i) - (i < other.i)

 Surprisingly, LLVM was unable to optimize one into the other in my 




tests.

If you mean the following, it's slower with ldc:

         const r = (i > other.i) - (i < other.i) ;
         if (r) return r;


 Additionally, the string may be traversed twice in opCmp. The following
 change makes D example faster:

          import std.algorithm : cmp;
          return cmp(s, other.s);
 //        return s < other.s
 //            ? -1
 //            : (s > other.s ? 1 : 0);


Faster with dmd but has no difference with ldc.

Ali
Jul 19 2016
prev sibling parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 07/18/2016 10:54 PM, Saurabh Das wrote:

 Posted on Atila's blog yesterday:

 https://atilanevesoncode.wordpress.com/2016/07/18/c-is-not-magically-fast-part-2/


https://www.reddit.com/r/programming/comments/4tlqyc/c_is_not_magically_fast_twopart_article/


Andrei
Jul 19 2016