Quote:

That is something.
I didn't think they'd need it, but "We do have the X5000 firmware source code...", hmm, sounds like someone is getting first rate support from the manufacturer.

I'm impressed.
So, uh, Kenny...how's that affect your theory? ;)

Quote:

It doesn't. The X5000 is still being sold to public with the original firmware, and so far nobody's commented on the legality of changing it.

Quote:

- No
- No
- No, but I requested modified firmware from Bigfoot and he was kind enough to make me one. My one has logo removed, removed double checking drives so it's much faster while booting.

>> In order to run MorphOS on your X5000:
>> - did you have to install a firmware binary patch, or
>> - does your X5000 have to execute a firmware runtime patch, or
>> - do you have to use another firmware than the one provided by A-Eon?

> - No
> - No
> - No

Thanks for the clear answer.

Quote:

I disable that when its used in PC bios myself so that makes sense, and what was removed could even be replaced.

Quote:

Quote:

I disable that when its used in PC bios myself so that makes sense, and what was removed could even be replaced.

Quote:

Obviously, if the source was supplied by the manufacturer, changing it is not an issue.

"feel free to continue speculating" :) +1!





[ Edited by Jim 13.10.2016 - 08:21 ]

Addendum:

>> dnetc: [...]
>> AmigaMARK: [...]
>> nbench: [...]
>> Stream: [...]

> I prepared a relative comparison with my 1.5 GHz Mac mini G4. The following list
> shows the performance of your 2.0 GHz X5000/Cyrus/P5020 compared to my
> 1.5 GHz Mac mini/MPC7447A (=1.00) at the leftmost position, then the scaled
> per-clock performance comparison, and the name of the specific test at last position.

Comparison of 2.0 GHz X5000/Cyrus/P5020 with my 2.3 GHz PowerMac G5/PPC970FX (=1.00):

dnetc

0.99 | 1.14 : KOGE 3.1 Scalar
1.05 | 1.20 : MH 2-pipe
0.98 | 1.13 : KKS 2-pipe
1.10 | 1.27 : KKS 604e
1.22 | 1.40 : MH 1-pipe
1.20 | 1.38 : MH 1-pipe 604e

AmigaMARK CPU

1.30 | 1.49 : BogoMIPS ppc-assembler inline
1.03 | 1.19 : Dhrystones
0.80 | 0.92 : 40th Fibonacci number
0.64 | 0.74 : FPU query [Double Precision] - Al Aburto
0.78 | 0.89 : LibJPEG - libjpeg [v6b]
0.95 | 1.10 : Mars chiper
1.34 | 1.55 : MD5 checksuming (RFC 1321) L. Peter Deutsch
1.10 | 1.26 : MP3 -> CDDA [mpega.library]
1.04 | 1.20 : Serpent chiper
0.74 | 0.85 : ZLib functions [v1.1.4]
0.94 | 1.08 : TOTAL CPU

AmigaMARK Memory

1.32 | 1.52 : Read CPU-Cache
0.31 | 0.36 : Read FAST byte [8]
0.30 | 0.35 : Read FAST word [16]
0.42 | 0.49 : Read FAST long [32]
0.35 | 0.40 : Write FAST byte [8]
0.36 | 0.42 : Write FAST word [16]
0.48 | 0.56 : Write FAST long [32]
0.43 | 0.50 : Copy FAST 2 FAST
0.76 | 0.87 : Allocate Memory FAST
1.30 | 1.50 : Initialize Memory FAST
0.60 | 0.69 : TOTAL MEM

nbench

1.35 | 1.55 : NUMERIC SORT
0.74 | 0.85 : STRING SORT
1.17 | 1.34 : BITFIELD
0.93 | 1.07 : FP EMULATION
0.74 | 0.86 : FOURIER
0.93 | 1.07 : ASSIGNMENT
1.25 | 1.44 : IDEA
1.04 | 1.19 : HUFFMAN
0.68 | 0.78 : NEURAL NET
0.55 | 0.63 : LU DECOMPOSITION
1.04 | 1.19 : INTEGER INDEX
0.65 | 0.75 : FLOATING-POINT INDEX
0.93 | 1.07 : MEMORY INDEX
1.13 | 1.30 : INTEGER INDEX

stream

0.56 | 0.65 : Copy
0.61 | 0.70 : Scale
0.74 | 0.85 : Add
0.73 | 0.84 : Triad

@Andreas_Wolf

Excuse me for being thick, but with 1.00 being reference the high numbers are faster?

Quote:

I'm also not entirely sure what these numbers are supposed to be, but you have "integer index" listed twice with two different values.

> with 1.00 being reference the high numbers are faster?

Yes, 1.00 being reference means that higher numbers are faster and lower numbers are slower.

> you have "integer index" listed twice with two different values.

Yes, nbench outputs two integer indexes and two floating-point indexes for the reason explained there:

http://serverfault.com/questions/254684/how-do-i-interpret-bytemark-nbench-results

The two floating-point indexes are proportional between compared machines, that's why I only list it once. That's however not the case for the two integer indexes, hence I list them both.

Quote:

Well that confirms my fears that the Cyrus/X5000 can't top a 12 year old PowerMac in speed, and that is not even taking the lack of Altivec into account. That seems to be the last chance for a PPC platform to beat a PowerMac, not happening. Looks like I'll be staying with my G5 2.7Ghz until the switch to MorphOS-NG.

> that confirms my fears that the Cyrus/X5000 can't top a 12 year old PowerMac in speed

To me, it confirms that overally it beats the 2.3 GHz PowerMac G5 in non-SIMD integer operations.

Quote:

I thought that the first numbers were for the X5000, and second numbers were for the 2.3GHz G5, making the results that the G5 is faster in all tests? Didn't your message list the X5000 first, then the G5, before the listing of all the test results?

Quote:

Quote:


Quote:

Now you completely lost me. Have you been drinking?

> I thought that the first numbers were for the X5000, and second numbers were
> for the 2.3GHz G5 [...]?

No, the G5 is, as I wrote, scaled to 1.00. To quote from my benchmark posting which in turn quotes from my January benchmark posting (with Mac mini G4 back then, updated results) that already used the same scheme:

"The following list shows the performance of your 2.0 GHz X5000/Cyrus/P5020 compared to my 1.5 GHz Mac mini/MPC7447A (=1.00) at the leftmost position, then the scaled per-clock performance comparison, and the name of the specific test at last position."

>> To me, it confirms that overally it beats the 2.3 GHz PowerMac G5 in
>> non-SIMD integer operations.

> Now you completely lost me.

Of the previously posted benchmarks, the following are CPU-bound integer ones (there're probably more, but those are the ones I'm sure of):

dnetc

0.99 | 1.14 : KOGE 3.1 Scalar
1.05 | 1.20 : MH 2-pipe
0.98 | 1.13 : KKS 2-pipe
1.10 | 1.27 : KKS 604e
1.22 | 1.40 : MH 1-pipe
1.20 | 1.38 : MH 1-pipe 604e

AmigaMARK CPU

1.30 | 1.49 : BogoMIPS ppc-assembler inline
1.03 | 1.19 : Dhrystones

nbench

1.35 | 1.55 : NUMERIC SORT
0.74 | 0.85 : STRING SORT
1.17 | 1.34 : BITFIELD
0.93 | 1.07 : FP EMULATION
0.93 | 1.07 : ASSIGNMENT
1.25 | 1.44 : IDEA
1.04 | 1.19 : HUFFMAN

As you can see, my 2.3 GHz PowerMac G5 is slower in 67% of cases. (And regarding per-clock non-SIMD integer performance, the PowerMac G5 is slower in 93% of cases.)

I feel comfortable enough with the benches to have decided to replace my G5s with a P5040 based X5000 (when available).
Enough that I have parted out my 2.7 GHz system.
I retained a 2.5 GHz quad core PCIe G5 for benchmark comparisons.
But even that will be closely matched by the previously mentioned X5000 while drawing a fraction of the power.

These WILL be good (if albiet expensive) systems to run MorphOS on.

Is it just me or does the benchmark differences not look all that impressive? It's faster yes, but for the most part not all that much.

> It's faster yes

...for (non-SIMD) integer operations. For floating point and memory speed, it seems to be the other way round.

Quote:

If it wasn't that expensive it could make a nice G5 replacement system. Same speed league as the G5, but low energy uptake and new board (no leaky cooling, no dust, fresh caps, etc.). But for that price...

Quote:

Looking at it through 2016-glasses, I'd say it's about on par with all other PPC stuff from more than a decade ago. Who cares what is slightly faster or slower in one or another area of mesurement, when the situation in total is so off the charts behind? The rest of the world moved several dimensions ahead since these performance levels were relevant in desktop computing.


Quote:

Hm yeah, and SIMD, floating point and memory are kind of essential for many day to day things, like codex encoding/decoding and other "multimedia" situations, not to mention rendering, image processing, etc.

Can the X5000 (single core) decode and display 1080p x.264 streams in CPU/SW?


Quote:

But *it is* that expensive! So the "if only" kind of falls flat...

> Who cares what is slightly faster or slower in one or another area of mesurement [...]?

Some people who raised their voice in this thread certainly do.

>> If it wasn't that expensive [...]. But for that price...

> But *it is* that expensive!

That's exactly what Zylesea said.

Quote:

Looking through your 2016-glasses, you should have seen that this is irrelevant today. Can any phone, tablet or low end X64 system decode video without the task being handled by dedicated hardware?

Both OS4 and MorphOS run on systems that give access to dedicated video decoding hardware and should be moving in that direction too, regardless of how important raw CPU speed may or may not be.

[ Edited by rob 30.10.2016 - 17:49 ]