Previous Thread
Next Thread
Print Thread
C64 driver speed issues #100026 06/03/15 08:24 PM
Joined: May 2009
Posts: 1,871
J
Just Desserts Offline OP
Very Senior Member
OP Offline
Very Senior Member
J
Joined: May 2009
Posts: 1,871
Just a suggestion, but it seems like c64h156_device could really do with some major refactoring.

I would suggest refactoring c64h156_device::live_run, as that's currently the most CPU-heavy function according to VTune, and I trust VTune's results. My theory is that the sheer number of branches in the function is absolutely ruining the instruction pipeline by way of the branch predictor, not to mention that there are certain compare/branches that can be avoided entirely based on the results of previous comparisons.

Take, for example, line 294:

Code:
if (!BIT(cell_counter, 1) && BIT(cur_live.cell_counter, 1)) {


However, earlier in that particular case, we have this at line 280:

Code:
			if (bit) {
				cur_live.cycle_counter = cur_live.ds;
				cur_live.cell_counter = 0;
			} else {


In that case, if we're setting cur_live.cell_counter to 0, then the check at line 294 can't possibly ever be true, because BIT(cur_live.cell_counter, ANYTHING) will be false.

Additionally, there's an inordinate amount of CPU time being wasted on the check at the beginning of live_run, here:

Code:
	if(cur_live.state == IDLE || cur_live.next_state != -1)
		return;


It seems to me that there could potentially be better use of the device_timer callback in c64h156_device, but that may be faulty reasoning on my part.

At any rate, if that device can be made faster, I'd be willing to guess that the C64 driver would be made considerably faster. There are some other hot-spots, like device_scheduler::timeslice(), and I have some potential optimizations for it for which I'll be posting a diff tomorrow, but it seems like the bulk of CPU time is being eaten up by timers that drive heavily branchy callbacks.

Re: C64 driver speed issues [Re: Just Desserts] #100033 06/04/15 10:41 AM
Joined: Dec 2005
Posts: 330
A
AWJ Offline
Senior Member
Offline
Senior Member
A
Joined: Dec 2005
Posts: 330
Be very careful with the core scheduler--c64 is a highly unusual case (having a large number of devices with identical clocks all running 1 cycle at a time) and if you optimize for that case you risk making literally every other driver in MAME slower to the sole benefit of c64 and one or two other Commodore drivers.

Re: C64 driver speed issues [Re: Just Desserts] #100036 06/04/15 01:28 PM
Joined: Feb 2005
Posts: 449
C
Curt Coder Offline
Senior Member
Offline
Senior Member
C
Joined: Feb 2005
Posts: 449
The code has not been optimized at all, it is a simple rendering of the logic in the schematics. Be very careful not to break every other C64 disk from loading if you try to optimize it...

./mame64 c64 -iec8 "" -nothrottle -str 10
Average speed: 421.96% (9 seconds)

./mame64 c64 -nothrottle -str 10
Average speed: 320.48% (9 seconds)

I don't have any intention to do a major refactoring of it, it was an absolute nightmare to debug millions of lines of bits getting shifted in to get it working in the first place.

Last edited by Curt Coder; 06/04/15 01:38 PM.
Re: C64 driver speed issues [Re: Curt Coder] #100038 06/04/15 02:44 PM
Joined: May 2009
Posts: 1,871
J
Just Desserts Offline OP
Very Senior Member
OP Offline
Very Senior Member
J
Joined: May 2009
Posts: 1,871
Originally Posted By Curt Coder
./mame64 c64 -iec8 "" -nothrottle -str 10
Average speed: 421.96% (9 seconds)

./mame64 c64 -nothrottle -str 10
Average speed: 320.48% (9 seconds)


What a great benchmark, and completely worthless. I have a top-of-the-line i7-5930K and the driver consistently dips to 80-90% when disk access is actually going on, which you clearly didn't test with -str 10.

If you're not interested in doing any sort of optimizations, then fuck you too and that's the last time I bother with profiling or offering optimization help for any of your precious drivers.

Re: C64 driver speed issues [Re: Just Desserts] #100039 06/04/15 02:47 PM
Joined: Sep 2010
Posts: 18
B
balrog Offline
Member
Offline
Member
B
Joined: Sep 2010
Posts: 18
Curt, likewise the gblaster and sblaster1_0 devices when used with at386 show nice performance... unless you actually try to use it! Then performance consistently dips below 100% and the audio stutters. (I haven't debugged this yet.)

Let's not use artificial benchmarks here which fail to test the system under actual use, all right?

EDIT: try booting a game perhaps.

Last edited by Balrog; 06/04/15 02:57 PM.
Re: C64 driver speed issues [Re: Just Desserts] #100040 06/04/15 03:40 PM
Joined: May 2012
Posts: 423
R
remax Offline
Senior Member
Offline
Senior Member
R
Joined: May 2012
Posts: 423
Originally Posted By Just Desserts
Originally Posted By Curt Coder
./mame64 c64 -iec8 "" -nothrottle -str 10
Average speed: 421.96% (9 seconds)

./mame64 c64 -nothrottle -str 10
Average speed: 320.48% (9 seconds)


What a great benchmark, and completely worthless. I have a top-of-the-line i7-5930K and the driver consistently dips to 80-90% when disk access is actually going on, which you clearly didn't test with -str 10.

If you're not interested in doing any sort of optimizations, then fuck you too and that's the last time I bother with profiling or offering optimization help for any of your precious drivers.


I'm far from being an expert, but from the few things i know, i seem to remember that the disk driver has his own CPU and so is demanding in term of power of emulation...

In a way, you are right, it's better to benchmark with it running to know the real speed...

Re: C64 driver speed issues [Re: remax] #100043 06/04/15 04:21 PM
Joined: May 2009
Posts: 1,871
J
Just Desserts Offline OP
Very Senior Member
OP Offline
Very Senior Member
J
Joined: May 2009
Posts: 1,871
Originally Posted By remax
I'm far from being an expert, but from the few things i know, i seem to remember that the disk driver has his own CPU and so is demanding in term of power of emulation...


The disk drive having its own CPU doesn't even really enter into the situation as far as the heavy-hitters go in the profile. Have a look:


Re: C64 driver speed issues [Re: Just Desserts] #100059 06/05/15 05:56 AM
Joined: Feb 2005
Posts: 449
C
Curt Coder Offline
Senior Member
Offline
Senior Member
C
Joined: Feb 2005
Posts: 449
Originally Posted By Just Desserts
Originally Posted By Curt Coder
./mame64 c64 -iec8 "" -nothrottle -str 10
Average speed: 421.96% (9 seconds)

./mame64 c64 -nothrottle -str 10
Average speed: 320.48% (9 seconds)


What a great benchmark, and completely worthless. I have a top-of-the-line i7-5930K and the driver consistently dips to 80-90% when disk access is actually going on, which you clearly didn't test with -str 10.


This was meant to illustrate that merely having the disk drive idling already takes 100 percentage points out of the performance. Obviously having a function execute 16 million times per second while running the motor is going to be slow. I don't have your expertise in pipelines and optimization techniques so me trying to fix it would be quite fruitless.


Who's Online Now
0 registered members (), 29 guests, and 1 spider.
Key: Admin, Global Mod, Mod
ShoutChat Box
Comment Guidelines: Do post respectful and insightful comments. Don't flame, hate, spam.
Forum Statistics
Forums9
Topics8,811
Posts115,965
Members4,914
Most Online890
Jan 17th, 2020
Powered by UBB.threads™ PHP Forum Software 7.7.3