From: Peter Olcott on
On 5/27/2010 11:40 PM, Liviu wrote:
> "Pete Delgado"<Peter.Delgado(a)NoSpam.com> wrote...
>>>>
>>>> Again, removing the context of the wager, the claim that you will
>>>> have written code with specific performance characteristics, won't
>>>> work here. Anyone can view the thread to see what you have done.
>>
>> BTW: I noticed that you posted some code and at least had the decency
>> to cite the original source! rotfl... that hardly qualifies as
>> *original work*, but then at this point I suppose that I should be
>> happy that you posted anything at all!
>
> Heh... I believe the original part can be reduced to
>
> int main() {
> return 0;
> }
>
> since the rest would be discarded by any half-decent compiler/linker
> in an optimizing mood. If Peter cared to profile that at all, it would
> score sky high performance, for sure. Take that, you naysayers ;-)
>
> Liviu
>
>

http://bjoern.hoehrmann.de/utf-8/decoder/dfa/

I would guess that the above code might be about twice as fast as my
code specifically because of the overhead of a switch statement. I still
like my code better for the single reason that it is much easier to
understand. I really like the above code too. It is very well written.

I have found that maximum readability also directly leads to maximum
reliability and minimum debugging. In the case where a function can be
easily exhaustively tested, is reasonably easy to read, and probably
won't need to be modified the increase of readability over speed is not
as important. In this case speed may outweigh readability.

http://www.ocr4screen.com/UTF8.cpp

If his code is any faster at all than mine this would disprove Joe's
statement that you can't known anything at all about performance without
actual testing. Of course Joe's statement was such an over exaggeration
that it would be easy to disprove.

From: Oliver Regenfelder on
Hello,

Peter Olcott wrote:
> I have found that maximum readability also directly leads to maximum
> reliability and minimum debugging.

There is at least one bug in your code which can be spotted when reading
it and complete prevents your example from working.

And a switch with goto where a loop would suffice does not count as
readable for me.

Best regards,

Oliver
From: Peter Olcott on
On 5/28/2010 8:25 AM, Oliver Regenfelder wrote:
> Hello,
>
> Peter Olcott wrote:
>> I have found that maximum readability also directly leads to maximum
>> reliability and minimum debugging.
>
> There is at least one bug in your code which can be spotted when reading
> it and complete prevents your example from working.
>
> And a switch with goto where a loop would suffice does not count as
> readable for me.
>
> Best regards,
>
> Oliver

I only use gotos in place of break statements within switch statements
in time critical code. I never use gotos anywhere else.

If you don't use a goto in place of the break; statement then two rather
than one assembly language jumps are generated. The break causes the
code to jump to the bottom, where the loop has it jump back to the top.
Maybe optimizers are smart enough to avoid this now.
From: Peter Olcott on
On 5/28/2010 9:21 AM, Peter Olcott wrote:
> On 5/28/2010 8:25 AM, Oliver Regenfelder wrote:
>> Hello,
>>
>> Peter Olcott wrote:
>>> I have found that maximum readability also directly leads to maximum
>>> reliability and minimum debugging.
>>
>> There is at least one bug in your code which can be spotted when reading
>> it and complete prevents your example from working.
>>
>> And a switch with goto where a loop would suffice does not count as
>> readable for me.
>>
>> Best regards,
>>
>> Oliver
>
> I only use gotos in place of break statements within switch statements
> in time critical code. I never use gotos anywhere else.
>
> If you don't use a goto in place of the break; statement then two rather
> than one assembly language jumps are generated. The break causes the
> code to jump to the bottom, where the loop has it jump back to the top.
> Maybe optimizers are smart enough to avoid this now.

This very limited use of the goto does not really add to complexity at
all. The break statement that the gotos replaced is essentially a goto
that jumps to the bottom. All that I did was change the direction of
this pre-existing goto to always jump to the top rather than always jump
to the bottom.
From: Liviu on
"Peter Olcott" <NoSpam(a)OCR4Screen.com> wrote...
>
> I have found that maximum readability also directly leads to maximum
> reliability and minimum debugging. In the case where a function can be
> easily exhaustively tested, is reasonably easy to read, and probably
> won't need to be modified the increase of readability over speed is
> not as important. In this case speed may outweigh readability.
>
> http://www.ocr4screen.com/UTF8.cpp

Compared to the first revision you posted yesterday, this one at least
fixes the infinite loops. That alone is a major speedup, indeed ;-)

Now maybe if you tried to actually test it, you'd find the next obvious
error, painfully obvious to anyone even remotely fluent in C/C++.
Which is even more odd since I thought you were writing code so
perfectly designed that it needed virtually no debugging.

Liviu