Recientemente sistemi per roulette casino live gambling game gratis giocare a poker online free craps…

I also feel that I should mention something else. The “optimalness” of your boundary-checking depends on the values of n and k that you test with. If your conditions of k == 1 and residue == 0 are frequently true, then you’ll probably see a good speedup. However, if both of those conditions are frequently false (allow n and k to vary over all positive integers, and see how often they’re true), then your solution has become sub-optimal, as you’re now checking for conditions that are rare. The bottom line is that checking for boundary cases only saves time if they occur frequently, and if the cost of checking for them is less than the cost of simply using the formula.

Maybe Java and possibly even .NET has this issue (it may even be in the specs for the language(s) to do extra boundary checking because of the nature of the language(s)), but I haven’t found any issue with this in C++. I look at the Assembly code output by the compiler, and things are the same. I’m glad I don’t suffer from this issue in C++. It does exactly what I write rather than what it thinks I write. ^_^

Also your points on improving the slow code is great!

@Travers
I’m glad that you tried it. I’m trying to explain how a Big code can’t be a Bad Code ( as normally people think ).

Here are my results when I tried while I was writing this post.

For IF Condition test
1 – Time: 37.5
2 – Time: 29.7
3 – Time: 31.2

For the Problem test
1 – Time: 42.2
2 – Time: 34.4
3 – Time: 32.8

Please find the code for above two tests at http://drop.io/mymindleaks. You will find two java files.

I strongly belive, Manual optimization is more effective than Compiler Optimization.

Using C# (VS 2008 Express), I made a quick benchmark for your first example:

using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;

namespace TestShortCode
{
class Program
{
delegate int TestMethod(int a, int b);

static int Method1(int a, int b) {
int x = a < b ? a : b;
return x;
}

static int Method2(int a, int b)
{
int x = b;
if (a < b)
x = a;
return x;
}

static void Profile(TestMethod code)
{
Random r = new Random();
code(0, 0);
DateTime startTime = DateTime.Now;
for (int i = 0; i < 100000000; i++)
{
int a = r.Next(100);
int b = r.Next(100);
code(a, b);
}
DateTime endTime = DateTime.Now;
TimeSpan delta = endTime – startTime;
Console.WriteLine(delta);
}

static void Main(string[] args)
{
Profile(Method1);
Profile(Method2);
}
}
}

Running it a half-dozen times, I got consistently the same results:
00:00:09.9218750
00:00:09.9375000

I notice people tend to ASSUME they know what their compilers are doing, but modern compilers do some crazy-ass stuff even with optimization turned off.

Your first example is not a good one because it ignores two things: 1) you assume the compiler somehow does a “return” when in fact even in debug output it would generate case B, and 2) the branch is the single most expensive operation (writes go straight to the cache and on most CPUs have 0-cost writes, at least for single store instructions).

In VM contexts, the issue gets even more fuddled where the ad-hoc compiler can use profiling of your code to figure out which branch is more likely and arrange for the most common case to be the fall-through.

On to your major point: that is true that writing “bigger” code can lead to time savings–the most famous example is loop unwinding. But as Donald Knuth liked to say “Premature optimization is the root of all evil”. One should profile your code and _only_ optimize the hot-spots. My personal experience has given me the following strategy:

For slow code try these steps (in order):
1. Change the algorithm. In 3-D world rendering (like for Halo), back-face culling is a HELL of a lot faster than a faster polygon renderer.

2. I/O bound is I/O bound. If your CPU monitor is less than half-full but your HD light is solid, you’re definitely I/O bound. Reduce I/O access by using caching or memory mapping (<– most often overlooked speed-up for file-based processing). If you are connecting to a database, figure out where in the database pipeline is the slowdown. Most of the time, it’s the query. Be generous with indexing on SQL databases.

3. Watch your memory access. This is very CPU/System dependent, but generally CPU time is cheaper than memory accessing (at least for C/C++/Assembly programming). It can _sometimes_ be faster to calculate a value than to use a look-up table. There are exceptions, but one should look at the actual assembly generated before deciding this because compilers can play mind-games on you. In interpreted languages (like Perl & Python), look-up tables are faster than calculations.