r/algotrading • • 5d ago

Infrastructure [CPUs for Backtesting Efficiency]

Hi folks, am putting together my specs for a new home build PC. I am reading conflicting info RE the best CPU for the task. Top contenders are: A. AMD 9950X , B. AMD 9950X3D and C. Intel 270K Plus. Any recommendations?

6 Upvotes

23 comments sorted by

12

u/AngryFker 5d ago

If backtesting engine is implemented properly it is more I/O bound than CPU.

If backtesting engine is implemented poorly CPU pick is literally irrelevant and you will be able to sleep between runs regardless it is $649 CPU or $292.

2

u/Suitable-Name Algorithmic Trader 4d ago

Please what? If you're IO bound, you're pretty poorly optimized or you're writing masses of data you shouldn't write

Edit:

Are you writing every single trade over hundreds of threads or what do you do to be iO bound? Whatever, if you're iO bound, you're doing something massively wrong

1

u/AngryFker 3d ago

trade level data is hundreds of gigabytes of data for one ticker. now add just 10 tickers. that's way over a terabyte of data and you need to go through all of it to run backtest.

even if you aggregate to 1s timeframe thats still tens of gigabytes per ticker.

if you pack that into dumb format like feather or even worse - csv you will wait forever till it seeks back and forward with low cpu load. which usually is the case for many people. massively wrong to keep it so. also you can pre-calculate indicators per TF. no much reason to calc them again and again every run. which turns into another I/O load.

1

u/Suitable-Name Algorithmic Trader 3d ago edited 3d ago

Aggregation is something you can do once for the desired timeframes, so iO would be blocked once. Doesn't work for my system, but just in general.
So, probably depends on the system you're using. I'm using a genetic algorithm. So cache isn't really worth much, it most likely changes every generation. Specially if one indicator depends on another one.
But then, I made sure the generated strategies are 100% reproducible via a hash. So I never ever store all trading results. I store the final statistics and the strategy hash that created the strategy. If I want to see a result in detail, it's a few secs (not too far from live, even "few secs" sounds too large) to run the strategy again an persist the details.

I'll publish the whole framework here anyways. But between this text and the publishing, there will be probably like 2-3 more months. Since I'll publish it anyways, there isn't much to hide. If you're interested, have fun with this:
https://github.com/suitable-name/blub/tree/main/manual

Edit:

And yes, many people don't realize that it's often faster to have a CPU bound "issue" than a IO bound. Just compare what finishes faster. It doesn't get better with IO bound as the data gets larger... Sharding might help

Edit2:

Just to be clear, trade level would get compacted to 1m data for me. I'd keep it 1m and have the trades live flying in for stats over the last minute, but above that I'd just aggregate it to 1m timeframes. So I can act on 1 min aggregates + 1 min of live data

1

u/[deleted] 5d ago

[removed] — view removed comment

1

u/AutoModerator 5d ago

Your post was removed under Rule 2 (high-quality questions only).

Generic “which data vendor should I use?” posts usually lack the detail needed for meaningful discussion.

Commonly used market data providers:

  • Yfinance
  • Massive.com
  • Databento
  • FMP

If you repost, please include details such as:

  • asset classes and markets
  • symbols or venues
  • historical vs real-time
  • granularity and depth
  • licensing or redistribution needs
  • latency expectations
  • budget constraints

I am a bot, and this action was performed automatically. Please contact the moderators of this subreddit if you have any questions or concerns.

4

u/QuanTradin 5d ago

plain 9950X for most of this. the X3D cache only pays when your working set fits and you hammer it in a tight loop, and a lot of python backtests sit on one core anyway, so profile first before paying for cores you won't use.

4

u/Feriman22 4d ago

If your backtester is yours, I'd suggest to optimize your code instead.

I had a similiar issue, and at the beginning it was 10 mins one single test (5 years ago) and by time it reduced to a few sec / tests, and now it's crazy fast, ~5000 tests / sec with 8 years of data in mins frame. Same CPU.

1

u/Hot-Swing-6992 4d ago

Yes, that seems to be consistent advice here--make sure the code is optimized for the job. I have work to do there for sure. It's my code and in Python.

2

u/Feriman22 4d ago

Yeah, I also built in python, but the code in C runs 100 times faster.

2

u/QATSAlgo 5d ago

For the 15 years of tick data you mention, benchmark one representative run with the data cold, then again with it cached. Also compare one worker with several independent parameter runs. That separates disk/decompression time, per-core compute and memory-bandwidth contention. Those measurements will tell you more about the useful CPU features than a generic gaming benchmark.

1

u/Hot-Swing-6992 5d ago

Thanks, will do

2

u/Outrageous_Band9708 5d ago

x3d is great for gaming.

more cores more simultanious tests.

my most of it comes down to code.

dotnet trace hot methods and reduce non hardare accelerated datatypes, dont use linq in hot methods or decimal types

2

u/kwaant 5d ago

Honestly, for most backtesting the CPU choice matters less than how your code runs, but between those three I’d lean AMD.

The 9950X and 9950X3D both have 16 full-size cores, which is what you want if you’re running parameter sweeps or many backtests in parallel. Zen 5 also has full AVX-512, which numpy and numba can take advantage of. As far as I know Intel’s consumer chips still don’t have it.

The X3D’s extra cache helps when your working data fits in it, like tight event-driven loops over tick data or lots of lookups. Some backtests get a noticeable boost from that, others none at all. If the price gap is small I’d take the X3D. If it’s big, the regular 9950X is the better value.

The bigger wins are usually elsewhere though. If your backtester is a single-threaded Python loop, 15 of your 16 cores sit idle no matter which chip you buy, so parallelizing across runs or vectorizing will speed you up way more than the CPU upgrade. Also budget for RAM (64GB minimum, 128GB if you’re loading a lot of tick data) and a fast NVMe drive, because loading data is often the real bottleneck.

What’s your stack, Python, C++, something like NautilusTrader?

1

u/Hot-Swing-6992 4d ago

Thanks—really helpful. I have two workloads:
Python research/backtesting on futures tick data, including parameter sweeps and comparisons across strategies, bar sizes and exit rules.
Sierra Chart with custom C++/ACSIL studies for execution and trade-by-trade replay, particularly on volume bars.
The Sierra replay is a major bottleneck at present—typically around 100–150× speed. I’m auditing the studies and their calculation frequency to understand how much is code overhead versus platform/bar-building overhead.
So I’m interested in both single-thread performance for replay and multicore throughput for independent Python runs. This is a work machine; gaming performance isn’t a consideration.
With that mix, would you still lean toward the 9950X3D, or save the premium and go with the 9950X? Particularly interested if you’ve benchmarked the extra cache on a similar workload.

2

u/TiresomeStairway4 4d ago

Before choosing between the 9950X and the other CPUs, I'd profile the existing backtest and find out whether the bottleneck is calculation, memory access or reading tick data. Fast storage and enough RAM might matter more than another processor upgrade. I use Moon through its regular market interface but processing 15 years of tick data is a completely different workload.

2

u/MormonMoron 2d ago

The minisforum MS-A2 with the 9955hx seems like a steal at $799 barebones. We got a beelink gti14 about 2 years ago, but if buying again it would be the MS-A2

1

u/maciek024 5d ago

what are u backtesting so it matters that much? i suppose tick data?

2

u/Hot-Swing-6992 5d ago

Yes, 15yrs of tick data across 3 instruments right now

1

u/maciek024 4d ago

What instruments and engine? Nautilius, sth different or your own? I am really curious about the speed and how fast is that to iterate 15y of data

-1

u/YourMomIsNotMale 5d ago

Why dont you make a script that can reproduce a random chart? There are videos where they proof the charts are random, and you can generate your own chart. So you can test against that as well.