Can SSDR utilize more than 4 processors in the Intel I7 CPU?

Jerry W4UK

One day in the Win7 task manager (ctl+alt+del), I discovered the "performance" tab showed 8 processors working in the "quad I7" HP workstation Z220 PC I recently bought.

I googled and found that Intel actually made some with 6 and 8 processors. Intel's announcement is:  http://newsroom.intel.com/community/intel_newsroom/blog/2014/08/29/intel-unleashes-its-first-8-core-... .
But they are rare,  according to PC magazine: http://www.pcmag.com/article2/0,2817,2404674,00.asp .

Anybody else have more than 4 in an I7? Would SSDR/Ham programs utilize the extras?

Jerry W4UK

Kent Hufford

My i7 is running 8 cores. Don't normally notice anything special. Except once and awhile when installing a complex piece of software, before the first part is done, the next part asks to start installation with another core. Sometimes gets confused.

My 6500 seems to run the same on this pc, as it does on my Winbook TW800.

Larry Loen WO7R

Processor counts are a funny beast these days.  There is a notion of a "virtual" processor. 

What often happens is that two "physical processors" pair up.  These pairs of processors have their own registers, but they share a memory cache.  Modern processors, it turns out, spend so much time waiting for memory operations that it actually makes sense for them to share the memory access logic.  So, is that one CPU or two?  Usually, it is counted as two.

In another design, firmware (often called a "hypervisor"), using some criteria or other, quickly loads and unloads processor state, enabling the illusion of more processors on the machine than are actually present.  This can also allow things like Windows running inside of a Mac.  The Windows "machine" within may have a dim or partial awareness that it's CPU count is virtual.

Either or both designs can be present; the hypervisor approach has become very popular.

All of these designs create a lot of confusion when measuring CPU utilization these days and it makes the processor count itself kind of hard to figure.  But, these kinds of designs have been more or less standard for at least a decade now.

You sometimes see the word "core" used as an attempt to distinguish full processors from some kind of virtualized one.

See also here:  http://www.tomshardware.com/forum/289186-28-processors

Bill Axelrod

My Acer I7 computer shows eight (8) cores running.

73...   Bill K3WA

Neal_K3NC

You are seeing hyperthreads which looks like a core to Windows but is a CPU trick that makes 1 core look like 2. So, you are probably looking a a 4 processsor CPU which is running 8 hyperthreaded 'cores'.

http://en.wikipedia.org/wiki/Hyper-threading

Jim Hawkins

Running i7 6 Cores.

K2CM

On my iPad, are they considered to be "Apple Cores"?

Jerry W4UK

Hard to argue that 2x hyperthreading or "virtual processors" would display 6 cores in a "quad-core" machine. I tend to think Jim actually has 6 physical cores, especially since Intel is/was actually making both 6 and 8 (physical) core I7s. See my original post for Intel's link to the press release.

I think some/all of us actually have as many cores as the Task Mgr displays.

Does anybody ONLY see 4 cpus with their  I7? That would be another clue.

Jerry W4UK

KY6LA_Howard

I am seeing 12 CPU in task manager - so 6 cores x 2 hyperthreading = 12

Joe, KQ1Q

W4UK: "Anybody else have more than 4 in an I7? Would SSDR/Ham programs utilize the extras?"

As already explained, you're likely just seeing the hyperthreaded cores on an i7. It is probably not a native 8-core CPU. Hyperthreading is an optimization which allows each core to concurrently execute multiple threads -- under some circumstances. This is possible since the instruction stream often contains events that would stall a core while it waits on something. Hyperthreading preserves the CPU core state and allows it to rapidly switch to another thread. In non-Intel parlance it's called SMT (Simultaneous Multi Threading).

Hyperthreading can be envisioned as running two automotive assembly lines past a single string of workers. When one worker is waiting on something, he just turns around and works on the other line behind him. He has to keep track of what he was doing on each line when he pivots back and forth, but in theory it wrings more production out of otherwise wasted time.

The benefit of SMT/Hyperthreading is the additional CPU hardware is modest vs adding another entire core (or worker in the above example), yet gives some of the benefit of an additional core. The actual practical benefit varies widely from slightly negative to about 40% positive. On Mac OS X I've tested Lightroom 5 and Final Cut Pro X for import and export with hyperthreading on and off using the utility CPUSetter utility. In that case LR5 had zero benefit but FCP X was about 30% faster with HT on.

On my Win7 PC with an i7-875K @ 4Ghz, 64-bit Geekbench 3 does about 9,000 with HT off, vs about 11,000 with HT on. Likewise exporting an H.264 high-def video in Premiere Pro CS6, the difference is 28 sec (HT off) vs 24 sec (HT on), roughly 15% difference improvement. 

I haven't tested whether SmartSDR exhibits noticeable perf. improvements from hyperthreading, but I doubt it since it's not very CPU-bound.

Hyperthreading support is not an app decision. Apps are either multithreaded or not, and if multithreaded, a hyperthreaded CPU will automatically be used. The only requirement for concurrent execution is multiple threads must be in a runnable state, not sleeping or pended on a synchronization event, cache miss, memory or I/O.

While no specific API calls or programming methods (beyond having multiple threads) are needed to use hyperthreading, for programmers working in C++ at a low level, there are some methods and compiler directives which can improve utilization of hyperthreading. Also at compile time, code generation options can be used which improve performance on a hyperthreaded CPU. There is much detailed info in this Intel white paper: http://cache-www.intel.com/cd/00/00/01/77/17705_htt_user_guide.pdf

On many Windows PCs you can optionally disable hyperthreading in the BIOS. This facilitates running tests with HT on and off.

Although Intel CPUs use 2-way SMT/Hyperthreading, other CPUs such as the IBM Power 8 use up to 8-way SMT. That potentially allows each core to run up to 8 concurrent threads but there's a diminishing law of returns so the benefit drops off with each additional SMT virtual core:  http://www.extremetech.com/extreme/191453-ibm-unveils-new-power8-servers-in-last-gasp-effort-to-batt...

Neal_K3NC

You can turn hyperthreading off in your BIOS. Generally, only i7 and i7-based Xeon CPUs implement hyperthreading, its one of the major (maybe the only) real difference between in like-speed i5 and i7. So a dual core i5 will show 2 processors and a dual core i7 with hyperthreading activated in the BIOS will show 4 cores. 

Thesome  2011-socket i7s and Xeon processors can have 6 or mote cores and if hyperthreading is turned off, it will indeed show up as 6 processors.

Not sure why this is questionable, guess the links we have provided didn't do a good job of explaining it?

BTW,  only later I7 intel-based Macs use hyperthreading so on older Macs a quad core i7 will show as 4 processors. Not sure why. There have been some questions about whether hyperthreading in heavy CPU usage situations might cause more performance problems than it solves. AMD processors do not play around with hyperthreading, when they give you 8 cores, it shows as 8 processors in Windows.

Jerry W4UK

Thanks, Howard. I guess I have a "lowly" Quad processor after all, as many here indicated. You have one of the rare ones referred to in Intel's press release. Wonder if anybody here has a genuine 8 physical core CPU, which would show 16 in the task manager...

Jerry W4UK

Walt - KZ1F

A hyperthreaded core is about equivalent to 1.2 times the number of processors. Standardly an I5 has 4 non hyperthreading cores. And I7 has 4 cores but also supports hyperthreading so while the OS thinks it is 8 it is really about 5. But it good for the ego. They come in incredibly handy when running fully virtualized. Without paravirtual drivers there is a fair amount of spin loops to simulate internal timing. If you overcommit threads you can start a VM so the hyperthreads come in handy to allow the system to run when it otherwise would seize up.

It is very deceptive how much of an I7 will actually get used. There are two main reasons for this:
1) processors > 1 are of no help if there is no parallelism in the program.
2) if 1 processor is handling a thread that performs a lot of IO, even when there is parallelism occurring in the program, if the program is IO bound (a lot of IO compared to computing) the processor that handles the interrupts is free to handle computing.
3) a thread (not to be confused with hyperthread) is a separately dispatchable unit of work in the program, This separately dispatchable unit of work in the program is, essentially, either running or waiting. If you define too many threads your program can actually slow down, it passes the point of diminishing returns. Every time a processor switches from one thread to another it is called a context switch. Context switching is not free. When I had 4 panadapters running (1 slc each) there were around 30-40 threads in the system. 

In an earlier post I mentioned there are a lot of laws in computer science. I think it was Amdahl's law that attempts to show the relationship between threads, processors, and the IO-ness of a program.
People with I5's with 4GB have had outstanding results. So comparing that to a business class machine with 20 processors, 20GB or error correcting memory, there is likely not a whole lot of difference beyond bragging rights.

So really, think about what SSDR actually does.
1) it sends English commands to the radio, as a result of you clicking something (how often does that occur?)

2) it receives English status messages from the radio in response to, primarily, the English commands sent. Not a lot happening here requiring business class machines.

3) It receives an incredible amount of bps for all the UDP traffic, meters, waterfall(s), spectrum display(s), digital audio. For every UDP datagram received SSDR creates a corresponding Vita-49 packet from it, from which the actual payload is subsequently removed from it. I am not sure how much of the CPU required to create the Vita-49 packets is really 'productive'. That would be an interesting experiment to quantify that.

4) from that data it draws the SWR meter, Power meter, Signal strength meter, spectrum display and, optionally, waterfall. The actual drawing generally is done on your video card.

I think you'd be hard pressed to find a duo core Intel these days but, from the above, I don't know that there is much to be gained beyond an I5 chip with 4GB.

Jim Hawkins

i7 6 cores, 12 logical processors, 3.4 GHZ as shown in the task manager.

It also works fine on my 2 core 4 logical processor laptop.

Jim Hawkins

Joe, Thanks for the detail.  I never bothered to fully understand it.  When I retired as a Windows programmer, we were not using multiple cores or multithreads.

Anyway, my brain is about 1/2 thread these days! :-)
I'm going to cut and paste your explanation into my notes.

Jim

Walt - KZ1F

Joe the I7 is a quad and is hyperthreaded. The I5 is a quad and is NOT hyperthreaded.
In case some may not believe me, from PC Mag "The quick explanation is that all Core i7 CPUs use Hyper-Threading, so a six-core CPU can handle 12 streams, a four-core can handle eight streams,"

Peter K1PGV

Good observations, Walt.

I suspect SSDR is very multithreaded.  Best practice is to have a thread dedicated to updating the display controls, a different one doing background processing, and for SSDR I would assume there's at least one dedicated thread for the panadapter/waterfall.

Not to mention:  FlexLib itself is in fact multithreaded.

And, don't forget: While you're running SSDR, there's lots of "other stuff" going on in your system.  If those other processes can "fight" less with SSDR for CPU resources by using other cores, so much the better.

Multiple CPU cores are a good thing.  The more, the better, in almost all practical cases. This is also true of memory.  Note that while there are systems with more than 250 cores, the practical limit for a workstation or home system these days is about 16 cores.

Peter
K1PGV

Joe, KQ1Q

Yes, understood -- that's why I always specified i7 above.

Walt - KZ1F

I don't disagree Peter. The distinction I wanted to make was core count vs thread count. You are absolutely right, at least earlier SSDR's would launch over 30 threads. That is a heck of a lot of context switches in one application. I can't speak to WPF but in JavaFX and Android there is a UI thread and, yes, I'd dedicate a core to that. However, as a counterpoise you have a whole pantload of UDP packets arriving, which take very little cpu. One could probably argue that the core handling the I/O could do dbl duty in processing the initial building of the view, to be drawn by the UI thread. With the exception of tablets and phones I think one would be hard pressed to find a current CoreDuo Intel box, but I suspect 2 cores could probably handle SSDR nicely. And then, as you point out, there is DM780 or FLdigi or CW Skimmer etc. This is why I said an I5 with reasonable memory, 4GB is reasonable, would suffice nicely.

There are some that would say, "I have a Dell PowerEdge T540 with 20GB of memory and 20 core dual Xeon procesors and ECC memory and SSDD and SSDR flies". Well, of course it does. And I tell those people they could put Hyper-V on it and rent time and still SSDR would fly.

As far as the title of this question, short of  defining processor affinity, yes, SSDR would run on all 20 procesors if you had a PowerEdge but the correct question would be does it need more than 4 cores and the answer is no. For those that watch their CPU utilization and see it at 50% that means that on a 4 core machine, on avg 2 of them are idle at any given time. They have 100% excess capacity. Even if with HRD and CWSkimmer if that pushes the CPU utilization to 85% that still is almost 20% excess capacity (15% / 85%).

If the thread processing the raw data into a spectrum view or waterfall view prior to handing over to the UI thread can do that faster than the FFT data arrives, more and/or faster cores are not necessary for that function. So long as the raw UDP packets are unmarshalled faster then they arrive more and/or faster cores will add no value. It is totally acceptable to have a dispatchable unit of work (thread) waitng for data to arrive.  What is, perhaps, less acceptable is to have a dispatchable unit of work waiting for an available core.

The other distinction I wanted to make was between faster processors verses more processors. Even in a multi-threaded application, i.e. SSDR, if thread 2 requires thread 1 to complete, then what they are doing is serial, not parallel. In the list of activities I made previously, tasks 1 and 2 occur solely by virtue of the user pressing a button or sliding a slider. Neither happen a lot or are time critical. Task 4 is completely dependent on task 3. You can't draw something that hasn't arrived yet.

task 1 depends on user input
task 2 depends on task 1
task 3 depends on UDP data from the radio (box).
task 4 depends on task 3.

However, if the software is designed properly task 3 can be processing datagram n+1 while task 4 is processing datagram data n. If the application is designed properly there is some parallelism between tasks 3 and 4. Prior to 1.4 they were serial. Now they are loosely coupled where task 3 (producer) populates a queue and task 4 consumes the queue. So long as task 3 can produce faster than task 4 can consume, task 4 wil stay busy and operate, largely, independent from task 3.

This presents an interesting queuing issue. On a locally attached network, task 3 can keep data available for task 4 such that task 4 never has to stop and wait for data. However, in a WAN environment it is not clear that will be the case, and likely won't be, task 4 may be faster than task 3. If task 4 is faster than task 3 the 'system' is once again serial. What does that mean? It may mean you don't necessarily want to be drawing a waterfall. At the end of the day, the bandscope (spectrum) doesn't draw many pixels. The waterfall, however, draws all of them.

So Howard? How am I doing now? ;-) (inside thing between Howard and me).

Joe, KQ1Q

Yes SmartSDR is heavily multi-threaded.  Task Manager shows mine has 55 threads. Opening an additional Panadapter starts up about three more threads.

As Peter stated, multiple cores can help even in cases where the app itself does not efficiently use multiple threads. There are typically hundreds of threads in the OS, some of which are in a runnable state and available for dispatch to an available core.

Intel's current highest end CPU the E5-2699 v3 has 18 hyperthreaded cores which under ideal conditions can concurrently run 36 threads.

i7-class CPUs are limited to 4 cores or sometimes 8 cores. This is less an issue than first appears because of Amdahl's Law, which essentially states that a small % of serializable code will quickly cap the achievable multiprocessor speedup. Multiple threads working on a common task must generally synchronize or combine their work, and those brief code paths can bottleneck perf. improvements. This happens much sooner than is intuitively apparent, e.g, 90% parallel code won't gain much multi-core perf. beyond about 32-64 cores. So the E5-2699 v3 is already near the Amdahl limit for the 90% parallel case: http://en.wikipedia.org/wiki/Amdahl%27s_law

This doesn't affect SmartSDR since it runs very well on two or four cores.

Clock rates have been constrained since the end of Denard Scaling which happened around 2005:  http://en.wikipedia.org/wiki/Dennard_scaling, and superscalar instructions per clock are now limited to small improvements. 

While specialized highly parallel code can harness many cores for narrow applications, even multicore growth is now limited by on-chip power dissipation: http://www.cc.gatech.edu/~Hadi.Esmaeilzadeh/doc/paper/2012-toppicks-dark_silicon.pdf

Ken - NM9P

Thanks for the insight, Walt.  I have also found that my experiments with remote ops with Parallels Access over LAN & WAN are much more successful when I remove the waterfall and reduce FPS rate, which is logical.  I think that those clamoring for "fill under the pan" will have similar graphics demands and potential slowdowns.  I personally don't see the point.  But if the processor will handle it, go ahead.  In a networked situation that would be one of the first features I would turn off.  I found the same when running my 1500 on a laptop that was barely sufficient to the task.

Ken - NM9P
"Not an expert programmer, but learning lot through SDR..."  (;o)

Walt - KZ1F

So you're (Joe) agreeing with me? In the case of the ES-2699, the 18 'phantom' cores, while adding value, don't double the performance of the 18 true cores. Similarly, for the same speed chip, an I7 with 4 cores w/hyperthreadiing is not twice as fast as an I5 with 4 cores non-hypertrheaded, at the same clock speed. It is faster but not 100% faster.

I can write a program that creates a thread pool of 1,000 threads. If you look at the system, you will see 1,000 threads started. That is totally independent of them doing anything productive. Whether you have 4 cores or 8 cores or 256 cores, you will still have over 900 threads waiting for an available processor or a dispatchable unit of work needing to be executed. This is why I brought up the notion of dispatchable unit of work. In software terms that would be a thread. If that thread is not dispatchable, because it is waiting for something else to occur then it is of zero value.

While this is an interesting thread we've somewhat gone into academia. As far as the central question of this thread the answer is still no.  Was it in the 80's that some company was redoing the Fortran V compiler to detect opportunities for parallel units of work. To my recollection that company folded.

The datacenters for Monster.com, of which I am intimately familiar, or Amazon, or Google are in a completely different space than what does it take to run SSDR with good performance.

This is where analytics come in handy. As you may know I am rewriting FlexLib. The advantage of doing this is I can instrument it. It's easy to create threads. What is less easy is to understand when you've created non-productive threads. If you have two threads running two dispatchable units of work and they are both 99% idle, I would argue you didn't want 2 threads. The context switching time between 2 threads is likely unnoticeable. However, when you get 50 or 100 threads going, the context switching time becomes quite noticeable.

I did, for simplicity, commingle two different things, dispatchable task and a thread. If you have 4 tasks (see task list for SSDR) and you marry each one to a thread there is still a dependency between task and, likely, each task (thread) is idle. However, if you decouple the unit of work (task) from the thread it is running on, you will lower the total threads necessary, reduce the context switching time, and improve performance. This is accomplished by utilizing a thread pool or, in Java parlance an ExecutorService. The goal is to minimize or, ideally, eliminate waiting on a processor. Given the consumer market is limited to a Gbs network, something Monster, Amazon, Google aren't limited to, we really can't control how fast UDP datagrams arrive. So long as each datagram is processed before the next one arrives, that is as fast as SSDR can get. If anything beyond 4 threads is superfluous we can make really good estimates on what class machine is the minimum for ideal performance.

I believe Dell's sub-$300 machines are all at least I5@3Ghz+ with 8GB memory. I think any of those would likely be dandy for SSDR.

Walt - KZ1F

Ken, and all: While, given the waterfall packets arrive at all,  the majority of time spend processing waterfall data is physically drawing, which is what happens when you pul the spectrum over the waterfall, it would be WAY faster to never see the waterfall packets at all. Consequently the ideal solution is for FRS to add a switch to eliminate even sending the packets to the SSDR. You can't draw what you don't see. If someone wants to see them, great, they should but for someone running from a hotel room with bad wifi, it would be nice to selectively turn the waterfall off at the radio.

Ken - NM9P

And here I am, running a "lowly" i3 on my Lenovo Ideacentre K410.  And this was a giant leap above the Toshiba Satellite running an Intel Centrino dual core that I was running (barely) before that!

These new computer processors are growing so fast I can't keep up with them mentally.  And keeping up financially is out of the question!

Ken - NM9P

Makes sense, Walt.  At present, when I operate remote I drag the waterfall down to zero height on the display.  But it is often difficult to get exactly on the line in the window I need to in order to shut it off.  It would be much more convenient to have a switch, perhaps persistent to the "Remote" button status, that does it easily.  If the waterfall would reset to the same position when reactivated it would be very nice.

I wonder what the CPU & Network load difference would actually be with elimination of the waterfall data feed as opposed to simply reducing the waterfall display size to zero?  

Ken - NM9P

Joe, KQ1Q

Walt, yes I agree with most of what you said. Yes hyperthreading (aka SMT) has limited benefits, which is why my initial post stated improvements range from slightly negative to about plus 40%. Using popular performance-intensive image software, I have measured improvements from 0% to about 30% on the same computer and software, turning hyperthreading on/off.

The thread context switching issue is well known. That is why at Microsoft when we developed SQL Server, we used a small thread pool, not spin up a thread for each client. Since then Windows has added support for lightweight threads called fibers which in some cases may reduce the work required to "roll your own" thread pool: https://msdn.microsoft.com/en-us/library/windows/desktop/ms682661%28v=vs.85%29.aspx

Fortran V was a proprietary compiler from Data General (where I also used to work). It was not parallelizing, since in that was before widespread use of symmetrical multi-processing. However much of the research in parallelizing compilers has used Fortran because of favorable aliasing semantics.

Walt - KZ1F

The data for the waterfall is still sent, whether it is a fast network (20Gbs) or a slow type B or G or N or AC wifi network. Data arrives serially. If good data has to wait in line behind 'bad' data that slows everything down.

The data is still processed, datagram packets need to be un-marshalled before it can be determined they are waterfal packets.

The data is still 'drawn' in the software. When the actual canvas work is done the data isn't being physically displayed yet.

Basically what you'd save is the scroll time. Scroll time is fast as the GPU physically does that in the video buffer on the video card.

If the data is never sent from the radio, that is the biggest dent possible in performance, verse just covering up the viewport.

Ken - NM9P

Thanks, Walt..
Reading these programming posts from top tier programmers like you, Joe, Neal, and Steve & others from FRS (and others) is like a little league kid sitting down with a bunch of Major Leaguers talking baseball.  Some of it is way over my head, but not so far that I can't follow the basic ideas.
Thanks for the "stretch."

Walt - KZ1F

Even to this day Ken, what I most enjoy is learning things I didn't previously know. I also enjoy teaching and mentoring. To be sure, there are many things in CS I do not know. As mentioned previously, on a good day I can spell .NET. Since I am now retired and don't like Microsoft's business practices, I don't have much need to. There are things you've said Ken that I hadn't previously known, so it works both ways!

Peter K1PGV

So let's break this down Barney-style for the OP and the archives.  The OP asked:

Can SSDR utilize more than 4 processors in the Intel I7 CPU?

And the answer is: More than 4 CPUs?  Yes, absolutely, positively. Up to some reasonable limit more cores is better than fewer cores.  That doesn't mean SSDR will necessarily run perceptibly better.  But it does mean there'll likely be better overall system throughput. 

Peter
K1PGV

Ken - NM9P

Not to hijack the thread, but perhaps to jump off from here....
I wonder of some of you who made your living by programming would be interested in starting a thread on this community board about "Basic programming concepts for the FLEX API?"

I envision something like:
1) Introduction to object oriented programming.  (verses the linear logic and subroutines that most of us grew up with in FORTRAN and Basic).
2) getting acquainted with major programming options - C#, Java, Processing, .net, Android, etc.
3) accessing the 6000 via the API ethernet protocol (How to set up your read/write routine.
4) accessing Serial CAT on the 6000 or other serial CAT rigs. (How to set up read/write on a serial port)
5) communicating with other equipment in the outside world - MIDI, amplifiers, rotor control, et. al.
6) Basic logic design for rig control  (how to use IF/THEN/ELSE, Do loops, While, Until, Boolean status switches, etc...)
7) Keeping it simple until you need to get complicated...
8) Error trapping
9) How to avoid memory leaks, data traffic jams and other programming errors.

And I am sure there are a lot of other topics that would help the "masses" who are interested in playing programming on our newfangled rigs.  This is one of the reason that I got into SDR.  I will probably do a lot more in 6-10 years when I retire, but playing with the MIDI controller last month gave me a taste and piqued my interest.  I would love to do it in C# rather than Processing as a first project so I can learn C#.  I have a nice book that was recommended on this board, but have only done the first two lessons and then got sidetracked by many other projects.

What do you think?

Ken - NM9P