PureBoard

Das Thema haben wir wohl immer mal wieder.

Ich würde folgendes Vorschlagen:


Normale C++ Befehle, kein Assembler.


Vergleich von einfachen Befehlen ohne (viele) Programmier-Kenntnisse
und von optimierten Routinen.

Kathegorien:

- Console
- FensterAnwendung mit allen Gadgets einmal
- Spiel 2D
- Spiel 3D

ZeilenAnzahl!

Achso! Ganz wichtig: auf gleichen Betriebssystemen, auf gleichen Rechnersystemen.

Gern auch mit den Optionen MMX, SSE, SSE2, SSE3 ... 3D KNOW ...
sofern das einstellbar in den Compailern ist.

Aber nicht auf einem alles anstellen und auf dem PB-Compailer alles abstellen.

Genauso bei Optimiertem Code drauf achten, wie komplex das Wissen von der Sprache sein muss, um solche Dinge zu erreichen.

...

Oder was meint ihr? Interessieren würde es mich schon.
Muss aber sagen, dass mir C in seiner Ursprungsform für ConsolenAnwendungen ganz recht war. Aber schon bei komplexeren Sachen mir das ganze geHeadere auf den Senkel ging.

Genauso ist die Frage, wie gut C# ist und vor allem das .NET-Framework.

...

Was meint ihr? Ich bin nun kein Experte, was Benchmarks angeht. Aber interessieren würde es mich natürlich schon.

So als Projekt. ProcessExplorer oder diese Zeilentester für Programmcode. Gab es da nicht schon mal eine Entwicklung für PB-Code, die die Geschwindigkeit für die einzelnen Befehle gemessen haben in einer Art DEBUG-Mode ...

???

Kennt sich jemand mit C aus? Also fair müsste es schon sein.
Sonst hat der Vergleich keinen Sinn. Wie Äpfel und Birnen halt

Genauso wie einige Dinge im Code nicht weggelassen werden dürfen, die auf Intel Core 2 Duo schneller laufen als auf AMD X64 oder so ...
und die Tests laufen nur auf AMD Rechnern.

Wäre zu berücksichtigen. Wir müssten also alle möglichst den selben Code testen. Möglichst dann die C und die PB Variante.

Und am Ende posten wir alle unsere Beiträge. Dazu wäre natürlich eine Art Online-Vergleichsliste nicht schlecht, denn im Forum das zu posten wird wieder sehr unübersichtlich ...

Kennt sich da jemand mit Webseiten aus und könnte soeine Online Poste seite machen?

Schaut euch mal den Benchmark von Cinema4D Release 9.0 an.
ist kostenlos und berücksichtig Mehrkernprozessoren und teset Grafik, Prozessor und RAM Geschwindigkeit.

Interessant wäre auch, ob PB Code auch im Mac OS Bereich oder Linux hier und da gut abschneidet.

>>
Compailieren sollten wir die Sachen mit so vielen C-Compailern wie möglich. Unter Berüclsichtigung der Preise für den Compailer.
Das heißt auch, dass schon compailierte Versionen zur Verfügung stehen sollten. Nicht, dass sich jeder erst noch die ganzen C-Compailer besorgen muss. Das würde auch gewährleisten, dass die Einstellungen gleich und richtig sind.

Könnten die Sache richtig groß aufmachen und gleich einige Statistikprogramme und Analysefunktionen zu denerhobenen Daten entwickeln ...


Achso: Ein ganz wichtiger Punkt ist auch noch Programmierzeit.
Das setzt natürlich voraus, dass zwei Leute, die sich ungefähr gleich in PB und C auskennen ein und das selbe Problem lösen.
Damit nicht einer mit PB 5 min. braucht und dann 2 Tage in C. Und am Ende das C-Programm schneller ist.

... Bin gespannt, wie viel Elan ihr dazu habt.

Die Einsatzzwecke sind doch unterschiedlich, wozu vergleichen?
PB wird bei kleinen Sachen die Nase vorn haben, wohingegen C++ seine
Vorteile erst bei grösseren Projekten ausspielt.

Wer beides kann, wird also das nehmen, was zum Projekt paßt und die
anderen haben eben keine Wahl

Vergleiche haben keinerlei Wert, vor allem bei so unterschiedlichen
Systemen, wie C++ und PB, auch wenn noch so sehr versucht wird
gleichmässige Bedingungen zu integrieren.

Verwendet die Zeit lieber dazu, eure Sourcen zu optimieren

Hast schon Recht.

Da wir uns hier alle für PB entschieden haben, ist die Geschwindigkeit fast egal. Denn die Vorteile haben wir ja erkannt und nutzen sie.

Größere Firmen wie SAP und andere, werden nicht Source in PB-Form haben. Hier wäre eine Art Umschreiber/Converter interessanter.

Und da könnte man dann wieder Geschwindigkeiten solange vergleichen, bis der Converter den Code optimal umschreibt.

Cool wäre in diesem Zusammenhang auch ein Optimierungsprogramm, was den PB-Code für Leihen selbst optimiert.

Falls das noch nicht im Compailer integriert sein sollte.


Interessant würde ich die Sache nur dafür finden, dass man selbst ohne große Erfahrung Hinweise von der Software (benchmark) bekommt, wo man den eigenen Code optimieren müsste, um die größten Performancezuwächse zu erlangen.

Ich glaube, es gab zum Thema Geschwindigkeit auch mal was in der Laberecke.

Ich sehe es vor allem in Bezug auf PB 4.1
Damit auch die Entwickler wissen, wo sie ihr Augenmerk drauf richten können. Wo die User gern mehr Leistung vom Compailer erwarten.

Und wer weiß, was mit Vista DirectX 10 und den neuen Prozessor-Befehlen alles drin sein kann.

Gut, XP und Direct X 9 und die neuen ProzessorBefehle wäre auch schon cool. Vor allem, was schnelle einfach zu programmierende Multimedia-Befehle angeht.

...

Apropo Multimedia, wurde bei Vista eigentlich der Bluescreen ein bissel aufgepeppt? Etwas bunter, mit Hintergrundsound

ts-soft hat geschrieben:Apropo Multimedia, wurde bei Vista eigentlich der Bluescreen ein bissel aufgepeppt? Etwas bunter, mit Hintergrundsound

yo, der nennt sich jetzt "blue room" und wird als werbefläche vermietet...

Kannst ja gleich mal ein VISTA-LÄSTER-THEMA in der Laberecke aufmachen. Ich glaub, es kann nicht mehr als XP.

Und was ich gelesen und gesehen habe. Muss man wohl nicht haben.
Mir gefallen meine grauen Fenster im Windows 95/98-Stile. Zum Glück kann man das bei XP einstellen. Aber kann man das bei VISTA noch?

davor hab ich Angst

Und ob mich der Virus nun Fragt, ob ich ihn installiere ...
ich meine, wer weiß das denn vorher ob oder ob nicht???

So ein geschwindigkeitstest wäre nicht sinnvoll aus gründen die zu umfangreich sind als das ich sie hier darlegen wollen würde.

Generell kann man die Geschwindigkeiten von Programmiersprachen nicht vergleichen, allerhöchstens die resultierenden binarys der selben sprache von verschiedenen Kompilern.

Zaphod hat geschrieben:Die STL stinkt nicht, die ist nur generisch. Da PB keine Generezität anbietet, kann man da auch nicht vergleichen.

Die C++ Compiler tendieren dazu mehr hinzu zu linken als nötig ist. Das man das umgehen kann, zeigen die 4,8,16,32,... kb Demos aus der Demoszene, die sind nämlich in der Regel auch mit C/C++ Compilern kompiliert.

Sag mir mal bitte, wie ich es mit MingW schaffe eine EXE kleiner als 5 kb zu bekommen ohne UPX oder sonst irgendeinen Komprimierungstool zu verwenden. Es funktioniert einfach nicht.

Laut Thorium ( http://www.purebasic.fr/german/viewtopi ... 849#138849 ) ist es auch nur möglich wenn man Zusatztools oder einen hexeditor verwendet.

Vielleicht kannst du mir da ja weiterhelfen.

[EDIT]

Xaby hat geschrieben:Kathegorien:

- Console
- FensterAnwendung mit allen Gadgets einmal
- Spiel 2D
- Spiel 3D

ZeilenAnzahl!

Achja, dann sag mir mal wie du ohne WinAPI und zusatzbibliotheken Fenster in C++ erstellen willst. Das geht nämlich nicht. Sowas wie OpenWindow gibt es nicht standardmäßig in C++. C++ ist eine Programmiersprache, keine Befehlsbibliothek.

>> Compailer
Kain Kommentar.

RE: Kommbailla

Ich war schon etwas schläfrig, siehste vielleicht an der Erschaffungszeit.

Von mir aus kann man ruhig den Test mit WinAPI machen. Ich würde vermuten dass der PB-Compiler auch auf die entsprechende API des jeweiligen Systems zugreift ... oder wie soll es sonst funktionieren?

Mac OS API, Linux API, ...


Wie gesagt, mir ist das Ergebnis auch eher schnuppe, wenn es drum geht, ob PB oder C++ schneller ist. Wobei das wie du richtig sagst, ja egal ist, sondern einfach die EXE oder die ausführbaren Dateien dann später entscheiden.

Es wäre nur interessant, um zu sehen, wo man sein eigenes Programm optimieren kann.

Für das .NET-Framework gibt es zum Beispiel auch alle möglichen Sprachen. Eine Art Converter, der diese Sprachen in diese komische Intermedien-Language umschreibt und diese anschließend compiliert.

Deshalb wäre auch ein Tool, was PB-Code in eine andere Sprache setzen kann sinnvoller als ein Geschwindigkeitstester ...

Naja. Wieder mal so eine Diskussion, die eigentlich keinen einzigen Kommentar gebraucht hätte, sich am Ende ins Gelaber verzerrt und dann in ein paar Wochen unter anderem Namen wieder von vorn losgeht

Die .Net Intermediate Language ist sozusagen das Assembly des .Net, es ist keine Hochsprache.

Mit PureBasic Code passiert beim compilieren im prinzip das gleiche, nur halt mit x86/PPC Assembly.

In andere Hochsprachen zu konvertieren ist meistens nicht sehr Sinnvoll, außer zum teilautomatisierten Portieren nach einer anderen Sprache. Das Ergebnis ist aber vermutlich meistens eher weniger performant.