nesdev.com

My emulator is running at 330 FPS in my Core i5-2320 3GHz, not the most modern PC. By playing a NSF, it goes at 550 FPS. Even with all the recent optimizations, including the gcc -march=atom, my emulator stucks at 30 FPS in my netbook (HP Mini Intel Atom with Windows 7 Starter). In rare times, I got 70 FPS, but something seems wrong, since the speed seems to slowdown and get stuck at 30 or a value between 19 and 26 FPS. There's no secret in my gcc flags, -Ofast -Wall -funroll-loops -ffast-math -fomit-frame-pointer -pipe -flto.

Any thoughts?

The CPU is an Atom N450, the same as in the Inspiron mini 1012 that I used to use. It has 1 in-order core and 2 threads. To get the most out of that core in the face of load and branch penalties, you'll need to keep both threads busy.

The first thing I'd try is to handle audio timing, such as the 240 Hz clock, in your CPU thread and signal generation in another thread. And if you're doing any video filtering, such as NTSC or Scale2x, I'd recommend pushing that out to a thread as well. On scanlines that don't contain sprite 0, you could run the PPU mostly in its own thread and pass only catch-up logs to the PPU thread.

If it runs fast at first but then slows down, that might be due to dynamic frequency scaling in the processor. For example, if the CPU heats up too much it will try compensate by tuning down the clock frequency. You may want to monitor the CPU clock frequency while you run the emulator.

_________________
Download STREEMERZ for NES from fauxgame.com! — Some other stuff I've done: fo.aspekt.fi

One thing I read is that -funroll-loops will not always help (this is due to the instruction cache, if the computer has one), so try removing that flag and see if it work better; see whether it is better with or without that flag.

_________________
.

Unrolling loops doesn't necessarily make code faster; it trades branch penalties for RAM bandwidth.

Gcc's manual page says

This option makes code larger, and may or may not make it run faster.

I'd see what fell out of the profiler (-pg) to figure out what's consuming more time.

The person who wrote VirtualDub has a blog entry about optimizing code for the Atom and it's not clear that any compiler other than Intel's own knows how to optimize for the N450's in-order CPU.

How does QuickNES run on an Atom?

_________________
Here come the fortune cookies! Here come the fortune cookies! They're wearing paper hats!

Removing the -funroll-loops makes the FPS to be... 274~280 (much slower).
On Atom, no difference... except the dropping effect in framerate again.

URL for downloading ?

QuickNES is available from these:

• Original 2008 version: https://www.zophar.net/download_file/13029
• Included in BizHawk: https://github.com/TASVideos/BizHawk/releases (NES menu, pick the QuickNES core instead of NesHawk core)
• Availble for RetroArch: https://buildbot.libretro.com/stable/1.7.3/windows/x86/ (use the core downloader to get it)

_________________
Here come the fortune cookies! Here come the fortune cookies! They're wearing paper hats!

Run it through a profiler. That's the most useful thing you could do right now.

You're not going to get a single correct set of optimization flags for all possible architectures. Things that worked well on (e.g.) the pentium3 worked disastrously on the pentium4. (And things that worked well on the pentium 4 were ... passable but suboptimal on the pentium3)

Atom is a different enough ISA that you may well want to make a separate build for it.

It kinda looks like you might be able to get a free-as-in-beer copy of ICC from Intel for the cost of giving them your contact information (and needing to re-get it every three months)

What profiler do you suggest for it? (free)

Microsoft Visual Studio 2017 has a very nice profiler.

_________________
Here come the fortune cookies! Here come the fortune cookies! They're wearing paper hats!

I'm not familiar with... a profiler.
I got one named GlowCode and I can launch the emulator, but I couldn't find a way to link the EXE with the source code, sort of. All I did is compiling with -gstabs and debug it with GDB (usually only if my program's crashing).

My setup is gcc (MinGW.org GCC-6.3.0-1) 6.3.0 with Orwell's Dev-Cpp.

Got a nightly I could try? (preferably without symbols stripped)
Maybe also a suggested test case game...

Finally, use `cv2pdb` to generate PDB files out of the DWARF debug symbols. Debuggers and profilers prefer to see those files, then they can name the functions that are slow.

_________________
Here come the fortune cookies! Here come the fortune cookies! They're wearing paper hats!