Index
> Main > Conditional moves vs jumpsGoto page Previous 1, 2, 3 Next |
| Author |
|
|
l_inc 09 Dec 2016, 03:12
revolution
Quote: Your synthetic tests also prove nothing other than "it depends". That's because you're asking the wrong question. The question should be: "What conditions/effects/mechanisms do I need to take into account?" — rather than: "What's faster?" system error Quote: synthetic tests are not useless Keywords: "on its own", "blind", "black box", "with no discussion". _________________ Faith is a superposition of knowledge and fallacy Last edited by l_inc on 09 Dec 2016, 03:16; edited 1 time in total |
|||
09 Dec 2016, 03:12 |
|
|
revolution 09 Dec 2016, 03:13
system error wrote: synthetic tests are not useless. People been doing "synthetic" tests in the wind tunnels and on dyno machines. The same goes with programming of any kind. They provide much more controlled environment for collecting specific data or observing specific behavior. |
|||
|
09 Dec 2016, 03:13 |
|
|
revolution 09 Dec 2016, 03:18
l_inc wrote: revolution We also have this problem with the big-O notation. It is easy to compare the O values and conclude that algorithm A is "better" than B, but in the actual use case things can be very different. |
|||
|
09 Dec 2016, 03:18 |
|
|
system error 09 Dec 2016, 03:18
inc and revo, you guys may have to take a second look at the OP's original post. He/She is giving us a simple condition and not an entire code or program. No info on current CPU. So his intention is pretty much clear. He wants to use a dyno to test his new bike rather than testing it on real road track. So give him synthetic tests and results. I am convince that he'll be happy with that.
The answer would be different if he gave a full routine or a complete code where we can identify those specific things that need optimizing. So my conclusion is based on his intention and not on his 'invisible' code that I am projecting in my mind. |
|||
|
09 Dec 2016, 03:18 |
|
|
revolution 09 Dec 2016, 03:20
system error wrote: inc and revo, you guys may have to take a second look at the OP's original post. He/She is giving us a simple condition and not an entire code or program. No info on current CPU. So his intention is pretty much clear. He wants to use a dyno to test his new bike rather than testing it on real road track. So give him synthetic tests and results. I am convince that he'll be happy with that. ETA: And actually redsock did that and came to no conclusion, so it got us no further. |
|||
|
09 Dec 2016, 03:20 |
|
|
system error 09 Dec 2016, 03:26
And btw, I am a Honda CBR fans. I am a fan because I can't afford one
 |
|||
|
09 Dec 2016, 03:26 |
|
|
revolution 09 Dec 2016, 03:29
system error wrote: And btw, I am a Honda CBR fans. I am a fan because I can't afford one  |
|||
|
09 Dec 2016, 03:29 |
|
|
system error 09 Dec 2016, 03:31
my dream bike
 |
|||
|
09 Dec 2016, 03:31 |
|
|
system error 09 Dec 2016, 03:32
revolution wrote:
|
|||
|
09 Dec 2016, 03:32 |
|
|
revolution 09 Dec 2016, 03:38
system error wrote: you really are a car guy arent you?  |
|||
|
09 Dec 2016, 03:38 |
|
|
l_inc 09 Dec 2016, 03:42
revolution
Quote: The "what's faster?" question is not mine. This is the OPs question. And if you answer you can say: "It depends", and leave him with nothing, or you can answer the other, better question, and this way give him a better insight. Quote: The mechanisms behind it are variable, as everyone has noted in here. "Variable" does not mean arbitrary. Most of them follow a common scheme and differ only in a relatively small number of parameters. Quote: It is easy to compare the O values and conclude that algorithm A is "better" than B, but in the actual use case things can be very different. You don't wanna argue that the complexity estimation gives no information at all, do you? To make use of your nice analogy: Your way to answer, what's faster, would be: "It depends", leaving the one asking with the task to check all possible inputs. My way to answer, what's faster, would be to give the big-O functions and allowing the one asking to do a single test for each of them to retrieve the constants only. _________________ Faith is a superposition of knowledge and fallacy |
|||
|
09 Dec 2016, 03:42 |
|
|
revolution 09 Dec 2016, 04:04
l_inc wrote: And if you answer you can say: "It depends", and leave him with nothing, or you can answer the other, better question, and this way give him a better insight. l_inc wrote: You don't wanna argue that the complexity estimation gives no information at all, do you? l_inc wrote: Your way to answer, what's faster, would be: "It depends", leaving the one asking with the task to check all possible inputs. And testing all inputs (lengths, ranges, types, whatever) is part of testing the application. If one doesn't test it then how does one know it works as intended? l_inc wrote: My way to answer, what's faster, would be to give the big-O functions and allowing the one asking to do a single test for each of them to retrieve the constants only. |
|||
|
09 Dec 2016, 04:04 |
|
|
redsock 09 Dec 2016, 04:24
l_inc wrote: If you just cluelessly test, then you'll have an unlimited number of degrees of freedom: you may manage to "optimize" one little piece of your software, but then any little change in any other piece may cause dramatical performance degradation, and the whole "optimization" will have to start from scratch. This whole thread is good material to absorb, despite the occasional diversion 
Discussions about the reasons why are far more valuable than barking alone in the wilderness (aka blackbox testing, haha). @system_error: hahah, we are nuts? Perhaps so, maybe its just that we don't talk "shop" enough with each other
Cheers all, this thread is gold. |
|||
|
09 Dec 2016, 04:24 |
|
|
l_inc 09 Dec 2016, 04:29
revolution
Quote: Big-O values are a guide, not an answer. There's no significant difference between a guide and an answer, if the guide trivially and unambiguously leads to an answer under given conditions. Same as indefinite integration leads to a parameterized function being the answer and the guide at the same time. Quote: I would be happy to see your answer to the OP. The OP has a lot of information including my posts as well. He'll be able to ask more if that turns out to be not enough. Quote: And testing all inputs (lengths, ranges, types, whatever) is part of testing the application According to this (partial) definition of testing very few applications have ever been tested. Most of them are only partially tested, i.e. with a very small fraction of all possible inputs. Quote: If one doesn't test it then how does one know it works as intended? How do you know no pair of positive integers raised to the power of 3 can sum up to the third power of a positive integer without testing all possible triples of integers? _________________ Faith is a superposition of knowledge and fallacy |
|||
|
09 Dec 2016, 04:29 |
|
|
revolution 09 Dec 2016, 04:34
redsock wrote: Discussions about the reasons why are far more valuable than barking alone in the wilderness (aka blackbox testing, haha). Q: 'Why' is A faster than B on platform C with input D? A: Erm, do we even know 'if' A is faster than B, shouldn't we test it first? |
|||
|
09 Dec 2016, 04:34 |
|
|
l_inc 09 Dec 2016, 04:49
revolution
Quote: We can't discuss 'why' until we even know 'if'. We can't discuss 'if' until we even know 'what'. Q: Is test case A faster then test case B? A: Do we know what test case A is, and what test case B is? And to finalize the round: It's inefficient to discuss 'what' until we know 'why' [it should be fast]. _________________ Faith is a superposition of knowledge and fallacy |
|||
|
09 Dec 2016, 04:49 |
|
|
revolution 09 Dec 2016, 05:02
l_inc wrote: We can't discuss 'if' until we even know 'what'. redsock posted 'if' so we're good there. The 'why' answer ... "it depends", hehe.
And really the answer here is "it doesn't matter". Usually when someone posts "is A better than B" the answer will be "it doesn't matter". Because if they have no idea which is "better" then it won't matter which they choose since they'll never know the "real" answer anyway. |
|||
|
09 Dec 2016, 05:02 |
|
|
l_inc 09 Dec 2016, 05:12
Very generous, revolution.
_________________ Faith is a superposition of knowledge and fallacy |
|||
|
09 Dec 2016, 05:12 |
|
|
system error 09 Dec 2016, 05:25
@redsock, There's nothing gold about this thread. If you want to have better discussions on optimization, go to MASM forum. They discuss these things better.
My point is clear. Limit the discussion on optimizations based on what the OP wants to know. Going wide and deep is useless and limitless because topics of optimization is way too vast to discuss, let alone to based on conjecture and projected code from everyone involved. For example, we don't have to involve code alignment for simple explanation like this because we'll never know where the loader will put our code in memory. It could be even or add address. It gives the wrong impressions to the OP that comparison codes should be aligned every time while in reality that doesn't always produce positive results. Now FINALLY everyone seems to agree that it's all up to the real OP's application. So where's the application code? NONE. So what are we discussing here that takes 3 pages long when there's no application code to talk about? Nothing but wild assumptions and "it depends". LOL |
|||
|
09 Dec 2016, 05:25 |
|
| Goto page Previous 1, 2, 3 Next < Last Thread | Next Thread > |
Forum Rules:
|