www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - D Cannot Be Used for Real Time / Low Latency Systems? - Of course it

reply Jakob Jenkov <jakob jenkov.com> writes:
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.
Dec 17 2015
next sibling parent reply ZombineDev <valid_email he.re> writes:
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.


While developing a real-time system with a GC maybe possible, I 
think D makes things much easier by:
+ Having deterministic GC - the GC will only run if your code 
triggers it. If you don't want to use the GC, don't write code 
that triggers it.
+ Being usable without the GC - that way turning into a better C 
/ C++. You can manage all resources yourself, just like you would 
if you were using C/C++.
+ It's not that hard to write your own GC for D. The hard part is 
making it high-performance which is intrinsic to the problem 
domain and not to D specifically.
+ Another good strategy is to start with a GC and when you reach 
the point where you know (e.g. by profiling) where are your 
performance critical parts of your system you can rewrite them 
with high-performance D code (taking advantage of the 
understanding of the problem domain that you've gained in the 
process).
A general advice is to prefer free functions to OOP heirarchies, 
because OOP inheritance often leads to needles coupling. Use 
static polymorphism instead of dynamic dispatch, where possible. 
Often classical OOP polymorphism is unneeded. And in the few 
places where you need to take runtime decisions, switch 
statements are easier to debug. Reduce mutable shared state - 
ranges, functional programming and the 'shared' atrribute really 
help with that.

Bottom line is, if you are competent enough, you can be 
successfull with D, just like you would be if you were using 
C/C++. D's superior compile-time meta programming allows you to 
express zero cost abstractions give you the edge that makes 
things more enjoyable.

There are several open-source kernels written in D that are proof 
of the above:
https://github.com/Vild/PowerNex
https://github.com/Bloodmanovski/Trinix
https://github.com/xomboverlord/xomb
Adam Ruppe has a chapter about bare-metal programming with D in 
his Cookbook.
Dec 18 2015
parent reply Claude <no no.no> writes:
 Bottom line is, if you are competent enough, you can be 
 successfull with D, just like you would be if you were using 
 C/C++. D's superior compile-time meta programming allows you to 
 express zero cost abstractions give you the edge that makes 
 things more enjoyable.

 There are several open-source kernels written in D that are 
 proof of the above:
 https://github.com/Vild/PowerNex
 https://github.com/Bloodmanovski/Trinix
 https://github.com/xomboverlord/xomb
 Adam Ruppe has a chapter about bare-metal programming with D in 
 his Cookbook.


I do think D may be a perfectly valid real-time language. And 
indeed, I believe that the GC is not an issue (you can disable 
it, question solved).

However, is D a proper Embedded System language? I'm not pretty 
sure it's there yet.
Plain C rules the world of embedded systems. All the RTES 
programmers I've met are reluctant to even use C++.

If you cannot program a 16-bit PIC in D, then D will not replace 
C at all (but is it meant to?).

The open-source kernels above are targeted at PC architecture.
I know some work have been done to make bare-metal OS targeted at 
ARM. I don't know what's the state of those projects, and I'd 
love to make my own once I have time (based on Rasberry Pi for 
instance).

To validate D as a proper Real-Time Embedded System, one would 
have to make a proper bare-metal OS a ARMv5 chip (for example). 
Write your Interrupt Service Routines in assembly calling D 
functions, program the MMU, the different hardware blocks (UART, 
INTC, USB etc).
And the API of such an OS would benefit of the expressiveness 
power of D (templates, traits UDA etc) and not just be a C-style 
clone, with an efficiency similar to C (at least same CPU load).
Dec 18 2015
parent Satoshi <satoshi gshost.eu> writes:
On Friday, 18 December 2015 at 10:41:46 UTC, Claude wrote:

 Bottom line is, if you are competent enough, you can be 
 successfull with D, just like you would be if you were using 
 C/C++. D's superior compile-time meta programming allows you 
 to express zero cost abstractions give you the edge that makes 
 things more enjoyable.

 There are several open-source kernels written in D that are 
 proof of the above:
 https://github.com/Vild/PowerNex
 https://github.com/Bloodmanovski/Trinix
 https://github.com/xomboverlord/xomb
 Adam Ruppe has a chapter about bare-metal programming with D 
 in his Cookbook.


 I do think D may be a perfectly valid real-time language. And 
 indeed, I believe that the GC is not an issue (you can disable 
 it, question solved).

 However, is D a proper Embedded System language? I'm not pretty 
 sure it's there yet.
 Plain C rules the world of embedded systems. All the RTES 
 programmers I've met are reluctant to even use C++.

 If you cannot program a 16-bit PIC in D, then D will not 
 replace C at all (but is it meant to?).

 The open-source kernels above are targeted at PC architecture.
 I know some work have been done to make bare-metal OS targeted 
 at ARM. I don't know what's the state of those projects, and 
 I'd love to make my own once I have time (based on Rasberry Pi 
 for instance).

 To validate D as a proper Real-Time Embedded System, one would 
 have to make a proper bare-metal OS a ARMv5 chip (for example). 
 Write your Interrupt Service Routines in assembly calling D 
 functions, program the MMU, the different hardware blocks 
 (UART, INTC, USB etc).
 And the API of such an OS would benefit of the expressiveness 
 power of D (templates, traits UDA etc) and not just be a 
 C-style clone, with an efficiency similar to C (at least same 
 CPU load).



Hi, D should be used for low level/real-time programming.
But there is a lot of exceptions in it and you cannot use entire 
D extensions like synchronized, array relocations, shared, and 
many operations on array like "string" ~  "join", etc.

Im working on modular, microkernel "RTOS" based on sync messages 
passing in D and there is not any big problem with using D as a 
low level language for OS development.

(Im creator of Trinix BTW)
Dec 25 2015
prev sibling next sibling parent reply Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= writes:
On Thursday, 17 December 2015 at 19:56:32 UTC, Jakob Jenkov wrote:

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


D supports most of C (but not all), so it is obviously possible. 
That's never been the argument. D's low performance global 
hog-the-world mark-sweep GC is simply too costly for soft real 
time. In hard real time you cannot even use malloc and have to 
turn off swapping for the memory ranges you stream from, so 
that's a different topic.

It is currently less work to use C++, overall. People won't move 
from C++ unless the new language is better throughout. That's the 
point. You have to be significantly better than C++, Rust and 
Swift to be considered.

And C++, Rust and Swift are improving. So, if D is to be 
considered then changes to D semantics not only has to compete 
with these languages as they are today. Improvements to D is 
competing with where C++, Rust and Swift will be in 2-3 years.
Dec 18 2015
parent reply bachmeier <no spam.com> writes:
On Friday, 18 December 2015 at 09:19:29 UTC, Ola Fosheim Grøstad 
wrote:


 Improvements to D is competing with where C++, Rust and Swift 
 will be in 2-3 years.


You have to pick your battles. Right now, fixing the 
documentation, improving third-party libraries and documentation, 
C++ interoperability, a GC-free standard library, Android 
support, and various other things are all of greater importance.
Dec 18 2015
parent reply Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= writes:
On Friday, 18 December 2015 at 15:01:44 UTC, bachmeier wrote:

 You have to pick your battles.


Exactly.


 Right now, fixing the documentation, improving third-party 
 libraries and documentation, C++ interoperability, a GC-free 
 standard library, Android support, and various other things are 
 all of greater importance.


Mmm... not so sure about that strategy. Focusing on an 
application area that has low coverage in competing languages is 
essential for fast growth. Which is why a language like Julia is 
growing.

Libraries come when the core is competitive.
Dec 18 2015
next sibling parent reply bachmeier <no spam.com> writes:
On Friday, 18 December 2015 at 15:09:05 UTC, Ola Fosheim Grøstad 
wrote:


 Focusing on an application area that has low coverage in 
 competing languages is essential for fast growth. Which is why 
 a language like Julia is growing.


That's why I'm working on embedding R inside D (almost done). 
I've suffered for years with all the problems that are making 
Julia popular. I just felt D was a better choice.

On the other hand, D for embedded devices is a big project with a 
small probability of success, at least from what I've read.
Dec 18 2015
next sibling parent Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= writes:
On Friday, 18 December 2015 at 16:59:54 UTC, bachmeier wrote:

 That's why I'm working on embedding R inside D (almost done). 
 I've suffered for years with all the problems that are making 
 Julia popular. I just felt D was a better choice.


I think the draw towards Julia is long term rather than 
productivity right now. If scientific programmers interested in 
interactive dataset exploration gravitate towards Julia then at 
some point they will have tailored solutions using the GPU...


 On the other hand, D for embedded devices is a big project with 
 a small probability of success, at least from what I've read.


Most people probably don't want to write an interactive 
application entirely in a language like C++, D, Rust or Go, even 
if it was a supported option with full GUI library support!

But making the engine of the app portable is important. So, being 
able to compile libraries to llvm-bit code, WebAssembly, ARM, x86 
etc is very important.
Dec 18 2015
prev sibling parent reply Carl Sturtivant <sturtivant gmail.com> writes:
On Friday, 18 December 2015 at 16:59:54 UTC, bachmeier wrote:

 On Friday, 18 December 2015 at 15:09:05 UTC, Ola Fosheim 
 Grøstad wrote:

 That's why I'm working on embedding R inside D (almost done).


Very interesting, I've been considering the same recently, so I'm 
happy to hear about this. Is any of this visible or usable by an 
outsider like me?
Dec 18 2015
parent bachmeier <no spam.com> writes:
On Friday, 18 December 2015 at 21:26:16 UTC, Carl Sturtivant 
wrote:

 On Friday, 18 December 2015 at 16:59:54 UTC, bachmeier wrote:

 On Friday, 18 December 2015 at 15:09:05 UTC, Ola Fosheim 
 Grøstad wrote:

 That's why I'm working on embedding R inside D (almost done).


 Very interesting, I've been considering the same recently, so 
 I'm happy to hear about this. Is any of this visible or usable 
 by an outsider like me?


Send me an email at the address found here: 
http://www.k-state.edu/economics/staff/bios/bachmeier.html

It's very much usable now. I am finishing the documentation, 
interoperability with R data, and practical functionality like 
linear algebra. Without those, embedding isn't particularly 
helpful. I just don't want to make my work publicly available 
until it's worth the time for others to use it.
Dec 18 2015
prev sibling parent Jakob Jenkov <jakob jenkov.com> writes:
Thanks for the comments everyone! I learn a lot from this D forum 
alone. I have been encaged in the Java world for too long. Great 
to get some input from other languages / eco systems. Not that 
I'll drop Java immediately, but I can definitely see how D can 
supplement Java in our systems.
Dec 18 2015
prev sibling parent reply Barry L. <barry.lapthorn gmail.com> writes:
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.
Dec 18 2015
parent reply Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= writes:
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.
Dec 18 2015
parent Barry L. <barry.lapthorn gmail.com> writes:
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.
Dec 19 2015