Slightly OT: speed of operation on a PC

On 8/4/2015 5:00 PM, glen herrmannsfeldt wrote:
>> Not content to live with this "obvious" implementation, I
>> realized that some of the "logic functions" coincided with
>> some of the "segment decoders" in common BCD->7segment display
>> decoders.  So, by twiddling the "BCD" inputs to the decoder,
>> I could get the logic function of the "junk logic" *and* the
>> bus driving capability of the NAND drivers -- all in one package!
>
> The 7447 has nice high current 15 volt OC drivers.
> Usual OC gates have 5V transistors.

The HV output wasn't required.  The silliness was the effort
to save a package of *gates* (or an AOI, etc.) -- at the expense
of puzzling anyone who had to look at the circuit thereafter
(Can you rattle off the decoding functions of any particular
7seg decoder, "off the top of your head"?  e.g., does 6 have a
tail?  9?  how are the non-decimal codes handled?  etc.  By
contrast, some *gates* wired together would be incredibly
obvious to damn near anyone looking at the schematic!)

Don Y <this@is.not.me.com> wrote:

(snip, I wrote)
>> The 7447 has nice high current 15 volt OC drivers.
>> Usual OC gates have 5V transistors.
 
> The HV output wasn't required.  The silliness was the effort
> to save a package of *gates* (or an AOI, etc.) -- at the expense
> of puzzling anyone who had to look at the circuit thereafter
> (Can you rattle off the decoding functions of any particular
> 7seg decoder, "off the top of your head"?  e.g., does 6 have a
> tail?  9?  

This one I still remember from years ago. The 7447 does not have
tails, the 74247 does.

> how are the non-decimal codes handled?  etc.  By
> contrast, some *gates* wired together would be incredibly
> obvious to damn near anyone looking at the schematic!)

-- glen

On 04/08/15 19:59, Tim Wescott wrote:
> Which do you think is quicker on a PC, with the latest gnu compiler:
> 
> double a = something;
> double b = something else;
> 
> if (a >= 0.0 && b < 0.0)
> 
>>> or <<
> 
> if (a * b <= 0)
> 
> Thank you for your time.
> 

If you are looking at the general principle, rather than this particular
example (since the two versions don't do the same thing), then the
answer is ... it depends :-)

These sorts of things often depend on the code before and after the
tests, the number of tests, the hardware, the compiler, and the
optimisation flags.  Testing the sign of a floating point number is just
a single bit test - in theory, the compiler could do this by loading a
and b (or the appropriate byte from them) into integer registers,
xor'ing it, then doing a test for that single bit (assuming normal
floating point, rather than NaNs, etc.).

Code before or after this section may affect the speed - perhaps the
compiler already knows something about a and b, or can make use of parts
of the calculation at a later state.  Perhaps /you/ know something, such
as that it is likely for a to be non-negative - and by telling the
compiler about it in the conditional, you'll get the likeliest path
executed fastest.

Some processors are good at handling conditional jumps (or conditional
instructions) smoothly, and have no problem with a series of tests.
Others are better with a single multiply and a single jump.

Different compilers may handle the ordering differently.  One thing to
be sure of is to use good optimisation (typically -Os or -O2), make sure
you target the actual hardware (-march=native, if that's not the
default), and use "-ffast-math" to tell gcc not to be painfully pedantic
about IEEE rules for re-arranging and optimising floating point.

On 05/08/15 09:54, Tim Wescott wrote:
> On Tue, 04 Aug 2015 17:05:03 -0400, rickman wrote:
>> On 8/4/2015 2:27 PM, Tim Wescott wrote:
>>> On Tue, 04 Aug 2015 20:06:35 +0200, Lanarcam wrote:
>>>> Le 04/08/2015 19:59, Tim Wescott a écrit :
>>>>> Which do you think is quicker on a PC, with the latest gnu compiler:
>>>>> double a = something;
>>>>> double b = something else;
>>>>> if (a >= 0.0 && b < 0.0)
>>>>>>> or <<
>>>>> if (a * b <= 0)
>>>>>>>>>> Thank you for your time.
> I suppose that a good optimizing compiler that understands floating point
> sign bits would figure this out quickly.


I would not have been a bit surprised if gcc did in fact figure this 
out, but it appears it does not. In any case, on a *86 machine, the time 
is entirely dominated by the time takes to load the two cache lines. 
Whether logical operations on the sign bits, or arithmetic comparisons, 
or the floating point multiplier is used to compute the result, all 
three will spend most of their time waiting for memory loads.

Try compiling the following file using "gcc -O6 -S foo.c":

int foo(double a, double b)
{
         return (a<0) != (b<0);
}

int bar(double a, double b)
{
         return a*b < 0;
}

and then read foo.s. You'll see that the second case uses a multiply.
Using my gcc 4.8.4 anyhow... and also with the Apple LLVM-based "gcc".

Clifford Heath.

On 05/08/15 04:28, Tim Wescott wrote:
> On Tue, 04 Aug 2015 11:07:49 -0700, Don Y wrote:
>
>> On 8/4/2015 10:59 AM, Tim Wescott wrote:
>>> Which do you think is quicker on a PC, with the latest gnu compiler:
>>>
>>> double a = something;
>>> double b = something else;
>>>
>>> if (a >= 0.0 && b < 0.0)
>>>
>>>>> or <<
>>>
>>> if (a * b <= 0)
>>>
>>> Thank you for your time.
>>
>> Do you really need to micro-optimize like this?
>
> Uh -- fun?
>
>> Why not just have the code *say* what you are trying to *do*?
>
> Where's the job security in that?

The first thing we do when we find someone has that attitude is to 
revert their clever codez, and the second one is to fire them. So in 
this case, your "job security" has a negative value.

On 8/4/2015 10:43 PM, glen herrmannsfeldt wrote:
> Don Y <this@is.not.me.com> wrote:
>
> (snip, I wrote)
>>> The 7447 has nice high current 15 volt OC drivers.
>>> Usual OC gates have 5V transistors.
>
>> The HV output wasn't required.  The silliness was the effort
>> to save a package of *gates* (or an AOI, etc.) -- at the expense
>> of puzzling anyone who had to look at the circuit thereafter
>> (Can you rattle off the decoding functions of any particular
>> 7seg decoder, "off the top of your head"?  e.g., does 6 have a
>> tail?  9?
>
> This one I still remember from years ago. The 7447 does not have
> tails, the 74247 does.

Your memory is far better than mine!  That was the *one* instance where I used
a TTL 7segment decoder in my career.  The only other times were CMOS devices
(e.g., 14543, 4511, etc.) driving non-muxed LCD or PGD displays.

Any other "display interfaces" had the decoding done in software lookup
tables (i.e., direct control of each segment so you could make "special
characters")

Clifford Heath <no.spam@please.net> wrote:
> Try compiling the following file using "gcc -O6 -S foo.c":

Just as a sidenote, GCC's optimization levels top out at -O3. The 
generated code will also depend on the used -march, -mtune, -mfpmath 
and other options.

-a

On 05/08/15 17:44, Don Y wrote:
> On 8/4/2015 10:43 PM, glen herrmannsfeldt wrote:
>> Don Y <this@is.not.me.com> wrote:
>>
>> (snip, I wrote)
>>>> The 7447 has nice high current 15 volt OC drivers.
>>>> Usual OC gates have 5V transistors.
>>
>>> The HV output wasn't required.  The silliness was the effort
>>> to save a package of *gates* (or an AOI, etc.) -- at the expense
>>> of puzzling anyone who had to look at the circuit thereafter
>>> (Can you rattle off the decoding functions of any particular
>>> 7seg decoder, "off the top of your head"?  e.g., does 6 have a
>>> tail?  9?
>>
>> This one I still remember from years ago. The 7447 does not have
>> tails, the 74247 does.
>
> Your memory is far better than mine!  That was the *one* instance where
> I used a TTL 7segment decoder in my career.

The 7447 was the first IC I ever bought, with a single digit display.
It absorbed my pocket money saved for a month, so you can imagine my
dismay when I found I'd bought a common-cathode display that wouldn't
work with the 7447 - and the supplier wouldn't take either of them back.
That was after fretting for a while about how to get 5V, when batteries 
only came in 1.5v increments. I really needed a mentor or a book.

I never did end up building the digital dice (die?) circuit I had 
designed, but I did design and build a lot of other stuff.

On 2015-08-04, Tom Gardner <spamjunk@blueyonder.co.uk> wrote:
> On 04/08/15 18:59, Tim Wescott wrote:
>> Which do you think is quicker on a PC, with the latest gnu compiler:
>>
>> double a = something;
>> double b = something else;
>>
>> if (a >= 0.0 && b < 0.0)
>>
>>>> or <<
>>
>> if (a * b <= 0)
>>
>> Thank you for your time.
>
> With many of these questions, the answer may depend on the
> surrounding context and the compiler optimisation level,
> and what is/isn't in the cache.
>
> And may change with the next compiler release. Or with
> a "trivial" change to the context.
>

You have no idea just how true that is. :-( :-(

Still annoyed about this one because it's just happened to me (last
night) and I sunk quite some time into it because I wrongly thought
initially I had done something stupid to my code while changing it.

MIPS gcc cross-compiler, targeting a M4K core, -Os in effect.

Made a change to a routine (called from lots of places) which _reduced_
the amount of code in the routine. End result: final binary _grew_ from
3520 bytes to 4844 bytes and hence smashed through the 4K SRAM limit
available for the code to execute in.

Even though -Os was in use, it appears gcc decided to inline my new
smaller routine; I guess the final binary size wasn't considered by gcc
for some reason.

-fno-inline fixed the problem. (As did -O1 :-))

This was with the MIPS sourced version of the compiler which is quite
old by now (gcc 4.4.6 IIRC) so I don't know if it's a problem on current
gcc versions.

The message for Tim is that you need to see the generated code in the
final binary at the optimisation level you are _actually_ using before
you can decide which one is best. (And don't assume higher optimisation
level equals "better". :-))

Simon.

-- 
Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP
Microsoft: Bringing you 1980s technology to a 21st century world

On 05/08/15 11:25, Simon Clubley wrote:
> On 2015-08-04, Tom Gardner <spamjunk@blueyonder.co.uk> wrote:
>> On 04/08/15 18:59, Tim Wescott wrote:
>>> Which do you think is quicker on a PC, with the latest gnu compiler:
>>>
>>> double a = something;
>>> double b = something else;
>>>
>>> if (a >= 0.0 && b < 0.0)
>>>
>>>>> or <<
>>>
>>> if (a * b <= 0)
>>>
>>> Thank you for your time.
>>
>> With many of these questions, the answer may depend on the
>> surrounding context and the compiler optimisation level,
>> and what is/isn't in the cache.
>>
>> And may change with the next compiler release. Or with
>> a "trivial" change to the context.
>>
>
> You have no idea just how true that is. :-( :-(
>
> Still annoyed about this one because it's just happened to me (last
> night) and I sunk quite some time into it because I wrongly thought
> initially I had done something stupid to my code while changing it.
>
> MIPS gcc cross-compiler, targeting a M4K core, -Os in effect.
>
> Made a change to a routine (called from lots of places) which _reduced_
> the amount of code in the routine. End result: final binary _grew_ from
> 3520 bytes to 4844 bytes and hence smashed through the 4K SRAM limit
> available for the code to execute in.
>
> Even though -Os was in use, it appears gcc decided to inline my new
> smaller routine; I guess the final binary size wasn't considered by gcc
> for some reason.
>
> -fno-inline fixed the problem. (As did -O1 :-))
>
> This was with the MIPS sourced version of the compiler which is quite
> old by now (gcc 4.4.6 IIRC) so I don't know if it's a problem on current
> gcc versions.
>
> The message for Tim is that you need to see the generated code in the
> final binary at the optimisation level you are _actually_ using before
> you can decide which one is best. (And don't assume higher optimisation
> level equals "better". :-))

Yes indeed.

That kind of "nonsense" is one reason why the best /general purpose/
language/environment is Java. HotSpot optimises what is /actually/
executing as opposed to what the compiler can /safely guess/ what
/might/ be executing. GP = in the absence of other constraints such
as might be found in embedded systems.

HP's Dynamo C compiler from the 1990s is a remarkable demonstration
of that kind of thing:
   - take a processor X, and emulate that processor on that processor
   - take optimised CPU-bound C (Oc) running in the emulator to discover
     what code is actually executing
   - change the binary to optimise what is actually executing (Oe)
   - measure performance of original C (Oc) running in X => Px
   - measure performance of the changed binary (Oe) running in the
     emulator of X running in processor X => Pe
   - now Px = +- Pe

So, C slows down code as much as emulating a processor!
Quite Remarkable, and one reason why Java isn't as slow as
naive oldies assume.