MorphOS on AmigaOne X5000?
  • Paladin of the Pegasos
    Paladin of the Pegasos
    Yasu
    Posts: 1724 from 2012/3/22
    From: Stockholm, Sweden
    You could play h264 1080p movies on my 2.7 GHz G5 with about 80% CPU usage or lower. You rarely passed 90%, so I imagine slower G5:s can also play such movie files with no fuss (but with fan going at full speed).
    AMIGA FORUM - Hela Sveriges Amigatidning!
    AMIGA FORUM - Sweden's Amiga Magazine!

    My MorphOS blog
  • »18.01.16 - 13:26
    Profile Visit Website
  • Jim
  • Yokemate of Keyboards
    Yokemate of Keyboards
    Jim
    Posts: 4977 from 2009/1/28
    From: Delaware, USA
    Quote:

    Yasu wrote:
    You could play h264 1080p movies on my 2.7 GHz G5 with about 80% CPU usage or lower. You rarely passed 90%, so I imagine slower G5:s can also play such movie files with no fuss (but with fan going at full speed).


    Since the 2.3 GHz dual core cpu in my PCI-e G5 can be replaced with a single 2.5 GHz dual core cpu module from a quad G5, and the PCIe models bench higher than the AGP models, I'd expect the system I have on hand would be a close match with the system Yasu has mentioned 9but with the added benefit of PCIe expansion slots).

    If the 2.3 and 2.5 GHz G5 PCIe systems match or beat X5000 performance, we may not need an expensive upgrade.

    And, as I have mentioned before, if we really wanted an upgrade we would be looking at an e6500 cored system.
    While running at a lower clock speed, this would have a definite advantage, especially if SMP were enabled.
    "Never attribute to malice what can more readily explained by incompetence"
  • »18.01.16 - 15:36
    Profile
  • Jim
  • Yokemate of Keyboards
    Yokemate of Keyboards
    Jim
    Posts: 4977 from 2009/1/28
    From: Delaware, USA
    glitch resulted in multiple posts


    [ Edited by Jim 18.01.2016 - 12:36 ]
    "Never attribute to malice what can more readily explained by incompetence"
  • »18.01.16 - 15:36
    Profile
  • Jim
  • Yokemate of Keyboards
    Yokemate of Keyboards
    Jim
    Posts: 4977 from 2009/1/28
    From: Delaware, USA
    glitch resulted in multiple posts


    [ Edited by Jim 18.01.2016 - 12:36 ]
    "Never attribute to malice what can more readily explained by incompetence"
  • »18.01.16 - 15:36
    Profile
  • Jim
  • Yokemate of Keyboards
    Yokemate of Keyboards
    Jim
    Posts: 4977 from 2009/1/28
    From: Delaware, USA
    glitch resulted in multiple posts


    [ Edited by Jim 18.01.2016 - 12:37 ]
    "Never attribute to malice what can more readily explained by incompetence"
  • »18.01.16 - 15:36
    Profile
  • Jim
  • Yokemate of Keyboards
    Yokemate of Keyboards
    Jim
    Posts: 4977 from 2009/1/28
    From: Delaware, USA
    glitch resulted in multiple posts


    [ Edited by Jim 18.01.2016 - 12:37 ]
    "Never attribute to malice what can more readily explained by incompetence"
  • »18.01.16 - 15:36
    Profile
  • Jim
  • Yokemate of Keyboards
    Yokemate of Keyboards
    Jim
    Posts: 4977 from 2009/1/28
    From: Delaware, USA
    glitch resulted in multiple posts


    [ Edited by Jim 18.01.2016 - 12:37 ]
    "Never attribute to malice what can more readily explained by incompetence"
  • »18.01.16 - 15:36
    Profile
  • Jim
  • Yokemate of Keyboards
    Yokemate of Keyboards
    Jim
    Posts: 4977 from 2009/1/28
    From: Delaware, USA
    glitch resulted in multiple posts


    [ Edited by Jim 18.01.2016 - 12:38 ]
    "Never attribute to malice what can more readily explained by incompetence"
  • »18.01.16 - 15:37
    Profile
  • Jim
  • Yokemate of Keyboards
    Yokemate of Keyboards
    Jim
    Posts: 4977 from 2009/1/28
    From: Delaware, USA
    glitch resulted in multiple posts


    [ Edited by Jim 18.01.2016 - 12:38 ]
    "Never attribute to malice what can more readily explained by incompetence"
  • »18.01.16 - 15:37
    Profile
  • Jim
  • Yokemate of Keyboards
    Yokemate of Keyboards
    Jim
    Posts: 4977 from 2009/1/28
    From: Delaware, USA
    glitch resulted in multiple posts


    [ Edited by Jim 18.01.2016 - 12:38 ]
    "Never attribute to malice what can more readily explained by incompetence"
  • »18.01.16 - 15:37
    Profile
  • Jim
  • Yokemate of Keyboards
    Yokemate of Keyboards
    Jim
    Posts: 4977 from 2009/1/28
    From: Delaware, USA
    glitch resulted in multiple posts


    [ Edited by Jim 18.01.2016 - 12:39 ]
    "Never attribute to malice what can more readily explained by incompetence"
  • »18.01.16 - 15:37
    Profile
  • Jim
  • Yokemate of Keyboards
    Yokemate of Keyboards
    Jim
    Posts: 4977 from 2009/1/28
    From: Delaware, USA
    glitch resulted in multiple posts


    [ Edited by Jim 18.01.2016 - 12:39 ]
    "Never attribute to malice what can more readily explained by incompetence"
  • »18.01.16 - 15:37
    Profile
  • Priest of the Order of the Butterfly
    Priest of the Order of the Butterfly
    eliot
    Posts: 569 from 2004/4/15
    Hmm,

    ok, but power consumption should more less?
    What about Raytracing?
    MorphOs 3.9 on Mac Mini G4@1.5GHz:

    Cinema4D.png
    regards
    eliot
  • »18.01.16 - 17:37
    Profile
  • Yokemate of Keyboards
    Yokemate of Keyboards
    Andreas_Wolf
    Posts: 12185 from 2003/5/22
    From: Germany
    > if we really wanted an upgrade we would be looking at an e6500 cored system.
    > While running at a lower clock speed, this would have a definite advantage,
    > especially if SMP were enabled.

    SMP would be fine with 4 e5500 cores in the P5040 and the T1042, and I have doubts that more cores can be frequently saturated with common desktop computing tasks. Besides, I think it's a given that the non-SIMD per-clock performance of the e6500 is less than 22% higher than that of the e5500 so won't make up for the clock rate decrease.
  • »18.01.16 - 18:44
    Profile
  • Jim
  • Yokemate of Keyboards
    Yokemate of Keyboards
    Jim
    Posts: 4977 from 2009/1/28
    From: Delaware, USA
    Quote:

    Andreas_Wolf wrote:
    > if we really wanted an upgrade we would be looking at an e6500 cored system.
    > While running at a lower clock speed, this would have a definite advantage,
    > especially if SMP were enabled.

    SMP would be fine with 4 e5500 cores in the P5040 and the T1042, and I have doubts that more cores can be frequently saturated with common desktop computing tasks. Besides, I think it's a given that the non-SIMD per-clock performance of the e6500 is less than 22% higher than that of the e5500 so won't make up for the clock rate decrease.


    If we had hardware that used those processors then I would agree with you.
    But the X5000 variant soon to be launched (in two weeks?) is P5020 based.
    A dual core.
    And the performance increase of the e6500 seems to provide exactly what is necessary to cover the decreased frequency.

    Then there is the fact that e6500 cores are dual threaded and that the minimum number of cores is 4.
    So, in a non-SIMD application we have parity, and with SMP we have four times the processing power than with a P5020.
    That is still twice what the P5040 could manage.

    And then there is the issue of Altivec....

    But...this is about the X5000 and the P5020 and P5040 processors used on those boards.
    My primary objection to those two cpus is price,
    A T1042, T2081, or even a T2080 would all be cheaper solutions.
    The T1042 is obviously slower than the P5040, but at about $200 less, it could provide a significant price reduction.

    Without SIMD, the e6500 based cpus (at least at the low end) offer parity with the P5020/P5040 AND they have a price advantage over the cpus used in the X5000.
    But it really would take SMP support to really make the 6500 based cpus perform optimally.

    I guess its of limited utility discussing potential solutions when we are about to get real hardware.
    But I was hoping that the performance of the X5000 would be a significant improvement over our current hardware, and while it may top our G4 based systems, the G5 is still probably the more powerful solution.

    So...do I wait for a P5040 based X5000 or hope for PCIe G5 support (OR the better price/value of a T1042 based board)?
    Because that would be the comparison I'd like to see, X5000 vs PCIe G5.
    "Never attribute to malice what can more readily explained by incompetence"
  • »19.01.16 - 12:30
    Profile
  • Yokemate of Keyboards
    Yokemate of Keyboards
    Andreas_Wolf
    Posts: 12185 from 2003/5/22
    From: Germany
    > If we had hardware that used those processors then I would agree with you. But the
    > X5000 variant soon to be launched (in two weeks?) is P5020 based. A dual core.

    Indeed, I was using the announced P5040-based X5000/40 to illustrate the top e5500 core count and performance.

    >> I think it's a given that the non-SIMD per-clock performance of the e6500 is less
    >> than 22% higher than that of the e5500 so won't make up for the clock rate decrease.

    > the performance increase of the e6500 seems to provide exactly what is necessary to
    > cover the decreased frequency. [...] So, in a non-SIMD application we have parity [...].
    > [...] Without SIMD, the e6500 based cpus [...] offer parity with the P5020/P5040

    As said, this required increase would be 22% to be on par with P5040 and 11% to be on par with P5020. Increase of DMIPS per clock and thread is between 3% and 10% (depending on source) in single-thread use according to Freescale documents, btw.

    >> SMP would be fine with 4 e5500 cores in the P5040 and the T1042, and I have doubts
    >> that more cores can be frequently saturated with common desktop computing tasks.

    > e6500 cores are dual threaded and [...] the minimum number of cores is 4. [...] with
    > SMP we have four times the processing power than with a P5020. That is still twice
    > what the P5040 could manage. [...] it really would take SMP support to really make
    > the 6500 based cpus perform optimally.

    As said, I doubt that more than 4 threads can be frequently saturated with common desktop computing tasks.

    > then there is the issue of Altivec....

    Yes, that's the glimmer of hope if used extensively.

    > this is about the X5000 and the P5020 and P5040 processors used on those boards.
    > My primary objection to those two cpus is price, A T1042, T2081, or even a T2080
    > would all be cheaper solutions. The T1042 is obviously slower than the P5040, but
    > at about $200 less, it could provide a significant price reduction. [...]
    > the e6500 based cpus [...] have a price advantage over the cpus used in the X5000.

    We are talking about whether or not the e6500 can be the real performance upgrade the e5500 apparently isn't (according to first benchmarks, that is), so T1 is out of this discussion obviously.
    1.8 GHz T2080 is less than 100 USD cheaper than 2.2 GHz P5040. The question is if 100 USD really matter with a 2000+ USD board. That's less than 5% price difference.

    > I was hoping that the performance of the X5000 would be a significant improvement
    > over our current hardware

    Over G4 yes, over G5 no (in terms of CPU performance, that is).

    > it may top our G4 based systems

    1.5 GHz G4 in terms of CPU performance, yes. This will look differently with faster G4 systems.

    > the G5 is still probably the more powerful solution.

    I guess so.

    > that would be the comparison I'd like to see, X5000 vs PCIe G5.

    I'd be content with a comparison with pre-PCIe G5. After all, it runs MorphOS for better comparability, and single-core CPU performance wasn't increased significantly (2.7 GHz PPC970FX is probably faster than 2.5 GHz PPC970MP in single-core performance).
  • »19.01.16 - 13:55
    Profile
  • Jim
  • Yokemate of Keyboards
    Yokemate of Keyboards
    Jim
    Posts: 4977 from 2009/1/28
    From: Delaware, USA
    >As said, I doubt that more than 4 threads can be frequently saturated with common desktop computing tasks.

    I would have to agree with you that more than four cores is rarely used on desktop PCs. I have one dual four core Xeon system and one 8 core AMD FX based system, and the overall performance of these in real world use is only marginally better than my older four core Phenom II based system.

    But, if I am buying a desktop system, I want a minimum of four cores. Additional threading doesn't hurt.
    However, without SIMD, the performance of P5020, P5040, and P2080 cpus is all fairly close.

    So the primary differences between the P5040 and the P2080 once SMP is factored in are limited to price, additional threads that might not see much uses, and the slight disadvantage presented by the clock speed/performance issues we have discussed with the T2080.

    As the T2080 was not available when the X5000 was designed, and since the performance of the P5040 model should be comparable to a T2080 based system, I am not going to denigrate the performance of this model.

    >The question is if 100 USD really matter with a 2000+ USD board. That's less than 5% price difference.

    Well...even with P50XX cpus, this price seems a bit high, but given that A-eon is not a charity or a community driven organization its certainly better than the cost of a development system.

    >I'd be content with a comparison with pre-PCIe G5. After all, it runs MorphOS for better comparability, and single-core CPU performance wasn't increased significantly (2.7 GHz PPC970FX is probably faster than 2.5 GHz PPC970MP in single-core performance).

    But the memory used in Late G5s is faster (DDR2) which does help performance.
    My guess is that single thread performance in a 2.5 GHz late G5 will be a close match for the earlier 2.7 GHz PowerMac.
    And, of course, if SMP is factored in the 2.5 GHz system should be close to twice as powerful.

    Since we have no commitment to SMP (like the OS4 community), I am rebuilding my 2.3 GHz system with one cpu board from a 2.5 GHz quad.
    That will have a speed advantage over the X5000, but with only one dual core cpu power draw will be lower (of course the P50XX cpus will have an advantage in this area regardless).

    However, if we do get a four core X5000, I would still have to consider it.

    After all, the 2.7 GHz G5 and the 2.5 GHz Quad G5 are serious power hogs.
    "Never attribute to malice what can more readily explained by incompetence"
  • »19.01.16 - 18:44
    Profile
  • Yokemate of Keyboards
    Yokemate of Keyboards
    Zylesea
    Posts: 2057 from 2003/6/4
    All in all it shows that ppc is an even deader end than I expected.
    Lets make a clear cut and go x64 ASAP.
    --
    http://via.bckrs.de

    Whenever you're sad just remember the world is 4.543 billion years old and you somehow managed to exist at the same time as David Bowie.
    ...and Matthias , my friend - RIP
  • »19.01.16 - 19:01
    Profile Visit Website
  • Jim
  • Yokemate of Keyboards
    Yokemate of Keyboards
    Jim
    Posts: 4977 from 2009/1/28
    From: Delaware, USA
    Quote:

    Zylesea wrote:
    All in all it shows that ppc is an even deader end than I expected.
    Lets make a clear cut and go x64 ASAP.


    Well Zylesea, its less than encouraging.
    But, PPC ports can be created from our current OS.
    What you are talking about is a new OS and that is going to take some time.

    In the meanwhile I can soldier on with PPCs.
    It certainly would help if we could point to something that offered more performance than our ten year old systems.
    "Never attribute to malice what can more readily explained by incompetence"
  • »19.01.16 - 19:13
    Profile
  • Yokemate of Keyboards
    Yokemate of Keyboards
    amigadave
    Posts: 2795 from 2006/3/21
    From: Northern Calif...
    Quote:

    Zylesea wrote:
    All in all it shows that ppc is an even deader end than I expected.
    Lets make a clear cut and go x64 ASAP.


    I am not against moving to x64 at all, in fact I support it completely, but with new ARM products coming soon that offer 64bit and 4 cores at over 1GHz in speed (like the Pine64 on Kickstarter at the moment), I can't help wondering if low priced but still quite powerful solutions wouldn't be better for our community, where many are concerned about price, as well as energy usage, performance and availability.

    I will be getting the Pine64+ with 2GB RAM, when it is available and think that MorphOS would be a perfect match as an OS for that product.
    MorphOS - The best Next Gen Amiga choice.
  • »21.01.16 - 22:22
    Profile
  • Yokemate of Keyboards
    Yokemate of Keyboards
    Zylesea
    Posts: 2057 from 2003/6/4
    Quote:

    amigadave schrieb:
    Quote:

    Zylesea wrote:
    All in all it shows that ppc is an even deader end than I expected.
    Lets make a clear cut and go x64 ASAP.


    I am not against moving to x64 at all, in fact I support it completely, but with new ARM products coming soon that offer 64bit and 4 cores at over 1GHz in speed (like the Pine64 on Kickstarter at the moment), I can't help wondering if low priced but still quite powerful solutions wouldn't be better for our community, where many are concerned about price, as well as energy usage, performance and availability.

    I will be getting the Pine64+ with 2GB RAM, when it is available and think that MorphOS would be a perfect match as an OS for that product.


    The Pine64 is (like most ultra cheap arm gadgets) using an Allwinner SoC AFAIK. Undocumented and rather half ready cooked. Have fun writing drivers for it.
    Plus, 2GB RAM is too little. When making the cut, do't do it for small steps (my powerbook has 1.5 GB already), but for a huge jump (like i7 with plenty RAM etc.) just to be on the safe side for the next 10 years or more.

    [ Editiert durch Zylesea 22.01.2016 - 01:31 ]
    --
    http://via.bckrs.de

    Whenever you're sad just remember the world is 4.543 billion years old and you somehow managed to exist at the same time as David Bowie.
    ...and Matthias , my friend - RIP
  • »21.01.16 - 23:29
    Profile Visit Website
  • Yokemate of Keyboards
    Yokemate of Keyboards
    amigadave
    Posts: 2795 from 2006/3/21
    From: Northern Calif...
    Not saying ARM instead of X64, and doing both is too much to expect from the limited development resources, just pointing out that MorphOS would be a great OS for such a cheap, small, power efficient, computing device. Maybe some day in the distant future, there will be an opportunity to have both X64 and ARM versions of MorphOS.

    A $15 to $20 portable MorphOS computer (okay, it would be more like $75 to $100 with a screen, keyboard and trackpad) is really appealing.
    MorphOS - The best Next Gen Amiga choice.
  • »22.01.16 - 00:55
    Profile
  • Paladin of the Pegasos
    Paladin of the Pegasos
    pampers
    Posts: 1061 from 2009/2/26
    From: Tczew, Poland
    Updated results.

    AmigaMark are under the same links, updated already.

    dnetc:

    Code:

    [Jan 21 17:18:21 UTC] Automatic processor type detection did not
    recognize the processor (tag: "MOS:0x8024")
    [Jan 21 17:18:21 UTC] OGR-NG: using core #0 (KOGE 3.1 Scalar).
    [Jan 21 17:18:40 UTC] OGR-NG: Benchmark for core #0 (KOGE 3.1 Scalar)
    0.00:00:16.37 [20,136,464 nodes/sec]
    [Jan 21 17:18:40 UTC] OGR-NG benchmark summary :
    Default core : #-1 (undefined) 0 nodes/sec
    Fastest core : #0 (KOGE 3.1 Scalar) 20,136,464 nodes/sec
    [Jan 21 17:18:40 UTC] RC5-72: using core #0 (MH 2-pipe).
    [Jan 21 17:18:59 UTC] RC5-72: Benchmark for core #0 (MH 2-pipe)
    0.00:00:16.32 [5,378,031 keys/sec]
    [Jan 21 17:18:59 UTC] RC5-72: using core #1 (KKS 2-pipe).
    [Jan 21 17:19:17 UTC] RC5-72: Benchmark for core #1 (KKS 2-pipe)
    0.00:00:16.08 [5,476,368 keys/sec]
    [Jan 21 17:19:17 UTC] RC5-72: using core #2 (KKS 604e).
    [Jan 21 17:19:36 UTC] RC5-72: Benchmark for core #2 (KKS 604e)
    0.00:00:16.07 [5,590,276 keys/sec]
    [Jan 21 17:19:37 UTC] RC5-72: using core #5 (MH 1-pipe).
    [Jan 21 17:19:55 UTC] RC5-72: Benchmark for core #5 (MH 1-pipe)
    0.00:00:16.70 [5,258,979 keys/sec]
    [Jan 21 17:19:56 UTC] RC5-72: using core #6 (MH 1-pipe 604e).
    [Jan 21 17:20:15 UTC] RC5-72: Benchmark for core #6 (MH 1-pipe 604e)
    0.00:00:16.08 [5,160,960 keys/sec]
    [Jan 21 17:20:15 UTC] RC5-72 benchmark summary :
    Default core : #-1 (undefined) 0 keys/sec
    Fastest core : #2 (KKS 604e) 5,590,276 keys/sec


    Stream:

    Code:

    -------------------------------------------------------------
    STREAM version $Revision: 5.10 $
    -------------------------------------------------------------
    This system uses 8 bytes per array element.
    -------------------------------------------------------------
    Array size = 10000000 (elements), Offset = 0 (elements)
    Memory per array = 76.3 MiB (= 0.1 GiB).
    Total memory required = 228.9 MiB (= 0.2 GiB).
    Each kernel will be executed 10 times.
    The *best* time for each kernel (excluding the first iteration)
    will be used to compute the reported bandwidth.
    -------------------------------------------------------------
    Your clock granularity/precision appears to be 1 microseconds.
    Each test below will take on the order of 134446 microseconds.
    (= 134446 clock ticks)
    Increase the size of the arrays if this shows that
    you are not getting at least 20 clock ticks per test.
    -------------------------------------------------------------
    WARNING -- The above is only a rough guideline.
    For best results, please be sure you know the
    precision of your system timer.
    -------------------------------------------------------------
    Function Best Rate MB/s Avg time Min time Max time
    Copy: 1148.2 0.140391 0.139346 0.142811
    Scale: 1210.7 0.133642 0.132151 0.135742
    Add: 1650.2 0.146227 0.145436 0.148499
    Triad: 1654.9 0.145661 0.145028 0.147620
    -------------------------------------------------------------
    Solution Validates: avg error less than 1.000000e-13 on all three arrays
    -------------------------------------------------------------


    nbench

    Code:

    BYTEmark* Native Mode Benchmark ver. 2 (10/95)
    Index-split by Andrew D. Balsa (11/97)
    Linux/Unix* port by Uwe F. Mayer (12/96,11/97)

    TEST : Iterations/sec. : Old Index : New Index
    : : Pentium 90* : AMD K6/233*
    --------------------:------------------:-------------:------------
    NUMERIC SORT : 657.77 : 16.87 : 5.54
    STRING SORT : 79.605 : 35.57 : 5.51
    BITFIELD : 2.1514e+08 : 36.90 : 7.71
    FP EMULATION : 72.453 : 34.77 : 8.02
    FOURIER : 30404 : 34.58 : 19.42
    ASSIGNMENT : 14.892 : 56.67 : 14.70
    IDEA : 3865.7 : 59.12 : 17.55
    HUFFMAN : 1107.1 : 30.70 : 9.80
    NEURAL NET : 16.248 : 26.10 : 10.98
    LU DECOMPOSITION : 503.67 : 26.09 : 18.84
    ==========================ORIGINAL BYTEMARK RESULTS==========================
    INTEGER INDEX : 36.054
    FLOATING-POINT INDEX: 28.663
    Baseline (MSDOS*) : Pentium* 90, 256 KB L2-cache, Watcom* compiler 10.0
    ==============================LINUX DATA BELOW===============================
    CPU :
    L2 Cache :
    OS :
    C compiler : gcc version 2.95.3 20020615 (experimental/emm)
    libc :
    MEMORY INDEX : 8.544
    INTEGER INDEX : 9.352
    FLOATING-POINT INDEX: 15.897
    Baseline (LINUX) : AMD K6/233*, 512 KB L2-cache, gcc 2.7.2.3, libc-5.4.38
    * Trademarks are property of their respective holder.


    Monolith doesn't work for me at the moment so cannot post results.
    MorphOS 3.x
  • »22.01.16 - 08:12
    Profile Visit Website