<div dir="ltr">On Fri, Oct 20, 2017 at 3:12 PM Avinash Dhumane <<a href="mailto:nistrigunya@gmail.com">nistrigunya@gmail.com</a>> wrote:<div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div>What I wish to hear from the experienced people on this forum here is whether I am missing on something in my Erlang code, or should I just go ahead and program in C.</div><div><br></div></div></blockquote></div><div class="gmail_quote"><br></div><div class="gmail_quote">Your problem is one where you want to have a language which can execute computations quickly, and preferably well under 1ms. In that case, you often want explicit concurrency modeling as well as fast computation. Languages such a C, C++, Rust and OCaml are good candidates.</div><div class="gmail_quote"><br></div><div class="gmail_quote">Soft realtime isn't that well-defined in the literature. But one can define it from hard realtime. Other people have already written about what hard realtime is, so I'm not going to bother with that. But I do note one thing about hard-realtime systems in the context of concurrency which I want to make:</div><div class="gmail_quote"><br></div><div class="gmail_quote">If you have an existing schedule of processes, and you want to add a new one, you must say how often you want to be called, and for how long you will run. Now, the system can either accept your process, in which case it must fulfill the periodic schedulings you wanted. If you use too much time, it is valid for the system to kill your process. Importantly, if the scheduler cannot fit you into its schedule, it must reject starting your process. So if you ask that 10000 processes be started at the same point in time, the scheduler must reject you, unless it has access to 10000 processor cores.</div><div class="gmail_quote"><br></div><div class="gmail_quote">Now, soft realtime is like hard realtime, but there is an SLA and certain objectives which must be met. For instance that 99th percentile of all requests are handled within 2ms. The last percent is ignored and we make no rules for those. Also note that "soft" realtime is a practical thing: you measure the system and fail it if it doesn't meet the SLA.<br></div><div class="gmail_quote"><br></div><div class="gmail_quote">Erlang, as a system is good for handling such soft realtime requirements, provided that they tend to fall in the millisecond range and that you don't excessively load the system with work. Then you can stay within the SLA in practice, easily.</div><div class="gmail_quote"><br></div><div class="gmail_quote">However, if your task is that you want to answer a query in less than a millisecond, you need something closer to the steel. C is one option, but note that if you want a nanosecond computation, you probably want to move from C to FPGAs. Often, you also want explicitly control over what you are doing. If you hog the core with something else, then even switching away from the current work to the newly arrived work can be enough to mess with your timing schedule. Likewise, if the operating system takes an interrupt at the wrong point in time, your timing will be off.</div><div class="gmail_quote"><br></div><div class="gmail_quote">Hence, a good solution starts by defining the acceptable window of lag before answering what language to use. At, say, 5us, you have around 20 memory reads from DRAM into cache lines. Tight schedule which requires you have some control you wont have in a typical Erlang system, even if you factor out the computation to a NIF. Even in C, this will be hard to get close to. If your process is switched out, you are looking at TLB misses as well and it can easily prod you into a direction where you can only answer in 5us for synthetic benchmarks. The trick, of course, is to "cheat" by doing more than a single piece of work in say 50us and then divide down to claim that it is 5us. Or by keeping the data set small enough it fits into L1 or L2.</div><div class="gmail_quote"><br></div><div class="gmail_quote">Erlang could be a nice tool for the orchestration on top of the C programs however, if you happen to need some massive concurrency there.</div><div class="gmail_quote"><br></div><div class="gmail_quote"><br></div><div class="gmail_quote"><br></div></div>