@Spectre660

I see it was the dual core result... guess the results are from Linux? Is it using _no_ fpu at all or SPE?

_________________
My programs: via.bckrs.de
MorphOS user since V0.4 (2001)

@Zylesea

As MPlayer doesn´t work with softfloats, I think answer is obvious...

@pavlor

3,984,559 keys/sec .
Sam460ex = 3,685,226 keys/sec
Quote:

pavlor wrote: @Spectre660 So, Tabor (single core) is as fast in MPlayer benchmark as: SAM460EX 2.1 GHz Pegasos 2 G4 700 MHz Mac Mini G4 600 MHz Nice result for non-Altivec CPU! May I ask for dnetc (OGR-NG in particular) result? That would show raw integer performance (not affected by memory speed like in MPlayer benchmark).

_________________
Sam460ex : Radeon Rx550 Single slot Video Card : SIL3112 SATA card

@Spectre660

RC5-72? This doesn´t scale so well with raw performance like OGR-NG.

SAM460EX has cca 10,000,000 in OGR-NG.


Edit: cca 750GX 1.2 GHz performance (if it is RC5-72). Nice!

Last edited by pavlor on 15-Oct-2015 at 05:03 PM.

@Dandy

Quote:

Dandy wrote: @cdimauro Quote: cdimauro wrote: Unfortunately the Amiga o.s. hadn't such good design practice, ... That's the reason why the Amiga o.s. never had the chance to be modernized, since it means rewriting the existing apps. Then I don't understand why this wasn't changed when they had to re-write the OS to create OS 4.

Because they didn't rewrote it: Amiga Inc. asked for a port of Amiga o.s. version 3.1 (and what was available of 3.5/3.9) for PowerPC. Nothing more.

In the meanwhile some other features were added, but the old o.s. basement is essentially there.
Quote:

My POV is that it is better just to re-write the OS once (properly) than to re-write all existing apps.

It requires resources, and porting of the existing applications (where possible): something which is difficult on the Amiga land.


@gregthecanuck

Quote:

gregthecanuck wrote: Apologies I'm taking this thread even more off-topic but I need to address some of cdimauro's comments... cdimauro wrote: Quote: In short, the difference is that Windows (and many other o.eses) never publicly exposed its data structures, and used some abstraction mechanism (handles, void pointers, getter & setter) to offer an "opaque" interface to the applications. Um, wrong. There are numerous structures that are used in the win32 API.

Who said here that the Win32 APIs didn't used structures? Not me.

I said a different thing, which I underlined now. However, I explain it better below.
Quote:

These are passed in/out via reference all over the place.

Sure.
Quote:

Want window info? You get a structure. Want system info? You get a structure. Want to create a control? You pass in a structure. Want network or user information? You get a structure. etc...

Want to create a process? Yes, you pass a structure also to CreateProcess, and you get back some data which is stored on another structure that you passed too.

However, if you take a look, you'll find simple data types used, and... HANDLEs (which I already cited) and IDs (for process and thread).

But that's it: you have ABSOLUTELY NO information about what the o.s. internally uses to represent a process, and how it's managed (e.g.: process queues, lists, or whatever).

Now take a look at what the Amiga o.s. does with CreateNewProc: it gives you back a pointer to the Process structure which it (the o.s.) uses to keep track of the process data & status, and to manage it.

Do you feel the difference? And the same is for many other APIs of the Amiga o.s., which publicly exposes INTERNAL, SENSIBLE, DELICATE data which are well HIDDEN on a goodly designed o.s..

Quote:

Quote: This way, it's possible to completely change the implementation without breaking the API, and it's also possible to make a 32-64 bit tunneling, like you reported. It is my understanding that the WOW64 subsystem takes care of win32 applications running on win64 systems and does the API mapping internally. The structure definitions are the same but of course things like pointer sizes differ on win32 and win64.

Exactly. But tunneling here is much easier, as I've explained in the previous comment.
Quote:

Quote: I make another example. Windows 3 introduced the first (sub)version of the famous Win32 APIs, but such APIs are internally "tunneled" (dispatched) to the Win16 implementation. The tunneling provided a conversion mechanism to transparently send the Win32 requests to the Win16 subsystem, converting the parameters (and the return values) back and forth. That happened for all Windows 9x version. On Windows NT, instead, the Win16 requests are tunneled to the Win32 subsystem. All this was possible due to the abstract interface provided by the o.s. to the application. Nothing abstract about the interface. It is simply structures and API calls or messages.

OK, so explain me why the Windows APIs use HANDLEs and IDs, whereas the Amiga o.s. APIs use directly pointers to the concrete structures used by the o.s..

Aren't handles and id "abstract enough"? Are pointers to the structures similarly abstract? The answer is clearly NO.
Quote:

Quote: Unfortunately the Amiga o.s. hadn't such good design practice, since the used (even private!) data structures were completely published. This means that (usually) it's not possible to exchange (with a tunnel mechanism) data structures between the 32 and the 64-bit subsystems. I see no reason why similar methods as those done on Windows would not work on an Amiga OS. It may involve providing both 32 and 64 bit interfaces in the libraries, or some other method.

Then tell me how any (32, 64-bit) application can send messages to the port of any other application. Thanks.
Quote:

Quote: Think about a Screen structure which was allocated by (for) a 64-bit application: you cannot pass it to a 32-bit application. Windows has the same limitation. 64 bit applications cannot call 32 bit DLLs.

You've misunderstood: I haven't talked about that.

To be clear on this part, show me how any application can display the list of ALL opened (by any application) screens. Just to give an example.

Then take a look at how any application can do the same task on Windows (for monitors, since it has no screens, but can have multiple monitors).

The same kind of problematics are solved in the same way on Windows: by an enumeration mechanism, instead of provide direct access to the list of screens, windows, libraries, tasks, etc..

Did you see the difference? Did you see how this impacts on what I was discussing about?
Quote:

Quote: That's the reason why the Amiga o.s. never had the chance to be modernized, since it means rewriting the existing apps. Sorry but this just isn't true in my opinion.

I reported some facts now. Not opinions.


@olegil

Quote:

olegil wrote: @cdimauro How on earth would you run 64bit Linux on a 32bit e500v2?

Not me, since (again! Seems to be a common problem to misunderstand what I say) I haven't said that. I requote myself:

"Last but not least, Linux (and apps) supports 64-bit (thanks to the 64-bit general purpose registers), so double precision can be supported (with DPESFP) as well."

I've underlined the relevant part. So, no: there's no 64-bit running (since the processor not even have a 64-bit mode). But registers are 64-bit wide with e500v2, only to support the DPESFP instructions.


@Zylesea

Quote:

Zylesea wrote: @cdimauro Quote: cdimauro wrote: @Zylesea AFAIK the e500v2 is able to decode and execute up to 2 instructions per clock cycle. Exactly like the AMCC 460. Indeed I messed up a number, but you were wrong, too :The e500v2 core does 2.4 MIPS/cycle/core.

Directly from the e500 reference manual on pag. 40 there's the scheme of the processor, where you clearly see that the Instruction Unit can only dispatch TWO instructions and the Completion Queue can only retire TWO (completed, executed) instructions.

If you don't like the diagram, I report the text, at pag. 41:

"The core complex is a superscalar processor that can issue two instructions and complete two instructions per clock cycle."

So, and as I said before, there's an upper limit to the number of instructions that can be executed, and it's TWO.

I don't know where have you got the 2.8 value but, reference manual at the hand, it's absolutely wrong.
Quote:

It's 2880 MIPS (P1022 one core@1.2 GHz) vs. 2200MIPS (AMCC 460ex 1.1 GHz). In pure integer calculations the P1022 should be up to 1.31times fatser than the Sam460ex.

See above. For the rest, it's better to wait for some benchmark with real-world applications.


@wawa

Quote:

wawa wrote: @TrevorDick Quote: The demo at the show was Debian 8 running an HD video concurrently with the 3D Gears demo and an animated Libre Office presentation. i would expect linux to decode and play video content on the gpu, the machine merely shoving video data through the bus. also i would expect linux to have working hardware mesa/gallium acceleration, so it shouldnt have problem with playing the simplest gl demo. i dont know what the libre office presentation do, but i expect that, similarly to video, displaying demo of office software isnt demanding what concerns the cpu or fpu. taking into account that so far i know neither full gpu, nor 3d acceleration, nor even libre office is available for os4, i doubt that such a presentation gives a reliable estimation about, how os4 would run on particular hardware.

I agree. The Linux test doesn't make sense, since you don't know the context (e.g.: what resources are used).

Regarding benchmark stuff, since this board has been shown running a very concrete set of applications under linux, one could replicate the same tests under linux on a sam460 board, that should give a clear idea of what to expect from such board, hardware wise.

_________________
Cuida tus piedras gordas.

A1200/030 32Mb
A4000D
A1-X1000.

@Ami603

Sam460ex Ubuntu-Mate 15.10

RC5-72 = 3,799,853 keys/sec
Mplayer Prometheus-Trailer = 311.379s


Quote:

Ami603 wrote: Regarding benchmark stuff, since this board has been shown running a very concrete set of applications under linux, one could replicate the same tests under linux on a sam460 board, that should give a clear idea of what to expect from such board, hardware wise.

Last edited by Spectre660 on 15-Oct-2015 at 06:32 PM.

_________________
Sam460ex : Radeon Rx550 Single slot Video Card : SIL3112 SATA card

@cdimauro

Quote:

cdimauro wrote: @Zylesea AFAIK the e500v2 is able to decode and execute up to 2 instructions per clock cycle. Exactly like the AMCC 460. Quote: Indeed I messed up a number, but you were wrong, too :The e500v2 core does 2.4 MIPS/cycle/core. Directly from the e500 reference manual on pag. 40 there's the scheme of the processor, where you clearly see that the Instruction Unit can only dispatch TWO instructions and the Completion Queue can only retire TWO (completed, executed) instructions. If you don't like the diagram, I report the text, at pag. 41: "The core complex is a superscalar processor that can issue two instructions and complete two instructions per clock cycle." So, and as I said before, there's an upper limit to the number of instructions that can be executed, and it's TWO. I don't know where have you got the 2.8 value but, reference manual at the hand, it's absolutely wrong.

Well, I got the 2.4 MIPS/MHz/corefrom a ppc comparison list I compiled a few years back.
Sure, you got a point with the ref man, but I got the value of 5760MIPS for the e500v2 based P2020 at 1200MHz which leads to 2.4 MIPS/core/MHz. Cannot say today where I got the number from (probably from some papers I got at a freescale seminar a few years ago), but definitely not from imagination (my list lacks a few values I was hunting down desperately, e.g. MIPS/MHz for the 970family by ibm) .

Also the e500 core is said to have 2.4 MIPS/MHz according to http://www.freescale.com/files/training_pdf/vFTF09_AN147.pdf?lang_cd=en

_________________
My programs: via.bckrs.de
MorphOS user since V0.4 (2001)

@Zylesea

Freescale lists several DMIPS/MHz values for its cores... e500v2 had both 2.3 and 2.4 in various documents.

That is why I (and also cdimauro) prefer application benchmarks, like these posted in this very thread.

@Zylesea

Quote:

Quote: Directly from the e500 reference manual on pag. 40 there's the scheme of the processor, where you clearly see that the Instruction Unit can only dispatch TWO instructions and the Completion Queue can only retire TWO (completed, executed) instructions. If you don't like the diagram, I report the text, at pag. 41: "The core complex is a superscalar processor that can issue two instructions and complete two instructions per clock cycle." So, and as I said before, there's an upper limit to the number of instructions that can be executed, and it's TWO. I don't know where have you got the 2.8 value but, reference manual at the hand, it's absolutely wrong. Well, I got the 2.4 MIPS/MHz/corefrom a ppc comparison list I compiled a few years back. Sure, you got a point with the ref man, but I got the value of 5760MIPS for the e500v2 based P2020 at 1200MHz which leads to 2.4 MIPS/core/MHz. Cannot say today where I got the number from (probably from some papers I got at a freescale seminar a few years ago), but definitely not from imagination (my list lacks a few values I was hunting down desperately, e.g. MIPS/MHz for the 970family by ibm) . Also the e500 core is said to have 2.4 MIPS/MHz according to http://www.freescale.com/files/training_pdf/vFTF09_AN147.pdf?lang_cd=en

As pavlor already pointed-out, what you report are DMIPS. Not MIPS.

Regarding MIPS, I've already discussed: you can have only a maximum of 2MIPS/MHz.

DMIPS numbers, instead, are the results of a synthetic benchmark.

I don't like synthetic benchmarks, as well MIPS which means nothing. Like pavlor, I prefer numbers coming from real-world applications.

P.S. I have nothing against you. I've only rebutted the technical stuff that you reported.

@Zylesea

Quote:

But a bog step from the Sam460 level and hence a good thing.

Freudian slip? Subconscious commentary on the pace of Amiga development? Some new hardware but still no new software. OS 4.2 still seems to be years in the future.

_________________
X5000 / microA1(OS4.1 FE U2) / CodeBench / Imagine / Blender
Lightwave 2019 / Microsoft Visual C++

@cdimauro

Indeed I was speaking of DMIPS not MIPS as DMIPS are the standard measure. My bad to mess this up. And where I totally chime in is that real worls tests are far more telling and I appreciate the values provided by Spectre.

_________________
My programs: via.bckrs.de
MorphOS user since V0.4 (2001)

@broadblues

Quote:

@itix Okay just for fun whilst preparing my meal I switched the root to LIBS: and ran again. No recursion in subdirs though life is too short and that script is suprisingly slow! (snipped)

Thanks. But how about ABI compatibility? Since this CPU has no dedicated FPU registers how this can be handled in native API calls where floating point parameters are passed in registers?

For example wouldn't it break newlib.library/snprintf() and utility.library/SNPrintf()? Or any of floating point based math functions in newlib?

Last edited by itix on 15-Oct-2015 at 08:56 PM.
Last edited by itix on 15-Oct-2015 at 08:48 PM.

_________________
Amiga Developer
Amiga 500, Efika, Mac Mini and PowerBook

Double post, please ignore

Last edited by Ami603 on 15-Oct-2015 at 10:17 PM.

_________________
Cuida tus piedras gordas.

A1200/030 32Mb
A4000D
A1-X1000.

@TrevorDick

so when some "real" price?

Honestly I really dont get the point of all that "suspance" in Amiga-related news...

Let away flamers and tell the "amiga-pepoles" news in clear ways plz...

_________________
Simone"Tuxedo"Monsignori, Perugia, ITALY.

@Ami603

See post linked below.

http://amigaworld.net/modules/newbb/viewtopic.php?mode=viewtopic&topic_id=40622&forum=2&start=360&viewmode=flat&order=0#770740

_________________
Sam460ex : Radeon Rx550 Single slot Video Card : SIL3112 SATA card

@olegil

Quote:

olegil wrote: But what the heck, now that we're getting hints of e500v2 support in AOS, I have a card here that could be "rerolled" for the Amiga market with minimal hardware effort (namely adding two PCIe slots that I couldn't have fit in our embedded form factor).

Ah, now here is something interesting. Without disclosing anything important, do you think there could be any chance that the company you work for might be interested in the amiga market? (In my case, I strongly suspect that my CEO's reaction to a similar question would be "lolnope")

@CodeSmith

lolnope

However, this is not the only way this could be done.

_________________
This weeks pet peeve:
Using "voltage" instead of "potential", which leads to inventing new words like "amperage" instead of "current" (I, measured in A) or possible "charge" (amperehours, Ah or Coulomb, C). Sometimes I don't even know what people mean.

Noticed Jens Schoenfeld made a comment regarding the CPU;

Quote:

The P1022 is a dual-core CPU. Even if you were to emulate all FPU commands in software, you'd have a spare core to do that, as OS4 is still a single-core OS. Besides, it's not all-incompatible, but throws a few illegal instruction traps on commands not implemented (according to one of the developers I talked to last saturday). That's about the same as what the 060 CPU does for unimplemented commands of the earlier members of the 68k group. Would you make fun of those who designed with the 060 back then? Surely not.

@CodeSmith

"lolnope"?

I think first reaction would be "Haeh? What?"