Read / Allocate Cores

[dISP]

Anyone know of commands in QB64 that:

1) Reads the number of available cores "cores"
2) Assigns or allocates an X number of cores to a program?

Regards - dsip

[mnrvovrfc]

Do you propose a project that would take advantage of it? Because QB64(PE) is a programming language for hobbyists, not for technology enthusiasts. Most people care about it running old QuickBASIC/QBasic code much faster and efficiently than the old M$ products, and they will be on single-core CPU's.

If you're really that worried about assigning cores to tasks, you should learn C++. It will also require a good threading library that will exclude pretty much the single- and dual-core CPU's. This is even more essential with ARM. Note that QB64(PE) emphasizes Windows perhaps too much so there is less attention paid to Linux and MacOS according to performance. It will work, and that's all that other people ask for.

There is a way to retrieve what is the CPU, and it might even report on the number of cores it has. However, allocating for threads is not that easy, and impossible without a library especially designed for it.

---

On some Linux OS could use "lscpu" command to get information about the CPU, including the number of cores.

But programming for it could be a headache as this article demonstrates:

https://unix.stackexchange.com/questions...-cpu-cores

Also Linux specific:

https://www.man7.org/linux/man-pages/man7/cpuset.7.html
https://www.man7.org/linux/man-pages/man...ity.2.html

There will be different ways to do it with Win32 API which might be portable to 64-bit.

[dISP]

OK well, thanks.  Most people will be on single core CPU's?   The i386 processor came about 40 years ago (see pic of its younger brother). Are you saying QB64 really is for 50 year or older code?  My impression was that QB64 wanted to make great effort to carry original Quick Basic platforms, but not that it was limiting itself just to that.  QB64 has many improvements that takes it well past QB4.5 for example. Not sure why you think I don't know how to program in C/C++.  Ive used that code for decades but, not as much Basic since it had gone unsupported.  However, I enjoy Basic which doesn't take complex "technology" programming to make bog down a CPU if only one core is available.

[MasterGy]

just a thought. One of my programs runs with 4 windows open. Different programs run in all 4. They share the burden. A shared 'random' file communicates with each other. Thus, all 4 windows run on separate threads, which are distributed by windows, and with very good performance. With this multi-window solution, it is possible to work on tasks in parallel at the same time.

[dISP]

That's an interesting idea because it would be pretty universal.  Different types of CPU's on the same OS would get the the same OS distribution. I had thought about using the chain command for the same idea but wasn't sure if I could get chains to run concurrently.

Still, it would be simpler if I could simply ask my single program to use multiple physical cores.  Even if there are no real qb64 commands, I have to believe their is a way for qb64 to ask MS windows how many cores I have and to use them.  But, I am not experienced with accessing MS windows from qb64.

https://qb64phoenix.com/qb64wiki/index.p..._Libraries

[mnrvovrfc]

OK well, thanks.  Most people will be on single core CPU's?

Some people keep computers around only to run Windows98 or WindowsXP because they hate that much M$'s changes starting with Vista and even more what has happened with Windows10 in particular. Heck, I'd do it too but unfortunately the hard disk died and the monitor became damaged beyond repair, of an 18-year-old so far Toshiba Satellite M45 with the excellent Intel Celeron-M CPU and upgraded to 1.5GiB RAM. Those people have favorite 32-bit software and don't trust the later versions of Windows to handle it for them. Moreover, some people have those computers to be able to run 16-bit software at all because Windows10 won't do it. Either that or they install a Linux distro with DOSBOX to run 16-bit programs.

Otherwise a lot of people (like me) find computers too freakin' expensive which have four cores and 16GB RAM. Even laptops are commanding prices which are significant after the inflation caused by COVID-19 and other world events. A computer is not acceptable which was used for a short time by somebody else, because it's not known what was done wiht it and to it, unless the price is marked down by 50% or more of what it was sold to that person. Having a CPU with four cores is a commodity, and even that's not enough for some of the most demanding projects such as compiling the Linux kernel in less than a few hours.

Now with rumors that M$ wants to put a chip into computers so that only Windows would run on them, to guard against whoever tries to replace it with Linux, it's even more unacceptable how expensive so-called budget portable computers are getting.

There are plenty of people over 50 years old who only want the thing to work, no matter what is the equipment they employ. One might have a 20-year-old computer with a single-core CPU because it's what he/she could afford. There are a lot of such people in Africa and Asia, maybe I'm sounding ignorant here. They're not going to care about the latest technology if they cannot reach it and if they cannot buy it. If the computer can run QBasic then that's what the user will stick with. If the computer could use QB64 with one core of the CPU and a limited amount of RAM, he/she would take it. That's why some people are thrilled with the additional advantages with performance that QB64 gives that 16-bit QuickBASIC and QBasic couldn't, and then they have to deal with consequences such as having to log out of a multiuser system to regain control of the computer.

We have a handful of Macintosh users around here. They could be as demanding as the course of ApCo's history. Equipment gets ancient faster in the Macintosh world than in the Windows world, only because that company completely controls it in the best way they think would generate more profits for them. And people are willing to pay for it, which is the saddest thing. However they are leaving even more people behind who want to stick around a bit longer. It seems to be a race for the most toys, to always have the latest, fastest and baddest to impress the friends and neighbors.

[DSMan195276]

That's an interesting idea because it would be pretty universal.  Different types of CPU's on the same OS would get the the same OS distribution. I had thought about using the chain command for the same idea but wasn't sure if I could get chains to run concurrently.

Still, it would be simpler if I could simply ask my single program to use multiple physical cores.  Even if there are no real qb64 commands, I have to believe their is a way for qb64 to ask MS windows how many cores I have and to use them.  But, I am not experienced with accessing MS windows from qb64.

https://qb64phoenix.com/qb64wiki/index.p..._Libraries

It's not possible in QB64, at least not in any reliable fashion, the best you can do is have multiple completely separate programs that run at the same time and communicate.

Like was mentioned, what you really want is threading support - you would create multiple threads in your program and then Windows/Linux/etc. will schedule them to run on whatever cores are available to the system. However while it's technically possible to create new threads via some

Declare Library

calls if you know the right magic, it won't work for very long because QB64 is not design for this and none of the functionality is thread-safe. Meaning, you cannot have two threads in your program running QB64 code at the same time, the various internal structures will eventually end-up corrupted.

[mnrvovrfc]

Like was mentioned, what you really want is threading support - you would create multiple threads in your program and then Windows/Linux/etc. will schedule them to run on whatever cores are available to the system. However while it's technically possible to create new threads via some

Declare Library

calls if you know the right magic, it won't work for very long because QB64 is not design for this and none of the functionality is thread-safe. Meaning, you cannot have two threads in your program running QB64 code at the same time, (otherwise) the various internal structures will eventually end up corrupted.

Take it from me, looking at the changelogs of Psycle and Sunvox and how many years of progress for those two music-creation programs. Sadly Psycle is no longer being developed and was for Windows only, the developers had a difficult time moving it to 64-bit and Windows7 and later. Have to add a couple of libraries no longer shipped with Windows10+ but for Arch Linux and descendants only it could run with Wine, but some functionality is missing which cannot consider it for everyday use.

Sunvox is still being developed and has to be offered even for portable devices. Back when I could only run Ubuntu Studio v12.04 "Precise Pangolin", and a short time after all the OS versions for Sunvox were set free except for iOS (portable Macintosh), the developer of Sunvox had great trouble getting right the "mutex lock and unlock". Such that one time I was running it, then I needed to open the HTML help file in Firefox and then that program locked up the system tightly. Had to do a cold reboot to get out of it.

Thank goodness Sunvox's developer received some help so the program is quite stable these days. Data sharing which is thread-safe is desireable, because it has security benefits.

Although yet another modular music program I don't use any longer for MacOS and Windows, called Plogue Bidule, has this thing called "MP Assign". A group of modules could theoretically be assigned to a CPU core within that program. However that is just a suggestion to the operating system. The program is CPU intensive anyway with serious duty, and one of the buggiest programs ever created which uses or had used OpenGL. It was just a weak selling point.

32-bit brought us multitasking and operating system with GUI. 64-bit brought up multiple processors in a single CPU. Then 128-bit in the distant future could feature multiple CPU's which have multiple cores on the same computer like a laptop, hopefully with the ability to assign "jobs" to cores or CPU's. It doesn't hurt to dream.

[mnrvovrfc]

disp why did you go then to the other forum to ask for help? You could have continued talking about it here.

Why are you trying to use QB64(PE) on a business computer? Intel Xeon 12-cores seems to be an FCC Class A device. :/

I'm sorry for sounding like tattle-tale here but "Xeon" run a bell and thus I felt I had to look it up.

https://en.wikipedia.org/wiki/Xeon

Starts with (boldface from me): "Xeon (/ˈziːɒn/ ZEE-on) is a brand of x86 microprocessors designed, manufactured, and marketed by Intel, targeted at the non-consumer workstation, server, and embedded system markets."

[dISP]

LOL - I am not on a "business computer".   I have a 16 year old Digitalstorm PC that came with an Intel i7-975 CPU.  I replaced the CPU with a Xeon X5690 12 logical core processor.  These are processors that were used in servers, yes, but I bought it on ebay.  You see, Xeon X5690 is about the fastest CPU that can be put into my old ASUS Premium P6X58D Mobo.  I then Overclocked the Xeon processor to 4.4 Ghz.  I have liquid cooling and used very good paste, so I could push it to a 27% OC level.

What you might have wanted to do is look up the Xeon X5690 in Overclock forums and you would see it was commonly used on ASUS MOBOs for speed.  Server CPU's work in many Mobo's of household PC's.  You have to assure the match up of course.