C++17

[rsw0x via Digitalmars-d]

On Wednesday, 27 January 2016 at 05:32:04 UTC, Chris Wright wrote:
> On Tue, 26 Jan 2016 21:15:07 +0000, rsw0x wrote:
>
>> On Tuesday, 26 January 2016 at 20:40:50 UTC, Chris Wright 
>> wrote:
>>> On Tue, 26 Jan 2016 19:04:33 +0000, rsw0x wrote:
>>>> GC in D is a pipedream, if it wasn't, why is it still so 
>>>> horrible? Everyone keeps dancing around the fact that if the 
>>>> GC wasn't horrible, nobody would work around it.
>>>
>>> Rather, if everyone believed the GC was awesome in all 
>>> circumstances, nobody would work around it. It could be 
>>> awesome in all circumstances, but if people believe 
>>> otherwise, they'll try working around it. It could be 
>>> generally awesome but bad for a certain use case, in which 
>>> case people who need to support that use case will need to 
>>> work around it.
>>>
>>> In this case, I think it's a marketing issue, not a technical 
>>> one. D's being marketed as an alternative to C++, and 
>>> existing C++ users tend to believe that any garbage collector 
>>> is too slow to be usable.
>> 
>> In any case where you attempt to write code in D that is equal 
>> in performance to C++, you must avoid the GC.
>
> Over on d.learn there was a post by H.S. Teoh today about how a 
> struct deserializer she wrote used techniques that absolutely 
> require a GC in order to work without leaking memory 
> everywhere. The version of the code without this technique was 
> an order of magnitude slower.
>
> You could probably implement something in C++ that had similar 
> performance, but you'd be writing a custom string type with 
> reference counting, and it would be terribly annoying to use.

As I haven't reviewed the code, I'll leave no comment.

>
> But the huge reason that it's a marketing problem rather than a 
> technical one is that I doubt most people care enough about 
> performance most of the time to need to avoid garbage 
> collection. The success of Unity3D shows that you can write 
> games in garbage collected languages, and those have at least 
> moderate latency requirements.

Unity3D engine is written in C++, moot point. It's also well 
known in gaming communities for being incredibly underperforming. 
There's no "AAA" games written in Unity, just indie games and 
phone games.

Hilariously enough, if you google "What major games have been 
made with Unity?" The first result(for me, anyways) was a reddit 
thread
https://www.reddit.com/r/gamedev/comments/2qigo0/why_arent_more_aaa_games_developed_with_unity/

Top response
"It's super easy to get from 0% to 90% in Unity but really hard 
to get from 90% to 100%.* The garbage collector is a major 
culprit in this."

>
> If you're doing real-time programming, you do need to be very 
> careful about the GC. If your entire application is real-time, 
> then you can't use a GC at all. If portions of it have lower 
> latency requirements, which, I'm told, is common, you can use 
> @nogc in strategic places, call GC.disable and GC.enable where 
> appropriate, and enjoy the best of both worlds.

Except the GC has leaked into the entire language.
Here's a fun idea, let's play "things that definitely should be 
usable in @nogc but are unusable in @nogc"
all core.thread.* functions are unusable in @nogc
for some dumb reason mutexes, semaphores, condition variables et 
cetera are classes; I have an in-house library that essentially 
wraps pthread primitives in structs.
I have no way to use exceptions in @nogc outside of massive 
hacks, I have to resort to C error handling.
I have to manually create my own functors to be able to capture 
variables by value in lambdas so that they're usable in @nogc. 
How C++98.
Alias template parameters are again massive hidden abusers of the 
GC.
Data structures? Haha. Nothing.
Logging? Time to create your own fprintf wrapper and wonder why 
you're not just using C directly.
This is just a tiny sample of my experience using @nogc.

>
> A bit of digging suggests that real-time programs have troubles 
> with malloc being too slow or having unpredictable latency, and 
> there are a few specialized allocators for real-time systems.

This is almost entirely applicable only to hard real-time. Note 
that hard real-time is a tiny minority of most real-time 
problems; it's almost always a variant of soft real-time.

> So this isn't so much a problem with GC in particular; it's 
> more of a problem with general- purpose allocators.

Yes, you allocate outside of the real-time parts and reuse memory 
in pools/buffers. This is completely against the grain of having 
a standard library that relies on a GC, the massive majority of 
Phobos(and hell, a lot of the runtime and language itself) is 
completely unusable in @nogc code.
The major problem with having a GC that it lulls developers into 
thinking it's okay to allocate *everywhere* because the cost of 
an allocation is now out of sight, and therefore, out of mind. 
This is doubly true for D's hidden allocations.

As a quick example, a lot of the code Walter rewrote to use 
ranges in Phobos over last year(? I think?) runs magnitudes 
faster while not allocating at all.

Yes, there are real-time garbage collectors. Yes, the London 
Stock Exchange did pay 18 million pounds to move away from C# to 
a low-latency C++ system despite this.
NASDAQ's OMX system, to the best of my knowledge, uses Java. With 
the garbage collector disabled and replaced with a C++-like 
allocator(JavaOne 2007, NASDAQ's CIO discussed this, and it is 
also talked about by Irene Aldridge in her 2012 publication)