Es wäre vielleicht - aufgrund der heute viel besseren Prozessoren - möglich, gerade im Krieg einen Monte-Carlo-Algorithmus einzuziehen
Es wäre vielleicht - aufgrund der heute viel besseren Prozessoren - möglich, gerade im Krieg einen Monte-Carlo-Algorithmus einzuziehen
Oder anders gesagt, die KI soll nicht mehr so berechenbar sein, da sie dann keine Exakten Entscheidungen mehr treffen würde. Wäre nicht schlecht.
Die KI könnte vor allem bessere Entscheidungen treffen, was die Angriffsreihenfolge angeht. Wegen der den Kämpfen inhärenten Unschärfe müsste man aber jedes Szenario etwa 10 mal durchprobieren, um zu guten Entscheidungen zu kommen, gerade, wenn viele 40 - 60 Kämpfe dabei sind.
Steht man als Mensch nicht vor den gleichen Problem? Man kann es selbst nur nicht durchprobieren. Ich bin mir sicher mehr wie 10 Durchläufe sind nicht notwendig.
Geändert von rucivfan (23. April 2014 um 12:39 Uhr)
Wie kommst du drauf, dass 10 mal eine gute Zahl ist? Oder dass 40-60 Kaempfe die Unschaerfe erhoehen?Zitat von Peregrin_Tooc
Man kann sehr wohl ein Schlachtergebnis exakt bestimmen in dem man sich einfach Wahrscheinlichkeiten aller diskreten Ergebnisse jedes Kampfen merkt. Man muss zwar im worst case mir exponentieller Komplexitaet klarkommen, in der praxis duerfte das aber kaum ein Problem sein, da man bei mehreren Einheiten meist identische Einheiten mehrfach hat.
Eine optimale Kampfreihenfolge ist aber nicht statisch, denn der beste 2. Angreifer haengt vom Ergebnis des 1. Angreifers ab.
Generell denke ich aber das Optimierungspotential bei der Kampfreihenfolge fuer die KI ist vernachlaessigbar verglichen mit anderen (leider wesentlich komplexeren) taktischen Schwaechen.
Achtung Spoiler:
Die Zahl 10 ist aus der Luft gegriffen, was sinnvolle Stichprobenumfänge angeht habe ich normalerweise ein ganz gutes Gespür.
40-60-Kämpfe erhöhen die Unschärfe, weil Ihr Ausgang unsicherer ist- bei 5 40-60-Kämpfen ist es einfach sehr viel Wahrscheinlicher, dass alle 5 für eine Partei ausgehen - was das Kampfergebnis grob verzerrt - als dass bei 5 90-10-Kämpfen 3 für die unterlegene Partei laufen (was das Ergebnis genauso grob verzerrt).
Die bessere Baustelle wäre aber vielleicht die Stadtverwaltung
Die bessere Baustelle wäre aber vielleicht die Stadtverwaltung
Ich finde das durchgehen der Kampfchancen irgend wie sinnlos. Die Change hängt bisher vom Zufalls-Seed ab und der ist in der Wertreihenfolge fest. Das würde nur wirklich einen Zweck erfüllen, wenn ein echter Zufall vorliegen würde. Die Abhängigkeit vom Seed würde ich nicht entkoppeln wollen.
Bei den Strategischen Entscheidungen sieht es schon anders aus. Dort würde sowas sinn machen. Es muss ja auch irgend wie eine Varietät zwischen den Kis erzeugt werden.
Kleine Verbesserungen sollten aber recht gut machbar sein. Zum Beispiel legt die KI irgendwann fest das sie angreifen wird. Gerade da könnte sie komplett auf Kriegsproduktion umstellen (Einheiten, aber auch Schmieden etc.)
Oder aber sie baut nicht planlos überall alle Gebäude hin, sondern man legt Parameter fest womit die KI eine Stadt zur Prodstadt oder Kommerzstadt aufbaut. Gerade das macht ein Mensch auch und jeder hat versch. Parameter (Anzahl Hügel, Flussfelder usw.) die ihm bei der Entscheidung helfen.
Ich denke man kann der KI gerade da sinnvoll helfen.
Leider habe ich wenig Zeit (und bisher auch nicht eine Zeile Civ-Code angeschaut) um helfen zu können.
Hi,
ich habe hier eine lange Funktion (Sprache: C), der als Argument eine fixe Schrittweite (1-7) übergeben werden kann. Es gibt in der Funktion sehr viele Zeilen der Form „x+=schrittweite+andere variable“
Meint ihr, es könnte sich lohnen 7 Varianten der Funktion anzulegen in der die Schrittweite als feste Konstante (via Makro) definiert wird.
Assemblercode von Additionen der obigen Form kann doch (nat. platformabhängig) in einen schnelleren Befehl kompiliert werden, wenn einer der Summanden beim Komplieren schon bekannt ist, oder?
I.d.r. landet Schrittweite in einem Register. Irgendetwas plus ein Register ist i.d.R. ein sehr schneller Befehl, außer das andere etwas liegt weit weg im Speicher, dann ist aber auch egal ob du ein Register oder eine Konstante addierst. Es kann schon gewisse Effekte geben bei denen eine Konstante besser ist (Register pressure, einfachere out of order execution,...), aber vermutlich bringt es weniger als du denkst. Ich würde erstmal allgemein mit Performance-Analyse schauen ob die Funktion überhaupt interessant ist. Wenn, dann sollte es eigentlich reichen um die Funktion eine andere Funktion mit einem 7fach switch zu bauen, dann hat der Compiler genug Informationen um dort die innere Funktion 7 mal inline mit konstanter Schrittweite zu bauen (überprüfen...).
Achtung Spoiler:
Danke fürs FeedbackIrgendwie hatte die Maschinencodes auch falsch in Erinnerung, denn heute habe gar keine Instruktion gefunden, bei der man
eine Addition vom Typ B = A+ OP + c mit einer zur Kompilerzeit bekannten Konstante definieren kann. Aber da es ja, wie vermutet bei
den Additionen um Adressen eines Arrays geht, könntest du Recht haben, und das ganze eh durch internes Caching, etc komplett überlagert wird.
Da die Funktion verdammt lang ist, dürfte kein Kompiler auf die Idee kommen, bei constanten Übergabeparmetern diese über inline aufzulösen.
Den Einfluss auf die Gesamtlaufzeit kann ich mangels Gesamtprogramm (
"#DEFINE stepwith 1" ersetzt und damit dem Kompiler etwas Spiel zum optimieren gegeben (-O3 war in beiden Fällen aktiviert. Anderenfalls wäre das Resultat ja auch nichtssagend.)
Durch diese kleine Änderung erreiche in (nur für die eine Methode) statt 115 nun 124 fps. Finde ich recht beachtlich
Unterschaetze mal die compiler nicht mit:Danke fürs Feedback
eine Addition vom Typ B = A+ OP + c mit einer zur Kompilerzeit bekannten Konstante definieren kann. Aber da es ja, wie vermutet bei
den Additionen um Adressen eines Arrays geht, könntest du Recht haben, und das ganze eh durch internes Caching, etc komplett überlagert wird.
Da die Funktion verdammt lang ist, dürfte kein Kompiler auf die Idee kommen, bei constanten Übergabeparmetern diese über inline aufzulösen.
Den Einfluss auf die Gesamtlaufzeit kann ich mangels Gesamtprogramm (
"#DEFINE stepwith 1" ersetzt und damit dem Kompiler etwas Spiel zum optimieren gegeben (-O3 war in beiden Fällen aktiviert. Anderenfalls wäre das Resultat ja auch nichtssagend.)
Durch diese kleine Änderung erreiche in (nur für die eine Methode) statt 115 nun 124 fps. Finde ich recht beachtlich
inlined sowohl gcc als auch clang auch 10000 solcher Zeilen problemlos in einen 7er switch. Das dauert zwar mit gcc ein paar Minuten (clang ein paar sekunden), aber dann sind alle konstanten komplett reinoptimiert. Das kannst du mit -S auch recht einfach pruefen. Vermutlich gehts auch irgendwie mit -finline-limit ohne das attribute.Code:__attribute__((always_inline)) static inline
Wenn du einen wirklich dummen compiler hast und es unbedingt C sein muss, dann kannst du die Funktion in ein einzelnes file packen:
rama.in.c:
und dann in dem hauptfile so includen/nutzen:Code:#define FOO_NAME2(x) foo_step ## x #define FOO_NAME(x) FOO_NAME2(x) void FOO_NAME(SW) (int bar*, int baz) { *bar += SW + baz; } #undef FOO_NAME2 #undef FOO_NAME
Aber ich wuerd das dem compiler ueberlassen... oder C++ templates verwenden.Code:#define SW 1 #include "rama.in.c" #undef SW #define SW 2 #include "rama.in.c" #undef SW void foo(const int stepwidth, int *bar, int baz) { switch(stepwidth) { case 1: foo_step1(bar, baz); break; case 2: foo_step2(bar, baz); break; } }
Achtung Spoiler:
Du hast bei den Kompileroptionen recht.Ist es also doch einfacher realisierbar als gedacht.
bläht sich die Lib von ca. 70 kb auf ca. 270kb auf, aber läuft etwas fixer. (Das static musste ich entfernen. Aber das passte ihmo eh nicht zum inline?!)Code:__attribute__((always_inline)) inline
Na was hast du denn erwartet. Das static wuerde ich schon lassen, ansonsten muss er das Symbol trotz inlining noch fuer externe caller (mit beliebigem stepsize) vorhalten. Da sparst du dir zumindest eine instanz des Monsters
Achtung Spoiler:
Die Größenbemerkung war keine BeschwerdeNa was hast du denn erwartet
Ja, es sind Wrapper-Methode mit Switch und eigentliche Funktion in der gleichen Datei definiert. Habs jetzt noch mal probiert und nun klappt es auch mit static-Deklaration.Muss ich beim ersten mal was falsch gemacht haben.
Berechtigungen
Zitieren
