See for yourself:
http://mywebpages.comcast.net/march...enchmark_01.htm
Jack
Dear allI have made a program using Visual C++, and i get the exe program.Now, i want to give the ex...
By mahmoudouf
Okay, here goes :)I've been burying some hours trying to get an existing C dll (using __cdeclcalling...
By theunprofessional
When I try to sort my combo box I get the following error."Cannot sort a ComboBox that has a DataSou...
By raj
hi all i m doing aproject i visual C++ on image processing. i wan to extract the r g b colorof the ...
By vinnu
hi please help me to find the color of an image . i am doing a project on image processing . iam usi...
By vinnu
Hello!!In the Toolbox I have now two controls with identical name despite havingnot added the contro...
By tony
Hello! Good Site! Thanks you! itorczhlwzclg...
By ibejrfypnr
Hello all,I'm a beginner of COM programming, I have a exercise, but got a compileerror withComFortun...
By awin, 1 Comments
Hi All,In my VC7 application, I want to read particular binary file from CDimage. But that binary fi...
By rachit_goyal_gmail_com, 2 Comments
I am trying to write programs in C in a text editor and run them on a command line but I am having t...
By matt, 1 Comments
We write lots of cross platform code at my company. To facilitatethis, class declarations are handle...
By geoffrey, 1 Comments
Hi group,when using unmanaged class with my managed app, I've seen errors whenincluding (for example...
By nicolas_hilaire_motorola_com, 3 Comments
I am not very fluent with computers, but I just got a new system withWin XP Pro x64 and it works gre...
By joejrk, 1 Comments
HI,I am converting VC++ 6.0 to .NET 2003. But I am getting linker error.Error:MyApplication fatal er...
By durga, 1 Comments
Hello,Until 6 years ago I was a C++ programmer. The last 6 years I've donesomething else than comput...
By bas, 4 Comments
Marchel wrote:
> For a long time I was a gib fan of Borland C++ Builder with VCL
> framework and never gave a second look in Microsoft products since
> I've seen MFC. Anyway, recently Borland decided out of the blue to
> abandon it's C++ Builder and I decided to give a look into the .NET
> C++ and .NET C# products. After briefly playing with them I put them
> to test against each other in some floating point tasks. The outcome
> might surprise you. It certainly surprised me !
> See for yourself:
> http://mywebpages.comcast.net/march...enchmark_01.htm
R:\>cl -O2 -EHs -Op fpbench1.cpp
Microsoft (R) 32-bit C/C++ Optimizing Compiler Version 13.10.3077 for 80x86
Copyright (C) Microsoft Corporation 1984-2002. All rights reserved.
fpbench1.cpp
Microsoft (R) Incremental Linker Version 7.10.3077
Copyright (C) Microsoft Corporation. All rights reserved.
/out:fpbench1.exe
fpbench1.obj
R:\>cl -O2 -EHs -Op fpbench2.cpp
Microsoft (R) 32-bit C/C++ Optimizing Compiler Version 13.10.3077 for 80x86
Copyright (C) Microsoft Corporation 1984-2002. All rights reserved.
fpbench2.cpp
Microsoft (R) Incremental Linker Version 7.10.3077
Copyright (C) Microsoft Corporation. All rights reserved.
/out:fpbench2.exe
fpbench2.obj
R:\>fpbench1
10000000 3.1415927035898 0.250
20000000 3.1415926785905 0.500
30000000 3.1415926702568 0.735
40000000 3.1415926660896 0.984
50000000 3.1415926635893 1.250
60000000 3.1415926619226 1.485
70000000 3.1415926607317 1.734
80000000 3.1415926598387 1.984
90000000 3.1415926591444 2.235
R:\>fpbench2
10000000 3.1415927035898 0.250
20000000 3.1415926785905 0.500
30000000 3.1415926702568 0.750
40000000 3.1415926660896 1.000
50000000 3.1415926635893 1.234
60000000 3.1415926619226 1.500
70000000 3.1415926607317 1.735
80000000 3.1415926598387 2.000
90000000 3.1415926591444 2.250
This code appears to be very sensitive to the -Op "Improve floating point
consistency" option. In fact, when I compiled your two samples without -Op,
I got times of 0.000 reported for every case!
-cd
carldanielvcmvp | Mon, 31 Dec 2007 14:51:00 GMT |
Marchel wrote:
> See for yourself:
> http://mywebpages.comcast.net/march...enchmark_01.htm
Very interesting! But there are far more variables in choice of tools
than raw speed. Most Windows applications are not number-crunching but
spend all their time waiting for the user to do something.
Perhaps you should consider other features such as ease of use,
portability, etc. I'm not claiming that Borland would necessarily do
better - I just think your tests need a wider scope. And let's not
forget deterministic cleanup - vital for resources other than memory
IMV, and often memory, too.
It's a great pity that Borland are ditching the VCL. It has had years
to mature into an excellent library, whereas the .NET library is still,
IMHO, in it's infancy. How is old Anders these days, anyway?
Arnold the Aardvark
arnoldtheaardvark | Mon, 31 Dec 2007 14:52:00 GMT |
"Arnold the Aardvark" <no...way.com> wrote in message news:c0ogee$5i$1$8302bc10...news.demon.co.uk...
> Very interesting! But there are far more variables in choice of tools
> than raw speed. Most Windows applications are not number-crunching but
> spend all their time waiting for the user to do something.
> Perhaps you should consider other features such as ease of use,
> portability, etc. I'm not claiming that Borland would necessarily do
> better - I just think your tests need a wider scope. And let's not
> forget deterministic cleanup - vital for resources other than memory
> IMV, and often memory, too.
> It's a great pity that Borland are ditching the VCL. It has had years
> to mature into an excellent library, whereas the .NET library is still,
> IMHO, in it's infancy. How is old Anders these days, anyway?
>
> Arnold the Aardvark
I did not intended to test anything else, but speed. I agree with you, that there are many other resons to choose
particular language. In my personal experience, most of the engineers choose BASIC for small projects. The choice of the
particular language for ocassional programmers is often driven by their personal basic and very limited contact with the
programming world. I did the test mostly for myself but wanted to share my experience with others. In my case, you can
say, I have speed obsession :-)
JM
marchel | Mon, 31 Dec 2007 14:53:00 GMT |
I normally don't run compiler from command line. Remeber, that this test is intended is for ocassional programmer that
is using IDE and is not familiar to all the internal "secrets" of the compiler. Quite frankly, lot's of prople who
ocassionally program, have no idea what "quad word" or "C calling convention" etc means and how particular settings they
relate to the peformance of the final product. IDE has a clear option to choose either "Debug" or "Release" version and
under release version it has "optimized for speed" setting. That is all one should need to know. If Microsoft compiler
has some other secrets beyond that, that is too bad for Microsoft.
The option -Op you mentioned is impossible to be changed in the standard version of the package (at least in IDE). It is
grayed out. Most of the occasional users of the C++ package don't have higher versions of the compiler simply because
such versions are too expensive and the cost is not justified for home or light use.
In you setting without -Op there must be something wrong with the clock measurement in the program. It is simply
impossible on a today PC even overclocked to 4GHZ to execute 4 floating point double size additions and two floting
point double size divisions 90,000,000 times under 0.001 second. That would make your PC some kind of supercomputer.
JM
marchel | Mon, 31 Dec 2007 14:54:00 GMT |
Marchel wrote:
> The option -Op you mentioned is impossible to be changed in the
> standard version of the package (at least in IDE). It is grayed out.
> Most of the occasional users of the C++ package don't have higher
> versions of the compiler simply because such versions are too
> expensive and the cost is not justified for home or light use.
You're doing these tests with the Standard Version? That's hardly a
relevant test for doing any kind of performance benchmarking, since that
compiler has no optimizer whatsoever, and all optimizer options specified in
the IDE or command line are simply ignored.
> In you setting without -Op there must be something wrong with the
> clock measurement in the program. It is simply impossible on a today
> PC even overclocked to 4GHZ to execute 4 floating point double size
> additions and two floting point double size divisions 90,000,000
> times under 0.001 second. That would make your PC some kind of
> supercomputer.
Actually, I think it means there's something wrong with the generated code
with -O2 but not -Op. I haven't had a chance to really look into it - the
benchmark cleary took about the same time as without -Op, so I'm guessing
that the calculation of elapsed time somehow got bunged up.
-cd
carldanielvcmvp | Mon, 31 Dec 2007 14:55:00 GMT |
Comparing against standard version of VC++ compiler is useless because it
has no meaningful optimizations.
"Marchel" <marchel...comcast.net> wrote in message
news:uYKdnYC8FuVtf7Ld4p2dnA...comcast.com...
> I normally don't run compiler from command line. Remeber, that this test
is intended is for ocassional programmer that
> is using IDE and is not familiar to all the internal "secrets" of the
compiler. Quite frankly, lot's of prople who
> ocassionally program, have no idea what "quad word" or "C calling
convention" etc means and how particular settings they
> relate to the peformance of the final product. IDE has a clear option to
choose either "Debug" or "Release" version and
> under release version it has "optimized for speed" setting. That is all
one should need to know. If Microsoft compiler
> has some other secrets beyond that, that is too bad for Microsoft.
> The option -Op you mentioned is impossible to be changed in the standard
version of the package (at least in IDE). It is
> grayed out. Most of the occasional users of the C++ package don't have
higher versions of the compiler simply because
> such versions are too expensive and the cost is not justified for home or
light use.
> In you setting without -Op there must be something wrong with the clock
measurement in the program. It is simply
> impossible on a today PC even overclocked to 4GHZ to execute 4 floating
point double size additions and two floting
> point double size divisions 90,000,000 times under 0.001 second. That
would make your PC some kind of supercomputer.
> JM
tester | Mon, 31 Dec 2007 14:56:00 GMT |
>
> The option -Op you mentioned is impossible to be changed in the standard version of the package (at least in IDE). It is
> grayed out. Most of the occasional users of the C++ package don't have higher versions of the compiler simply because
> such versions are too expensive and the cost is not justified for home or light use.
The standard version has no optimizer as Carl Daniel pointed out and
Microsoft point out http://msdn.microsoft.com/visualc/h...y/choosing.aspx
You should ammend your benchmark results to say that you used the
Standard version.
--
sashan
http://www.cs.auckland.ac.nz/~sgov008/
sashan | Mon, 31 Dec 2007 14:57:00 GMT |
> You're doing these tests with the Standard Version? That's hardly a
> relevant test for doing any kind of performance benchmarking, since that
> compiler has no optimizer whatsoever, and all optimizer options specified in
> the IDE or command line are simply ignored.
As I said, it's too bad for Microsoft. I'm not a professional programmer and I cannot, as many engineers and scientists
in similar to mine position, justify cost of more expensive versions of the software. I mentioned that clearly in the
test page.
Consider this for example:
(www.borland.com)
Borland C++ Builder 6.0 (Personal) $69
Borland C++ Builder 6.0 (Professional) $999
Borland C++ Builder 6.0 (Enterprise) $2999
(www.microsoft.com)
Microsoft Visual C++ .NET (Standard) $109
Microsoft Visual C++ .NET (Professional) $1079
In fact you can download complete, full version of the Borland compiler (without IDE) for free. Also you can get open
source (gcc) C++ windows compiler freely. This make the price span even more ridiculous. I'm refusing to buy expensive
versions of the software for occasional programming sessions. My money making job has nothing to do with computer
programming.
> > In you setting without -Op there must be something wrong with the
> > clock measurement in the program. It is simply impossible on a today
> > PC even overclocked to 4GHZ to execute 4 floating point double size
> > additions and two floting point double size divisions 90,000,000
> > times under 0.001 second. That would make your PC some kind of
> > supercomputer.
> Actually, I think it means there's something wrong with the generated code
> with -O2 but not -Op. I haven't had a chance to really look into it - the
> benchmark cleary took about the same time as without -Op, so I'm guessing
> that the calculation of elapsed time somehow got bunged up.
And that makes sense. On my Athlon XP 1800 + (similarly to your timing) 90,000,000 loops of four additions and two
divisions took roughly 2 seconds. For the sake of simplicity assuming that addition and division takes the same time, it
means six general math operations per loop, which means about 540,000,000 math operations in two seconds or 270,000,000
operations per second. Athlon XP 1800+ runs at 1533 MHz. So in fact it made each operation in about 5.7 clock cycle
which is pretty good. You can't massively improve this. That is why the differences between Borland, C# and VC++ were
not that big. All those compilers are in fact pretty good.
> -cd
JM
marchel | Mon, 31 Dec 2007 14:58:00 GMT |
To answer your reservations:
I seriously doubt that optimization will help in this particular test. The floating point math is done in FPU by
hardware. It will probably help with controversy of running the different style of coding almost twice as fast as the
other style of coding which I still consider ridiculous. I dont own a professional version of any compilers that I
tested.
I did mentioned, that the versions of all three compilers used in the test is the most stripped down, cheapest version
available on the market. It is mentioned in the section "2. Operating system and languages choice." of my test.
JM
marchel | Mon, 31 Dec 2007 14:59:00 GMT |
Marchel wrote:
> As I said, it's too bad for Microsoft. I'm not a professional programmer
> and I cannot, as many engineers and scientists in similar to mine
> position, justify cost of more expensive versions of the software. I
> mentioned that clearly in the test page.
While I completely agree that it is unfortunate an optimizing version of
Visual C++ is not freely available, the conclusions drawn in the writeup do
not reflect that problem at all.
For example, the discussion on "Microsoft Visual C++ problem" is solely
demonstrable in non-optimized debug builds. The debug compiler allocates
variables when it sees them, which does make a difference in this case. The
optimizer, on the other hand, does perform rather standard life time
analyses which result in exactly the same code generated for both.
In the end, the writeup makes the conclusion, "And the looser (sic) is ...
Microsoft Visual C++ 7.0 (Win32 MFC version)." FYI, every version of Visual
C++ includes MFC. Because the conclusion is based on a non-optimizing
compiler, some mention of that fact is necessary. In reality, if Visual C#
is rated higher, it should be suspicious that Visual C++ rated so low for
two reasons: (1) Visual C++ has a far more sophisticated optimizer and thus
memory allocation issues are the only class that would possibly make C#
faster than a native C++ program, and (2) Visual C++ can produce the same
MSIL that gets Just-in-Time compiled as Visual C#, thus they both would rank
at the same level.
The good news is that in the future, we are including the optimizing
compiler in all SKUs. This should address the concern of availability.
I hope this information helps!
--
Brandon Bray http://blogs.msdn.com/branbray/
This posting is provided AS IS with no warranties, and confers no rights.
brandonbraymsft | Mon, 31 Dec 2007 15:00:00 GMT |
> While I completely agree that it is unfortunate an optimizing version of
> Visual C++ is not freely available, the conclusions drawn in the writeup do
> not reflect that problem at all.
> For example, the discussion on "Microsoft Visual C++ problem" is solely
> demonstrable in non-optimized debug builds. The debug compiler allocates
> variables when it sees them, which does make a difference in this case. The
> optimizer, on the other hand, does perform rather standard life time
> analyses which result in exactly the same code generated for both.
I agree, that this is probably the case. It is still dissapointitng that competitor versions of C++ and even Microsoft
own C# Standard version does not behave so badly depending on the style of writing code. For me it was a dissapointment.
I understand, that you are trying to "excuse" Microsoft, but the fact remains, that the stnadard version is inferior
comparing to the competition. Since large majority of the users will buy standard version, this test will help them to
make their mind and clearly understand the restrictions they are getting into.
> In the end, the writeup makes the conclusion, "And the looser (sic) is ...
> Microsoft Visual C++ 7.0 (Win32 MFC version)." FYI, every version of Visual
> C++ includes MFC
This is unfortunate choice of words on my side. By MFC I meant the old "style" that produces fully executable code
capable of running on every version of Windows. .NET version of Visual C++ produces intermediate code that requires JIT
to be installed. I was under impression, that these are not the same versions of the code. You can see that in test # 3
in which Visual C++ .NET console version outrun by several precent the Visual C++ Win32 console version of the same
code. Both version were produced using exactly the same issue of Visual Studio.
>. Because the conclusion is based on a non-optimizing
> compiler, some mention of that fact is necessary. In reality, if Visual C#
> is rated higher, it should be suspicious that Visual C++ rated so low for
> two reasons: (1) Visual C++ has a far more sophisticated optimizer and thus
> memory allocation issues are the only class that would possibly make C#
> faster than a native C++ program,
I disagree. The test # 2, in which Visual C++ simply stinks, all you use, is library functions. It seems, that C# math
library is much better written than C++. All three tests do not use any extensive memeory allocation that would change
test outcome significantly. I avoided on purpose allocating memory. Visual C++ Win32 console version runs really slow
comparing to C# (and presumably .NET C++ which should equal C#). I suspect, that math run time libraries used with
Win32 console are not that good as the ones in the .NET Math class. Borland is even worse here. How much "optimization"
you can do here with optimizing compiler if you still are going to use bad libraries ?
> and (2) Visual C++ can produce the same
> MSIL that gets Just-in-Time compiled as Visual C#, thus they both would rank
> at the same level.
And they do when you actually use .NET console application in Visual C++. If you try to use Win32 console application,
Visual C++ losses to C# at least in it's standard version. That is exactly what my test shows. I also mentioned on the
web page, that Microsoft Visual C++ .NET is one of the winners. Only the Win32 version in its standard edition is
considered by me to be a looser. For some people this distinction is important. Corporation that I work for has PC
computers equipeed with Win2000 version of Windows that does not has .NET installed. Therefore I cannot write programs
that use .NET version of the languages and I'm left to choose between Borland C++ Builder and Visual C++ Win32.
> The good news is that in the future, we are including the optimizing
> compiler in all SKUs. This should address the concern of availability.
> I hope this info rmation helps!
Excellent move !
> --
> Brandon Bray http://blogs.msdn.com/branbray/
> This posting is provided AS IS with no warranties, and confers no rights.
JM
marchel | Mon, 31 Dec 2007 15:01:00 GMT |
Marchel wrote:
> To answer your reservations:
> I seriously doubt that optimization will help in this particular
> test.
And yet the test results that I posted prove just that case: when compiled
with the optimizing compiler, your two flavors of code have nearly identical
performance. I didn't check myself, but I believe Brandon Bray indicated
that they in fact generate identical machine code. The conclusions you
present on the web site are misleading at best, and highly suspect in any
case. If nothing else, I see no justification for the leap from "bechmark 2
was faster than benchmark 1" to "I'll do all my coding in this style" based
on a single data point of un-optimized code.
-cd
carldanielvcmvp | Mon, 31 Dec 2007 15:02:00 GMT |
"Carl Daniel [VC++ MVP]" <cpdaniel_remove_this_and_nospam...mvps.org.nospam> wrote in message news:<#gkYL1E9DHA.2924...tk2msftngp13.phx.gbl>...
> Marchel wrote:
> > To answer your reservations:
> > I seriously doubt that optimization will help in this particular
> > test.
> And yet the test results that I posted prove just that case: when compiled
> with the optimizing compiler, your two flavors of code have nearly identical
> performance.
And I don't dispute that. I belive that the controversy of treating
two different styles of programming with almost double time penalty
for one style over the other is an issue of non optimized code. I
consider that ridiculous but that is beyond the issue here. Keep in
mind, that once I realized the problem, for the comaprison tests I was
using coding style that generates the faster code. I still challenge
the opinion that the optimization of my very simplistic code would
change MS VC++ in any significant way to help in any meaningfull way
the outcome of the tests against C# or BCB. VC++ was especially bad in
test #2 where it lost by a large margin on the run time library math
functions. Could you explain, what makes VC++ to execute squrare root
function more than twice as long as C# ? This function is already
compiled in DLL library and optimizer would do squat here. It maybe
that optimization would put VC++ on a better place in test # 3, but in
that test the difference between the best Borland and the worst VC++
was within 10% which is not a big deal.
> I didn't check myself, but I believe Brandon Bray indicated
> that they in fact generate identical machine code. The conclusions you
> present on the web site are misleading at best, and highly suspect in any
> case. If nothing else, I see no justification for the leap from "bechmark 2
> was faster than benchmark 1" to "I'll do all my coding in this style" based
> on a single data point of un-optimized code.
Absolutely not misleading. Majority of occasional programmers will buy
Standard version of the software. The enigmatic "non optimized
compiler" is not very clear for those buyers, what they are getting
into. Before I run those tests I would never suspect that it would
mean almost doubling execution time if the programmer was using old
"C" type coding style where all the declarations are put at the top of
the function. I consider my test to be a very good warning for those
people who like me are yet unaware of it. I would probably skip the
purachase of the product if I knew beforehand that it behaves like
this. My experience with Borland was such, that the Standard version
(which is called in Borland - Personal) was very decent but lacked
many optimizing tools, components available in higher versions and had
a restrictive license. But Borland compiler never behaved so badly
depending on coding style. Niether does Microsoft C# Standard for that
matter. You guys are lucky to have optimizing version of the compiler
and that's good for you. But there are only handful of people ready to
invest $1000 into the software used sparringly. For those folks my
results are not misleading at all. They are in fact perfect warning to
look into some other competitor products and competitive langugaes
such as Microsoft own C# for example.
> -cd
JM
jack | Mon, 31 Dec 2007 15:03:00 GMT |
> > The option -Op you mentioned is impossible to be changed in the
> > standard version of the package (at least in IDE). It is grayed out.
> > Most of the occasional users of the C++ package don't have higher
> > versions of the compiler simply because such versions are too
> > expensive and the cost is not justified for home or light use.
> You're doing these tests with the Standard Version? That's hardly a
> relevant test for doing any kind of performance benchmarking, since that
> compiler has no optimizer whatsoever, and all optimizer options specified
in
> the IDE or command line are simply ignored.
Someone have the professional version to repeat this test?
I am not really suprised in this, since one day in the future .NET code will
surpass conventional exe code because of the improved JIT compilers
optimized for the latest processor, while the conventional exe gets frozen
since the latest release version at the moment of the compilaion and service
pack of the C++.
It suprises me that it might already be the case today.
I think you will find far more "Standard" versions of VC ++ than
professional versions in the scientific area, so I guess this test is
interesting for scientists that have limited resources. "Standard" C#
clearly outperforms "Standard" C++ in this test.
Standard C# comparing with "Professional" C++ would be the same as comparing
speed of a Porsch to a normal priced car.
hbb | Mon, 31 Dec 2007 15:04:00 GMT |
Jack wrote:
> Absolutely not misleading. Majority of occasional programmers will buy
> Standard version of the software. The enigmatic "non optimized
> compiler" is not very clear for those buyers, what they are getting
> into. Before I run those tests I would never suspect that it would
> mean almost doubling execution time if the programmer was using old
> "C" type coding style where all the declarations are put at the top of
> the function. I consider my test to be a very good warning for those
> people who like me are yet unaware of it. I would probably skip the
> purachase of the product if I knew beforehand that it behaves like
> this.
Your conclusions:
<quote
Microsoft Visual C++ in the old MFC version is simply a piece of junk. It
performed poorly in most of the tests.
...
Microsoft Visual C++ 7.0 (Win32 MFC version).
It was unexpected to see, how this software, considered by many to be
professional standard of Windows programming, failed to perform well in most
of the tests that I run.
</quote
First, there is no such product. The average reader, unless they study your
site thoroughly is going to read this as "Visual C++" (in general), not
"Visual C++ 7.0 Standard Edition targeting Win32 executables".
Second, the product you tested (not identified here, but only in a small
table on a distant page) is not considered to be the professional standard
of Windows programming by anyone at all. I understand that you're
disappointed in the performance of Visual C++ Standard Edition in your
tests, but this "conclusion" is nothing more than ignorant Microsoft
bashing.
> My experience with Borland was such, that the Standard version
> (which is called in Borland - Personal) was very decent but lacked
> many optimizing tools, components available in higher versions and had
> a restrictive license. But Borland compiler never behaved so badly
> depending on coding style. Niether does Microsoft C# Standard for that
> matter. You guys are lucky to have optimizing version of the compiler
> and that's good for you. But there are only handful of people ready to
> invest $1000 into the software used sparringly. For those folks my
> results are not misleading at all. They are in fact perfect warning to
> look into some other competitor products and competitive langugaes
> such as Microsoft own C# for example.
That may be. On the other hand, I wouldn't expect the casual programmer to
be terribly concerned about performance of their code. Most likely, they're
going to write such badly organized code that any improvement in compiler
optimization will be totally swamped by poor algorithm choices, poor data
structure choices, and so on.
There's a valid conclusion that your article can reach: If you're
interested in performance, don't use Visual C++ Standard Edition to generate
Win32 code. That's just a bit less inflamatory than saying it's "a piece of
junk", which it is not.
-cd
carldanielvcmvp | Mon, 31 Dec 2007 15:05:00 GMT |
His test was intended for Scientists and Engineers!
Not the typical database and Web programmer!
> That may be. On the other hand, I wouldn't expect the casual programmer
to
> be terribly concerned about performance of their code. Most likely,
they're
> going to write such badly organized code that any improvement in compiler
> optimization will be totally swamped by poor algorithm choices, poor data
> structure choices, and so on.
I doubt that. Many scientific students will try to get the best performance
out of their code.
And they don't have the money to buy the professional version.
> There's a valid conclusion that your article can reach: If you're
> interested in performance, don't use Visual C++ Standard Edition to
generate
> Win32 code. That's just a bit less inflamatory than saying it's "a piece
of
> junk", which it is not.
I agree, it should not be classified as junk since it probably can do other
things C# would lose at.
But he could also give the following conclusion:
"For Scientists and Engineers on a tight budget, C# is clearly the winner in
this test".
Then again, we have now VC ++ 2003, this might outperform the C# again, he
compared this to the 2002 version. .
hbb | Mon, 31 Dec 2007 15:06:00 GMT |
<Olaf.Baeyens...skyscan.be> skrev i meddelandet
news:4030e8ce$0$325$ba620e4c...news.skynet.be...
> His test was intended for Scientists and Engineers!
> Not the typical database and Web programmer!
> > That may be. On the other hand, I wouldn't expect the casual programmer
> to
> > be terribly concerned about performance of their code. Most likely,
> they're
> > going to write such badly organized code that any improvement in
compiler
> > optimization will be totally swamped by poor algorithm choices, poor
data
> > structure choices, and so on.
> I doubt that. Many scientific students will try to get the best
performance
> out of their code.
> And they don't have the money to buy the professional version.
And they don't have to!
I you really are a student, you can often get an Academic License, which
gives you the Professional version for about the same price as the Standard
Edition!
The Standard Edition is good for learning programming, as it runs in debug
mode all the time - which is just fine for that purpose.
You shouldn't benchmark it though - I have programs that run 100 to 1000
times slower in debug mode...
> > There's a valid conclusion that your article can reach: If you're
> > interested in performance, don't use Visual C++ Standard Edition to
> generate
> > Win32 code. That's just a bit less inflamatory than saying it's "a
piece
> of
> > junk", which it is not.
> I agree, it should not be classified as junk since it probably can do
other
> things C# would lose at.
> But he could also give the following conclusion:
> "For Scientists and Engineers on a tight budget, C# is clearly the winner
in
> this test".
Yes, "in this test". :-)
Bo Persson
bopersson | Mon, 31 Dec 2007 15:07:00 GMT |
<Olaf.Baeyens...skyscan.be> wrote in message news:4030e222$0$7033$ba620e4c...news.skynet.be...
> Someone have the professional version to repeat this test?
> I am not really suprised in this, since one day in the future .NET code will
> surpass conventional exe code because of the improved JIT compilers
> optimized for the latest processor, while the conventional exe gets frozen
> since the latest release version at the moment of the compilaion and service
> pack of the C++.
This is excellent suggestion. I'm really interesting to see if optimizer
can really improve as much as many here seem to belive. I listed the code on the
web page, so it is a matter of just copy and paste, should not take more than
a few minutes. To make things "equal" I'm looking for somebody, who has
at least VC++ Professional and C# and could run at least those two and list the
timing ratio between the two.
JM
marchel | Mon, 31 Dec 2007 15:08:00 GMT |
"Bo Persson" <bop...gmb.dk> wrote in message news:esOwGsK9DHA.3404...TK2MSFTNGP09.phx.gbl...
>...
> The Standard Edition is good for learning programming, as it runs in debug
> mode all the time - which is just fine for that purpose.
I'm not sure what exactly you mean by this,. The same code compiled in
stanadard version as "debug" runs about twice as slow as the same code
compiled with "release" setting, so clearly there is a difference.
If your statement would be true, changing this setting would have no effect
whatsoever or the setting would not be even made available, wouldn't be ?
Also, if you are right, why is it, that fully optimized code compiled with Borland
or with open source gcc runs roughly the same time as VC++ ? I have
hard time to belive that VC++ can run in debug mode complete loop that
includes four double floating point additions and two double floating point
divisions on top of loop service in less than 35 clock cycles.
> > But he could also give the following conclusion:
> > "For Scientists and Engineers on a tight budget, C# is clearly the winner
> in
> > this test".
> Yes, "in this test". :-)
I tell you what. Why don't you just repeat the test # 1 with "fully" optimized code
and post it here to let all of us know, how many clock cycles it took to run one loop
after you made sure it runs in a "release" mode and with "full optimization" ?
Maybe you can prove something in a scientific - engineering way :-)
> Bo Persson
JM
marchel | Mon, 31 Dec 2007 15:09:00 GMT |
Bo Persson wrote:
> The Standard Edition is good for learning programming, as it runs in
> debug mode all the time - which is just fine for that purpose.
This is not true. There is a difference between Debug and Release builds
even under the Standard Edition (different runtime libraries, most notably).
-cd
carldanielvcmvp | Mon, 31 Dec 2007 15:10:00 GMT |
You might want to raise the priority of your test apps:
Process.GetCurrentProcess().PriorityClass = ProcessPriorityClass.RealTime;
Thread.CurrentThread.Priority = ThreadPriority.Highest;
SetPriorityClass( GetCurrentProcess(), REALTIME_PRIORITY_CLASS);
SetThreadPriority( GetCurrentThread(), THREAD_PRIORITY_TIME_CRITICAL);
Also note that DateTime/GetTickCount is not high-resolution enough for
precise timing. One should use
QueryPerformanceCounter and QueryPerformanceFrequency like so:
LARGE_INTEGER start={0};
LARGE_INTEGER end={0};
LARGE_INTEGER freq={0};
if(!QueryPerformanceFrequency(&freq))
return 0;
QueryPerformanceCounter(&start);
//time consuming operation
QueryPerformanceCounter(&end);
double elapsedTime = (end.QuadPart - start.QuadPart)*1.0f/freq.QuadPart;
One should also subtract the difference of QueryPerformanceCounter call
itself.
"Marchel" <marchel...comcast.net> wrote in message
news:46-dnYBOBe0my6zdRVn-gw...comcast.com...
> <Olaf.Baeyens...skyscan.be> wrote in message
news:4030e222$0$7033$ba620e4c...news.skynet.be...
> > Someone have the professional version to repeat this test?
> > I am not really suprised in this, since one day in the future .NET code
will
> > surpass conventional exe code because of the improved JIT compilers
> > optimized for the latest processor, while the conventional exe gets
frozen
> > since the latest release version at the moment of the compilaion and
service
> > pack of the C++.
> This is excellent suggestion. I'm really interesting to see if optimizer
> can really improve as much as many here seem to belive. I listed the code
on the
> web page, so it is a matter of just copy and paste, should not take more
than
> a few minutes. To make things "equal" I'm looking for somebody, who has
> at least VC++ Professional and C# and could run at least those two and
list the
> timing ratio between the two.
> JM
tester | Mon, 31 Dec 2007 15:11:00 GMT |
Marchel wrote:
> I agree, that this is probably the case. It is still dissapointitng that
> competitor versions of C++ and even Microsoft own C# Standard version
> does not behave so badly depending on the style of writing code. For me
> it was a dissapointment. I understand, that you are trying to "excuse"
> Microsoft, but the fact remains, that the stnadard version is inferior
> comparing to the competition. Since large majority of the users will buy
> standard version, this test will help them to make their mind and clearly
> understand the restrictions they are getting into.
I am certainly not trying to make excuses for the product. The observable
differences in the style are as expected and by design. That does not make
it inferior. When debugging an application, it is very important that the
compiler not muck with the code. That is why the compiler does exactly has a
difference between the two programming styles.
Your observation was strictly about debug behavior. The complaint was that
this lead to an inferior product. This is simply not a fair statement. The
entire discussion is summed up with "optimizing compilers are better than
non-optimizing compilers" no matter what the language is. No one will argue
with that. However, that is not what the writeup says. While you have
repeatedly said that you understand that, the feedback is simply that
reading the conclusions page alone or the page about problems with Visual
C++ does not even mention you are using a non-optimizing compiler.
The title of the writeup might better be titled as to what to expect with
free compilers.
> I disagree. The test # 2, in which Visual C++ simply stinks, all you use,
> is library functions. It seems, that C# math library is much better
> written than C++. All three tests do not use any extensive memeory
> allocation that would change test outcome significantly. I avoided on
> purpose allocating memory. Visual C++ Win32 console version runs really
> slow comparing to C# (and presumably .NET C++ which should equal C#). I
> suspect, that math run time libraries used with Win32 console are not
> that good as the ones in the .NET Math class. Borland is even worse here.
> How much "optimization" you can do here with optimizing compiler if you
> still are going to use bad libraries ?
Of course, saying that the math libraries in Visual C# are better than the
Visual C++ libraries is highly suspicious. If you really believe that, it
would be far more important to isolate the math library by itself and
benchmark that. As done, the information is highly inconclusive.
I really don't mean to be rude, but I see reports like this fairly
frequently and they're always misinformed. The math libraries that the C++
compiler uses are supplied by Intel and AMD and are highly optimized to the
hardware. If there was truly any competition, it would be a matter or
milliseconds in difference and certainly within a noise threshold.
> And they do when you actually use .NET console application in Visual C++.
> If you try to use Win32 console application, Visual C++ losses to C# at
> least in it's standard version.
Of course it does. The C# compiler doesn't do any optimization -- it relies
on the JIT compiler in the runtime. For C++, there isn't any JIT compiler to
optimize the code. Given that you're working with a non-optimizing compiler,
the result is completely expected.
The thread here started with the statement that the result of this study was
surprising. In reality, it is completely expected that a non-optimizing tool
set will fall behind an optimizing tool set.
On another note, Carl Daniel was studying a curious problem where the
optimizing compiler would print zero for the elapsed time. The problem was
that 'benchmark' is an algebraic function that does not manipulate global
memory. This allows the optimizer to move the call benchmark forward or
backwards. Thus, the two calls to GetTickCount were sequential (which
improves hot code paths, as the code is more likely to be in the instruction
cache). The solution is to make the outcome variable volatile.
double volatile outcome = benchmark(i);
Hope that helps!
--
Brandon Bray, Visual C++ Compiler http://blogs.msdn.com/branbray/
This posting is provided AS IS with no warranties, and confers no rights.
brandonbraymsft | Mon, 31 Dec 2007 15:12:00 GMT |
Marchel <marchel...comcast.net> wrote:
> "Bo Persson" <bop...gmb.dk> wrote in message news:esOwGsK9DHA.3404...TK2MSFTNGP09.phx.gbl...
> > ...
> > The Standard Edition is good for learning programming, as it runs in debug
> > mode all the time - which is just fine for that purpose.
> I'm not sure what exactly you mean by this,. The same code compiled in
> stanadard version as "debug" runs about twice as slow as the same code
> compiled with "release" setting, so clearly there is a difference.
> If your statement would be true, changing this setting would have no effect
> whatsoever or the setting would not be even made available, wouldn't be ?
Bo's statement might have simplified
things a little bit too much. There's
more differences between release and
debug builds than whether the optimizer
kicks in. For example, debug builds will
use the debug version of the RTL, which
is slower than the release version.
> [...]
> JM
Schobi
--
SpamTrap...gmx.de is never read
I'm Schobi at suespammers dot org
"Sometimes compilers are so much more reasonable than people."
Scott Meyers
hendrikschober | Mon, 31 Dec 2007 15:13:00 GMT |
"Brandon Bray [MSFT]" <branbray...online.microsoft.com> wrote in message news:<unrwaYP9DHA.1596...TK2MSFTNGP10.phx.gbl>...
> I am certainly not trying to make excuses for the product. The observable
> differences in the style are as expected and by design. That does not make
> it inferior.
I see your point. I guess, my dissapointement has more to do with the
fact, that I did not know prior to my tests, that Microsoft is
selling in fact different product under standard version. Because of
my prior experience with Borland I simply didn't expect that.
From the certain point of view it reminds me the same marketing
scheme of NVIDIA, which sold under the generic name of GeForce 4
two different chips with two different price points. The cheaper
version was actually renamed beefed up GeForce 2 chip, worse than the
older GeForce 3 chip. If one knew that, one could say, that it is not
the big deal, if you did not know that it was a dirty trick from the
certain point of view. Same by the way is now with the USB 2.0 High
speed and USB 2.0 full speed. How many people belive, that this
marketing scheme is crystal clear and fair ? I don't dispute, that the
information is out there, but many customers probably will buy the
product without knowing the fact.
> Of course, saying that the math libraries in Visual C# are better than the
> Visual C++ libraries is highly suspicious. If you really believe that, it
> would be far more important to isolate the math library by itself and
> benchmark that. As done, the information is highly inconclusive.
What is suspicious, is rather why C++ square root function in either
Borland or Microsoft version is two to three times slower that C# version
without any gain in accuracy. My concern about the libraries, it is
simply my guess about the cause. Since the code between various high math
functions in test # 2 is identical with the exception of library call,
then the major increase of C# advantage over C++ (either Borland or
Microsoft) for some of the functions can be only attributed to the
differences between the library function implementation. How otherwise
would you explain, that the arctan() test has very similar timing between
C++ and C# versions of the code, but when the single library call in the
code is changed from arctan() to exp() or sqrt(), suddenly C# executes
otherwise the same code two to three times faster than C++ with the same
accuracy ? What exactly changed in optimalization ? There maybe a very
good scientific explanation, that for example C++ libraries are more
stable at extreme exotic input etc., but as a occasional user I'm not
in a position to either prove it or really care about it. It is similar
to the famous Pnetium FDIV flaw, that affected mainly experts but for
everyday occasional programmers had no impact whatsoever (except FUD
of course :-) ).
I disagree also about approach. If my aprroach is to calculate
particular integral (as I'm doing in the test # 2), C# won in most cases
by a large margin over non optimized C++ by Microsoft and over
supposedly highly optimized C++ by Borland. As a end user I don't care
what is the exact cause of C++ being slower. All I care is to have my
program run as fast as it can. In any case either library was bad or
the information exchange mechanism between the library and program was
crippled or something else. You should not expect from the occasional
end user to make a scientific analysis why his program that is written
in a conventional, acceptable way is uderperforming on the theoretically
better platform. What is then better in that platform ? The occasional
user should be advised to run the platform that generates the fastest
code most of the time without tweaking.
For the expert your approach is absolutely right but it is not for
the target user of my test.
JM
jack | Mon, 31 Dec 2007 15:14:00 GMT |
Jack wrote:
> How many people belive, that this marketing scheme is crystal clear and
> fair ? I don't dispute, that the information is out there, but many
> customers probably will buy the product without knowing the fact.
This absolutely something worth complaining about. I've unfortunately had to
deal with too many customers who bought the Standard Edition not knowing
that the compiler was non-optimizing. This certainly makes your analysis
worth while, and demonstrates that Visual C++ isn't competitive at low price
points.
In fact, this is exactly the feedback that led to our decision to stop
building the non-optimizing compiler. In the next version of Visual C++
codenamed "Whidbey", we will only provide the optimizing compiler
Cheerio!
--
Brandon Bray, Visual C++ Compiler http://blogs.msdn.com/branbray/
This posting is provided AS IS with no warranties, and confers no rights.
brandonbraymsft | Mon, 31 Dec 2007 15:15:00 GMT |
> The good news is that in the future, we are including the optimizing
> compiler in all SKUs. This should address the concern of availability.
That IS good news - I don't think you've really got anything to worry about
with GNU (it's horrible and linux-based) but the fact that you can download
a Borland optimizing compiler AND debugger from Borland for free in UNDER 20
MB should worry you, currently.
I certainly hope reliability of the SDK's installer come top of the priority
list aswell. I don't know why but I've only got 28 files in my
SDK\v1.1\Include directory. There is one .cpp, one .def and the others are
..h and .idl files. There is no windows.h. Reinstalling windows, fixing the
disk, and reinstalling the SDK wouldn't make the header files reappear. I
phoned up Microsoft, but they wanted 185 to even attempt to start giving an
answer to my question. This doesn't bode well for the reputation of
Microsoft, certainly in my esteem anyway - and how many other people are
experiencing the same thing? Microsoft have long been successful due to two
main factors - commercial aggressiveness and technical excellence, but if
they're losing the edge on the latter to other outfits... I now therefore
not only prefer to use Borland, but have no other option.
I would definitely be interested to know if Microsoft have decided to do the
right thing and include an optimizer for free though. I mean it's mainly
businesses that spend the money on the pricey software anyway, and they are
going to buy the IDE no matter what not because they want the optimizer, but
because they want their staff to use the IDE to build applications as
quickly as possible. Keeping the hobbyist satisfied
> I hope this information helps!
> --
> Brandon Bray http://blogs.msdn.com/branbray/
> This posting is provided AS IS with no warranties, and confers no rights.
bonj | Mon, 31 Dec 2007 15:17:00 GMT |
The compiler might even be as clever as to simply *not do* some of the
calculations at all, since it knows the variables don't get used in a
meaningful way. That's why I think as close to real world test scenarios
with genuine program output are better. So you don't really know, I mean
that might be why it showed as doing it really fast, when in fact it was
just not doing it as it knew it didn't need to.
"Marchel" <marchel...comcast.net> wrote in message
news:EcOdnWvLAp2erq3dRVn-uw...comcast.com...
> > You're doing these tests with the Standard Version? That's hardly a
> > relevant test for doing any kind of performance benchmarking, since that
> > compiler has no optimizer whatsoever, and all optimizer options
specified in
> > the IDE or command line are simply ignored.
> As I said, it's too bad for Microsoft. I'm not a professional programmer
and I cannot, as many engineers and scientists
> in similar to mine position, justify cost of more expensive versions of
the software. I mentioned that clearly in the
> test page.
> Consider this for example:
> (www.borland.com)
> Borland C++ Builder 6.0 (Personal) $69
> Borland C++ Builder 6.0 (Professional) $999
> Borland C++ Builder 6.0 (Enterprise) $2999
> (www.microsoft.com)
> Microsoft Visual C++ .NET (Standard) $109
> Microsoft Visual C++ .NET (Professional) $1079
> In fact you can download complete, full version of the Borland compiler
(without IDE) for free. Also you can get open
> source (gcc) C++ windows compiler freely. This make the price span even
more ridiculous. I'm refusing to buy expensive
> versions of the software for occasional programming sessions. My money
making job has nothing to do with computer
> programming.
> > > In you setting without -Op there must be something wrong with the
> > > clock measurement in the program. It is simply impossible on a today
> > > PC even overclocked to 4GHZ to execute 4 floating point double size
> > > additions and two floting point double size divisions 90,000,000
> > > times under 0.001 second. That would make your PC some kind of
> > > supercomputer.
> > Actually, I think it means there's something wrong with the generated
code
> > with -O2 but not -Op. I haven't had a chance to really look into it -
the
> > benchmark cleary took about the same time as without -Op, so I'm
guessing
> > that the calculation of elapsed time somehow got bunged up.
> And that makes sense. On my Athlon XP 1800 + (similarly to your timing)
90,000,000 loops of four additions and two
> divisions took roughly 2 seconds. For the sake of simplicity assuming that
addition and division takes the same time, it
> means six general math operations per loop, which means about 540,000,000
math operations in two seconds or 270,000,000
> operations per second. Athlon XP 1800+ runs at 1533 MHz. So in fact it
made each operation in about 5.7 clock cycle
> which is pretty good. You can't massively improve this. That is why the
differences between Borland, C# and VC++ were
> not that big. All those compilers are in fact pretty good.
>
> > -cd
> JM
bonj | Mon, 31 Dec 2007 15:17:00 GMT |
> The title of the writeup might better be titled as to what to expect with
> free compilers.
It certainly might aswell! However, simply the inclusion of those few words
would have made it a lot more difficult to dismiss the test as unfair.
bonj | Mon, 31 Dec 2007 15:18:00 GMT |
> Why should that be so? In 12 years or so of SDK installations <windows.h>
> has never disappeared on me. <EG
Excellent. It definitely has on mine though.
> > and how many other people are
> > experiencing the same thing?
> People with problems tend to be vocal. Common problems affect lots of
> people. The collective roar of people experiencing common problems is hard
> to miss. On the other hand, the absence of a roar around an issue is often
> evidence that no common problem exists.
Yep, and likely me more than most. But if you throw enough shit, some
sticks. It doesn't alter the fact that Microsoft's compiler therefore simply
doesn't work on my computer, while Borland's works perfectly. I've got the
VS.NET 2002 IDE which I use if I want to build some utility, but for my
hobbyist-type work I think I'd rather use Borland. Basically, I'll use MS
for things that don't take long to write and I'm not really putting my heart
in it or as much effort, and when the IDE makes things much more convenient
which would be possible otherwise but boring. For my main programming,
though, if I can't really be sure the development software isn't going to
behave like a house of cards after a while, then it just smacks of the
author of such dev tools not putting as much effort into their product as I
intend to put into mine - which I think is profesionally rude, and I can't
stand it. For long-termish projects, then I want to be able to trust the
method by which I'm developing it. And I'm afraid Microsoft's compiler
simply doesn't live up to that requirement for me.
> > I now therefore not only prefer to use Borland, but have no other
option.
> :-) Way back when C6 was current, Borland's IDE and compiler was a quite
> popular option, widely regarded as better. It was the one that I choose,
> too. By C7 it wasn't immediately obvious which was better. The
introduction
> of the "Visual" line was the beginning of the end for Borland.
Well, commercially that may be the case, but it is a shame they felt it
necessary to send limos to Borland's offices to take 34 of their executives
and key developers out to lunch then subsequently poach them, in order to
achieve their market-leading position. When I read that it put even less
trust in microsoft in me than I already had, and it puts the 'stupid white
man' tag even more firmly on their shoulders. They may be wrong, but some do
claim there is a growing tide of mistrust towards ms - chiefly centred
around the growing 'locking-in' and 'locking-down' strategies.
> Just by the way, the free command line compiler that Borland gives away is
a
> few years old, no?
Possibly - but the stats speak for themselves - Borland provide a free
optimizing compiler - Microsoft simply don't.
> Regards,
> Will
bonj | Mon, 31 Dec 2007 15:20:00 GMT |
"Bonj" <a...b.com> wrote in message
news:O4VhDHl9DHA.1504...TK2MSFTNGP12.phx.gbl...
> There is no windows.h. Reinstalling windows, fixing the
> disk, and reinstalling the SDK wouldn't make the header files reappear. I
> phoned up Microsoft, but they wanted 185 to even attempt to start giving
an
> answer to my question. This doesn't bode well for the reputation of
> Microsoft, certainly in my esteem anyway
Why should that be so? In 12 years or so of SDK installations <windows.h>
has never disappeared on me. <EG
> and how many other people are
> experiencing the same thing?
People with problems tend to be vocal. Common problems affect lots of
people. The collective roar of people experiencing common problems is hard
to miss. On the other hand, the absence of a roar around an issue is often
evidence that no common problem exists.
> I now therefore not only prefer to use Borland, but have no other option.
:-) Way back when C6 was current, Borland's IDE and compiler was a quite
popular option, widely regarded as better. It was the one that I choose,
too. By C7 it wasn't immediately obvious which was better. The introduction
of the "Visual" line was the beginning of the end for Borland.
Just by the way, the free command line compiler that Borland gives away is a
few years old, no?
Regards,
Will
williamdepalomvpvc | Mon, 31 Dec 2007 15:20:00 GMT |
Bonj wrote:
>> The title of the writeup might better be titled as to what to expect with
>> free compilers.
> It certainly might aswell! However, simply the inclusion of those few
> words would have made it a lot more difficult to dismiss the test as
> unfair.
That is pretty much my point. I do think there is value in these kinds of
analyses, as long as the reader is not misled.
--
Brandon Bray, Visual C++ Compiler http://blogs.msdn.com/branbray/
This posting is provided AS IS with no warranties, and confers no rights.
brandonbraymsft | Mon, 31 Dec 2007 15:22:00 GMT |
There are two SDKs. One is Platform SDK and the other one is .NET SDK. You
have .NET SDK, which included standard version of C++/MC++ compiler, but no
win32 headers or libs.
"Bonj" <a...b.com> wrote in message
news:O4VhDHl9DHA.1504...TK2MSFTNGP12.phx.gbl...
> > The good news is that in the future, we are including the optimizing
> > compiler in all SKUs. This should address the concern of availability.
> That IS good news - I don't think you've really got anything to worry
about
> with GNU (it's horrible and linux-based) but the fact that you can
download
> a Borland optimizing compiler AND debugger from Borland for free in UNDER
20
> MB should worry you, currently.
> I certainly hope reliability of the SDK's installer come top of the
priority
> list aswell. I don't know why but I've only got 28 files in my
> SDK\v1.1\Include directory. There is one .cpp, one .def and the others are
> .h and .idl files. There is no windows.h. Reinstalling windows, fixing the
> disk, and reinstalling the SDK wouldn't make the header files reappear. I
> phoned up Microsoft, but they wanted 185 to even attempt to start giving
an
> answer to my question. This doesn't bode well for the reputation of
> Microsoft, certainly in my esteem anyway - and how many other people are
> experiencing the same thing? Microsoft have long been successful due to
two
> main factors - commercial aggressiveness and technical excellence, but if
> they're losing the edge on the latter to other outfits... I now therefore
> not only prefer to use Borland, but have no other option.
> I would definitely be interested to know if Microsoft have decided to do
the
> right thing and include an optimizer for free though. I mean it's mainly
> businesses that spend the money on the pricey software anyway, and they
are
> going to buy the IDE no matter what not because they want the optimizer,
but
> because they want their staff to use the IDE to build applications as
> quickly as possible. Keeping the hobbyist satisfied
> > I hope this information helps!
> > --
> > Brandon Bray
http://blogs.msdn.com/branbray/
> > This posting is provided AS IS with no warranties, and confers no
rights.
tester | Mon, 31 Dec 2007 15:22:00 GMT |
William DePalo [MVP VC++] <willd.no.spam...mvps.org> wrote:
> [...]
> Just by the way, the free command line compiler that Borland gives away is a
> few years old, no?
It's BCC5.5, the compiler that came with
C++ Builder 5. Regarding std conformance
it is better than VC6 (what wouldn't?).
However, I think that VC7.1 has passed it
in this regard. (From what I know VC's
GC has for long been better than BCC's.
But I have never tested this myself.)
> Regards,
> Will
Schobi
--
SpamTrap...gmx.de is never read
I'm Schobi at suespammers dot org
"Sometimes compilers are so much more reasonable than people."
Scott Meyers
hendrikschober | Mon, 31 Dec 2007 15:23:00 GMT |
MS .NET Framework EULA
"3.4Benchmark Testing. You may not disclose the results of any benchmark test of the .NET Framework component of the Software to any third party without Microsoft's prior written approval.
legalteammsft | Mon, 31 Dec 2007 15:24:00 GMT |
Legal Team [MSFT] <anonymous...discussions.microsoft.com> wrote:
> MS .NET Framework EULA:
> "3.4 Benchmark Testing. You may not disclose the results of
> any benchmark test of the .NET Framework component of the Software
> to any third party without Microsoft's prior written approval."
LOL!
These clauses spread through software
licenses like viruses.
Schobi
--
SpamTrap...gmx.de is never read
I'm Schobi at suespammers dot org
"Sometimes compilers are so much more reasonable than people."
Scott Meyers
hendrikschober | Mon, 31 Dec 2007 15:26:00 GMT |