bb.donnay-software.com

Roger,

We are using the dc_setcpu on a few clients that have a lot of users, over 100, no ADS,, and terminal servers.
We have two clients with terminal servers and ADS that want to split the cpu use on the terminal server for the menu opening,
So, our main app and all dll files,etc are on t:\oiswin.ads (two different identical servers)
The ads and the data files are on z:\oiswin, their data server
We have an ini file that directs the files to the z-drive and our oiswin folder.

We can add the dc_setcpu to load on our main app but it updates the z:\oiswin\setcpu.smp with the next cpu each time, but does not appear to do anything on the terminal server, unsure if it is possible. It is updating the main server file, so appears it uses the cpu later on the files(?). The app shows on their task manager as cpu 0 each time we open one on the terminal server

Think we may have discussed this 5-6 years ago, but not sure. They are moving servers and asking us,, showing copies of emails from 2013-2017.

thanks

Fred
Omni

hi,

there is no Way that Xbase++ use different CPU Core within same Instance of a Application.
Only Way is to start different Instance of a Application and assign each App to different CPU Core.

Interesting. We have one user that has been using the dc_setcpu() for many years, which is obviously Rogers.
The setcpu.smp file shows changing the next cpu each time. Not a heavy hardware guy, I look at their task manager and it shows
all cpu's have activity, if that is really accurate. When I go to look at the detail of each app our app is showing cpu 0 for all the users.
On another client, did the same check on an exe that runs on task scheduler, not using anything special, no setcpu. The task manager detail showing it changing cpu's contantly, which is really weird. About every couple of seconds it changes from 1 to 2 to 3,etc.

So am I to understand the the dc_setcpu is not something that actually resets anything. This is going back 10 or so years, and each user was supposed to use the next assigned cpu, 1-4, back to 1-4,etc. They each log in separately.

Thanks for any input.

hi,

Auge_Ohr wrote: ↑Tue Oct 01, 2024 8:53 pm there is no Way that Xbase++ use different CPU Core within same Instance of a Application.

what i mean is that same instance can´t use more than 1 CPU Core.

you can switch CPU Core using "next" Core but only one Core can be active, so a Thread can only use same CPU Core as Main Thread is using.

Hi,
It is possible to use multiple CPUs in a single Xbase++ app instance, but that job have to be done in C using Xbase++ C-API. You have to create your own multiple threads in C and run your thread processes in C. Each thread can be assigned a different CPU and they all run concurrently. In this way your multiple CPU job in C is executed independently of the basic Xbase++ thread(s), and Xbase++ cannot control it and forbid your multiple CPU use in C.

I tested this scenario and it works fine. I have a demo program to post here if you want to try it and convince yourself.

hi,

SlavkoDam wrote: ↑Sat Oct 05, 2024 10:22 am I tested this scenario and it works fine. I have a demo program to post here if you want to try it and convince yourself.

i remember early Version of Xbase++ was able to use more than 1 x CPU, but ALASKA have cancel it.
i do not remember why it was canceled, but i remember ALASKA say it is NOT SAFE to use.
so ALASKA don´t support it, you can try it at your own risk

Hi,

I remember ALASKA say it is NOT SAFE to use. So ALASKA don´t support it, you can try it at your own risk.

Alaska have their reasons to say it is not safe, it is their matter and I don't care for that. Multi CPU is an option in Windows for decades and I don't think that Microsoft would allow that if it is not safe. Yes, there are some stuff you have to set in order that to work, but I have solved that and it works FINE and very SAFE, as I said. It doesn't interfere with Xbase++ code in any way, since it is independent of it, and doesn't depend of ALASKA support.

Sometimes you have to take some risk if you want to do more. I will certainly use Windows multi CPU in my massive data processing apps, because I want more of them and I know how to achieve that. Multi CPU is a great option that should be used, otherwise your apps don't have a true benefits of your CPU.

Hi Slavko

Kind upload a demo of your solution for our benefits. Quite interested

Thanks

Joe

We also started working on our own solution for that, but we didn't find a way to keep the benefit of Alaska's simple way to threads (using the thread object, exchanging workspaces between threads, using global variables everywhere, handing default DBE sessions to threads, using only one application interface a.s.o.). Slavko, if you have found a solution for all that, I would be willing to pay for it.

Besides, if you want, you may just activate multiple CPUs for your application using the task manager. But you will end up with an incredible slow or simply not running application (depending on the complexity).

Second that.

After years I just assign xpp .exe to random CPU on multi-core systems and be done with it (learned about ~ 2005 on Citrix system).

Currently I just offload the big and intensive work to either (if possible) db server and/or app server (rest interface to python). Sometimes it is not even worth the hassle and just do it in code as there is too much overhead of parelising in external process or server.

Even batch generation of thousands of billing invoices with QR payment codes is simple set of multiple batches running concurrently as spawned external processes in C# ...

So it is interesting to see how a single-core tied language can be expanded.

So please Slavko. Willing to pay with large portion of čevapi and large beer too.

unixkd wrote: ↑Mon Oct 07, 2024 1:36 am Kind upload a demo of your solution for our benefits. Quite interested