On 3/22/2014 7:04 AM, Daniel Davidson wrote:
> But then, with a large amount of time and unlimited funding the techniques could
> probably be duplicated in C++.

That's correct. It's also true of writing code in C or even assembler.

Productivity matters because time-to-deploy matters. I.e. if you can deploy a better system in one month rather than two months, you've got an extra month of making money with it.

On Saturday, 22 March 2014 at 14:30:00 UTC, Russel Winder wrote:
> On Sat, 2014-03-22 at 14:17 +0000, Daniel Davidson wrote:
> […]
>> Performance engineers who can eek out that 10% on existing systems do very well. The same engineers who can build it entirely do much better.
>
> Good C++ programmers appear to be able to get $350k to $400k in NY.
>
> Of course the effect of that good programmers can be a profit increase
> measures in millions.
>
> I guess D should be able to do things just as fast as C++, at least
> using LDC or GDC. My little informal microbenchmarks indicate that this
> is the case, but for now this is anecdotal evidence not statistically
> significant. Sadly for a while D programmers won't be able to achieve
> the same remuneration as the top C++ programmers exactly because there
> is little demand/supply pressure.

HFT is very latency sensitive. D stop the world GC is a no go.

D needs a better GC to be viable in these markets.

The work Don's company does has very similar requirements to HFT. His talks here are totally relevant to the use of D in this area.

On Saturday, 22 March 2014 at 23:27:18 UTC, Sean Kelly wrote:
> The work Don's company does has very similar requirements to HFT. His talks here are totally relevant to the use of D in this area.

Yes, I'm very much looking forward to that talk as well.

His talk last year killed!

On Saturday, 22 March 2014 at 23:27:18 UTC, Sean Kelly wrote:
> The work Don's company does has very similar requirements to HFT. His talks here are totally relevant to the use of D in this area.

They did significant work to customize th GC in order to meet the requirements.

On Saturday, 22 March 2014 at 14:04:01 UTC, Daniel Davidson wrote:
> On Saturday, 22 March 2014 at 13:36:01 UTC, Saurabh Das wrote:
>> The edge for D in our case comes from 3 factors -
>>
>> 1. A lot of statistical data from older C++ systems means better assumptions and decisions in the new D system; and
>>
>
> But, clearly that is not necessarily a benefit of D. It is a benefit of prior experience and the learning curve. If you said, we use our data to not only make better assumptions/decisions, but to do things in D that can not be done in C++ - then you make a very strong case.

Yes - I didn't mean this as a point in favour of D, but just to put down the factors that made a difference. However in all microbencharks thus far, D has not done worse than C++.

>
>> 2. 20% of the system is latency-critical and 80% is not. D allows us to quickly finish 80% and really concentrate on the critical 20%. I must also comment upon how much more productive it is to write a new system in D as compared with C++ - gives us more time to think about the actual problem than try to jump through the C++ hoops.
>>
>
> Productivity is very important and can mean big $$ for most firms. But if latency is the critical factor in an all-or-nothing game, then it is much less so. Maybe your game is different and you have edge beyond low latency. I hope that is the case.
>

To clarify - for us latency is critical. The reason that productivity matters is that given resource constraints, I can spend much more time optimizing the 20% in D because the 80% can be written quickly.

>> 3. A much better type system - some checks can be moved to compile time. Major benefit.
>>
>
> What is a simple example of something that could be done with D but not C++ that has nothing to do with building things with less developer time?
>
> 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++.

None of the type-system stuff CANNOT be duplicated in C++ (given enough resources), but D makes it easy.

I'll give you an example which is similar to XML parsing - consider FIX messages. Using templates judiciously, it is possible to write a blazing fast FIX message processing system in D where a lot of the processing is unrolled at compile time. Surely this is possible in C++, but it's going to be a hell of a task.

>
> Again, I don't think it is necessary to have any/many cases where D beats C++ hands down in performance for its adoption to widen. But to push D to a wider audience by focusing on areas where the bar is already super high is tough. If I had money to invest in D I would invest it in vibe rather than quant because the relative advantages of D are so much higher.

Yes I agree with that.

>
>> Yes - R, Matlab et all won't be replaced by D most likely. Let's wait and watch. However I disagree about the HFT/low-latency side. Ofcourse there's no way to say for sure. Let's check again in a year :)
>
> Sounds good - keep us posted!
>
> Thanks
> Dan

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.

On Sat, 2014-03-22 at 21:13 +0000, deadalnix wrote:
[…]
> HFT is very latency sensitive. D stop the world GC is a no go.
> 
> D needs a better GC to be viable in these markets.

GC technology was well beyond "stop the world" in Common Lisp in the 1990s. Java learnt this lesson in the 2000s. IBM, Azul, and now OpenJDK have an array of very sophisticated, and indeed some real-time, garbage collectors. Clearly though the Lisp and Java worlds are very different from the C++, D and Go worlds, thus sophisticated algorithms cannot simply be transplanted.

As I understand it, Go has a parallel mark and sweep algorithm which is relatively unsophisticated, and a bit "stop the world", but they claim fine for small heaps: generational and compacting collectors (as per Java) are only beneficial for large heaps is the claim (but I haven't seen much data to back this up for Go). There is rumour of a change, but this has been circulating for ages.

I guess Herb Sutter's (reported) view that he can write C++ code with no new and so no need for garbage collection, if applied to D would mean that although the collector "stopped the world", the heap would need no work and be small. But for real time you would just have to remove the GC completely to have the needed guarantees.
-- 
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

Am 23.03.2014 08:13, schrieb Russel Winder:
> On Sat, 2014-03-22 at 21:13 +0000, deadalnix wrote:
> […]
>> HFT is very latency sensitive. D stop the world GC is a no go.
>>
>> D needs a better GC to be viable in these markets.
>
> GC technology was well beyond "stop the world" in Common Lisp in the
> 1990s. Java learnt this lesson in the 2000s. IBM, Azul, and now OpenJDK
> have an array of very sophisticated, and indeed some real-time, garbage
> collectors. Clearly though the Lisp and Java worlds are very different
> from the C++, D and Go worlds, thus sophisticated algorithms cannot
> simply be transplanted.
>
> As I understand it, Go has a parallel mark and sweep algorithm which is
> relatively unsophisticated, and a bit "stop the world", but they claim
> fine for small heaps: generational and compacting collectors (as per
> Java) are only beneficial for large heaps is the claim (but I haven't
> seen much data to back this up for Go). There is rumour of a change, but
> this has been circulating for ages.
>
> I guess Herb Sutter's (reported) view that he can write C++ code with no
> new and so no need for garbage collection, if applied to D would mean
> that although the collector "stopped the world", the heap would need no
> work and be small. But for real time you would just have to remove the
> GC completely to have the needed guarantees.
>

Well, there is a nice quote from Bjarne as well:

 "C++ is my favourite garbage collected language because it generates so little garbage"

And yet C++11 got to have an optional GC API defined, so even the ANSI/ISO folks do recognize its value in C++.

Visual C++ already supports it,

http://msdn.microsoft.com/en-us/library/vstudio/hh567368%28v=vs.120%29.aspx

--
Paulo

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

> approach to numerical modelling.
>
[snip]
> Many of the hedge funds are following in the HEP,

By HEP do you mean "High Energy Physics"?

[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"?

TIA.

-regards,
Larry