Allow additional "Number of Threads"

Let us know your likes and dislikes, or what you'd like to see next. We listen!

Allow additional "Number of Threads"

Postby Jaded » Wed Mar 09, 2011 6:43 pm

I've thought about this for a while, and I noticed that when processing on my 8 core machine, that out of the 8 cores, none of them ever get anywhere near 100% utilized during a single run. Would it be possible to open up the setting for Number of Threads to allow us to pick a maximum of (2 * Number of Cores Available in Windows)?

If not, how about some flag we can set in the .ini file to force a certain number of threads, so I can at least do some timed benchmarks and see if adding additional threads will have a benefit for large sectors.

Thanks!
Jaded
 
Posts: 151
Joined: Mon May 14, 2007 6:49 pm

Re: Allow additional "Number of Threads"

Postby Overload » Thu Mar 10, 2011 9:18 am

Multi-core processing in StrataSearch works by using multiple threads to evaluate the trades of multiple symbols at a time. Because of this, you will only see benefits with searches that use larger sectors. There will be absolutely no benefit in having 8 threads if you are running against a single symbol. But if you are running against the Russell 2000 or All Securities, there is an enormous benefit between using 8 threads and just 1.

Nevertheless, once all of the symbols have been evaluated, there is still a significant step required to pull all those trades together into a portfolio and organize and post the results. Out of necessity, this phase of the search is a single-threaded process, and there isn't much that can be done about that.

Opening up additional threads would probably not provide much benefit. If you are running a relatively small search without an excessive amount of data, the prices will be stored in memory and the 8 threads will already have a very high utilization. However, if you have an extremely large search, prices are likely being retrieved directly from the disk drive rather than being stored in memory. And the threads in that case are being slowed by their disk access more than anything else. Having even more threads accessing the disk at the same time will not increase the processor utilization.

I have considered this as well, and one option I've considered would be to allow the Processor to run multiple tasks at once rather than simply splitting the symbol processing into multiple threads. The problem, however, is that each process would require a great deal more memory, and many users are already bumping up against memory limitations. So this isn't really something that can be done without an expansion to 64-bit first.

The one suggestion I have, and I actually use this quite frequently myself, is to run multiple instances of StrataSearch on your computer. You can do this by entering the Setups > System Settings menu, General tab, and checking the box titled "Launch Data Folder Selection at Startup" box. You'll then be able to run multiple instances of StrataSearch, each time starting with a different Data Folder. Managing the different instances takes a little getting used to, but for now I believe it is the best way to squeeze more processing out of your multiple cores.

Pete
Overload
 
Posts: 2246
Joined: Wed Nov 30, 2005 12:14 pm

Re: Allow additional "Number of Threads"

Postby mandelmus » Fri Dec 30, 2011 2:05 am

I would vote for you pushing all the processing to the graphics card (i.e., an nvidia CUDA version ... http://www.nvidia.com/object/cuda_home_new.html) ... much, much more powerful than the archaic CPU processing power these days :) ... there may come a day when everything, including CPUs, plug into GPUs
mandelmus
 
Posts: 141
Joined: Fri Dec 23, 2011 1:51 pm

Re: Allow additional "Number of Threads"

Postby Overload » Fri Dec 30, 2011 1:47 pm

It is true that there is processing power to be had from the graphics card. However, the card manufacturers have not standardized that interface, and I'd be hesitant to lock the best StrataSearch processing only to those using Nvidia hardware. But... we'll continue to evaluate this and see where things go in the future.

Pete
Overload
 
Posts: 2246
Joined: Wed Nov 30, 2005 12:14 pm

Re: Allow additional "Number of Threads"

Postby mandelmus » Fri Dec 30, 2011 8:41 pm

Overload wrote:It is true that there is processing power to be had from the graphics card. However, the card manufacturers have not standardized that interface, and I'd be hesitant to lock the best StrataSearch processing only to those using Nvidia hardware. But... we'll continue to evaluate this and see where things go in the future.
Pete

i was hoping that you would consider adding the gpu route "in-addition to" the cpu route rather than as a replacement
mandelmus
 
Posts: 141
Joined: Fri Dec 23, 2011 1:51 pm

Re: Allow additional "Number of Threads"

Postby Dacamic » Sun Jan 01, 2012 3:13 pm

I'm curious about the nature of research being performed by those using extensive processing power.

StrataSearch ran for years on my single processor, 2.7 Mhz machine. My son, bless his heart, recently built a much more powerful machine for me. I certainly enjoy my work being done more quickly; however, I've not yet found any practical ideas for expanding the scope of my tests.

I'd appreciate learning about the applications people have -- or would like to have -- for uber-speed in StrataSearch.
Steve
Dacamic
 
Posts: 457
Joined: Wed Nov 30, 2005 12:40 pm

Re: Allow additional "Number of Threads"

Postby mandelmus » Mon Jan 02, 2012 11:04 pm

Dacamic wrote:I'm curious about the nature of research being performed by those using extensive processing power.

StrataSearch ran for years on my single processor, 2.7 Mhz machine. My son, bless his heart, recently built a much more powerful machine for me. I certainly enjoy my work being done more quickly; however, I've not yet found any practical ideas for expanding the scope of my tests.

I'd appreciate learning about the applications people have -- or would like to have -- for uber-speed in StrataSearch.


well, if you've got systems that have taken you "years" to develop, I'm sure they are pretty good systems ... in that case, speed might not be as important to you ... but, if you are just starting out with stratasearch, like me, i've got to try to catch up to you ... one way to do this is to speed up the processing in order to learn the software and figure out what works and what doesn't
mandelmus
 
Posts: 141
Joined: Fri Dec 23, 2011 1:51 pm

Re: Allow additional "Number of Threads"

Postby Overload » Tue Jan 03, 2012 10:05 am

I'd appreciate learning about the applications people have -- or would like to have -- for uber-speed in StrataSearch.

While the speed of a faster computer is helpful when I just want to get results quicker, where I think a fast computer is critical is Dynamic Strategies. When you want to rotate your strategies on a weekly basis throughout your entire evaluation period, or even optimize your parameters on a weekly basis, it takes forever to do that on a little XP machine. But on a screaming Intel Core i7, it just flies. You can literally do in a few hours what would take a week to do on an old single-core Pentium.

Not everyone likes to use Dynamic Strategies, but it's definitely one of the areas where you just can't get enough speed.

Pete
Overload
 
Posts: 2246
Joined: Wed Nov 30, 2005 12:14 pm

Re: Allow additional "Number of Threads"

Postby Dacamic » Fri Jan 06, 2012 4:04 pm

mandelmus wrote: well, if you've got systems that have taken you "years" to develop, I'm sure they are pretty good systems ... in that case, speed might not be as important to you ... but, if you are just starting out with stratasearch, like me, i've got to try to catch up to you ... one way to do this is to speed up the processing in order to learn the software and figure out what works and what doesn't

The length of time it took to develop my active systems varied from a few days to a couple months. The difference in time resulted mostly from the number of symbols in my evaluations. StrataSearch's functionality has expanded over the years, too, which helped reduce development time.

The impact that speed might have on the learning curve would most likely be favorable, assuming that a new user is trying to figure out the AutoSearch-based functions (including OneClick and Dynamic Strategies). The bigger issue often seems to be that paradigms are slow to shift when using brute-force searches; nonetheless, this is an advantage of faster processing that I'd not thought of.

Overload wrote:While the speed of a faster computer is helpful when I just want to get results quicker, where I think a fast computer is critical is Dynamic Strategies. When you want to rotate your strategies on a weekly basis throughout your entire evaluation period, or even optimize your parameters on a weekly basis, it takes forever to do that on a little XP machine. But on a screaming Intel Core i7, it just flies. You can literally do in a few hours what would take a week to do on an old single-core Pentium.

Not everyone likes to use Dynamic Strategies, but it's definitely one of the areas where you just can't get enough speed.

Yeah, I can certainly see the benefit of speed on Dynamic Strategies, because of its ability to test combinations against multiple evaluation periods. It's probably time for me to dust off my brain, then give that feature another try.
Steve
Dacamic
 
Posts: 457
Joined: Wed Nov 30, 2005 12:40 pm

Re: Allow additional "Number of Threads"

Postby Jaded » Sat Jan 12, 2013 5:42 pm

Have you thought about this any more? I would love to see the following:

1. x64 version of StrataSearch
2. Ability for multiple copies of StrataSearch running to be able to share a single prices directory ( right now I am symlinking to achieve this )
3. Be able to choose actual # of CPU threads * 2 ( run some tests with this, maybe against 2000+ sector ? )
4. Be able to leverage GPU on both ATI and Nvidia cards. If Folding@Home can do it with both of these, I think it can be done :)
5. Cache more, so reads/writes do not happen as often. I don't notice much read activity, but there sure is plenty of write activity going on while a Oneclick is running. Maybe only write changes to disk every 30/60 seconds or so, or when necessary ( pausing/holding/stopping a queue item )
6. A built-in standardized hardware performance benchmark that can be used on any system. This would make it easy to test things out, compare PC hardware, etc.

I'd be willing to alpha/beta test any of the above. I have a higher-powered ATI card and an i7-3930k ( 12 CPU threads ) running @ 4.4ghz so it would be a great candidate for testing/benchmarking/etc.

Hopefully this revives this topic and breathes some new life into the program. I love it already and am a huge fan, but would love to see it taken farther.
Jaded
 
Posts: 151
Joined: Mon May 14, 2007 6:49 pm

Re: Allow additional "Number of Threads"

Postby Overload » Sun Jan 13, 2013 10:49 am

Thanks for all the tips. They are on the list.

Pete
Overload
 
Posts: 2246
Joined: Wed Nov 30, 2005 12:14 pm

Re: Allow additional "Number of Threads"

Postby Jaded » Mon Nov 11, 2013 12:47 pm

Adding on to my wishlist: Allow for OneClick systems to span to the maximum length that you have pricing available. I think the limit right now is 25 years, but I'd like to test some systems against $SPX and $NYA over a longer period of time for major trend moves ( recessions ) and it's not possible right now with the limit in place.
Jaded
 
Posts: 151
Joined: Mon May 14, 2007 6:49 pm

Re: Allow additional "Number of Threads"

Postby Overload » Mon Nov 11, 2013 4:52 pm

I agree there are cases where an expanded test beyond 25 years would be helpful. While one can certainly divide the data into 2 periods and test them independently, a single test would be nice. I will put this on the list and see if there's an easy way to do that, without causing a larger risk of RAM overflows.

Pete
Overload
 
Posts: 2246
Joined: Wed Nov 30, 2005 12:14 pm


Return to Comments and Suggestions

cron