New ppc board by Acube/A-Eon: A1222 "Tabor"

[Spectre660]

@matthey

I already have a Tabor and I am enjoying it.

[Niding]

@Spectre660    

Ignoring all the indepth discussion about pros and cons;

I guess you have had expirience with SAM440 or 460.
How do you feel (subjectivly) about the performance of Tabor vs the SAM lineup?

[Spectre660]

I have run AmigOS 4.1 update6 on Sam440ep-Flex,FE on Sam460ex.
Linux on both Sams and the Tabor.
I have run Both the Special FPE Debian on the Tabor and the regular
Debian with the emulated floating point on the Tabor.
The Tabor is much faster than the Sams under Linux .

@Spectre660    

Ignoring all the indepth discussion about pros and cons;

I guess you have had expirience with SAM440 or 460.
How do you feel (subjectivly) about the performance of Tabor vs the SAM lineup?

[Iggy]

30% faster integer performance will make some applications feel snappier while others with heavy floating point use (like Blender) will likely run at a fraction of the speed of a PPC with standard FPU. It's kind of like hiring a motivated worker who is missing one arm. He may be a little faster than average at some jobs but is going to have major trouble doing some work.

Well, one vote for 'poor decision' but not a lethal one.

Is there an NG port of Blender?

I have two different dual cpu systems (one a dual quad Xeon the other dual hex core Opteron) both with 32GB of memory for that monster.

I can't picture it working well on a single core system with memory limitations.

And PPCs won't die out for awhile.

Current e6500 based cpus could extend the life of the platform for several years.

[zylesea]

I have run AmigOS 4.1 update6 on Sam440ep-Flex,FE on Sam460ex.
Linux on both Sams and the Tabor.
I have run Both the Special FPE Debian on the Tabor and the regular
Debian with the emulated floating point on the Tabor.
The Tabor is much faster than the Sams under Linux .

Would the Tabor still be much faster than Sam if you disable one of teh two p1022 cores? I mean it's no wonder that an SMP aware OS is faster on a system with two cores than on a system woth one core.

[nicholas]

I have run AmigOS 4.1 update6 on Sam440ep-Flex,FE on Sam460ex.
Linux on both Sams and the Tabor.
I have run Both the Special FPE Debian on the Tabor and the regular
Debian with the emulated floating point on the Tabor.
The Tabor is much faster than the Sams under Linux .

What are the Prometheus Trailer benchmark results running mplayer on regular Debian with the emulated floating point?

[itix]

Why not? If I have used floats to save some typing and it works then why on earth I should care if it won't work on some non-FPU machine?

Why would you bother writing software if you don't care if it will work or not?

For fun. I am not a slave.

[matthey]

I have run AmigOS 4.1 update6 on Sam440ep-Flex,FE on Sam460ex.
Linux on both Sams and the Tabor.
I have run Both the Special FPE Debian on the Tabor and the regular
Debian with the emulated floating point on the Tabor.
The Tabor is much faster than the Sams under Linux .

Linux is probably using both cores of the Tabor CPU so it would be significantly faster at integer math than the SAM. FPU trapping probably isn't going to be noticeable for light floating point use while being devastating to heavy use floating point programs. Run a MFlops benchmark under Linux using the traps on the Tabor board and let us know how it performs. The AMCC (SAM) 460EX gives 2.0 MFLOPS/MHz. I would be surprised if the P1022 can do 10% of the SAM's MFLOPS with trapping. Traps have a huge amount of overhead (20+ cycles per trap) and allow no superscalar parallelism.

Well, one vote for 'poor decision' but not a lethal one.

I'll wait to place my vote but I have low expectations. My scale would go something like this:

0) acceptable decision as better than half the FLOPS of the SAM 460
1) poor decision as 1/2 - 1/4 the FLOPS of the SAM 460
2) bad decision as 1/4 - 1/8 the FLOPS of the SAM 460
3) desperation as worse than 1/8 the FLOPS of the SAM 460

Is there an NG port of Blender?

Andy Broad did a port of Blender to AmigaOS 4.

http://www.broad.ology.org.uk/amiga/blender/

I can't picture it working well on a single core system with memory limitations.

What makes you think the 68k can't do multi-core? It is not much more difficult than copy and paste of an existing FPGA CPU core. The FPGA has an advantage of being able to deal with problems like the executive base forbid counter in a more compatible way. I believe the 68k in FPGA has a better chance of preserving compatibility while exceeding the 4GB addressing barrier. The PPC can not use 64 bit pointers and keep compatibility with AmigaOS 3 or AmigaOS 4 because structure sizes would change. Better code density (smaller code size) is an advantage with a memory extension like XMS for the PC. How many Amiga 68k users complain about 128MB of memory not being enough compared to Amiga PPC users complaining about 512MB not being enough? I wonder how much memory the Tabor FPU trapping support code will take up?

[Spectre660]

Unfortunately the regular Debian Mplayer powerpc32 wont run.
Would have to try to compile a non-altivec version but
I suspect that  other components may also causes  problems .
Same issue on the Sam460ex but I compiled a non-altivec version some time ago and that works.Interestingly the regular Mplayer version in Ubuntu-mate 15.10 works ok on the Sam460ex . Tabor does not work with X windows stuff under Lubuntu 15.10. I can experiment and see if I can get a regular Debian benchmark by some means .
 

What are the Prometheus Trailer benchmark results running mplayer on regular Debian with the emulated floating point?

[nicholas]

Unfortunately the regular Debian Mplayer powerpc32 wont run.

I hope that isn't a bad omen for regular pp32 OS4 programs running on the Tabor.

Would have to try to compile a non-altivec version but
I suspect that  other components may also causes  problems .
Same issue on the Sam460ex but I compiled a non-altivec version some time ago and that works.Interestingly the regular Mplayer version in Ubuntu-mate 15.10 works ok on the Sam460ex . Tabor does not work with X windows stuff under Lubuntu 15.10. I can experiment and see if I can get a regular Debian benchmark by some means .

Cool.

[wawrzon]

Unfortunately the regular Debian Mplayer powerpc32 wont run.
Would have to try to compile a non-altivec version but
I suspect that  other components may also causes  problems .
Same issue on the Sam460ex but I compiled a non-altivec version some time ago and that works.Interestingly the regular Mplayer version in Ubuntu-mate 15.10 works ok on the Sam460ex . Tabor does not work with X windows stuff under Lubuntu 15.10. I can experiment and see if I can get a regular Debian benchmark by some means .

well. thats just the taste whats gonna happen i guess. prepare for more threads like this while interesting stuff happens elsewhere.

[itix]

Better code density (smaller code size) is an advantage with a memory extension like XMS for the PC. How many Amiga 68k users complain about 128MB of memory not being enough compared to Amiga PPC users complaining about 512MB not being enough? I wonder how much memory the Tabor FPU trapping support code will take up?

In modern computing code density and code size have very little to do with memory requirements. PPC code requires 50% more space (versus 68k code) but we are still talking few hundred kilobytes.

It is the data that counts.

[matthey]

In modern computing code density and code size have very little to do with memory requirements. PPC code requires 50% more space (versus 68k code) but we are still talking few hundred kilobytes.

It is the data that counts.

It depends on the programs (streaming data needs little memory and no DCache for example) and sometimes 68k "data" is smaller also because of less alignment restrictions. Code density is more important to processor performance where the 68k can have 40%-50% more code in the ICache and to bandwidths which allow code to be transferred 40%-50% faster. DCaches are rarely larger than ICaches despite some programs using much more data. Memory is cheap now days but even tens of MBs are important to the AmigaOS where 64 bit pointers will break compatibility. Code density is important enough that most modern 32 bit mobile and embedded devices use ARM with Thumb 2 or Android's Dalvik byte code which have good but inferior code density to the 68k. IMO, it makes sense for the Amiga to leverage all the advantages of compatibility and a small footprint with the 68k using 32 bit for the low end. The high end could break compatibility converting to 64 bit pointers while adding SMP and using a sandbox for AmigaOS 3 and 4 compatibility but I don't think there is enough market for it currently and especially with the price/performance and future prospects of PPC. The same technology used to make an enhanced 68k CPU (and learn from it) could be used to make a new 68k like 64 bit SuperCISC ISA and CPU design (if necessary) which is better than x86_64 (an average ISA at best while the CISC advantages giving the most powerful consumer processors in the world are continuously overlooked). It would require some investment but at least the Amiga could control its destiny, standardize and innovate instead of being dependent on the last small customer PPC manufacturer and aging embedded designs.

[broadblues]

Amiga 68k users complain about 128MB of memory not being enough compared to Amiga PPC users complaining about 512MB not being enough?

Ridiculous thing to say, modern memory usage is all about data, code is like 1% of it.

eg SketchBlock is 3.5MB unstripped (plus some small libraries and filters) but as I'm working in quad float pixels I can max out on 1.5Gb of free ram when dealing with modern digital camera images.

blender needs about 100MB to start but only 10% of that is code.

[itix]

Ridiculous thing to say, modern memory usage is all about data, code is like 1% of it.

eg SketchBlock is 3.5MB unstripped (plus some small libraries and filters) but as I'm working in quad float pixels I can max out on 1.5Gb of free ram when dealing with modern digital camera images.

Unstripped exec just contains debug information (function names etc.). The instruction section is much much smaller than that...

[matthey]

Ridiculous thing to say, modern memory usage is all about data, code is like 1% of it.

eg SketchBlock is 3.5MB unstripped (plus some small libraries and filters) but as I'm working in quad float pixels I can max out on 1.5Gb of free ram when dealing with modern digital camera images.

The AmigaOS libraries and devices are probably 95% code. They have to be counted too. The AmigaOS requirements:

AmigaOS 3.1 no requirement, 2MB recommended
AmigaOS 3.5 4MB required, 8MB recommended
AmigaOS 3.9 6MB required, 8MB recommended
AmigaOS 4.0 64MB required
AmigaOS 4.1 Classic 96MB required

Many classic users consider AmigaOS 3.9 to be bloated but PPC requires another ~60MB of memory. Why does PPC need another ~60MB for "data"?

What kind of floating point range and precision are needed to require quad precision floating point in SketchBlock? If only increased range is required then extended precision should be adequate (both have 15 bits of exponent) but extended precision only has 11 more bits of precision than double precision while quad precision has 60 more bits of precision.

blender needs about 100MB to start but only 10% of that is code.

Data used once, infrequently and streamed shouldn't count as it isn't necessary to be persistent in memory. Code in the AmigaOS which is persistent should be counted as code used.