4 ms·

Interesting snippet from article to test if http response code is between 200 and 299 "http_status / 100 != 2". Never seen that before..

nknight 15y ago
Scary snippet, really. Besides requiring you to stop and think about its implications, division is historically slow. On the various x86 CPUs of the past ~20 years, it's taken anywhere from 15 to 80 cycles. Compares are reliably cheap (1-2 cycles), jumps are usually similar. If the code is structured right, the simple two comparison mechanism is no worse than the division, and at best may be an order of magnitude faster. A sufficiently smart JIT might end up deconstructing that division into the double-compare, but at that point, again, you're no better off. So, Mr. Bray is setting an example that's probably slower, and definitely less intuitive, for no apparent gain.
- mcav 15y ago
  At the point where you're making an HTTP request, that's nothing. As nothing as nothing can get.
  - nknight 15y ago
    Range checks aren't limited to HTTP requests, they're a highly generic construct. Novices will pick up this bad habit and use it elsewhere, including in tight loops, not understanding that it's a serious mistake.
chadaustin 15y ago
Compares and jumps are cheap only if the branch is predicted. If not predicted, they're worse than a division. In data-driven conditionals, a conditional move operations is likely the best.
- chadaustin 15y ago
  Sorry, meant to respond to nknight.
- zokier 15y ago
  There is still a compare/jump with the division method ( != 0) which needs prediction.
- nknight 15y ago
  Branch predictors have for years been accurate enough that the right thing is to not worry about a pipeline flush until you actually encounter a high miss rate. By the way, on the latest CPUs, they're not just "cheap" -- cmp is actually as low as 0.5 cycles, and a predicted jcc is effectively 0. The comparison is actually between something that, in the absolute best case, is 5.5 cycles, vs. something that, in the general case, is 0.5 cycles.

nknight 15y ago

Scary snippet, really. Besides requiring you to stop and think about its implications, division is historically slow. On the various x86 CPUs of the past ~20 years, it's taken anywhere from 15 to 80 cycles. Compares are reliably cheap (1-2 cycles), jumps are usually similar. If the code is structured right, the simple two comparison mechanism is no worse than the division, and at best may be an order of magnitude faster. A sufficiently smart JIT might end up deconstructing that division into the double-compare, but at that point, again, you're no better off. So, Mr. Bray is setting an example that's probably slower, and definitely less intuitive, for no apparent gain.

mcav 15y ago
At the point where you're making an HTTP request, that's nothing. As nothing as nothing can get.
- nknight 15y ago
  Range checks aren't limited to HTTP requests, they're a highly generic construct. Novices will pick up this bad habit and use it elsewhere, including in tight loops, not understanding that it's a serious mistake.

chadaustin 15y ago

Compares and jumps are cheap only if the branch is predicted. If not predicted, they're worse than a division. In data-driven conditionals, a conditional move operations is likely the best.

chadaustin 15y ago
Sorry, meant to respond to nknight.
zokier 15y ago
There is still a compare/jump with the division method ( != 0) which needs prediction.
nknight 15y ago
Branch predictors have for years been accurate enough that the right thing is to not worry about a pipeline flush until you actually encounter a high miss rate. By the way, on the latest CPUs, they're not just "cheap" -- cmp is actually as low as 0.5 cycles, and a predicted jcc is effectively 0. The comparison is actually between something that, in the absolute best case, is 5.5 cycles, vs. something that, in the general case, is 0.5 cycles.