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: 416008 # Views: 54 # Ratings: 0
Version: Visual FoxPro 9 SP2 Category: 3rd Party Software
Date: Thursday, December 18, 2014 4:55:58 PM         
   


> >
> >
> >
> > Hi Mike,
> >
> > Sounds to me like picking several slow items out of hundreds of good things about the Microsoft C++ compiler
> > engine is like throwing the baby away with the bath water!
> > However, this is every developers choice to decide. - lol
> >
> > Since the fault sits with the Microsoft C++ Compiler engine maybe a call to good old Bill would help.
> >
> > In the mean time I continue to use Microsoft C++ version 10 for some desktop applications and C# for
> > web although there are definitely some things in VFP I would much rather work with.
> > In the past 2 years I have been forced into C++ and C# development as many of my clients now demand a
> > current and fully supported language.
> >
> > Unfortunately, with most of my application upgrades coming down off of a deployment server and up in northern
> > Canada we have very slow Internet download speeds . . . we are still concerned about EXE sizes. I am sure there
> > are a lot of others in 3rd world countries and remote location operating on old T1 carriers or worse that are
> > also concerned about EXE sizes.
> >
> >
> > On the topic of compilers . . .
> > Don't get me wrong, I totally agree that; "optimization is also about changing poorly written code into faster code".
> > Optimization is also about shrinking the EXE size; by removing unneeded/uncalled dead code, removing duplicate code,
> > tokenization of common calls, etc. This by the nature of the beast will shrink the EXE and impart a speed improvement
> > across the entire application. Smaller memory footprint, less memory addressing to handle, no reads to the disk for
> > required DLL runtime routines that are not currently in memory, etc.
> >
> >
> > REAL WORLD TEST
> > Interestingly enough, I did one more test using a native VFP created EXE versus a VFP C++ created EXE using
> > the Microsoft C++ compiler engine.
> >
> > In this test I performed a process loop to run through 6 millions records with an inside loop to process
> > 6 character fields filled with unique 10 character text strings.
> > I introduced no indexes and performed a 100% sequential process of all 6 million records. I performed the
> > test search on the last record value in field number 3. That means that the unique match would be found
> > after looking for a match on 6M records X 3 as each field was processed one field at a time.
> > So in this test 18 million string comparisons were done involving and outer and inner process loop.
> >
> > Interesting enough here are the results and this is a true test as I rebooted my computer and ran the
> > VFP test then rebooted my computer and performed the C++ test to 100% ensure nothing cached.
> >
> >
> > VFP NATIVE COMPILED EXE TEST RUN
> >
> >
> >
> > C++ TEST RUN
> >
> >
> >
> > Of interest here on the above testing the C++ compiler performed the search 4 seconds faster
> > or around 9% faster.
> >
> > I present these test results for 2 reasons.
> > 1. You simply cannot pick one test result based upon a process loop that does nothing inside it.
> > If one chooses to measure the worth on a compiler based upon this kind of test well I guess they
> > can do as they wish.
> > 2. When you get into a 18 million loop process to obtain a meaningful time measurement, I think that
> > bringing speed differences into the mix at this point is meaningless.
> >
> > I 100% believe that to conclude . . .
> > "If the simple loop is not fast, then it stands to reason other things are not going to be fast."
> > is a generalized opinion statement and everyone is entitled to their own option.
> >
> >
> > Anyways, I am not going to debate the pros and cons of other compilers as the entire subject is relative to what
> > a developers needs to do as they try to balance product needs, speed needs, development time and cost.
> >
> >
> > Pete "the IceMan", from the Great White North of Canada.
> > www.marathongriffincomputers.com
>
> I care about EXE size. I've long been a proponent of single or few classes per classlib and single UDF per prg. That is intended to increase re-use and reduce un-needed things in the exe. It also increases speed. You're missing my point. How does VFP do an empty loop faster than C++? I was convinced C++ would regularly beat VFP in every task - because VFP is a layer removed from C++.
>
> 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,


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

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