@fishy_fis

Quote:

fishy_fis wrote: Emulated 68k speed of Pi4 running UAE = ~500MIPS

Question: Does UAE have a JIT on ARM?

Last edited by Kronos on 28-Dec-2023 at 05:46 PM.

_________________
- We don't need good ideas, we haven't run out on bad ones yet
- blame Canada

@Kronos

Not all, but most versions.
The figures I gave were with JIT enabled on the Pi4 (Amiberry, the fork of WinUAE which uses a recent source code base).

edits: I was the typo king.

Last edited by fishy_fis on 28-Dec-2023 at 05:47 PM.
Last edited by fishy_fis on 28-Dec-2023 at 05:47 PM.

@Kronos

500 MIPS without JIT is quite an high value

_________________
Indigo 3D Lounge, my second home.
The Illusion of Choice | Am*ga

@ppcamiga1

Quote:

ppcamiga1 wrote: @Karlos you should remeber before start trolling that I have rpi and know real performance emu68 on it. real performance of emu68 is one sixth native code and on rpi3 it is about PII 300 MHz. uae jit is better than emu68, uae jit performance is quarter of native code. so 1200 MHZ x86 is enough to outperform emu68 on rpi. 22 years ago I have athlon 1200 MHz and it run 68k code faster than emu68 on my rpi. little faster but faster. it was affordable pc. No cheap but affordable. I have mac mini you not. 68k code on my i9 is still little slower than native ppc code on mm.

I call bullshit.

The fact is, if you are running anything like an Amithlon type config - and by that I include *non cycle exact* WinUAE with "I don't give a shit about chipset timing" settings in JIT mode and your mac mini is giving faster performance for any 68K task, then your PC needs servicing because it's knackered.

Now, you are comparing 68K code on that PC to native PPC code on the mac mini, but you give no information as to what you tested - probably because you haven't tested anything since you are troll - but sure. There will be code tuned for G4 altivec at ~1.25GHz that can turn better performance than generic scalar 68000 code under a JIT emulation. Colour us all surprised by that, I am sure. Except that's an unfair comparison because you aren't comparing like for like and if you want to do that, then compile something for the 68K that makes *native* x86 code calls to a *native* vector unit there, since the 68K doesn't have a vector unit.

When I ran Amithlon on an Athlon XP, *scalar* code compiled for 68K versus the same scalard code compiled for OS4 native showed that there was no competition. Amithlon's virtual 68K performance utterly trashed the A1XE's real PPC performance. And that's without resorting to any *native* code tricks on Amithlon.

This was around the same time I was actively working on code for OS4 and it was one of the glaring red flags for me that the whole thing may have taken a seriously wrong turn architecturally.

Last edited by Karlos on 28-Dec-2023 at 05:55 PM.

_________________
Doing stupid things for fun...

@Karlos

Quote:

Karlos wrote: When I ran Amithlon on an Athlon XP, *scalar* code compiled for 68K versus the same scalard code compiled for OS4 native showed that there was no competition. Amithlon's virtual 68K performance utterly trashed the A1XE's real PPC performance.

Don't forget that the A1XE was a turd (like anything Articia) and OS4 was still running plenty critical OS code in 68k.

I do remember switching form AthonXP1700 (1.4Ghz) to a Peg1 and NOT feeling any difference one way or the other.

The Peg2_G4 some time later was a real upgrade and MorphOS1.4 for sure made use of Altivec.

So what is fair? Crippling a G4/5 to "scalar" only despite much real world code utilizing Altivec? Or fantasying about running native code on a setup where nothing has been running native for the past 20 years.

So yeah, I'll take a >2GHz G5 running a well polished OS over some theoretically much faster but only slightly faster in real life 68kARM running an OS where the latest achievement is the 3rd reinvention of a not quite runners up GUI toolkit.

_________________
- We don't need good ideas, we haven't run out on bad ones yet
- blame Canada

@Kronos

Quote:

Don't forget that the A1XE was a turd (like anything Articia)

It was, but it still had a functional vector unit and code compiled for that is capable of better than scalar 68K code can hope to reach, even if it were 1:1 translatable.

Quote:

and OS4 was still running plenty critical OS code in 68k.

That was completely irrelevant for my compute and/or IO bound tests as there were no system calls involved in any of the time critical parts.

Quote:

I do remember switching form AthonXP1700 (1.4Ghz) to a Peg1 and NOT feeling any difference one way or the other.

I don't base my claims on how fast the systems felt, I measured it. Carefully, and repeatedly. The results were conclusive.

This is not to say OS4 was a terrible experience. It wasn't. It was also orders of magnitude faster than my physical 040 machine when running the same 68K code, but it couldn't hold a candle to Amithlon for that task.

Last edited by Karlos on 28-Dec-2023 at 06:28 PM.
Last edited by Karlos on 28-Dec-2023 at 06:27 PM.
Last edited by Karlos on 28-Dec-2023 at 06:25 PM.

_________________
Doing stupid things for fun...

@Karlos

Quote:

That was completely irrelevant for my compute and/or IO bound tests as there were no system calls involved in any of the time critical parts.

See, and the code I ran spent a lot of time in CGX functions which performed quite a lot better on the Radeon7000 than the Matrox G550.

That was real life, and wether the AthlonXP could have run faster with that card or another with a better OS and drivers (which were mostly native at that point) is something I don't care about since that just wasn't there in the real world.

Just like there isn't much SW that is running so much better on 68kARM that I would consider accepting an OS that is some 20 years behind.

_________________
- We don't need good ideas, we haven't run out on bad ones yet
- blame Canada

@Kronos

Quote:

See, and the code I ran spent a lot of time in CGX functions which performed quite a lot better on the Radeon7000 than the Matrox G550.

No, your code didn't spend that much time in CGX functions unless CGX is an especially poor driver system that relies on software (including but not limited to data copying and register polling) to do what any VESA class GPU can do.

Now, CGX is not an especially poor driver system (I preferred it to P96), so instead, it *probably* sat there waiting for the hardware to do something. Hopefully in a manner that was non-busy-polling though sometimes that's unavoidable at the hardware level. I feel confident in saying that an emulated 68000 can wait for hardware just as effectively as PPC can natively wait for hardware.

This doesn't demonstrate anything about whether or not Amithlon can run 68K code faster than a PPC machine can run something natively. It just demonstrates differences in hardware/driver configuration that had an impact on your software.

Last edited by Karlos on 28-Dec-2023 at 07:30 PM.
Last edited by Karlos on 28-Dec-2023 at 07:29 PM.
Last edited by Karlos on 28-Dec-2023 at 06:53 PM.

_________________
Doing stupid things for fun...

68k emulation on ARM is totally OT on a thread about AmigaOS/MOS for RISC V

AFAIK there is not even an UAE port for it

@Karlos

It demonstrates that Amithlon in a best case HW config could be beaten by a default low end config on something as broken as a Peg1 in real world use.


Same is still true with über-fast-68k today, sure SysSpeed bar will go even longer but beyond that it's barely any better then an 680x0 with a Zorro GFX Card and some flash based storage.

_________________
- We don't need good ideas, we haven't run out on bad ones yet
- blame Canada

@Kronos

No, it demonstrates that code critically dependent on graphics drivers/hardware worked better on one machine than another. It's contrived AF and not remotely representative of the actual meaningful performance achievable by either system generally.

By your asinine metric, my 2007/8 Core2 Quad build, retrofitted with a 780ti in 2013, is better than my i7 laptop because it plays Doom 2016 at 60fps 1080p at maximum settings but the laptop can barely run it at all even in the most potato settings.

Meanwhile, the laptop destroys it for every other general purpose / compute bound task.

Finally, there is no "best case" config for Amithlon because it was discontinued before it could truly show it's potential. Do you really think it would be outperformed on modern x64 hardware with refreshed drivers for any remotely modern GPU by some decade(s) old PPC kit?

Last edited by Karlos on 29-Dec-2023 at 12:21 PM.

_________________
Doing stupid things for fun...

@Karlos

If playing Doom is the only valid use case for that laptop.....

Sofar (20 years and counting) I have yet to se a valid use case for über fast 68k.

Might be because no ones writes SW targeting it, which might be because what little there is in OS development doesn't go in that direction.

A fast CPU alone does not make a computer useable, surely not "general purpose".

_________________
- We don't need good ideas, we haven't run out on bad ones yet
- blame Canada

@Kronos

Your metric is still asinine. Most code on 68K or PPC is not dependent on the performance of the RTG solution. Exceptions include video playback/capture.

You say nobody targets Uber 68K, and that may be true for software development. However it's not true for application use. Theres plenty of 68K productivity software that gets better the more CPU/memory you can throw at it. Art, rendering, music production, video. The very things the platform was famous for.

Even tedious but necessary stuff like spreadsheets, word processing and DTP benefit. As do emulators and games. Not just games posted from PC either. TKG is now playable at 50fps on AGA only, thanks to PiStorm.

Eventually, all the things that are considered PPC/NG exclusive are within reach too.

There isn't a 68K user out there that runs more than OCS A500 games that will tell you there's a fast enough 68K. If that were true, why are people still making 060 boards, vampires and PiStorms? Never mind the total count of UAE/AF users.

Compared to NG, 68K users are legion.

_________________
Doing stupid things for fun...

@Karlos

Quote:

Karlos wrote: There isn't a 68K user out there that runs more than OCS A500 games

Truer words never been written

But for real, visit a user meeting and you will see 68k users playing that kind of games using all the extra HW just for creature comfort and bragging rights. And you will see some tinkering just for the point of tinkering.
People actually "using" them? Few and far in between, which is no surprise when everything except CPU performance is just plain archaic.

_________________
- We don't need good ideas, we haven't run out on bad ones yet
- blame Canada

@Karlos

what you wrote is as usually pure bullshit.
I have rpi3 with emu68 and it perform like PII 300MHz.
To outperform emu68 on rpi3 only 1200 MHz x86 is needed.
I have something like that in 2001.
It was affordable pc with athlon 1200 MHz.
uae on my pc run faster 68k code 22 years ago than emu68 on my rpi3 today.

ppc code on my mac mini 1.4 GHz g4 still run faster than emulated 68k code on my i9.

@ppcamiga1

Thanks, I needed a good laugh.

Look, allowing for the possibility for just a moment that you are not the most paralysed from the neck upwards hamster troll, your statement is stupid.

"I have rpi3 with emu68 and it perform like PII 300MHz."

In what sense does it perform like a PII 300? A P2 300 running native code or a P2 300 running UAE non-JIT? What? You need to explain yourself.

"To outperform emu68 on rpi3 only 1200 MHz x86 is needed."

Sure. The Pi3 is hardly the upper limit of PiStorm performance though. Nevertheless, you only have to look at the work being done on Emu68/CM4 to understand the performance envelope for the Pi as a hardware expansion. Depending on the code being executed, the 68K side can execute more instructions per second than the actual clockspeed of the ARM cpu. This is due to two factors - the efficiency of the translated code (i.e. approaching 1:1 68K instructions in => ARM instructions out) for the right code and the superscalar execution of the resulting ARM code. Obviously this won't be true for every example 68K code out there, but it's still an impressive achievement.

Petunia - good as it is - doesn't come close to this, unfortunately. Of course, high end x64 emulation is still more performant but when I last checked, I can't install a high end x64 CPU in my A1200 trapdoor and even if I could, I don't fancy the thermals of that. A Umilator type box however.... Now you are talking.

You see, my A1200 is *infintely* more interesting to me as an Amiga enthusiast than your rancid dumpster find mac mini (that the original owner likely dropped like a shit stained pair of underpants as soon as an intel mac came out) is and can ever be.

Sure, it's better PPC machine than the original A1 ever was but with standards set that low, how could it not be?

Last edited by Karlos on 29-Dec-2023 at 02:29 PM.

_________________
Doing stupid things for fun...

@liquidbit

Quote:

liquidbit wrote: ..Im in the MOS community since 2003, ... , now MOS is running on MacMini's which are decades back with today's PC hardware. So they need a new Cell.

MorphOs running on AMD64:

https://twitter.com/chainq/status/1183013352706101248

Like I told before
... they will port the OS to a hardware with better price to performance ratio and availability.

And like always we don't know when this will be available ...

Last edited by OneTimer1 on 31-Dec-2023 at 03:36 PM.
Last edited by OneTimer1 on 31-Dec-2023 at 03:35 PM.

@Karlos

Quote:

In what sense does it perform like a PII 300?

The first question to this troll should be "do you have PiStorm?" ;)

@michalsc

He claims to.

_________________
Doing stupid things for fun...

@Karlos

Quote:

@michalsc He claims to.

From what I've heard of him I got the impression that he has a standalone raspberry pi 3

_________________
Indigo 3D Lounge, my second home.
The Illusion of Choice | Am*ga