It is currently Mon Oct 15, 2018 12:46 pm

All times are UTC - 7 hours





Post new topic Reply to topic  [ 83 posts ]  Go to page Previous  1, 2, 3, 4, 5, 6  Next
Author Message
PostPosted: Fri May 25, 2018 9:08 am 
Offline

Joined: Mon Mar 30, 2015 10:14 am
Posts: 275
psycopathicteen wrote:
The 68000 would've had a head start with compilers.

Yes like all modern CPU, but it's not fair to compare code density with an IA64 for exemple which memory size nowadays are not really a problem, but parallelising process or others modern things are,to summarise the code is less dense but more efficient.


Top
 Profile  
 
PostPosted: Fri May 25, 2018 9:23 am 
Offline

Joined: Sun Sep 19, 2004 11:12 pm
Posts: 20656
Location: NE Indiana, USA (NTSC)
Of course code size in memory is still a problem, particularly instruction cache, L2 cache, and L3 cache.


Top
 Profile  
 
PostPosted: Fri May 25, 2018 9:37 am 
Offline

Joined: Mon Mar 30, 2015 10:14 am
Posts: 275
tepples wrote:
Of course code size in memory is still a problem, particularly instruction cache, L2 cache, and L3 cache.

I agree, but code efficiency is more important than code density here,this is not a bottleneck because the huge main RAM is alway here if needed .
This why modern CPUs are crisc and not cisc only .


Top
 Profile  
 
PostPosted: Fri May 25, 2018 11:42 am 
Offline

Joined: Sun Mar 27, 2011 10:49 am
Posts: 265
Location: Seattle
You have it backwards: CISC ISAs are as CISCy as ever. RISC chips have gradually turned into CRISC chips, in large part due to code density issues.

Modern CPUs are *insanely* good at reordering, parallelizing, and fusing instructions together once they get inside the pipeline. Nothing - *nothing* - a CPU can do internally comes close, performance-wise, to the cost of hitting RAM. When writing tight code (at least on a first pass) I view branchless operations on registers as effectively *free*; my big concerns are always always always branch prediction failures and cache misses.


Top
 Profile  
 
PostPosted: Fri May 25, 2018 11:53 am 
Offline

Joined: Mon Mar 30, 2015 10:14 am
Posts: 275
Quote:
RISC chips have gradually turned into CRISC chips, in large part due to code density issues.

I do not agree, this is more because the RISC CPUs have a hard time having a high frequency due largely to his reduced pipeline.


Top
 Profile  
 
PostPosted: Sat May 26, 2018 7:44 pm 
Offline

Joined: Wed May 19, 2010 6:12 pm
Posts: 2757
I would like to see how a 68000 expert would pull off "add r0, r1, r2, asl #8" in one cycle.


Top
 Profile  
 
PostPosted: Sat May 26, 2018 7:59 pm 
Online

Joined: Sun Apr 13, 2008 11:12 am
Posts: 7648
Location: Seattle
That's literally out of scope? This isn't about "all instructions are faster on ISA X than on ISA Y". It's that the two ISAs provide different instructions and different tasks can be done in different ways. You wouldn't want to do that on 68k unless you were specifically writing an ARM emulator on the 68k.

Comparing a single unique unchanging instruction speed is more or less useless in all contexts. There is literally no context in which that is a useful metric. (This is specifically why MIpS is a useless metric)

8086 IDIV was abominably slow. But you wouldn't claim that the XT ran at 24KIpS as a result, that's just misleading.


Top
 Profile  
 
PostPosted: Sat May 26, 2018 8:18 pm 
Offline

Joined: Wed May 19, 2010 6:12 pm
Posts: 2757
There's no way it's just 20% faster at the same megahertz speed.


Top
 Profile  
 
PostPosted: Sat May 26, 2018 8:21 pm 
Online

Joined: Sun Apr 13, 2008 11:12 am
Posts: 7648
Location: Seattle
Your disbelief doesn't change the fact that the recorded Dhrystones per MHz for ARMv1 are only 20% higher than the 68k.

If you want to argue with it, you need to actually dig up the corresponding assembly for the algorithms on the two ISAs. Only then can you make a meaningful comment about the relative performance.

Otherwise... you're just letting your preconceptions blind you.


Top
 Profile  
 
PostPosted: Sat May 26, 2018 8:30 pm 
Offline

Joined: Sun Sep 19, 2004 11:12 pm
Posts: 20656
Location: NE Indiana, USA (NTSC)
It might help as a baseline to hand-compile Dhrystone to idiomatic 6502, 65816, LR35902, and Z80 assembly, so they can be compared with GCC and LLVM output for m68k and ARM. Has this been done publicly?


Top
 Profile  
 
PostPosted: Sat May 26, 2018 8:56 pm 
Offline

Joined: Wed May 19, 2010 6:12 pm
Posts: 2757
Dhrystones can't measure how fast a collision detection routine written in assembly code is.


Top
 Profile  
 
PostPosted: Sat May 26, 2018 9:45 pm 
Online

Joined: Sun Apr 13, 2008 11:12 am
Posts: 7648
Location: Seattle
Your point being?

A Dhrystone is an arbitrary metric. It is less misleading than pure MIPS. It does not indicate suitability for other tasks other than those measured. It is definitely not a good metric of floating point capabilities, which are explicitly out of scope.

Some things benefit from certain CISC features. (For example: 68k register autoincrement). Sometimes the simplicity gained in early RISC designs outweighs that. Sometimes they don't. But replacing the metric "dhrystones/sec" with the metric "bounding box collisions/sec" doesn't tell you more, it just tells you something different.

The N64 has a very fast RISC CPU. And yet it is completely hamstrung by having high latency and limited bandwidth to main system memory. If you just counted operational cycles without paying attention to memory latency, you'd get a horrifically misleading picture.

The earliest ARM CPUs were only used in Acorn's Archimedes, which had graphical capabilities somewhere between EGA and VGA, and sound capabilities comparable to the Amiga OCS. But when I look at the very few demos that were posted to Pouet and viewable on youtube ... it doesn't even come close to its contemporaries. Is this a fair metric? Who knows, but on top of the other metrics, all I'm hearing is the same thing over and over:
RISC promised us that simpler instruction sets were a key to performance. Other factors have always overwhelmed any resulting gain.


Top
 Profile  
 
PostPosted: Sat May 26, 2018 10:31 pm 
Offline

Joined: Wed May 19, 2010 6:12 pm
Posts: 2757
I never said MIPS was accurate.


Top
 Profile  
 
PostPosted: Sat May 26, 2018 11:13 pm 
Online

Joined: Sun Apr 13, 2008 11:12 am
Posts: 7648
Location: Seattle
Then why do you insist that this ARM should be drastically faster than the 68000? It looks like your sole metric for believing so is the relative MIPS of the two.


Top
 Profile  
 
PostPosted: Sun May 27, 2018 9:56 am 
Offline

Joined: Wed May 19, 2010 6:12 pm
Posts: 2757
This 68000 instruction takes 12 cycles:
move.w (a0)+,(a1)+

The ARM needs 2 instructions to perform this:
ldrh r2,(r0),#2
strh r2,(r1),#2

Both of these are 3 cycles, which adds up to 6 cycles, which is still half as many cycles.


Top
 Profile  
 
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 83 posts ]  Go to page Previous  1, 2, 3, 4, 5, 6  Next

All times are UTC - 7 hours


Who is online

Users browsing this forum: Great Hierophant and 5 guests


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to:  
Powered by phpBB® Forum Software © phpBB Group