Welcome To The Home Of The Visual FoxPro Experts  
home. signup. forum. archives. search. google. articles. downloads. faq. members. weblogs. file info. rss.
 From: Pete Sass
  Where is Pete Sass?
 Marathon, Ontario
 Canada
 Pete Sass
 To: Mike Yearwood
  Where is Mike Yearwood?
 Toronto
 Canada
 Mike Yearwood
 Tags
Subject: RE: C++ compiler
Thread ID: 415740 Message ID: 416013 # Views: 51 # Ratings: 0
Version: Visual FoxPro 9 SP2 Category: 3rd Party Software
Date: Thursday, December 18, 2014 7:53:51 PM         
   


> >
> >
> >
> > Hi Mike,
> >
> >
> > VERY --- VERY INTERESTING QUESTION HERE!
> >
> >
> > C++ does not beat VFP on every task if you do what you are looking at and this is picking one single
> > individual task such as a FOR loop.
> > Actually the FOR loop case you picked is a known issue with C++ and again this is a matter of processor
> > register handling if you decompile into assembly.
> >
> > Another very good example of this is with the VFP Scan . . . EndScan that Visual FoxPro has and which
> > was specifically designed for loop handing of a table or cursor. As we VFP folks all know the Scan
> > operates quicker that a DO WHILE loop as the skip and EOF() conditions are built into the Scan command
> > thus eliminating the SKIP line of code and the WHILE .not. EOF() checking on each loop to test for and
> > end of file marker.
> >
> > Well C++ does not have a Scan ... EndScan loop so when coding and compiled you cannot use this and
> > have to resort to generally a C++ DO WHILE loop.
> > You can imaging that a test of this nature again with only one specific looping process being measured
> > and with nothing else going on, my money is on VFP.
> >
> >
> > Here is yet another interesting example, but now looking at C++ versus VB.NET
> >
> > C++
> >
void problem10(void)
> > {   
> >    clock_t init, final;
> >    init=clock();
> > 
> >    int maxVal = 2000000;
> >    long long sumOfPrimes = 0;
> >    for (long i = 2; i < maxVal; i++)
> >    {
> >       if (isPrime(i))
> >       {
> >          sumOfPrimes+= i;
> >       }
> >    }
> >    final = clock() - init;
> >    cout << (double)final / ((double)CLOCKS_PER_SEC);
> >    cout << "The sum of all the prime numbers below " << maxVal << " is " << sumOfPrimes;
> > }
> > 
> > bool isPrime(int NumToCheck)
> > {
> >    for (int i = 2; i <= (sqrt((double)NumToCheck)); i++)
> >    {
> >       if (NumToCheck % i == 0)
> >       {
> >          return false;
> >       }
> >    }
> >    return true;
> > }

> >
> >
> >
> >
> >
> > VB.NET
> >
Private Sub Form1_Load(ByVal sender As System.Object, ByVal e As System.EventArgs) Handles MyBase.Load
> >     Dim watch As New Stopwatch
> >     watch.Start()
> > 
> >     Dim maxVal As Long = 2000000
> >     Dim sumOfPrimes As Long = 0
> >     For i As Integer = 2 To maxVal
> >         If (isPrime(i) = True) Then
> >             sumOfPrimes += i
> >         End If
> >     Next
> >     watch.Stop()
> >     Console.WriteLine(watch.ElapsedMilliseconds)
> >     Console.WriteLine("The sum of all the prime numbers below " & maxVal & " is " & sumOfPrimes)
> > End Sub
> > 
> > Function isPrime(ByVal NumToCheck As Integer) As Boolean
> >     For i As Integer = 2 To (Math.Sqrt(CDbl(NumToCheck)))
> >         If (NumToCheck Mod i = 0) Then
> >             Return False
> >         End If
> >     Next
> >     Return True
> > End Function

> >
> > Speed is of course relating to the computer hardware, but on the same machine the VB code will
> > beat the C++ code by a factor of approx. a 25% to 30% speed improvement and all calculations are
> > being done in memory with no disk assess, etc. involvement.
> > Simply doing a SQroot calc on primary numbers.
> >
> > If you review the code snippets above you can see the structure is as close to the same as
> > possible to do exactly the same thing, but a increase in speed will be realized using VB.NET
> > I am again looking at the FOR loop scenario here.
> >
> > The root cause of all of this is as follows:
> > The VB.Net computes once at the beginning and end of the loop, while C++, C# and Java compute
> > every time through the loop because their looping primitives are not defined the same way.
> >
> > So you can see the point I was trying to make was that when you target one thing and one process
> > it is easy to show the same process in one language faster than in another language. In my case
> > knowing C++ handles its math calculations on every loop pass and VB.NET does not, well one could
> > now demonstrate this and make the statement, "this proves VB.NET is faster that C++"
> > However, this is again just an opinion based upon one loop benchmark test.
> > The above statement concluding that VB.NET is faster is misleading as C++ is faster in almost every
> > other benchmark test you would think up, but not in this one . lol
> >
> >
> > I see a very distinct difference between isolated benchmark testing of this nature versus the overall
> > responsiveness of the running application in a real-world setting.
> >
> >
> > However Mike a very interesting question and actually pushed me into doing some benchmark testing that
> > to tell you the truth I was surprised at. In the VFP versus C++ on the 6,000,000 record loop I would
> > have expected C++ to beat the socks off VFP not coming in at a measly 3-4 second faster on 18 million
> > cycles. I would have guessed a 40% speed improvement in favour of C++. Apparently C++ has a very
> > slight edge here. In the loop only test "doing nothing else" well VFP came ahead.
> >
> >
> > Pete "the IceMan", from the Great White North of Canada.
> > www.marathongriffincomputers.com
>
> Except for one assumption of mine - that VFP is not really compiling to the level of C++ - and is simply passing a line of code to a set of C++ functions which do the execution. If so, that passing would introduce overhead. VFP could beat C++ in LOCATE FOR or SQL because the programmers that made VFP are probably better than we are at C++. Further the code that does the LOCATE can examine the command and interpret it
>
> LOCATE FOR .F.
>
> Could instantly move to the EOF() without any consideration of the number of records...
>
> Mike Yearwood
> Microsoft MVP Visual FoxPro 2008, 2009
> We have enough youth. We need a fountain of smart!
> There may be many ways to skin a cat, but there are very few right ways to do it.


Hi Mike,

I think the assumption you have or maybe had is what most folks "even experienced developers"
may think.
C++ will definitely beat VFP, C#, etc. overall, but in specific isolated cases this is not always
true and the assumption maybe that C++ will always win out may not apply.

You comment as well about VFP not compiling to the same level as C++ is 100% on target. IN VFP we
code what we want to code and the VFP compiler makes an EXE in p-code not pure assembly. So we as
developers decide upon what logic we will use. ie: I will use a FOR loop not at DO WHILE loop, etc.
The p-code does exactly what our source code says to do.

In a C++ compiled project the compiler can take the decision away from you and may do something that
you did not expect. You only know what the compiler actually did if you decompile and review the
assembly calls.
In all fairness to the compilers of today they all do a very good optimization job, but every once in
a while an issue can rear it head.

For me the C++ exe make sense to me to use, but maybe not for everyone?
The speed advantage is really not the driving force at all in C++, my reasons relate to . . .

a) All but impossible to gleam any code out of and if someone what's to decompile and weed thought
400,000 lines of pure assembly call and try to figure out my code that go for it.

b) Overall the C++ compiler does a pretty good job of reducing the overall EXE size and I am
happy with this. The tokenization should reduce total EXE size as well plus as well provide a
speed boost.

c) The other think that I like is I can include runtime dll's in the EXE build. I no longer have to bother
about VFP runtime distribution files. You never end up with the infamous . . .
"Cannot locate the Microsoft Visual FoxPro support library."
due to old runtime files left in old Windows environmental path settings.

e) VFP although not supports is still one of the easier development languages to use in referencing
an external dll and exposing what-ever calls have been provided in the dll. Just like the rest of Visual
Studio products the object reference work very well with the VFP intellisense, providing easy drilldowns.

All said and done today I still do a lot in VFP and to me this is still a very viable development language.
I can say that brand new projects starting at ground zero, I would be hard pressed to code in VFP when other
supported development languages are out there. Again a personal choice that each developer will need to
decide upon.

Pete "the IceMan", from the Great White North of Canada.
www.marathongriffincomputers.com

ENTIRE THREAD

C++ compiler Posted by Mike Yearwood @ 12/11/2014 9:47:42 PM
RE: C++ compiler Posted by Tony Vignone @ 12/11/2014 10:18:16 PM
RE: C++ compiler Posted by michael johnson @ 12/12/2014 3:15:14 AM
RE: C++ compiler Posted by Mike Yearwood @ 12/12/2014 4:40:18 PM
RE: C++ compiler Posted by Chuanbing Chen @ 12/12/2014 8:01:24 AM
RE: C++ compiler Posted by Pete Sass @ 12/12/2014 12:41:53 PM
RE: C++ compiler Posted by Pete Sass @ 12/13/2014 5:29:47 PM
RE: C++ compiler Posted by Tony Vignone @ 12/13/2014 8:27:53 PM
RE: C++ compiler Posted by Chuanbing Chen @ 12/14/2014 3:44:09 AM
RE: C++ compiler Posted by Mike Yearwood @ 12/15/2014 4:02:35 PM
RE: C++ compiler Posted by Tony Vignone @ 12/16/2014 2:10:42 PM
RE: C++ compiler Posted by Mike Yearwood @ 12/16/2014 6:00:18 PM
RE: C++ compiler Posted by Tony Vignone @ 12/16/2014 7:37:14 PM
RE: C++ compiler Posted by Pete Sass @ 12/17/2014 3:27:15 AM
RE: C++ compiler Posted by Mike Yearwood @ 12/17/2014 3:50:23 PM
RE: C++ compiler Posted by Pete Sass @ 12/17/2014 6:09:24 PM
RE: C++ compiler Posted by Mike Yearwood @ 12/18/2014 3:22:37 PM
RE: C++ compiler Posted by Pete Sass @ 12/18/2014 4:55:58 PM
RE: C++ compiler Posted by Mike Yearwood @ 12/18/2014 7:16:44 PM
RE: C++ compiler Posted by Pete Sass @ 12/18/2014 7:53:51 PM
RE: C++ compiler Posted by Chuanbing Chen @ 12/19/2014 12:48:30 AM
RE: C++ compiler Posted by Pete Sass @ 12/19/2014 11:57:43 PM
RE: C++ compiler Posted by Mike Gagnon @ 12/20/2014 2:09:13 AM
RE: C++ compiler Posted by Pete Sass @ 12/20/2014 3:18:09 PM
RE: C++ compiler Posted by Vilhelm-Ion Praisach @ 12/20/2014 6:53:41 PM
RE: C++ compiler Posted by Pete Sass @ 12/20/2014 8:25:14 PM
RE: C++ compiler Posted by Vilhelm-Ion Praisach @ 12/20/2014 9:18:10 PM
RE: C++ compiler Posted by Mike Yearwood @ 12/22/2014 3:01:11 PM
RE: C++ compiler Posted by Pete Sass @ 12/22/2014 3:57:28 PM
RE: C++ compiler Posted by Vilhelm-Ion Praisach @ 12/22/2014 5:54:52 PM
RE: C++ compiler Posted by Mike Yearwood @ 12/22/2014 9:38:06 PM
RE: C++ compiler Posted by Chuanbing Chen @ 12/23/2014 1:03:49 AM
RE: C++ compiler Posted by Mike Yearwood @ 12/22/2014 3:42:43 PM