🚀 go-pugleaf

In article <J0wb8.23178$ql6.1955334@zwoll1.home.nl>, Serve La wrote:
>> > Hoe gaat Delphi op IA64
>> > performen,
>>
>> Niet gehinderd door theoretische grenzen.
> 
> De drol die ik in de WC ga afschieten kan theoretisch ook met de snelheid
> van het licht gaan

Alleen hoef ik met die drol geen app te bouwen
 
>> > die komen zeker weer drie jaar later met een compilertje op de
>> > proppen en weer drie jaar later met een stabiele versie.
>>
>> .NET voor Delphi komt in 2e helft dit jaar. Is toch niet laat?
> 
> Om je even te quoten
> "Een ander leuk detail las ik in het article over .NET op arstechnica:
> Hoe gaat .NET performen op IA64 architecturen waar een helehoop optimizatie
> naar
> de compiler verschoven wordt? Alleen de precompile (en niet de JIT) variant
> gebruiken?"
> 
> Hoe gaat Delphi dan performen als het over een half jaar voor .NET uitkomt?

Delphi staat niet ter discussie, en ik zie niet wat dit hier mee te maken
mee heeft. 

Maar persoonlijk verwacht ik inderdaad dat het zuigt ten opzicht van native
apps, en dat het cross platform gehalte van .NET laag zal zijn.

> En eh, nee hoor, een half jaar is niet te laat, we gaan wel wachten, ten
> slotte is er toch nergens concurrentie te vinden.
> Hoe weten ze trouwens dat het over een half jaar uitkomt, brengen ze niet
> eerst een beta uit, of maken zij geen fouten? Even uitleg, die laatste
> vraag is retorisch, ik heb in twee weken meer crashes gehad met c++
> builder5 dan met VS 5 en 6 in vier jaar.

En als jij dat hebt, dan geldt het voor de wereld.
 
>> Waar is je VS voor IA64?
> 
> ??....Ten eerste is die er al,

Als productie?
 
>> > comp.unix.programmer de thread Java vs C++, iemand deed daar een
>> > snelheidtest met een aantal talen, waaronder ook jullie freepascal
> compiler.
>>
>> Onze compiler zuigt qua performance in het nummerieke bedrijf. Doet geen
>> loop unrolling, tail recursion etc.
>>
>> Maar dat heb ik ook nooit anders beweerd.
> 
> In bijna al je postjes die over andere talen dan (OO) pascal/Delphi gaan
> begin je over dat de performance zuigt.

Nee hoor, ik hakte in eerste instantie tegen belangrijke  misverstanden
tussen C/C++ en Pascal/Object Pascal qua perforance. Dat die ruwweg in
dezelfde orde liggen.

Je haspelt die discussie met de discussie over native compiling vs VM
systemen door elkaar.

> Ik kan me zelfs nog herinneren dat C niet zo snel was volgens jou omdat
> het bepaalde dingen niet had (zal wel met pointer aliasing te maken hebben
> gehad).

O.a. strings kunnen in theorie in sommige loopjes ook sneller zijn, al zal
dat gemiddeld wel tegenvallen.

> En pascal compilers kunnen theoretisch* hetzelfde.

Niet geheel, al scheelt het niet veel. B.v. Templates (en de daarbij
behorende optimalizaties).

> "De drol die ik in de WC ga afschieten kan theoretisch ook met de snelheid
> van het licht gaan"

Ik hield je tot nu toe niet voor een onredelijk figuur. Tot nu toe dus.
 
>> > Scoorde stukken lager dan java en java scoorde ook hoger dan Delphi. Als
> je
>> > dan zo gespitst bent op snelheid, moet je natuurlijk wel zorgen dat je
> eigen
>> > compiler supersnel is.
>>
>> Hoezo, het niet hebben van een eigen compiler houdt jou toch tegen
> commentaar
>> te geven?
> 
> 1. kromme zin

Moet soms tussendoor werken af en toe.

> 2. volgens mij niet wat je bedoelde te zeggen

Min of meer wel, jij hebt ook geen eigen compiler die beter is, en toch geef
je ook commentaar. Het hebben van een eigen development systeem maakt je
niet blind voor zowel fouten in het eigen systeem, als in andere.
Ik weet wat de optimizing staat van de compiler is.

Ik hoop verder dat de vergelijking niet op basis benchmarks is gebaseerd. De
optimalizaties aan FPC worden meestal door profiling bepaald, niet door toe
te werken naar benchmark performance.

Sterker nog, ik denk dat b.v. Free Pascal, en andere kleinere compilers
zonder full time mensen het heel lastig gaan krijgen door de snelle
opvolging van backend veranderingen (IA64, .NET). Ook opensource VM systemen
(die aangepast zullen moeten worden om performance over te houden krijgen
het moeilijk)

We/Ze zullen keuzes moeten maken. Als het aan mij ligt, laten we .NET links
liggen. Delphi gaat er naar toe, en voordat wij het af hebben is het
afgeschaft. IA64 zal ook alle krachten gaan vergen, zelfs met de huidige langzame

> 3. Als mensen performance belangrijk vinden in een compiler en ze werken mee
> aan een compiler (jij dus), zullen ze er veel werk in steken om hun eigen
> compiler ook qua performance goed te laten lopen

Heb jij wel enig idee hoeveel werk dat dat is? 6 mensen trekken het hele project, inclusief
runtime libraries, ports etc. 

Het komt, maar langzaam. Het moet concureren voor tijd met nieuwe processor targets, OS ports,
bepaalde compiler en runtime library feature extensies  (denk aan register parameters, thread
safety, shared libraries met PIC etc).


Verder doe ik weinig aan structurele compiler verbetering, dat is Jonas'
(back end optimizer), Florian (compiler zelf) en Peter (beide) soepje.
Ik doe wel veel bughunting op zowel de Unix als Windows platforms, en kan steeds meer zelf
fixen, nu ik de compiler wat beter leer kennen.