Re: D Cannot Be Used for Real Time / Low Latency Systems? - Of course it can!
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)
Re: D Cannot Be Used for Real Time / Low Latency Systems? - Of course it can!
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!
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.
Re: D Cannot Be Used for Real Time / Low Latency Systems? - Of course it can!
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.
Re: D Cannot Be Used for Real Time / Low Latency Systems? - Of course it can!
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).
Re: D Cannot Be Used for Real Time / Low Latency Systems? - Of course it can!
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.
Re: D Cannot Be Used for Real Time / Low Latency Systems? - Of course it can!
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.
Re: D Cannot Be Used for Real Time / Low Latency Systems? - Of course it can!
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.
Re: D Cannot Be Used for Real Time / Low Latency Systems? - Of course it can!
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.
Re: D Cannot Be Used for Real Time / Low Latency Systems? - Of course it can!
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.
Re: D Cannot Be Used for Real Time / Low Latency Systems? - Of course it can!
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.
Re: D Cannot Be Used for Real Time / Low Latency Systems? - Of course it can!
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?
Re: D Cannot Be Used for Real Time / Low Latency Systems? - Of course it can!
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.
Re: D Cannot Be Used for Real Time / Low Latency Systems? - Of course it can!
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.
D Cannot Be Used for Real Time / Low Latency Systems? - Of course it can!
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.
