bb.donnay-software.com

bwolfsohn wrote:re-read the message..

"the paper it WASN'T printed on"

Aahh... that's pretty clever

We invested a huge amount of time to handle processor utilization in a multicore-/terminal-server-environment with low resources. Several tables, semaphore files, registry values and other elements are involved to get a) a valid snapshot of what's going on and b) switch processors if needed. Every new process/thread started checks the situation and causes the app to switch if another core is/seems to be better. A watchdog process does this in the background aswell. Anyway, the number of users is NOT a/the only valid information in the context of processor utilization. There may be ten users just doing nothing and one who works with tons of modules at the same time. As the result, we get an o-kay situation even if 70 users are working on 20 processors, but sometimes, one kills all others. A better and modern compiler-side structure for this would be a huge step, since we can't tell every customer to provide 1 core and 1 GB of memory for every possible user.

Hi,
I mean, using multicore processing has good effect if processing many mathematical/logical processes every with high utilisation CPU. This is my case.
For example I need process 8 tasks, every need 10 minutes to processing.
In sequence processing full time will be 80minutes, on 8 cores in "multi" time will be only 10minutes.
This works good, need little more time than 10 minutes because some other operations was used.
If I have 24 cores on server, it would be a shame using only 1 CPU.

Solution will be some new and better RunShell(), with more parameters , for examples also with some channell to interchange informations between main app and modules, some own "DDE channell".
Also controlling limites of using RAM, handles,...
Maybe this exist, I do not know.
But everytime it will be only primitive replacement ...

Tom wrote:A better and modern compiler-side structure for this would be a huge step, since we can't tell every customer to provide 1 core and 1 GB of memory for every possible user.

Write a personal letter to Steffen. If enough customers speak up, maybe the priorities will change. For sure 'core' compiler improvements are much more difficult than creating new add-on functions and duplicating solutions that have already been solved by the 3P. But, this is exactly what we need Alaska Software for.