|
|
|
|
|
|
|
|
Ich hab irgendwas im Hinterkopf, dass Räume mit mehr als 3 (4?) Dimensionen nur noch eine stark begrenzte Anzahl an möglichen Oberflächen für Figuren haben oder so ähnlich und eben der 3-dimensionale Raum mit relativ vielen Möglichkeiten heraussticht. So ähnlich oder ganz anders, ich komm jedenfalls mit Google nicht weiter. Hat jemand eine Ahnung was ich meine?
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| | Zitat von Irdorath
Ich hab irgendwas im Hinterkopf, dass Räume mit mehr als 3 (4?) Dimensionen nur noch eine stark begrenzte Anzahl an möglichen Oberflächen für Figuren haben oder so ähnlich und eben der 3-dimensionale Raum mit relativ vielen Möglichkeiten heraussticht. So ähnlich oder ganz anders, ich komm jedenfalls mit Google nicht weiter. Hat jemand eine Ahnung was ich meine?
| |
das was du meinst bar aber nichts hiermit zu tun oder?
en.m.wikipedia.org/wiki/Poincar%C3%A9_conjecture
|
|
|
|
|
|
|
|
|
|
|
Ich glaube nicht.
Leider habe ich vergessen, was genau die Eigenschaft war, ich erinnere mich nur an eine große (irgendwo zwischen 10 und 20? ABer ich kann mich auch ganz falsch erinnern...) Anzahl in wenigen Dimensionen und ab dann in allen höheren Dimensionen eine von zwei kleinen Zahlen (<10).
An mehr erinnere ich mich leider nicht, weiß´auch nicht mehr in welchem Rahmen ich das gelesen hab. :/
|
|
|
|
|
|
|
|
|
|
|
|
Meinst du vielleicht, dass das Volumen der Einheitskugel bei einer gewissen Dimension sein Maximum hat?
|
|
|
|
|
|
|
|
|
|
|
So, ich habe jetzt in einer guten Woche mein Programm nach C++ portiert. Vom Aufbau her ist es ähnlich, d.h. ich nutze konzeptionell die gleichen Container (heap hier, array da, etc.). Trotzdem ist es nur in etwa halb so schnell. Eigentlich kann der Overhead nur durch die Function calls entstehen, da, wie gesagt, ansonsten alles ähnlich ist. Eigentlich war ich davon ausgegangen, der Compiler kann sowas weg optimieren - scheinbar Pustekuchen.
Ein Beispiel
| |
| Code: |
//C++
site->getNeighborByIndex(10)->getOccupant()->getName()
//C
site->neighbors[10]->occupant->name |
|
Scheinbar schafft g++ es nicht, solche Dinge gleich schnell zu kriegen. Das Programm ist jetzt komplett objektorientiert und ich habe alle Class member hinter gettern und Settern versteckt, in der Annahme, das würde irgendwie geinlined.
Was kann ich tun? (gprof nutze ich natürlich, ist aber irgendwie mittelmäßig hilfreich...)
|
|
|
|
|
|
|
|
|
|
|
Du könntest aus Performance-Gründen auf C wechseln...
|
|
|
|
|
|
|
|
|
|
|
|
Ich weiss ja nicht wie dein Programm auszieht, aber hast dus mal mit inline keyword als hint für den Compiler bei kleinen Methoden versucht? (Der Compiler darf den hint natürlich ignorieren).
|
|
|
|
|
|
|
|
|
|
|
| | Zitat von AcidF!re
Ich weiss ja nicht wie dein Programm auszieht, aber hast dus mal mit inline keyword als hint für den Compiler bei kleinen Methoden versucht? (Der Compiler darf den hint natürlich ignorieren).
| |
Nunja, mich stört daran etwas, dass ich die Implementierung der Methoden dann in den Klassen in den header files machen muss. Außerdem war ich davon ausgegangen, dass g++ da bei simplen getter/setter Methoden auch von selbst drauf kommt. Ich habe es eben mit der am häufigsten aufgerufenene Methode mal probiert, aber habe keinen Performance Gewinn feststellen können.
| | Zitat von wuSel
Du könntest aus Performance-Gründen auf C wechseln...
| |
So blöd es klingt, wenn ich den Performance Unterschied nicht reduzieren kann, werde ich wieder zum alten Programm gehen. Was echt schade wäre, weil das c++ Zeugs viel übersichtlicher, eleganter und vor allem kleiner ist.
|
|
|
|
|
|
|
|
|
|
|
|
Ich würde mal abwägen, ob es das nicht wert ist. Ist dir der Performance-Unterschied so wichtig? Ich mein, je nach Einsatz könnte man auch auf die perfekte Performance verzichten zu Gunsten einer brauchbaren. Dafür hast du ein Programm dass man in Monaten/Jahren auch noch warten kann ohne einen geistigen Kollaps zu erreichen. Das passiert bei voll durchoptimierten C-Programmen nämlich sehr gern mal.
|
|
|
|
|
|
|
|
|
|
|
Das ist ne Monte Carlo Simulation, die unter relevanten Bedingungen ca. 24 Stunden läuft. Die hat geschätzte 20 Parameter, aus denen ich bestimmte Sets raussuchen muss. Selbst auf unserem Cluster mit 40 Knoten oder so ist ein Faktor 2 in der Performance einfach unangenehm... 
|
|
|
|
|
|
|
|
|
|
|
|
Bloede Frage, aber uebergibst du vielleicht grosse Container oft per-value statt per-reference? *insblauerat*
|
|
|
|
|
|
|
|
|
|
|
| | Zitat von AcidF!re
Bloede Frage, aber uebergibst du vielleicht grosse Container oft per-value statt per-reference? *insblauerat*
| |
Nein, nichtmal Referenz. Ich wickle fast alles über Pointer ab. Dazu bin ich übergegangen, als mir das mit den Referenzen zu unübersichtlich wurde. Ich weiß, dass das nicht unbedingt empfohlen ist, aber eigentlich kann es sich ja nicht auf die Performance auswirken, oder?
/e: meine kritischste Funktion wird in dem Testlauf ca. 7mrd mal gecalled. Dann machen sich ein paar CPU ticks mehr oder weniger halt schon bemerkbar...
|
|
[Dieser Beitrag wurde 1 mal editiert; zum letzten Mal von Oli am 30.07.2013 15:01]
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
jo, ich nutze relativ viel, dass Pointer NULL sein können.
| |
| Code: |
bool Site::isOccupied()
{
return _occupant != NULL;
} |
|
|
|
|
|
|
|
|
|
|
|
|
| | Zitat von PutzFrau
Google Style verlangt sogar, dass alle Referenzen als const uebergeben werden, d.h. wenn du was veraendern willst, musst du es mit pointern machen:
| |
Hö, warum das denn? Wenn ich z.b. nen langen std::vector mit irgendwas drin habe und möchte da was ändern, dann übergebe ich den doch als reference und nicht als pointer auf den vector?!
/e: das mit den pointer könnte aber langsamer sein, da die ja jedesmal kopiert werden?
|
|
[Dieser Beitrag wurde 1 mal editiert; zum letzten Mal von NRG_Mash am 30.07.2013 15:18]
|
|
|
|
|
|
|
|
|
So weit ich informiert bin, gibt -flto die Möglichkeit, Aufrufe über TU-Grenzen hinweg zu inlinen.
Ansonsten: Callgrind benutzen, KCachegrind kann den Kram gut darstellen.
|
|
[Dieser Beitrag wurde 1 mal editiert; zum letzten Mal von csde_rats am 30.07.2013 15:19]
|
|
|
|
|
|
|
|
|
Weil es fuer den Nutzer keinen Unterschied beim uebergeben gibt, wenn er value oder reference uebergibt. Im Link ist es begruendet.
|
|
|
|
|
|
|
|
|
|
|
| | Zitat von PutzFrau
Weil es fuer den Nutzer keinen Unterschied beim uebergeben gibt, wenn er value oder reference uebergibt. Im Link ist es begruendet.
| |
Hm, wenn ich eine rießige Matrix übergebe macht doch schon ein Unterschied ob ich die Matrix mit by-value oder by-reference übergebe?
/e: also von der performance
|
|
[Dieser Beitrag wurde 1 mal editiert; zum letzten Mal von NRG_Mash am 30.07.2013 15:26]
|
|
|
|
|
|
|
|
|
Nur dass es um by-Reference(&) vs by-Pointer(*) geht. 
|
|
[Dieser Beitrag wurde 1 mal editiert; zum letzten Mal von Admiral Bohm am 30.07.2013 15:55]
|
|
|
|
|
|
|
|
|
...was intern eben beides by-ref ist, nur mit anderer Semantik. Reference hat in C++ by-val Semantik (keine explizite Zeigerbildung), es wird vom Caller also nicht unbedingt erwartet, dass das Objekt verändert wird.
Unabhängig davon überall const hinknallen wo es geht. Bei geschachtelten Pointern heißt es meist intuitiv das richtige, sonst cdecl explain.
|
|
|
|
|
|
|
|
|
|
|
| | Zitat von csde_rats
...was intern eben beides by-ref ist, nur mit anderer Semantik. Reference hat in C++ by-val Semantik (keine explizite Zeigerbildung), es wird vom Caller also nicht unbedingt erwartet, dass das Objekt verändert wird.
| |
Genau das ist der Punkt.
|
|
|
|
|
|
|
|
|
|
|
Und zu Olis Perfomanceproblem würde ich wirklich mal Callgrind auf die C und
die C++ Version laufen lassen und schauen, ob sich Schwerpunkte eventuell verschieben.
Wenn ich lese, dass seine eine Methode X Mrd. calls hat, dann muss betrachtet
werden, ob man das Caller/Callee-Gefüge an dieser Stelle nicht auflösen kann.
Hier könnte es auch sehr hilfreich sein, sich die Assembly an den Stellen
anzuschauen (KCachegrind kann das ganz gut anzeigen).
Ansonsten gelten die allgemeinen Stolperfallen:
-Bei range-based-for mit auto will man meistens _nicht_ den Typ von auto,
sondern den entsprechenden Referenztyp (auto &), sonst werden die Daten kopiert
[je nach exaktem Containerinhalt].
-std::string niemals einfach so handhaben, da sonst bei jeder Zuweisung kopiert wird,
also hier Pointer oder Referenzen.
-shared_ptr will man meistens nicht einsetzen (zusätzlicher Speicherverbrauch,
langsam, unsauber).
-Virtuelle Methodenaufrufe sind langsamer als non-virtual, also ggf. Hierarchien
anpassen.
-Der Compiler kann nur inlinen, wenn auch die Definition bekannt ist. Deswegen
gehören inline Methoden/Funktionen mit Definition in die Header.
-"Ich nutze relativ viel, dass Pointer NULL sein können" → ersetze conditionals
mit Vererbung, wenn möglich.
| | quantenmechanik ist wie frauen... quantemechanik versteht quantenmechanik und quantenmechanik hasst quantenmechanik
also nich versuchen quantenmechanik zu verstehen...! | |
|
|
[Dieser Beitrag wurde 1 mal editiert; zum letzten Mal von csde_rats am 30.07.2013 16:43]
|
|
|
|
|
|
|
|
|
| | Zitat von csde_rats
-"Ich nutze relativ viel, dass Pointer NULL sein können" → ersetze conditionals
mit Vererbung, wenn möglich.
| |
Was meinst du damit?
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
So, danke nochmal für eure Hilfe. Aggressives Optimieren und Herumfuchteln mit unordered_sets etc. hat den Performance Unterschied zwischen C und C++ auf weniger als das 1.5 fache reduziert. Ich kann noch weiter optimieren, aber dann an Stellen, an denen das im C Programm ebenso ginge. Anyway, reicht mir erstmal.
Ansonsten habe ich heute viel Zeit damit verbracht, forward declarations einzuführen und cyclic dependencies zu eliminieren. Jetzt hat auch jeder Klasse hübsch seine eigene Translation Unit und alles ist irgendwie eleganter. Noch einen Tag Code kommentieren, und ich bin erstmal fertig. 
|
|
[Dieser Beitrag wurde 2 mal editiert; zum letzten Mal von Oli am 31.07.2013 22:21]
|
|
|
|
|
|
|
|
|
Ich glaube, mit den ersten vier Zeilen von "I am the walrus" habe ich einen Fixpunkt für Google-Translator gefunden...
Make way evil! I'm armed to the teeth and packing a hamster!
|
|
|
|
|
|
|
|
|
|
|
| | Zitat von Virtus
Eine exakte Sequenz ist ein Kettenkomplex mit trivialer Homologie
Ach, Du wollstest eine nützliche Beschreibung? Dann ignorier obenstehenden Satz.
Eine exakte Sequenz ist eine Folge von aneinandergehängten Morphismen, so dass jeweils das Bild einer Abbildung dem Kern der darauffolgenden entspricht. Falls Du den ersten Satz nicht ignoriert hast: Homologie misst, um wieviel das Bild "zu klein" ist.
Denk im folgenden an Vektorräume und lineare Abbildungen. Die einfachste zweiteinfachste Form von exakter Sequenz ist eine kurze exakte Sequenz, also eine Sequenz der Form
 .
Exaktheit bei A besagt, dass die Abbildung von A nach B injektiv ist (der Kern entspricht dem Bild einer Abbildung aus dem Nullvektorraum), Exaktheit bei C ist die Surjektivität der Abbildung von B nach C (denn das Bild ist gleich dem Kern der Abbildung, die alles auf 0 schickt). Bleibt noch die Frage was es bedeutet, dass die Sequenz bei B exakt ist...
Weil die Abbildung  injektiv ist, können wir A als Unterraum von B auffassen. Die Abbildung  macht dann genau diesen Unterraum trivial (und ist wie vorher bemerkt surjektiv), kann also als die kanonische Projektion  aufgefasst werden.
Selbiges gilt für Gruppen, Ringe, etc...
Nun zur einfachsten exakten Sequenz:
Bei  ist die mittlere Abbildung ein Isomorphismus (Argumentation siehe oben). Das ist zum Beispiel bei langen exakten Sequenzen nützlich. Angenommen Du hast die lange exakte Sequenz
 .
Wenn Du weißt, dass  und  trivial sind folgt, dass  ein Isomorphismus ist.
| |
Ich glaube, ich habe das noch nicht ausreichend würdigend kommentiert:
Das ist, was ich kenne (und hoffentlich auch halbwegs weiß...), aber es ist nicht, was ich mit pädagogisch sinnvoll meine.
Quasi ein Spielzeugmodell für den Laien, an dem er erkennen kann, warum es toll ist, Ergebnisse zu einer (Ko)Homologie zu haben. Etwas, was an so unterschiedlichen Stellen in der Mathematik immer wieder aufgegriffen wird (oder zumindest werden kann...), hat bestimmt auch coole "Alltagsanwendungen" für die man jemandem nicht erst erklären muss, was ein Komplex, eine Sequenz oder injektiv und surjektiv ist.
Atkins diet. I maim anyone with carbohydrates. Keeps me rather fit.
|
|
|
|
|
|
|
|
|
|
|
|
Ich sehe immerhin den Isomorphismus zwischen Virtus' Post und "I am the walrus".
|
|
|
|
|
|
|
|
|
|
|
Wer doktoriert hier eigentlich so?
Ich hab nächste Woche in Gespräch, bei dem wir relativ locker mögliche Themen besprechen, die aber wohl ziemlich interessant wären. Irgendwie hab ich noch ein wenig Respekt davor, aber sonst spricht irgendwie nichts dagegen (Gruppe gut, Bezahlung gut, Themen interessant). Bin gerade noch ein wenig unschlüssig, ob ich's mir zutraue 
|
|
|
|
|
|
|
|
| Thema: pOT-lnformatik, Mathematik, Physik XIII ( Completely Automated Public User Test To tell PIMP ) |
