@hardwaretech

Ironically, given your username, you appear to grossly underestimate the obdurate attachment Amiga users seem to have to physical hardware, even when it's PPC hardware that has nothing to do with the original platform.

I made the same mistake - obvious in hindsight - given the sums of money people are prepared to throw at a physical system - even one that isn't properly compatible with the existing operating system they intend to run on it!

As for emulation, well, people already can use emulation, they can just run QEMU.

The original question has been answered, the insults have been thrown, etc. The only question I have left remotely related to the original topic, which geen_naam has quietly sneaked away from, is where does he get the impression I'm a PPC hater from?

Still waiting on that one

_________________
Doing stupid things for fun...

@Karlos

it is simple get that impression for your boring attempts
to persuade people to switch from ppc
we amiga users use ppc 27 years since 1997 accept that
leave it as it is
want pople to use arm give them something as good as android

@hardwaretech

get lost
amiga is interesting because it is not pc
pc is boring
x86 and arm is boring
i have x86 and arm in work and don't want to made software for it after work
accept that

@ppcamiga1

Firstly, nobody asked you anything. However, since you feel the perpetual need to chime in:

What are you going to do when your PPC machine(s) fail? Is that the end of the road for you?

_________________
Doing stupid things for fun...

@Hammer

Well you set different standard for ARM then you do for PowerPC,

ARM can’t run 680x0 with a JIT or a emulator, its pretty much the same as on PowerPC, expect we also have native PowerPC programs and tools, there are no native AmigaOS arm programs, games or tools. You have AROS but it does not have JIT built in.

Last edited by NutsAboutAmiga on 13-Feb-2024 at 05:58 PM.
Last edited by NutsAboutAmiga on 13-Feb-2024 at 05:58 PM.

_________________
http://lifeofliveforit.blogspot.no/
Facebook::LiveForIt Software for AmigaOS

@NutsAboutAmiga

Quote:

ARM can’t run 680x0 with a JIT or a emulator, its pretty much the same as on PowerPC, expect we also have native PowerPC programs and tools, there are no native AmigaOS arm programs, games or tools. You have AROS but it does not have JIT built in.

You know, this argument doesn't sell the PPC solution. When you see Emu68 running 68K applications in the same performance range and realise it has no assistance whatsoever from native system calls, it only looks better by comparison.

The same is true with compatibility. By emulating a processor rather than a user mode ISA, Emu68 is able to run software that Petunia can't.

_________________
Doing stupid things for fun...

@Karlos

When people are trying to compare emu68k to Petunia, it’s not exactly the same, emu68K is a minimalistic emulator without a OS that gets in the way, this means you map registers without worrying about ABI standards.

But because Petunia is running on top/inside an OS, it has to apply to standards.

The implementations are not exactly the same. This means its bit like compare different benchmarks.
Try comparing DOSBOX to QEMU and see if you get any difference.

Last edited by NutsAboutAmiga on 13-Feb-2024 at 06:05 PM.
Last edited by NutsAboutAmiga on 13-Feb-2024 at 06:01 PM.

_________________
http://lifeofliveforit.blogspot.no/
Facebook::LiveForIt Software for AmigaOS

@NutsAboutAmiga

All that matters is the application performance / compatibility.

Last edited by Karlos on 13-Feb-2024 at 06:05 PM.

_________________
Doing stupid things for fun...

@Karlos

As you know will get huge bust from highly optimized native system libraries like for example the MemCopy or GPU accelerated routines. But if you are not measuring that, you will off course not see the benefits.

Last edited by NutsAboutAmiga on 13-Feb-2024 at 06:08 PM.

_________________
http://lifeofliveforit.blogspot.no/
Facebook::LiveForIt Software for AmigaOS

@NutsAboutAmiga

Memory copy is an extremely overrated example. Try benchmarking a large copy natively using CopyMem/Quick() and the same size copy using a relatively naive long word move loop in 68k emulated under petunia for the same size data.

Unless you have secret sauce memory copy for the native side*(and there may well be some), you'll see the JIT 68K is not much slower. Indeed, depending on the hardware you may hit memory IO bandwidth before then. This was certainly true for the hardware I have.

*You should also compare, in the interest of fairness, the same naive copy compiled for PPC.

Next, consider the infrequecy with which CopyMem/Quick is actually called from compiled code. Almost every by value copy will be generated as a sequence of moves by the compiler because invoking a system call for it is just too much overhead for the data being copied.

GPU acceleration is a different matter, of course. However, if your application is GPU bound in the first place then you really aren't comparing like for like.

_________________
Doing stupid things for fun...

@Karlos

It really is not, MemCopy will use DMA, AltiVec or 64bit mem copy routines,
a 680x0 data register is limited to 32bit, so its slow compared any native code.

Note that AmigaONE X50x0 also benefits a lot from cache handling instructions.
Something Petunia JIT will never generate.

I assume that GCC will produce a better then code then a JIT compiler.
Putina was created by one developer, GCC created by lots of brilliant developers.

Quote:

However, if your application is GPU bound in the first place then you really aren't comparing like for like.

I think my point was it where not comparing like for like, and does it make sense to try when implementation is so different and trying to achieve different things? It’s not simply about running a 68K program, it’s also about how it is integrated into the OS.

Last edited by NutsAboutAmiga on 13-Feb-2024 at 06:55 PM.
Last edited by NutsAboutAmiga on 13-Feb-2024 at 06:43 PM.
Last edited by NutsAboutAmiga on 13-Feb-2024 at 06:43 PM.
Last edited by NutsAboutAmiga on 13-Feb-2024 at 06:40 PM.

_________________
http://lifeofliveforit.blogspot.no/
Facebook::LiveForIt Software for AmigaOS

@NutsAboutAmiga

Quote:

It really is not, MemCopy will use DMA, AltiVec or 64bit mem copy routines...

None of which are used for 99% of all copies in typical compiled code because they are simply too small and simply inlining a few move operations is always faster.

The only copies that will do this are direct calls to CopyMem/Quick() or indirectly from the standard library memcpy() or possibly by-value copies of data for large structures, if the compiler support is configured accordingly.

Even when calling the system routines, you assume a lot. There are all kinds of checks and balances about the safety of using any of the features you describe, based on which kinds of memory are used, errata about the system (e.g. safety of using DMA), alignment considerations, etc.

The very first check is, "is the copy big enough to be bothered with any of that?" and when it's not, just do the most naive copy.

Don't take my word (or anyone else's) for it. Measure it.

Last edited by Karlos on 13-Feb-2024 at 07:31 PM.

_________________
Doing stupid things for fun...

@Karlos

geennaam already did, and he got big speed increase on his experiments.

I’m not that interested… but yes do get major speed up from OS improvements,
patches and other nice things too.

Yeh. I might confused the two.. CopyMem() and memcpy(), anyhow depending on what c Library you use it might end up in CopyMem() or CopyMemQuick(), and I wont exclude optimization in other systems libraries as well.

BltBitMapRastPort() will also be lot faster, under OS4.1 as well.

Last edited by NutsAboutAmiga on 13-Feb-2024 at 08:17 PM.

_________________
http://lifeofliveforit.blogspot.no/
Facebook::LiveForIt Software for AmigaOS

@NutsAboutAmiga

If your code is memory copy bound then you have a somewhat atypical workload. The only code that should be memory copy bound are, well, memory copies. Which you are more likely to use in drivers and codecs, e.g. storage access, moving pixel buffers between memory and video memory etc.

It's just not as common as you think. My comments about the behaviour of CopyMem are based in part on my recollection of thow that code looked in OS4.1FE.

I'm sure there are optimised paths for large copies, but these get increasingly rare as the size goes up. Perhaps software decoding of HD video would be an exception, but even then you may be dealing with small buffers and transfer from those to vram as you go, in order to get better cache utilisation (keeping the small fast ram buffer cached since vram rarely is cacheable) rather than soft decoding the entire frame then copying all that.

_________________
Doing stupid things for fun...

@Karlos

It be that I’m strange, but like to keep my CPU usage low at 3-5% if possible,
this because when I start Odyssey it peek up 100% for a while, I just don’t like music to be stutter, and like my system fast.

I don’t like much UAE or Hollywood programs, so avoid this programs if I can, I just like things that run well.

Last edited by NutsAboutAmiga on 13-Feb-2024 at 09:25 PM.
Last edited by NutsAboutAmiga on 13-Feb-2024 at 09:18 PM.
Last edited by NutsAboutAmiga on 13-Feb-2024 at 09:17 PM.

_________________
http://lifeofliveforit.blogspot.no/
Facebook::LiveForIt Software for AmigaOS

@Thread

Recreating a CPU on FPGA makes nor sense except, if the CPU is not available for the same price.

If you are doing a simple memcopy() your memory interface will be the bottle neck, it won't be faster if you have a special memcopy hardware, especially in a single thread application where you wait until it is done.

If you have to do a memcopy() with some kind of calculation f.e. pixel transformation, you might gain some speed over a typical CPU, that doesn't have support for those operations.

There are some simple media operations (audio ore video) , that can benefit from special hardware support f.e. adding / multiplying without overflow, you can win a lot of speed against standard CPU code, that would needs branches preventing pipeline stalls.

In those cases a CPU with special functions, could increase the speed of such operations dramatically.

Last edited by OneTimer1 on 13-Feb-2024 at 09:44 PM.
Last edited by OneTimer1 on 13-Feb-2024 at 09:40 PM.
Last edited by OneTimer1 on 13-Feb-2024 at 09:38 PM.

@NutsAboutAmiga

If your machine isn't responsive at high load, then your scheduler has a problem. Vanilla exec on 3.x was a good example, it's why we used to use Executive. The difference was night and day.

My Linux box sometimes has double digit load if I'm doing some heavy stuff but remains snappy as long as there is memory available. Going into swap is the problem there, rather than CPU load.

_________________
Doing stupid things for fun...

You fail to face facts each tear the Amiga market gets smaller like it or not. Hardware dies so do people who remember the Amiga. The only possible way to get enough number to get cost down is to make it work with all old school systems that are 68k and possible ppc. Which I doubt you will do. IE 68k Mac, amiga, ST and on ppc side Amiga, mac, and other If i remember MS put out version of windows, and Beos was made, and morph os. As for qemu it still is not as friendly to set up as it could be. As for my handle I work in IT support for 11years and as an electrician for 15. I left both industries because of health issues. My main argument you have very limited money and limited potential to get more. By doing a emulator first you can test your ideas before throwing money into hardware for your new cpu design. 2. You charge for it used money to make the real hardware. Do stuff in steps rather a leap you have limited money. This was the problem with the A1222 if it ever comes out it will be too slow and cost too much to generally available hardware.

I wrote a 68k CopyMem() and CopyMemQuick() patch for the 68060.

http://aminet.net/util/boot/CopyMem.readme

35.54% speedup for CopyMem060 v1.1 (vs AmigaOS 3.9)

It's not worthwhile to try to use the blitter for chip mem and few copies are large enough for MOVE16 to make a difference. The only reason why the speedup is so large is because the AmigaOS is compiled for an old CPU like the 68000. What is the point anyway when the AmigaOS is compiled for a 68000? That is the kind of treatment the 68k receives.

I improved the performance of Warp3D by roughly 10% (much more for certain programs) by disassembling the libraries and optimizing them with much more to go. The Warp3D.library could be half the size. Memory trashing bugs are not fixed and the 68k doesn't get the newest major version. PPC 3D is in better shape than 68k as some people have commented. That is the kind of treatment the 68k receives.

Emulation of the 68k on ARM has a fraction of the performance of native code. The cheap and weak ARM Cortex-A53 that suffers 3 cycle load-to-use penalties often seems to be the CPU of choice for emulation. Optimizations for an Amiga virtual machine are pointless and there is little incentive for developer support. Hardware is ignored when it used to be the most important part of the Amiga success. That is the kind of treatment the 68k receives.

The retro 68k Amiga market is many times larger than the PPC AmigaNOne market but is ignored. The PPC AmigaNOne hardware is subsidized for micro production while 68k Amiga hardware is ignored and practically blocked despite hundreds of thousands of units sold. That is the kind of treatment the 68k receives.

Question could a combo updated workbench better support built in capabilities of a native cpu such as built in compress on graphic card or raytracing. i realized this would have to be design also in the emulator to hand off to native hardware, or even cpu special abilities for example ai?