🚀 go-pugleaf

Pieter Philippaerts wrote:
> 
> "Sjoerd Schreuder" <sa_schreuder@wanadoo.nl> wrote in message
> news:3C706D11.C90F42C2@wanadoo.nl...
> > Het is geen kunst om sneller te zijn dan trage producten zoals VB.
> >
> > De ene link waarin wel met C++ werd vergeleken, bleek unmanaged C++ code
> > sneller te zijn dan managed C++ en C#.
> 
> Nochthans beweert die Duitse powerpoint presentatie net het
> tegenovergestelde :-)
> (leuk toch die benchmarks, je kan ze draaien exact hoe je ze wil)

Inderdaad. Dat ga ik hieronder toch ook eventjes doen.

> Hun resultaten voor bijvoorbeeld een iteratie van 1 miljard keer was voor
> VC6 10.172 seconden, VC7 unmanaged 10.172 seconden, VC7 managed 5.312
> seconden en C# 4.015 seconden (das dus een snelheids verschile van 2x in
> managed tov niet-managed code).

Je bedoelt: 2x in geoptimaliseerde code t.o.v. ongeoptimaliseerde code.

Wel graag er even bijvermelden dat de VC6 en VC7 tijden op debug
executables zijn bepaald. Dan zijn automatisch alle optimalisaties
uitgeschakeld. Die moesten ze ook uitschakelen, want zelfs VC6 optimaliseert
een lege loop helemaal weg en komt dus normaal gesproken op 0.0 seconden uit.

Dus die 2x is appels met peren vergelijken.

> Natuurlijk was dat maar 1 van de testen die die mensen uitgevoer hebben...

En het geeft me de kriebels over het niveau van de overige testen.

> Bewerkingen met floating points gingen dan weer in het ene geval trager in
> managed code, in het andere geval even snel als managed code (afhankelijk
> van de formule).

Dat zal wel weer met die debugversie te maken hebben.

> StringBuilder operaties (appenden in dit geval) waren dan weer 0.468 seconden
> in C# terwijl (gebufferde) CString operaties in unmanaged C++ 0.703 seconden duurde.
> Kopieren van strings met memcopy was dan weer iets sneller als het kopieren dmv.
> een StringBuilder.

Waar is de standaard string van C++, std::string?

In een CString wordt de lengte niet opgeslagen, dus als je append moet eerst het
einde worden opgezocht. Waarschijnlijk kun je daarmee al het snelheidsverschil
mee verklaren. std::string slaat wel de lengte op, en zal dus waarschijnlijk
wel sneller werken.

Ze vergelijken wel met een char-array en memcpy, en die is veel sneller.
Maar die wordt gelijk opzij geschoven onder het mom "dat is ouderwets".

Tja, zo kan ik het ook: het ene alternatief gewoon niet noemen, en een
ander alternatief als "achterhaald" afdoen alhoewel het veel sneller is.

> Zo gaat het verder... de ene keer is managed code sneller, de andere keer
> unmanaged.

Mijn indruk is dat ze niet alle mogelijkheden van C++ hebben benut.

> Het belangrijkste resultaat, neem ik aan, is het laatste: de resultaten van
> de 'ByteMark' benchmark. Daarin scoort C# beter als VC6 maar minder als VC7.

Zucht, ze gebruiken /O1. Dat is optimaliseren voor size, en niet voor
snelheid. Als ze dat al fout doen...

[Even muggenziften: Het is "beter dan"]

> Het leuke is dat dus al deze vergelijkingen met C++ zijn gedaan en aangezien over
> het algemeen aangenomen wordt dat C++ een hoog performante taal is
> (of toch 'kan zijn'), kan je ook hetzelfde aannemen voor C# en VB.NET.

Let op je eigen 'kan zijn'. Bij deze benchmark is niet het maximale uit C++
gehaald. Daardoor kan ik de uitkomsten van de benchmark niet serieus nemen.

Sjoerd Schreuder

PS: Sterker nog, als zelfs met zulke verdraaiingen C++ nog in de buurt van C#
komt, dan denk ik dat echt geoptimaliseerd C++ rondjes draait rond C#.