What CPU? Single vs Multi core in real life (no games)? Future?

[KaneTW]

I like my large amount of cores (TR 1950X) simply because something compute-intensive can run in the background without hindering other operations at all.

[Berni]

..... I need a nvme m.2 disk which is stupid fast compared to SATA.

Once you're "nvmed" , you will never look back. 

Mhm NVME SSDs really fly.

Tho you have to be careful about motherboard support for those. Only after buying one i found out that my motherboard only has PCIe 2.0 2x brought to the M.2 slot while another newer board in a different machine has PCIe 3.0 4x on the M.2 slot. Makes a significant difference in speed.(Both are faster than SATA tho in MB/s and IOPS)

Im personally running a i7 4790K...

So am I. Unless the magic smoke gets in the air it won't be replaced anytime soon.

Now, for that stupid ass dual core i7 in that damn laptop...

Same here, it does everything i need.

I've written some multi threaded programs, nothing super complicated, but even a simple enough program has a lot of things to take into consideration so it gets tricky.

Not all programs in nature can be written to fully take advantage of multithreading, it really depends what kind of task the program does, and if it involves work loads that can be split up and worked on independently without relying on each other.   So for example if you are brute forcing something, you could split it up in multiple threads.  Thread 1 tries "password", thread 2 tries "password2" etc so you can try multiple passwords at once.   So now you can try say, 8 passwords at once instead of doing them serially.

One project I always think would be cool to take on is a MMO/minecraft type game but I'd want the world physics to be real time, like water flow, plants growing, NPCs, any AI stuff etc would constantly be working.  Say someone builds a dam and punches a hole then the water will flow even when they arn't logged in.  So imagine all these mechanics working, now I'd want to be able to make this multithreaded so that each physics is basically a "task" that is loaded off and then the result returns. (modified blocks etc).  This would definitly pose a challenge but if done right would make for a very scallable application.  Ideally, each thread does not even need to reside on the same physical machine, you can have it act as a cluster.  That's when things get really fun.    All this would be the easy part compared to the actual game client though, I know nothing about graphical application design. 

By the way minecraft servers actually multithread pretty well. Java is still not the best choice for any high performance number crunching, but this is at least a reasonably parallelable workload. Each player tends to be handled by its own thread, world update(world ticks, redstone ticks, block updates etc) runs in its own thread and world generation can use multiple threads(each thread works on its own chunk). The reason why unused chunks get unloaded back to disk is mostly to save RAM since most servers wont have hundreds of GBs of it.

[rdl]

The Sunny Cove series seems like massive overkill for most needs. I'd be happy to have just the 4 or 6 Series updated with the Spectre/Meltdown bugs fixed.

[apis]

Race conditions, deadlocks, spooky glitches that are impossible to reproduce and debug -- such is the domain of multi-threaded computing.

Think of how buggy single-threaded code is.  Now imagine those same developers writing multi-threaded code

Many of the tools, even something as fundamental as the programming languages themselves, were developed for single threaded programming only. Java for example have abysmal support for multi-threaded programming, you might as well not even try. Others languages have much better support. On top of that, most programmers have never learned how to do multithreaded programming properly.

[Berni]

Yep not all languages do multi threaded as nicely.

Also the code in general has to be written with multithreading in mind. Taking an old codebase and making it multithreaded is a massive task that requires a lot of rewriting in most cases. This has to be done very carefully since its easy to forget a reference to something in another thread. Touching something in another thread while thinking it belogns to your thread can have a wide range of consequences. Sometimes it works just fine and there are no problems. Other times it will crash something really badly and you will look for it. But in a lot of cases it breaks something just after about 2 weeks of use and only in certain use cases, this makes it very hard to debug and track down.

Code written from the ground up to be multithreaded and solve a problem that is pretty parallel in nature is really easy in modern languages. Everything else is multithreading hell.

[Zucca]

I like my large amount of cores (TR 1950X) simply because something compute-intensive can run in the background without hindering other operations at all.

So you are telling me that Windows 10 is so intelligent to distribuite the workload across the cores?

[Kilrah]

Uh... yes, like any MP OS that's existed in 2 decades? 

[wraper]

I like my large amount of cores (TR 1950X) simply because something compute-intensive can run in the background without hindering other operations at all.

So you are telling me that Windows 10 is so intelligent to distribuite the workload across the cores?

Yes it is smart enough to not place high load from different processes onto single core.

[Zucca]

see there is always something to learn.  I never double checked it or observed it.

So a pure thoretical example: I have 8 core. I have Adobe open and Solidworks at the same time.
Windows will use the first 4 for Adobe and the other 4 for Solidworks? So the Adobe Encoding is not slowed down by the others programs running and vice versa?

If yes, I want the 2950x... and yes, now I understand what a workstation is.

[Red Squirrel]

Yes multiple separate processes will spread each other to different cores.  So multi core is still good for multi tasking even with single threaded apps.  Not sure what logic the OS uses to choose which core but I imagine there's different algorithms, like picking one with least load.

[wraper]

So a pure thoretical example: I have 8 core. I have Adobe open and Solidworks at the same time.
Windows will use the first 4 for Adobe and the other 4 for Solidworks? So the Adobe Encoding is not slowed down by the others programs running and vice versa?

If yes, I want the 2950x...

If something can load all of the cores, of course it will affect other processes. But generally it's quite hard to put a lot of load on all of them. You might see slight reduction of performance but most likely you won't notice unless doing benchmark.

[Zucca]

That's why I pay that stupid ISP every month... Now I know, thanks to you all. I can go in peace now.

[Kilrah]

Yup, the more cores you have the harder it is to use all of them really fully and "fill all the inutilisation voids" so as a result light tasks will more easily have something to sneak themselves into even with multiple heavy loads.

[nctnico]

SSD is kinda mandatory for a fast PC nowadays. When it comes to a CPU I'd go for the largest number of GHz, biggest cache and most memory bandwidth. For my workstation PC I choose to have an Intel Xeon with ECC memory. A Xeon has about twice the memory bandwidth compared to a core i7. Many cores is only relevant for machines which run many virtual machines (lots of parallel processes).

[Zucca]

SSD is kinda mandatory for a fast PC nowadays

I would say NVME SSD.

[hayatepilot]

Most CAD programms can only run on one or two cores. So faster single core speed is the dominant factor for performance.

There are rumors that the next AMD Ryzen generation (7nm process) will have a boost clock of over 5GHz and that the consumer grade chips will have up to 16 cores.
I will definitely wait for the official reveal (CES 2019) and third party benchmarks but man this sounds like some incredible little chips.

https://www.pcbuildersclub.com/wp-content/uploads/2018/12/Ryzen-3000-Specs-Leak.png?ssl=1

Greetings

[filssavi]

The biggest problem with multi threading is very far from being the workloads, there are far bigger issues

For the most used languages multi threading is a second class citizen at best, and a bolt on botch job at worst

This is especially true for c++ and java

The education has probably the largest fault since the inherently serial mentality is forced onto new programmers and by the time multithreading is introduced it is far to late and also not much time is dedicated to it

Splitting a monolithic program (such as most cad programs are now or were 5 years ago) inmultiple threads is much much more difficult and time consuming than a rewrite but for commercial reasons that is out of question

[SparkyFX]

So a pure thoretical example: I have 8 core. I have Adobe open and Solidworks at the same time.
Windows will use the first 4 for Adobe and the other 4 for Solidworks? So the Adobe Encoding is not slowed down by the others programs running and vice versa?

An application can fork threads or processes as many as it wants (usually doesn´t make sense to open more than 1 per core/hyperthread, speedwise), whenever it wants. The OS does the association which core will be loaded (maybe based on current load indication). Adobe might check that you have an 8 core processor and spawn 7 additional threads for whatever task it is, Solidworks might do the same -> no gain, the operating system can not judge how much load this thread will create in the future.

As long as you can´t limit the amount of threads somewhere in the settings... you either waste potential performance or lose performance. Windows only lets you bind whole applications to certain cores... check the task manager.

But it is relatively uncommon to do heavy lifting in two applications concurrently on a desktop machine. In the ideal case the user does the right choice which application(s) run on which hardware to begin with and does not expect unrealistic performance.

There are many applications in which the work can be split without requiring the exchange of data between threads, where just the results need to be combined (that´s still a critical part where the application needs to be written thread-safe). But when threads depend on data from each other to continue, it starts to become complicated.

Imho, get as many cores as you can...

[T3sl4co1l]

Many of the tools, even something as fundamental as the programming languages themselves, were developed for single threaded programming only. Java for example have abysmal support for multi-threaded programming, you might as well not even try. Others languages have much better support. On top of that, most programmers have never learned how to do multithreaded programming properly.

  I was originally taught threads on Java.

Thread t = new MyThread();
t.run();

I don't know about the performance stats though.  I never used it for more than toy purposes (I did at least do one with a creator-consumer model, but it was still simple enough to run on practically anything and the context switching probably cost more execution time, not that I could tell).

All the sync/lock/mutex action is at the programmer's behest, but I don't see how you could otherwise encapsulate that, without making a much less general system, or making a confusing number of classes that use each combination of protection.

Tim

[T3sl4co1l]

see there is always something to learn.  I never double checked it or observed it.

So a pure thoretical example: I have 8 core. I have Adobe open and Solidworks at the same time.
Windows will use the first 4 for Adobe and the other 4 for Solidworks? So the Adobe Encoding is not slowed down by the others programs running and vice versa?

If yes, I want the 2950x... and yes, now I understand what a workstation is.

Y'never punched CTRL+SHIFT+ESC before?  (Task Manager)

Windows normally shifts tasks around in some kind of sequence, or maybe it's not sequential at all, but in any case, all threads tend to be shared among all cores, sooner or later.

These days, idle cores are shut down for power saving purposes, but sleep/wake takes microseconds so it can be done seamlessly as threads are scheduled.

Programs can be locked to a group of cores (right-click a Process, Set Affinity...) if you like, in which case only those will be used.  This can save on cache latency for critical applications, but mostly isn't necessary.

AFAIK, this has been around in some form or another, since preemptive multitasking was rolled out to PCs in the 90s.  Multi-core machines were very rare for the first decade or so, but Windows NT I think has always supported it (and consumer Windowses since 98 or 2000?).

Tim

[Karel]

..., compiling code etc are not multithreaded.

Never heard of "make -jn"? (where n is the number of threads to use)

Except when you compile a tiny program with just one file, it makes a big difference in speed.
Personally, I prefer more cores. It speeds things up a lot when compiling.

[rsjsouza]

Programs can be locked to a group of cores (right-click a Process, Set Affinity...) if you like, in which case only those will be used.  This can save on cache latency for critical applications, but mostly isn't necessary.

AFAIK, this has been around in some form or another, since preemptive multitasking was rolled out to PCs in the 90s.  Multi-core machines were very rare for the first decade or so, but Windows NT I think has always supported it (and consumer Windowses since 98 or 2000?).

In my experience this exists since NT3.1 and I used it at large in NT4 running on my Dual Pentium II 300MHz back in 1997.

[nctnico]

Most things that electronics engineers do like PCB tools, compiling code etc are not multithreaded.

Compiling code is definitely multi-threaded. Make has a specific option to have parallel compilation tasks and it speeds up compilation of large projects considerably (if you have an OS which doesn't suck at task switching). C/C++ source lends itself very well to parallel compilation because each file is compiled into an object file first before all the object files are linked into an executable. Interestingly compiling large C/C++ programs don't really need a fast hard drive. I did some benchmarking compiling several hundreds of MB worth of code (embedded Linux environment) and it didn't matter at all whether I used an SSD or a slow (but silent) hard drive.

[Berni]

Yes C/C++ compilers are pretty good at large projects when it can use each core to compile one file. The compilers for HDL languages on FPGAs are not so great at it. Sure they go a little bit faster with more cores but its nowhere near the boost that C gets.

I am guessing you didn't see the improvement from a SSD due to file caching in windows. Ever since Windows 7 this is enabled by default. This feature makes use of unused RAM areas to hold on to files that got recently read from the drive. Next time the same file needs to be accessed its simply pulled from RAM, making it even faster than a SSD. The effect of this can be seen quite clearly if you have any programs that take a while to start (Photoshop, Corel etc..) installed on a mechanical HDD. The first time you run it after a fresh boot you get the usual load time, but if you close it and run it again it will likely start in 1/3rd the time. The more RAM you have the more files can be kept in there for longer so it improves overall system performance.

[rstofer]

I was working for one of the largest semiconductor companies when I got into a conversation with one of the VPs.  He warned me "Never bet against technology!".

You can't "future proof" a workstation because you can't predict the future.  All you can do is drive a stake in the ground, buy a machine, and figure you're going to replace it in a few years.

I built a machine a year ago with an I7-7700 with SSD.  It runs well, Vivado execution time is acceptable (the free version only runs on 4 cores) and I'm happy enough.  I'm sure a multi-chip Xeon would be faster but, again, I would be limited to 4 cores.

I can get make/gcc to use multiple cores for parallel compilation and that might be cool but the whole idea behind  make is that I only compile changed files and that is usually just one.  Sometimes 2...  Unless I do a make clean all, I'm not going to get any advantage out of parallel compilation.

Large computation jobs probably belong on the GPUs.  I don't have any applications that would gain an advantage from that idea so I have never tried it.  If I was doing Finite Element Analysis or Method of Residuals for a large number of nodes, yes, the GPUs would be the way to go.  But I'm not...