Why Pentium?

You must have misunderstood my sentence because that they didn't 'stop
doing something', or consuming power (possibly current latch-up too), is
why they stayed hot till power was removed.

 

The same as "what" exactly? I've no idea what you mean by "classic" but
the field of Operations Research & Management Science is rich with
specialized software... anything from bare tools to integrated vertical
solutions.

The tools do not need to be created and are available from umm, vendors...
who err, specialize in such stuff. The bare tools, e.g. simulation, LP,
etc. and modelling in general, are not industry specific and can be applied
to *any* enterprise; if the buyer lacks the expertise to actualize his
model/solution, like I said there are vertical, integrated solutions which
are applicable.

 

Family businesses are often umm, problematic. There are, however many
different tools just sitting around waiting to be discovered by people who
need them, even smallish enterprises. As an example, from someone who
posts in in c.s.i.p.h.c., there's SizeFitter by Johannes Andersen
http://sizefitter.com - I figure there are thousands, if not millions, of
businesses which could make profitable use of this tool. The only trouble
is that the potential buyer often doesn't realize he has a "problem" which
has a better "solution".

BTW I am not an associate of Johannes - I just think his tool is very
elegant, clever and probably under-utilized.

 

AMD is not the one who burned you and their current CPUs have been superior
for ~3 years.

Intel's have claimed to shutdown and/or throttle since the P!!!s IIRC,
though it didn't always help. AMD processors don't "continue to run" any
longer and run considerably cooler even at full tilt - you're missing out
on safety & energy waste.

Defective? That would mean that every PC processor made before Intel
succeeded with its thermal triggers "defective". Uhh, it's not the
processor which was a fire hazard and would fail to get UL rating, if
that's the case, but the system.

I have one in the office which has been running happily for 4-5 years -
sounds to me like you found an OEM who did not use the AMD boxed fan and
cheaped out with a POS to coax a few $$ into his margin.

 

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.

 

Not superior, just a better purchase.

 

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?

 

Intel CPUs work just fine. I see no reason to change.

I don't want to waste safety or energy.

If other processors already had it, yes.

Yes, that's what UL told me. Lucky for AMD.

I've already mentioned that it was not the stock fan. It was a very
cheap sleeve-bearing fan and a cheap heatsink. The manufacturer was
SonBook. The CPU fan on one of the machines failed a few days after I
got it. Another took about two weeks, and I think a third lasted for
almost a year. Worse yet, the failing fans would turn when first
turned on, but would stop shortly thereafter, so when I first checked
things, it looked like all the fans were running.

There were other shortcuts in the machines. The CPU was almost behind
the PSU, so even with the fan running, it was still hot. The
components were not top quality. After the SonBook fiasco, I started
building my own machines.

 

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.

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.

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.

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.

Well, I don't know why it is so slow for you, then. It works fine for
me.

 

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.

I don't spend my day applying filters, that's for sure. I leave that
for the newbies and the high-school kids.

 

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.

 

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.

 

I don't set process priorities on a desktop machine, nor do I
recommend that anyone else do so.

 

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.

 

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.

 

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

I doubt that is the case since the A64 is basically a 32bit K7
extended.

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.

3.3s for me

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

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.

 

That is very strange indeed. That's almost twice the amount of time
required on my machine.

I agree, but maybe there is something strange about the radial filter.

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).

Maybe you should take your machine back to the vendor.

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.

 

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 [email protected] 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.

 

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.

Large timesharing operating systems (such as UNIX) long ago became
very good at this type of thing.

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.

 

Uhh, better performance at lower temp, better thermal management, quieter
== superior.