Yes I know that's not latency per se but in the end it is too.
EDIT: I agree with Morg. If coding right also results in faster code there is no reason not to do that.
Some approaches are NOT acceptable, it's not about optimizing prematurely, it's about coding obvious crap.
While you may be used to the usual "code crap, fix later" and "waste cycles, there are too many of it" , it doesn't mean you're right.
Everyone says it but you're still running on C (linux, unix), you're still going nuts over scaling issues (lol nosql for everyone) and you're still paying your amazon cloud bill.
I have several sites running on a single smallest Linode, and the CPU utilization virtually never cracks 1%.
Also, note that I am not advocating "coding crap". I'm talking about not berating coworkers over the nanosecond cost of an extra modulo inside a loop.
The others I will be pleased not to work with.
And the anti-optimization argument would be correct if: -typing represented more than 1% of dev work -code was never reused -code was never massively used -code had a short lifespan
So let me help you see clearly: -I'm not a typist -Every bad code tutorial out there creates millions of code bits that contain the N times slower version, with an aggregate impact that actually matters -Any 10% opt mistake in a codebase like iptables would cause more carbon than you can imagine -Fortran is still in use because it's the fastest language there is with the best math libraries.
Those seem to be eternal so far, and C seems to remain the only other relevant language throughout the short history of coding.
Sure, there are much more problematic cases than the dumb even odd example, but I picked that one because many would recognize it.
If your code is expressive, easy to reason about and fast enough, then less expressive, harder to reason about and even faster code isn't more correct.
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 ?
for(t = 0; t < T; t++)
for(i = 0; i < NN; i++)
A[i%N] = 0;
_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;
}
}
}
And per se should NEVER be spelled "per say".
Alt rows are a simple concept, the first row is odd, the next is even, etc.
A good step forward is an if/then/else or a switch or an unrolled loop - a huge step forward in terms of performance too, as a mod takes 63 cycles and a cmp takes almost nothing.
an example could be
rowClass='even'; loop if(rowClass=='odd'){ rowClass='even'; }else{ rowClass='odd'; } endloop
Unroll your loop once they are tried, tested, and working correctly, and a profiler finds out you spend much too time in the specific parts that would be discarded when unrolling.
The liberties you took with your pseudocode above prove the point: as others have noted, you've chosen premature optimization over using a fitting data type. The first could be easily fixed before release. The latter is harder.
And it would still be faster than a mod, too, even though one byte might be better for registry usage, it won't affect cycles that much iirc.
>>> import timeit
>>> timeit.Timer(stmt="z=101%2").timeit()
0.033080740708665485
>>> timeit.Timer(stmt="z='even'=='odd'").timeit()
0.05949918215862482 > profile = function(fn) { var start = Date.now(); fn(); return Date.now() - start; }
> cmp = function() { for (var i=0; i < 1000000000; i++) { var z = 'odd' === 'even'; } }
> mod = function() { for (var i=0; i < 1000000000; i++) { var z = 101 % 2; } }
> prof(cmp)
20329
> prof(mod)
40792
is_even = !is_even should be a lot cheaper than string comparison or modulus, assuming a reasonable language.
My idea with that is that it's extremely important to reach that conclusion, as it matches the problem perfectly and thus is much more efficient than our (often natural) standard approach of mod(x,2).
When you've reached that step, you can further improve by using a boolean instead of a short string, but that steps clearly into optimization, as it's not "formulating the problem correctly" but "finding a better way to implement the same solution".
There is major cost in not formulating the problem correctly (even odd is an approach to alternating colors, not the problem itself), and mod for table rows is a prime example of that.
And yet we miss the simple, efficient answer?
isEven = 1
rowClasses[] = { 'odd', 'even' }
loop
isEven = 1 - isEven
rowClass = rowClasses[isEven]
endloop
In essence your solution and the strcmp one follow the same logic, except yours is limited to two states as it is - but indeed the best n-state solution uses an array too.
What you posted here is a somewhat optimized implementation of the right solution, which is slightly better, like the boolean one (indeed you're using one bit that you flip ...).
But the BIG difference between the mod family of solutions and ours is that mod is over ten times slower because it does not correctly use the problem data.
I'm not the best coder there is, but I know it is much simpler to base yourself on something you already know (the state of the previous row) rather than doing additional computing because an analytical approach says alternating two colors is like having a color for even rows and one for odds.
By the way. your code is evil, if you're going to implement two-state logic, you're expected to use a boolean, and it will run faster with an if(b){str1}else{str2} than with an array that costs additional processing because of its nature (I'm talking straight out of my ass btw, but I still know it's inevitable that an array of two strings requires more bits and ops than two strings).
Also, the point of using an array for such an exercise would be to support n-state logic, yet your fake-boolean int approach makes it doubtful ;)
I'm not aware of any compiler that optimises such a structure to avoid branch misprediction. An array of two strings might require more bits and ops in an unoptimised interpreted language, or one in which bounds checking is always enabled, but I can assure you that an indexed load is 1 instruction and a load for each string is... well, more than that. You are right, you are definitely talking straight out of your ass!
The n-state solution is a state machine, btw - but it is right to use a simple solution if that is all your problem requires.
Do you work on real-time systems, embedded code, or something similar?
You don't know WHY people started saying that, WHEN they started and WHO started.
It was started by old people a while ago who told even older people that for the simple stuff they were writing for DESKTOP computers, it didn't matter anymore.
Indeed, if you have a 486dx4 and all you want to do is word processing, it didn't matter much wether it was optimized or microsoft word as the thing was way too powerful for that kind of stuff already.
Today, battery life is a concern, virtualization is a reality, scalability is a CORE issue, there are low power states etc.
Today, making your application 100 times more efficient gives you 10x more battery life,100x lower cloud hosting costs, 100x better scalability, etc.
Think that's unlikely ? You've been stacking inefficient blocks for a lifetime, sometimes with inefficiencies multiplying, where do you think you are today ?
Simple example, from a pgsql>jdbc>jboss>j2ee>hibernate>java report factory to a dumb php script that did simple SQL, you already have factors above 20 in favor of the simple solution.
That's before you make a better data model or even try using a fast language or a more suiting data store depending on your needs.
Besides, your argument is nonsense, the simplest most correct way IS the most efficient, that's the power of programming, there is absolutely NO compromise between reliability and efficiency in terms of code.
Readability is over rated, as long as you don't code crap, any COMPETENT coder will be able to read and understand fast enough, even without comments.
Do you work on overweight UIs that drain phone batteries or cloud-hosted applications or anything that needs scaling ?