Re: D Cannot Be Used for Real Time / Low Latency Systems? - Of course it can!

2015-12-19 Thread Barry L. via Digitalmars-d
On Saturday, 19 December 2015 at 02:20:32 UTC, Ola Fosheim 
Grøstad wrote:

On Friday, 18 December 2015 at 20:40:48 UTC, Barry L. wrote:
Summary - modern financial trading apps use multi-core 
machines and shared memory via memory mapped files, and 
multi-core boxes to achieve nanosecond latency.


1 nanosecond => 3 clock cycles. A single read from RAM is > 100 
cycles.


In that ballpark you have to use silicone/FPGA.


Yep, my typo, meant low microsecond.


Re: D Cannot Be Used for Real Time / Low Latency Systems? - Of course it can!

2015-12-18 Thread Barry L. via Digitalmars-d

On Thursday, 17 December 2015 at 19:56:32 UTC, Jakob Jenkov wrote:

Hi guys,

I read from some of the other forum threads that D is being 
criticized for not being usable for real time / low latency 
systems because it has a GC.


First of all, such system are already being written in Java. 
Google "Martin Thompson" and LMAX and you will see. Or Aeron 
(also Java and Martin Thompson).


Second, when Java has been used to develop such systems, the GC 
has been avoided as much as possible - which is even easier to 
do with D than Java.


So, it's a load of BS that D's GC should somehow make it 
impossible to make real time / low latency software.


Yes, it is a load of BS.

Andy Smith's talk from DConf 2015:  
https://www.youtube.com/watch?v=0KBhb0iWsWQ


Summary - modern financial trading apps use multi-core machines 
and shared memory via memory mapped files, and multi-core boxes 
to achieve nanosecond latency.  Compare to pre-2000 systems that 
used single core and Tibco/RV networking.  Remove the network, 
remove the bottleneck.


Java does it using Chronicle (google Peter Lawrey).  The other 
twist is to reuse allocated flyweights to avoid triggering the GC.


Andy (unless I misheard) worked with/for Peter and has 
reimplemented the same thing using D with comparable (or better?) 
performance.


Even if D's entirely optional GC was on, its trigger could (I 
would think) be avoid be similarly allocating once, and reusing 
the object.