Re: OT if/else or not if/else

[Christopher Schultz]

Chuck,

On 4/26/16 12:18 PM, Caldarale, Charles R wrote:
>> From: Christopher Schultz [mailto:ch...@christopherschultz.net] 
>> Subject: Re: OT if/else or not if/else
> 
>> Unless the JIT can prove that there are no side-effects, it's not
>> going to perform any speculative computations for a possible branch.
> 
> True, but due to inlining of many methods, the side effects are often 
> visible.  It's quite common for compilers to generate reads out of order when 
> it can be proven they are not impacted by any subsequent write operations.
> 
>> it's not easy to decide if either of those two methods have any
>> side-effects.
> 
> Actually, given the JVM architecture, it is quite easy - the 
> compiler (the real one, not javac) has the callee method
> implementation available when it's processing the caller. This is not
> true with most languages. If a subsequent class definition
> invalidates such a determination, the compiler deoptimizes the
> generated method, and, if needed, recompiles it.

The compiler would have to invalidate that side-effect cache every time
a new class was used for that particular shouldDoSomething method gets
called, since it could be overridden at any time, so the callee's method
cannot (always) be known in advance. This is why, below, I mentioned
private and final methods. Those are known knowns, so coin a phrase.

I've never written a compiler (JIT) and all of these things are great
optimizations if they don't become bottlenecks, but I guess it's up to
the compiler writers to decide when enough is enough. Then again, JIT
work is constantly being done, so I suppose these days, they are quite
smart. When you gotta compete with native C, the JIT had better be good ;)

>> If the method is private or final in the declared type,
>> it can be evaluated completely, but that's a somewhat rare case.
> 
> Nope (see above).
> 
>> Presumably, the if-without-else case would actually free the compiler
>> to evaluate those predicates "early", but that wouldn't be considered
>> "speculative" in my mind because those side-effects would have
>> happened anyway (since all branches will be evaluated).
> 
> Only certain reads can be issued in such instances, since any writes
> are expected to be in order (unless you're dealing with the rather
> bonkers C++ memory model). The predicate evaluation isn't speculative,
> but reads from inside the predicated area are often lifted out of the
> blocks, and it's these that are speculative.

Agreed. I was more concerned with writes. Any time you can have your CPU
doing anything other than NOPs, you should be. Speculative reads are
pretty much always a good idea.

>> The only potential problem would be with an early branch that throws an
>> exception, in which case any side-effects of a later predicate would
>> be ... surprising.
> 
> If a predicate evaluation might cause a write, it pretty much
> precludes looking at them out of order.

Exactly. This just goes back to how much work the compiler (JIT) is
willing to investigate and how complex the predicate (or branch itself)
might actually be. Because not only must the predicates be read-only,
anything you might want to execute ahead of time within the branch needs
to be read-only as well.

The smarter the compiler, the better performance you can get. Compilers
these days are strikingly smart, and can prove things that even the most
seasoned high-level-language (e.g. Java) programmer might stay away from
because it's risky, or perhaps just plain difficult to read. That's one
of the great things about languages with JITs (instead of
pre-processors) instead of traditional compilers (e.g. C): the JIT can
take nice, maintainable, good-looking code and turn it into a complete
mess of internal code that has equivalent runtime meaning, but with
better performance than a naive or straightforward implementation of the
high-level language.

I like Olaf's saw: "optimize for the maintainer, not the compiler." The
compiler is smarter than you, anyway, so you may as well write your code
so that humans can understand it. ;)

-chris

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

RE: OT if/else or not if/else

[Caldarale, Charles R]

> From: Christopher Schultz [mailto:ch...@christopherschultz.net] 
> Subject: Re: OT if/else or not if/else

> Unless the JIT can prove that there are no side-effects, it's not
> going to perform any speculative computations for a possible branch.

True, but due to inlining of many methods, the side effects are often visible.  
It's quite common for compilers to generate reads out of order when it can be 
proven they are not impacted by any subsequent write operations.

> it's not easy to decide if either of those two methods have any
> side-effects.

Actually, given the JVM architecture, it is quite easy - the compiler (the real 
one, not javac) has the callee method implementation available when it's 
processing the caller.  This is not true with most languages.  If a subsequent 
class definition invalidates such a determination, the compiler deoptimizes the 
generated method, and, if needed, recompiles it.

> If the method is private or final in the declared type,
> it can be evaluated completely, but that's a somewhat rare case.

Nope (see above).

> Presumably, the if-without-else case would actually free the compiler
> to evaluate those predicates "early", but that wouldn't be considered
> "speculative" in my mind because those side-effects would have
> happened anyway (since all branches will be evaluated).

Only certain reads can be issued in such instances, since any writes are 
expected to be in order (unless you're dealing with the rather bonkers C++ 
memory model).  The predicate evaluation isn't speculative, but reads from 
inside the predicated area are often lifted out of the blocks, and it's these 
that are speculative.

> The only potential problem would be with an early branch that throws an
> exception, in which case any side-effects of a later predicate would
> be ... surprising.

If a predicate evaluation might cause a write, it pretty much precludes looking 
at them out of order.

 - Chuck


-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Re: OT if/else or not if/else

[Christopher Schultz]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Chuck,

On 4/25/16 4:54 PM, Caldarale, Charles R wrote:
>> From: Christopher Schultz [mailto:ch...@christopherschultz.net] 
>> Subject: Re: OT if/else or not if/else
> 
>> If you use else-less-if, then there is never an opportunity for 
>> parellelization, since the program is going to assume that those 
>> predicates are (a) independent and (b) ordered in a way that the 
>> programmer intended.
> 
> Not quite true. Modern compilers and CPU cores will speculatively 
> execute code sequences in parallel that may later be abandoned when
> the results of predicate evaluation are available; this can be done
> for both the if-else-if and the else-less-if forms. Regardless, the
> if-else-if form is much preferred, in terms of providing both the
> compiler and the maintainer with more information (and is certainly
> not premature optimization, by any stretch of the imagination).

Unless the JIT can prove that there are no side-effects, it's not
going to perform any speculative computations for a possible branch.
Many structures are of the form:

if(somethingIsTrue()) {
   ...
} elseif(somethingElseIsTrue()) {
   ...
}
...

and it's not easy to decide if either of those two methods have any
side-effects. If the method is private or final in the declared type,
it can be evaluated completely, but that's a somewhat rare case.

Presumably, the if-without-else case would actually free the compiler
to evaluate those predicates "early", but that wouldn't be considered
"speculative" in my mind because those side-effects would have
happened anyway (since all branches will be evaluated). The only
potential problem would be with an early branch that throws an
exception, in which case any side-effects of a later predicate would
be ... surprising.

- -chris
-BEGIN PGP SIGNATURE-
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iEYEARECAAYFAlcfjI4ACgkQ9CaO5/Lv0PBqvwCgiap/UoI6/slICwUCQtZOYjjq
af0AoJZ8e5qy9yUy3shqblCJJ2cRL2Ls
=TTKq
-END PGP SIGNATURE-

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

RE: OT if/else or not if/else

[Caldarale, Charles R]

> From: Christopher Schultz [mailto:ch...@christopherschultz.net] 
> Subject: Re: OT if/else or not if/else

> If you use else-less-if, then there is never an opportunity for
> parellelization, since the program is going to assume that those
> predicates are (a) independent and (b) ordered in a way that the
> programmer intended.

Not quite true.  Modern compilers and CPU cores will speculatively execute code 
sequences in parallel that may later be abandoned when the results of predicate 
evaluation are available; this can be done for both the if-else-if and the 
else-less-if forms.  Regardless, the if-else-if form is much preferred, in 
terms of providing both the compiler and the maintainer with more information 
(and is certainly not premature optimization, by any stretch of the 
imagination).

 - Chuck


THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY 
MATERIAL and is thus for use only by the intended recipient. If you received 
this in error, please contact the sender and delete the e-mail and its 
attachments from all computers.


-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Re: OT if/else or not if/else

[Christopher Schultz]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Leon,

On 4/25/16 10:38 AM, Leon Rosenberg wrote:
> On Mon, Apr 25, 2016 at 4:13 PM, Christopher Schultz < 
> ch...@christopherschultz.net> wrote:
> 
> Leon,
> 
> On 4/22/16 12:24 PM, Leon Rosenberg wrote:
 Hi guys,
 
> 
> I would always choose the case with the elses.
> 
> First, I think it's more clear: if you expect that only one branch
> of the code will run, and no others, then the elses tell the reader
> that fact without any further commentary. The zero-else case might
> help you catch some logic errors (because for example you can log
> each entry into a branch) but there are of course other ways to do
> that.
> 
> Second, it's more efficient, regardless of what type of processor
> you have. Let's take an example where there are more than 3
> branches. How about something like a million branches (just to
> accentuate the point)? If one of the branches runs, the others are
> skipped. If all branches have an equal change of being chosen, then
> the CPU has to perform on average 50 predicates. If you put the
> common cases at the top, you can do even better. Let's assume the
> 80/20 rule applies, here, and you can take a guess that, on
> average, the CPU will only have to perform 10 predicates on
> average.
> 
> 
>> I don't think the example is valid (even if machines with 100.000
>> cpus and more actually exist). But I remember from days of my
>> study, which lies way way back, that languages that are optimized
>> for parallel processing would be able to tell the compiler to
>> execute all ifs in parallel. So if we stick with a number of ifs
>> which is less than the number of available cores/pipes we could
>> run it all in parallel. I don't think it is possible with if
>> else, unless it is transformed into something else.

While there may be some systems that do this kind of thing, Java isn't
one of them. Java is single-threaded unless you explicitly dispatch
work to other threads.

If you use else-less-if, then there is never an opportunity for
parellelization, since the program is going to assume that those
predicates are (a) independent and (b) ordered in a way that the
programmer intended.

If you use if-with-else then those statements are also in intentional
order and -- at someone else said elsewhere in this thread -- the
predicates may have side-effects that could be dangerous to execute
out-of-order (or just "early").

>> The other thing that made me wonder is that most people on the
>> list (or all except me) actually considered if-else-if-else more
>> readable. It not only creates a more complex structure (visually
>> and syntactically  (more letters)). But also the semantics of an
>> *else* are different as of an *if*. This is like North Carolina
>> ;-) if (man){ do_man_thing; } else { do_woman_thing(); } doesn't
>> work anymore, even it worked 20 years ago. Talking about
>> maintaining :-)

You *did* mention that the cases were all mutually exclusive. This is
precisely what if/elseif was designed for.

- -chris
-BEGIN PGP SIGNATURE-
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iEYEARECAAYFAlced1YACgkQ9CaO5/Lv0PAFXQCfYPdxnWhuAIozpjp6m0/X79B2
fTkAniMHNCkr9nRzXm/A1jNCQVDXB6Ke
=scIU
-END PGP SIGNATURE-

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Re: OT if/else or not if/else

[David kerber]

On 4/25/2016 11:44 AM, Leon Rosenberg wrote:

On Mon, Apr 25, 2016 at 5:21 PM, Dougherty, Gregory T., M.S. <
dougherty.greg...@mayo.edu> wrote:




Yes, we do, because, well, it is more informative. :-)

if (a) Š
else if (b) Š
else if (c) Š

Says you have three mutually exclusive options, and implies that a is more
likely / more important than b, than c.

Or, if ³a" is a method call, possibly that ³a² has some setup needed for
³b² and ³c².

All of this is lost with multiple if statements.


Then there¹s the everlasting wisdom of Knuth¹s comment about "premature
optimization is the root of all evil².



Exactly my point.
if (a) Š
if (b) Š
if (c) Š

shorter and therefore easier than the other one ;-) if-else-if is just a
premature optimization to the above statement ;-)


Not necessarily.  Independent IFs have different semantics from an 
if..elseif construct.  In your example, they could all be true, and 
therefore S will be executed 3 times.  In an elseif construct at most 
one will be executed.








-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Re: OT if/else or not if/else

[Dougherty, Gregory T., M.S.]

On 4/25/16, 10:44 AM, "Leon Rosenberg"  wrote:


>On Mon, Apr 25, 2016 at 5:21 PM, Dougherty, Gregory T., M.S. <
>dougherty.greg...@mayo.edu> wrote:
>
>>
>>
>> Yes, we do, because, well, it is more informative. :-)
>>
>> if (a) Š
>> else if (b) Š
>> else if (c) Š
>>
>> Says you have three mutually exclusive options, and implies that a is
>>more
>> likely / more important than b, than c.
>>
>> Or, if ³a" is a method call, possibly that ³a² has some setup needed for
>> ³b² and ³c².
>>
>> All of this is lost with multiple if statements.
>>
>>
>> Then there¹s the everlasting wisdom of Knuth¹s comment about "premature
>> optimization is the root of all evil².
>>
>
>Exactly my point.
>if (a) Š
>if (b) Š
>if (c) Š
>
>shorter and therefore easier than the other one ;-) if-else-if is just a
>premature optimization to the above statement ;-)

No, they’re different statements.

Your code says “any or all of these three options can occur.” But you’ve
told us that is not correct, only one can occur.

So while the code you provide is clean, it is not correct.

Greg


-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Re: OT if/else or not if/else

[Leon Rosenberg]

On Mon, Apr 25, 2016 at 5:21 PM, Dougherty, Gregory T., M.S. <
dougherty.greg...@mayo.edu> wrote:

>
>
> Yes, we do, because, well, it is more informative. :-)
>
> if (a) Š
> else if (b) Š
> else if (c) Š
>
> Says you have three mutually exclusive options, and implies that a is more
> likely / more important than b, than c.
>
> Or, if ³a" is a method call, possibly that ³a² has some setup needed for
> ³b² and ³c².
>
> All of this is lost with multiple if statements.
>
>
> Then there¹s the everlasting wisdom of Knuth¹s comment about "premature
> optimization is the root of all evil².
>

Exactly my point.
if (a) Š
if (b) Š
if (c) Š

shorter and therefore easier than the other one ;-) if-else-if is just a
premature optimization to the above statement ;-)

Re: OT if/else or not if/else

[tomcat]

On 25.04.2016 17:21, Dougherty, Gregory T., M.S. wrote:

On 4/25/16, 9:38 AM, "Leon Rosenberg"  wrote:



The other thing that made me wonder is that most people on the list (or
all
except me) actually considered if-else-if-else more readable. It not only
creates a more complex structure (visually and syntactically  (more
letters)). But also the semantics of an *else* are different as of an
*if*.
This is like North Carolina ;-)
if (man){ do_man_thing; } else { do_woman_thing(); } doesn't work anymore,
even it worked 20 years ago. Talking about maintaining :-)

regards
Leon


Yes, we do, because, well, it is more informative. :-)

if (a) Š
else if (b) Š
else if (c) Š

Says you have three mutually exclusive options, and implies that a is more
likely / more important than b, than c.

Or, if ³a" is a method call, possibly that ³a² has some setup needed for
³b² and ³c².


Now that would be *really* maintainer-unfriendly, to say the least. Talk about obscure 
side-effects. You do not even need a quantum CPU in that case..




All of this is lost with multiple if statements.


Then there¹s the everlasting wisdom of Knuth¹s comment about "premature
optimization is the root of all evil².

Write clean, readable, correct, code.  If nothing else, this will provide
the data for your unit tests when you start optimizing.

Once you have a working implementation, then figure out where your time¹s
being spent.  But your starting pattern should always be ³clean, readable,
correct², and if the options are mutually exclusive ³if .. else if² is
what meets that requirement.

Greg


-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org




-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Re: OT if/else or not if/else

[Dougherty, Gregory T., M.S.]

On 4/25/16, 9:38 AM, "Leon Rosenberg"  wrote:


>The other thing that made me wonder is that most people on the list (or
>all
>except me) actually considered if-else-if-else more readable. It not only
>creates a more complex structure (visually and syntactically  (more
>letters)). But also the semantics of an *else* are different as of an
>*if*.
>This is like North Carolina ;-)
>if (man){ do_man_thing; } else { do_woman_thing(); } doesn't work anymore,
>even it worked 20 years ago. Talking about maintaining :-)
>
>regards
>Leon

Yes, we do, because, well, it is more informative. :-)

if (a) Š
else if (b) Š
else if (c) Š

Says you have three mutually exclusive options, and implies that a is more
likely / more important than b, than c.

Or, if ³a" is a method call, possibly that ³a² has some setup needed for
³b² and ³c².

All of this is lost with multiple if statements.


Then there¹s the everlasting wisdom of Knuth¹s comment about "premature
optimization is the root of all evil².

Write clean, readable, correct, code.  If nothing else, this will provide
the data for your unit tests when you start optimizing.

Once you have a working implementation, then figure out where your time¹s
being spent.  But your starting pattern should always be ³clean, readable,
correct², and if the options are mutually exclusive ³if .. else if² is
what meets that requirement.

Greg


-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Re: OT if/else or not if/else

[tomcat]

On 25.04.2016 16:38, Leon Rosenberg wrote:

On Mon, Apr 25, 2016 at 4:13 PM, Christopher Schultz <
ch...@christopherschultz.net> wrote:


-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Leon,

On 4/22/16 12:24 PM, Leon Rosenberg wrote:

Hi guys,



I would always choose the case with the elses.

First, I think it's more clear: if you expect that only one branch of
the code will run, and no others, then the elses tell the reader that
fact without any further commentary. The zero-else case might help you
catch some logic errors (because for example you can log each entry
into a branch) but there are of course other ways to do that.

Second, it's more efficient, regardless of what type of processor you
have. Let's take an example where there are more than 3 branches. How
about something like a million branches (just to accentuate the
point)? If one of the branches runs, the others are skipped. If all
branches have an equal change of being chosen, then the CPU has to
perform on average 50 predicates. If you put the common cases at
the top, you can do even better. Let's assume the 80/20 rule applies,
here, and you can take a guess that, on average, the CPU will only
have to perform 10 predicates on average.



I don't think the example is valid (even if machines with 100.000 cpus and
more actually exist). But I remember from days of my study, which lies way
way back, that languages that are optimized for parallel processing would
be able to tell the compiler to execute all ifs in parallel. So if we stick
with a number of ifs which is less than the number of available cores/pipes
we could run it all in parallel. I don't think it is possible with if else,
unless it is transformed into something else.

The other thing that made me wonder is that most people on the list (or all
except me) actually considered if-else-if-else more readable. It not only
creates a more complex structure (visually and syntactically  (more
letters)). But also the semantics of an *else* are different as of an *if*.
This is like North Carolina ;-)
if (man){ do_man_thing; } else { do_woman_thing(); } doesn't work anymore,
even it worked 20 years ago. Talking about maintaining :-)



And one more thing, as we all write programs that should last for 20 years at least, is 
the advent of quantum computers.  What would be the correct (maintainer-friendly) answer 
once the mere action of testing for a condition may change it ?



-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Re: OT if/else or not if/else

[David kerber]

On 4/25/2016 10:38 AM, Leon Rosenberg wrote:

On Mon, Apr 25, 2016 at 4:13 PM, Christopher Schultz <
ch...@christopherschultz.net> wrote:


-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Leon,

On 4/22/16 12:24 PM, Leon Rosenberg wrote:

Hi guys,



I would always choose the case with the elses.

First, I think it's more clear: if you expect that only one branch of
the code will run, and no others, then the elses tell the reader that
fact without any further commentary. The zero-else case might help you
catch some logic errors (because for example you can log each entry
into a branch) but there are of course other ways to do that.

Second, it's more efficient, regardless of what type of processor you
have. Let's take an example where there are more than 3 branches. How
about something like a million branches (just to accentuate the
point)? If one of the branches runs, the others are skipped. If all
branches have an equal change of being chosen, then the CPU has to
perform on average 50 predicates. If you put the common cases at
the top, you can do even better. Let's assume the 80/20 rule applies,
here, and you can take a guess that, on average, the CPU will only
have to perform 10 predicates on average.



I don't think the example is valid (even if machines with 100.000 cpus and
more actually exist). But I remember from days of my study, which lies way
way back, that languages that are optimized for parallel processing would
be able to tell the compiler to execute all ifs in parallel. So if we stick
with a number of ifs which is less than the number of available cores/pipes
we could run it all in parallel. I don't think it is possible with if else,
unless it is transformed into something else.

The other thing that made me wonder is that most people on the list (or all
except me) actually considered if-else-if-else more readable. It not only
creates a more complex structure (visually and syntactically  (more
letters)). But also the semantics of an *else* are different as of an *if*.
This is like North Carolina ;-)
if (man){ do_man_thing; } else { do_woman_thing(); } doesn't work anymore,
even it worked 20 years ago. Talking about maintaining :-)


I find if...else if...else more readable in that it more clearly 
expresses the programmer's intent that the options are mutually 
exclusive.  If it is done as a series of simple if...end if statements, 
the programmer may know that they're mutually exclusive, but the 
maintainer may not, and will take longer to get up to speed on the code.


If I see independent if...endif statements, I normally assume that 
anywhere from 0 to all of them may be true.




regards
Leon



-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Re: OT if/else or not if/else

[Leon Rosenberg]

On Mon, Apr 25, 2016 at 4:13 PM, Christopher Schultz <
ch...@christopherschultz.net> wrote:

> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> Leon,
>
> On 4/22/16 12:24 PM, Leon Rosenberg wrote:
> > Hi guys,
> >
>
> I would always choose the case with the elses.
>
> First, I think it's more clear: if you expect that only one branch of
> the code will run, and no others, then the elses tell the reader that
> fact without any further commentary. The zero-else case might help you
> catch some logic errors (because for example you can log each entry
> into a branch) but there are of course other ways to do that.
>
> Second, it's more efficient, regardless of what type of processor you
> have. Let's take an example where there are more than 3 branches. How
> about something like a million branches (just to accentuate the
> point)? If one of the branches runs, the others are skipped. If all
> branches have an equal change of being chosen, then the CPU has to
> perform on average 50 predicates. If you put the common cases at
> the top, you can do even better. Let's assume the 80/20 rule applies,
> here, and you can take a guess that, on average, the CPU will only
> have to perform 10 predicates on average.
>

I don't think the example is valid (even if machines with 100.000 cpus and
more actually exist). But I remember from days of my study, which lies way
way back, that languages that are optimized for parallel processing would
be able to tell the compiler to execute all ifs in parallel. So if we stick
with a number of ifs which is less than the number of available cores/pipes
we could run it all in parallel. I don't think it is possible with if else,
unless it is transformed into something else.

The other thing that made me wonder is that most people on the list (or all
except me) actually considered if-else-if-else more readable. It not only
creates a more complex structure (visually and syntactically  (more
letters)). But also the semantics of an *else* are different as of an *if*.
This is like North Carolina ;-)
if (man){ do_man_thing; } else { do_woman_thing(); } doesn't work anymore,
even it worked 20 years ago. Talking about maintaining :-)

regards
Leon

>
> - -chris
> -BEGIN PGP SIGNATURE-
> Comment: GPGTools - http://gpgtools.org
> Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
>
> iEYEARECAAYFAlceJg8ACgkQ9CaO5/Lv0PAODQCfRCBvVgM2HSM2/CBEGtlBe0Pg
> MrcAn2OdBYKJR0OSApcBFfONJHOlKGY0
> =YeMH
> -END PGP SIGNATURE-
>
> -
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
>
>

RE: OT if/else or not if/else

[Caldarale, Charles R]

> From: Christopher Schultz [mailto:ch...@christopherschultz.net] 
> Subject: Re: OT if/else or not if/else

> > Actually, a good compiler should generate the same code for switch
> > and if ... else if, assuming the boolean expressions used with the
> > ifs are compatible with a switch operand.

> Do you know of such a compiler (for Java)? I've never seen a compiler
> generate a switch bytecode when a "switch" statement wasn't present in
> the original Java source.

I'm not talking about the front end, but rather the native code generators 
after optimization (e.g., the C2 compiler for the Oracle JVM).  The bytecodes 
aren't representative of what actually gets executed.

 - Chuck


THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY 
MATERIAL and is thus for use only by the intended recipient. If you received 
this in error, please contact the sender and delete the e-mail and its 
attachments from all computers.


-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Re: OT if/else or not if/else

[Christopher Schultz]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Chuck,

On 4/22/16 12:54 PM, Caldarale, Charles R wrote:
>> From: David kerber [mailto:dcker...@verizon.net] Subject: Re: OT
>> if/else or not if/else
> 
>> But I would add that if the conditions can be reduced to
>> enumerations, a Switch would be even faster.
> 
> Actually, a good compiler should generate the same code for switch
> and if ... else if, assuming the boolean expressions used with the
> ifs are compatible with a switch operand.

Do you know of such a compiler (for Java)? I've never seen a compiler
generate a switch bytecode when a "switch" statement wasn't present in
the original Java source. My experience has been that the Java
compiler itself is fairly dumb, and the most optimizations seem to be
performed by the JIT which knows much more about what's really going
to happen than the Java-bytecode compiler.

(Admittedly, I haven't played with this in quite a while, and I never
really did a survey of compilers.)

- -chris
-BEGIN PGP SIGNATURE-
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iEYEARECAAYFAlceJt0ACgkQ9CaO5/Lv0PCwsQCcCZTs9ktsGh1m6RaetdAt5Iyd
LyYAmQG2HMoz1A6ps5oZPQ65IaLAY/yJ
=FKW2
-END PGP SIGNATURE-

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Re: OT if/else or not if/else

[Christopher Schultz]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Leon,

On 4/22/16 12:24 PM, Leon Rosenberg wrote:
> Hi guys,
> 
> this is completely off-topic ;-)
> 
> I was wondering if using if/else is not actually slowing down your
> code. Lets say I have three possible conditions, A, B and C, which
> are exclusive. My native approach would be: if (A){...} if
> (B){...} if (C){...}
> 
> now some people would 'optimize' it as if (A){ ...} else if (B)
> {} else if (C) { } and I think in the world of single-cpu
> computers this optimization could work.
> 
> But what is now, given that compilers can optimize stuff like this
> and tell the processor to calculate all 3 branches simultaneously,
> which is not possible for ifelse.
> 
> Which one would you choose? Equally important, which one do you
> think is more readable? I would say if else is hard to read, but
> this can be just personal impression.

I would always choose the case with the elses.

First, I think it's more clear: if you expect that only one branch of
the code will run, and no others, then the elses tell the reader that
fact without any further commentary. The zero-else case might help you
catch some logic errors (because for example you can log each entry
into a branch) but there are of course other ways to do that.

Second, it's more efficient, regardless of what type of processor you
have. Let's take an example where there are more than 3 branches. How
about something like a million branches (just to accentuate the
point)? If one of the branches runs, the others are skipped. If all
branches have an equal change of being chosen, then the CPU has to
perform on average 50 predicates. If you put the common cases at
the top, you can do even better. Let's assume the 80/20 rule applies,
here, and you can take a guess that, on average, the CPU will only
have to perform 10 predicates on average.

In Java (specifically), if you can use a switch statement, it's
(sometimes) even better: Java has bytecode primitives for two kinds of
switches: "lookup" switches and "table" switches. The first is just a
big table of possible predicate values and the addresses of the target
branch. The CPU scans through the (sorted) table of values and then
jumps based upon what it found. If you have a big table, this can be
less efficient than if/elseif/elseif. The second is even better: the
value of the predicate can be used to compute the location in the
table, so no scanning is required.

- -chris
-BEGIN PGP SIGNATURE-
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iEYEARECAAYFAlceJg8ACgkQ9CaO5/Lv0PAODQCfRCBvVgM2HSM2/CBEGtlBe0Pg
MrcAn2OdBYKJR0OSApcBFfONJHOlKGY0
=YeMH
-END PGP SIGNATURE-

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Re: OT if/else or not if/else

[Olaf Kock]

Am 23.04.2016 um 12:19 schrieb André Warnier (tomcat):
> Since it is still week-end..
>
> On 22.04.2016 21:57, Olaf Kock wrote:
>> Optimize for the maintainer, not for the compiler. The maintainer might
>> buy you a beer, the compiler for sure will not.
>
> With permission, I will borrow that paragraph for my upcoming
> "Programming for Dummies" book.
Run with it ;) (Will that be a predecessor or successor of the recently
circulating "Copying and pasting from Stackoverflow"?)

The further this awareness gets spread, the better for all of us. Plus,
the world would be better with more gratitude beer (or wine, coffee or
postcards).

Olaf

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Re: OT if/else or not if/else

[tomcat]

Since it is still week-end..

On 22.04.2016 21:57, Olaf Kock wrote:

Optimize for the maintainer, not for the compiler. The maintainer might
buy you a beer, the compiler for sure will not.


With permission, I will borrow that paragraph for my upcoming "Programming for 
Dummies" book.

This is probably nothing new for long-time practitioners of the art, but my recent 
analysis of about 100 programs and scripts history in our SVN repository showed that, over 
a 5-year period, about 10% of the time is spent on the original writing of the code, and 
90% on a posteriori maintenance and bug correction.
So, given that it is extremely difficult in the practice to convince programmers that they 
should make an effort and not deliver shaky code at the start, one might as well make an 
effort to make the 90% less painful.




-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Re: OT if/else or not if/else

[Baran Topal]

if else i prefer. Multiple ifs sounds like a political programming and you
are not sure what you are doing.

22 Nisan 2016 Cuma tarihinde, Leon Rosenberg 
yazdı:

> Hi guys,
>
> this is completely off-topic ;-)
>
> I was wondering if using if/else is not actually slowing down your code.
> Lets say I have three possible conditions, A, B and C, which are exclusive.
> My native approach would be:
> if (A){...}
> if (B){...}
> if (C){...}
>
> now some people would 'optimize' it as
> if (A){ ...} else if (B) {} else if (C) { }
> and I think in the world of single-cpu computers this optimization could
> work.
>
> But what is now, given that compilers can optimize stuff like this and tell
> the processor to calculate all 3 branches simultaneously, which is not
> possible for ifelse.
>
> Which one would you choose?
> Equally important, which one do you think is more readable? I would say if
> else is hard to read, but this can be just personal impression.
>
> regards
> Leon
>

Re: OT if/else or not if/else

[Olaf Kock]

Am 22.04.2016 um 18:24 schrieb Leon Rosenberg:
> Hi guys,
>
> this is completely off-topic ;-)
>
> I was wondering if using if/else is not actually slowing down your code.
> Lets say I have three possible conditions, A, B and C, which are exclusive.
> My native approach would be:
> if (A){...}
> if (B){...}
> if (C){...}
>
> now some people would 'optimize' it as
> if (A){ ...} else if (B) {} else if (C) { }
> and I think in the world of single-cpu computers this optimization could
> work.
That would be me - as you say they're mutually exclusive.

>
> But what is now, given that compilers can optimize stuff like this and tell
> the processor to calculate all 3 branches simultaneously, which is not
> possible for ifelse.
>
> Which one would you choose?
> Equally important, which one do you think is more readable? I would say if
> else is hard to read, but this can be just personal impression.
>
> regards
> Leon
I find that the if/else communicates the mutual exclusiveness better
than individual if blocks - thus be implicitly better readable.

Without proper measurements I'd be optimizing purely for readability of
the maintaining developer (which might be me - yes, I'm quite selfish).

*Only* in cases where a proper load test has demonstrated that a
different way to write this code makes a *significant* difference, I'd
shy away from this default. Which includes that this piece of code must
be in a highly frequented section, executed extremely often (otherwise
it wouldn't make a difference).

Yes, compilers can optimize, but developers and maintainers need to
understand the original intent, and they need every clue they can get.
Measure both options under realistic circumstances, then check the
difference. If the difference is significant, you might be up to
something. If it isn't: Make it as readable as possible.

Optimize for the maintainer, not for the compiler. The maintainer might
buy you a beer, the compiler for sure will not.

My 2ct (Euro, of course)
Olaf




-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Re: OT if/else or not if/else

[Tim Watts]

On Fri, 2016-04-22 at 17:34 +0100, Mark Thomas wrote:
> On 22/04/2016 17:24, Leon Rosenberg wrote:
> > Lets say I have three possible conditions, A, B and C, which are exclusive.
> > My native approach would be:
> > if (A){...}
> > if (B){...}
> > if (C){...}
> > 
> > now some people would 'optimize' it as
> > if (A){ ...} else if (B) {} else if (C) { }
> > and I think in the world of single-cpu computers this optimization could
> > work.
> > 

> As an aside, why can't the compile optimize to test the three conditions
> in parallel with the "else if"?

Actually, I would think the compiler could do a parallel optimization
for "if else" but more likely could NOT for a series of "if"s as often
only the programmer knows whether the "if" series is mutually exclusive.

> 
> Mark
> 
> 
> -
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
> 



-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

RE: OT if/else or not if/else

[Caldarale, Charles R]

> From: Leon Rosenberg [mailto:rosenberg.l...@gmail.com] 
> Subject: OT if/else or not if/else

> I was wondering if using if/else is not actually slowing down your code.
> Lets say I have three possible conditions, A, B and C, which are exclusive.
> My native approach would be:
> if (A){...}
> if (B){...}
> if (C){...}

> now some people would 'optimize' it as
> if (A){ ...} else if (B) {} else if (C) { }
> and I think in the world of single-cpu computers this optimization could
> work.

This doesn't really have anything to do with the number of CPUs, but rather 
whether or not a single core can execute instructions in parallel 
(vectorization or multiple execution ports).

> But what is now, given that compilers can optimize stuff like this and tell
> the processor to calculate all 3 branches simultaneously, which is not
> possible for ifelse.

These two sets of code are semantically different.  Unless the compiler (not 
the programmer) can prove that A, B, and C are mutually exclusive, the first 
example requires checking all three.  Also, unless the block of code executed 
for a prior true condition can be proven to not affect a later predicate (e.g., 
cannot alias, no side effects), the compiler must issue the three statement 
blocks in order.  Depending on the memory ordering model in play for the 
statements, the compiler may be able to issue speculative reads for each block 
of code, but that's very, very language specific.

A modern CPU core can also speculatively execute instructions, and will likely 
do so with either sequence (assuming typical memory ordering constraints).

> Which one would you choose?

Definitely the if ... else if ... sequence, or the corresponding switch 
statement, if feasible.  Give the compiler as much help as you can to figure 
out the programming intent.

 - Chuck


THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY 
MATERIAL and is thus for use only by the intended recipient. If you received 
this in error, please contact the sender and delete the e-mail and its 
attachments from all computers.


-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

RE: OT if/else or not if/else

[Caldarale, Charles R]

> From: David kerber [mailto:dcker...@verizon.net] 
> Subject: Re: OT if/else or not if/else

> But I would add that if the conditions can be reduced to enumerations, a 
> Switch would be even faster.

Actually, a good compiler should generate the same code for switch and if ... 
else if, assuming the boolean expressions used with the ifs are compatible with 
a switch operand.

 - Chuck
 

THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY 
MATERIAL and is thus for use only by the intended recipient. If you received 
this in error, please contact the sender and delete the e-mail and its 
attachments from all computers.


-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Re: OT if/else or not if/else

[David kerber]

On 4/22/2016 12:34 PM, Mark Thomas wrote:

On 22/04/2016 17:24, Leon Rosenberg wrote:

Hi guys,

this is completely off-topic ;-)


Excellent. An almost perfect Friday afternoon distraction. You just
needed some decent troll bait to make it perfect. ;)


I was wondering if using if/else is not actually slowing down your code.
Lets say I have three possible conditions, A, B and C, which are exclusive.
My native approach would be:
if (A){...}
if (B){...}
if (C){...}

now some people would 'optimize' it as
if (A){ ...} else if (B) {} else if (C) { }
and I think in the world of single-cpu computers this optimization could
work.

But what is now, given that compilers can optimize stuff like this and tell
the processor to calculate all 3 branches simultaneously, which is not
possible for ifelse.

Which one would you choose?


If (A){ ...} else if (B) {} else if (C) { }


Equally important, which one do you think is more readable? I would say if
else is hard to read, but this can be just personal impression.


Same one.

Regarding performance it depends on exactly what you are measuring and
how. Testing the conditions in parallel will be quicker if B or C is the
true condition. But, you will be doing more work as a result so in
theory throughput will fall.

Personally, I'd stick if "else if" and order the conditions from most
likely to least likely.

As an aside, why can't the compile optimize to test the three conditions
in parallel with the "else if"?


+1.  I prefer the if ... else if ... construct for readability as long 
as the are mutually exclusive.


But I would add that if the conditions can be reduced to enumerations, a 
Switch would be even faster.




-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Re: OT if/else or not if/else

[James H. H. Lampert]

But what is now, given that compilers can optimize stuff like this and tell
the processor to calculate all 3 branches simultaneously, which is not
possible for ifelse.

Which one would you choose?
Equally important, which one do you think is more readable? I would say if
else is hard to read, but this can be just personal impression.


1. Simultaneous execution of sequential IF blocks is not necessarily a 
good idea, as it could change the meaning of the code.


2. If you're using more than two mutually exclusive alternatives, then 
why are you using IF at all, unless you're working in a language that 
doesn't have any form of CASE construct? (Nearly everything based on C 
or ALGOL syntax has some form of it, and even primitive BASIC has 
ON...GOTO, or occasionally GOTO...ON, and even the most primitive 
versions of RPG I've worked with -- hardly a modern language -- have 
SELECT...WHEN...OTHER blocks).


--
JHHL

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Re: OT if/else or not if/else

[Mark Thomas]

On 22/04/2016 17:24, Leon Rosenberg wrote:
> Hi guys,
> 
> this is completely off-topic ;-)

Excellent. An almost perfect Friday afternoon distraction. You just
needed some decent troll bait to make it perfect. ;)

> I was wondering if using if/else is not actually slowing down your code.
> Lets say I have three possible conditions, A, B and C, which are exclusive.
> My native approach would be:
> if (A){...}
> if (B){...}
> if (C){...}
> 
> now some people would 'optimize' it as
> if (A){ ...} else if (B) {} else if (C) { }
> and I think in the world of single-cpu computers this optimization could
> work.
> 
> But what is now, given that compilers can optimize stuff like this and tell
> the processor to calculate all 3 branches simultaneously, which is not
> possible for ifelse.
> 
> Which one would you choose?

If (A){ ...} else if (B) {} else if (C) { }

> Equally important, which one do you think is more readable? I would say if
> else is hard to read, but this can be just personal impression.

Same one.

Regarding performance it depends on exactly what you are measuring and
how. Testing the conditions in parallel will be quicker if B or C is the
true condition. But, you will be doing more work as a result so in
theory throughput will fall.

Personally, I'd stick if "else if" and order the conditions from most
likely to least likely.

As an aside, why can't the compile optimize to test the three conditions
in parallel with the "else if"?

Mark


-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

OT if/else or not if/else

[Leon Rosenberg]

Hi guys,

this is completely off-topic ;-)

I was wondering if using if/else is not actually slowing down your code.
Lets say I have three possible conditions, A, B and C, which are exclusive.
My native approach would be:
if (A){...}
if (B){...}
if (C){...}

now some people would 'optimize' it as
if (A){ ...} else if (B) {} else if (C) { }
and I think in the world of single-cpu computers this optimization could
work.

But what is now, given that compilers can optimize stuff like this and tell
the processor to calculate all 3 branches simultaneously, which is not
possible for ifelse.

Which one would you choose?
Equally important, which one do you think is more readable? I would say if
else is hard to read, but this can be just personal impression.

regards
Leon