Is there consumer s/w available now that uses multi-core CPUs?

Maybe OT, but given the thread about future CPUs, is there consumer
software now that actually uses the multi-core CPU technology? I mean,
all the additional cores sounds nice, but has any consumer s/w caught
up with the hardware?

TIA,

John Howland

Yes wrote:
Maybe OT, but given the thread about future CPUs, is there consumer
software now that actually uses the multi-core CPU technology? I mean,
all the additional cores sounds nice, but has any consumer s/w caught
up with the hardware?

TIA,

John Howland

In practical terms, the uptake is "surprisingly poor".

That means, when you buy a 16C 32T process, that's largely
going to be a waste.

On tools that are multi-threaded, not all functions are that
way. Some are single, and some are multi.

Take 7ZIP. It's native format (.7z) is multithreaded, but *only*
on compression, not on decompression. If you look at GZIP
compression in the tool, it is single threaded (even though
the PIGZ program showed how to do a couple threads).

When you're working on video, if the CODEC was MJPEG, then
every core can be given an MJPEG frame to compress. That
means you get a linear speedup. An AVI with MJPEG CODEC, flies.
Many other video types, not so much.

Now, take a tougher CODEC to crack. The CinePak codec is only
single threaded. And to boot, the code is also slow as molasses.
It operates at maybe 1/60th of real time when compressing. On that
one, you start N separate movie compressions, each one using 1 core,
to get the best usage of your N-core processor. The reason that's
feasible, is the movie can be losslessly joined later without
recompression, as long as each movie segment ends on a Group-Of-Pictures.

Most games, have a "boss" thread, and helper threads. And a good
game has the "boss" thread at 100%, and each helper thread uses
about 30% of a core. A dual core pretty well meets the load. If you
had a 16C processor, there's going to be a lot of idle cores there.

So if you're going to own beastly CPUs, you have to be a good
multitasker, and start three or four movie renders going at the
same time. To get your value from the thing.

Otherwise, a 4790K or a 7700K or whatever costs $350 these
days, is more likely to be the right processor for you.

Even the Windows OS is pretty sleazy. They don't mention
this in the documentation anywhere, but they "reserve" a good
portion of the CPU for your usage. Then, when you command
Windows Defender to scan your hard drive, it doesn't work
as hard as it could. Maybe it uses 1/4 to 1/3 of cores. There
are *lots* of Windows things, that do this. And it's very
annoying. If you're going to annoy me, take all the cores,
and finish the nuisance activity as quickly as possible,
and I'll walk away until it is done. This "skulking" approach
to irritating users, really sucks!

So if you own a 16C processor in such a situation, a quarter of
that would be four cores, and you might get Windows Defender
using four cores to scan. But that's a pretty expensive way
to speed up Windows maintenance activity.

Photoshop, the filters are split. Half are multi-threaded,
half are single-threaded. The multi-threaded ones will
scream, when you give them 16 cores. The single-threaded
ones, not so much... Overall, I'm sure the Creative Cloud
suite, will get some benefit.

But there's really no consistency to any of this. You're
betting on a pile of "corner cases". Rather than generous
mainstream support.

And this is true of more than CPUs. Just about every whizzy
piece of hardware out there, is a hood ornament. There are
very few items where I would give them an unreserved
recommendation. It used to be different, years ago.
Like, if you had a 300MHz cacheless Celeron, and you
saw a 1400MHz Tualatin for sale, yes, I would have
recommended that, and you would not have been disappointed.
The days of stuff like that happening, are gone.

Paul

On Sat, 24 Jun 2017 03:57:13 -0000 (UTC), "Yes"
wrote:

Maybe OT, but given the thread about future CPUs, is there consumer
software now that actually uses the multi-core CPU technology? I mean,
all the additional cores sounds nice, but has any consumer s/w caught
up with the hardware?

A good promotion point, at least for consumers consuming programs;- if
it's free as well, beating having to pay money, I suppose, to be
consumed and caught up by presumably more than the sound of it.
....Something along an old Unix joke, about going places with 3 people
and 3 operating systems:

1- I run DOS from the command line prompt, in working directly with
machine registers, limited mapped-charters. And I drive a Chevy 6.

2- I run from a Windows bitmapped graphic user interface. And I drive
a new Cadillac V8.

3-I run *NIX and compile my own. I'd as soon rather walk.

-
(Standard Mileage Disclaimer- Some people wouldn't think that's in
the least funny.)

On 24/6/2017 11:57 AM, Yes wrote:
Maybe OT, but given the thread about future CPUs, is there consumer
software now that actually uses the multi-core CPU technology? I mean,
all the additional cores sounds nice, but has any consumer s/w caught
up with the hardware?

Games! Do you play those 3D DirectX games? And video making and photo
editing!

--
@~@ Remain silent! Drink, Blink, Stretch! Live long and prosper!!
/ v \ Simplicity is Beauty!
/( _ )\ May the Force and farces be with you!
^ ^ (x86_64 Ubuntu 9.10) Linux 2.6.39.3
�借貸! ��騙! ��交! �打交! �打劫! �自殺! 請考慮綜� (CSSA):
http://www.swd.gov.hk/tc/index/site_...sub_addressesa

"Yes" wrote:

Maybe OT, but given the thread about future CPUs, is there
consumer software now that actually uses the multi-core CPU
technology? I mean, all the additional cores sounds nice,
but has any consumer s/w caught up with the hardware?

Your premise is invalid. In addition to a jillion Windows
background processes, users almost always have many of their
own programs going at the same time. We are never talking
about just one program, let alone a single thread.

Obviously you are concerned with processing power, so the
question is whether you want few faster cores or many slower
cores. You need to specify the applications in order to
receive a valid answer. I think the best answer is found by
asking people who use the applications you plan to use.

I have not bothered looking to see whether my modern quad
core eight thread CPU is filling up all cores and virtual
threads, because I have no doubt it is efficiently using all
of them. Multicore CPUs have been around for decades. Windows
and the CPU itself, not an individual program, controls the
use of cores.

John Doe wrote:

Multicore CPUs have been around for decades. Windows
and the CPU itself, not an individual program, controls the
use of cores.

That's not true.

Photoshop was the first program to use multiple threads
of execution, in a way that a lot of end users could
experience. They made it popular.

One of the "accelerator" concepts, was a "private"
dual processor board, used only by Photoshop.
At the time, I think it ran at around 66MHz.
Your motherboard in this case, would have just
one core, but the accelerator card had two DSP
chips on it.

SuperMac ThunderStorm DSP card 66 MHZ
AT&T 3210 DSP x 2 ?
Can't find a decent picture.

An example of a modern analogous situation, would
be the usage of shaders on a video card. The main
OS scheduler doesn't schedule that activity. And I
don't even know how a video card would handle two
Windows programs doing shader-related acceleration
at the same time. Whether there is sharing or not.

In my house, Win2K was the first OS that handled more
than one socket here. You could run Photoshop on a
dual socket motherboard, and get twice the speed
on half the filters. And in that case, yes, the
OS played a part in commissioning the two CPUs
involved.

But Photoshop has dabbled with private accelerators.

Another example of a private accelerator, is a video
editing suite that uses a Toshiba "Cell" card. The
Cell card would not be visible to Windows, in a "cores
sense". The instruction set is not x86 to start with.

https://en.wikipedia.org/wiki/Cell_processor

One guy in the rec.video.desktop group, owned one of those.

Paul

Paul wrote:

John Doe wrote:

Multicore CPUs have been around for decades. Windows and
the CPU itself, not an individual program, controls the
use of cores.

That's not true.

Provide citations.

Yes, a program can spawn a thread, but it does not control
the cores that the threads run on or even whether the extra
threads run concurrently. That is obvious, isn't it?
Considering the fact that if there is only one CPU with one
thread obviously multiple threads are going to run
sequentially. Windows controls that. If not Windows, the CPU.
The program doesn't dictate how many cores or virtual threads
are in use. Otherwise your program would be limited to a
certain CPU!

http://www.tomshardware.com/forum/31...-controls-core
s-used

"The operating system controls what threads are running on which cores"

https://superuser.com/questions/5829...core-to-run-on

"The app will run on whichever core the operating system
happens to choose."

Just because you can set the "affinity" in Task Manager and
because a program might be able to request Windows to use a
particular core, that does not mean doing so is a good idea.
Besides, you would have to know in advance how many cores
there are.

John Doe wrote:
Paul wrote:

John Doe wrote:

Multicore CPUs have been around for decades. Windows and
the CPU itself, not an individual program, controls the
use of cores.
That's not true.

Provide citations.

Yes, a program can spawn a thread, but it does not control
the cores that the threads run on or even whether the extra
threads run concurrently. That is obvious, isn't it?
Considering the fact that if there is only one CPU with one
thread obviously multiple threads are going to run
sequentially. Windows controls that. If not Windows, the CPU.
The program doesn't dictate how many cores or virtual threads
are in use. Otherwise your program would be limited to a
certain CPU!

http://www.tomshardware.com/forum/31...-controls-core
s-used

"The operating system controls what threads are running on which cores"

https://superuser.com/questions/5829...core-to-run-on

"The app will run on whichever core the operating system
happens to choose."

Just because you can set the "affinity" in Task Manager and
because a program might be able to request Windows to use a
particular core, that does not mean doing so is a good idea.
Besides, you would have to know in advance how many cores
there are.

The program can still pick which cores the program runs on.

I have a program here which does this.

DScaler has two threads it wants to run. For best
performance, the designer doesn't want the threads to
ever run on the same core. Therefore, the program selects
"run this thread of execution on the highest numbered core,
run this other thread of execution on the lowest numbered
core". Which tells you that programs have access to
Affinity control, just as much as Task Manager does.

On a Hyperthreaded CPU, like a P4, it would run on 0 and 1.
On a Q6600, maybe it would run on 0 and 3. So rather than
pick a particular number, the designer of the program had one
thread run on the "highest core" and the designer did the math
to make that happen. Don't ask me what happens if you
use Task Manager and tick two different boxes :-) Changing
affinity or priority settings, can have consequences,
and there is no guarantee of stability after mucking about.

The OS *can*, in a fully automated way, select what
cores and when to run a process. But application
software, or even Task Manager settings, can change that.

In a way, it's like Windows sound. Everybody assumes the sound
can only come out of the speakers, or out of the headphones,
but not both. The System Mixer is set up to drive one set of
outputs. However, programs such as WinAmp, the developer did
the extra work, to use the feature where the System Mixer is
bypassed, and all of the hardware is then available for usage.
Windows doesn't actually "enforce" the restrictive model,
but for lazy developers, they get "instant sound" with one
call and they're all done and home for dinner.

In some cases, this ability to adjust things is important,
for example, when the OS gets the metrics for running
programs all wrong. There is currently a situation
where an 8C 16T Ryzen CPU is being viewed as a 16C
processor. Performance suffers, because too many
threads are launched. A means is needed to intervene,
and you could, for example, use the Affinity tick boxes
to change the behavior slightly. Notice that the AMD
rep ("evangelist"), just "blows off" this issue.

https://www.pcgamesn.com/amd/amd-ryz...10-performance

There is also a program, a "launcher", which launches
old games, so that they can only "see" one core. And
this permits the games to run properly without crashing.
That would be an example of a program that fiddles
the affinity at launch.

This isn't the program I was thinking of. There is more
than one of these programs. This program would be suited
for running a game that isn't thread-safe for some reason,
and really needs to be fooled into running on the same
core during the entire game.

https://robpol86.com/imagecfg.html

I could go into some of the nuances of scheduling, but
you may also be able to find web articles with the same info.
This is an example of a site that occasionally
has interesting articles.

http://ixbtlabs.com/articles2/cpu/rmma-numa.html

http://ixbtlabs.com/articles2/cpu/rmma-numa2.html

The more modern OSes are supposed to be able to tell the
plumbing apart, use the right metrics (so processes
are not migrated needlessly to places which would
be "more expensive"). Yet, even today, we still read
stories about the OS getting it wrong. Leaving the
impression that the OS lashup isn't anything more
than a set of custom configurations for known
hardware anomalies (Bulldozer comes to mind).

The marketing departments of the processor companies,
don't want us to know that stuff in any detail.
Which is why the info seems so embarrassing when
users discover it. It's not that the info is a surprise,
it's that it wasn't revealed in an up-front way. With
a schedule as to how it would be resolved, when the
patch will come out. Bulldozer was patched, but
the performance gain wasn't earth-shattering.

Microsoft has already given their opinion on the
matter, with their blanket term "support for CPU X"
policy. Whereas Intel and AMD generally skulk under
their respective rocks, when it comes to the OS
not meshing with the hardware they've designed.

I've learned some amazing things from some of the
better technical websites. For example, the early
Hyperthreading on the P4, was actually broken.
But, because the stalling issue resolved before
it got to the millisecond level, users were
totally unaware what was going on :-) My jaw
dropped when I was reading the techniques they
were using for testing, and I couldn't figure out
where the got the "hint" to even look for it.
So some of these guys, have a thing or two they
could teach us. Some of the people on these
sites, are architecture-class, and not just
"game review monkeys".

Paul

Paul wrote:

John Doe wrote:
Paul wrote:
John Doe wrote:

Multicore CPUs have been around for decades. Windows and
the CPU itself, not an individual program, controls the
use of cores.

That's not true.

Provide citations.

Yes, a program can spawn a thread, but it does not control
the cores that the threads run on or even whether the
extra threads run concurrently. That is obvious, isn't it?
Considering the fact that if there is only one CPU with
one thread obviously multiple threads are going to run
sequentially. Windows controls that. If not Windows, the
CPU. The program doesn't dictate how many cores or virtual
threads are in use. Otherwise your program would be
limited to a certain CPU!

http://www.tomshardware.com/forum/31...-controls-core s-used

"The operating system controls what threads are running on
which cores"

https://superuser.com/questions/5829...core-to-run-on

"The app will run on whichever core the operating system
happens to choose."

Just because you can set the "affinity" in Task Manager
and because a program might be able to request Windows to
use a particular core, that does not mean doing so is a
good idea. Besides, you would have to know in advance how
many cores there are.

The program can still pick which cores the program runs on.

The OS *can*, in a fully automated way, select what cores
and when to run a process. But application software, or
even Task Manager settings, can change that.

Yes, but that has little to do with real computing.

You should have put the emphasis on the latter part instead
of the former part. Windows DOES by default without program
or user interaction determine which cores threads run on.

You should know it would be silly otherwise. Imagine if
programs decided for themselves, you could have all programs
wanting to use the first core. Of course that would make no
sense whatsoever. It goes hard against logic to think that
way. There is no reason, without being clairvoyant, for a
programmer to insist on using a particular core. Of course
talking about software most of us use.

1. The programmer does not know how many cores you have.

2. The programmer does not know what other programs might
want to use that particular core.

You need to provide citations, your logic is failing on this
issue. The only question is how many threads does a program
want to use. And even that is defeated, depending on how few
cores the user has.

I could go into some of the nuances of scheduling

In other words... If you cannot dazzle them with brilliance,
baffle them with bull****.







--


In a way, it's like Windows sound. Everybody assumes the
sound can only come out of the speakers, or out of the
headphones, but not both. The System Mixer is set up to
drive one set of outputs. However, programs such as WinAmp,
the developer did the extra work, to use the feature where
the System Mixer is bypassed, and all of the hardware is
then available for usage. Windows doesn't actually
"enforce" the restrictive model, but for lazy developers,
they get "instant sound" with one call and they're all done
and home for dinner.

In some cases, this ability to adjust things is important,
for example, when the OS gets the metrics for running
programs all wrong. There is currently a situation where an
8C 16T Ryzen CPU is being viewed as a 16C processor.
Performance suffers, because too many threads are launched.
A means is needed to intervene, and you could, for example,
use the Affinity tick boxes to change the behavior
slightly. Notice that the AMD rep ("evangelist"), just
"blows off" this issue.

https://www.pcgamesn.com/amd/amd-ryz...-10-performanc
e

There is also a program, a "launcher", which launches old
games, so that they can only "see" one core. And this
permits the games to run properly without crashing. That
would be an example of a program that fiddles the affinity
at launch.

This isn't the program I was thinking of. There is more
than one of these programs. This program would be suited
for running a game that isn't thread-safe for some reason,
and really needs to be fooled into running on the same core
during the entire game.

https://robpol86.com/imagecfg.html

I could go into some of the nuances of scheduling, but you
may also be able to find web articles with the same info.
This is an example of a site that occasionally has
interesting articles.

http://ixbtlabs.com/articles2/cpu/rmma-numa.html

http://ixbtlabs.com/articles2/cpu/rmma-numa2.html

The more modern OSes are supposed to be able to tell the
plumbing apart, use the right metrics (so processes are not
migrated needlessly to places which would be "more
expensive"). Yet, even today, we still read stories about
the OS getting it wrong. Leaving the impression that the OS
lashup isn't anything more than a set of custom
configurations for known hardware anomalies (Bulldozer
comes to mind).

The marketing departments of the processor companies, don't
want us to know that stuff in any detail. Which is why the
info seems so embarrassing when users discover it. It's not
that the info is a surprise, it's that it wasn't revealed
in an up-front way. With a schedule as to how it would be
resolved, when the patch will come out. Bulldozer was
patched, but the performance gain wasn't earth-shattering.

Microsoft has already given their opinion on the matter,
with their blanket term "support for CPU X" policy. Whereas
Intel and AMD generally skulk under their respective rocks,
when it comes to the OS not meshing with the hardware
they've designed.

I've learned some amazing things from some of the better
technical websites. For example, the early Hyperthreading
on the P4, was actually broken. But, because the stalling
issue resolved before it got to the millisecond level,
users were totally unaware what was going on :-) My jaw
dropped when I was reading the techniques they were using
for testing, and I couldn't figure out where the got the
"hint" to even look for it. So some of these guys, have a
thing or two they could teach us. Some of the people on
these sites, are architecture-class, and not just "game
review monkeys".

Paul

On Sunday, June 25, 2017 at 1:26:14 AM UTC+8, Paul wrote:

One of the "accelerator" concepts, was a "private"
dual processor board, used only by Photoshop.
At the time, I think it ran at around 66MHz.
Your motherboard in this case, would have just
one core, but the accelerator card had two DSP
chips on it.

SuperMac ThunderStorm DSP card 66 MHZ
AT&T 3210 DSP x 2 ?
Can't find a decent picture.

Back in late 80s, I worked on a PC that had an "array processor" plugged
into a slot, as the host was a Compaq 486, far too slow to do the math.
I think that array processor was rated at 8 MegaFLOPS (about 1/10 of
a Pentium III).