HN2new | past | comments | ask | show | jobs | submitlogin

I suppose you are referring to the very particular case of the right shift, but as much as that's easily predictable, it's a corner case.

Who knows maybe the trend will be 3 colors instead of two. Or maybe it'll be another instruction that's wrongly abused. Or another compiler that actually sucks, like most JS interpreters.

The idea really is to use the simplest logical approach to the problem rather than the wrong one.

In the very well known case of the alt row table, it looks to me like we're alternating odd and even, why not just code that to start with, before any optimization ?



No, this form of strength reduction can often eliminate modulo operations in a loop even when the modulus is not a constant. The example given is:

  for(t = 0; t < T; t++)
    for(i = 0; i < NN; i++)
      A[i%N] = 0;
which is optimised to this, without a modulo in sight:

  _invt = (NN-1)/N;
  for(t = 0; t <= T-1; t++) {
    for(_Mdi = 0; _Mdi <= _invt; _Mdi++) {
      _peeli = 0;
      for(i = N*_Mdi; i <= min(N*_Mdi+N-1,NN-1); i++) {
        A[_peeli] = 0;
        _peeli = _peeli + 1;
      }
    }
  } 
I find the modulo easier to read in this case, but I guess that's a question of taste. It's certainly not 'wrong' to use a modulo, and probably worth the trade off in most cases if it makes your code clearer.


Yes, sometimes the compiler can compensate bad decisions from the programmer, the jvm can collect your garbage etc. - none of these will save you from stupid data models and idiotic objects.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: