@matthey

Quote:

It's not clear to me. A tightly coupled OS to a narrow range of standardized hardware is more efficient. This is part of the reason why inferior specked consoles have respectable performance. The trick is controlling the hardware so that a manufacturer or intellectual property holder can't pull the hardware out from under your feet. This is much easier today with cheap FPGAs

Efficiency is important in many specialized contexts when the applications demand it.

Applications... as in software.

The AmigaOS was tied to a boat anchor that all of the other rats started abandoning in 2004.

@itix

Quote:

Endianess is not big deal but 68k compatibility is lost in the process.

And yet there are already many existing solutions for ensuring compatibility.

The problem isn't just the hardware - it's the OS.

@pavlor

Quote:

pavlor wrote: @cdimauro Quote: You also like to report Doom results to compare platforms performances, even using emulators, and... emulators inside emulators... And in nearly every of my Doom related posts I add caution that Doom benchmarks both GFX and CPU.

Nevertheless, you use videogames as benchmarks to measure performance of CPU also (and, BTW, it's not true the usually you report them as CPU + GFX benchmark).

So, may I suggest you to completely avoid them, since there's such strong dependency between CPU and the graphic card?

A solution might be to compare videogames which are only software rendered, but you know what?

There's still an underneath o.s. which is running and serving the game requests through its exposed APIs. Which is quite normal, since ANY application makes use of them, so you cannot simply turn off the o.s.. In a real world the o.s. is there, takes it's time itself and for serving applications requests: you have to deal with it.

But the most important thing is that people don't care a single penny of benchmarks using software rendering. They use games in the normal way that have to be used: with the graphic card having a big role.

So, the only reasonable way to test a videogame is as it's normally done: with the whole system. CPU + GPU/GFX + o.s..

In the reported benchmark it's easier, because all systems used the SAME GPU. So the only variables left are CPU and o.s. (because the driver is done by the same entity: GPU vendor).


@all: regarding the PowerPC endianess question, 1Mouse was clearly referring to the porting of OS4 to x64. In this case there's no other chance for PowerPC of running in the normal way: big endian. Here comes my answer to him.

@Zylesea

Quote:

Zylesea wrote: @iggy Quote: iggy wrote: @tlosm Are you guys even sure of your facts? After all, MorphOS runs on the G5. 68k is BE and so is MorphOS. Hence, no prob on the 970. The endian issue is/was the major show stopper to another ISA while maintaining legacy binary compability. http://via.i-networx.de/q86.htm

Very good paper, albeit it's old.

Only one point which is not clear:

"Addition of full memory protection is of course debateable, too."

Why?

@cdimauro

because of this

https://www.youtube.com/watch?v=G4Jht1Gm-x0

_________________
I love Amiga and new hope by AmigaNG
A 500 + ; CDTV; CD32;
PowerMac G5 Quad 8GB,SSD,SSHD,7800gtx,Radeon R5 230 2GB;
MacBook Pro Retina I7 2.3ghz;
#nomorea-eoninmyhome

@tlosm: full memory protection has NOTHING to do with Intel. It's an o.s. feature!

Of course, it needs that the processor offers something to achieve it, but all processors, even 68K (020 + MMU; 68030 to 68060 have an MMU already integrated), has it.

Do you know what's really and totally against the Amiga philosophy? The infamous OS'4 Extended Objects which make use of the ridiculous bank switching technique introduced on the 8-bit age. But I'm pretty sure that here you have nothing to say, right? No "Hyperion outside"...

@cdimauro

Quote:

it's not true the usually you report them as CPU + GFX benchmark

Even in my very first Doom benchmark thread I have link to Doom benchmark description page, which states:

Note that performance is not only determined by processor, video card, and motherboard but also by the sound system, the memory manager, the mouse driver and the disk performance (e.g. SMARTDRV). In particular, some of the faster results reported were achieved without sound.

Quote:

So, may I suggest you to completely avoid them, since there's such strong dependency between CPU and the graphic card?

If you know what you benchmark, you may find uses for Doom benchmark (eg. Corto used Doom for measuring of impact of his CPU code improvements in DosBox - there it was nearly pure CPU benchmark).

Quote:

(because the driver is done by the same entity: GPU vendor).

Did you read my link to Phoronix site? Even drivers from the same company had different results on various OSs - runing on the same hardware.

Quake 3 may be used as some sort of CPU benchmark - with same OS and GFX card, but its purpose is to compare 3D games performance (OS/drivers, CPU, GFX card combination).

@pavlor

Quote:

pavlor wrote: @cdimauro Quote: it's not true the usually you report them as CPU + GFX benchmark Even in my very first Doom benchmark thread I have link to Doom benchmark description page, which states: Note that performance is not only determined by processor, video card, and motherboard but also by the sound system, the memory manager, the mouse driver and the disk performance (e.g. SMARTDRV). In particular, some of the faster results reported were achieved without sound.

I haven't said that you never did it. In fact, I used the word "(not) usually".

For example, take a look at your last comments regarding that argument.
Quote:

Quote: So, may I suggest you to completely avoid them, since there's such strong dependency between CPU and the graphic card? If you know what you benchmark, you may find uses for Doom benchmark (eg. Corto used Doom for measuring of impact of his CPU code improvements in DosBox - there it was nearly pure CPU benchmark).

I agree, in this case.
Quote:

Quote: (because the driver is done by the same entity: GPU vendor). Did you read my link to Phoronix site? Even drivers from the same company had different results on various OSs - runing on the same hardware.

Here comes the o.s., and I've already reported it as one of the variables.
Quote:

Quake 3 may be used as some sort of CPU benchmark - with same OS and GFX card, but its purpose is to compare 3D games performance (OS/drivers, CPU, GFX card combination).

Which is the only important thing for people which wants... to play.

But here you've to decide what to do when you present the benchmark data for such game: do you want to test the game or the processor? For the latter, there's no chance by definition. So, it's better stop to reporting data, because they are misleading people.

@cdimauro

Quote:

So, it's better stop to reporting data, because they are misleading people.

I don´t get it. Isn´t purpose of application benchmark to show, how typical application works on various configurations? It was you, who used Quake 3 as measure of pure CPU performance.

@pavlor. I quote myself, marking some words:

"As you can see, comparing the top x86 machine with the SINGLE G5 one, the MINIMUM difference (worse, of course) is 25%, up to 138% more time spent.

Regarding Quake, they are FPS, so have a different meaning: it's home many frames, in percentage, the G5 lost compared to the x86 machine. Of course, it's negative: it's doing around 50% LESS frames per seconds.

For your joy, I also added the worst x86 machine of the time: the Pentium 4. Which, like the Athlon, never lose a single test against the G5.

Taking the DUAL G5, this machine was able to win only on two tests, and by at most 15%. But in 3 tests it around double slower than the Athlon. The P4 has a similar trend, with only 2 tests lost of maximum 25%."

@cdimauro

Quote:

So, the comparison is valid, and you can see that a single core x86 is able to outperform the dual core G5.

Your post 102 in this very thread...

@pavlor: which doesn't change the picture. In fact, I never stated that it's a pure CPU benchmark.

From the same post:

"Yes, and if the graphic card is the same, then you're testing the CPU, right?"

The fact that the GPU is the same does NOT mean that we are testing ONLY the CPU, because the graphic card is still working, right?

You're testing the (behavior of the) CPU, keeping one variable blocked (because it's the same).

@cdimauro

Quote:

From the same post:

Look few posts back, we both agreed it is even more complicated because of different drivers... thanks for confirming my point.

@pavlor: as I already stated, the drivers are made by the same graphic vendor. Of course they are different, but because of the different o.s..

@cdimauro

Quote:

as I already stated, the drivers are made by the same graphic vendor. Of course they are different, but because of the different o.s..

sorry but on amiga and friends the drivers are not made by the same person and not by vendor... and im sure 100000000% if one day will be an amigaos or mos x86 no vendors will made the video drivers of it...
amen

_________________
I love Amiga and new hope by AmigaNG
A 500 + ; CDTV; CD32;
PowerMac G5 Quad 8GB,SSD,SSHD,7800gtx,Radeon R5 230 2GB;
MacBook Pro Retina I7 2.3ghz;
#nomorea-eoninmyhome

@tlosm: in this context, have we talked of Amiga? No. Absolutely.

Why don't you read the thread before replying?

@cdimauro

Quote:

sorry but on amiga and friends the drivers are not made by the same person and not by vendor... and im sure 100000000% if one day will be an amigaos or mos x86 no vendors will made the video drivers of it... amen @tlosm: in this context, have we talked of Amiga? No. Absolutely. Why don't you read the thread before replying?

why when you dont know how reply write thinks that look like posted by a child for change the cards on a table... ... we are not play poker dont try the bluf like usual

Last edited by tlosm on 13-Dec-2015 at 10:34 AM.

_________________
I love Amiga and new hope by AmigaNG
A 500 + ; CDTV; CD32;
PowerMac G5 Quad 8GB,SSD,SSHD,7800gtx,Radeon R5 230 2GB;
MacBook Pro Retina I7 2.3ghz;
#nomorea-eoninmyhome

@tlosm

Even drivers by the same vendor give different results, I fear we are runing in circles with cdimauro.

Quote:

if one day will be an amigaos or mos x86 no vendors will made the video drivers of it...

Gallium3D is now comparable in speed to proprietary drivers, fast "x86" CPUs could gain far more power from modern graphics cards (eg. Radeon R9 would be bottle-necked by slow CPU on X5000 even with superb drivers).

@tlosm: ROFL. I've replied to everything. It's no me which has problems, here.

Look at your comments, and my replies, which clearly exposes the situation...

@pavlor

Quote:

pavlor wrote: @tlosm Even drivers by the same vendor give different results, I fear we are runing in circles with cdimauro.

The different results come from the different o.ses, which require a different interface with the driver (the frontend). But (roughly speaking) once that the driver gets its data (through the interface provided by the o.s.), the work done is essentially the same (backend).

To be clear, Ati had no interest on losing time and money writing specific code for MacOS X. It's obvious that it recycled as much as possible, and so leaving the backend mostly untouched.

In short: we are still speaking of the o.s. impact.

@pavlor

i dont know . for now i can say only one sure thing the gallium and mesa have no good performance on ppc hardware because the not vendors drivers make a big difference .
i been test it on linux ppc... the old 7800gtx (2005) on osx kill the 4650, 5450 and 6570 hd

on quad g5
quake osx 640x480 870fps 7800gtx
linuxppc not more than 150fps on radeonhd with gallium on linuxppc and full of endianess
and look like the last mesa are much slower than before 10.x

_________________
I love Amiga and new hope by AmigaNG
A 500 + ; CDTV; CD32;
PowerMac G5 Quad 8GB,SSD,SSHD,7800gtx,Radeon R5 230 2GB;
MacBook Pro Retina I7 2.3ghz;
#nomorea-eoninmyhome