Amibroker Dream Machine specs requested!


#1

Hi, every few years I build a new computer from scratch and I’d like to know what some of you would spec for the fastest calculations and best performance of Amibroker. My budget would be in the $1500 range for motherboard, ram, processor, and power supply. Everything else I can scavenge off other systems. Also which operating system would you recommend?
Thanks!
Tony


Performance after Windows Meltdown and Spectre patches
#2

hi Tony
i think there is a topic about recommentation. you may have a look here


#3

Wait for new Coffee Lake i7 8700K (apparently till 5th October 2017) this should be great performer at nice price point. This plus plenty of RAM and SSD disk (>500MB/sec) is all you really need.


#4

Tomasz, as soon as AMD Ryzens appeared I thought that those are the processors which should show their full potential with AmiBroker. 8 cores, 16 threads should theoretically offer unmatched crunching power below $300-400. But I have noticed that you don’t seem to be Ryzen’s enthusiast :wink: Is there a reason for that? Have you (or anybody else) been testing them with AmiBroker?

I’m asking because (for now) Ryzens are much cheaper than Intel processors. Maybe they are not ideal for gamers, but they seemed the perfect match for multi-threading AmiBroker :wink:

… and if 8 cores is not enough - Threadrippers are available with 16 cores and 32 threads :wink:


#5

I don’t have Ryzen here. There are some conflicting opinions with regards to floating point unit performance on Ryzen. It has different architecture than Intel i7. Some say it is slower some say it is faster. The thing is that it is not really the problem which one is “theoreticallly” faster, but whenever current C/C++ compilers produce machine code that runs faster on given architecture. Given the fact that i7 is here for years and Ryzen is new, there are no compilers that build Ryzen-optimized code.


#6

Tomasz - thank you for your opinion. I understand that in general Ryzens may be a little slower (when you i.e. compare 8 core Ryzen to 8 core Intel) and C/C++ compiler issue is very important, but they are 2 or even 3 times cheaper than their Intel counterparts, so they still seem very attractive. For the same money everyone can have twice as many physical cores - it should probably still give Ryzen an advantage. Probably …

… but of course the new Coffee Lake i7 8700K seems interesting :wink:

Regards


#7

Hi All,

I would like to build the fastest spec machine for Amibroker. Can you kindly confirm that an 8-core (or more) machine will in fact be faster than a quad-core for backtesting? Also, does Amibroker support GPU acceleration? I’d like to build a powerful machine, but no point doing anything beyond what Amibroker can make use of. Thanks for your advice!


#8

@ezekiel Professional Edition of AB has a limit of 32 threads per single Analysis window - so it would have no problem with utilising all available cores and threads in your case.

You will find answers to your questions in these threads:

The most recent and comprehensive TJ article from KB (a must-read for serious users): http://www.amibroker.com/kb/2017/10/06/limits-of-multithreading/

https://www.amibroker.com/guide/h_multithreading.html
https://www.amibroker.com/guide/x_performance.html
https://www.amibroker.com/guide/versions.html
https://groups.yahoo.com/neo/groups/amibroker/conversations/topics/197249

Here you can find TJ information about utilising GPU:
https://groups.yahoo.com/neo/groups/amibroker/conversations/topics/193644


#9

From: https://groups.yahoo.com/neo/groups/amibroker/conversations/topics/173568

Does Amibroker/AFL make use of GPU instructions available in the newer generation of Graphics cards? (November 2012)

No AmiBroker does not use GPU. Why? The answer is on slide 9 of the presentation, “NVidia GPU architecture”. --> 64KB of RAM shared memory. Although entire card can have gigabyte of RAM, there is only 64KB shared memory per processing core. Such architecture is good for Monte Carlo simulations but not for end-user programmable array processing language that requires large shared memory.

Best regards - Tomasz Janeczko

From: https://groups.yahoo.com/neo/groups/amibroker/conversations/topics/190752

Intel Phi processors

With regards to Phi processor: as with ANY other processor AmiBroker would run on multiple cores/processors in multiple threads as described here http://www.amibroker.com/guide/h_multithreading.html Currently upto 32 threads will be used per single Analysis window. Whenever your algorithm scales or not depends on your code.

If your code is memory bound (i.e. relies on RAM bandwidth) then it would not scale well because RAM is single shared resource that multiple cores compete to access and each core is much faster than RAM. Go give you an idea here are timings of on-die CPU caches (i7 920 processor)
Level 1 cache = 52408 MB/s
Level 2 cache = 30722 MB/s
Level 3 cache = 24521 MB/s
RAM = 11879 MB/s

As you can see, Level 1 cache on the processor die which works with exactly same speed as the executing core is 5 times faster than system RAM. It means that single core may saturate your system RAM. If that is happening, adding multiple threads won’t help.

However, if your algorithm uses lots of CPU computation (things like trigonometric functions, divison, logarithms, roots, heavy sorting of small arrays that fit into CPU caches) and relatively small amount of data shuffling then it would scale linearly.

For example this formula scales linearly to 32 threads because it does huge amount of sorting of small tables to calculate percentile for each bar separately. So on 32-core/processor system it would run approx 32 faster than on single core.

for( i = 0; i < 100; i++ ) x = Percentile( C, 100, 10 ); // lots of sorting of small tables

Such algorithms are relatively infrequent. In many cases the limiting factor is RAM bandwidth.

Best regards - Tomasz Janeczko


#10

One month ago I bought the newest i7 8700K processor and it works great for me. I got it running even on 5.2GHz but for everyday use 4.7GHz provides great blend of performance & silence & cost. You don’t need any special GPU for AmiBroker.


#11

@Tomasz Could you share more details of your rig (motherboard, RAM, cooler)?


#12

Hi Tomasz,

I have just ordered my i7-8700K. Can you please elaborate on performance & silence & cost?
Is the CPU running reasonably silent without overclocking?
I mainly want to know if the i7-8700K is quite in “normal operations”?

From the google search on this subject I found the following;
"In an IDLE state, a PC (motherboard / processor / memory / SSD/ GTX 1080) consumes roughly 50 Watts. This number depends and will vary per motherboard (added ICs / controllers / wifi / bluetooth) and PSU (efficiency). Keep in mind that we measure the ENTIRE PC, not just the processor’s power consumption. Your average PC can differ from our numbers if you add optical drives, HDDs, soundcards etc. "

Kind Regards
Richard


#13

I’ve got Cryorig H7 cooler which is pretty inexpensive and BeQuiet PurePower supply and the computer is totally silent in normal desktop work. It only gets barely audible when all cores are under 100% load. I mean totally silent - the hand watch ticking from the distance of 1 meter is louder than the computer.


#14

Thank you Tomasz.
This is god news. Although, my system is not exactly the same but, it looks like system noise in not an issue in normal desktop operations.

Kind Regards
Richard


#15

I7 8700K really seems to be the best choice for now, but I wonder if the below issue will have any real impact on its performance in case of AmiBroker:

Intel patches critical processor security bug, but the fix imposes a 35% performance hit!

… According to HotHardWare, Spengler said an Intel Core i7-3770S GPU will take a 34 percent performance hit, while the new Intel Core i7-6700 will run 29 percent slower


#16

I don’t know yet. Will see when Microsoft releases a patch. Since this CPU issue seems to affect only going to kernel, it won’t affect number crunching speed at all as it is all done in user land.
There are many possible software solutions to this issue and I hope Intel + Microsoft would be able to implement it without sacrificing that much speed. The impact depends on architecture of OS. Linux has monolithic kernel and this causes big impact. Windows NT (the base of all current windowses) has microkernel-like/hybrid design that is likely to be less affected.


#17

Google posted details on this CPU vulnerability and as I understand it:

  1. Vulnerability requires malware program to be running locally on the machine
  2. It allows to read contents of entire physical memory (RAM) including kernel pages
  3. Does not seem to allow to do any write to kernel memory

As I see it, main risk is for servers, especially ‘cloud’ or ‘VPS’ services that share single computer among number of clients where those clients can run any software on their own. Virtualized environment that was supposed to protect them against each other running on same physical hardware can be circumvented using the vulnerability in question, so other VPS data can be read (but not written) by an attacker.

On personal PC, generally there is one user who controls what is run. So excluding any potential security holes in browsers (apparently patched already), the vulnerability in question is not as easy to exploit on personal PC. It should be well noted that running any malware on your PC puts your personal data to risk, because executable running on your PC in most cases has access to all files anyway, without need to do kernel tricks.


#18

As more and more details surface, I'd like to add an extra comment:
This is typical cache timing attack. This kind of vulnerability is known from some time but wasn't exploited because it is difficult to exploit in practice. Some recent "improvements" to browsers allowed access from javascript to "SharedArrayBuffer" and precise timing and this was the reason why it was possible to write a "proof of concept" for those attacks from Javascript. But now browser vendors (at least Mozilla and Microsoft) removed ability to measure time more precisely than 20 microseconds from Javascript and removed SharedArrayBuffer and that effectively blocks this vector of the attack (i.e. Javascript running in browser). So the only way to get exposed to this vulnerability is running actual malware executable exploiting that. But if malware is run on local machine it can do much more than just reading the memory anyway.