Computer specifications

See this revision of the page if you're looking for detailed information for older days and hardware.

Intel 4004 Visual Transistor-level Simulation

Emulator performance is primarily dependent on the CPU's speed, as the CPU undertakes the demanding task of mimicking another system's hardware. While the GPU typically rendering visuals and enhances graphics through applying graphical and post-processing enhancements features, a sufficiently fast CPU is crucial for achieving full-speed emulation. This makes the CPU the most critical component when building or upgrading a PC for emulation, particularly for accurately recreating performance-demanding systems. Some emulators offer Software Rendering, where all graphics processing is handled by the CPU, which is a method that significantly increase CPU performance demand. In recent years, choosing the right GPU for emulation is more important now than it used to be; with the recent advancements like compute shader renderer implementations and emulators like Yuzu, Ryujinx, Cemu, Xenia, ShadPS4 heavily utilizing GPUs and its features.

Recommended Specifications

What kind of EMULATION can you do with your PC?

This list excludes inactive or unsupported emulators as much as possible, see History of emulation page for older software emulators. For seeing recommended specifications for obsolete, non-active and older emulators, see this page. We also discourage recommending outdated hardware (this does not apply to GPUs that have moved off the mainline feature-driver branch but remain supported via the maintenance-mode / legacy driver branch; such GPUs may still be included in our guidelines) or operating systems.[5] Why? In the '90s and '00s, there are various popular tools and webpages for users to check system compatibility for games and software. Similarly, this page aims to guide emulation users by highlighting the system requirements for modern, actively maintained emulators. These emulators implements and rely on up-to-date frontends, standards, compiler features, functions, library and API related stuff from time to time (see high and low-level emulation#Future Outlook section) which usually depends on actively maintained and supported operating system versions and hardware via drivers (considering using binaries provided by official sources, not building software by yourself without some serious patching).[6] There are even some interesting discussions happening about microarch support for emulators.[7][8]

Windows: 10 (64-bit) based on servicing supported build or later

Linux: Distributions based on 64-bit active kernel releases/EOL

macOS: still maintained version

Android: still maintained version

iOS: still maintained version

Only emulators that are recommended in the EmuGen Wiki are listed here, for Shader Preset's performance cost, see Shaders, presets and filters#Shader presets section. Frontend cores are excluded, though they generally have similar requirements.
If you're gonna edit this table, please provide the official system requirements page URL (in Official Links section), we offer unofficial guidelines and recommendations in this page to help you decide.
This guideline targets moderate hardware requirements for emulators to ensure the emulated device realistically matches the behavior of typical native hardware; not merely the minimum needed to function. Situations such as some games using less resources are addressed in the "Notes" section.

WIP: PC-9800 series, FM Towns, Apple II line, Classic Mac OS, Sharp X68000, ZX Spectrum, Amstrad CPC, MSX 1/2

Emulator		CPU Demand	GPU Demand		Notes	Official Links
			Native	Enhancements
Mesen (NES)		▰▱▱	▰▱▱	▰▱▱	—	?
Genesis Plus GX	(SMS)	▰▱▱	▰▱▱	▰▱▱	—	?
	(MD • Mega CD)				—	?
Stella	(VCS)	▰▱▱	▰▱▱	▰▱▱	—	?
Altirra	(Atari 8-bit)	▰▱▱	▰▱▱	▰▱▱	—	Official requirements
Hatari	(Atari ST)	▰▱▱	▰▱▱	▰▱▱	—	Official requirements
Mednafen	(PC-FX)	▰▱▱	▰▱▱	▰▱▱	—	?
	(Atari Lynx)				—	?
	(Virtual Boy)				—	?
	(Neo Geo Pocket • Color)				—	?
FinalBurn Neo	(2D arcade boards)	▰▱▱	▰▱▱	▰▱▱	—	?
MAME	(3D arcade boards)	▰▰▰	▰▱▱	▰▱▱	⤷ *Some 3D titles may run on ▰▰▱ perf. level CPU hardware.	John IV's MAME Benchmarks
VICE	(PET • CBM-II • VIC-20 • C64 • C128)	▰▱▱	▰▱▱	▰▱▱	⤷ *Commodore 64 emulation demand metrics are based on x64sc version of VICE.	Manual
FS-UAE	(Amiga 4000)	▰▱▱	▰▱▱	?	—	Docs: Performance
	(CD32)
86Box	(Standard PC)	▰▰▰	▰▱▱	▰▱▱	⤷ *86Box has OpenGL 3.0 renderer. ⤷ *The Standard PC's demand metrics are based on a Windows 98 guest with a Celeron 300A and a Voodoo 3. ⤷ *IBM PC-compatible's demand metrics are based on a MS-DOS 6 guest with a 486DX2 and a S3 Trio64.	Official requirements Host machine survey
	(IBM PC-compatible)	▰▱▱	▰▱▱	▰▱▱
xemu (Xbox)		▰▰▱	▰▱▱	▰▰▱	⤷ *Some titles may run on ▰▱▱ perf. level CPU hardware. Due to Xemu's work-in-progress nature, certain games require ▰▰▰ CPU or enhancement features for certain games require 🔥 GPU.[9]	Official requirements Performance guide
BigPEmu (Jaguar • Jaguar CD)		▰▱▱	▰▱▱	▰▱▱	—	User manual#Troubleshooting
Ymir (Saturn)		▰▰▱	▰▱▱	▰▱▱	⤷ *Some titles may run on ▰▱▱ perf. level CPU hardware.	?
Flycast (Dreamcast)		▰▱▱	▰▱▱	▰▱▱	—	?
DuckStation (PlayStation)		▰▱▱	▰▱▱	▰▱▱	—	Official requirements
Ares	(Nintendo 64)	▰▰▱	▰▱▱	▰▰▱	—	SoullessSentinel's comment
	(SNES)	▰▱▱	▰▱▱	▰▱▱		?
	(PCE • PCE-CD • PCE2)
	(Sega 32X • Sega CD 32X)
	(LaserActive)
PPSSPP (PSP)		▰▱▱	▰▱▱	▰▱▱	⤷ *MSAA requires the VK_KHR_depth_stencil_resolve extension.[10]	Official requirements
Vita3K (PS Vita)		▰▰▱	▰▱▱	▰▱▱	—	Official requirements
PCSX2 (PlayStation 2)		▰▰▱	▰▱▱	▰▰▱	⤷ *Additionally requires the extensions GL_ARB_shading_language_420pack, GL_ARB_copy_image, and GL_ARB_clip_control ⤷ *Some titles may run on ▰▱▱ perf. level CPU hardware. ⤷ *If you plan to use ParaLLEl-GS renderer with enhancements, ▰▰▰ perf. level GPU is recommended.	Official requirements
Dolphin (GameCube • Wii)		▰▰▱	▰▱▱	▰▰▱	⤷ *Some titles may run on ▰▱▱ perf. level CPU hardware.	Performance guide
SameBoy (Game Boy • Game Boy Color)		▰▱▱	▰▱▱	▰▱▱	—	?
mGBA (Game Boy Advance)		▰▱▱	▰▱▱	▰▱▱	—	Official requirements Official requirements #2
MelonDS (Nintendo DS • DSi)		▰▱▱	▰▱▱	▰▱▱	⤷ *melonDS has compute shaders support.	Official site
Citra (Nintendo 3DS • new 3DS)		▰▰▱	▰▱▱	▰▱▱	—	Official requirements
RPCS3 (PlayStation 3)		▰▰▰	▰▱▱	▰▰▱	⤷ *Some titles that aren’t SPU heavy may run on ▰▰▱ perf. level CPU hardware.	Official requirements CPU Tier List for RPCS3
Cemu (Wii U)		▰▰▱	▰▱▱	▰▰▱		Official site
Xenia (Xbox 360)		▰▰▱	▰▰▱	🔥	⤷ *Some games manage to run just fine on ▰▱▱ performance GPUs.	Official requirements
Yuzu (Switch)		▰▰▱	▰▱▱	▰▰▰		Official requirements nx optimizer's recommendations
ShadPS4 (PlayStation 4)		▰▰▱	▰▰▱	🔥	⤷ *Needs VK_KHR_swapchain and VK_KHR_push_descriptor extensions ⤷ *Some games manage to run just fine on ▰▱▱ performance GPUs.	Official requirements

Demand Levels

The demand levels provide a rough indicator of hardware intensity. Colors represent low (green), medium (orange), and high (red) demands. Below are separate tables standardizing typical examples for CPU and GPU across emulators.
For emulator-specific variations (e.g., lower-end titles or enhancements), refer to the "Notes" and "Enhancements" columns in the main table.
If your CPU’s PassMark Single-Thread score is < 1500 and/or microarchitecture level is x86-64 (v1), some ▰▱▱ low-demand emulators may still run adequately, but upgrading your CPU is strongly recommended at that point.
Likewise, if your GPU's PassMark G3D score is < 3000, API support is limited to older version of OpenGL, or Direct3D, and/or the hardware is so old that it isn’t even covered by a maintenance-mode / legacy driver branch: although some ▰▱▱ low-demand emulators may still function, a GPU upgrade is strongly recommended at that point.

---

CPU Demand	PassMark Single-Thread	CPU-Z Bench 1T	Microarch	RAM	Example CPUs	Budget (CPU+MOBO+RAM)
▰▱▱	1500 2000	260 350	x86-64 (v2)	OS recommended	Pentium G2020 (2C/2T) / i3-2130 (2C/4T) Pentium G4560 (2C/4T)	🥔
▰▰▱	2500 3000	480 600	x86-64 (v3)	8 GB 16 GB	i3-9100F (4C/4T) • Ryzen 3 4100 (4C/8T) i5-11400F • Ryzen 5 5500 (6C/12T)	~$150 ~$250
▰▰▰	3500 4500	700 880	x86-64 (v4)	≥16 GB	Ryzen 5 7500F • i5-12400F* (6C/12T) Ryzen 5 9600X (6C/12T)	~$350 ~$450
🔥	≥5500	≥1000			Ryzen Zen 6 Medusa • Core Ultra Series 4 Nova Lake	~$???

GPU Demand	PassMark G3D	API Support	VRAM	Example GPUs	Budget (GPU)
▰▱▱	3000	OpenGL 4.6 Vulkan 1.3	4 GB	Radeon 740M	🥔
▰▰▱	11000		6 GB	GTX 1660 • RX 5600	~$200
▰▰▰	16000		8 GB	RTX 3060 • RX 7600	~$270
🔥	≥20000		≥8 GB	RTX 5060 • RX 9060 XT	~$350

Popular Pre-Built, Handheld, Mobile and APU systems for comparison

---

CPU Demand	GPU Demand	PassMark Single-Thread • PassMark G3D	PassMark Android • PassMark iOS	Microarch • API Support	System	Budget (System)
▰▱▱	▰▱▱	-	8500	ARMv8.2-A • OpenGL ES 3.1, Vulkan 1.2	Raspberry Pi 5	$150
		-	12500	ARMv8.2-A • OpenGL ES 3.2, Vulkan 1.1	Retroid Pocket 5[11]	$200
		CPU: 2200 • GPU: 3000	-	x86-64 (v3) • OpenGL 4.6, Vulkan 1.3	Steam Deck[12]	$400
▰▰▱		-	25000	ARMv9.2-A • OpenGL ES 3.2, Vulkan 1.3	Samsung SM-S928B	$500
		-	40000	ARMv9.2-A • OpenGL ES 3.2, Metal	iPhone 16	$700
	▰▰▱	CPU: 3300 • GPU: 11000	-	x86-64 (v4) • OpenGL 4.6, Vulkan 1.3	Steam Machine	$700?

Before diving in

Semiconductor industry categorization

The semiconductor industry, particularly for CPUs, GPUs, and other processors, involves a complex supply chain with distinct roles. Companies are typically categorized based on their primary functions: designing chips, manufacturing them, or assembling/finalizing products like graphics cards.

Chip Designers (Fabless Semiconductor Companies)

These companies focus on designing the architecture and intellectual property (IP) of chips but do not own manufacturing facilities ("fabs"). They outsource production to foundries.

• NVIDIA (designs GPUs such as GeForce RTX)
• AMD (designs CPUs such as Ryzen and GPUs such as Radeon)
• Qualcomm (designs mobile SoCs such as Snapdragon)
• Apple (designs custom silicon such as Apple Silicon M-series and A-series)
• Arm (designs CPU/GPU core architectures licensed to others)

Chip Manufacturers / Foundries

These companies physically produce silicon wafers and chips using advanced process nodes (e.g., 3 nm, 2 nm). They can be "pure-play" foundries (manufacturing only for third parties) or integrated.

• TSMC – world's largest pure-play foundry; manufactures for NVIDIA, AMD, Apple, etc.; leader in advanced nodes (2 nm in production ramp as of 2025)
• Samsung Foundry – pure-play foundry division of Samsung; competes directly with TSMC (notable for 3 nm GAA transistors)
• Intel Foundry – Intel's foundry business (formerly Intel Foundry Services)
• GlobalFoundries
• SMIC

Integrated Device Manufacturers (IDMs)

Companies that both design and manufacture their own chips in-house.

• Intel (designs and manufactures x86 CPUs)
• Samsung (for its own Exynos SoCs, memory, etc.)
• Micron (DRAM and NAND flash)

Board Partners / Add-in-Board (AIB) Partners

Companies that take finished GPU dies (from NVIDIA or AMD) and design complete graphics cards, including PCB, cooling, power delivery, and branding.

• ASUS (ROG Strix, TUF Gaming series)
• EVGA (historically major NVIDIA partner; exited new GPU production in 2022)
• MSI
• Gigabyte / Aorus
• Zotac
• Palit, Galax, PNY, etc.

The modern GPU supply chain is often described as the "fabless → foundry → AIB" model: a chip designer (e.g., NVIDIA) sends designs to a foundry (e.g., TSMC), which produces the dies, and then AIB partners turn those dies into retail graphics cards.

History of Firmware stack

Technology	Key Milestones and Description
Early BIOS	Originated in 1975 with Gary Kildall's CP/M OS as machine-specific boot code. Standardized in IBM PC (1980s) as proprietary ROM-based firmware for hardware initialization and booting. Reverse-engineered by companies like Phoenix, AMI, and Award for compatible systems. Limited to 16-bit real-mode, small drives (MBR), and basic peripherals.
Transition to UEFI	Developed by Intel in early 2000s to overcome BIOS limitations (e.g., 16-bit constraints, no support for >2TB drives). Introduced 64-bit support, GPT partitioning, Secure Boot, modular drivers, and faster boot times. Wide adoption in 2010s; required for Windows 8 (2012) features like Secure Boot. Compatibility Support Module (CSM) retained for legacy BIOS modes. Now standard, mandatory for modern OS (e.g., Windows 11 requires UEFI + Secure Boot + TPM 2.0).
AMD-Specific: AGESA	Introduced ~2003–2007 as proprietary library for initializing AMD64 processors, memory, chipsets, and controllers. Provided as binary blobs to motherboard vendors for integration into BIOS/UEFI. Enabled rapid platform development; briefly open-sourced in 2011 (stopped after Family 15h). Evolved with UEFI; critical for long-lived sockets like AM4/AM5. Updates (e.g., ComboPI versions) add CPU support, fixes, and security patches.
Shift to Open-Source: openSIL	Announced April 2023 as modular, C-based open-source stack (MIT-licensed on GitHub) to replace AGESA. Components: Silicon Library (low-level init), Platform Library (board-specific), Utilities Library (shared functions). Goals: Transparency, community auditing, security, faster integration, reduced closed-source reliance. Proof-of-concept on EPYC Genoa/Turin and Phoenix (Zen 4). Production rollout: 6th Gen EPYC "Venice" (Zen 6 server) in 2026 (first full openSIL, code release ~1 quarter post-launch). Client Ryzen "Medusa" (Zen 6) openSIL support in 1H 2027. AGESA phased out progressively (full replacement likely by Zen 7 or later). Reflects industry trend toward open firmware for enterprise and hyperscalers.

UEFI and AGESA/openSIL operate at different layers of the PC boot process and are not direct competitors. UEFI is the overall firmware interface standard, while AGESA and openSIL are AMD-specific components that provide low-level silicon initialization and are integrated into a host firmware (typically UEFI, but potentially others like coreboot).

Aspect	UEFI	AGESA / openSIL
Role	Full firmware interface: provides boot services, runtime services, driver model, Secure Boot, GUI setup, and OS handoff.	AMD-specific silicon initialization library: handles early CPU, memory, chipset, and controller setup.
Scope	Complete boot environment (replaces legacy BIOS).	Low-level hardware initialization for AMD processors only (called by the host firmware).
Vendor/Standard	Industry standard defined by the UEFI Forum (Intel-initiated, supported by AMD, ARM, etc.).	AMD-exclusive (AGESA proprietary; openSIL open-source under MIT license).
Integration	Host firmware (e.g., AMI Aptio, Phoenix SecureCore, TianoCore reference implementation) used on most modern motherboards.	Provided to motherboard vendors as a library/blob (AGESA) or source code (openSIL) to integrate into the host firmware.
Open-Source Status	Partially open (e.g., EDK II/TianoCore reference is open-source).	AGESA: Proprietary binary blobs. openSIL: Fully open-source (GitHub-hosted).
Compatibility	Cross-platform (Intel, AMD, ARM systems).	AMD x86 platforms only.
Key Features	Bootloader services Driver model Secure Boot GUI setup OS handoff	Processor core initialization Memory training and configuration Power management setup Chipset and HyperTransport/Link initialization Modular components in openSIL (Silicon, Platform, Utilities Libraries)

Marketing tricks

Beware the Megahertz Myth, higher clock speeds don’t always mean better performance especially comparing two different CPU architecture. There are other factors due to architectural differences that affects performance; e.g., fewer pipeline stages, wider execution units. Similarly, some older CPUs that have high clocks but weaker single-threaded performance and shared FPUs (e.g., FX-4350 has 2 FPUs for 4 cores), making them poor choices for emulation. Since at least 1997, "process nodes" have been named purely on a marketing basis, and have no direct relation to the dimensions on the integrated circuit; neither gate length, metal pitch or gate pitch on a "28 nm" device is twenty-eight nanometers.[13] A common source of confusion arises from the difference between generic “7 nm node” standards (such as the IRDS/IEEE roadmap) and actual vendor implementations. The IRDS values represent theoretical, retrospective ideals rather than real-world fab measurements. Similarly to board partners for GPUs, vendor processes differ significantly from one another (e.g., exact stack height, inner/outer spacer materials, and how each company integrates it with backside power delivery; Intel PowerVia, TSMC Super Power Rail later, etc). For instance;

• TSMC N7: CGP = 57 nm, MMP = 40 nm
• Samsung 7LPP: CGP = 54 nm
• Intel 7 (formerly 10 nm): CGP = 60 nm

As process nodes have shrunk, the fundamental transistor structure (transistor types through history) has evolved from planar designs to various multigate architectures to maintain electrostatic control, reduce leakage, and allow further scaling:
Planar bulk MOSFET (1960s–~2011): Classic single-gate flat transistor used from micron-era nodes down to ~22 nm.

Planar double-gate MOSFET (DGMOS) (research 1990s–2000s): Thin-body planar transistor with top and bottom gates; explored by IBM and others but never entered volume production.

FlexFET (early 2000s): Independent double-gate planar SOI transistor developed by American Semiconductor; used in some radiation-hardened and flexible-electronics applications.
FinFET (Tri-gate) (commercial 2011–present): First mainstream 3D multigate transistor; gate wraps the channel on three sides. Introduced by Intel at 22 nm (Ivy Bridge), later adopted by TSMC/Samsung at 16/14/10/7/5 nm and Intel up to Intel 4.
GAAFET (Gate-All-Around FET) / Nanosheet FET (commercial 2022–present): Gate completely surrounds the channel. Generic term for the architecture. Below "3 nm", all leading logic processes (TSMC N3E/N2, Samsung SF2, Intel 18A) are GAA-based; FinFET is no longer scalable for cutting-edge density.

MBCFET (Samsung’s branded GAAFET using stacked nanosheets, debuted with 3 nm class nodes in 2022).

RibbonFET (Intel’s branded GAAFET nanosheet implementation, first used in Intel 20A (2024–2025) and continued in 18A).

Lower metal layers (M0/M1) are used for dense local interconnect near the transistors, while higher layers (M2+) are thicker, wider routing layers for long-distance signals and power delivery; therefore, only the tightest layers define density scaling.

This table includes several projected and estimated values and is not intended to represent 100% confirmed specifications
CPU Peak FP32 reports the maximum theoretical floating-point performance for vector math. PassMark STR (Single Thread Rating) reflects real-world single-core instruction throughput (higher is better).
Physical dimensions are key scaling metrics: Gate Length shrinks slowly in modern nodes (~20nm) while Contacted Gate Pitch (CGP) is the primary density metric. Min. Metal Pitch (MMP) refers to the tightest metal layers (M0/M1) that define transistor density, distinct from wider top layers.
Second section of the table is for consumer mid-tier discrete GPU process node evolution.

CPU / APU	Marketed Node	Gate Length	CGP	MMP	CPU Transistor Count	GPU Transistor Count	Die Size	Transistor Density	CPU Peak FP32	PassMark STR	GPU Peak FP32	Power	Min. ISA	Yield / Cost
Intel i486DX2-66 (P24, 1992)	800 nm (Intel)	≈ 800 nm	≈ 1500 nm (est.)	≈ 1000 nm (est.)	~1.2 M (1 core + 8 KB L1)	—	~81 mm²	~0.015 MTr/mm²	~0.06 GFLOPS (FPU)	—	—	~5 W	x86 (i486 baseline)
Celeron 300A (Mendocino, 1998)	250 nm (Intel)	≈ 250 nm	500–600 nm	300–350 nm	~18.9 M (1 core + 128 KB L2)	—	110 mm²	~0.17 MTr/mm²	0.6 GFLOPS (FPU)	~65 (est.)	—	~17 W	x86 (i686 baseline)
Intel Pentium III (OG Xbox, 2001)	180 nm (Intel)	≈ 180 nm	250–280 nm	110–120 nm	~28.1 M (P3/Celeron, 128 KB L2)	—	~95 mm²(CPU est.)	~0.3 MTr/mm² (CPU est.)	2.9 GFLOPS (SSE)	~150 (est.)	—	~20–30 W	x86 (SSE baseline)
AMD Athlon 64 (Clawhammer, 2003)	130 nm (SOI)	70–80 nm	190–200 nm	160 nm	105.9 M (1 core + 1 MB L2)	—	144 mm²	~0.74 MTr/mm²	~9.6 GFLOPS (SSE)	622	—	89 W TDP	x86-64 (v1)
Intel Core 2 Duo E8500 (Wolfdale, 2008)	45 nm (Intel)	≈ 35 nm	120–130 nm	90–100 nm	410 M (2 cores + 6 MB L2)	—	107 mm²	~3.8 MTr/mm²	50.6 GFLOPS (SSE)	1 323	—	65 W	x86-64 (v2)
Jaguar APU (PS4 Launch 2013)	28 nm (TSMC HPM)	≈ 25 nm	112 nm	80 nm	~450 M (2×4-core + L2)	~1.31 B (GCN 1.0)	347 mm² APU ~160 mm² CPU	~1.3 MTr/mm² CPU ~5.1 MTr/mm² APU	102.4 GFLOPS (SSE/AVX)	~545 (est.)	1840 GFLOPS (18 CU)	~75–100 W (APU)	x86-64 (v2)	~$60 ($83 in 2026)–$80 ($111 in 2026) / die
Intel Core i7-6700K (Skylake, 2015)	14 nm (Intel)	≈ 20 nm	70–78 nm	42 nm (Mx)	1.75 B (4-core + iGPU + L3)	~0.184 B (HD 530)	122 mm² (uncore) 82 mm² (CPU est.)	~14.3 MTr/mm²	270 GFLOPS (AVX2)	2 498	347 GFLOPS (24 EUs)	91 W TDP	x86-64 (v3)
Zen 2 APU (PS5 Oberon, 2020)	7 nm (TSMC N7)	≈ 18–20 nm	54–57 nm	36 nm	~2.8 B (8 cores + 8 MB L3 est.)	~7.8 B (RDNA 2, 36 CUs)	308 mm² (full APU)	~34.4 MTr/mm² (APU)	~448 GFLOPS (AVX2 est.)	~2 050 (est.)	10280 GFLOPS (36 CU est.)	~180 W (max)	x86-64 (v3)	~$100 ($124 in 2026)–$120 ($149 in 2026) / die
Intel Core i5-12600K (Alder Lake, 2021)	Intel 7 (10 nm)	≈ 17–18 nm	54 nm	30 nm (M0)	~3.4 B (6P) ~1.1 B (4E) ~5.3 B (uncore)	~0.8 B (Xe-LP)	205 mm² ~64 mm² (P) + ~16 mm² (E)	~73 MTr/mm² (avg) ~80 MTr/mm² (P) ~65 MTr/mm² (E)	~650 GFLOPS (AVX2) 860 w/ AVX-512 if available	3 922	1230 GFLOPS (32 EUs)	125 W (PL1) 150 W (PL2)	x86-64 (v3) v4 if available
AMD Ryzen 5 9600X (Zen 5, 2024)	4 nm / TSMC N4P	≈ 14–15 nm	51 nm	28 nm (M0)	~8.3 B (8-core CCD, 6 active)	~0.15 B (on I/O Die est.)	70.6 mm² (CCD)	~118 MTr/mm²	1040 GFLOPS (AVX2) 2080 w/ AVX-512	4 566	~1130 GFLOPS (2.2GHz, 2 CU, RDNA 3+)	65–88 W	x86-64 (v4)
AMD Ryzen 5 Medusa (Zen 6, 2026-27) Future projection	~3 nm (TSMC N3E)	≈ 12–15 nm (est.)	~45–50 nm (est.)	~22–25 nm (est.)	~12–16 B (12-core CCD est., 8 active)	?	~100 mm² (CCD est.)	~130–150 MTr/mm² (est.)	~1470 GFLOPS (AVX2 est.) ~2900 w/ AVX-512	~5 400 (proj.)	~1540 GFLOPS (est.) (3GHz, 2 CU, RDNA 4 or 5)	~90–120 W TDP	x86-64 (v4)
GPU	Marketed Node	Gate Length	CGP	MMP	CPU Transistor Count	GPU Transistor Count	Die Size	Transistor Density	CPU Peak FP32	PassMark G3D	GPU Peak FP32	Power	API Shader Model	Yield / Cost
Radeon 8500 (R200, 2001)	150 nm (TSMC)	≈ 130–140 nm	~450 nm	~300 nm	—	60 M	108 mm²	0.56 MTr/mm²	—	7	55 GFLOPS	40 W
NV2A (Xbox GPU, 2001)	150 nm (TSMC)	≈ 130–140 nm	~450 nm	~300 nm	—	57 M	≈ 115 mm²	0.50 MTr/mm²	—	—	233 GFLOPS (fixed-function est.)	233 MHz core ~30–35 W	DirectX 8.1 SM 1.1–1.3 equiv.
Radeon 9700 PRO (R300, 2002)	150 nm (TSMC Low-k)	≈ 130 nm	~450 nm	~300 nm	—	107 M	218 mm²	0.49 MTr/mm²	—	54	260 GFLOPS	65 W	DirectX 9.0 Shader Model 2.0
GeForce 6600 GT (NV43, 2004)	110 nm (TSMC)	≈ 95 nm	~340 nm	~220 nm	—	146 M	156 mm²	0.94 MTr/mm²	—	143	320 GFLOPS	65 W	DirectX 9.0c Shader Model 3.0
GeForce 7600 GT (G73, 2006)	90 nm (TSMC)	≈ 80 nm	~300 nm	~180 nm	—	177 M	127 mm²	1.39 MTr/mm²	—	237	360 GFLOPS	40–56 W	DirectX 9.0c Shader Model 3.0
HD 3870 (RV670, 2007)	55 nm (TSMC)	≈ 45 nm	180 nm	110 nm	—	666 M	192 mm²	3.5 MTr/mm²	—	552	800 GFLOPS	105 W
HD 4870 (RV770, 2008)	55 nm (TSMC)	≈ 45 nm	180 nm	110 nm	—	956 M	263 mm²	3.6 MTr/mm²	—	1 385	1150 GFLOPS	160 W
HD 5870 (Cypress, 2009)	40 nm (TSMC)	≈ 35 nm	140 nm	90 nm	—	2.15 B	334 mm²	6.4 MTr/mm²	—	2 180	2720 GFLOPS	188 W
HD 6870 (Barts XT, 2010)	40 nm (TSMC)	≈ 35 nm	140 nm	90 nm	—	1.70 B	255 mm²	6.7 MTr/mm²	—	2 206	2016 GFLOPS	151 W
HD 7870 (Pitcairn, 2012)	28 nm (TSMC)	≈ 24 nm	90 nm	64 nm	—	4.31 B	212 mm²	20.3 MTr/mm²	—	4 570	2560 GFLOPS	175 W
GTX 970 (GM204, 2014)	28 nm (TSMC)	≈ 24 nm	90 nm	64 nm	—	5.2 B	398 mm²	13.1 MTr/mm²	—	9 650	3900 GFLOPS	145 W
GTX 1070 (GP104, 2016)	16 nm (TSMC 16FF+)	≈ 20 nm	78 nm	44 nm	—	7.2 B	314 mm²	22.9 MTr/mm²	—	13 500	6500 GFLOPS	150 W
RTX 2060 (TU106, 2019)	12 nm (TSMC N12)	≈ 18 nm	66 nm	40 nm	—	~6.8 B (CUDA/shaders) ~1.7 B (RT cores) ~2.3 B (Tensor cores)	445 mm²	24.3 MTr/mm²	—	14 110	6500 GFLOPS	160 W
RX 5600 XT (Navi 10, 2020)	7 nm (TSMC N7)	≈ 18–20 nm	57 nm	40 nm	—	10.3 B	251 mm²	41.0 MTr/mm²	—	15 920	7190 GFLOPS	150 W	DirectX 12 Shader Model 6.5
RTX 3060 (GA106, 2021)	8 nm (Samsung 8N)	≈ 16–18 nm	64 nm	44 nm	—	~8.1 B (CUDA/shaders) ~1.4 B (RT cores) ~2.5 B (Tensor cores)	276 mm²	43.5 MTr/mm²	—	17 000	12700 GFLOPS	170 W
RX 7600 (Navi 33, 2023)	6 nm (N6) 5 nm (N5)	≈ 14–16 nm	51 nm	28 nm	—	~18.1 B (shaders) ~1.4 B (RT) ~1.3 B (AI/matrix)	204 mm²	102 MTr/mm²	—	16 580	21800 GFLOPS	190 W
RTX 4060 (AD107, 2023)	4N (TSMC N4)	≈ 12–14 nm	49 nm	28 nm	—	~11.2 B (CUDA/shaders) ~2.1 B (RT cores) ~5.6 B (Tensor cores)	144 mm²	131 MTr/mm²	—	19 550	15100 GFLOPS	115 W
RX 9060 XT (Navi 44, RDNA 4, 2025)	4NP (TSMC N4P)	≈ 12–14 nm	49–51 nm	28 nm	—	~22.4 B (shaders) ~1.9 B (RT) ~2.2 B (AI/matrix)	200 mm²	132.5 MTr/mm²	—	19 850	20000 GFLOPS	160 W
RTX 5060 (GB205, Blackwell, 2025)	4NP (TSMC N4P)	≈ 12–14 nm	49 nm	28 nm	—	~18.5 B (CUDA/shaders) ~3.8 B (RT cores) ~8.8 B (Tensor cores)	263 mm²	118 MTr/mm²	—	20 850	25000 GFLOPS	170 W

CGP Scaling and Microprocessor Law Eras

Recommended Reading

Check out the Displays, Controllers, and Input lag pages for additional context. Websites like PCPartPicker can help with hardware selection.

Demanding Emulation

Main article: #Recommended Specifications

If you're aiming for demanding emulation ▰▰▱ and ▰▰▰ (e.g., 3D arcade boards, Pentium II emulation, PS2, Xbox, GameCube, or newer systems), avoid mobile devices or low-power Single Board Computers (SBCs) like the Raspberry Pi, as their CPU performance is generally insufficient for these tasks due to thermal and power limitations. Even recent Android-based handhelds such as Retroid Pocket 5, or handheld gaming computers such as the Steam Deck, may struggle to meet the requirements for these tasks. Mini-PCs such as Steam Machine would offer a significant leap in performance for emulation. Currently, FPGA-based retro hardware recreations, such as the MiSTer FPGA or Analogue consoles (Mega Sg, Super Nt, Duo, etc.) do not support emulation of demanding systems. If you're purchasing a notebook/laptop or handheld gaming computer, look for one with a CPU, such as ≥ Zen 4-based Ryzen notebook APUs family (since 7040) or Ryzen handheld APUs (since Z1), that at least offers some level of AVX-512 support. Desktop CPUs outperform laptop variants due to higher clock speeds and better cooling. Mobile GPUs with the same name as desktop parts (e.g., RTX 4060 mobile) are significantly slower, sometimes 50–60 % of desktop performance. Power limits are usually 80–140 W for the GPU (vs. 200 W+ on desktop). Under prolonged load, clocks drop noticeably; single-thread CPU performance suffers the most. A few rare “desktop-replacement” laptops use actual desktop CPUs, but they are very heavy (>4 kg), loud, and expensive.

Architecture Recommendation

For both development and end-user performance, x86-64 (AMD64/Intel 64) remains by far the most practical target architecture. Other architectures (e.g., PowerPC, SPARC, MIPS, IA-64, Alpha, PA-RISC, 68000) lack support and; in cases where emulation is possible, it typically requires an additional layer of x86 emulation just to run the emulator itself on the non-x86 host, resulting in degraded performance. Native emulators for these are rare or outdated. Development and maintenance of software emulators and related libraries on ARM-based systems receive considerably less attention than on x86. Several developers have cited the often hostile or “toxic” community surrounding certain ARM-focused emulation projects as a contributing factor. Additionally, the vast majority of ARM users are on battery-powered mobile devices (smartphones and tablets), which inherently have stricter thermal and power limitations compared to the typical x86 user base found on desktops, laptops, mini-PCs, and high-performance handheld gaming computers. Critically, developers targeting complex emulation projects benefit enormously from deep familiarity with the x86/x86-64 instruction set architecture (ISA), its extensions (SSE, AVX, etc.), and the mature tooling ecosystem built around it over decades. Desktop-class operating systems (Windows and Linux on x86) provide fairly stable, well-documented drivers, libraries, system functions, and graphics APIs (OpenGL, Vulkan, Direct3D) that emulator authors rely on heavily. Equivalent low-level APIs and driver quality on ARM Linux or mobile platforms are often less mature, more fragmented, or simply absent, making performance-critical development far more difficult. The professional toolchain; IDEs (Visual Studio, CLion), debuggers (WinDbg, x64dbg, GDB/LLDB with full extensions), profilers (VTune, RenderDoc, PIX), and reverse-engineering tools (Ghidra, IDA Pro, Binary Ninja) was developed and remains most mature on x86-64. On ARM, many of these tools are either unavailable natively, run under emulation with reduced functionality, or suffer from missing features and instability that make day-to-day development noticeably harder. Keep in mind that; for demanding emulation, dynarec and Just-In-Time (JIT) compilation support is vital for good performance. Apple Silicon (macOS) is not an exception within the ARM world, unlike on iOS/iPadOS where 'jailbreaking' might be needed to enable JIT, emulators on Mac systems typically utilize JIT without such modifications, but graphics performance in emulation on Macs is significantly influenced by Apple's native Metal API. Software relying on Vulkan or OpenGL may use wrappers like MoltenVK to run on Metal, or may use older, deprecated versions of OpenGL, which can impact efficiency compared to native Metal implementations. See high and low-level emulation for more information about which methods used when emulating components or entire systems.

Overclocking (advanced)

Overclocking your CPU, GPU and DRAM, including boosting clock speeds and tightening memory timings, can potentially increase emulation performance, particularly on desktop PCs with robust cooling like AIO, custom water cooling, or delidded chips with liquid metal. Efficient and high-quality VRM components (capacitors, chokes, MOSFETs) with good thermal performance, optimizing using the Load-Line Calibration (e.g., for balanced vDroop and low voltage ripple/minimal VPPmax) and VRM switching frequency (e.g., 250–300 kHz) are also crucial for longetivity for your motherboard and CPU while minimizing heat with maintaining stability/sustained overclocks.[14] Keep CPU voltages within safe limits (which is different for each chip) to prevent degradation, and maintain load temps below recommended levels (again, it is different for each chip) with efficient cooling and profiles. For heavy emulation workloads, you can reduce voltage and heat while preserving high clocks; the "silicon lottery" affects overclocking potential due to manufacturing tolerances and binning, so test stability thoroughly to avoid crashes or WHEA errors. Always verify your PSU, voltage regulator and VRM limits before attempting. Laptops and handhelds have limited thermal capacity, making overclocking riskier and less effective. For NVIDIA GPUs, managing power states (P-states) is critical when overclocking. Lots of software often trigger P2 states (balanced 3D/compute mode with lower memory clocks) instead of P0 (max performance). You can force P0 via tools like NVIDIA Inspector or nvidia-smi (nvidia-smi -pm 1) for consistent core and memory clocks. But instead, we're recommend using MSI Afterburner’s voltage/frequency curve to target stable undervolts (e.g., 0.95–1.0V at 2.7–3.0 GHz) for efficiency. Monitor P-states to avoid throttling, especially in GPU compute-heavy emulators. Remember, there is no software with the same precision as hardware-based measurements (e.g., using an oscilloscope connected to CPU die-sense pins, with ~150 μs transients). HWiNFO and similar tools rely on motherboard sensors and polling intervals (typically milliseconds), which are too slow to accurately measure rapid voltage fluctuations (microsecond range) like Vppmax (peak-to-peak voltage ripple) during load transitions.

Modern Hardware Issues

Also see High and low-level emulation#Modern Graphics Backends section.

Hardware	Issues	Impact on Emulation	Mitigation	Fixed?
Intel CPUs (Raptor Lake+)	Voltage instability, crashes	Crashes, stuttering	Update BIOS/microcode, use Windows 11, disable E-cores	The issue of voltage instability and crashes with recent intel CPUs has been widely reported since late 2023. While Intel has identified microcode issues and motherboard manufacturers have released numerous BIOS updates to address this, it's not a single, universally "fixed" problem. The situation often varies by specific motherboard model, BIOS version, and even silicon lottery. Users often need to apply the latest BIOS, and some still experience issues depending on their specific workload or system configuration. Therefore, it's an ongoing effort that requires continuous updates from both Intel (microcode) and motherboard vendors (BIOS).
Intel CPUs (Raptor Lake+)	OS scheduler issues	Stuttering, reduced FPS	Use Windows 11, CoreDirector tool	Hybrid CPU architectures (P-cores/E-cores) introduced with Intel's 12th Gen and continued with Raptor Lake+ require sophisticated OS scheduling to allocate tasks efficiently to the appropriate cores. Windows 11's scheduler was specifically designed with these architectures in mind and generally performs better than Windows 10 for hybrid CPUs. However, even with Windows 11, edge cases or specific demanding applications (like some emulators) can sometimes benefit from manual core affinity management tools (like Process Lasso/CoreDirector, or their own implementations). If the OS scheduler was perfectly resolved for all scenarios, such third-party tools wouldn't be as necessary or effective. Thus, it's improved but not absolutely perfect for every workload.
Intel ARC GPUs	DirectX 9.0c (also see Windows NT 5.x emulators)	Latency, graphical glitches	Use DirectX 12/Vulkan, update drivers	At the launch of Intel Arc GPUs, DirectX 9 support was notably poor because Arc GPUs handle DX9 API calls via a wrapper (D3D9On12), rather than natively. Intel acknowledged this and consistently released driver updates throughout 2022 and 2023 that significantly improved DX9 support in many titles. While performance has improved dramatically, it's still a wrapper, which can inherently introduce some overhead or minor compatibility quirks compared to native DX9 support on older hardware.
Intel ARC GPUs	Driver stability	CPU overhead, game-specific bugs	Driver updates	Intel Arc GPUs are a relatively new architecture, and like all new GPU lines, driver maturity takes time. Intel has been on an aggressive schedule of driver releases, frequently addressing bugs, improving performance, and reducing CPU overhead in various games and applications. While each update brings progress, new issues can sometimes emerge, or existing ones might require further refinement. This is a continuous process characteristic of a developing hardware ecosystem.
AMD RX and RX XT GPUs	OpenGL performance	Slow rendering, graphical bugs	Switch to alternative renderer backends ✔️ Fixed with Adrenalin 22.7.1 [See AMD Driver Update]	For many years, AMD's OpenGL driver performance and stability have generally been considered less robust than Nvidia's, particularly for applications and emulators that used OpenGL. While AMD has made strides, and modern emulators often offer DirectX 11/12 or Vulkan backends as well, native OpenGL performance can still be a weaker point. The common mitigation of switching to alternative backends indicates that while there are ways to achieve good performance, the core OpenGL driver may not always be optimal.
AMD RX and RX XT GPUs	Fragment shader interlock	Suboptimal performance vs. Nvidia	Use Adrenalin 24.12.1 or later, test configurations	VK_EXT_fragment_shader_interlock was added in Adrenalin 24.12.1. This confirms that the feature is now supported in the driver. However, the presence of a feature doesn't always equate to immediate, fully optimized performance that matches competitors in all scenarios. While the feature 'exists', its implementation could always be crippled due to hardware limitations or interaction with specific emulator workloads might still require further optimization or refinement from AMD.
AMD RX and RX XT GPUs	Vulkan performance	Performance drops, artifacts	Use DirectX 11, update drivers	While AMD generally has good Vulkan performance in modern games, specific emulators can expose unique behaviors or bugs. Issues like performance drops due to "barrier region bit" or driver timeouts are examples of ongoing challenges that require continuous driver refinement. Like Arc drivers, Vulkan drivers are constantly evolving, and specific optimizations or bug fixes are regularly pushed out in new Adrenalin releases.
Nvidia GPUs	Crashes, shader issues due to recent drivers	Crashes, stuttering	Roll back drivers, monitor updates	It's not uncommon for specific "Game Ready Driver" releases to introduce new issues, sometimes related to shader compilation, stability, or performance regressions in certain games or applications, including emulators. The community frequently discusses problematic driver versions recently.

Build Guide for Emulation

X86 (recommended)

CPU

• Prioritize Single-Core Performance: This is the top factor for emulator performance. Focus on CPUs with high Instructions Per Clock (IPC), typically found in newer generations and architectures. Shader stutters are totally normal for ≥ seventh-gen emulation. If available, using Pre-built Shader Caches (if compatible) or Async Shader Compilation option (if available), on top of upgrading to a better CPU could cut down the stutter intervals a bit (faster compilation = smoother runs). See TechPowerUp emulation chart, CPU Tier List for RPCS3 and John IV's MAME Benchmarks for benchmarks with emulators. If you don't have the time to research, it is recommended to get one of the most single-thread price/performance value chip on the market with considering the factors mentioned below.

• AVX2 and x86-64-v3 Support: Consider this a baseline requirement for a modern emulation build. Many emulators use AVX2 instructions to significantly speed things up nowadays. Ensure any CPU you consider supports it.

• AVX-512 and x86-64-v4 exists and can offer benefits in specific emulators due to more registers or specific instructions, but support is less widespread, hardware implementations vary, and it's less critical than strong AVX2 support for most users currently. Early implementations sometimes required multiple clock cycles for certain operations or could cause the CPU to downclock significantly under heavy load due to power/heat constraints, potentially negating performance gains in some scenarios. Newer implementations are better (e.g, Zen 5). The AMD Zen 5 desktop and server microarchitectures address the limitations of prior designs by implementing a native 512-bit vector datapath in the Floating-Point Unit, which allows most AVX-512 instructions to execute in a single clock cycle, significantly doubling the vector throughput compared to the double-pumped 256-bit AVX512 execution used in Zen 4. Critically, Zen 5 was designed for power efficiency, allowing it to execute heavy AVX-512 code with minimal to no frequency downclocking, directly solving the major performance-negating issue that plagued older, high-end Intel Skylake-X and similar implementations. This consistency and the native throughput make Zen 5's AVX-512 support a more reliable and substantial performance booster for optimized applications, including emulators that benefit from the instruction set's features like the doubled number of registers (32 ZMM) and specialized instructions like VNNI. Looking ahead, the upcoming Zen 6 architecture builds on this foundation with additional AVX-512 extensions, including AVX512-BMM for bit matrix multiplications (useful in sparse or binary data processing for emulation workloads), AVX-NE-CONVERT for efficient low-precision floating-point conversions, AVX-IFMA for fused integer multiply-adds, AVX-VNNI-INT8 for 8-bit neural network dot products, and AVX512-FP16 for native half-precision floating-point operations. These enhancements, confirmed via AMD's Znver6 ISA manual and early GCC/Binutils patches, promise further gains in power efficiency and throughput for vector-heavy emulation tasks, potentially enabling broader adoption of low-precision optimizations without GPU offload. There are various rumours about power consumption of AVX-512 since the Skylake X's implementation, see this video about that. Also see uops.info, and PlayStation 3 emulators#Emulation issues section for more information. That is to say, that the kinds of AVX-512 optimizations that RPCS3 (and other emulators such as Yuzu, Citra, Vita3k, Xenia) makes are actually fairly broadly applicable across consoles. But since any machine that supports AVX-512 should be fast enough to run older systems like N64 or PS2 games at fullspeed, the gains would be in power efficiency rather than performance.[15]

• Core Count: Multithreading often irrelevant prior to PlayStation 3 emulation. While CPUs with very high IPC performance are usually recommended for emulation, most CPUs nowadays feature more than 4 cores with even higher clock speeds. This advancement, a notable improvement over earlier, lower-clocked HEDT CPUs, means that selecting a modern higher core-count CPU no longer presents a disadvantage; in fact, it often offers superior performance for emulation due to higher clock speed.

• Minimum: Aim for at least 6 cores / 12 threads. If on a 12th Gen Intel CPU or newer, this is the number of P-cores rather than physical cores. E-cores are mostly useless for emulation, since emulators like PCSX2 (and probably other updated popular emulators) will pin workloads to the performance cores anyway.
• Recommended: 8 cores / 16 threads is a good sweet spot for handling demanding emulators alongside compiling modules, shader compilation and background tasks.

• If you're into virtualization, look for AMD-Vi or Intel VT-d supported chips and IOMMU supported motherboards.[16][17][18]

RAM

If you don't want to waste your time, just prioritize getting two sticks of RAM for dual-channel performance and aim for a total capacity suitable for your needs within your budget. If you have time however, when choosing speed and latency, target the recommended 'sweet spot' for your platform. Be aware that the quality of the underlying memory chips used on the modules affects how reliably and stably they perform at those rated speeds and latency (recommended to see buildzoid's youtube channel for this). Opting for kits considering these, including motherboard's Memory QVL and better-quality or better-binned memory chips, generally provides better experience compared to the absolute cheapest or expensive options.

GPU

Choosing the right GPU for emulation is more important now than it used to be. This increased importance is due to recent advancements like compute shader renderer implementations. Actively maintained popular emulators may leverage specific modern GPU hardware features and APIs for optimized rendering. Graphical and post-processing enhancements: e.g., resizable internal resolution, texture filtering hacks, aspect ratio hacks, texture replacement, ray-tracing/screen-space ray-traced global illumination shaders, internal framerate hacks, frame generation technologies, AI powered filters, post-processing options such as shader chains/presets offered by modern emulators, or using EmuVR instead of standalone emulator software demands higher GPU performance as well.

• Vulkan 1.3[19][20] and D3D12 12_1 or 12_2 support. - See registry/vulkan/specs, Direct3D 12 levels and List of Vulkan extensions used in RPCS3.
• GPU with drivers still up-to-date.
• If you're heavily into virtualization, you could look for an GPU that supports SR-IOV or GPU Paravirtualization.
• Choose one of the latest GPU models available on the market within your budget. See these webpages: [21][22]

PSU

See this PSU Tier List and thefpsreview.com's PSU reviews.

ARM

CPU

• Minimum: A core with SVE (Scalable Vector Extension) support. SVE was introduced in ARMv8.2-A, but remained optional for many years. Nearly all smartphone and application processor cores based on ARMv8.2-A through ARMv8.5-A (including Cortex-A75, A76, A77, A78, and derivatives such as Kryo 300/400/500 series) do not implement SVE. They only support fixed 128-bit NEON/ASIMD. The earliest widely available consumer core with SVE is the Cortex-A710 (ARMv8.6-A). Choose a device with A710 or newer if possible.
• Recommended: A core with SVE2 support. SVE2 is mandatory starting with ARMv9.0-A and is present in ARMv9.2-A cores. Cortex-A715, A720, X3, X4, X925, and newer; or recent Qualcomm Kryo cores based on ARMv9-A (Kryo Mobile 8 series and later).

GPU

Choose Snapdragon Adreno platforms for GPU as much as possible due to better driver support and possibly capabilities regarding to API and libraries. placeholder text

Storage

Storage is a critical component when building a system for emulation and preservation, as it affects capacity, and data longevity. Recommended to see storagereview.com's reviews for SSDs, backblaze's hard drive failure rates chart for HDDs.

Types of approach and storage;

• Hot Storage: Data you access frequently, like emulators, ROMs, or save files. SSDs (especially NVMe) are best for hot storage due to their performance.
  • Solid-State Drives (SSDs) with DRAM Cache: These are useful for heavy workloads like frequent data transfers & read/write tasks, minimizing latency, and ensuring consistent efficiency during sustained, high-intensity workloads.
• Cold Storage: Data accessed infrequently, such as archived game ISOs or backups. HDDs or NAS are cost-effective for cold storage, prioritizing capacity and reliability over performance.
  • Hard Disk Drives (HDDs): These are ideal for "cold storage" (long-term archival of large game libraries, ISOs, or backups) where access speed is less critical. Make sure the drive is CMR, not SMR.
  • Network-Attached Storage (NAS): NAS is perfect for securely storing and sharing large game archives across multiple devices, with redundancy options like RAID to protect against data loss.
  • Cloud Storage: Cloud storage is perfect for cold storage, providing secure, scalable backups for game archives with protection against local drive failures. It can be a strong alternative to NAS for users with a robust internet connection, offering similar off-site redundancy without the need for local hardware setup.
• Hybrid Approach: Combine a smaller SSD (1TB) for hot storage with a larger HDD (8TB+) or NAS for cold storage to balance performance and capacity.

Display

Main article: Displays

Peripherals

Main article: Input lag

Main article: Controllers

Operating System

For performance comparison: See Timing and Synchronization, Platform-Specific Memory and I/O Optimization sections and RPCS3's SPURS Test v1.2.1 Benchmark Results.

Prerequisites and Dependencies (Windows):For fresh Windows installations, installing commonly required runtime packages is recommended, as many applications rely on them. These include the Visual C++ Redistributable Runtimes All-in-One and the DirectX Runtime Offline Installer. Applications built with a statically linked C++ runtime do not require external VC++ redistributables, since all needed components are embedded in the executable. However, most software still depends on shared system libraries, so missing dependencies are a common cause of launch errors.

Portable Software Considerations: Portable builds of emulators or tools can be useful in non-personal computer environments, plug-and-play setups, multi-boot testing, and guest-account scenarios. “Portable” does not mean the application has no OS-level dependencies; many portable programs still require runtimes such as DirectX, .NET, VC++ redistributables, codecs, etc. According to the Portable Freeware definition, an application is considered stealth when it leaves no persistent registry entries and writes no permanent files outside its own directory after being launched, used, and closed. OS-generated entries (Windows MRU lists, DirectX registration, temporary files in system Temp folders) are generally not counted. Note: “Stealth” refers only to not leaving behind application data; it does not imply anonymity or that system administrators cannot track activity. The ideal definition of portable software includes the following characteristics;

• Runs without installation.
• Functions on older or unpatched Windows versions.
• Minimal coupling to system components such as Internet Explorer, DirectX, system codecs, or .NET (unless necessary for core functionality).
• Writes its configuration files to its own directory rather than the registry or user profile.
• Leaves no permanent traces on the host machine (in ideal/“stealth” cases).
• Works under guest or limited user accounts.
• Tolerates USB drive letter changes.

In practice, few applications meet all of these requirements. Portability can be evaluated at two levels;

• Executable portability: the program runs without installation.
• Settings portability: configuration files are kept within the application directory.

Dependencies related to intended functionality (e.g., IE-based UI for a feed reader, DirectX for a game) are acceptable; unnecessary dependencies are discouraged. On Linux, portable programs often rely on static linking, where required libraries are embedded directly into the executable and configuration files reside alongside the binary. However, the GNU C Library (glibc) is generally not statically linked because updates frequently address security issues and hardware-compatibility improvements. As a result, fully static Linux applications are uncommon. Unlike Windows portable applications (which commonly store settings in the same directory as the executable) this is considered inelegant in Linux environments. Linux programs usually place their configuration files in plain-text form under the user’s $HOME/.config directory. This makes less convenient to back up compared to portable software on windows, but it is simple to version-control with systems like Git. When reinstalling Linux, users typically use distro-wide portable packages (AppImage) or reinstall software through the package manager and restore their configuration files by copying them back into the home directory. Static binaries contain fixed versions of all embedded libraries. Updating the OS will not update these internal copies, meaning old bugs and security vulnerabilities remain inside the program until it is rebuilt. This is a primary reason why many Linux environments discourage fully static applications. Historically, Windows software often suffered from “DLL Hell”: missing, overwritten, or incompatible shared libraries could break installed programs. Portable apps avoided these problems by shipping their own libraries. Native Linux packages rely on strict dependency resolution. If required libraries are missing or incompatible, the package simply cannot install or update. Packages built for one distribution often cannot be used on another due to differing package structures. Flatpak, AppImage, and Snap formats provide per-application libraries or runtime environments to enable cross-distribution portability. This improves convenience but can preserve outdated libraries, depending on update frequency. Users should balance convenience with maintenance and security considerations.

Also see

• Input lag
• Displays
• Controllers