<div dir="ltr">Hi Andersen,<div><br></div><div>Woww thank you very much for the explanation. </div><div><br></div><div>>> <span style="font-family:arial,helvetica,sans-serif">First, you need to recognize you have a parallelism problem</span></div><div>Yes, i need parallelism. But i don't have time to research about GPU processing. </div><div><br></div><div>Yes now i know, how much scheduler that i need to provide.</div><div><br></div><div>Thank you :)</div><div><br></div><div><br></div><div><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">Pada tanggal Sen, 15 Jul 2019 pukul 20.23 Jesper Louis Andersen <<a href="mailto:jesper.louis.andersen@gmail.com">jesper.louis.andersen@gmail.com</a>> menulis:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div dir="ltr"><div class="gmail_default" style="font-family:arial,helvetica,sans-serif">On Sat, Jul 13, 2019 at 10:47 AM I Gusti Ngurah Oka Prinarjaya <<a href="mailto:okaprinarjaya@gmail.com" target="_blank">okaprinarjaya@gmail.com</a>> wrote:<br></div></div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr">Hi,<div><br></div><div>I'm a super newbie, I had done very very simple parallel processing using erlang. I experimenting with my database containing about hundreds of thousands rows. I split the rows into different offsets then assign each worker-processes different rows based on offsets. For each row i doing simple similar text calculation using binary:longest_common_prefix/1</div><div><br></div></div></blockquote><div><br></div><div><div style="font-family:arial,helvetica,sans-serif" class="gmail_default">First, you need to recognize you have a parallelism problem, and not a concurrency problem. So you are interested in what speedup you can get by adding more cores, compared to a single-process solution. The key analysis parameters are work, span and cost[0]. On top of that, you want to look at the speedup factor (S = T_1 / T_p).</div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><br><div>1. How to quick calculation / dumb / simple calculation max Erlang's processes based on above machine specs?<br><br></div></div></blockquote><div><br></div><div style="font-family:arial,helvetica,sans-serif" class="gmail_default">This requires measurement. A single-core/process system have certain advantages:</div><div style="font-family:arial,helvetica,sans-serif" class="gmail_default"><br></div><div style="font-family:arial,helvetica,sans-serif" class="gmail_default">* It doesn't need to lock and latch.</div><div style="font-family:arial,helvetica,sans-serif" class="gmail_default">* It doesn't need to distribute data (scatter) and recombine data (gather).</div><div style="font-family:arial,helvetica,sans-serif" class="gmail_default"><br></div><div style="font-family:arial,helvetica,sans-serif" class="gmail_default">Adding more processes has an overhead and at a point, it will cease to provide speedup. In fact, speedup might go down.</div><div style="font-family:arial,helvetica,sans-serif" class="gmail_default"><br></div><div style="font-family:arial,helvetica,sans-serif" class="gmail_default">What I tend to do, is to napkin math the cost of a process. The PCB I usually set at 2048 bytes. It is probably lower in reality, but an upper bound is nice. If each process has to keep, say, 4096 bytes of data around, I set it at 2*4096 to account for the GC. So that is around 10 Kilobytes per process. If I have a million processes, that is 10 gigabytes of memory. If each process is also doing network I/O you need to account for the network buffers in the kernel as well, etc. However, since you are looking at parallelism, this has less importance since you don't want to keep a process per row (the overhead tends to be too big in that case, and the work is not concurrent anyway[1]).</div><div style="font-family:arial,helvetica,sans-serif" class="gmail_default"></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div>2. The running time when doing similar text processing with 10 worker, or 20 worker or 40 worker was very blazingly fast. So i cannot feel, i cannot see the difference. How to measure or something like printing total minutes out? So i can see the difference.</div><div><br></div></div></blockquote><div><br></div><div style="font-family:arial,helvetica,sans-serif" class="gmail_default">timer:tc/1 is a good start. eministat[2] is a shameless plug as well.</div><div style="font-family:arial,helvetica,sans-serif" class="gmail_default"></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div></div><div>3. How many scheduler need to active / available when i create 10 processes? or 20 processes? 40 processes? and so on..</div><div><br></div></div></blockquote><div><br></div><div style="font-family:arial,helvetica,sans-serif" class="gmail_default">If your machine has 2 physical cores with two hyperthreads per core, a first good ballpark is either 2 or 4 schedulers. Adding more just makes them fight for the resources. The `+stbt` option might come in handy if supported by your environment. Depending on your workload, you can expect some -30 to 50% extra performance out of the additional hyperthread. In some cases it hurts performance:</div><div style="font-family:arial,helvetica,sans-serif" class="gmail_default"><br></div><div style="font-family:arial,helvetica,sans-serif" class="gmail_default">* Caches can be booted out by the additional hyperthread</div><div style="font-family:arial,helvetica,sans-serif" class="gmail_default">* If you don't have memory presssure to make a thread wait, there is little additional power in the hyperthread</div><div style="font-family:arial,helvetica,sans-serif" class="gmail_default">* In a laptop environment, the additonal hyperthread will generate more thermal heat. This might make the CPU clock down resulting in worse run times. This is especially important on MacBooks. They have really miserable thermals and add way too powerful CPUs in a bad thermal solution. It gives them good peak performance when "sprinting" for short bursts, but bad sustain performance, e.g., "marathons". Battery vs AC power also means a lot and will mess with runtimes.</div><div style="font-family:arial,helvetica,sans-serif" class="gmail_default"><br></div><div style="font-family:arial,helvetica,sans-serif" class="gmail_default">As for how many processes: you want to have enough to keep all your schedulers utilized, but not so many your work is broken into tiny pieces. This will mean more scatter/gather IO is necessary, impeding your performance. And if that IO is going across CPU cores, you are also looking at waiting on caches.</div><div style="font-family:arial,helvetica,sans-serif" class="gmail_default"><br></div><div style="font-family:arial,helvetica,sans-serif" class="gmail_default">If you are really interested in parallel processing, it is probably better to look at languages built for the problem space. Rust, with its rayon library. Or something like <a href="https://futhark-lang.org/" target="_blank">https://futhark-lang.org/</a> might be better suited. Or even look at TensorFlow. It has a really strong, optimized, numerical core. Erlang, being bytecode interpreted, pays an overhead which you have to balance out with either more productivity, ease of programming, faster prototyping or the like. Erlang tends to be stronger at MIMD style processing (and so does e.g., Go).<br></div><div style="font-family:arial,helvetica,sans-serif" class="gmail_default"><br></div><div style="font-family:arial,helvetica,sans-serif" class="gmail_default">[0] <a href="https://en.wikipedia.org/wiki/Analysis_of_parallel_algorithms" target="_blank">https://en.wikipedia.org/wiki/Analysis_of_parallel_algorithms</a></div></div><div style="font-family:arial,helvetica,sans-serif" class="gmail_default">[1] your work is classical SIMD rather than MIMD.<br></div><div style="font-family:arial,helvetica,sans-serif" class="gmail_default">[2] <a href="http://github.com/jlouis/eministat" target="_blank">github.com/jlouis/eministat</a><br></div><br>-- <br><div dir="ltr" class="gmail-m_2096571625017880504gmail_signature">J.</div></div>
</blockquote></div>