On Sun, 2014-03-23 at 10:35 -0700, Walter Bright wrote:
> On 3/23/2014 12:13 AM, Russel Winder wrote:
> > But for real time you would just have to remove the
> > GC completely to have the needed guarantees.
> 
> 
> malloc/free cannot be used in hard real time systems, either. malloc/free do not have latency guarantees.

By estimating the resource needs and preallocating a freelist, you can get round this issue. C++ is quite good at supporting this sort of stuff.

-- 
Russel. ============================================================================= Dr Russel Winder      t: +44 20 7585 2200   voip: sip:russel.winder@ekiga.net 41 Buckmaster Road    m: +44 7770 465 077   xmpp: russel@winder.org.uk London SW11 1EN, UK   w: www.russel.org.uk  skype: russel_winder

On 3/22/2014 9:47 AM, Paulo Pinto wrote:
>
> Assuming those 10% still happen if the test was done today as suggested,
> how much are trade companies willing to pay for developers to achieve
> those 10% in C++ vs having a system although 10% slower,
> still fast enough for operations while saving salaries for more cheaper
> developers?

If the domain is high-performance, high-volume, (hard|soft) realtime, then I doubt very much you can get away with significantly cheaper developers, even if it is Java. Unless it just happens to be a sub-par company with a questionable future.

Am 23.03.2014 22:04, schrieb Nick Sabalausky:
> On 3/22/2014 9:47 AM, Paulo Pinto wrote:
>>
>> Assuming those 10% still happen if the test was done today as suggested,
>> how much are trade companies willing to pay for developers to achieve
>> those 10% in C++ vs having a system although 10% slower,
>> still fast enough for operations while saving salaries for more cheaper
>> developers?
>
> If the domain is high-performance, high-volume, (hard|soft) realtime,
> then I doubt very much you can get away with significantly cheaper
> developers, even if it is Java. Unless it just happens to be a sub-par
> company with a questionable future.
>

My question was precisely because I tend to see that a lot in general, as on my area saving project costs seems to be more valuable than quality.

--
Paulo

On 3/23/2014 12:42 PM, Russel Winder wrote:
> On Sun, 2014-03-23 at 10:35 -0700, Walter Bright wrote:
>> On 3/23/2014 12:13 AM, Russel Winder wrote:
>>> But for real time you would just have to remove the
>>> GC completely to have the needed guarantees.
>>
>>
>> malloc/free cannot be used in hard real time systems, either. malloc/free do not
>> have latency guarantees.
>
> By estimating the resource needs and preallocating a freelist, you can
> get round this issue. C++ is quite good at supporting this sort of
> stuff.


Yes, and you can do that in D, the same way.

On Sunday, 23 March 2014 at 18:15:16 UTC, Paulo Pinto wrote:
>
> At least on Java world it is not quite true.

And that's why I said a language like C/C++ that allows aliasing.


> If you use XML parsers that return a DOM or SAX, yes quite true.
>
> But as far as I can tell, XML streaming parsers (StAX) only parse on demand.

It's been a while since I used it, but the Apache SAX parser (Xerces?) converts all string input to wchar_t before passing it to the callback.  And since XML input is nearly always in UTF-8, this can mean a ton of transcoding.

On Monday, 24 March 2014 at 05:41:38 UTC, Sean Kelly wrote:
> On Sunday, 23 March 2014 at 18:15:16 UTC, Paulo Pinto wrote:
>>
>> At least on Java world it is not quite true.
>
> And that's why I said a language like C/C++ that allows aliasing.
>
>
>> If you use XML parsers that return a DOM or SAX, yes quite true.
>>
>> But as far as I can tell, XML streaming parsers (StAX) only parse on demand.
>
> It's been a while since I used it, but the Apache SAX parser (Xerces?) converts all string input to wchar_t before passing it to the callback.  And since XML input is nearly always in UTF-8, this can mean a ton of transcoding.

Ah Xerces! Last time I looked into it was around 2003.

I doubt it has any optimizations of modern XML parsers looking
how little the web site has changed since then.

--
Paulo

On Saturday, 22 March 2014 at 17:30:45 UTC, TJB wrote:
> On Saturday, 22 March 2014 at 16:35:07 UTC, Brian Rogoff wrote:
>
>> This is a very interesting thread that you started. Could you flesh it out more with some example C++ that you'd like compared to D? I'm sure quite a few people would assist with a translation.
>
> Well, right away people jumped to high-frequency trading. Although that may be the most visible area in computational finance - it's not the only one. There are areas where performance is crucial, but where trading is done at a lower frequency (where latency is not the main issue).
>

I apologize for that. HFT has been a driver of a lot of business and attention. Of course you are right about areas with less latency sensitivity and D is attractive there. Even in latency sensitive efforts I think could be D attractive for new efforts providing some of the memory management efforts continue to evolve. My main point was selling it would be tough.

Thanks
Dan

On Monday, 24 March 2014 at 11:57:14 UTC, Daniel Davidson wrote:
> On Saturday, 22 March 2014 at 17:30:45 UTC, TJB wrote:
>> On Saturday, 22 March 2014 at 16:35:07 UTC, Brian Rogoff wrote:
>>
>>> This is a very interesting thread that you started. Could you flesh it out more with some example C++ that you'd like compared to D? I'm sure quite a few people would assist with a translation.
>>
>> Well, right away people jumped to high-frequency trading. Although that may be the most visible area in computational finance - it's not the only one. There are areas where performance is crucial, but where trading is done at a lower frequency (where latency is not the main issue).
>>
>
> I apologize for that. HFT has been a driver of a lot of business and attention. Of course you are right about areas with less latency sensitivity and D is attractive there. Even in latency sensitive efforts I think could be D attractive for new efforts providing some of the memory management efforts continue to evolve. My main point was selling it would be tough.
>
> Thanks
> Dan

Dan,

Thanks for your thoughtful points.  I think your experience is worth listening to - I think it confirms that both:

* D is worth pursuing in these areas

* It won't be easy to convince others to adopt it

These points are worth thinking deeply about as D is developed for the real world.

TJB

On Sunday, 23 March 2014 at 17:38:17 UTC, Sean Kelly wrote:
> On Saturday, 22 March 2014 at 14:04:01 UTC, Daniel Davidson wrote:
>>
>> For example, I could see technical reasons why in certain non-quant areas like XML parsing where D can be faster than C++. (http://dotnot.org/blog/archives/2008/03/12/why-is-dtango-so-fast-at-parsing-xml/) But then, with a large amount of time and unlimited funding the techniques could probably be duplicated in C++.
>
> Try no funding and a trivial amount of time.  The JSON parser I wrote for work in C performs zero allocations and unescaping is performed on demand.  D arguably makes this easier by building slicing into the language, but not decoding or copying is a design decision, not a language artifact (at least in the case of C/C++ where aliasing data is allowed).  The take-away from that Tango article is that the performance hit for parsing is aggressively decoding data the user may not care about or may not want decoded in the first place.  This just happens to be the approach that basically every XML parser on the planet uses for some ridiculous reason.

This isn't for ridiculous reasons, this is because in other languages you have no guarantee that what you work on is immutable. So you must aggressively copy anyway. With a separate decoding step, you'll ends up copying twice, which is also wasteful.

On Sunday, 23 March 2014 at 18:58:20 UTC, Walter Bright wrote:
> On 3/23/2014 11:29 AM, "Ola Fosheim Grøstad"
>> While that is true you can have a soft real time thread feeding the hard real time thread
>
> Yes, and you can do that with GC, too.

You can, but the way I view "soft real time" is that you accept jitter, but not prolonged freezing of threads. I don't think the current GC is "soft real time".