Processor Performance Ratios?

Is there perhaps an online lookup table where you could plug in...

t7100 1.8ghz
t9900 3.06ghz

or

t7100 1.8ghz
i7-820QM 1.7ghz

....and see the approximate performance ratio? Thanks.

On Monday, December 2, 2013 9:59:32 AM UTC-6, Davej wrote:
Is there perhaps an online lookup table where you could plug in...

t7100 1.8ghz
t9900 3.06ghz

I found this cpu lookup, which is adequate...

http://www.cpubenchmark.net/cpu_list.php

Davej wrote:
On Monday, December 2, 2013 9:59:32 AM UTC-6, Davej wrote:
Is there perhaps an online lookup table where you could plug in...

t7100 1.8ghz
t9900 3.06ghz

I found this cpu lookup, which is adequate...

http://www.cpubenchmark.net/cpu_list.php

Yes, those are multi-threaded benchmarks.

Not all application software, is capable of using
all the cores in a processor in parallel. In such
cases, the above PassMarks don't tell you everything.

We used to rely on SuperPI timing benchmarks, as
a measure of single threaded performance. The
hwbot.org site has a large number of these results,
but the interface to the information makes it
very difficult to get what you need. The problem
with that site, is 99% of the SuperPI results
are for overclocked processors. Hardly
any benchmarks exist for "stock" operation.

Still, it's the only other site I know of,
that can help predict single-threaded
performance. Most of the software on
my computer is single threaded. Photoshop
would be one of the exceptions (where half
the filters are single-threaded for numerical
accuracy, and the other half are multi-threaded
for speed).

Movie editing and rendering, is another area that
uses multiple cores to good effect. If you're buying
a computer for movie editing or transcoding,
then the PassMark results above are the
benchmarks to use. But for other purposes,
SuperPI is my choice (since much of my software
is older, and no effort was made to get it to
execute in parallel).

Recent versions of Excel, do some calculations
in parallel, but then other sections are still
single threaded. Engaging parallelism, isn't
always the easiest thing to do. And some applications
with parallel execution, don't scale to an infinite
number of cores. Perhaps the 7ZIP compression option
you've selected, runs at most two threads, and only
uses half of the processing power of a four-core
processor. From that perspective, PassMark over-estimates
what you're buying. There could be wasted capacity
you cannot use.

It's just like Cinebench, which is a "perfect scaling
application". Cinebench as a benchmark can use a large
number of cores, which may not be representative of
how the rest of your software works. The reason Cinebench
can do that, is the threads of execution don't talk
to one another. Real-world applications have more
need to synchronize the threads of execution, which slows
them down (waiting for the slow thread to finish).

Paul

On Wednesday, December 4, 2013 6:28:53 AM UTC+8, Paul wrote: We used to rely on SuperPI timing benchmarks, as

a measure of single threaded performance. The

hwbot.org site has a large number of these results,

but the interface to the information makes it

very difficult to get what you need. The problem

with that site, is 99% of the SuperPI results

are for overclocked processors. Hardly

any benchmarks exist for "stock" operation.



Still, it's the only other site I know of,

that can help predict single-threaded

performance. Most of the software on

my computer is single threaded.
Perhaps the 7ZIP compression option

you've selected, runs at most two threads, and only

uses half of the processing power of a four-core

processor. From that perspective, PassMark over-estimates

what you're buying. There could be wasted capacity

you cannot use.

I just downloaded and ran the SuperPI program, which the latest version for single core tests, and occasionally gives an error message like 'Could not Round' or some such (just restart it and it goes away), and for my system of a i5-2400 Sandy Bridge core for 1M Pi digits got: 11.6 seconds and 11.8; my system is not overclocked.

What is strange is that an i7 gave the following weak scores online (you would think the i7 is faster than the i5, as it should be):
(Screen scrape from a site online):

Super PI 1M
(Core i7 4000MQ Series @ 3276.2 MHz)
11.047sec
4700qm

Super PI 1M
(Core i7 4000MQ Series @ 2394.7 MHz)
15.453sec

Note the second Core i7 score is worse than my system, while the first score is not much better--why?

I have 4 MB memory.

It's also interesting that Paul thinks 7-zip only uses at most 2 cores--actually, I would be happy if it used just one core--I need the other cores to run my other programs. I hate the "freezing" that occasionally happens to a multi-core PC when a parallel execution software program takes over the entire PC (like for example a chess program, which is notorious for using parallel processing--nearly all do nowadays). I heard Intel is working on the next generation that will prevent such 'freezes'.

Further, it's interesting that most of the time, even when doing compression using WinZip, etc, Windows Task Manager rarely shows any core (and they all seem to work in parallel, even for a single threaded program, which is weird) working more than 5% to 10% or so. This actually annoys me, as I wish one of my four cores was at 80% so the job would finish quicker. But no, they all chug along at less than 10%, with an occasional spike. It think the 'normal priority' default for cores per any single program is probably very low, perhaps less than 10%, and unless you as a programmer somehow override that, at the system level using some call, you cannot really make the cores work at a higher rate than that (I am guessing but so it seems).

RL

RayLopez99 wrote:
On Wednesday, December 4, 2013 6:28:53 AM UTC+8, Paul wrote: We used to rely on SuperPI timing benchmarks, as
a measure of single threaded performance. The

hwbot.org site has a large number of these results,

but the interface to the information makes it

very difficult to get what you need. The problem

with that site, is 99% of the SuperPI results

are for overclocked processors. Hardly

any benchmarks exist for "stock" operation.



Still, it's the only other site I know of,

that can help predict single-threaded

performance. Most of the software on

my computer is single threaded.
Perhaps the 7ZIP compression option

you've selected, runs at most two threads, and only

uses half of the processing power of a four-core

processor. From that perspective, PassMark over-estimates

what you're buying. There could be wasted capacity

you cannot use.

I just downloaded and ran the SuperPI program, which the latest version for single core tests, and occasionally gives an error message like 'Could not Round' or some such (just restart it and it goes away), and for my system of a i5-2400 Sandy Bridge core for 1M Pi digits got: 11.6 seconds and 11.8; my system is not overclocked.

What is strange is that an i7 gave the following weak scores online (you would think the i7 is faster than the i5, as it should be):
(Screen scrape from a site online):

Super PI 1M
(Core i7 4000MQ Series @ 3276.2 MHz)
11.047sec
4700qm

Super PI 1M
(Core i7 4000MQ Series @ 2394.7 MHz)
15.453sec

Note the second Core i7 score is worse than my system, while the first score is not much better--why?

I have 4 MB memory.

It's also interesting that Paul thinks 7-zip only uses at most 2 cores--actually, I would be happy if it used just one core--I need the other cores to run my other programs. I hate the "freezing" that occasionally happens to a multi-core PC when a parallel execution software program takes over the entire PC (like for example a chess program, which is notorious for using parallel processing--nearly all do nowadays). I heard Intel is working on the next generation that will prevent such 'freezes'.

Further, it's interesting that most of the time, even when doing compression using WinZip, etc, Windows Task Manager rarely shows any core (and they all seem to work in parallel, even for a single threaded program, which is weird) working more than 5% to 10% or so. This actually annoys me, as I wish one of my four cores was at 80% so the job would finish quicker. But no, they all chug along at less than 10%, with an occasional spike. It think the 'normal priority' default for cores per any single program is probably very low, perhaps less than 10%, and unless you as a programmer somehow override that, at the system level using some call, you cannot really make the cores work at a higher rate than that (I am guessing but so it seems).

RL

Using Task Manager, right click on the 7ZIP entry, and use
the Set Affinity function to limit 7ZIP to run on just one core.
That works, for a running program. So you do have some control over that.
You don't have to suffer.

There are ways to launch a program, with an external launcher,
and restrict execution to one core. So you can have a shortcut
on your desktop for "7ZIP on one core". The Task Manager trick
will get you by for now.

*******

SuperPI performance depends on:

1) Clock rate.
2) Memory bandwidth (cranking memory clocks may help etc)
3) Processor cache. The more of the benchmark that
fits in cache, the better it works. That's why choosing 1M digits
is kinda cheating. That's an 8MB footprint, and may fit
completely in a processor cache. For example, there are some
quad core processors with 12MB of cache, and the
benchmark of 1M should run real good there.

Maybe the mobile processor had slower memory than
what you've got ?

To prevent the cache from making a difference, serious
benchmarking likely uses more than 1M digits. IF you're not
careful, and select a small number of digits, the benchmark
fits completely in cache. 1M takes 8MB of memory. (See
the "Allocated Memory" in the program window, when the
benchmark is running.) If you select 8M digits, that takes
64MB of memory, which won't fit in the processor cache, and
causes the memory subsystem to get pounded. Thus, the benchmark
is now sensitive to main memory speed.

It's a dumb benchmark, but it's been around for a long time.
The interesting part, is the source code was lost, and
most of the modern changes were patched into the executable
by hand, using assembler code. I don't know the person who
did that, but, pretty impressive. The original author was
Japanese, and possibly a professor or something.

Paul