Welcome, Guest. Please login or register.

Author Topic: p4 too slow ?  (Read 2615 times)

Description:

0 Members and 1 Guest are viewing this topic.

Offline KennyR

  • Hero Member
  • *****
  • Join Date: Mar 2002
  • Posts: 8081
    • Show only replies by KennyR
    • http://wrongpla.net
Re: p4 too slow ? YES!
« Reply #14 from previous page: August 19, 2002, 04:26:10 AM »
Segemented memory addressing makes assembly language a nightmare, so the current situation is that high level language compilers are compiled by other high level compilers, and software doesn't get the asm optimisation it should. Therefore, x86 software gets slower, more bloated and less efficient as time goes on. I compiled HelloWorld.c on visual basic with a fairly basic set of includes in uni and it was 56KB. Combine this inefficiency with the huge instruction decoding time of the x86 and you have a CPU that is propped up only by mounting clock speeds and bigger coolers. Er, no thanks.

On the other hand, PPC asm is a comparitive breeze. The exe's are big, because it is RISC code and needs more instructions, but its a great deal more efficient. It doesn't have 200 extra instructions no-one ever uses, so the decoding time is measured in picoseconds rather that nanoseconds. PPC is a lot better than x86, period.
 

Offline Munchkin

  • Sr. Member
  • ****
  • Join Date: Mar 2002
  • Posts: 287
    • Show only replies by Munchkin
    • http://www.sjolin.eu
Re: p4 too slow ?
« Reply #15 on: August 19, 2002, 06:18:07 AM »
Quote
here some people turn that way, too. i think the only place to live without these will be outer space (ie. the moon could be a rather good place  )  


Oh! I'm really considering this! As soon it is possible I'll try... the problem is just this: The most likely thing that will happen there is that a lunar colony will be under american jurisdiction... so the problem won't go away.. However, I can build myself a small igloo of moon-rock somewhere out in the nowhere or something LOL
 

Offline Hammer

  • Hero Member
  • *****
  • Join Date: Mar 2002
  • Posts: 1996
  • Country: 00
    • Show only replies by Hammer
Re: p4 too slow ?
« Reply #16 on: August 19, 2002, 09:30:04 AM »
On my personal experience;

Running Oracle 9(e.g. transactions) with a Pentium 4 1.6 Ghz* with 1Gb RDRAM memory will use roughly 50 percent of processor’s capacity.

Running Oracle 9(e.g. transactions) with an Athlon XP 1.6 Ghz* with 1Gb DDR memory will will use roughly 25 percent of processor’s capacity.

Both has the same HD and OS (i.e. Windows 2000 Pro).

*denotes test bed PCs.

With SiSoftware Sandra 2002 Pro’s benchmarks, it indicates to us that Pentuim4’s FPU performance is poor.  My backup Celeron 500A Mhz PC will beat Pentuim4’s FPU performance @ 1.2 Ghz.

The speed increase is mostly from the use of SSE i.e. nVidia’s drivers, MS’s DirectX 8 and some other mpeg2/mpeg4/mp3/DIvx based software supports these instructions.
Amiga 1200 PiStorm32-Emu68-RPI 4B 4GB.
Ryzen 9 7900X, DDR5-6000 64 GB, RTX 4080 16 GB PC.
 

Offline Hammer

  • Hero Member
  • *****
  • Join Date: Mar 2002
  • Posts: 1996
  • Country: 00
    • Show only replies by Hammer
Re: p4 too slow ?
« Reply #17 on: August 19, 2002, 09:37:09 AM »
Quote
I have one p4 1800mhz sitting here, one amd 1.4ghz both has sdram 133mhz, the p4 is way slower than the amd, even the ram BW is lower, though the p4 has 400mhz fsb... While the athlon has only 266. That tells something about how crappy those p4 chips is.  

Have you considered the number of bits in it’s bandwidth?
Amiga 1200 PiStorm32-Emu68-RPI 4B 4GB.
Ryzen 9 7900X, DDR5-6000 64 GB, RTX 4080 16 GB PC.
 

Offline Hammer

  • Hero Member
  • *****
  • Join Date: Mar 2002
  • Posts: 1996
  • Country: 00
    • Show only replies by Hammer
Re: p4 too slow ? YES!
« Reply #18 on: August 19, 2002, 10:08:45 AM »
Quote
This has been common knowledge for some time. Many PC users said that the best Pentium was III,
.

That would be dependant on the application being use.

Quote

and of course its pretty obvious AMD CPUs were always faster MHz to MHz.
.

As proven with wide range of legacy/ISA x86 only applications (i.e. mostly non-SSE2 software).

Quote

And of course, a CPU that struggles to match a G4 clocked at half the cycles is in severe trouble.
.

You wouldn't be saying that if the benchmarks and applications were running
OpenGL programs (e.g. Quake3) with all the platforms fitted with the same video card(i.e. Geforce 4 4600).

Quote

And of course, a CPU that struggles to match a G4 clocked at half the cycles is in severe trouble.
.

Which processors are you referring too (i.e. AMD or Intel)?  

Quote

Combine that with legacy segmented memory addressing
.

Ever since the 386, it has "linear 32-bit address base" capability. The problem is with MS’s 16bit OSs

Reference;
http://www.lowendpc.com/tech/386.shtml

Quote

and an idiotic interrupt system fit only for the trash,
.

WinXP handles IRQ's problems pretty well, even with plenty of devices plugged in i.e.
1. Dual channel Promise RAID controller (PCI).
2. Four port USB controller (PCI),
3. AC97 sound card (PCI).
4. Sblive 5.1(PCI).
5. Realtek 10/100 LAN card (PCI).
6. nVidia Geforce 4, 4400 with VIVO capability(AGP).
(PS my PC mobo has no ISA slots)

Vmware solves most of my legacy application needs.  

Quote

I'm glad Amiga went the PPC route. Ok, they went there half-assed, but they went there.

Most of your statements are pretty shallow…
Amiga 1200 PiStorm32-Emu68-RPI 4B 4GB.
Ryzen 9 7900X, DDR5-6000 64 GB, RTX 4080 16 GB PC.
 

Offline Hammer

  • Hero Member
  • *****
  • Join Date: Mar 2002
  • Posts: 1996
  • Country: 00
    • Show only replies by Hammer
Re: p4 too slow ? YES!
« Reply #19 on: August 19, 2002, 10:13:22 AM »
Quote
It'd be interesting to know if that would work at all

DOS 6.22 works fine with Pentium 4 1.6Ghz i.e. for boot disk usage.
Amiga 1200 PiStorm32-Emu68-RPI 4B 4GB.
Ryzen 9 7900X, DDR5-6000 64 GB, RTX 4080 16 GB PC.
 

Offline Hammer

  • Hero Member
  • *****
  • Join Date: Mar 2002
  • Posts: 1996
  • Country: 00
    • Show only replies by Hammer
Re: p4 too slow ? YES!
« Reply #20 on: August 19, 2002, 10:26:56 AM »
Quote
I compiled HelloWorld.c on visual basic with a fairly basic set of includes in uni and it was 56KB. Combine this inefficiency with the huge instruction decoding time of the x86 and you have a CPU that is propped up only by mounting clock speeds and bigger coolers. Er, no thanks.

Are you referring to Visual C or Visual Studio instead of Visual Basic?  

You getting it mixed up with OS and hardware issues.

Can you apply that the same argument on Tao's native mode VP/Intent technologies in regards to binary size?  

Note that latest AROS’s Workbench disk(e.g. 32bit GUI OS) fits on one disk....

Why not you compare PPC Linux complied MAME vs x86 Linux complied MAME?
Amiga 1200 PiStorm32-Emu68-RPI 4B 4GB.
Ryzen 9 7900X, DDR5-6000 64 GB, RTX 4080 16 GB PC.
 

Offline Hammer

  • Hero Member
  • *****
  • Join Date: Mar 2002
  • Posts: 1996
  • Country: 00
    • Show only replies by Hammer
Re: p4 too slow ? YES!
« Reply #21 on: August 19, 2002, 10:37:00 AM »
Quote
On the other hand, PPC asm is a comparitive breeze. The exe's are big, because it is RISC code and needs more instructions, but its a great deal more efficient. It doesn't have 200 extra instructions no-one ever uses,

That's a load of BS. Both late release nVidia drivers  and MS's Direct 8.x uses MMX, 3DNow, SSE and SS2.
The claim that "no-one ever uses " is a load of BS.

Quote

so the decoding time is measured in picoseconds rather that nanoseconds. PPC is a lot better than x86, period.

Does that deliver real life solutions?
Amiga 1200 PiStorm32-Emu68-RPI 4B 4GB.
Ryzen 9 7900X, DDR5-6000 64 GB, RTX 4080 16 GB PC.
 

Offline Hammer

  • Hero Member
  • *****
  • Join Date: Mar 2002
  • Posts: 1996
  • Country: 00
    • Show only replies by Hammer
Re: p4 too slow ? YES!
« Reply #22 on: August 19, 2002, 10:46:30 AM »
Quote
for this reason even the new 64bit hammer has got funny things like the well known a20 gate ...

AMD likes to protect customer’s software investments, while delivering some increase in performance.  But if the customer wants to have the full performance increase, then they must purchase or recompile new software.

AMD’s K8 solution offers the “best of both world” in relations to the customer’s needs and wants.
Amiga 1200 PiStorm32-Emu68-RPI 4B 4GB.
Ryzen 9 7900X, DDR5-6000 64 GB, RTX 4080 16 GB PC.
 

Offline Cluke

  • Jr. Member
  • **
  • Join Date: May 2002
  • Posts: 68
    • Show only replies by Cluke
    • http://www.cluke.demon.co.uk/shatner.html
Re: p4 too slow ? YES!
« Reply #23 on: August 19, 2002, 06:18:59 PM »
Quote
On the other hand, PPC asm is a comparitive breeze. The exe's are big, because it is RISC code and needs more instructions, but its a great deal more efficient. It doesn't have 200 extra instructions no-one ever uses, so the decoding time is measured in picoseconds rather that nanoseconds. PPC is a lot better than x86, period.


It may be, but RISC chips like the PPC are not really intended for direct machine language programming, due to the increased amount of instructions (and thus increased program design complexity) it takes to do anything. It's designed to make writing higher-level compilers easier...
 

Offline Kronos

  • Resident blue troll
  • Hero Member
  • *****
  • Join Date: Feb 2002
  • Posts: 4017
    • Show only replies by Kronos
    • http://www.SteamDraw.de
Re: p4 too slow ? YES!
« Reply #24 on: August 19, 2002, 09:21:50 PM »
Kenny Kenny Kenny (/me shacks head  :-P )

Every x86-CPU since the 386 can be used in "386-mode" with
4Gb linear memory, and every moderm OS runs in that mode.

The only real prob with the x86 (when coding in asm) is the lack
of multi-purpose registers, but who is doing anything useable
in asm these days ?

The x86 may not be elegant, but they are cheap, fast and quite reliable.

An AthlonXP has a RISC-core and a builtin translator for the
"normal" x86-code, while a G4+Altivec isn't really RISC any more.

Oh and and "Hello World" with Linux-gcc (no optimization)
is 13463 bytes ......
1. Make an announcment.
2. Wait a while.
3. Check if it can actually be done.
4. Wait for someone else to do it.
5. Start working on it while giving out hillarious progress-reports.
6. Deny that you have ever announced it
7. Blame someone else
 

Offline KennyR

  • Hero Member
  • *****
  • Join Date: Mar 2002
  • Posts: 8081
    • Show only replies by KennyR
    • http://wrongpla.net
Re: p4 too slow ? yes, and broken ;)
« Reply #25 on: August 20, 2002, 02:21:10 AM »
Isn't it strange that it seems to be Amithlon users/wanters that defend the x86? :-D Personally, I think that the only positive point of the x86 is low price. Other CPUs do the job more elegantly and better.

And yes, Kronos, people do still use asm optimisation and coding, just not on the x86. For other platforms, using visual basic to compile a new compiler would be unthinkable.

Ok, anyway: you mention all the special things that have been done to shore up the basic 8086 legacy problems. And they seem to be very effective, but there is a limit to how far you can push. You build your foundations on the sand, and no matter how well you build your house, it will collapse in the end. This is the cold, hard truth in the end, no matter how many billions of dollars and millions of man-hours you spend.
 

Offline Kronos

  • Resident blue troll
  • Hero Member
  • *****
  • Join Date: Feb 2002
  • Posts: 4017
    • Show only replies by Kronos
    • http://www.SteamDraw.de
Re: p4 too slow ? yes, but it's gone stay.
« Reply #26 on: August 20, 2002, 04:07:59 AM »
@KennyR

If you put all the legacy-stuff in to an mircrocode-based
emu, you can use the same technology as if you didn't have
any legacy-stuff to bother about.

That is what happening in both Intel's and AMD's new 64-bit-CPUs.

Once they have reached that point, they can throw their billions
at buliding faster cores.

How much money can Moto or IBM throw at high-speed-CPUs
before they start making a loss ?
And how much will one single CPU cost if they have to get the
same money back as Intel, but sell only far lower numbers ?

No I don't like x86, but I've heard this "x86 is at an end"-BS for
well over 10 years now, and I don't see any reason why it should
happen now, when it did not happen back when Intel had their probs
with the 1st Pentiums, while "better" alternatives from Moto
(68060/PPC) were available.
1. Make an announcment.
2. Wait a while.
3. Check if it can actually be done.
4. Wait for someone else to do it.
5. Start working on it while giving out hillarious progress-reports.
6. Deny that you have ever announced it
7. Blame someone else
 

Offline Hammer

  • Hero Member
  • *****
  • Join Date: Mar 2002
  • Posts: 1996
  • Country: 00
    • Show only replies by Hammer
Re: p4 too slow ? yes, and broken ;)
« Reply #27 on: August 20, 2002, 01:52:49 PM »
Quote
Isn't it strange that it seems to be Amithlon users/wanters that defend the x86?

It’s basically a form of protest against Motorola and IBM for their apparent  lack of progress.

What happens if AMD or Intel controls PowerPC as their secondary CPU line instead of MIPs or ARM respectively?

Can IBM and Motorola complete directly these highly completive companies?

Do you realize that Motorola’s Strong-Arm CPU series are already behind Intel’s StrongARM in terms of clock speed?  

Motorola basically contributed on killing most of 68k desktopOS platform by making it harder for desktopOS vendors to provide a cheap high-speed solution. CPU transition didn't things against the completion coming from x86 based desktop OS.  

What happens if the old Commodore-Amiga selected an i80386 instead of MC68000? That is, imagine a 80s A500 machine with OCS with an 80386 CPU(and also includes a 32bit preemptive multitasking multimedia OS).

We may have WinXP/nVidia/ATI style PC box back in the 80s. MS may not have chance to develop their OS on x86 platform.

Quote
I think that the only positive point of the x86 is low price.

At least x86 manufactures recognize that money doesn't grow on trees.

Remember, Amiga’s original success is partly due to good performance and relatively cheap hardware prices i.e. A500/A1200 style products.

Quote

Other CPUs do the job more elegantly and better.

That would dependant on what types of job i.e. running legacy applications.  

Quote
And yes, Kronos, people do still use asm optimisation and coding, just not on the x86. For other platforms, using visual basic to compile a new compiler would be unthinkable.

What is the proportion of IT programmers would be involved with "on metal" programming?

"Visual Basic" focuses on delivering RAD(Rapid Application Development) and concentrates more on the business problem and business solutions.  

Try Borland Builder products, if you want a reasonability fast efficient object code and Visual Basic style learning curve.

Quote

Ok, anyway: you mention all the special things that have been done to shore up the basic 8086 legacy problems.
.

Modern x86 has a glorified x86 emulator engine for their “front end”.

Note that PPC achieves legacy compatibility in software* instead of hardware.

*referring 68k based software.
Quote

And they seem to be very effective, but there is a limit to how far you can push.
.

Define those limits.

Refer to
http://www.macosxhints.com/article.php?story=20020113045343563

This shows some integer benchmarks between the different architectures.

=========================================
iMac G4 700MHz --

sign verify sign/s verify/s
rsa 512 bits 0.0036s 0.0004s 275.2 2826.6
rsa 1024 bits 0.0198s 0.0012s 50.6 847.8
rsa 2048 bits 0.1438s 0.0043s 7.0 230.7
rsa 4096 bits 1.0040s 0.0159s 1.0 62.9

sign verify sign/s verify/s
dsa 512 bits 0.0033s 0.0041s 301.0 245.8
dsa 1024 bits 0.0118s 0.0147s 84.8 68.2
dsa 2048 bits 0.0421s 0.0503s 23.7 19.9
=========================================
K6-3 450Mhz

K6-3 450Mhz 320Mb ram P100 cas2
slackware linux, 8.1 2.4.19 kernel

sign verify sign/s verify/s
rsa 512 bits 0.0039s 0.0003s 254.6 2914.7
rsa 1024 bits 0.0210s 0.0011s 47.6 925.9
rsa 2048 bits 0.1292s 0.0037s 7.7 270.5
rsa 4096 bits 0.8675s 0.0132s 1.2 75.6

sign verify sign/s verify/s
dsa 512 bits 0.0036s 0.0043s 278.5 234.9
dsa 1024 bits 0.0109s 0.0131s 92.0 76.1
dsa 2048 bits 0.0363s 0.0447s 27.5 22.4
=========================================
Focus on rightmost column.  

K6-III 450Mhz pretty much equaling G4 700MHz on this type application.  

Quote

You build your foundations on the sand, and no matter how well you build your house, it will collapse in the end.

I wonder which CPU type bring in the money...

Quote

This is the cold, hard truth in the end, no matter how many billions of dollars and millions of man-hours you spend.

Where is your facts to support your case?
Amiga 1200 PiStorm32-Emu68-RPI 4B 4GB.
Ryzen 9 7900X, DDR5-6000 64 GB, RTX 4080 16 GB PC.