I would assume that 1 branch (the first option) is always faster than
2 branches (the second option). The branch prediction in the CPU
should figure out with execution path is most likely.
That is not a correct assumption, even if the branch prediction table of
the CPU was long enough to remember
I will be out of the office on vacation starting from 6:30am CDT on Friday,
April 19th. I will not have access to email throughout this time. I will
return on Monday, April 29th at 6:30am.
19 avril 2013 14:39
À : ASSEMBLER-LIST@LISTSERV.UGA.EDU
Objet : Re: Good Performing Code (Was: Millicode Instructions)
I would assume that 1 branch (the first option) is always faster than
2 branches (the second option). The branch prediction in the CPU
should figure out with execution path is most
I understand also that unconditional branches are faster than conditional
branches. So, which is faster:
BNZ LABEL Branch most frequent
or:
BZ*+8fall through most frequent
B LABEL Unconditional
It might seem naïve but I would assume that 1 branch
John Ehrman wrote:
Performance concerns about individual instructions aren't worth much
effort. Things like operand alignment, data and instruction cache
retention, locality of reference, branch frequency etc. can have really
significant effects.
For sure. But for the pathologically curious, if
The two newest processors (z196 and zEC12) do out-of-order processing. Does
that mean that we do not need to 'intermingle' instructions because the
processor will do it for us?
Fred!
Sent from my new iPad
On Apr 18, 2013, at 17:05, Phil Smith III li...@akphs.com wrote:
John Ehrman wrote:
On 17 April 2013 07:34, Ed Jaffe edja...@phoenixsoftware.com wrote:
On 4/16/2013 3:55 PM, Scott Ford wrote:
I want to ask a question, in this day/age and processing power is it
really worth
being concerned about Assembler instructions speed ?
I am not unbiased. My answer is exactly what
Long ago G. H. Hardy, one of the great figures of 20th-century
mathematics, set out what he took to be the three most important
characteristics of successful contributors to any technical field.
They are
1) intellectual curiosity, the itch to know how things work,
2) craftsmanship, a commitment
when, why, and
what to multiply.
Bill Fairchild
Franklin, TN
- Original Message -
From: Rob van der Heij rvdh...@gmail.com
To: ASSEMBLER-LIST@LISTSERV.UGA.EDU
Sent: Wednesday, April 17, 2013 3:12:09 AM
Subject: Re: Good Performing Code (Was: Millicode Instructions)
On 17 April
On 17 April 2013 15:14, DASDBILL2 dasdbi...@comcast.net wrote:
Your elapsed times in g oing from 100,000 records to 107 million looks
like linear scaling. That's the best one can hope for. Working fine
means running in less than two minutes. It did work for 107 million
records. But it
On 4/17/2013 9:14 AM, DASDBILL2 wrote:
I learned how to multiply in the third grade. Sixty years later I
still remember how to multiply. It's also important to know when,
why, and what to multiply.
Simple - you write the two numbers with the larger on the left. In the
next row, double the
AM
Subject: Re: Good Performing Code (Was: Millicode Instructions)
On 4/17/2013 9:14 AM, DASDBILL2 wrote:
I learned how to multiply in the third grade. Sixty years later I
still remember how to multiply. It's also important to know when,
why, and what to multiply.
Simple
I am currently out of the office and unreachable until Thursday.
If you have a P1, Production Down issue with PowerExchange or UDR products
please make a voice call to Informatica Support and open an SR.
Thanks,
Joey
On 2013-04-17, at 09:31, DASDBILL2 wrote:
I tried your algorithm with 13 multiplied by 81 and produced the correct
answer. This algorithm is undoubtedly how the microcode for the M (multiply
fullword) instruction does its math.
It has a lot to do with where the 1-bits are in the binary
Hey Gil,
I assume that type of math with bits is super fast ...I has a friend show my
similar techniques using SRL or SLL, but my old age ...I forgot . Will have to
revisit
Scott ford
www.identityforge.com
from my IPAD
'Infinite wisdom through infinite means'
On Apr 17, 2013, at 1:03 PM,
On 2013-04-17, at 11:26, Scott Ford wrote:
I assume that type of math with bits is super fast ...I has a friend show my
similar techniques using SRL or SLL, but my old age ...I forgot . Will have
to revisit
I expect it's hardwired in the Multiply instruction. Or, you could
do it with a
Performance concerns about individual instructions aren't worth much
effort. Things like operand alignment, data and instruction cache
retention, locality of reference, branch frequency etc. can have really
significant effects.
Remember that CPU speeds have increased much faster than memory
John,
For example, what are Assembler no nos in performance ...I am trying to put you
'on the spot' ,
I am curious and responsible person, so I would like to know
Best Regards,
Scott ford
www.identityforge.com
from my IPAD
'Infinite wisdom through infinite means'
On Apr 17, 2013, at 2:08
Trying not to put you on the spot sorry...
Scott ford
www.identityforge.com
from my IPAD
'Infinite wisdom through infinite means'
On Apr 17, 2013, at 3:35 PM, Scott Ford scott_j_f...@yahoo.com wrote:
John,
For example, what are Assembler no nos in performance ...I am trying to put
you
On 4/17/2013 12:35 PM, Scott Ford wrote:
For example, what are Assembler no nos in performance ...I am trying to put you
'on the spot' ,
I am curious and responsible person, so I would like to know
One example would be having a data area with various fields that are
frequently updated by
Scott Ford asked:
what are Assembler no nos in performance ...
Here are some examples (from my session 12522 talk at SHARE in San
Francisco):
1. Memory speed is very slow compared to CPU speed -- for example, use
immediate operands wherever possible
2. Operand alignment can be very important
On 2013-04-17, at 14:59, John Ehrman wrote:
6. Arrange branches so the fall through path is most frequent
I understand also that unconditional branches are faster than
conditional branches. So, which is faster:
BNZ LABEL Branch most frequent
or:
BZ*+8fall through
, 2013 6:19 PM
To: ASSEMBLER-LIST@LISTSERV.UGA.EDU
Subject: Re: Good Performing Code (Was: Millicode Instructions)
On 2013-04-17, at 14:59, John Ehrman wrote:
6. Arrange branches so the fall through path is most frequent
I understand also that unconditional branches are faster than conditional
On 4/16/2013 3:55 PM, Scott Ford wrote:
I want to ask a question, in this day/age and processing power is it really
worth
being concerned about Assembler instructions speed ?
I am not unbiased. My answer is exactly what one would expect from the
CTO of a software company that has been
24 matches
Mail list logo
