kevinkdog 

I would say what you programmed and backtested is not the same strategy as what you ran as actual. I don't know what is different, but there is probably an explanation. I'm sure one of the Ninja experts here would be happy to take a look.

so that's the thing - the strategy builder on nt generates the code for a strategy that can be uploaded to a chart or even applied to the strategy analyzer. unfortunately it actually is precisely the same code

shade9281 

so that's the thing - the strategy builder on nt generates the code for a strategy that can be uploaded to a chart or even applied to the strategy analyzer. unfortunately it actually is precisely the same code

So then I would look at the settings on the chart/analyzer/replay. Something BIG must be different.

Your best bet is to post it (take out any stuff you want secret), and let people try to duplicate and debug.

Fu510n 

https://forum.ninjatrader.com/forum/ninjatrader-8/platform-technical-support-aa/1128700-does-nt8-use-all-cores-threads-when-backtesting ...there are SO many ways to address this but you might want to start by "throwing hardware/cores at it". AMD Ryzen ThreadRipper CPUs can be purchased with 64/128 threads but those aren't cheap - if you're tied to cloud-based only, you can throw a lot of CPU horsepower there as well. Neither option is "cheap" but you didn't divulge exactly what you're trying to optimize (length/size of data, # parameters being optimized, etc.).

I thought that some years ago, and splashed a chunk of change on a 44C/88T dual xeon workstation, with 1TB of DDR4-2400Mhz ECC RAM and a 4TB PCIE NVME Raid array, for my personal use with NT8. Sadly I found that no matter what I did (I'm not a coder, just a technically aware trader that works with a team of pro C/C# coders), NT8 still only works about 6 or 7 of those 44 cores at anywhere near capacity (typically about 20% of available total cpu time) . So chucking cores at it doesn't really work well. I know the issues with using large amounts (eg. >5yrs) of tick data across multiple symbols. Its not easy to cut down the run-time. Its even harder if you have to use NT8 as your backtest/optimisation platform. My firm built its own platform at a cost of several £MM, largely to address these issues. So IMHO unless you're working towards a large, scalable automated system with its own OMS/EMS platform, you're better off developing an NT8 algo that has to be re-tuned every few weeks/months, rather than seeking to build a self-tuning algo using years of tick data, "chunking" it, running each chunk in parallel and then stitching it back together. For NT8 I suggest using a box with high performance characteristics on single-core benchmarks, e.g. an i9-13900HX with a generous helping of the fastest DDR5 RAM or similar. You do still benefit from multiple cores, but NT8's multi-threading in backtest/optimisation work is poor, partly due to its architecture, and partly due to the "tyranny of numbers" issue when working with time-series. At least this is my experience with it over the last 6 years or so.