On 4/10/2023 2:18 PM, Artjom wrote:
> I have written this simple bruteforce algorithm that finds max sum of subsequence in some sequence, both in C# and D. And when the size of array is 1000000 elements - D is 20 seconds lated. Why?
>
>      public int solveBruteForce()
>      {
>          int currMax = arr[0], currSum;
>          foreach (_; arr)
>          {
>              currSum = 0;
>              foreach (int el; arr)
>              {
>                  currSum += el;
>                  currMax = max(currSum, currMax);
>              }
>          }
> 
>          return currMax;
>      }

The outer loop does nothing, perhaps C# optimizes it away.

On 4/12/23 05:19, WebFreak001 wrote:

> Otherwise this currently always doubled the time, since you added the
> total (converted) seconds twice.

I am beginning to think performance comparisons are trickier than they look. ;)

Ali

On Wednesday, 12 April 2023 at 13:13:42 UTC, Ali Çehreli wrote:
> On 4/12/23 05:19, WebFreak001 wrote:
>
> > Otherwise this currently always doubled the time, since you
> added the
> > total (converted) seconds twice.
>
> I am beginning to think performance comparisons are trickier than they look. ;)
>
> Ali

Ironic that it takes so long to do a proper performance comparison when the only reason to do it is to save time.

On 4/12/23 06:24, bachmeier wrote:

> Ironic that it takes so long to do a proper performance comparison when
> the only reason to do it is to save time.

I sometimes have the same concern for optimized builds: Will the number of times a program will ever be executed warrant the time lost on optimized builds? :)

Ali

On Wed, Apr 12, 2023 at 07:35:29AM -0700, Ali Çehreli via Digitalmars-d wrote:
> On 4/12/23 06:24, bachmeier wrote:
> 
> > Ironic that it takes so long to do a proper performance comparison when the only reason to do it is to save time.
> 
> I sometimes have the same concern for optimized builds: Will the number of times a program will ever be executed warrant the time lost on optimized builds? :)
[...]

Depends on the program and how it will be used.

For one-off shell-script replacements, the answer is no, it's not worth the bother.  For this kind of task, what you want is fast turnaround time: to fix bugs in the code, then once it does what it needs to, you just get a result and that's good enough. No need to sweat it.  If the difference in performance is 10ms per run vs. 100ms per run, who cares, you won't even notice the difference. Waiting for 5s compiles as LDC optimizes it to the end of the world and back to get it down to 10ms is simply not worth it, when using dmd gives you a 2s turnaround time for 100ms runtime that you won't even notice.

For long-running compute-intensive tasks, though, the tables begin shifting the other way. If using dmd gives you 2s turnaround times but it takes the program 10 hours to come up with the answer vs. using ldc with 8s compile times but the program comes up with the answer in 4 hours, then yeah, the time spent on optimization is totally worth it.

Or if you're running a high-traffic website and using dmd gives you fast turnaround during development, but caps website performance at say 1000 requests per second, then you'd want to consider using ldc for the production build, it will take a little bit longer but may get you to 5000 requests per second.  If your business depends on the volume of processed requests, this would totally be a worthwhile investment.  But if it's a low traffic website and the difference is between 1000 requests per *day* vs. 5000 requests per day, then I wouldn't bother, dmd gives me faster turnaround and therefore faster development, and I won't even notice the difference anyway.

It's not just about compilers, of course. The same reasoning goes for time spent hand-optimizing your code.  If you spend 10 hours optimizing a shell script from 100ms runs to 10ms runs, you can feel great about yourself but in the grand scheme of things it's a waste of time. But if 10 hours of hand-optimization gets you from 1000 requests per second to 10000 requests per second on a high-traffic website that will be continuously running for a long time, then yeah it's totally worth it.


T

-- 
Insanity is doing the same thing over and over again and expecting different results.

On Wednesday, 12 April 2023 at 17:16:55 UTC, H. S. Teoh wrote:
> On Wed, Apr 12, 2023 at 07:35:29AM -0700, Ali Çehreli via Digitalmars-d wrote:
>> On 4/12/23 06:24, bachmeier wrote:
>> 
>> > Ironic that it takes so long to do a proper performance comparison when the only reason to do it is to save time.
>> 
>> I sometimes have the same concern for optimized builds: Will the number of times a program will ever be executed warrant the time lost on optimized builds? :)
> [...]
>
> Depends on the program and how it will be used.
>
> For one-off shell-script replacements, the answer is no, it's not worth the bother.  For this kind of task, what you want is fast turnaround time:

I agree with all your views. But you are missing something! So is the questioner:

C sharp is optimized to be compatible with W$. So if you are using windowze, the comparison you make is similar to comparing jet-ski and motorcycle.

SDB@79

On Monday, 10 April 2023 at 21:18:59 UTC, Artjom wrote:
> I have written this simple bruteforce algorithm that finds max sum of subsequence in some sequence, both in C# and D. And when the size of array is 1000000 elements - D is 20 seconds lated. Why?
> D code (algorithm):
> ..

By C#, I presume you mean dotnet.exe (and not csc.exe).

dotnet has many, many optimizations with regards to looping, and many more to come.

btw: 'quick JIT is not used for methods that contain loops'
https://learn.microsoft.com/en-us/dotnet/core/runtime-config/compilation

also:
'Loop optimizations can be surprising'
https://leveluppp.ghost.io/loop-optimizations-in-various-compilers/

As for D, well you have 3 different compilers to choose from, and various defaults, and various flags you can pass to them....so good luck with that ;-)

 - "The 80-20 rule is the dominating force driving the argument that premature tuning is a sin."