Where every number comes from

What counts as a source

A source is a page any reader can open: the product's specification page on its maker's site, the maker's press release, or an open public dataset such as Blender's benchmark results. Every number in the Lab carries a reference such as [1], and the list at the foot of the page gives the publisher, a link to the page and the date we read it.

For graphics cards we use the reference specifications published by the company behind the chip: NVIDIA, AMD or Intel. Cards that other brands build on the same chip can ship with different clock speeds or power draw; their own pages are the reference for those.

When no source publishes a number, the page says "Not published" in its place. We never fill the gap with a zero, an estimate or a figure from memory.

The Lab holds desktop processors and graphics cards, and the graphics cards section also holds laptop GPUs and workstation cards, each with its kind and its own heading in the list. A laptop GPU's power is the most its laptop's maker lets it draw, and its page says so. A name a maker sells as two models (an RTX 3060 with 12 GB or with 8) is one page with the first model's figures and a note for the other, as Blender lists the name once. The Lab leaves out the PRO processors AMD sells to businesses, laptop and embedded processors, parts sold only inside other makers' computers (OEM), and special editions of a product (a colour, an anniversary) whose main specs are its own: each would be a second page for a part that has one.

How a number reaches a page

1. 1

   Processors and graphics cards come in on their own, from their makers' own pages: AMD's specification tables, Intel's ARK database, and NVIDIA's page for each family of its cards. A program reads them every hour, a few pages at a time, and reads the lists again weekly and each product's page monthly.

2. 2

   The program reads each spec by its fixed name on the maker's page ("Total Cores", "Default TDP"...), not by guessing and not with AI. A cell holding two figures ("165 or 160") gives nothing, so the page says "Not published". A chip missing anything the Lab requires gets no page.

3. 3

   A Blender score is read from Blender Open Data's own figures, under the name that is the product exactly once the maker's fixed words are set aside: "AMD Ryzen 5 7600 6-Core Processor" is the Ryzen 5 7600, and "... 7600X" is not.

4. 4

   A value outside the plausible range for its spec is refused. A value already published is never removed because it disappeared from the maker's page.

5. 5

   The value is saved with its source, the maker's page, and the date it was read, and appears on the page with its source number. When a maker changes a figure, the page's change log says so, with the date.

How two products are compared

Every row of a comparison follows a fixed rule for its spec, the same for every pair: higher is better (video memory, for example), lower is better (power draw, for example), or neither, where more is not better or worse. The better value is green and marked ✓; when the two are equal, neither is marked.

Some rows rank neither side on purpose: cores, threads, clock speeds and cache, and a graphics card's shader units. Across two chip designs, a bigger count is not better performance, so these rows show both values and mark neither. Each maker counts shader units its own way (CUDA cores at NVIDIA, stream processors at AMD), so each value says whose count it is. A processor with two kinds of cores is listed with the total its maker gives, and the split in a note under it; its base clock is its performance cores'.

We don't add rows up, weight them or turn them into a score or a percentage. The two product cards at the top of a comparison repeat rows of its table and add no number of their own, and "Wins on" under each product lists the rows it wins.

A DisplayPort or HDMI version compares by its number alone: the letter after it (2.1a, 2.1b) does not change the port's speed, so two versions with one number are equal. The launch year is as its maker publishes it: AMD gives the day and Intel the quarter, so we show the year; NVIDIA does not publish it on its card pages, so graphics cards have no such row.

You can compare any two products in a section with the comparison box. A verdict, and a place in the section's list of comparisons, are for the pairs an editor has picked, usually because readers search for them.

The Blender score

For graphics cards and processors we also show the score of Blender's benchmark. Blender is a free 3D program, and the score is how fast it renders the benchmark's scenes, in samples per minute added up over the scenes, so higher is faster. It is not our measurement: Blender users run the benchmark on their own computers and publish the results at opendata.blender.org, free for anyone to reuse (CC0).

We show the median of all runs for a card or processor on one Blender version, the same for every product in a section, with the number of runs and, for a graphics card, how Blender ran on it (OptiX on NVIDIA, HIP on AMD, oneAPI on Intel). It measures rendering, not games: a card that renders faster is not always faster in games.

A card or processor with fewer than 10 runs on that version shows no score: the median of a few runs says more about the computers they ran on than about the chip.

Because the runs come from many different computers, two scores less than 5% apart are shown as too close to call (≈), and neither is marked better: in Blender's own results, the same processor sold under two names (with and without graphics) usually differs by about 2% between its two listings. For the same reason, a score we show changes only when Blender's median moves that far from it or further: a median moves a little each time people add runs.

During a power cut

Graphics card, processor and monitor pages show what the device draws from the wall, how many amps that is on a generator subscription, and what it takes from an inverter's battery; the compatibility check shows the same for the parts you pick together. We count only what has a figure: the part's or the monitor's official one, and what you type for other devices on the same line. The rest of the computer (motherboard, RAM, storage, fans) has no official figure, so we don't guess one.

A part's figure is the highest its maker publishes: a graphics card's rated board power, and a processor's maximum turbo power where its maker publishes one (Intel does). AMD publishes the base power (TDP) alone, which the processor exceeds under load: we use it, every result from it says "at least", and we don't compare it with a processor whose figure is its maximum.

A monitor's figure is its official SDR power use from EPREL (the monitors part below). It is measured at the plug, so no power supply comes between and no 80 PLUS badge applies: we count it as it is, as we do your other devices.

A power supply loses part of what it takes from the wall, so a computer draws more from the wall than its parts' figures. We divide by the supply's efficiency as the 80 PLUS badge on it requires, from the program's table for 230 V mains: the lowest efficiency the badge requires between a fifth of the supply's load and all of it, 80 PLUS 82%, 80 PLUS Bronze 85%, 80 PLUS Silver 87%, 80 PLUS Gold 89%, 80 PLUS Platinum 90%, 80 PLUS Titanium 91%, 80 PLUS Ruby 92%. A supply without a badge has no guaranteed efficiency, so we count the parts' figures as they are, and the result says "at least".

Amps = watts ÷ (voltage × power factor). A breaker trips on current, not watts, and the power factor raises the current: the badge requires at least 0.9 (0.95 from 80 PLUS Platinum up) at half the supply's load, and we apply it at every load. For a monitor and your other devices we divide the watts by the voltage, since their power factor is unknown, so their real current may be higher. The voltage is 220 V unless you pick another: the lower voltage gives more amps, the safe side. A generator whose voltage drops under load draws more amps too: at 200 V, 10% more than at 220.

For each subscription (1, 2, 3, 5, 10 A, and yours if you type it) we give what is left of it after what is counted, or how far short it falls, rather than a bare "enough": one part is not the whole computer.

From the battery: the watts from the wall ÷ the inverter's efficiency ÷ the battery's voltage gives the current drawn from it, and the runtime = the battery's voltage × its capacity in amp-hours × the share used × the inverter's efficiency ÷ the watts from the wall. Some of this is assumed, and yours to change: an inverter efficiency of 85%, and a share of 50% for a lead-acid battery (gel or AGM), which lasts longer kept above half charge, and 80% for lithium (LiFePO4).

The real time is shorter in two cases: a lead-acid battery gives less than its rated capacity when drained fast, since that capacity is usually measured over 20 hours. And an inverter that charges its battery from the same subscription takes from its amps too while it charges.

We round to the safe side: watts and amps up, time and what is left of a subscription down. Each step starts from the figure shown before it, so redoing the sum gives the same number.

The graphics card in your computer

Graphics card pages, the compatibility check, game pages and local AI model pages have a "Detect my device" button. When you press it, the site asks your browser for the name of the graphics card it draws with (through WebGL), and never before you press: that name is one of the things trackers tell devices apart by. The name is never sent to our site. It stays in your browser alone, so other Lab pages show it too, until you press "Forget my device".

We match the card's whole name, never part of it: GeForce RTX 4060 doesn't match GeForce RTX 4060 Ti or GeForce RTX 4060 Laptop GPU, which are other products with other figures. A card the Lab doesn't have is shown by the name the browser gave, and we don't pick a similar one in its place.

Some browsers don't give the real name: Safari says "Apple GPU" on every device, Firefox gives the name of a card close to yours followed by "or similar", and a browser with hardware acceleration turned off draws without the graphics card at all. In each case the page says so and picks no card.

A laptop's chip is picked where the Lab lists it: the graphics cards section lists NVIDIA's and AMD's laptop GPUs, and the local AI models' check lists them by their memory. Game requirements as we read them and the compatibility check are about desktop cards, so there the page says it is a laptop's chip and picks none. On a phone or tablet the page asks the browser nothing, and says its graphics chip is built in.

Game requirements, and whether your PC runs them

Game pages are for what Steam lists among its most played and weekly best sellers. A program reads them from Steam itself, with no one in between, and reads each game again about once a day. We copy the Windows requirements as the game's publisher wrote them, in English and unedited, and only name their rows in the page's language. Arabic support (interface, subtitles, audio) is as Steam lists it. When a publisher changes a tier's requirements, or the Arabic support changes, the page's change log dates it.

This data is Steam's as it is, with no warranty from us: each game's publisher writes and changes it. Steam is a trademark of Valve, and the Lab is not affiliated with or endorsed by Valve.

There is no page for what is not a game (software or an add-on), for a game Steam rates as adult sexual content, or for a game with no Windows requirements. A game whose graphics line names no card we can read ("TBD", say) has a page that is not indexed: it answers nobody yet.

We don't rank graphics cards or processors: no open ranking may be republished, and a ranking built from publishers' lines contradicts itself more as games are added (we measured it for cards on over 400 games). So a verdict rests on publishers' direct statements alone: a card in a game's recommended requirements is above one in its minimum. Your card is enough for a tier when the tier's line names it, or a game puts it above a card of that line and no game puts it below one. It is below when games put it below every card of the line. Each verdict names the game it rests on and the card it compared yours with. When no game says anything, games disagree, or they put it below some cards of the line and say nothing of the rest, we say we can't tell, and don't guess: a publisher's line lists alternatives, and below one of them is not below the others. A processor is judged as a card is, from the processor line.

A publisher's line is its own judgement, not a measurement. Two cards in one line are not made equal by it: each is enough for that game, and a publisher lists the weakest card it accepts from each maker, which can be years apart (Diablo IV's minimum puts the Radeon R9 280, from 2014, beside the Arc A380, from 2022, Intel's weakest Arc). So one line never tells us your card is enough; when no other game says anything, we show it and say we can't tell. Nor do we chain statements: when one game puts a card above a second and another puts the second above a third, we don't say the first is above the third. We judge the graphics card, the processor and the memory, each on its own; storage is in the publisher's lines, as written.

We read a card from a publisher's line by its maker, family and number and what makes it another card (Ti, SUPER, XT), and never read a series ("GTX 900 series"), a laptop chip or a memory size. Memory is part of a card's name for the GTX 1060 and GTX 1050 alone, each of which was sold with two chips.

We read a processor by its maker, family and number and what makes it another processor (K, X, X3D, G), and never read a family alone ("Intel Core i5"), a generation ("i5 8th gen"), a series, a speed and core count, or a laptop chip. An Intel processor ending in F is the same processor with its built-in graphics turned off, so we read the two as one.

Memory is a number against a number, so it needs no other game's word: we read the one size in the memory line ("8 GB RAM", "512 MB RAM"), and your PC's RAM is enough when it is that much or more. We don't read a line with two sizes ("2 GB for 32-bit OS or 4 GB for 64-bit OS"), since it doesn't say which is for a PC of today.

Monitors: where their figures come from, and which get a page

A monitor's specs (size, resolution, top refresh rate and panel type, and its brightness, contrast, ports, stand and weight) come from its sheet in Open Icecat, a catalogue its makers pay for, each approving its products' sheets, and open to comparison sites. A program reads them every hour, each figure by its fixed id on the sheet, with no AI. Brightness and contrast are the "typical" figures as the maker writes them, not our measurement. Its data reaches us as is (AS IS), with no warranty from Icecat that it is right.

A monitor's power use comes from EPREL, the energy register every display sold in the EU must be filed in: a figure its maker measures to the EU standard, at the monitor's settings out of the box, in SDR, and in HDR when the monitor was measured in it. Raising the brightness or turning HDR on raises it. We don't take the "typical consumption" makers print on their sheets: it is not the label's figure, and sometimes not close (65 W for a monitor filed at 26 W in EPREL). Nor do we take EPREL's figure from old copies: records are revised, and we read the current one. A monitor's release date on its page, and the year in its table, is its first day on the EU market, as EPREL records it.

The EPREL number on an Icecat sheet is a claim we check before taking any figure from the record: its resolution must be the sheet's, its size within 2 cm of the sheet's, the record must be a monitor's and not a television's or a sign's, and it must name the same model. We found one Dell monitor's number filed for two other models, so nothing short of these four checks will do. What fails them takes no figure.

Only gaming monitors get a page: a top refresh rate of 144 Hz or more, as their makers state it. Among them, those most asked for by the shops that take their sheets from Open Icecat, since 2023, summed over every market code of the model. That is the demand of sales channels, mostly European, not our readers' searches, so a maker that does not pay for Icecat (Xiaomi and Huawei, for example) is not on the list. A monitor that has a page keeps it. A monitor's page is not indexed without its official EPREL power use.

Two figures we work out, and never print as the maker's: pixel density, the square root of the sum of the two resolutions squared, divided by the size in inches; and frame time, 1,000 divided by the top refresh rate, in milliseconds.

We don't show response time (GtG and MPRT) or input lag. A maker's figure is its own test, run a way it doesn't name, and the "response time" on its sheet mixes the two kinds: one maker's "1 ms" is GtG, another's MPRT. Makers don't publish input lag at all. The labs that measure all three don't allow their figures to be republished, so we show none of them until we find an independent measurement we may publish.

In their place we show two certifications from VESA, the display standards body, tested by a lab it authorises rather than by the maker, at the monitor's out-of-the-box settings: ClearMR, a motion clarity tier (the higher, the less blur when the picture moves, and two listed monitors compare on it); and AdaptiveSync Display, a variable refresh certification with limits on response time (GtG), overshoot and flicker. We read both lists every week and take for a monitor what matches its model code, size and resolution together; where a list disagrees with itself about a monitor, we take nothing from it. "Not listed" doesn't mean a monitor lacks one: VESA lists only what its maker approves for listing, so it never ranks one monitor above another.

Your screen

Monitor pages and their comparisons have a "Measure my screen" button. When you press it, your browser measures the screen its window is on, and never before you press: what a screen is like is, as a graphics card's name is, one of the things trackers tell devices apart by. None of it is sent to our site or kept: it is worked out in your browser and shown on the page only. What it measures is the screen as it runs now, not the most it can do, so we set it beside the maker's figures and don't compare the two.

Refresh rate: we count the frames the browser draws for one second (requestAnimationFrame) and divide their number by their time, counting a frame the browser missed while busy as two, so a busy moment never lowers the figure (we measured it: 165 on a 165 Hz screen, and 162 had we counted the gaps alone). We round it to a whole number and write "about" with it. It is the rate the browser draws at now: lower than the screen can do on battery, when the system is set lower, or in a power-saving mode. We don't measure while the page is in the background, where the browser slows it, or in a browser that doesn't time its frames finely enough.

Resolution: the screen's size as the browser gives it, times its pixel density (devicePixelRatio). It is the resolution your system runs the screen at now, so if you lowered it in the settings you see what you chose. The product isn't always a whole number (a 2560 × 1600 screen with Windows scaling at 165% gives 2560.8 × 1600.5), so we round one that isn't to the nearest even number and write "about" with it. Zooming the page in Chrome and Edge changes the density but not the size (we measured it: the same screen at 125% zoom gives 3201 × 2001), so we don't read the resolution while the page is zoomed in or out, nor while it looks so because a panel is open beside it in the browser. On a Mac set to a "scaled" resolution the system draws larger than the panel and shrinks the picture to fit, and we read the size it draws at.

HDR: we ask the browser whether the screen shows a high dynamic range right now (dynamic-range: high). That says HDR is on now, not that the screen supports it: an HDR screen with HDR turned off in the system's settings says no.

Local AI models: which get a page, and whether one fits your PC

We read the models from Hugging Face, where their makers publish them for download, every hour, with no AI. Only a model by its maker gets a page: Qwen, Google, Meta, Mistral AI, Microsoft, DeepSeek, OpenAI, IBM, NVIDIA, Z.ai, Liquid AI, MiniMax, Moonshot AI, Cohere, TII, QCRI, HUMAIN, SILMA, Inception. Not a copy someone else uploaded, nor a model someone retrained, since among the most downloaded copies are "uncensored" ones no maker publishes. And a model you talk to, not a base model: its file carries a chat template, and its name doesn't call it "Base".

We rank them by the downloads of all their GGUF copies (the format LM Studio and llama.cpp open) over the last 30 days, as Hugging Face counts them, summed for each model. The first 60 get a page, and so does every model of the makers who train theirs for Arabic. A model that has a page keeps it. A renamed model, or a maker's in-between checkpoint named after one of its models, gets no second page.

Each file's size is as Hugging Face lists it, in GB of a billion bytes: the maker's own copy where it holds a Q4_K_M file, otherwise the most downloaded of ggml-org, bartowski, unsloth, lmstudio-community, mradermacher that holds one, under the model's own name. We show four levels: Q4_K_M (the most downloaded), and Q5_K_M, Q6_K and Q8_0 (larger and more exact). A file split in parts is its parts added up.

Conversation memory is what a model keeps of everything said before, to remember it. We work it out from the Q4_K_M file's own header (its start only, without downloading the file), as llama.cpp (release b11936) reserves it with its default settings: a part that grows with each token, and a fixed part that doesn't, since some layers keep only the last tokens and some keep one running state instead of the whole conversation. We checked the sum for each architecture against llama.cpp's own figure for real files, and it matched to the megabyte at 4,000, 8,000 and 32,000 tokens, for 18 architectures. A model whose architecture we haven't checked gets no figure, and its page says so. Where a model's window is longer than the conversation, we count the whole window, so the figure is a little larger, never smaller.

"Can your PC run it?" is a sum, not a test: the file, the conversation memory, and about 0.7 GB llama.cpp reserves to work in (the most it reserved for the twenty files we measured with the whole model on the card, up to 32,768 tokens, so we offer no longer conversation). Against it, your card's memory as its maker states it, in GB of 1,073,741,824 bytes as Windows counts them, less the 1 GB llama.cpp leaves free for your screen and programs. What doesn't fit on the card goes to your RAM, after the 4 GB Windows 11 needs for itself (the least Microsoft asks for it), which is much slower. Programs built on llama.cpp (LM Studio, for one) reserve the same; others may not.

The list of cards holds some with no page in the graphics cards section: laptop GPUs Blender has too few runs of to list (each one's memory from NVIDIA's pages comparing them; their laptop's maker sets their power), and the other memory size of a card NVIDIA sells in two, such as the RTX 3060's 8 GB (the card's page is its 12 GB model), listed with its size in its name. A browser doesn't say your card's memory size, so we don't pick one of the two for you. Each card's page lists the models whose Q4_K_M file fits on it alone, with a conversation of 8,192 tokens, by this same sum.

We show no speed: how many tokens a model writes a second is measured, not worked out, and needs a computer running nothing but the test. We tried on a laptop in daily use, and the figure changed from run to run more than is fit to publish, so there is none until we measure it properly.

The Arabic test

The Arabic score is a test we run ourselves: every model with a page is asked the same 56 questions in Arabic, and code grades its answers, with no AI. It doesn't measure what a model knows about the world, but what someone running it in Arabic needs: that it understands what is written to it, does what it is asked, says "I don't know" rather than make things up, and stays in Arabic.

• Understanding Arabic text (20 questions): a short text and a question on it, some answered only by reading a verb's gender ("كانت تحمل", she was carrying) or the dual ("مبرمجتان", two women programmers), some a small sum or a day of the week.
• Following instructions in Arabic (16 questions): a set number of lines, one word, JSON, alphabetical order, a number in words, the number alone, a sentence ending on a given word, and an answer in Arabic to a question asked in English.
• Does not invent (16 questions): half ask about products that don't exist, under names we make up (a phone, a graphics card, a programming language, a watch), and the right answer is that it doesn't know them. One that gives a figure for them counts as made up. The other half are well-known facts, so a model that declines everything gains nothing.
• And 4 longer paragraphs, not graded. In them and in every answer we count those that slip into a third script (Chinese, Hebrew, Thai...). Product names in Latin letters don't count: they are normal in Arabic tech writing.

The score is the mean of the first three parts, each its share of right answers. The names, cities and numbers in the questions are generated by code, so no model has met these exact questions before, and every model is asked the same ones, with the setting that leaves the least to chance (temperature 0). A model's file doesn't change once published, so it is asked once. This is version 1 of the questions; a new version is asked of every model anew.

We ask a model through Hugging Face's providers when one hosts it at a listed price, that is, a copy of it a provider hosts, not the Q4_K_M file you download, and the provider is named under the score. A model no one hosts at a listed price we run ourselves: its Q4_K_M file itself, through llama.cpp on a rented graphics card, with the same questions and settings, and the score says so. In our first trial, Qwen3-4B's hosted copy and its Q4_K_M file on a laptop got the same grade on every one of 26 questions (one model). A new model no one hosts has no score until we run it, and its page stays out of search engines until then. Answers that come back mostly in no Arabic at all are a provider's fault, not a grade, as happened to Fanar-1-9B: we don't grade them, and ask again a month later, through another provider where there is one. Each answer may take up to 8,192 tokens, the model's thinking before it answers included. An answer that reaches the limit before it starts comes back empty and counts as wrong, and a model whose answers mostly come back empty gets no score: it would measure our limit, not its Arabic.

The code reads numbers in Arabic and Western digits and in words, and names without diacritics and whatever the hamza. We set the grading rules on 260 real answers from nine models, and checked every grade ourselves before relying on it.

The verdict

Every comparison an editor has picked has a short verdict in Arabic and English, with the name of the editor who approved it.

Some verdicts are drafted by AI (Gemini). It sees only that page's comparison table (each row's name, the two values, and which one the row's rule favours) and is told to write from that alone. A program then checks that every number in the draft is in the table, and a draft with any other number cannot be approved. The editor reads the draft, edits it and approves it, and the page says so under the verdict: "Drafted by AI from the figures on this page and reviewed by", then the editor's name.

The program checks numbers, not claims. A sentence without a number can be wrong too, which is why a person reads every verdict before it is published.

Changes and corrections

Every change to a published page's numbers or verdict is listed in its change log, with its date: a value added, updated or corrected, or a verdict revised. When the old figure was wrong, the entry says "Corrected", not "Updated".

Found a number that doesn't match its source? Tell us through the contact page, with a link to the page and to the source.