Re: Atila Neves: "C IS NOT MAGICALLY FAST, PART 2"
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
Re: Atila Neves: "C IS NOT MAGICALLY FAST, PART 2"
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
Re: Atila Neves: "C IS NOT MAGICALLY FAST, PART 2"
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
Re: Atila Neves: "C IS NOT MAGICALLY FAST, PART 2"
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.
Re: Atila Neves: "C IS NOT MAGICALLY FAST, PART 2"
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
Re: Atila Neves: "C IS NOT MAGICALLY FAST, PART 2"
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
Re: Atila Neves: "C IS NOT MAGICALLY FAST, PART 2"
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.
Re: Atila Neves: "C IS NOT MAGICALLY FAST, PART 2"
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
Re: Atila Neves: "C IS NOT MAGICALLY FAST, PART 2"
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.
Re: Atila Neves: "C IS NOT MAGICALLY FAST, PART 2"
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
Re: Atila Neves: "C IS NOT MAGICALLY FAST, PART 2"
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
Re: Atila Neves: "C IS NOT MAGICALLY FAST, PART 2"
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)
Re: Atila Neves: "C IS NOT MAGICALLY FAST, PART 2"
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.
Re: Atila Neves: "C IS NOT MAGICALLY FAST, PART 2"
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.
Re: Atila Neves: "C IS NOT MAGICALLY FAST, PART 2"
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.
Re: Atila Neves: "C IS NOT MAGICALLY FAST, PART 2"
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.
Re: Atila Neves: "C IS NOT MAGICALLY FAST, PART 2"
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/
Re: Atila Neves: "C IS NOT MAGICALLY FAST, PART 2"
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.
Re: Atila Neves: "C IS NOT MAGICALLY FAST, PART 2"
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
Re: Atila Neves: "C IS NOT MAGICALLY FAST, PART 2"
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/
Re: Atila Neves: "C IS NOT MAGICALLY FAST, PART 2"
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 ?
