Welcome to NexusFi: the best trading community on the planet, with over 150,000 members Sign Up Now for Free
Genuine reviews from real traders, not fake reviews from stealth vendors
Quality education from leading professional traders
We are a friendly, helpful, and positive community
We do not tolerate rude behavior, trolling, or vendors advertising in posts
We are here to help, just let us know what you need
You'll need to register in order to view the content of the threads and start contributing to our community. It's free for basic access, or support us by becoming an Elite Member -- see if you qualify for a discount below.
-- Big Mike, Site Administrator
(If you already have an account, login at the top of the page)
You can Google HyperThreading and learn that in many situations disabling it will offer superior performance. I asked him to time the tests with HT on and HT off. Not to measure CPU difference between the two tests.
With HT enabled = 54 seconds
With HT disabled = 42 seconds, a 25% improvement in speed
This is the first time I loaded NinjaTrader in well over two years!
Video attached. Strategy attached.
This is on my Chicago dedicated trading box, a single X3450. I can't test on my i7 home workstation right now, too much going on to reboot and disable HT.
I never said it would not be slower. I said it would not cause lower CPU utilization.
See, HyperThreading shares ressources of teh CPU between two threads. CPU utilization says how busy the CPU is. A CPU waiting for the other thread to release resources is busy.
So, if the CPU is fully used, it may FINISH testing faster iwhtout hyper threading, but both scenario should show the CPU utilization in task manager clsoe to 100%. Task amnager does not show some magical "operations per second" it basicalyl show "time CPU is busy dealing with threads scheduled from the operating system" comapred to "time CPU core is not used by operating system". Again, whether or not "1 core with 1 thread" is faster in cycles per second than "1 core with 2 threads" is totally irrelvant for the CPU utilization graph. It simply does not know WHAT the cpu is busy with.
The fact that NInja does not manage to get the CPU up to 90% upward - regardless of how fast the backtests actually execute - show it is not scheduling effectively.
Inosfar your comments are irrelevant - they do not address my comment at all, instead talking about how many seconds it takes. Fact is, NinjaTrader does not schedule enough threads efficiently enough to keep all visible cores busy most of the time. I personalyl set 90% as the minimum for effective use (it is very hard to get 16+ threads properly organized in many applications) with 95% as "full use" limti (mostly because it is sometimes VERY hard to get the view to 100%).
Ninja should have no problem getting the CPU pretty much hit the top of the line (100%) most of the time. Backtesting is a perfectly scalable algorithm, every backtest is totally independant, only returning to the coordination system when it is finished to write the resutls back to the manager. As Ninja seems to build all price data in memory during a prep phase (disc IO is very low during backtests) this also can not be the limit.
I'll run the tests using the built-in MA Cross Over strategy tonight, w/o HT.
Great tip! Thanks! Can you point me to an example?
I'm new to NT7 and not familiar with using genetic or brute force exhaustive optimization in NT7. Are these options in the standard optimizer or do I need to use a custom optimizer?
As for HT On or Off, I've seen it go both ways. It depends too much on the activity, code, load, and systems architecture. One really needs to test it both ways...
BTW, great forum software! really like the features. Thanks! JB
Actualy attempt done today. It looks with the brute force optimizer it uses all cores, the genetic one is not that efficient in scheduling. Trying to play with parameters to see whether i can get it to execute more parallel optimizations. Non-Generic uses up the CPU nicely.
Btw., Hyper-Threading is likely less efficient - Ninja seems to use double a lot, and the one item that is not shared (i.e. a scarce resoruce) betwen the two threads is the FPU. hyper-Threading is pretty much designed for scenarios where math is not "the primary operation" of the threads. Need to look up details, though. What I wonder is though is that it is SLOWER.
