---

Så fik jeg oversat mit projekt (der tidligere er compilet med GNU,
Borland og Intel compilere) med Visual C++ .Net 2003.

Udover de to problemer jeg nævnte tidligere, var der også det gamle
problem at MS enkoder "struct" og "class" forskelligt, så

class Foo;
extern void bar (const Foo&);

og

struct Foo;
extern void bar (const Foo&);

i følge Microsoft refererer til to forskellige funktioner. Jeg kan
godt forstå MS måske har svært ved at ændre ABI'en, men de burde ændre
linkeren så de to matchede.

Ud over det var de fleste andre problemer i min kode. Jeg kunne ikke
længere bruge "chdir" hvilket er fair nok da det er en Unix funktion.
Jeg måtte lave en særlig fil der kaldte "SetCurrentDirectoryA", for
man kunne ikke win32 ABI'en i "conforming mode", hvilket er lidt
sølle. På den anden side lægger det op til en klar adskillelse mellem
den portable og den uportable kode, hvilket jo er godt.

Visual C++ er kommet langt siden jeg prøvede sidst (det var vist 6.0),
men den er stædig et stykke fra GNU Og intel.

Og så er der jo lige spørgsmålet om den genererede kode. Min standard
testkørsel gav:

VC++ .Net 2003: 0 m 48 sekunder.
MinGW GCC 2.95: 0 m 17 sekunder.

Det var standard "Release" configuration. "Debug" configurationen gav
en eksekverbar der var over 7 minutter om testkørslen. Det så ikke ud
til at der var mange flag man kunne pille ved i den udgave af
compileren jeg har (Standard), så jeg ved ikke hvor meget der er at
vinde.

---

Per Abrahamsen wrote:

[8<8<8<]
> Visual C++ er kommet langt siden jeg prøvede sidst (det var vist 6.0),

Jeg antager at du mener med hensyn til overholdelse af sprogstandarden.
Det stemmer også med min erfaring - men det er var også stærkt påkrævet.

> men den er stædig et stykke fra GNU Og intel.

Men bedre end Borland med hensyn til sprogkonformance på de fleste felter ?


>
> Og så er der jo lige spørgsmålet om den genererede kode. Min standard
> testkørsel gav:
>
> VC++ .Net 2003: 0 m 48 sekunder.
> MinGW GCC 2.95: 0 m 17 sekunder.

Har du de tilsvarende målinger for Borland og Intel ?

Venlig hilsen

Mogens Hansen

---

Mogens Hansen <mogens_h@dk-online.dk> writes:

> Jeg antager at du mener med hensyn til overholdelse af sprogstandarden.
> Det stemmer også med min erfaring - men det er var også stærkt påkrævet.

Ja.

>> men den er stædig et stykke fra GNU Og intel.
>
> Men bedre end Borland med hensyn til sprogkonformance på de fleste felter ?

Det er meget længe siden jeg har oversat under med en Borland
compiler. Men klart bedre en Borland C++ 5.01, måske på niveau med
C++ Builder 5 i "hvor svær at porte til". Builder IDE'n var derimod
klart den værste jeg har oplevet, men den er selvfølgelig heller ikke
beregnet til konsolapplikationer.

>> Og så er der jo lige spørgsmålet om den genererede kode. Min
>> standard
>> testkørsel gav:
>> VC++ .Net 2003: 0 m 48 sekunder.
>> MinGW GCC 2.95: 0 m 17 sekunder.
>
> Har du de tilsvarende målinger for Borland og Intel ?

Fra hukommelsen:

Linux GCC 3.x giver den hurtigste kode, Intel 7 og gcc 2.95 ligger 5
til 10% efter, Borland C++ 5.0 20% efter. Alt sammen indenfor den
forskel man med rimelighed kan forvente mellem forskellige compilere.

MinGW GCC 3.x gen. kode er katastrofale 1 m 44 om testkørslen.
Borland C++ Builder 5 giver er dobbelt så langsom kode som deres
pre-builder compiler. Og som du kan se er VC++ 2.5 gange så langsom
som de "gode" compilere.

Jeg er sådan set ligeglad med forskelle på 20%, om en stor simulering
tager 10 eller 12 timer betyder ikke det store, men de andre
resultater er absurde. Måske skyldes det at jeg bruger vector<double>
med array indeksering rigtig meget, hvis compileren ikke kan optimere
det går det galt. På den anden side, det forklarer ikke forskellen
Linux og MinGW, det er samme compiler til samme CPU. Det kan næsten
kun være et eller andet horribelt i MinGW's I/O i 3.x.

---

Hejsa -

Per Abrahamsen wrote:
> VC++ .Net 2003: 0 m 48 sekunder.
> MinGW GCC 2.95: 0 m 17 sekunder.
>
> Det var standard "Release" configuration. "Debug" configurationen gav
> en eksekverbar der var over 7 minutter om testkørslen. Det så ikke ud
> til at der var mange flag man kunne pille ved i den udgave af
> compileren jeg har (Standard), så jeg ved ikke hvor meget der er at
> vinde.

Prøv at se:
http://msdn.microsoft.com/visualc/howtobuy/choosing.aspx

Der mangler et flag i "optimizing compiler", så mon ikke det er det som
er årsagen.

mvh Jonas

---

Jonas Meyer <a@b.c> writes:

> Der mangler et flag i "optimizing compiler", så mon ikke det er det som
> er årsagen.

Jo, det er det nok. Der plejer nu at være en optimizer med i
Microsofts og Borlands "billige" udgaver.

Det gør heldigvis ikke så meget, formålet var primært at porte
programmet så andre kan arbejde med det.