On 1 July 2013 12:02, dennis luehring <dl.soluz@gmx.net> wrote:
> Am 01.07.2013 10:14, schrieb Iain Buclaw:
>>
>> On Jul 1, 2013 7:16 AM, "dennis luehring" <dl.soluz@gmx.net> wrote:
>>>
>>>
>>> Am 01.07.2013 03:07, schrieb Kapps:
>>>
>>>> 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.
>>>
>>>
>>>
>>> GDC got the same Exception problems like LDC - no support for SEH but Exceptions are working - only the Windows-internal-Exception ->
>>
>> D-Exception transition is not working properbly
>>>
>>>
>>> but even using Visual Studio you need to add special flags or using
>>
>> __try, __catch to get these - so normaly not a problem
>>>
>>>
>>
>> Right, gcc (thus, gdc) uses sjlj (setjmp/longjmp) exceptions on Windows.
>> AFAIK, structured exception handling support in gcc is being developed to
>> overcome the weaknesses of both dw2 and sjlj.
>
>
> "...is being developed" thats means gcc got Windows-SEH support?
>

No, it hasn't.  If there are any patches, I can't see them after a cursory look.

There a wiki for discussion at least: http://gcc.gnu.org/wiki/WindowsGCCImprovements


--
Iain Buclaw

*(p < e ? p++ : p) = (c & 0x0f) + '0';

On 1 July 2013 12:38, Iain Buclaw <ibuclaw@ubuntu.com> wrote:
> On 1 July 2013 12:02, dennis luehring <dl.soluz@gmx.net> wrote:
>> Am 01.07.2013 10:14, schrieb Iain Buclaw:
>>>
>>> On Jul 1, 2013 7:16 AM, "dennis luehring" <dl.soluz@gmx.net> wrote:
>>>>
>>>>
>>>> Am 01.07.2013 03:07, schrieb Kapps:
>>>>
>>>>> 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.
>>>>
>>>>
>>>>
>>>> GDC got the same Exception problems like LDC - no support for SEH but Exceptions are working - only the Windows-internal-Exception ->
>>>
>>> D-Exception transition is not working properbly
>>>>
>>>>
>>>> but even using Visual Studio you need to add special flags or using
>>>
>>> __try, __catch to get these - so normaly not a problem
>>>>
>>>>
>>>
>>> Right, gcc (thus, gdc) uses sjlj (setjmp/longjmp) exceptions on Windows.
>>> AFAIK, structured exception handling support in gcc is being developed to
>>> overcome the weaknesses of both dw2 and sjlj.
>>
>>
>> "...is being developed" thats means gcc got Windows-SEH support?
>>
>
> No, it hasn't.  If there are any patches, I can't see them after a cursory look.
>
> There a wiki for discussion at least: http://gcc.gnu.org/wiki/WindowsGCCImprovements
>
>

Which after a few clicks brings you to this page: http://gcc.gnu.org/wiki/WindowsGCCImprovementsGSoC2008#General_Information

Though, that was support as of 2008... there might have been a few changes since then to improve it. =)

--
Iain Buclaw

*(p < e ? p++ : p) = (c & 0x0f) + '0';

On Monday, 1 July 2013 at 09:14:07 UTC, Jacob Carlborg wrote:
> On 2013-07-01 01:14, Steven Schveighoffer wrote:
>
>> 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.
>
> I quite often run out of memory at work on my machine with 6GB of RAM when coding Ruby on Rails. I don't know if there's something I do with the code but sometimes something happens in the Ruby code making the Rails server take over 1GB of RAM from 300MB, the same thing happens with the web browser at the same time. Suddenly it decided to eat 2GB of extra RAM.

My 4 gig machine needs swap space... just to surf on internet.

I think one of the biggest culprits are not the programs, but today's *shiny* and *exciting* websites...

> My 4 gig machine needs swap space... just to surf on internet.
> 
> I think one of the biggest culprits are not the programs, but today's *shiny* and *exciting* websites...

Wow!
Then you must be running Windows...

I have currently 1.5Gb used, with ~30 tabs open, Kdevelop, a few terminals and Thunderbird (and thunderbird takes the most ram!)

On Monday, 1 July 2013 at 14:11:50 UTC, David wrote:
>> My 4 gig machine needs swap space... just to surf on internet.
>> 
>> I think one of the biggest culprits are not the programs, but today's
>> *shiny* and *exciting* websites...
>
> Wow!
> Then you must be running Windows...
>
> I have currently 1.5Gb used, with ~30 tabs open, Kdevelop, a few
> terminals and Thunderbird (and thunderbird takes the most ram!)

Firefox with ~70 tabs including an hour long youtube video, matlab and ipython all running at once: Used memory + swap still under 4GB.

It's worth bearing in mind that just because you've got swap space being used, doesn't mean you're actually short on memory.

On Monday, 1 July 2013 at 06:28:57 UTC, monarch_dodra wrote:
> On Monday, 1 July 2013 at 02:53:24 UTC, Jonathan M Davis wrote:
>> 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.
>>
>> - Jonathan M Davis
>
> Well... in "C++", a slice is called an iterator pair. If you just:
> typedef std::pair<std::string::const_iterator, const_itrator> string_slice;
>
> Then there is no reason you can't do it... The only "problem" is that it is not a standard semantic in C++, so nobody ever thinks about doing this, and much less actually ever does it. There is a *little* bit of barrier to entry too.
>
> I've done this once about two years ago (before I knew about D) because I needed a "subview" of a vector. My typedef's name was "shallow_vector". It was a fun experience given I didn't know about the range concept back then :)
>
> In any case, if you *do* want to go there, it doesn't really require you creating that much new stuff, especially not your own string/vector type.

Boost recently added string_ref, "a non-owning reference to a string": http://www.boost.org/doc/libs/1_53_0/libs/utility/doc/html/string_ref.html

Gets you something similar to slices but is inherently more dangerous to use than GC backed slices.

On Monday, 1 July 2013 at 02:53:24 UTC, Jonathan M Davis wrote:
> 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


That doesn't mean D is "faster". It just means it's less painful to get the same performance.


Regarding what someone else mentioned, I wasn't talking about the backend either.

As an example of what I was looking for, consider that people claim a GC can be faster than manual memory management. If that's the scenario we're talking about, then what I was asking for is to see piece of _code_ (not a hand-wavy explanation!) that demonstrates GC-based code being faster than non-GC-based code.

If it's a different feature (I don't know what), then I'd like to know what it is strictly in terms of performance.


In other words, I know C++ is _painful_ to write fast code in, but that doesn't make it slower; it just makes it more painful. On the other hand, if you could demonstrate that e.g. the GC is faster than manual memory management, then I'd totally agree D is faster than C++.

On Wednesday, 3 July 2013 at 03:13:59 UTC, Mehrdad wrote:
> In other words, I know C++ is _painful_ to write fast code in, but that doesn't make it slower; it just makes it more painful. On the other hand, if you could demonstrate that e.g. the GC is faster than manual memory management, then I'd totally agree D is faster than C++.

Slice + immutability + GC is awesomeness. You need the 3 to get the full efficiency, or you'll ends up doing quite a lot of book keeping.

On 07/03/2013 05:13 AM, Mehrdad wrote:
> That doesn't mean D is "faster". It just means it's less painful to get the same performance.

That would be ... kind of the point.  If we didn't care about the pain, we'd all be programming using assembly.  Or butterflies: https://xkcd.com/378/

But faster performance with less pain and more safety?  Yes please. :-)

On Wednesday, 3 July 2013 at 07:12:54 UTC, Joseph Rushton Wakeling wrote:
> On 07/03/2013 05:13 AM, Mehrdad wrote:
>> That doesn't mean D is "faster". It just means it's less painful to get the same
>> performance.
>
> That would be ... kind of the point.  If we didn't care about the pain, we'd all
> be programming using assembly.  Or butterflies: https://xkcd.com/378/
>
> But faster performance with less pain and more safety?  Yes please. :-)


Not really. For example, no matter how much C++ code you feel like writing, it'll be _impossible_ for you to replicate the behavior of a GC in C++.

So it's not a matter of how much pain you're willing to go through -- it's literally a matter of language capabilities.