"A Pharo forked process is still running under the vm single threaded process... so it's more a matter of in-image blocking rather than external access."
There is parallelism which means code that execute at the same time instruction by instruction There is concurency which means code that executes a bit of it from different parts giving the illusion that codes run at the same time OS threads do parallelism VM threads , aka green threads, do concurrency VM technically speaking uses several OS threads but the byte code is indeed executed on the main thread only , thus VM alllows only green threads for pharo code. I am not saying you do not know this stuff, I am just mention it here so everyone is on the same page. You cannot have more parallelism than cores, actually that may not be true because I think each core allows for two parallel threads because of hyperthreading but more or less thats the idea. Just for the record there are cases when multiple OS threads running on multiple cores can be actually slower than one thread running on one core. This the nightmare that is called parallelism and why coders generally avoid it. The usually reason why multiple OS threads may be slower it has to do with CPU cache and how it exchanges data between threads and CPU cores. I had the pleasure of getting a taste of this nightmare when I was learning OpenMP which is the most popular library for parallel execution for C/C++. Of course there are also the usual problems with synchronisation etc. Technically speaking you can do OS threads from Pharo with my CPP library. Thats possible because CPP works by having two isolated process (actually you can have an infinite amount of processes if your hardware can handle them ) , in this case one C++ executable and one for Pharo that share an area of memory that both can directly access to. You could implement callbacks to, you could do anything and you would not have to worry about joining threads or providing compatibility with Pharo VM because you deal with shared data and not code execution. Because CPP uses shared memory which in turn uses OS kernel native memory access and management functions, you get top speed. So you can have one process using OpenMP taking full advantage of the hardware acceleration (triggering multiple OS threads) of your CPU cores and one for Pharo that will drive the OpenMP process. There is still the issue of data synchronisation, who locks the data and who accesses it at what time, but those are usual issues for any kind of thread orientated coding, you wont be doing anything diffirent. "However any CPU intensive request will block the process, and that will happen with looping server like Pharo or an evented VM like NodeJS." Again you can avoid that with my CPP library. You do not need to block , you could let the external process do its thing and just block it when you decide to fetch data after it finishes or on specific intervals. There are so many ways you can do this. You can also have like the VM one central OS thread that is able to be blocked by Pharo and multiple secondary ones that Pharo will have no control over either than the level of control that the main thread provides. In any case, most servers run Apache which should deal with many of those issues, there are wrappers for many languages , Apaches is wrriten in C/C++ so its should be able to tap into this technology to avoid solving problems that have been already solved. So its a matter of writing wrappers for Pharo too. On Wed, Dec 14, 2016 at 8:59 PM Esteban A. Maringolo <emaring...@gmail.com> wrote: > 2016-12-14 15:41 GMT-03:00 Dimitris Chloupis <kilon.al...@gmail.com>: > > That 5% idle CPU consumption is not the only problem, creating a new > process > > will add additional overheads anyway so it does not make sense to have > more > > pharo processes than CPU cores. > > Not exactly, thinking it that way would disable you from running Pharo > in a machine with other daemon services running (if daemons > cores). > But those other daemons at idle consume less than 1% of the total CPU, > whilst 10 idle Pharo images will consume 50%. > > With peak demand a single image can take 100% of the CPU core. > > > Concurrency can be handled by pharo forks. > > A Pharo forked process is still running under the vm single threaded > process... so it's more a matter of in-image blocking rather than > external access. > > > I am not web dev even by a remote imagination but my recent experience > with > > UFFI is that Pharo can go to insane speeds when it relies on C libraries > , > > especially performance orientated ones. Of course learning C and playing > > with C is a pain by itself but necessary evil if top performance is the > > goal. > > This is true. And non-blocking callbacks really alleviate the weight a > single threaded vm can support. > > However any CPU intensive request will block the process, and that > will happen with looping server like Pharo or an evented VM like > NodeJS. > > Unless you're targeting to an initial really high concurrent users > count, then you can scale up gradually. > > Esteban A. Maringolo > >
