pixie Quote:

I guess Pistorm could use AHI native drivers and lower the latency. It would be interesting to see if a draco like emulation where only the CPU is emulated bare metal like emu68 adds jitter and how much

Consider a program that has been loaded from disk into memory. Worst case for native 68k code execution is loading one cache line of code from memory and executing it. Worst case for JIT emulation of 68k code is loading 68k code from memory and translating it from 68k code to ARM code in a JIT buffer before executing the ARM code. I expect a JIT buffer is much larger than a native cache line too. Modern performance has not improved enough to improve worst case performance even though best case performance has improved, largely because of much larger modern cache sizes. The small footprint advantage of the 68k is gone with JIT emulation of 68k code too. It is the small footprint advantage of ARM Thumb ISAs, licensed from 2nd source 68k producer Hitachi, that made ARM popular for these embedded applications (68k, Hitachi SuperH and then ARM with Thumbs led the 32 bit embedded market). Some of the ARM cores now are using AArch64 with inferior code density giving larger foot prints but this is the risk ARM is taking after most of the competition has been defeated by ARM Thumb ISAs.

@matthey

So what? The worst case for a JIT is always going to be worse than an interpreter the first time any code is executed. This is why many modern JIT actually interpret until they find the hotspots.

Fortunately worst case is just that. Worst case. What matters is typical case.

_________________
Doing stupid things for fun...

Karlos Quote:

So what? The worst case for a JIT is always going to be worse than an interpreter the first time any code is executed. This is why many modern JIT actually interpret until they find the hotspots. Fortunately worst case is just that. Worst case. What matters is typical case.

So what if a professional musician's audio loses synchronization. So what if a game's controller latency is sometimes a couple of frames. Who needs accurate timing and low latency anyway?

http://nerdlypleasures.blogspot.com/2021/07/lag-consoles-emulators-fpgas.html Quote:

FPGAs : Benefits and Drawbacks Regarding Latency and Accuracy An FPGA console can provide significant benefits over a traditional PC emulator, but none of those benefits are guaranteed. An FPGA console can demonstrate a very high level of accuracy to the original systems with relatively modestly priced hardware. FPGAs have the advantage of having programmable logic and that logic can be programmed to simulate the original circuitry and the various quirks, edge cases and delays associated with those circuits. While a highly-accurate SNES emulator like Higan requires a rather powerful modern PC system to maintain perfect synchronization between the emulated CPU, PPU and APU and a stable 60fps, the Analogue Super Nt and SNES MiSTer core can do the same for a fraction of the cost of the PC hardware needed for that same level of fidelity. With the FPGA consoles from Analogue and others, for the controllers they support those controllers can be read at the same speed as the original consoles (if the controller was intended for the console, Analogue's Nt Mini and Nt Mini Noir must translate the NES controller signals for the Atari 2600 core, for example). MiSTer is designed for USB controllers (including adapters which translate original controller data into USB data). MiSTer was not always designed for low latency, in the early days when home computers cores were being ported over the latency was in the neighborhood of 2 frames. While this did not matter quite as much for most home computers, when home consoles and handhelds began to be ported over the relatively slow translation of USB input into native input no longer was good enough. It can poll compatible USB controllers as fast as 1ms (1000Hz) and now can process that input with very little delay, so for most people USB input will be good enough. MiSTer also has a low-latency option, namely the SNAC (Serial Native Accessory Converter), which can provide a port to read an original controller directly for the controllers supported (NES, SNES, Genesis, Turbo Grafx). It also has a lower then USB latency option called BLiSSTer which can translate native controller input to a core more quickly than via USB but not as directly as SNAC.

Who cares about accuracy and latency? Who cares about finesse or efficiency? Who optimizes when brute force CPU performance is available with a Moore's Law tailwind? Moore's Law forever?

@pixie

before discussing improvements - has anybody noticed a jitter on PiStorm or maybe also measured it?

@matthey

You are absolutely grasping here. When we discuss latencies of JIT relative to interpretation, you have to understand what the baseline is. The fact is that for 68K emulation, interpretation is already faster on modern silicon than any physical 68K ever made. It is the exception, not the norm, that the worst case latency for any application produces a performance worse than interpreting, since that's the entire point of doing JIT in the first place.

Hypothetical cases are interesting but unless you have actual numbers to show that say Emu68/PiStorm o has unreliable real world performance due to jittery JIT latencies and is an impediment to gaming, music or any other class of application, you're just releasing hot air.

I ran OctaMED sound studio for years on my A1200 driving all my MIDI gear both on real 68040 and also on OS4.1 under JIT on the PPC on the same A1200. Absolutely no issues and it could handle more mixed channels thanks to the increased performance. And that was on a JIT on a much slower CPU with much fatter native instructions. System friendly 68K games were equally no problem.

_________________
Doing stupid things for fun...

@Karlos
Emulation is not the EOL computing experience I'm interested in and I don't think I'm the only one. The philosophy has completely changed from the original 68k Amiga philosophy. The 1980s hardware with 1990s CPU performance using GHz clocked CPUs with GiBs of memory doesn't interest me. Good luck with your EOL emulation.

@matthey


Quote:

So what if a professional musician's audio loses synchronization. So what if a game's controller latency is sometimes a couple of frames. Who needs accurate timing and low latency anyway?

Emu68 is bare metal CPU translation without distractions from the Linux host OS.

As for modern PC's retro emulators, a modern X86-64 CPU has large caches that can store the entire memory contents of target retro platform.

4700000000 hz translates into 0.2127659574468085 nanoseconds

5800000000 hz translates into 0.1724137931034483 nanoseconds

_________________
Amiga 1200 (rev 1D1, KS 3.2, PiStorm32/RPi CM4/Emu68)
Amiga 500 (rev 6A, ECS, KS 3.2, PiStorm/RPi 4B/Emu68)
Ryzen 9 7900X, DDR5-6000 64 GB RAM, GeForce RTX 4080 16 GB

@matthey

Whataboutism much? You keep confusing emulation of entire systems vs. emulation of just CPU - Emu68 on PiStorm is just the CPU, everything else uses original chipset. Whatever lag you might experience if you replace hardware with software, such as P96 and AHI, you will also experience with real 68k CPU based Amiga.

_________________
B5D6A1D019D5D45BCC56F4782AC220D8B3E2A6CC

@matthey

Quote:

matthey wrote: @Karlos Emulation is not the EOL computing experience I'm interested in and I don't think I'm the only one. The philosophy has completely changed from the original 68k Amiga philosophy. The 1980s hardware with 1990s CPU performance using GHz clocked CPUs with GiBs of memory doesn't interest me. Good luck with your EOL emulation.

The original Amiga philosophy was Amiga's custom chips to PATCH the weak IPC and multimedia incompetent 68000 CPU. 68000 is useful to host 32-bit programming model OS.

Motorola wasn't big on multimedia and 3D when it focused on embedded and telecommunications.

Motorola was late on MMU integration. Must pay for a separate MMU for the privilege.

Motorola was late on integrating fast MUL instruction in the CPU. Must pay for a separate DSP for the privilege.

_________________
Amiga 1200 (rev 1D1, KS 3.2, PiStorm32/RPi CM4/Emu68)
Amiga 500 (rev 6A, ECS, KS 3.2, PiStorm/RPi 4B/Emu68)
Ryzen 9 7900X, DDR5-6000 64 GB RAM, GeForce RTX 4080 16 GB

@matthey

Quote:

Emulation is not the EOL computing experience I'm interested in and I don't think I'm the only one.

Your preferences are duly noted. Get a Vampire V4. It's the closest thing you can get to an in silico 68K that's more performant than the fastest 68060.

Quote:

The philosophy has completely changed from the original 68k Amiga philosophy.

No, that happened with the 68020. Suddenly the awesome idea that both CPU and chipset could share the same memory at full speed disappeared and that for best performance, the CPU is always going to need to be more isolated from the rest of the system, with its own local memory.

_________________
Doing stupid things for fun...