![](/i/fill.gif) |
![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
Bill DeWitt wrote:
>
> "Ken" <tyl### [at] pacbell net> wrote :
> >
> > Does a comiler make code or does it make a program out of code ?
> >
>
> Yes. A compiler makes code out of code. Hope I've cleared that up...
>
> Using MSVC++ as a compiler won't make much of a difference in the
> program itself. The problem, if there is one, would be if they switched over
> to MFC (Microsoft Foundation Classes). That is the single largest bloater of
> code in the universe.
>
> I suspect that they will write straight to API though so that the code
> can be compiled from source in any C++ compiler. That would make more sense
> considering the history so far.
Given the emphasis on portability in all the C versions, I couldn't see
anything like that happening.
PoD.
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
What about Borland (Inprise ;-)) C++ compiler? No one mentions it. Is it not
of the same class as Watcom and MS?
--
Regards,
Sander
Nieminen Juha <war### [at] punarastas cs tut fi> schreef in berichtnieuws
385e58f5@news.povray.org...
> Pabs <pab### [at] hotmail com> wrote:
> : What is the POV-Team going to do now that Watcom C++ is dying
> : Please don't go to MSVC++
>
> Actually the MSVC compile of povray seems to be faster than the watcom
> compile.
> Who cares which compiler is used as long as it makes faster code?
>
> --
> main(i,_){for(_?--i,main(i+2,"FhhQHFIJD|FQTITFN]zRFHhhTBFHhhTBFysdB"[i]
> ):5;i&&_>1;printf("%s",_-70?_&1?"[]":" ":(_=0,"\n")),_/=2);} /*- Warp -*/
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
Sander wrote:
>
> What about Borland (Inprise ;-)) C++ compiler? No one mentions it. Is it not
> of the same class as Watcom and MS?
No, it isn't. It's about twice as expensive and does not optimize
as good. Watcom has long been the compiler producing the fastest code,
no overtaken by MS.
Markus
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
Markus Becker wrote in message <3860EE66.F112F868@student.uni-siegen.de>...
>Sander wrote:
>>
>> What about Borland (Inprise ;-)) C++ compiler? No one mentions it. Is it
not
>> of the same class as Watcom and MS?
>
>No, it isn't. It's about twice as expensive and does not optimize
>as good. Watcom has long been the compiler producing the fastest code,
>no overtaken by MS.
How does GCC compare for optimizing code?
Mark
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
Mark Wagner wrote:
>
> How does GCC compare for optimizing code?
As far as I know, they are about equal. (MS and GCC)
Markus
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
Markus Becker wrote:
> Mark Wagner wrote:
> >
> > How does GCC compare for optimizing code?
>
> As far as I know, they are about equal. (MS and GCC)
>
> Markus
One point on the PNG mailing lists came up with the non-optimizing VC++
and GCC. Someone compared some straight C code versus some
hand-optimized assembly language, and gcc on the straight code did a
better job than the hand-optimized assembly code under gcc or VC++. So,
for some things it might even beat VC++.
--
"My new computer's got the clocks, it rocks
But it was obsolete before I opened the box" - W.A.Y.
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
Jon A. Cruz <jon### [at] geocities com> wrote:
: gcc on the straight code did a
: better job than the hand-optimized assembly code
This only means that the person who made the assembly code didn't know
what he was doing.
You can always make the same and often better code than a program can.
It requires LOTS of knowledge about the cpu, though.
--
main(i,_){for(_?--i,main(i+2,"FhhQHFIJD|FQTITFN]zRFHhhTBFHhhTBFysdB"[i]
):5;i&&_>1;printf("%s",_-70?_&1?"[]":" ":(_=0,"\n")),_/=2);} /*- Warp -*/
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
On Wed, 22 Dec 1999 16:29:42 +0100, Markus Becker
<mar### [at] student uni-siegen de> wrote:
>Sander wrote:
>>
>> What about Borland (Inprise ;-)) C++ compiler? No one mentions it. Is it not
>> of the same class as Watcom and MS?
>
>No, it isn't. It's about twice as expensive and does not optimize
>as good. Watcom has long been the compiler producing the fastest code,
>no overtaken by MS.
Does anyone have any benchmarks on the Intel Performance Toolkit C++
compiler that comes with vTune? I have it here, and I've been
building 3.5 with it (note that that doesn't say anything about what
the final official version will be built with.) If nobody has
benchmarks, I might be persuaded to build an MS version and an Intel
version and compare, but I'd have to wait to do the tests because I
don't have a Pentium running Windows here at home (this box is a
K6/233.)
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
On 27 Dec 1999 05:10:49 -0500, Nieminen Juha
<war### [at] punarastas cs tut fi> wrote:
> You can always make the same and often better code than a program can.
>It requires LOTS of knowledge about the cpu, though.
That's knowledge most mere mortals don't have when it comes to P5/P6
optimization.
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
Ron Parker <par### [at] fwi com> wrote:
:> You can always make the same and often better code than a program can.
:>It requires LOTS of knowledge about the cpu, though.
: That's knowledge most mere mortals don't have when it comes to P5/P6
: optimization.
You are terribly right.
A long time ago, in the age of 286's and even 386's the architecture of
the CPU was so simple that making a superduper-optimized asm code which
was at least twice as fast as any C code, was quite easy.
Nowadays, however, the CPU's have evolved to such an extent and they are
so extremely complicated, that the same tricks of the old asm coding do not
hold anymore. To beat a good C-compiler it would require so much knowledge
about the CPU (and often other hardware) that it's almost impossible for
the average asm-coder.
The compiler has two main advantages over a human coder: It will remember
everything taught to it and it will compile extremely fast.
Nowadays it doesn't make much sense to code in assembler for the big
computers. I have not written a line of asm in many years. A pitty, really.
Fortunately we still have the embedded systems...
--
main(i,_){for(_?--i,main(i+2,"FhhQHFIJD|FQTITFN]zRFHhhTBFHhhTBFysdB"[i]
):5;i&&_>1;printf("%s",_-70?_&1?"[]":" ":(_=0,"\n")),_/=2);} /*- Warp -*/
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |