Jud

Thanks, I'm going to look at those. However, I don't need one that runs until I stop it. I need one that verifies that the program is still running. I need to update it periodically. After I posted the message, I realized that a simple thing to do would be to have a label with just '*' and make it visible or not visible every X times through the outer loop. I had a strange problem the other day. I had an i7 running 14 threads of a big computation. It was going to take 15-16 days. It stopped running at 92% finished. None of the CPUs were executing the calculations, but strangely, everything in the Windows user interface still worked. It didn't bomb out or lock up. The calculation had been stopped for about 2 days when I realized it. I've never had that happen before. And nine other i7s running the same program on different data haven't had the same problem. This is to check to see if the program is still executing the calculations.

Is there a VCL component that does something like the Windows spinner? I looked through the VCLs and didn't see one. And which group is it under (System, additional, Win, etc)? Added: Actually, I need something sort of like the ProgressGuage, where I update it periodically to show that a loop is still executing. I need to update it every few seconds to show that it is still executing, rather than a percentage finished.

I used GExperrs with many versions of Delphi, through 12.2, and got to depending on it. I upgraded to 12.3 yesterday, and GExperts won't install into it. Then I realized that it was probably because of the IDE changes.

Will there be a version of GExperts for version 12.3? I realize that this may be harder than usual for this version, due to the change in the IDE.

Thanks, it works well. You guys are the greatest!

I have 20 TMemos, named memo1 ... memo20. I have an integer which indicates which memo is to be written to. Is there a direct way to write to the desired memo, as opposed to a large, ugly case statement?

Thanks. I don't think that it must be called in the main thread.

So do I need to put all of the stuff where the tasks are called and WaitForAll into a thread, or just WaitForAll? I've tried the memo updates with and without TThread.Synchronize.

I have a multitasking program that has been running for weeks, but now I'm having problems adding WaitForAll to do some things when all tasks have been finished. First, some minor problems when I add WaitForAll: the main form is no longer responsive - I can't drag it or close it. Mainly though, are problems with updating the screen. Each task has a memo that it updates occasionally. Also, there are labels for the elapsed time and estimated remaining time. These work without WaitForAll but when WaitForAll is added, the program locks up if it tries to write to a memo or change the caption of a label. I know that these aren't thread safe, but they work if WaitForAll isn't in the program. Is there an easy way to get these to work?

Update I've spent a good deal of time experimenting with this. There are two points: 1. The people that said to look at performance instead of CPU utilization were right. 2. Modern CPUs are different from older ones. I've done optimizations for multitasking for more than 10 years. Years ago I did it with Sandy Bridge, Ivy Bridge, and Haswell i7s (32GB of DDR3) and Sandy Bridge and Ivy Bridge Xeons (128GB of DDR3) - all with four hyperthreaded cores. On those, generally the higher the CPU utilization, the more throughput. The exception is when memory bandwidth starts to be the limit - then it is usually better to be running seven tasks instead of eight (in my tests). But now I'm doing it on 12th- and 14th-generation i7s (64GB and 128HB of DDR5) and Kaby Lake Xeons (512GB of DDR4). The Kaby Lake Xeon has four hyperthreaded cores and it behaves like the aformentioned CPUs. The new i7s with eight hyperthreaded cores behave differently. When running 16 threads, the CPU was utilized under 50%. I tried running more threads - that utilized more of the CPU, percentage wise, but didn't help performance. I tried 20 threads, and that had the same performance as 16 threads. I tried 24 threads, and that had 3% more performance than 16. I tried 28 threads and that had 3% less performance than 16 threads. These all utilized a higher percentage of the CPU. So you really aren't gaining much, if anything, by running more than 16 threads, in my test, and you are using more electricity. In fact, 15 threads performs better than 16.

Well, I used to be able to get to 100% usage, now I can't get 50%.

I was allowing it to use all cores. But it doesn't seem to be putting my program on E-cores To be sure, I set the affinity to use only P-cores. Neither way gives the performance I expected.