On Friday, 7 February 2014 at 16:25:01 UTC, Andrei Alexandrescu wrote:
> I'm jaded - Walter and I bounced around for years ideas that vaguely prescribe a feature/optimization and gloss over many details and all difficulties... they're a dime a dozen.

I see, in this particular case it will work if dynamic stack allocation works and if you have guards on the stack size (page traps at the end of the stack).

The optimization is very limited, since it only works for returning one variable length structure under certain circumstances, but then again it is a common case for types where you want to do temporary allocation and prepending/appending something before making a system call or similar.

On Wednesday, 5 February 2014 at 16:50:40 UTC, Ola Fosheim Grøstad wrote:
> On Wednesday, 5 February 2014 at 16:04:06 UTC, Dicebot wrote:
>> It is up to programmer to decide. Right now he does not have a choice and sometimes you can't afford to have GC in your program at all (as in can't have it linked to the binary), not just can't call collection cycles. Having sane fallback is very desired.
>
> Yes, if D is going to be a system level programming language then there is no other option than.
>
>> Proposed solution does not seem to save you from uncontrollably long collection cycles anyway as it still uses same memory pool so I don't see how it can help even games, not even speaking about more demanding applications.
>
> Well, for games and game servers I think a 100ms delay once or twice per hour is inconsequential in terms of impact.
>
> If you can reduce the GC load by various means it might work out for most applications.
>
> 1. Reduce the set considered for GC by having the GC not scanning paths that are known to be covered by RC.
>
> 2. Improving speed of GC by avoiding interior pointers etc.
>
> 3. Reducing the number of calls to GC by having RC take care of the majority of the memory releases.
>
> 4. Have local GC by collecting roots of nodes that are known to create cycles.
>
> I don't think ARC is an option for OS-level development  and critical applications anyway. :-)
>
>>> Different scenarios have different needs.
>>
>> Haven't you just basically confirmed my opinion? :)
>
> In a way. :-) But what if the question is this:
>
> How can you in a pragmatic way come up with a solution that cover most soft real time applications?
>
> A compiler switch that default to RC (i.e. turn standard GC features into standard RC features) could in theory get you pretty close, but I think clever RC/GC memory management requires whole program analysis…

For a competitive game 100ms delays during gameplay would be completely unacceptable.

On 02/06/2014 12:16 AM, Adam D. Ruppe wrote:
> On Wednesday, 5 February 2014 at 22:32:52 UTC, Andrei Alexandrescu wrote:
>> ...
>> I should also add that imparting useful semantics to scope is much
>> more difficult than it might seem.
>
> I'm not so sure about that*, but the fact is scope would be enormously
> useful if it was implemented.
>
> * Let's say it meant "assigning to any higher scope is prohibited".

Then the type system should track scope depth (i.e. regions) in order to support abstraction properly. (This is Walter's usual identity function test, and it won't get less of a problem unless D gets a sane polymorphic type system.)

> That
> should be trivially easy to check and ensures that variable itself
> doesn't escape.

How would you express that a slice of a static stack array of GC-allocated references (and those may be escaped) shouldn't be escaped?

> The tricky part would be preventing:
>
> int[] global;
> void foo(scope int[] a) {
>     int[] b = a;
>     global = b;
> }

Well, to some extent this is a solved problem. Just decide which escape analysis strategy to use and maybe extend its precision with type information.

On Saturday, 8 February 2014 at 10:21:27 UTC, ixid wrote:
> For a competitive game 100ms delays during gameplay would be completely unacceptable.

But inconsequential, in the economic sense: you cannot demand a refund for such a tiny deficiency.

Am 08.02.2014 11:21, schrieb ixid:
> On Wednesday, 5 February 2014 at 16:50:40 UTC, Ola Fosheim Grøstad wrote:
>> On Wednesday, 5 February 2014 at 16:04:06 UTC, Dicebot wrote:
>>> It is up to programmer to decide. Right now he does not have a choice
>>> and sometimes you can't afford to have GC in your program at all (as
>>> in can't have it linked to the binary), not just can't call
>>> collection cycles. Having sane fallback is very desired.
>>
>> Yes, if D is going to be a system level programming language then
>> there is no other option than.
>>
>>> Proposed solution does not seem to save you from uncontrollably long
>>> collection cycles anyway as it still uses same memory pool so I don't
>>> see how it can help even games, not even speaking about more
>>> demanding applications.
>>
>> Well, for games and game servers I think a 100ms delay once or twice
>> per hour is inconsequential in terms of impact.
>>
>> If you can reduce the GC load by various means it might work out for
>> most applications.
>>
>> 1. Reduce the set considered for GC by having the GC not scanning
>> paths that are known to be covered by RC.
>>
>> 2. Improving speed of GC by avoiding interior pointers etc.
>>
>> 3. Reducing the number of calls to GC by having RC take care of the
>> majority of the memory releases.
>>
>> 4. Have local GC by collecting roots of nodes that are known to create
>> cycles.
>>
>> I don't think ARC is an option for OS-level development  and critical
>> applications anyway. :-)
>>
>>>> Different scenarios have different needs.
>>>
>>> Haven't you just basically confirmed my opinion? :)
>>
>> In a way. :-) But what if the question is this:
>>
>> How can you in a pragmatic way come up with a solution that cover most
>> soft real time applications?
>>
>> A compiler switch that default to RC (i.e. turn standard GC features
>> into standard RC features) could in theory get you pretty close, but I
>> think clever RC/GC memory management requires whole program analysis…
>
> For a competitive game 100ms delays during gameplay would be completely
> unacceptable.

In the stock exchange there are Java and .NET systems doing transactions at faster speed than that.

100ms is too much money to be lost if the transaction course changes.

--
Paulo

On 6 February 2014 21:59, <"Ola Fosheim Grøstad\" <ola.fosheim.grostad+dlang@gmail.com>"@puremagic.com> wrote:

> On Thursday, 6 February 2014 at 11:29:35 UTC, Manu wrote:
>
>> Some that I regularly encounter: system libs, opengl, directx, fmod,
>> physics (havok, phyzx, etc), animation (euphoria, natural
>>
>
> And just to nitpick:
>
> 1. Games are hit or miss with a very short life cycle. This is not typical. Most software have a life cycle counted in years with contractual support requirements that can be harsh, not months with very little possibility of damage claims for the end user.
>

I don't think you've mage a game recently.
Most big games are multi-year projects with teams numbering well in the
hundreds, and then downloadable-content (ie, after-market content) is
basically a given these days, and often supported by a different team than
initially wrote the code.


2. The life cycle of games is porting when your product succeeds. You are
> F*CK*D if you don't have source code access and want to port to an emerging platform, so I believe you can obtain source code for libraries like Havoc and FMOD for that reason alone.
>
> I really don't think closed source libraries should be the focus of D if it prevents having a good infrastructure.
>

I didn't say they should be a focus, I'm saying they must however be supported.

On Sunday, 9 February 2014 at 10:06:12 UTC, Manu wrote:
> I don't think you've mage a game recently.

Pointless comment.

> Most big games are multi-year projects with teams numbering well in the

Most games are not big.
Most games fail in the marketplace.

> I didn't say they should be a focus, I'm saying they must however be supported.

Must is a strong word, but since D is focusing on separate compilation it probably is a focus.

Why are most comments about the application domain for D centered on "prestigious" projects such as AAA games, high volume trading system and safety critical appliations?

The most likely application domain is a lot less "exciting": tools and simple servers.

Get down to earth, plz.

On Saturday, 8 February 2014 at 16:41:42 UTC, Paulo Pinto wrote:
>
> In the stock exchange there are Java and .NET systems doing transactions at faster speed than that.
>
> 100ms is too much money to be lost if the transaction course changes.

It might be worth referring back to Don's talk at least year's D conference.  His company does targeted advertising, and if I remember correctly, their entire transaction response time limit including time on the wire is around 40ms.  It's small amounts rather than potentially millions per transaction, but either way, for many network services these days, profit is directly tied to exceedingly rapid response time.

Even for cloud services, let's say a user is willing to accept a 500ms transaction time, including transport.  Now let's say the could service has to talk to 5 other services to process the request, each which has a normal transaction time of 50ms.  If one occasionally spikes to 250ms, that's a problem for that one request, but it's an even bigger problem for all the requests piling up behind it, since in this case the entire process is blocking on a garbage collection.  Under very heavy load, the process may not even be able to recover.  You can see this in Netty for Java, as it has a fixed request queue size (defaults to like 5) and once this limit is reached it just starts rejecting requests.  A long collection means request failures.

On Sunday, 9 February 2014 at 10:16:20 UTC, Ola Fosheim Grøstad wrote:
> On Sunday, 9 February 2014 at 10:06:12 UTC, Manu wrote:
>> I don't think you've mage a game recently.
>
> Pointless comment.
> [snip]
> Get down to earth, plz.

I love how you wrote that "Pointless comment" then added that "Get down to earth, plz" at the end. :P
[ok, sorry for metaposting, but I couldn't resist]

On Sunday, 9 February 2014 at 17:48:21 UTC, Francesco Cattoglio wrote:
> I love how you wrote that "Pointless comment" then added that "Get down to earth, plz" at the end. :P

Yes, you did love that, didn't you? It is generally a good idea to set down the foot firmly when people go ad hominem.

However, the last point was directed to the D community. The language needs to be more focused on being very good at some key areas, not cover everything.