... 8 cores. Looks like there is something wrong with the thread scheduling (it blocks for extended periods).
Interesting, I run with 4 cores - newer seen. Any details?
I am using the VAC compiler from time to time. It comes with an IDE called "Integrated Workframe" (IWF).
The IWF implements a couple of WPS classes, in particular one to display all "parts" of the project in a WPS folder.
You can open different views of that WPS folder much like any other WPS folder: icon, tree, details view.
A "part" is normally a file in an ordinary filesystem, however, the IWF can be extended and generalizes the concept of a "part". That said, I wrote an extension to display the contents of ZIP files within the WPS folder where the "directory" is the ZIP file and the "files" are the archive files within that ZIP file.
Now, I have linked 3 ZIP files into one project and the overall number of archive files is > 9000. Unfortunately, the IWF is not very performant and in addition, it starts a new thread for each view of the WPS folder (you can concurrently open multiple views of the same WPS folder, again, much like an ordinary WPS folder). I used the "unzip" DLL interface to query and list the archive files within the ZIP file and maybe, that also eats up quite some processing power as the "unzip" DLL interface will be called for as many views as there are open (even though, of course, the ZIP content is the very same).
What I now observe is this: the time to display all "parts" of a WPS view is already pretty slow with the OS/2 kernel (takes more than 90 seconds to display all "parts") but it becomes VERY slow with the OS/4 kernel in place where it takes much longer (3 minutes or more). From the way those IWF WPS classes work, I'd think that this has either something to do with threading or with some blocking semaphores waiting for something.
What I can see is that OS/4 activates about all kernels on my 8 core machine when that view refresh happens whereas the OS/2 kernel will typically only use 3 kernels with the rest idling (I guess ACPI.PSD takes care of that but I am of course using OS4APIC.PSD+ACPI4.BPD when I am using the OS/4 kernel).
What I additionally see with the TOP tool is that with the OS/2 kernel, one process will shortly monopolize the processing power and that will then quickly move to the next process monopolizing the processing power and so on and so forth (so, the load is not only concentrated on PMSHELL.EXE under whose context the WPS classes are executing).
With the OS/4 kernel, one process will monopolize the processing power for a much longer time.
