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.

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.

On Sunday, 23 March 2014 at 07:14:06 UTC, Walter Bright wrote:
> On 3/21/2014 3:33 PM, TJB wrote:
>> I would be happy to help you with an option pricing example that
>> is commonly used.  Let me know if you are interested.
>
> Sure, please email it to me.

Walter, I would be happy to.  Where do I find your email address?  Sorry if this is a dumb question.

TJB

Am 23.03.2014 18:38, schrieb Sean Kelly:
> 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.

At least on Java world it is not quite true.

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.

Unless I am missing something.

--
Paulo

On Sunday, 23 March 2014 at 17:35:37 UTC, Walter Bright wrote:
> malloc/free cannot be used in hard real time systems, either. malloc/free do not have latency guarantees.

While that is true you can have a soft real time thread feeding the hard real time thread with new configurations and the associated preallocated buffers using a lock-free queue.

On 3/23/2014 11:10 AM, TJB wrote:
> Walter, I would be happy to.  Where do I find your email address?  Sorry if this
> is a dumb question.


My first name followed by digitalmars.com.

On 3/23/2014 11:29 AM, "Ola Fosheim Grøstad" <ola.fosheim.grostad+dlang@gmail.com>" wrote:
> On Sunday, 23 March 2014 at 17:35:37 UTC, Walter Bright wrote:
>> malloc/free cannot be used in hard real time systems, either. malloc/free do
>> not have latency guarantees.
>
> While that is true you can have a soft real time thread feeding the hard real
> time thread with new configurations and the associated preallocated buffers
> using a lock-free queue.

Yes, and you can do that with GC, too.

On 3/23/2014 10:38 AM, Sean Kelly wrote:
> 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.

Lazy evaluation FTW. Ranges and algorithms fit right in with that.

On Sun, 2014-03-23 at 11:46 -0500, evansl wrote:
> On 03/22/14 06:40, Russel Winder wrote:
> [snip]
> > What you are alluding to is the use of Monte Carlo approach to solve some of the models given boundary conditions. This is a "bog standard"
> By "bog standard" do you mean "plain or ordinary?
> 
> http://en.wiktionary.org/wiki/bog_standard

Sort of. This webpage almost, but not quite, totally misses all the British humorous subtleties. But yes. Effectively.

> > approach to numerical modelling.
> >
> [snip]
> > Many of the hedge funds are following in the HEP,
> 
> By HEP do you mean "High Energy Physics"?

Oh yes. But I was only involved in HEP when all the software was in FORTRAN. Recently they have started using Fortran, and even C++. This is almost certainly Stephen Wolfram's fault.

> [snip]
> > In a number of the major international finance houses a Python/Scala/C++ stack has taken hold. However this is not fixed forever, since whenever the CTO changes the stack tends to as well.
> 
> By CTO do you mean "Chief Technology Officer"?

Indeed.

Many companies outside the US hipster company organization theory may use the term Technical Director. :-)

> TIA.
> 
> -regards,
> Larry

Hopefully that is not Page or Ellison. ;-)


-- 
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 Sun, 2014-03-23 at 19:15 +0100, Paulo Pinto wrote:
[…]
> 
> At least on Java world it is not quite true.
> 
> 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.
> 
> Unless I am missing something.

This is exactly why Groovy has two distinct XML parsers. British Library consider a small XML document to be about 6GB, you don't use DOM for these ;-)

-- 
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