Lightwave benchmark for users with PPC, 060, PiStorm, Vampire accelerators

[Promilus]

Originally Posted by Bruce Abbott

(...)
Yes, you are. An A1200 wasn't good enough for you, even with 060. You didn't like the A500 until you put a PiStorm in it. (...)
More recently I bought another A600 and put a Vampire in it. Probably not such a good idea because Vampire owners are universally hated - for good reason.

Oh, so putting Vampire which has performance over highest available 68k is ok, putting PiStorm is for "amiga haters". Putting pistorm which DOES NOT emulate amiga chipset is for amiga haters. Running A500/A600 with SAGA instead of regular OCS/ECS is ok.

RPi4 overall has better availability worldwide than Apollo products. I can even buy few versions of RPi4 in Poland. I don't get how bad can it be in NZ. True. Price is inflated as hell. I still own RPi4 pre-covid which did cost me ~50$ (1GB version with PSU and non-official acrylic case with fan). Today I can buy only 4gb/8gb sets for 150-200USD. Madness. But even then it's still cheaper than Apollo products (yes, including whole pistorm baseboard cost and optional fpga OCS with hdmi out and/or mipi-csi).

Ppl buy vampire because original amiga isn't fast enough. Neither CPU, nor graphics, nor IDE. And connectivity to new displays is problematic with RGB out. So... ppl buy vampire because it's fast. Because it offers USB kb/mouse support. Because it offers fast storage interface (but... still only IDE which already sux due to low availability), because it offers RTG and also - for those OCS/ECS machines - AGA. So those aren't original amiga haters. But those seeking faster cpu, rtg, network, connectivity, storage but with lower price and different implementation are. Because? Because you can't even see your own hypocrisy.

[TCD]

Originally Posted by Korban

It could be argued that wanting to restrict a platform and needing to rely on other systems for tasks that could be done on an Amiga if it had more raw grunt would make the person who wants it restricted a "hater".

Are you implying the only 'hater' here might be Bruce? What a fascinating theory

[Korban]

@TCD

It was in response to his comment, but I was just pointing out the silliness in the idea that people are "haters" based on their preferences in retro hardware.

[klx300r]

I can't get the render screen to play nice to render the scene via LW but using Shell via ScreamerNet to render as per walkero over at amigans instructions:

AmigaONE X1000, PPC, OS4.1FE- 17m10s

BUT this is not comparing apple to apples though as per the steps from post 1but still cool to try.

T do so make sure your using v5, open Shell and type:

xx:xx/Lwsn.fp -3 scenes/benchmark/Raytrace.lws 0 0 (x is location of your Lightwave folder)

[pixie]

Where the images are created?

[midwan]

Originally Posted by pixie

Where the images are created?

They are not. Unless you configure the scene to save the generated image somewhere, it will only render it by default.

[hammer]

Originally Posted by Ferry

To be fair, in that spreadsheet PiStorm should be in the "68 software emulation" section: it's not a real 68k, it's not a FPGA. In fact, it's a software program that emulates the 68k on another CPU.

Make no mistake: I'm fan nr. 1 of PiStorm, I've collaborated with its documentation and I'm partially responsible of some "tricks" (Amiga HDF shared with Linux, putting Musashi and Emu68 in the same SD and booting both from the Emu68 0x76 drive, mounting 0x76 drive in Linux…), but things are what they are, and PiStorm is a software-emulated 68000 CPU, in both Musashi and Emu68.

Saluditos,

Ferrán.

Reminder, 68060 has a RISC core that translates variable CISC 68K into fix length RISC 68K internal instructions. 68060 is missing the pipelined FPU.

No modern "CISC" CPU runs complex instruction sets as their native instructions.

PiStorm-Emu68 method doesn't have a dedicated hardware decoder for CISC X86 to RISC translation and a dedicated mini-CPU for the microcode engine (translation software from CPU firmware). PiStorm-Emu68 method has CPU resource usage for the translation process and its "bare metal" software translation method i.e. no memory-protected/security model Linux type OS to disturb it.

With investment, a team could semi-customize a modern ARM CPU IP with dedicated 68K hardware decoders for hardware-accelerated Emu68 translation.

[starship]

Pistorm for A4000 ?

[Gorf]

Originally Posted by starship

Pistorm for A4000 ?

And A3000 please!!

[fxgogo]

Right, so on my Laptop with WinUAE I get 1 minute 8 seconds. It is an emulated 060 with JIT.
My Raspberry Pi 400 with Amikit got 3 minutes and 9 seconds.

[fxgogo]

Originally Posted by Bruce Abbott

I was thinking of benchmarking my Vampire 600 V2, but Lightwave 5 doesn't seem to be available for download. Is this viable or should I just leave it to people who already have Lightwave on their machines?

Try this on Turrans. http://ftp2.grandis.nu/turran/FTP/~U..._v5.0r-CDSetup

Muadib has good guide to getting it installed: https://www.amigaraytracers.com/foru...topic.php?t=36

[Promilus]

Originally Posted by hammer

No modern "CISC" CPU runs complex instruction sets as their native instructions.

Actually both CISC and RISC nowadays run on microops. RISC just usually end up being translated 1:1, but when you make ISA you want it to be fairly stable and compiler optimized. On the other hand when you make chip microarchitecture you want it to run things smoothly. That's where microops come handy. You can optimize architecture using expendable microops. You can modify microops how you see fit because instruction decoders can still make it work with existing ISA. So it's harder to break software compatibility despite impressive changes in internal architecture. CISC and RISC nowadays only differs in ISA alone. Not how they are implemented deep in the execution pipelines ... as those are inherently RISC.

[Karlos]

There's no such thing as CISC, really. It's just a term invented by early adopters of RISC to explain how their architecture was different.

When you look at, for example, the PowerPC, it's called RISC but it's in no way a Reduced Instruction Set. It has many instructions and a lot of them are pretty complicated. What it adopts of the RISC manifesto (something I just made up but probably exists in some form somewhere) is that it essentially exports the complexity of optimum instruction scheduling to the compiler. It's also a load store architecture which is typical of RISC machines.

There was a point to all this, but it's been a very long day and I've forgotten, so I'll just finish with the closing statement, "bollocks".

[Hedeon]

Dunno. The basis of PPC is certainly reduced instruction set IMHO. But every instruction has like x variants...

[grond]

Originally Posted by Karlos

There's no such thing as CISC, really. It's just a term invented by early adopters of RISC to explain how their architecture was different.

When you look at, for example, the PowerPC, it's called RISC but it's in no way a Reduced Instruction Set. It has many instructions and a lot of them are pretty complicated. What it adopts of the RISC manifesto (something I just made up but probably exists in some form somewhere) is that it essentially exports the complexity of optimum instruction scheduling to the compiler. It's also a load store architecture which is typical of RISC machines.

There was a point to all this, but it's been a very long day and I've forgotten, so I'll just finish with the closing statement, "bollocks".

There are several aspects of a design that are considered "RISCy" but I'm not sure whether there ever was a pure RISC-design. Early SPARC- and also MIPS-processors may have been the most RISCy designs. The PPC certainly didn't have a reduced instruction set. It had instructions such as "estimate 1/x with guaranteed 8bit accuracy" and lots of other crazy stuff.

The aspects of RISC I still remember:

- reduced instruction set size
- load/store architecture
- large register file
- no instruction decode stage
- all instructions execute in the same amount of clock cycles
- all instructions are encoded in the same size
- pipelined ALU
- 3-operand code

The point was that all this made it easier to design ALUs with high throughput that could be clocked at high clockrates. RISC-instructions didn't need decoding (so they thought) because the longer instructions and lack of implied operands made it possible to directly fetch operands from the place indicated in the instruction itself (connect bits x..y of the instruction word to multiplexer 1, connect bits y...z to multiplexer 2, a.s.o.). At the time the decoders were the most complex parts of a processor (probably still are) and going for superscalar execution made instruction decoding more complex by an order of magnitude.

Why doesn't any of this matter very much today? Because we have huge 1st level caches that simply cache decoded instructions along with lots of hint bits we don't even get to know about. Processor clock rates are quite a bit faster than memory so that additional stages for decoding can be hidden somewhere between the cache levels. Executing uncached code will always be slow anyway.

[Karlos]

The point is, whatever architectural benefits RISC had when it was new are standard CPU microarchitecture today, regardless of the ISA.

[Bruce Abbott]

Originally Posted by fxgogo

Try this on Turrans. http://ftp2.grandis.nu/turran/FTP/~U..._v5.0r-CDSetup

Muadib has good guide to getting it installed: https://www.amigaraytracers.com/foru...topic.php?t=36

Thanks for that. I will download it when I get more bandwidth.

[IanS]

Originally Posted by Bruce Abbott

Thanks for that. I will download it when I get more bandwidth.

If you're downloading things for your Amiga, are we to assume you only use modem technology that was contemporary with the release of the Amiga 500 and 2000? Surely anything else would be ludicrously fast and most definitely "anti-Amiga".

[Bruce Abbott]

Originally Posted by IanS

If you're downloading things for your Amiga, are we to assume you only use modem technology that was contemporary with the release of the Amiga 500 and 2000? Surely anything else would be ludicrously fast and most definitely "anti-Amiga".

In 1996 I developed a driver for the CNET CN40BC PCMCIA Ethernet card. Initially I used a PC as a gateway to the internet, then when ADSL became available in 1997 I was able to connect directly to the 'net. I still use that card on my A1200 today, only difference is I have to use a wireless modem connected to the cell-phone network because Spark (formerly Telecom NZ, the company I used to work for) forced me off copper.

When I last posted my internet was extremely slow and intermittent due to damage caused by Cyclone Gabrielle. Luckily the floodwaters only reached the outskirts of Hastings where I live, but the substation supplying electricity to the area went underwater and some people are even now still waiting for their power to be restored. After my power came back on it was like being back in the days of dial-up modems, with data transfer rates of a few kB/s and pages taking minutes to load. Not fun, but it brought back memories...

Actually it was quite a relief to get anything at all. Without power and no copper line I had no phone, and the cell-phone network wasn't working properly either. All I had to get information from was a transistor radio, and they were talking about it taking up to 3 weeks to get power restored. I was one of the lucky ones who were reconnected earlier because I live close to the hospital.

[fxgogo]

That is a good example of us moving so far forward with technology to the point where if it goes out there is no basic backup for emergencies.