Quicker Optimizations in Trading Blox 4 (Web Link)

 

Previous Trading Blox versions executed stepped optimizations one test step at a time.  Versions 3.x and earlier executed a stepped optimization in a serial 1-step at a time sequence.  Serial step testing requires each test step to complete before the next step begins testing.  Processing optimization steps serially adds each step’s test time to the amount of time the optimization consumes to complete all test steps.

 

Version 4 changes how optimizations are executed by putting each test step into a thread.  Two threads are available when Trading Blox 4 is first installed, and more threads are available as an option.  Each thread can test 1-step at a time, and multiple threads can test other steps in that same test period.  With 2-threads always available in version 4 the time it will take to perform an optimization in version 3.x is about twice the amount of time it will take in version 4.x, assuming the same computer specifications and test suite.

 

Multiple threads can save time because each thread running a step test provides an independent area where calculations can be tested in parallel.  By running 2-threads at the same time the amount of time 2-threads requires compared to how a single thread test is nearly half the time of a the single thread time.

 

To put this in more concrete terms, the following table shows the amount of time that four different optimized test needed to run using 1-thread.  All four tests were executed on three different computers.  One computer used both the 32-Bit versions of Trading Blox 3.8.4, and Trading Blox 4.2.4.5.  Two computers supporting 64-Bit software tested both 32-Bit & 64-Bit version 3 and version 4.

 

Test duration details in this table represent how many steps were in the four tests and the number of seconds each test required.  All tests in this table were limited to 1-thread.  Versions prior to version 4.x were only able to use one thread tests, so that test limitation will be the baseline to show how additional threads help to reduce stepped test times.

 

Active Threads: ^Top

Being able to do an intensive processing required for good system development quickly is a significant enhancement in our trading platform.  It is significant because it allows us to see the results of more ideas in less time, and having a second thread provides us with a significant time reduction from what was possible in version 3.

 

In this next table 2-threads are used to perform the same test as shown above, however only data for version 4 is available because version 3 cannot support a second thread to improve performance, so we need to accept the single thread times are the best older versions will be able to provide.

 

Time saved versus the time needed for a 2-thread test in Trading Blox 4 versus the time it takes with 1-threads creates a significant time reduction across all three optimizations: ^Top

 

A second thread run in parallel for optimization test is a noticeable improvement, and it also asks the question of whether two threads are enough.  My answer is no, two threads are not enough.  It is no because our test ranged from 20 to 120 steps is a fairly small optimization test, but it is a practical size for careful data collection, and it shows how ineffectively we are using the computer’s capacity to get work done.

 

Computer’s capability should be a factor in making the decision about how many threads are enough; 2-threads on multi-core computers will only generate a low utilization.  It is low because a single core limits 2-threads to process the entire test.  This means all the other cores won’t be helping to reduce test times.

 

This next image shows the six-core computer running our 120-step test.  Windows Task Manager’s performance tab shows this thread limitation only being able to demonstrate an 18% utilization rate, leaving the other 82% of the computer’s capability at idle. ^Top

 

For reference Window’s Task Manager Performance Tab gives us a good estimation of the CPU Usage based on how much of the computer’s design capacity is available.

 

Each in these CPU Usage images the narrow vertical windows represents the number of threads the CPU was designed to handle at the same time.  In this case there are 6-physical CPU cores in the chip, with each core capable of managing two threads, for a total of 12-threads available by design.

 

In this next image of a quad-core CPU the utilization running the same test creates an estimate of 27% utilization leaving 73% of the CPU’s ability to sit at idle. ^Top

 

Being able to support 12-threads, or 8-threads for a quad-core CPU, doesn't mean all the cores should be loaded at 100% because that would interfere with the user’s need to do other things while the computer was running optimization test.  More threads up to the design limit will improve utilization as long as the operating system and the computer’s memory installation are capable of supporting all the threads. ^Top

 

In this next thread count test results table image a full range the same our 120-Step test using 1-thread up to 12-threads on each of the computers was executed on all three computers.  Test results details for the other steps lengths are available on request. ^Top

This table shows that 4-core computers performance improvement slows significantly when Trading Blox is sets to allow 6 of the possible 8 threads a quad-core CPU will support.  On a 6-core computer the number of thread time reduction differences slows when there are 8 to 9 threads operating in memory.  If these two thread to cores ratio is indicative, a Dual-Core CPU should easily handle 3-threads, and a single core CPU will be very busy with 2-threads.

 

Thread counts up to the thread-count design limit can give the best time, but if you try to do something else while a stepped simulation is executing the CPU will need to do some memory or thread swapping operations that will slow everything down.  Memory swapping doesn't have a significant time reduction impact on performance, but disk swapping will reduce performance significantly.

 

Having enough memory to keep the all the available threads in memory throughout the test step testing time is critical to being able to keep the CPU from swapping threads to disk like the results of the R9 computer demonstrates because of Windows XP Pro max working memory size limitation.  That memory limitations causes Windows XP Pro results to run slower than its less capable LT2 computer because XP is doing a lot of thread to memory swapping.

 

In the Trading Blox Roundtable Forum, there is a discussion that adds information to this topic:

Multicore CPUs

 

---