CPU Xeon vs i7

Hi All!

It's that time to buy another computer! I really want to take advantage of the speed of the new SSDs and for my optimization work, a faster CPU.

I'm considering Xeon ES-2920 or better vs a high end i7-4960. Both are 6 core, but the Xeon has dual processors although a slower clock speed.

I've researched that MultiCharts optimization can fully utilize the multi physical core machines.

Anyone have experience with these or similar CPUs for optimization and graphics?

Thanks,
S

I too would also like to know if a xeon setup is better than an i7 setup. Xeon setups can be quiet expensive compared to an i7 setup so I wonder if the performance gain (if any) is worth it for the extra cost.

I'm semi tempted to upgrade my current setup or considering waiting for the 8 core haswell-e to come out third quarter this year. At the same time the x99 chipset and ddr4 will arrive.

t-rader
I don't know about that new stuff you are mentioning.
What sort of performance improvement are you looking for?

btw too bad no one has any advice on this topic, I'd thought it would be more lively.

t-rader
I don't know about that new stuff you are mentioning.
What sort of performance improvement are you looking for?
btw too bad no one has any advice on this topic, I'd thought it would be more lively.

You already know the basics: ie. real core, not virtual core, is what makes optimization fast. What else do you need to know that can add value to your quest? For optimization (not trading), this is a very simple process: brute power rules -- there is no room for negotiation. ie lots of cores, multitudes of megahertz, loads of gigabytes; There is no "fast" that is ever too fast.

If money is no object, then buy the fastest machine.
If money is a consideration, then buy the most expensive one you can afford.

Here is a chart you can use to compare CPU power:
http://www.cpubenchmark.net/cpu_list.php

You already know the basics: ie. real core, not virtual core, is what makes optimization fast. What else do you need to know that can add value to your quest? For optimization (not trading), this is a very simple process: brute power rules -- there is no room for negotiation. ie lots of cores, multitudes of megahertz, loads of gigabytes; There is no "fast" that is ever too fast.

If money is no object, then buy the fastest machine.
If money is a consideration, then buy the most expensive one you can afford.

Here is a chart you can use to compare CPU power:
http://www.cpubenchmark.net/cpu_list.php

If money is a consideration, but you still want quick backtesting, you could also go with an IaaS provider which only charges you for the hours you use an instance for backtesting.

That has the benefit of not having to buy an expensive, high-end pc that might only use its full CPU/RAM for a few hours each day. Furthermore, you can then still use your desktop pc for other MultiCharts work.

However, a drawback of Amazon's EC2 and Windows Azure is that they use non-dedicated, virtualised hardware (not as quick and consistent, but easy). Other providers, such as Rackspace and ProfitBricks, do offer dedicated hardware and plenty of computing power (requires a little more maintenance on your part). This last one, for example, offers up to 240 GB RAM and 62 CPU cores - if that's not quick enough, I don't know what is. :]

Bear in mind that backtesting uses only one core. (faster megahertz helps here)
Optimization can utilize multi-core. (more cores helps here)

Bear in mind that backtesting uses only one core. (faster megahertz helps here)
Optimization can utilize multi-core. (more cores helps here)

Backtesting only uses one core? This seems like quite a flaw, especially when all CPUs these days are multi core. Wouldn't I backtesting be faster if it used all cores?

Backtesting only uses one core? This seems like quite a flaw, especially when all CPUs these days are multi core. Wouldn't I backtesting be faster if it used all cores?

According to current implementation a script calculation cannot be separated for multiple threads. 1 strategy is calculated by 1 core. Since backtesting = 1 strategy calculation, it uses only 1 core; while the optimization = multiple strategy calculations, so it utilizes multiple cores.

TJ:

thanks for sending the link. The i7 compares favorably to the Xeon units. Given the savings, I'm really inclined to go that way now.

Backtesting only uses one core? This seems like quite a flaw, especially when all CPUs these days are multi core. Wouldn't I backtesting be faster if it used all cores?

According to current implementation a script calculation cannot be separated for multiple threads. 1 strategy is calculated by 1 core. Since backtesting = 1 strategy calculation, it uses only 1 core; while the optimization = multiple strategy calculations, so it utilizes multiple cores.

Is this something that will be changed later to improve performance of script calculation and backtesting?

Backtesting only uses one core? This seems like quite a flaw, especially when all CPUs these days are multi core. Wouldn't I backtesting be faster if it used all cores?

Before you jump in with both feet and declare it a flaw...
I would take a step back to try to understand the "how" and "why".

This has been explained before, and I will try it one more time, with an illustration: This is not a flaw, this is not a limitation, this is not a MultiCharts issue, but simply, this is how computer works.

I will use a simple strategy as illustration.
(Indicator works the same way, but nobody ever complained about indicators.)

This sample strategy has 2 moving averages: If the fast MA crosses above the slow MA, a BUY order is triggered.

In a single core, the computer will execute the strategy in a step-by-step order:

step #1: calculate slow MA
step #2: calculate fast MA
step #3: compare slow MA with fast MA
step #4: if fast MA crosses above to slow MA, send buy order. (in an indicator, this would be a plot).

Note that a strategy is a sequential process. Each step is dependent of the previous one...
You cannot start step #3 before step #1 and #2 are completed,
and you cannot perform step #4 before step #3 is completed.

Multi-Core concurrent processing can be useful ONLY if you could farm out this strategy to different cores. In this example, only step #1 and step #2 can be processed at the same time. Core #3 and core #4 must stand at idle and wait for their turns.

You might say, if MultiCharts splits the MA processes into 2 cores, it will save 25% processing time!

Let me explain further.
Multiple charts can be allocated to multiple cores for processing.
A script calculation within a study cannot be separated for multiple threads. But just for discussion's sake, let's say if we could split the calculations, the process would probably look like this:

step #1: Core #1 breaks up the strategy for multi-tasking
step #2: Core #1 sends slow MA formula to core #2 for processing
step #3: core #2 receives the slow MA formula, checks parity
step #4: core #2 sends core #1 acknowledgement for receipt
step #5: core #2 ---> calculates slow MA
step #6: core #2 ---> calculates result parity
step #7: core #2 sends slow MA result with parity back to Core #1
step #8: Core #1 stops everything to receive the slow MA result from core #2
step #9: Core #1 verifies the slow MA integrity (ie nothing went wrong during transmission between the cores)
step #10: Core #1 sends acknowledge to core #2 that it received the data ok
step #11: Core #1 somehow splices the slow MA result back into the strategy
... repeat the same for fast MA... then continue...

As you can see, the CPU spent more time in housekeeping than in actual calculation.
10 steps for housekeeping and 1 step to calculate the slow MA.
Conclusion: There is no real time saving. It might even slow down the strategy.


ps. The above is just a fantasy illustration, in reality it is not possible to break up a strategy (or indicator) for multi-core processing in this fashion.

Backtesting only uses one core? This seems like quite a flaw, especially when all CPUs these days are multi core. Wouldn't I backtesting be faster if it used all cores?

Before you jump in with both feet and declare it a flaw...
I would take a step back to try to understand the "how" and "why".

I hadn't quite jumped in with both feet, just had two toes in the water

Thank you TJ for the in depth explanation