December 07, 2017 Re: Post about comparing C, C++ and D performance with a real world project | ||||
---|---|---|---|---|
| ||||
Posted in reply to Daniel Kozak | On 12/7/17 1:26 PM, Daniel Kozak wrote:
> This is not about write the best D code. It is about similar code to perform same. However when I looked at the D code it is not good port of C/C++. He made many mistakes which make it slower than C/C++ counterpart.
> One example is read_one_line function:
> C++: https://github.com/jpakkane/pkg-config/blob/cpp/parse.cpp#L60
> D: https://github.com/jpakkane/pkg-config/blob/d/parse.d#L57
Wow, interesting that D uses less memory with that continue new char[1] in there!
Kind of funny that he didn't just use FILE * directly, it's totally available in D :)
-Steve
|
December 07, 2017 Re: Post about comparing C, C++ and D performance with a real world project | ||||
---|---|---|---|---|
| ||||
Posted in reply to Steven Schveighoffer Attachments:
| Yes using FILE* directly could be the way. But using file.rawRead is still possible. But it is better to use static array with length one. Other problem is with string. It would make sense make it out instead of ref and change it to empty string and use RefAppender.
Dne 7. 12. 2017 9:00 odp. napsal uživatel "Steven Schveighoffer via Digitalmars-d" <digitalmars-d@puremagic.com>:
> On 12/7/17 1:26 PM, Daniel Kozak wrote:
>
>> This is not about write the best D code. It is about similar code to
>> perform same. However when I looked at the D code it is not good port of
>> C/C++. He made many mistakes which make it slower than C/C++ counterpart.
>> One example is read_one_line function:
>> C++: https://github.com/jpakkane/pkg-config/blob/cpp/parse.cpp#L60
>> D: https://github.com/jpakkane/pkg-config/blob/d/parse.d#L57
>>
>
> Wow, interesting that D uses less memory with that continue new char[1] in there!
>
> Kind of funny that he didn't just use FILE * directly, it's totally available in D :)
>
> -Steve
>
|
December 07, 2017 Re: Post about comparing C, C++ and D performance with a real world project | ||||
---|---|---|---|---|
| ||||
Posted in reply to Steven Schveighoffer | On 7 December 2017 at 20:56, Steven Schveighoffer via Digitalmars-d <digitalmars-d@puremagic.com> wrote:
> On 12/7/17 1:26 PM, Daniel Kozak wrote:
>>
>> This is not about write the best D code. It is about similar code to
>> perform same. However when I looked at the D code it is not good port of
>> C/C++. He made many mistakes which make it slower than C/C++ counterpart.
>> One example is read_one_line function:
>> C++: https://github.com/jpakkane/pkg-config/blob/cpp/parse.cpp#L60
>> D: https://github.com/jpakkane/pkg-config/blob/d/parse.d#L57
>
>
> Wow, interesting that D uses less memory with that continue new char[1] in there!
>
I would have thought that it just reuses the same pointer to the GC on each loop.
|
December 07, 2017 Re: Post about comparing C, C++ and D performance with a real world project | ||||
---|---|---|---|---|
| ||||
Attachments:
| Yes, it reuse the same pointer. But it still a little bit slower than accessing stack memory
Dne 7. 12. 2017 11:04 odp. napsal uživatel "Iain Buclaw via Digitalmars-d" < digitalmars-d@puremagic.com>:
On 7 December 2017 at 20:56, Steven Schveighoffer via Digitalmars-d <digitalmars-d@puremagic.com> wrote:
> On 12/7/17 1:26 PM, Daniel Kozak wrote:
>>
>> This is not about write the best D code. It is about similar code to
>> perform same. However when I looked at the D code it is not good port of
>> C/C++. He made many mistakes which make it slower than C/C++ counterpart.
>> One example is read_one_line function:
>> C++: https://github.com/jpakkane/pkg-config/blob/cpp/parse.cpp#L60
>> D: https://github.com/jpakkane/pkg-config/blob/d/parse.d#L57
>
>
> Wow, interesting that D uses less memory with that continue new char[1] in there!
>
I would have thought that it just reuses the same pointer to the GC on each loop.
|
December 07, 2017 Re: Post about comparing C, C++ and D performance with a real world project | ||||
---|---|---|---|---|
| ||||
Attachments:
| The other slowdown is caused by concatenation. Because std::string += is more simillar to std.array.(Ref)Appender Dne 7. 12. 2017 11:33 odp. napsal uživatel "Daniel Kozak" <kozzi11@gmail.com >: > Yes, it reuse the same pointer. But it still a little bit slower than accessing stack memory > > Dne 7. 12. 2017 11:04 odp. napsal uživatel "Iain Buclaw via Digitalmars-d" <digitalmars-d@puremagic.com>: > > On 7 December 2017 at 20:56, Steven Schveighoffer via Digitalmars-d <digitalmars-d@puremagic.com> wrote: > > On 12/7/17 1:26 PM, Daniel Kozak wrote: > >> > >> This is not about write the best D code. It is about similar code to perform same. However when I looked at the D code it is not good port of C/C++. He made many mistakes which make it slower than C/C++ > counterpart. > >> One example is read_one_line function: > >> C++: https://github.com/jpakkane/pkg-config/blob/cpp/parse.cpp#L60 > >> D: https://github.com/jpakkane/pkg-config/blob/d/parse.d#L57 > > > > > > Wow, interesting that D uses less memory with that continue new char[1] > in > > there! > > > > I would have thought that it just reuses the same pointer to the GC on each loop. > > > |
December 08, 2017 Re: Post about comparing C, C++ and D performance with a real world project | ||||
---|---|---|---|---|
| ||||
On 7 December 2017 at 23:39, Daniel Kozak <kozzi11@gmail.com> wrote:
> The other slowdown is caused by concatenation. Because std::string += is more simillar to std.array.(Ref)Appender
>
Correct. The semantics of ~= mean that the memory is copied around to a new allocation every time (unless the array is marked assumeSafeAppend).
|
December 08, 2017 Re: Post about comparing C, C++ and D performance with a real world project | ||||
---|---|---|---|---|
| ||||
Posted in reply to Daniel Kozak | On Thursday, 7 December 2017 at 22:39:44 UTC, Daniel Kozak wrote:
> The other slowdown is caused by concatenation. Because std::string += is more simillar to std.array.(Ref)Appender
wait, i thought appenders performed better than concatenation. is that not true or did i just misunderstand your post?
|
December 07, 2017 Re: Post about comparing C, C++ and D performance with a real world project | ||||
---|---|---|---|---|
| ||||
Posted in reply to Iain Buclaw | On 12/07/2017 03:07 PM, Iain Buclaw wrote:
> On 7 December 2017 at 23:39, Daniel Kozak <kozzi11@gmail.com> wrote:
>> The other slowdown is caused by concatenation. Because std::string += is
>> more simillar to std.array.(Ref)Appender
>>
>
> Correct. The semantics of ~= mean that the memory is copied around to
> a new allocation every time (unless the array is marked
> assumeSafeAppend).
>
You must have meant ~, not ~= because luckily, it is assumeSafeAppend when there is just one slice. ~= is not that bad in that case:
import std.stdio;
void main() {
int[] a;
foreach (i; 0 .. 10) {
a ~= i;
writeln(a.ptr);
}
}
7F621818D020
7F621818D020
7F621818D020
7F621818C100
7F621818C100
7F621818C100
7F621818C100
7F621818B040
7F621818B040
7F621818B040
Ali
|
December 08, 2017 Re: Post about comparing C, C++ and D performance with a real world project | ||||
---|---|---|---|---|
| ||||
Posted in reply to Mengu | On 12/7/17 8:11 PM, Mengu wrote:
> On Thursday, 7 December 2017 at 22:39:44 UTC, Daniel Kozak wrote:
>> The other slowdown is caused by concatenation. Because std::string += is more simillar to std.array.(Ref)Appender
>
> wait, i thought appenders performed better than concatenation. is that not true or did i just misunderstand your post?
>
You misunderstood. Appender is faster than ~= to a straight array, because it doesn't have to do any opaque lookups in the GC to see if it needs to reallocate -- all the information is right there.
Daniel's point was that Appender is more akin to std::string (which doesn't have the benefit of having language-defined array operaions). If the blogger used Appender, he would have had better performance.
-Steve
|
December 08, 2017 Re: Post about comparing C, C++ and D performance with a real world project | ||||
---|---|---|---|---|
| ||||
Posted in reply to Iain Buclaw | On 12/7/17 6:07 PM, Iain Buclaw wrote:
> On 7 December 2017 at 23:39, Daniel Kozak <kozzi11@gmail.com> wrote:
>> The other slowdown is caused by concatenation. Because std::string += is
>> more simillar to std.array.(Ref)Appender
>>
>
> Correct. The semantics of ~= mean that the memory is copied around to
> a new allocation every time (unless the array is marked
> assumeSafeAppend).
>
Slightly incorrect. If an array is not marked with the append bit (or not even part of the GC), it is copied on the *first* append. However, it is copied to a new GC block that DOES have the bit set. Further appends are amortized.
-Steve
|
Copyright © 1999-2021 by the D Language Foundation