Files |  Tutorials |  Articles |  Links |  Home |  Team |  Forum |  Wiki |  Impressum

Aktuelle Zeit: Do Mär 28, 2024 23:10

Foren-Übersicht » Sonstiges » Meinungen zu den Projekten
Unbeantwortete Themen | Aktive Themen



Ein neues Thema erstellen Auf das Thema antworten  [ 60 Beiträge ]  Gehe zu Seite Vorherige  1, 2, 3, 4  Nächste
Autor Nachricht
 Betreff des Beitrags: Re: @Radon Framework
BeitragVerfasst: Mi Aug 28, 2013 10:03 
Offline
DGL Member
Benutzeravatar

Registriert: Do Sep 02, 2004 19:42
Beiträge: 4158
Programmiersprache: FreePascal, C++
Abgefahren :). Ich sollte libRocket wirklich im Auge behalten ;). Ich hoffe du sendest denen dann einen Pull Request?

grüße

_________________
If you find any deadlinks, please send me a notification – Wenn du tote Links findest, sende mir eine Benachrichtigung.
current projects: ManiacLab; aioxmpp
zombofant networkmy photostream
„Writing code is like writing poetry“ - source unknown


„Give a man a fish, and you feed him for a day. Teach a man to fish and you feed him for a lifetime. “ ~ A Chinese Proverb


Nach oben
 Profil  
Mit Zitat antworten  
 Betreff des Beitrags: Re: @Radon Framework
BeitragVerfasst: Mi Aug 28, 2013 18:47 
Offline
DGL Member
Benutzeravatar

Registriert: Di Mai 18, 2004 16:45
Beiträge: 2621
Wohnort: Berlin
Programmiersprache: Go, C/C++
Ja, ich habe vor das zurück in den Master fließen zu lassen.
Ich will das auch in unserem MMORTS haben, welches wir Ende des Jahres, auf Arbeit, anfangen werden zu produzieren.

Eine weitere praktische Erweiterung wäre noch ein Framebuffer Target, damit man post Effekte machen kann aber das brauch ich nicht privat, von daher mal gucken ob ich das auf Arbeit einbaue.
Wenn man ein Element erst in ein Framebuffer rendert und diesen dann in die Szene rendert, dann kann man z.B. Motion-Blur, Gaussian-Blur und Bloom machen.

_________________
"Wer die Freiheit aufgibt um Sicherheit zu gewinnen, der wird am Ende beides verlieren"
Benjamin Franklin

Projekte: https://github.com/tak2004


Nach oben
 Profil  
Mit Zitat antworten  
 Betreff des Beitrags: Re: @Radon Framework
BeitragVerfasst: Sa Apr 19, 2014 23:23 
Offline
DGL Member

Registriert: Do Dez 29, 2011 19:40
Beiträge: 421
Wohnort: Deutschland, Bayern
Programmiersprache: C++, C, D, C# VB.Net
Mal eine Frage: Wieso hast du im aktuellen Codebeispiel "unused" drin und außerdem 3 Byte Verlust durch automatisches Alignment bei "m_MemoryManagment"? Ich dachte du wolltest effizienter mit Cache umgehen und da werden glatt 7 Byte direkt in den Papierkorb verschoben, pro String, 2 mal pro Cacheline und direkt darüber schreit "FixString<16>" nach mehr Platz für SSO. Das kann ich gerade nicht ganz verstehen.

Ich weiß nicht wie du allokierst oder wie das "ALIGN"-Makro bei dir aussieht. Aber ich vermute es verwendet intern wohl "__declspec(align(...))" und es hat sich bei mir herausgestellt, dass das bei Allokationen auf den Heap scheinbar versagt, das heißt , es bringt dann genau gar nichts.

In VS2013 sind übrigens Profiler und Codeanalyse (zum ersten mal?) auch in der "normalen" Professional-Version integriert. An der UI wüsste ich persönlich ehrlich gesagt keine entscheidenden Änderungen, außer billiger aussehende Symbole im Vergleich zu VS10.


Nach oben
 Profil  
Mit Zitat antworten  
 Betreff des Beitrags: Re: @Radon Framework
BeitragVerfasst: So Apr 20, 2014 01:02 
Offline
DGL Member
Benutzeravatar

Registriert: Di Mai 18, 2004 16:45
Beiträge: 2621
Wohnort: Berlin
Programmiersprache: Go, C/C++
Code:
  1. Mal eine Frage: Wieso hast du im aktuellen Codebeispiel "unused" drin und außerdem 3 Byte Verlust durch automatisches Alignment bei "m_MemoryManagment"? Ich dachte du wolltest effizienter mit Cache umgehen und da werden glatt 7 Byte direkt in den Papierkorb verschoben, pro String, 2 mal pro Cacheline und direkt darüber schreit "FixString<16>" nach mehr Platz für SSO. Das kann ich gerade nicht ganz verstehen.

Ich schätze du denkst an folgende Variante, wo ich nicht unused und 1byte enum für den String verwende.
Code:
  1. class ALIGN(32) String{
  2. protected:
  3.     union{
  4.         FixString<27> m_Fix;
  5.         AutoPointerArray<Char> m_Dyn;//RAII Pattern: besteht aus T* m_Data und Size m_Size(16Byte bei 64bit und 8Byte bei 32Bit)
  6.     }
  7.     DataManagment::Type m_MemoryManagment;
  8.     UInt32 Length;
  9.     //UInt64 unused;
  10. };

Das unused sollte zeigen, dass ich noch 8Byte Platz für weitere Dinge in der Klasse hab, sollte ich diesen brauchen und ich auch noch nicht einschätzen kann, wie ich mit den 27byte umgehen würde.
Entweder mach ich 2x 16Byte SIMD/1x 32Byte SIMD Operation und kümmer mich dann noch um die 5Bytes von MemoryManagment und Length oder hab halt nur 16Byte länge, mach 1x 16Byte SIMD operation und brauch mich um nix weiter kümmern und verbrenne halt für ein mir unbekannten % an Strings in einem Programm, weil die dann über m_Dyn laufen.
Dafür muss ich mich erst mit Beispielcode hin setzen und messen.
Optimierung kann man ja leider nur schwer vorraus planen, wenn man auf so niederen Hardware level arbeitet, da ist es besser vorher zu messen. Damit ich sinnvoll messen kann muss ich allerdings sicher sein, dass mein Code auf allen 3 Systemen funktioniert und dafür baue ich ja noch an mein BuildGrid.

Zitat:
Ich weiß nicht wie du allokierst oder wie das "ALIGN"-Makro bei dir aussieht. Aber ich vermute es verwendet intern wohl "__declspec(align(...))" und es hat sich bei mir herausgestellt, dass das bei Allokationen auf den Heap scheinbar versagt, das heißt , es bringt dann genau gar nichts.

Da verweise ich auf folgendes.
Zitat:
Der standard allocator reicht dafür aus, man muss einfach nur Bytegröße+15Byte alloziieren und dann kann man den pointer um bis zu 15 Byte verschieben, um alignment hin zu bekommen.

Alternative auch _aligned_malloc oder posix_memalign, damit man nicht jedes mal 15Byte verbrennt.
Alignment regelt VC++ im Release bisher ziemlich zuverlässig, in meinen memory funktionen werden die Duff device übersprungen. Im Debug kann es schief gehen, weil dann die speicherfunktionen gehooked werden und dann die Debugger Memory verwaltung zu ignoranten Speicherreservierungen führt.
http://blogs.msdn.com/b/reiley/archive/2011/08/28/side-effects-of-debugger.aspx _NO_DEBUG_HEAP=1 könnte das lösen.

Zitat:
In VS2013 sind übrigens Profiler und Codeanalyse (zum ersten mal?) auch in der "normalen" Professional-Version integriert. An der UI wüsste ich persönlich ehrlich gesagt keine entscheidenden Änderungen, außer billiger aussehende Symbole im Vergleich zu VS10.

VS2010 hatte eine Profile guided optimization aber ein richtigen Profiler und Codeanalyse ist erst mit 2013 rein gekommen.
Bisher konnte ich nur auf AMD CPU's mit Code Analyst gescheit profilen, bzw. mit gprof unter linux und OSX auf Intel und AMD.
Einzig Intel auf Windows ist pain in the ass, weil Intel einfach mal 900$ für VTune haben will, was AMD OpenSource anbietet.
Der VS2013 Profiler ist besser als CodeAnalyst für Intel CPU's von daher sehe ich das als + Punkt für die neue Version.
In VS2013 wurden viele neuerungen aus Extensions übernommen. Tab well z.B. ist ziemlich gut implementiert wurden.
Syntax formatierung, highlight, jit und intellisense arbeiten nun viel besser und das man nun alle Projekte in der Solution mit einmal neu laden kann ist praktisch(wenn man mit cmake arbeitet). Man kann nun auch Symbole und Datein in der Solution suchen, Funktions Documentation wird korrekter dargestellt, ne menger toller extension von MS zum erweitern, wie z.B. für Profiler und Build Overview.
Da fehlt eigentlich nicht mehr viel, bis man kein Visual Assist X mehr bräuchte.

_________________
"Wer die Freiheit aufgibt um Sicherheit zu gewinnen, der wird am Ende beides verlieren"
Benjamin Franklin

Projekte: https://github.com/tak2004


Nach oben
 Profil  
Mit Zitat antworten  
 Betreff des Beitrags: Re: @Radon Framework
BeitragVerfasst: So Apr 20, 2014 12:28 
Offline
DGL Member

Registriert: Do Dez 29, 2011 19:40
Beiträge: 421
Wohnort: Deutschland, Bayern
Programmiersprache: C++, C, D, C# VB.Net
Also wird es bei dir nicht vorgesehen sein, die "String"-Klasse direkt zu verwenden? "ALIGN(32)" kannst du dir dann eigentlich auch sparen, bringt ja dann eh nix, bei "_aligned_malloc" oder einem eigenen Allokator.
Meinst du nicht das es von Vorteil sein könnte, wenn kleine Strings direkt auf dem Stack erzeugt werden können, ohne eigenen Allokator, der in möglicherweise nicht verfügbare Pages verweist?


Nach oben
 Profil  
Mit Zitat antworten  
 Betreff des Beitrags: Re: @Radon Framework
BeitragVerfasst: So Apr 20, 2014 13:12 
Offline
DGL Member
Benutzeravatar

Registriert: Di Mai 18, 2004 16:45
Beiträge: 2621
Wohnort: Berlin
Programmiersprache: Go, C/C++
Da komme ich nicht hinter her.
Code:
  1.         RadonFramework::Core::Types::Bool Compare()
  2.         {
  3.             String str("aaa");
  4.             String str1("abc");
  5.             String str2("cb");
  6.             Int32 a,b,c;
  7.             a=str.Compare(str);
  8.             b=str.Compare(str1);
  9.             c=str.Compare(str2);
  10.             return a==0 && b==2 && c==-1;
  11.         }

Das funktioniert wunderbar, die sind aligned in meinen unit test.
Code:
  1. String* a = new(String);// funktionierte im unit test auch bisher problemlos
  2.  
  3. void* p;
  4. posix_memalign(&p, 32, 32);
  5. String* b = new(p)String();// der Standard legt schon fest das dies gehen muss, daher nicht getestet
  6.  
  7. struct Bla{String myString;};
  8. Bla test;// ist aligned muss es aber nicht
  9.  
  10. struct ALIGN(8) Bla{String myString};
  11. Bla test// kann in 75% der fälle nicht aligned sein


Das eigentlich Problem ist, dass nur displacement new es garantieren kann, der rest ist dem Compiler überlassen.
new kann man ja für String überladen und damit Heap Objekte immer garantieren, dass sie aligned sind(das machen wir z.B. im Framework auf arbeit so, da sind diplacement new und new für bestimmte Klassen überladen und nutzen aligned memory allocation).
Stack allocation ist dem Compiler seine Sache und ich wüsste auch nicht, wie ich ihm ausser mit Globalen 32Byte alignment als Compiler Flag es garantieren könnte. Ich hoffe darauf, dass alle Compiler mit align Attribute schon das machen, was ich beabsichtige.
Wenn er es nicht macht, kann ich immer noch von MemoryManagment::Copy mode in MemoryManagment::AllocateAndCopy mode springen und dann ist es ja wieder garantiert aber halt ein indirekter zugriff(weil er nicht mehr den lokalen buffer sondern den pointer verwendet).

Wenn der Speicher nicht aligned ist, dann geht ja die Welt nicht unter, die aktuell schon besser optimierten Funktionen haben immer nen Duff Device, was solange arbeitet bis die nächste Aligned Memory Adresse erreicht ist und dann setzt der SIMD code ein.
Das hab ich von der VC++ Funktion memcpy abgeguckt und im nachhinein hab ich das auch bei Agner gefunden.
Als wir die Diskussion im Moderne Sprachen über Latenzen und co hatten, hab ich auch mal in die aktuellen Cycle Tabellen geguckt und da waren nun auch standard Typen wie 8Bit, 16Bit, 32Bit und 64Bit integer streamline fähig, also 2 oder 3 aufrufe aber nur den Preis einer Operation.
Da hab ich dann auch bemerkt, das ne menge Operationen nun Latenzen eingetragen haben.

_________________
"Wer die Freiheit aufgibt um Sicherheit zu gewinnen, der wird am Ende beides verlieren"
Benjamin Franklin

Projekte: https://github.com/tak2004


Nach oben
 Profil  
Mit Zitat antworten  
 Betreff des Beitrags: Re: @Radon Framework
BeitragVerfasst: So Apr 20, 2014 13:38 
Offline
DGL Member

Registriert: Do Dez 29, 2011 19:40
Beiträge: 421
Wohnort: Deutschland, Bayern
Programmiersprache: C++, C, D, C# VB.Net
Also die "New/Delete"-Operatoren dafür zu überladen klingt nach einer sehr interessanten Idee.
Das werde ich vielleicht auch mal so machen.


Nach oben
 Profil  
Mit Zitat antworten  
 Betreff des Beitrags: Re: @Radon Framework
BeitragVerfasst: Mo Mai 19, 2014 21:32 
Offline
Ernährungsberater
Benutzeravatar

Registriert: Sa Jan 01, 2005 17:11
Beiträge: 2067
Programmiersprache: C++
Wieso nutzt du Sleep() und nicht std::this_thread::yield()?
In der Implementation ist es vermutlich dasselbe, aber das eine ist STL, dass andere Compilerspezifisch.

_________________
Steppity,steppity,step,step,step! :twisted:
❆ ❄ ❄ ❄ ❅ ❄ ❆ ❄ ❅ ❄ ❅ ❄ ❅ ❄ ❄
❄ ❄ ❄ ❅ ❄ ❄ ❄ ❅ ❄ ❄ ❆ ❄ ❄


Nach oben
 Profil  
Mit Zitat antworten  
 Betreff des Beitrags: Re: @Radon Framework
BeitragVerfasst: Di Mai 20, 2014 08:03 
Offline
DGL Member
Benutzeravatar

Registriert: Di Mai 18, 2004 16:45
Beiträge: 2621
Wohnort: Berlin
Programmiersprache: Go, C/C++
Danke für den Tipp, ich hab das System yield bisher gemieden, weil jeder es anders implementiert und ich hab mal das verhalten nach gelesen und es mit sleep verglichen. Yield hat nur garantiert, dass der Thread suspended aber mehr nicht. Der Standard hingegen ist da recht genau und sagt, dass es die System Sheduler Mechanik benutzt. yield unter linux macht genau das gleiche wie sleep(0) unter windows, von daher werde ich mal Yield noch einbauen und entsprechend mappen.

Ich werde dann auch SleepEx verwenden, damit ich später für Completion Ports besser performen kann.

Yield()
->Windows SleepEx(0, true)
->Linux std::this_thread::yield()

_________________
"Wer die Freiheit aufgibt um Sicherheit zu gewinnen, der wird am Ende beides verlieren"
Benjamin Franklin

Projekte: https://github.com/tak2004


Nach oben
 Profil  
Mit Zitat antworten  
 Betreff des Beitrags: Re: @Radon Framework
BeitragVerfasst: Di Mai 20, 2014 14:03 
Offline
DGL Member
Benutzeravatar

Registriert: Do Sep 02, 2004 19:42
Beiträge: 4158
Programmiersprache: FreePascal, C++
Gibts nen Grund, warum du den () Operator für das Indexing deines Arrays verwendest anstatt dem dafür vorgesehenen [] Operator?

grüße

_________________
If you find any deadlinks, please send me a notification – Wenn du tote Links findest, sende mir eine Benachrichtigung.
current projects: ManiacLab; aioxmpp
zombofant networkmy photostream
„Writing code is like writing poetry“ - source unknown


„Give a man a fish, and you feed him for a day. Teach a man to fish and you feed him for a lifetime. “ ~ A Chinese Proverb


Nach oben
 Profil  
Mit Zitat antworten  
 Betreff des Beitrags: Re: @Radon Framework
BeitragVerfasst: Di Mai 20, 2014 17:44 
Offline
DGL Member
Benutzeravatar

Registriert: Di Mai 18, 2004 16:45
Beiträge: 2621
Wohnort: Berlin
Programmiersprache: Go, C/C++
Der Array kann mehrere Dimensionen haben z.B. bla(x,y,z)=value;
edit:
Allerdings überlege ich schon das ein zu dampfen, da ich es eigentlich nie verwende.
Die Array Klasse ist größten Teils von .Net/Java übernommen.

_________________
"Wer die Freiheit aufgibt um Sicherheit zu gewinnen, der wird am Ende beides verlieren"
Benjamin Franklin

Projekte: https://github.com/tak2004


Nach oben
 Profil  
Mit Zitat antworten  
 Betreff des Beitrags: Re: @Radon Framework
BeitragVerfasst: Mi Mai 21, 2014 08:47 
Offline
DGL Member
Benutzeravatar

Registriert: Do Sep 02, 2004 19:42
Beiträge: 4158
Programmiersprache: FreePascal, C++
Mhm, das ergibt sinn. Eigentlich ne schicke Lösung, das sollte ich vielleicht in meinen Linalg Klassen mal so implementieren, bisher gebe ich da aus operator[] ein static_cast auf einen Vektor mit geringerer Dimension zurück, was dann über matrix[i][j] funktioniert (sogar recht effizient), außerdem habe ich eine component-Methode, die im prinzip das gleiche macht wie dein operator() (gibt der ne schreibbare referenz zurück?).

grüße,

_________________
If you find any deadlinks, please send me a notification – Wenn du tote Links findest, sende mir eine Benachrichtigung.
current projects: ManiacLab; aioxmpp
zombofant networkmy photostream
„Writing code is like writing poetry“ - source unknown


„Give a man a fish, and you feed him for a day. Teach a man to fish and you feed him for a lifetime. “ ~ A Chinese Proverb


Nach oben
 Profil  
Mit Zitat antworten  
 Betreff des Beitrags: Re: @Radon Framework
BeitragVerfasst: Mi Mai 21, 2014 15:50 
Offline
DGL Member
Benutzeravatar

Registriert: Di Mai 18, 2004 16:45
Beiträge: 2621
Wohnort: Berlin
Programmiersprache: Go, C/C++
Da sind die operator überladungen.
Ich hab das nie benutzt, deswegen überlege ich das entweder aus zu lagern oder einfach zu entfernen.
edit:
Das Synchronize gibt es in der Klasse schon lokal nicht mehr, weil das kein Sinn macht.
.Net macht das so aber ich find das Blöd, ich mach nie was so granular thread safe.
Die Klasse ist ein 1D Array welcher auf mehrere Dimensionen erweiterbar ist, weil beim erstellen schon die größe jeder Dimension fest steht, das ist ein Equivalent zu C mehrdimensionale Arrays.
Für sowas Algorithmen zu schreiben ist total ätzend, weil will man Sort für eine Dimension machen oder über alle Daten oder nur über Teile von einer Dimension.

_________________
"Wer die Freiheit aufgibt um Sicherheit zu gewinnen, der wird am Ende beides verlieren"
Benjamin Franklin

Projekte: https://github.com/tak2004


Nach oben
 Profil  
Mit Zitat antworten  
 Betreff des Beitrags: Re: @Radon Framework
BeitragVerfasst: Mi Mai 21, 2014 16:18 
Offline
DGL Member
Benutzeravatar

Registriert: Do Sep 02, 2004 19:42
Beiträge: 4158
Programmiersprache: FreePascal, C++
Hm, die Operatoren müssten mit C++11 und variadic templates doch hübscher gehen …

Wenn man das was du in deinem Edit schreibst noch weiter denkt, endet man irgendwann bei numpy, wo man views auf unterschiedliche Arrayteile bekommen kann. Dann erlaubt man Sort nur auf einer eindimensionalen View… Aber letztenendes ist das wohl die falsche Richtung für eine Spielengine.

grüße

_________________
If you find any deadlinks, please send me a notification – Wenn du tote Links findest, sende mir eine Benachrichtigung.
current projects: ManiacLab; aioxmpp
zombofant networkmy photostream
„Writing code is like writing poetry“ - source unknown


„Give a man a fish, and you feed him for a day. Teach a man to fish and you feed him for a lifetime. “ ~ A Chinese Proverb


Nach oben
 Profil  
Mit Zitat antworten  
 Betreff des Beitrags: Re: @Radon Framework
BeitragVerfasst: Mi Mai 21, 2014 17:28 
Offline
DGL Member
Benutzeravatar

Registriert: Di Mai 18, 2004 16:45
Beiträge: 2621
Wohnort: Berlin
Programmiersprache: Go, C/C++
Ich schreibe keine Spiele Engine sondern ein Framework für engines, was es eigentlich dein Argument noch mehr bekräftigt ^^
Allerdings hab ich ja zum Glück geschrieben, dass ich entweder es aus lager oder entferne.
Aktuell versuche ich eigentlich kein Code raus zu werfen sondern alles auf einem Stand zu bringen, mit Unit Tests und Ressourcen Tests.

Irgendwie schaffe ich es aber immer wieder mich zwischen durch mal ablenken zu lassen.
So wollte ich z.B. endlich mal mein DXT Kompressor fertig machen und dabei hab ich dann ForEach gebaut und weil das so lahm war hab ich dann halt mal den ThreadPool teilweise auf den geplanten Stand gebracht(aktuell fehlen noch Completion Ports für IO).
Da ich das ja alleine als Hobby betreibe dauert das halt alles länger und solche Ablenkungen kommen häufiger vor ^^

_________________
"Wer die Freiheit aufgibt um Sicherheit zu gewinnen, der wird am Ende beides verlieren"
Benjamin Franklin

Projekte: https://github.com/tak2004


Nach oben
 Profil  
Mit Zitat antworten  
Beiträge der letzten Zeit anzeigen:  Sortiere nach  
Ein neues Thema erstellen Auf das Thema antworten  [ 60 Beiträge ]  Gehe zu Seite Vorherige  1, 2, 3, 4  Nächste
Foren-Übersicht » Sonstiges » Meinungen zu den Projekten


Wer ist online?

Mitglieder in diesem Forum: 0 Mitglieder und 15 Gäste


Du darfst keine neuen Themen in diesem Forum erstellen.
Du darfst keine Antworten zu Themen in diesem Forum erstellen.
Du darfst deine Beiträge in diesem Forum nicht ändern.
Du darfst deine Beiträge in diesem Forum nicht löschen.
Du darfst keine Dateianhänge in diesem Forum erstellen.

Suche nach:
Gehe zu:  
cron
  Powered by phpBB® Forum Software © phpBB Group
Deutsche Übersetzung durch phpBB.de
[ Time : 0.138s | 17 Queries | GZIP : On ]