> The CPU utilization dropped two - three times during the optimization. > Every time JBT updates results in the table. My experience is that > java's GUI is much faster when kept to OS default decorations but I do > not know if this is the case. I can try to disable the GUI override > tomorrow.
The temporary drop in CPU utilization is normal. What happens is that the threads are given a chunk of strategies to process, and when one thread is done with its work, it waits for the other threads to complete. The reason for waiting is that the "divide & conquer" optimizer needs the results of the entire chunk before it can decide what the next chunk is. However, that's not the case for the brute force optimizer, so there is room for improvement here. When a thread is done, it can be given the next set of strategies immediately. So, with the brute force optimizer, CPU can be fully utilized. Regarding the GUI overhead, I found it insignificant. What you can do is to comment out the call to showResults() in the execute() method of OptimizerRunner. That way, no intermediate results are sent to the optimization results table, and only final set of results is displayed. In my tests, it didn't make much of a difference in the total times. The other thing to do is to experiment with the CHUNK_SIZE setting in BruteForceOptimizerRunner. This *does* affect the improvement ratio. If it's set too low, each thread will be given too little work to do, so thread will die quickly and new worker threads will be created frequently, resulting in the overhead of thread creation. On the other hand, if it's set too high, you may run out of memory because there will be too many strategies optimized at the same time. Additionally, if it's set too high, it's more likely that temporary drops in CPU utilization will occur, as I explained above. For my dual core system, the CHUNK_SIZE somewhere between 400 and 500 seems to result in the best ratios. Maybe it makes more sense to set it as something like 200 times the number of processors. Ultimately, there is always some overhead with multi-threading. I'd say if the multi-threaded optimizer is 3.75 times faster on a quad core, it's good enough. We can try to squeeze a few more percentage points, but it's probably not worth the effort. However, the 3.1 ratio that HF got seems a little low, so I'd like to get to the bottom of it. --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "JBookTrader" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/jbooktrader?hl=en -~----------~----~----~----~------~----~------~--~---
