4 ms·

You look at the assembly code, grab an Intel Programmer Reference manual (they were about 1000 pages), look up each instruction opcode and that would tell you t

You look at the assembly code, grab an Intel Programmer Reference manual (they were about 1000 pages), look up each instruction opcode and that would tell you the clock cycles. For memory operations it is much more difficult due to caching. However, for many hot regions of code, the data is already in the L1s so manual counting is sufficient. (At the time there was a book called The Black Art of ... Assembly? I can't recall, and I should be flogged for forgetting it... but it was directed at game programmers and covered all sorts of assembly tricks for Intel CPUs.) Also, a little later in the 90's: VTune. When VTune dropped it was a game changer. Intel started adding performance counters to the CPUs that could be queried in real-time so you could literally see what code was missing branches or stalling, etc. Source: I worked with Blizzard (pre-WoW!) developing VTune, feeding back requirements for new performance counter requests from them and developers.

nitrogen 5y ago
(At the time there was a book called The Black Art of ... Assembly? I can't recall, and I should be flogged for forgetting it... Probably not the book you're thinking of, but Michael Abrash's Graphics Programming Black Book was a mix of reprinted old articles and new content that had a bunch of highly optimized (for 486) graphics routines. IIRC there was a 9-cycle-per-texel texture mapping routine.
radicalbyte 5y ago
It was common back in the day for machines to ship with detailed technical documentation. I spent many an hour as a young child reading the C64 programmers reference guide, calculating the op speed and drawing memory maps. https://archive.org/details/c64-programmer-ref https://archive.org/details/c64-programmer-ref
- SavantIdiot 5y ago
  What were you drawing memory maps for?
  - radicalbyte 5y ago
    Mainly making cheats for games. Back then you have devices which allowed you to view memory, so I would play games and look for changes made in memory when you did certain actions. Made a map of them. Most of the time a life counter was good enough. Also for my own games - you don't have pointers as such, you have your memory, and you need to know what lives where (and when it lives where).
kqr 5y ago
> You look at the assembly code, grab an Intel Programmer Reference manual (they were about 1000 pages), look up each instruction opcode and that would tell you the clock cycles. Wouldn't this "just" tell you how many "cycles of code" there are, and not how many cycles actually run? Branches etc. will of course cause some cycles to be double-counted and others to be skipped, in the dynamic view.
- pepoluan 5y ago
  Then you just calculate them all. If Branch A is taken ... total X clock-cycles. If Branch B is taken ... total X clock-cycles. If Branch C is taken ... total X clock-cycles. And so on. And then make sure that the "longest" branch fits into the clock-cycle budget.
  - kqr 5y ago
    Were games at this point of low enough complexity that the combinatorial explosion of branches could be contained and reasoned about by humans? Or did you have software doing this?
    - Jensson 5y ago
      There is no such thing as combinatorial explosion here, just take the longest branch every time.
      - kqr 5y ago
        But this means if you have a situation like if (a) { ... } ... if (b) { ... } Where the branches are long, and b = !a, you significantly overestimate the amount of code. I guess that was considered good enough, then?
        mjul 5y ago
        You just need your code to finish before the next frame. Then you wait and start the next cycle when you receive the interrupt from the start of the next frame from your graphics hardware. Of course once you start writing for heterogeneous hardware like PCs with very different performance between models, you may use adaptive approaches to use all the available resources rather than just providing the most basic experience for everyone.
lapsis_beeftech 5y ago
You might be thinking of "Zen of Assembly Language" or "Zen of Code Optimization" by the brilliant Michael Abrash. I own the latter and in addition to plenty of low-level code optimization advice for the microprocessors available at the time it also includes timer code for DOS that lets you measure code performance with high precision.
- SavantIdiot 5y ago
  Yep! Thanks! I was also thinking of his "Graphics Programming Black Book". Black Art ... hah! My bad memory. That dude abused the hell out of int 13! Kinda surprised he's with Oculus under Facebook. I wish his brain wasn't owned by Zuck. Maybe he's in that phase that musicians hit, when they get old and gray and start performing their classics at Vegas for a million bucks a night to audiences of boomers.

nitrogen 5y ago

(At the time there was a book called The Black Art of ... Assembly? I can't recall, and I should be flogged for forgetting it... Probably not the book you're thinking of, but Michael Abrash's Graphics Programming Black Book was a mix of reprinted old articles and new content that had a bunch of highly optimized (for 486) graphics routines. IIRC there was a 9-cycle-per-texel texture mapping routine.

radicalbyte 5y ago

It was common back in the day for machines to ship with detailed technical documentation. I spent many an hour as a young child reading the C64 programmers reference guide, calculating the op speed and drawing memory maps. https://archive.org/details/c64-programmer-ref https://archive.org/details/c64-programmer-ref

SavantIdiot 5y ago
What were you drawing memory maps for?
- radicalbyte 5y ago
  Mainly making cheats for games. Back then you have devices which allowed you to view memory, so I would play games and look for changes made in memory when you did certain actions. Made a map of them. Most of the time a life counter was good enough. Also for my own games - you don't have pointers as such, you have your memory, and you need to know what lives where (and when it lives where).

kqr 5y ago

> You look at the assembly code, grab an Intel Programmer Reference manual (they were about 1000 pages), look up each instruction opcode and that would tell you the clock cycles. Wouldn't this "just" tell you how many "cycles of code" there are, and not how many cycles actually run? Branches etc. will of course cause some cycles to be double-counted and others to be skipped, in the dynamic view.

pepoluan 5y ago
Then you just calculate them all. If Branch A is taken ... total X clock-cycles. If Branch B is taken ... total X clock-cycles. If Branch C is taken ... total X clock-cycles. And so on. And then make sure that the "longest" branch fits into the clock-cycle budget.
- kqr 5y ago
  Were games at this point of low enough complexity that the combinatorial explosion of branches could be contained and reasoned about by humans? Or did you have software doing this?
  - Jensson 5y ago
    There is no such thing as combinatorial explosion here, just take the longest branch every time.
    - kqr 5y ago
      But this means if you have a situation like if (a) { ... } ... if (b) { ... } Where the branches are long, and b = !a, you significantly overestimate the amount of code. I guess that was considered good enough, then?
      - mjul 5y ago
        You just need your code to finish before the next frame. Then you wait and start the next cycle when you receive the interrupt from the start of the next frame from your graphics hardware. Of course once you start writing for heterogeneous hardware like PCs with very different performance between models, you may use adaptive approaches to use all the available resources rather than just providing the most basic experience for everyone.

lapsis_beeftech 5y ago

You might be thinking of "Zen of Assembly Language" or "Zen of Code Optimization" by the brilliant Michael Abrash. I own the latter and in addition to plenty of low-level code optimization advice for the microprocessors available at the time it also includes timer code for DOS that lets you measure code performance with high precision.

SavantIdiot 5y ago
Yep! Thanks! I was also thinking of his "Graphics Programming Black Book". Black Art ... hah! My bad memory. That dude abused the hell out of int 13! Kinda surprised he's with Oculus under Facebook. I wish his brain wasn't owned by Zuck. Maybe he's in that phase that musicians hit, when they get old and gray and start performing their classics at Vegas for a million bucks a night to audiences of boomers.