Am 30.06.2013 22:53, schrieb SomeDude:
> On Sunday, 30 June 2013 at 20:47:17 UTC, Adam D. Ruppe wrote:
>> On Sunday, 30 June 2013 at 20:37:16 UTC, SomeDude wrote:
>>> It seems indeed that the automatic memory management is a major performance killer
>>
>> Eh, I'd say it is D's gc implementation specifically that is the biggest worry rather than the concept. I think the .net gc is seriously like 10x faster than D's implementation.
> 
> Yes, yes, you're right. However, not allocating at least in Phobos is one of the surest way to get near optimal performance, not to mention it's always more satisfying when you know that your program doesn't monopolize Mb of RAM to do even the simplest task.

Wow, I don't care if it does, especially if it is only a simple task. Memory is there to be used. If I want to avoid memory useage, I wouldn't be using D.

On Monday, July 01, 2013 00:35:45 David wrote:
> Am 30.06.2013 22:53, schrieb SomeDude:
> > On Sunday, 30 June 2013 at 20:47:17 UTC, Adam D. Ruppe wrote:
> >> On Sunday, 30 June 2013 at 20:37:16 UTC, SomeDude wrote:
> >>> It seems indeed that the automatic memory management is a major performance killer
> >> 
> >> Eh, I'd say it is D's gc implementation specifically that is the biggest worry rather than the concept. I think the .net gc is seriously like 10x faster than D's implementation.
> > 
> > Yes, yes, you're right. However, not allocating at least in Phobos is one of the surest way to get near optimal performance, not to mention it's always more satisfying when you know that your program doesn't monopolize Mb of RAM to do even the simplest task.
> 
> Wow, I don't care if it does, especially if it is only a simple task. Memory is there to be used. If I want to avoid memory useage, I wouldn't be using D.

For simple stuff, I really don't care much about how much memory a program uses as long as it's not an outrageous amount. So personally, I don't find it more satisfying to know that my program doesn't monopolize MB of RAM. And honestly, I have enough RAM on my system, that you _can't_ monopolize RAM if you're not talking in GB. However, memory usage matters a _lot_ for programs that need to be really performant (especially when they're larger programs), and having the GC kick in a lot due to how much memory you're using can be a real performance killer. So, being able to minimize the memory footprint of your program is critical, because there are cases where you _really_ care, but there are also plenty of cases where you really don't.

- Jonathan M Davis

On Sun, 30 Jun 2013 18:35:45 -0400, David <d@dav1d.de> wrote:

> Am 30.06.2013 22:53, schrieb SomeDude:
>> On Sunday, 30 June 2013 at 20:47:17 UTC, Adam D. Ruppe wrote:
>>> On Sunday, 30 June 2013 at 20:37:16 UTC, SomeDude wrote:
>>>> It seems indeed that the automatic memory management is a major
>>>> performance killer
>>>
>>> Eh, I'd say it is D's gc implementation specifically that is the
>>> biggest worry rather than the concept. I think the .net gc is
>>> seriously like 10x faster than D's implementation.
>>
>> Yes, yes, you're right. However, not allocating at least in Phobos is
>> one of the surest way to get near optimal performance, not to mention
>> it's always more satisfying when you know that your program doesn't
>> monopolize Mb of RAM to do even the simplest task.
>
> Wow, I don't care if it does, especially if it is only a simple task.
> Memory is there to be used. If I want to avoid memory useage, I wouldn't
> be using D.

The difference between using 300 MB of ram and 1GB of ram on an online virtual private server can be about $30/month.

I recently figured out that vibe.d's idea of "just in time" compile and module load would not work on my VPS because dmd takes 500MB to compile simple vibe.d hello world.

I think memory usage is still important.  Many people don't consider that their computer is running hundreds of programs at a time.  If each one of those "didn't care" about memory usage, the one that you are currently interested in would not have any breathing room.

-Steve

Gabi:

> The first question that came up was how it stands up with C++ performance wise ?

In my experience if you write D code very similar to equivalent C or C++ code (this means using abstractions with enough care), and you use the ldc2 compiler with the right compilation switches (some of them are hidden), and you don't make mistakes in D coding (like leaving virtual functions, copying fixed static arrays when you want just a reference, and so on), then you get sufficiently similar performance to C or C++ code compiled with Clang.

Bye,
bearophile

On Sunday, 30 June 2013 at 21:06:37 UTC, Gabi wrote:
> On Sunday, 30 June 2013 at 20:26:38 UTC, Joakim wrote:
>> On Sunday, 30 June 2013 at 20:05:16 UTC, Joakim wrote:
>>> On Sunday, 30 June 2013 at 19:48:45 UTC, Gabi wrote:
>>>> Are there any good comparisons out there ?
>>> Not that I know of, but then I'm not looking to justify the use of D anymore. ;)
>> When I just googled for "d programming language benchmark," this post was two clicks from the first page of search results:
>>
>> http://attractivechaos.wordpress.com/2011/06/22/my-programming-language-benchmark-analyses/
>
> Thanks for that. Unfortunately it doesn't contain dmd benchmarks which I most interested in because our main platform is windows.

If you're concerned about performance, I'd recommend against using DMD for your release builds. GDC and LDC will give much better performance, and GDC works perfectly fine on Windows. LDC has some problems with exception handling AFAIK on Windows.

On Sunday, 30 June 2013 at 20:49:28 UTC, Peter Alexander wrote:
> sometimes faster

Would love an example that demonstrates it!

On Monday, July 01, 2013 04:37:43 Mehrdad wrote:
> On Sunday, 30 June 2013 at 20:49:28 UTC, Peter Alexander wrote:
> > sometimes faster
> 
> Would love an example that demonstrates it!

Anything involving taking a lot of substrings is likely to be faster in D thanks to slices (which is one of the main reasons that Tango's xml parser is so lightning fast). You could write the same code in C++, but it's harder, because slices aren't built-in, and you have no GC, probably forcing you to create your own string type that supports slices and does reference counting if you want a similar effect. However, you do have to be somewhat careful with string processing and Phobos functions, because you could end up doing more decoding than you might want, which would slow down the code (as Phobos strives to be Unicode correct by default, whereas C++'s STL doesn't). But anything which heavily uses slicing stands a good chance of creaming C++ code doing the same task. So, in general, well-written parsers written in D should beat well-written parsers written in C++.

- Jonathan M Davis

Am Sun, 30 Jun 2013 22:55:26 +0200
schrieb "Gabi" <galim120@bezeqint.net>:

> I wonder why is that.. Why would deleting 1 million objects in C++ (using std::shared_ptr for example) have to be slower than the garbage collection freeing a big chunk of million objects all at once.

I have no numbers, but I think especially when you have complex graph structures linked with pointers, the GC needs a while to follow all the links and mark the referenced objects as still in use. And this will be done every now and then when you allocate N new objects.

> I mean, it would probably block the main thread but the avg rate of deleting objects shouldn't differ from manually doing so right ? So the main issue would be unpredictable pauses (what's a typical delay to expect from cleaning 1000000 objects?) of the main thread and not avg performance I think..

The current implementation is a stop-the-world GC. It freezes all threads known to the runtime. (Excluding threads created with the native API and not registered with the runtime.)

> Any other tips to get high performance besides the GC issue?

From the top of my head:

o Mark classes or single methods final when you can, as
  bearophile pointed out. (shaves off a few % in object heavy
  code)
o See if you can use structs instead of classes, they don't
  have virtual methods and are simpler to allocate/return on
  the stack.
o When working with strings, be aware that foreach iterates
  them by byte, whereas Phobos - in an attempt to do the right
  thing - iterates them by dchar (UTF-32 code point), which
  means a UTF-8 decoding process.
o Some of Phobos is very fast, some is very slow. If you care
  much about performance evaluate different approaches before
  jumping to conclusions.

As an example of the two last points combined, take finding
a '\0' in a string (compiled with DMD):
algorithm.countUntil:     355213 per second
std.string.indexOf  :   33121530 per second (~100x faster)


Am Sun, 30 Jun 2013 19:53:05 -0700
schrieb Jonathan M Davis <jmdavisProg@gmx.com>:

> On Monday, July 01, 2013 04:37:43 Mehrdad wrote:
> > On Sunday, 30 June 2013 at 20:49:28 UTC, Peter Alexander wrote:
> > > sometimes faster
> > 
> > Would love an example that demonstrates it!
> 
> Anything involving taking a lot of substrings is likely to be faster in D thanks to slices (which is one of the main reasons that Tango's xml parser is so lightning fast).

I think he referred to the DMD backend being faster than GDC/LDC sometimes, no ?

-- 
Marco

On Monday, July 01, 2013 06:27:15 Marco Leise wrote:
> Am Sun, 30 Jun 2013 22:55:26 +0200
> 
> schrieb "Gabi" <galim120@bezeqint.net>:
> > I wonder why is that.. Why would deleting 1 million objects in C++ (using std::shared_ptr for example) have to be slower than the garbage collection freeing a big chunk of million objects all at once.
> 
> I have no numbers, but I think especially when you have complex graph structures linked with pointers, the GC needs a while to follow all the links and mark the referenced objects as still in use. And this will be done every now and then when you allocate N new objects.

The other thing to consider is that when the GC runs, it has to figure out whether anything needs to be collected. And regardless of whether anything actually needs to be collected, it has to go through all of the various references to mark them and then to sweep them. With deterministic destruction, you don't have to do that. If you have a fairly small number of heap allocations in your program, it's generally not a big deal. But if you're constantly allocating and deallocating small objects, then the GC is going to be run a lot more frequently, and it'll have a lot more objects to have to examine. So, having lots of small objects which are frequently being created and destroyed is pretty much guaranteed to tank your performance if they're being allocated by the GC. You really want reference counting for those sorts of situations.

> I think he referred to the DMD backend being faster than GDC/LDC sometimes, no ?

Maybe someone did, but if that's ever true, it's rare. It's pretty much always the case that the dmd backend is inferior with regards to optimizations. It just isn't getting worked on like the other backends are. Where it shines is compilation speed.

- Jonathan M Davis

On Monday, 1 July 2013 at 04:27:46 UTC, Marco Leise wrote:
> Am Sun, 30 Jun 2013 19:53:05 -0700
> schrieb Jonathan M Davis <jmdavisProg@gmx.com>:
>
>> On Monday, July 01, 2013 04:37:43 Mehrdad wrote:
>> > On Sunday, 30 June 2013 at 20:49:28 UTC, Peter Alexander wrote:
>> > > sometimes faster
>> > 
>> > Would love an example that demonstrates it!
>> 
>> Anything involving taking a lot of substrings is likely to be faster in D thanks to slices (which is one of the main reasons that Tango's xml parser is so lightning fast).
>
> I think he referred to the DMD backend being faster than
> GDC/LDC sometimes, no ?
No, he was talking about D being sometimes faster than C++, from this quote, "The end result is that D programs are typically as fast as C++ programs, sometimes faster, sometimes slower."  So Jonathan got the comparison right.