Why Pentium?

  • Thread starter Thread starter Talal Itani
  • Start date Start date
The said:
Most likely system difference, I only have a 2.2Ghz A64 compared to
your 3Ghz and these things are quite likely sheer clockspeed
dependent.

Well, 3.0 GHz is only 36% faster than 2.2 GHz, so that alone would not
explain the big difference you are seeing.

However, you have a 64-bit chip. Perhaps it is not optimized for
32-bit operations.
What are your timings for a radial blur, spin, best
quality?

For a 1600x1200 color 8-bit image, 19 seconds. I could not try it
with an A3-sized image because Photoshop says I don't have enough
memory.
Is yours a HT chip?
Yes.

You should also try seeing what happens when previewing artistic
filters like plastic wrap. It takes about 15~16 seconds just to
generate the preview for me.

On the same 1600x1200 image, it takes less than a second to apply the
filter.

If I upsize the image to 33 megapixels and apply the same filter, it
takes 22 seconds to apply it.
Personally I've avoided taking on projects dealing with bigger sizes
simply because after one experience (saved file was some 200MB IIRC),
I decided I don't want to have to wait half an hour to apply a filter.

Some filters are naturally very slow; some of the Impressionist
filters I have can take a few minutes (but they give great results).

I routinely do things with 80-megapixel images and aside from a few
filters, it's all very fast.

Note also that I'm using Photoshop 5.0.2.
Windows is reporting that because PS is using as much processing power
as it can and not responding to external inputs during that time. It
has nothing to do with memory in this case. Purely CPU bound.

Well, I don't know why it is so slow for you, then. It works fine for
me.
 
kony said:
Quite untrue. EVERY operation's processing time depends
largely on it. So sure, any operation will complete,
eventually, but all are slower.

Not significantly, in most cases.

Also, if there isn't enough memory, every operation will involve
extremely slow disk I/O.

The difference between Photoshop with inadequate memory and Photoshop
with plenty of memory is like night and day. Nothing speeds up
Photoshop more than adding memory.
You obviously don't do much or very demanding image editing.

I don't spend my day applying filters, that's for sure. I leave that
for the newbies and the high-school kids.
 
kony said:
Why would you think that an insult coming from someone who
disagrees, would have even the slightest weight to it at
all? From you Rod, it's expected, redundant, and just shows
you're out of valid arguments.

It reminds me of some old and excellent sketches on "Saturday Night
Live." There was one about a restaurant run by Greeks or something
that has only cheeseburgers and Pepsi that comes to mind.
 
kony said:
A nice theory, but we have benchmarks to compare these
things and they do show improvements from a faster CPU.
Not as much improvement in some cases as having a HDD
upgrade, but the difference is nevertheless significant.

Every upgrade will change _something_, but in the world of
microcomputers, the role of processor speed in overall performance has
been dramatically exaggerated for many years. Today, processor speed
is not the problem.
 
kony said:
If you have a lot running at incorrect (per user's needs)
process priority, then it's somewhat true, and mostly false,
because gen-purpose OS can easily be very snappy. Win9x
Lite, Win2k, even WinXP if you whittle away at it for
awhile.

I don't set process priorities on a desktop machine, nor do I
recommend that anyone else do so.
 
George said:
To a certain extent it can be but we're not talking about processor
speed... more to the point, with dual cores, and to a lesser extent with
HyperThreading, there is a definite improvement in snapiness: the TLB and
cache doesn't have to be flushed and refilled -- note that "refill" of the
TLB requires walking page tables -- on every task switch. I can assure you
the effect is noticable instantly.

The "snappiness" of multiprocessor systems comes from the availability
of a second processor thread, not from processor speed. Even an old
dual PPro will be snappy compared to many uniprocessor systems, but
only because it has two processors to which things can be dispatched,
not because of any speed advantage.

Windows XP and its family (NT) isn't very good about dealing with
CPU-bound processes. They tend to slow the machine down because
Windows will not pull them from execution and dispatch to other
processes quickly enough to preserve good response time. The only
solution is multiple processors--but they don't have to be fast. HT
helps somewhat, although it has constraints of its own. HT works best
when you have two significantly different threads to run.
 
Mxsmanic said:
David Maynard writes:




I presume so. It's the NVIDIA driver reporting the temp for the
graphics card, so wherever the driver gets it from is the source.




Then why are the limits so much lower for CPUs?

Well, for one, because junction failure isn't necessarily the limiting
factor. Speed counts and they can't run as fast at high temperatures.

They're also denser with heavier bias (again for the speed) and, as a
result, are more prone to localized hot spots. I.E. All them junctions
gotta stay under max, not just the die average.
 
Well, 3.0 GHz is only 36% faster than 2.2 GHz, so that alone would not
explain the big difference you are seeing.

It makes quite a bit of difference for straight forward operations
like applying a filter. The P4 is very good for this kind of
operations because Netburst's kind of like a DSP :P
However, you have a 64-bit chip. Perhaps it is not optimized for
32-bit operations.

I doubt that is the case since the A64 is basically a 32bit K7
extended.
For a 1600x1200 color 8-bit image, 19 seconds. I could not try it
with an A3-sized image because Photoshop says I don't have enough
memory.

It takes 32 seconds for me on 1600x1200. Quite significant and disk IO
would have nothing to do with an image that small since we both have
several times more memory than needed for this.

It is quite strange why you cannot do the operations on A3 when you
have 2GB versus my 1.5GB physical memory. The only explanation I can
think of is the implementation in PS 5 and PS 8 is different wrt to
memory usage i.e. PS8(CS) is more efficient in memory usage, which of
course supports my point that CPU can be the bottleneck and not disk
nor memory once you need to crunch through enough data.

This will explain why you don't get the not-responding messages.
Mine's single core, non-HT.
On the same 1600x1200 image, it takes less than a second to apply the
filter.

3.3s for me
If I upsize the image to 33 megapixels and apply the same filter, it
takes 22 seconds to apply it.

14s for mine after upsizing it. This is a bit strange tho, our first
reversal.

I routinely do things with 80-megapixel images and aside from a few
filters, it's all very fast.

I guess we need to define fast here. Fast to me is less than 3
seconds. Basically, I only consider it fast if I click, take a breath,
blink and it's done. At A3 sizes, basically none of the filters are
fast from my POV.
 
The said:
It takes 32 seconds for me on 1600x1200. Quite significant and disk IO
would have nothing to do with an image that small since we both have
several times more memory than needed for this.

That is very strange indeed. That's almost twice the amount of time
required on my machine.
It is quite strange why you cannot do the operations on A3 when you
have 2GB versus my 1.5GB physical memory.

I agree, but maybe there is something strange about the radial filter.
This will explain why you don't get the not-responding messages.
Mine's single core, non-HT.

Maybe, although HT is hardly the same as two processors. It does work
a lot like two processors as long as the two processor threads are
quite different, though (if they are the same, they hit the same
hardware on the processor, effectively forcing one thread to wait for
the other, like a uniprocessor).
3.3s for me

Maybe you should take your machine back to the vendor.
I guess we need to define fast here. Fast to me is less than 3
seconds. Basically, I only consider it fast if I click, take a breath,
blink and it's done. At A3 sizes, basically none of the filters are
fast from my POV.

My PS 5.0.2 gets stuck if I try to do a radial blur on an A3 page.

It is interesting to note that PS takes one fully processor, but the
other HT thread remains idle, so response time on the system is
completely unaffected.
 
It is interesting to note that PS takes one fully processor, but the
other HT thread remains idle, so response time on the system is
completely unaffected.

I wouldn't necessarily put this down to HT. Where it is a matter of a
single program consuming all available CPU it's a relatively simple
matter for the OS to give another program the cycles needed for it to
appear fairly responsive - provided it doesn't need too much CPU time
of course. It's a mystery to me why at times Windows seems to handle
this so poorly. An example of this would be SETI@home under UNIX -
unlike its Windows counterpart, the UNIX version is always running in
the background -not just when the screensaver kicks in. This doesn't
affect response at all, although admittedly it does run at a low
priority. In effect it soaks up any spare CPU capacity but doesn't
slow down your operation of the machine more than a neglible amount.

What really slows the feel of things down, IMO, is I/O activity. Two
processes both fighting over the disk does seem to slow things down
a lot. This is one area where SCSI still seems to have an advantage,
despite the improvements to IDE over the years.
 
Andrew said:
I wouldn't necessarily put this down to HT. Where it is a matter of a
single program consuming all available CPU it's a relatively simple
matter for the OS to give another program the cycles needed for it to
appear fairly responsive - provided it doesn't need too much CPU time
of course. It's a mystery to me why at times Windows seems to handle
this so poorly.

I don't know why it handles it poorly, but it does. On a straight
uniprocessor system, any program that is tightly CPU-bound will slow
the system down considerably. And I know that it's a question of OS
design, because the cursor continues to respond normally. So the
hardware resources are there, but Windows is just not good at
switching between applications when one of them is CPU-bound.

NT-based systems are much, much better at this, but Windows as a whole
still has trouble with it.
An example of this would be SETI@home under UNIX -
unlike its Windows counterpart, the UNIX version is always running in
the background -not just when the screensaver kicks in. This doesn't
affect response at all, although admittedly it does run at a low
priority. In effect it soaks up any spare CPU capacity but doesn't
slow down your operation of the machine more than a neglible amount.

Large timesharing operating systems (such as UNIX) long ago became
very good at this type of thing.
What really slows the feel of things down, IMO, is I/O activity. Two
processes both fighting over the disk does seem to slow things down
a lot. This is one area where SCSI still seems to have an advantage,
despite the improvements to IDE over the years.

True. Fortunately applications usually don't fight over the disk. On
one occasion when they were, though, I got the only unexplained BSOD
I've had with Windows XP. I still don't know what happened.
 
That company I worked for had only 50 employees, at its peak, so our
business software needs were modest and could be handled just
accounting and cost estimation packages. Most of the needed strategy
and tactics consisted of making the salesmen go out and find customers
rather than just sit around in the office, providing technicians with
everything they wanted, and keeping the owner's son out of the way.

Yeah we have one of those, Problem is, the owner died, and guess
what? Now the son is the owner. He comes in and makes big decisions,
such as "we need plants outside" and "lets put fancy signs on the
building". Jeez.
 
That is very strange indeed. That's almost twice the amount of time
required on my machine.

Do keep in mind that we are using two different platforms after all. I
would expect certain things to perform much better on the P4 due to
the way it is designed just as somethings just do much better on the
A64.
I agree, but maybe there is something strange about the radial filter.

It could just be the filter is better implemented as well on the newer
versions.
Maybe, although HT is hardly the same as two processors. It does work
a lot like two processors as long as the two processor threads are
quite different, though (if they are the same, they hit the same
hardware on the processor, effectively forcing one thread to wait for
the other, like a uniprocessor).

I had a HT system for a while and from that experience, I will say
that HT does work for situations like this. On a single core system,
if one process takes up enough processing power, the rest of the
system slows to a crawl, especially if it's choking on some disk IO.
On the HT system, the virtual processor was capable of allowing the
rest of the processes and programs to more or less remain responsive
even if overall speed was affected.
Maybe you should take your machine back to the vendor.

Just on the basis of this? :P I'm pretty willing to bet my machine
will outdo yours on various other benchmarks. After all, mine did do
better on the 33mpix test with 14s vs your 22s. Would you then bring
your system back to your vendor and complain about it? I'm sure if
either of us did that, your vendor will either laugh his/her head off
or bang it against the wall asking why did they get this kind of
client :pPPp
 
The said:
I had a HT system for a while and from that experience, I will say
that HT does work for situations like this. On a single core system,
if one process takes up enough processing power, the rest of the
system slows to a crawl, especially if it's choking on some disk IO.
On the HT system, the virtual processor was capable of allowing the
rest of the processes and programs to more or less remain responsive
even if overall speed was affected.

HT is the poor man's multiprocessor system, but it's good enough to
make the system more responsive, as you observe. If you have very
different threads running at the same time, it can also come close to
a true multiprocessor system.

I note that PS 5.0.2, at least, does not use more than one processor.
Just on the basis of this? :P

Well, it all sounds very weird.
After all, mine did do
better on the 33mpix test with 14s vs your 22s. Would you then bring
your system back to your vendor and complain about it?

Well, since I built it myself, I'd have only myself to blame.
I'm sure if
either of us did that, your vendor will either laugh his/her head off
or bang it against the wall asking why did they get this kind of
client :pPPp

Depends. Some PC salespeople are so stupid that they would probably
take it back, thinking there's something wrong with the machine.
 
Yeah we have one of those, Problem is, the owner died, and guess
what? Now the son is the owner. He comes in and makes big decisions,
such as "we need plants outside" and "lets put fancy signs on the
building". Jeez.

Wot... no salt-water tropical fish tank in the err, reception foyer?:-)
 
There isnt, you're desperately
attempting to bullshit your way out of your predicament and
fooling absolutely no one at all, as always.


I'm quite content to have you think that Rod, and plenty of
people were quite happy to have a quieter fan instead.
Perhaps your subjective opinion of "quiet" means anything
less than 30% of the noise a hair dryer produces, but to
others if the CPU isn't particularly high heat, quiet would
mean "can I hear it without trying to".

I happened to pull out another P3 fan yesterday as it just
happened to be within arm's reach and I'd needed a temporary
airflow for testing passive cooling a C3 (simulation of a
PSU intake flow). The fan was far louder than anything I
have running, cooling video cards, overclocked CPUs,
chipsets, etc. Pathetic really, didn't even move half the
air of fans far far quieter. For the record this particular
fan was Nidec-made and rated for 0.13A, and like all the
others it's problems were that it was too thin, too high an
RPM, bearings and hub too small.

Disagree all you want but more than anything it shows just
how little you realize how quiet a system can actually be if
you think that era of intel fan was quiet.

There's nothing desperate about plugging in a fan and
noticing how loud it is. Same as observed by many many
people for many years. All except a handful including Rod.
Oh well, I'm done arguing about it because nothing you or I
write will change the noise level.
 
Not superior, just a better purchase.

Arguable, P4 needed software optimizations to even keep up
most of the time. Benchmarks belie this by always testing
newest versions of app even when most people don't run
newest versions, it'd cost several thousand addt'l per year
to do that.
 
Every upgrade will change _something_, but in the world of
microcomputers, the role of processor speed in overall performance has
been dramatically exaggerated for many years. Today, processor speed
is not the problem.


For many common tasks it is not the bottleneck. That
doesn't diminish it as a bottleneck for other tasks.

Gaming isn't so uncommon, nor is video capture, editing,
on-the-fly compression for burning DVDs. Remember Win MCE?
Plenty of OEMs sell it, relatively unsophisticated users are
now doing things they never could before because of the CPUs
we have today. Most of the time the CPU is nowhere near
100% utilized but for milliseconds at a time, it helps.
 
Back
Top