Read / Allocate Cores

[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.