Recent

Author Topic: Ridiculously slow?  (Read 2832 times)

Shpend

  • Jr. Member
  • **
  • Posts: 93
Re: Ridiculously slow?
« Reply #30 on: December 18, 2019, 03:32:50 pm »
Why did you put the if inside the second loop?  You check the mod of li 1000000 times, for no reason. This should be much faster:

Because I am a late-night-owl-idiot ===> I need to stop doing focusheavy stuff at such a time.. You are right , even the original testcase had the mod logic in the outer loop, sry!

I adapted the change and now its:

//DELPHI 10.3.3 Compiler

* Optimization ON
* release mode

= 26-28 sec
--------------------------

* Optimization OFF
* Debug mode

= 120 sec



Shpend

  • Jr. Member
  • **
  • Posts: 93
Re: Ridiculously slow?
« Reply #31 on: December 18, 2019, 03:41:29 pm »
Quote
But the OP has specifically quoted times gathered from original runs of the test code using Delphi and C#, and complained that the FPC result was orders of magnitude slower. Even if the original code is flawed, we need to see it so that we can check the accuracy of the transcription.

I never stated that? Look my first post in this thread (the original ofc) I just said I compare delphi vs C# 2015 since the original testcase was the same, I only tested it not with Delphi 6 but with my community Edition 10.3.3!

MarkMLl

  • Hero Member
  • *****
  • Posts: 1242
Re: Ridiculously slow?
« Reply #32 on: December 18, 2019, 03:50:02 pm »
You said

Quote
he got for delphi like 2-3 sec and C# got 17 sec or so, for me the program takes up to 03min 40sec to finish

So let's see the code for those test cases.

MarkMLl
Turbo Pascal v1 on CCP/M-86, multitasking with LAN and graphics in 128Kb.
Pet hate: people who boast about the size and sophistication of their computer.

Shpend

  • Jr. Member
  • **
  • Posts: 93
Re: Ridiculously slow?
« Reply #33 on: December 18, 2019, 03:58:23 pm »
Quote
So let's see the code for those test cases.

Is this ok?

https://www.delphipraxis.net/186058-delphi-vs-c-vs-c-7.html

Shpend

  • Jr. Member
  • **
  • Posts: 93
Re: Ridiculously slow?
« Reply #34 on: December 18, 2019, 04:03:56 pm »
Did anyone of you guys at some point made some benchmarks also for delphi, based on this site, I would be very interessted:

https://benchmarksgame-team.pages.debian.net/benchmarksgame/fastest/fpascal-gpp.html

schuler

  • Full Member
  • ***
  • Posts: 167
Re: Ridiculously slow?
« Reply #35 on: December 18, 2019, 04:37:24 pm »
@Martin_fr
Quote
fpc 3.0.4 (64bit)     312 sec
fpc trunk (32&64bit) 91 sec

This is a big change! Congrats to FPC developers!

440bx

  • Hero Member
  • *****
  • Posts: 2000
Re: Ridiculously slow?
« Reply #36 on: December 18, 2019, 05:10:02 pm »
Quote
So let's see the code for those test cases.

Is this ok?

https://www.delphipraxis.net/186058-delphi-vs-c-vs-c-7.html
Not really.  Here is why:
Code: C  [Select][+][-]
  1. private void button1_Click(object sender, EventArgs e)
  2.          {
  3.              int li = 0;
  4.              int lj = 0;
  5.              double lw = 0.0f;
  6.              double lc = 0.0f;
  7.              for (li = 0; li < 50000; li++)   // <- this loop is _not_ empty
  8.              {
  9.                 for (lj = 0; lj < 1000000; lj++)   // <--- this loop is empty !!
  10.                  {
  11.                  }
  12.                  if (li % 1000 == 0)
  13.                  {
  14.                      button1.Text = li.ToString();
  15.                      button1.Update();
  16.                  }
  17.              }
  18.  
  19.          }
It's possible and maybe even likely that the empty loop was optimized away since even after getting rid of it, there is still something present in the originally "outer" loop.

That code, execution-wise, is nowhere near what is in your OP.

There is NO way for a PC-class processor today to execute the code you presented in 3 secs.  C#, 17 secs ? not even in MS' wet dreams.
FPC v3.0.4 and Lazarus 1.8.2 on Windows 7 64bit.

GetMem

  • Hero Member
  • *****
  • Posts: 3757
Re: Ridiculously slow?
« Reply #37 on: December 18, 2019, 10:28:48 pm »
@440bx
Quote
C#, 17 secs ? not even in MS' wet dreams.
:D This is funny.

marcov

  • Global Moderator
  • Hero Member
  • *****
  • Posts: 8733
  • FPC developer.
Re: Ridiculously slow?
« Reply #38 on: December 18, 2019, 11:31:03 pm »
C# and Java code that only deals with value types in a single piece of source can be quite fast and compete with Pascal, C etc.

That is just static compilation optimization, and just depends on how much time cq money you are willing spend on the compiler.

It was used to great effect to demonstrate speediness when C# was introduced.

The challenges of .NET/C# come only later if the code paths get more complex to prohibit such optimizations and you start to use types that use the GC and the fact that strings are immutable.

ASBzone

  • Sr. Member
  • ****
  • Posts: 461
  • Automation leads to relaxation...
    • Free BrainWaveCC Console Utilities
Re: Ridiculously slow?
« Reply #39 on: December 18, 2019, 11:42:18 pm »

ETA:

One thing I don't understand is why @wp's results don't show the same time difference between Delphi and FPC's tests.



ETA 2

I forgot to mention, the above results are in 64bit.


On my machine with just the empty loops you provided, I ran a test on Win10, both 32-bit and 64-bit, with my normal optimizations[1], and both loops ran for 12 seconds.


[1] -O3 -CX -XX -Xs -OpCOREAVX2 -CfSSE42
-ASB: https://www.BrainWaveCC.com

Lazarus v2.0.11 r63516 / FPC v3.2.1-r46879 (via FpcUpDeluxe) -- Windows 64-bit install w/32-bit cross-compile
Primary System: Windows 10 Pro x64, Version 2004 (Build 19041.508)
Other Systems: Windows 10 Pro x64, Version 2004 or greater

440bx

  • Hero Member
  • *****
  • Posts: 2000
Re: Ridiculously slow?
« Reply #40 on: December 19, 2019, 12:20:09 am »
C# and Java code that only deals with value types in a single piece of source can be quite fast and compete with Pascal, C etc.
There are situations where that is true but, C# is caught between a rock and a hard place.  MS wants to provide fast compilation times when using C# (something their C/C++ compilers aren't particularly good at), as a result, it simply cannot afford to deeply analyze the code in order to achieve a really high level of optimization.  This is particularly true for their JIT, that thing cannot afford to spend much time doing sophisticated optimizations.  It's expected to be fast, that limits it.

That is just static compilation optimization, and just depends on how much time cq money you are willing spend on the compiler.
There is that.  Also, there are some cases a compiler may not even bother to identify simply because they are rare and often are the result of "not so great programming", e.g, empty loops and nested empty loops.

It was used to great effect to demonstrate speediness when C# was introduced.
No doubt it impressed the C programmers, particularly those who use VC/C++.

The challenges of .NET/C# come only later if the code paths get more complex to prohibit such optimizations and you start to use types that use the GC and the fact that strings are immutable.
I just played with C#, my knowledge of C# and .Net internals is limited but, C# isn't a pony I'd take to the Kentucky Derby (unless I had a bucket of U235 enriched carrots for it.)



On my machine with just the empty loops you provided, I ran a test on Win10, both 32-bit and 64-bit, with my normal optimizations[1], and both loops ran for 12 seconds.
It sounds like, 1. you have a fast machine :) and 2. version 3.2.0 does register allocation better than 3.0.4. 
« Last Edit: December 19, 2019, 12:23:21 am by 440bx »
FPC v3.0.4 and Lazarus 1.8.2 on Windows 7 64bit.

valdir.marcos

  • Hero Member
  • *****
  • Posts: 999
Re: Ridiculously slow?
« Reply #41 on: December 19, 2019, 08:46:14 am »
C# and Java code that only deals with value types in a single piece of source can be quite fast and compete with Pascal, C etc.
That is just static compilation optimization, and just depends on how much time cq money you are willing spend on the compiler.
It was used to great effect to demonstrate speediness when C# was introduced.
The challenges of .NET/C# come only later if the code paths get more complex to prohibit such optimizations and you start to use types that use the GC and the fact that strings are immutable.
Interesting.

 

TinyPortal © 2005-2018