Generelle Konzeptfrage

Öffentlicher Testrealm (PTR)
25.09.2017 11:19Beitrag von thE
@Hebalon: Größere Zahlen machen SEHR wohl einen RIESIEGEN Unterschied aus.

Eine CPU ist generell gesagt mal etwas sehr dummes was nur eine Hand voll logische Operationen kann.
Und große Zahlen brauchen viel Leistung. Deswegen ist Prim-Zahlen berechnen auch sehr schwer (die richtig Hohen dann).

Deswegen war es (und vielleicht noch immer) die Berechnung vom DMG der das Game zum Stocken brachte.
Leute haben dann AreaDmg rausgenommen, damit weniger berechnet werden musste, etc.
Wie gesagt, das war vor 1em Jahr. Habe mal eine Pause gemacht für eine Zeit lang..

Dadurch dass das ganze AM Server berechnet wird, was bringt da ein 64bit Client mehr? Vorallem, Leute spielen das Spiel mit Top Hardware (ich habe ja selbst alles auf SSD und 16GB RAM).

Auch kommt es auf die Builds drauf an. Zb war der static-Charge Monk ein Albtraum. Oder auch die Hexendoktoren mit den Sachen, was erst in gewisser Zeit Schaden verursacht.

Danke dass du dich nochmals zu Wort meldest.
Es ist immernoch so dass es Wirkung zeigt wenn alle die es nicht brauchen Areadmg rausnehmen.
Als Tipp für dich, wenn du wieder aktiv spielen solltest.
Plus 1 für deinen Beitrag.
25.09.2017 11:19Beitrag von thE
@Hebalon: Größere Zahlen machen SEHR wohl einen RIESIEGEN Unterschied aus.

Eine CPU ist generell gesagt mal etwas sehr dummes was nur eine Hand voll logische Operationen kann.
Und große Zahlen brauchen viel Leistung. Deswegen ist Prim-Zahlen berechnen auch sehr schwer (die richtig Hohen dann).

Deswegen war es (und vielleicht noch immer) die Berechnung vom DMG der das Game zum Stocken brachte.
Leute haben dann AreaDmg rausgenommen, damit weniger berechnet werden musste, etc.

25.09.2017 13:44Beitrag von PaulLoutman
Man muss die Sache mal ganz einfach betrachten, jeder Prozessor kann jede Aufgabe nur nacheinander bearbeiten. Wären z.B. die Schadenzahlen nur im einstelligen Bereich müssten weniger Daten durch den Prozessor wandern da diese nur maximal eine Länge von 8 bits hätte pro Zahl. Wären die Zahlen über 256 sind es schon das Doppelte was durch den Prozessor gejagt wird an Daten. Da wir aber schon im Billardenbereich hin und wieder kommen sind wir schon beim 5fachen der Datenmenge wie bei einstelligen. Dieser Mehraufwand kann sich schon auswirken.

Da ich mich als Grüner zurückhalten muss, steige ich aus der Diskussion aus. Bringt nichts. Alternative Fakten schlagen wieder zu. Schade.

Der Vergleich mit Primzahlen hinkt komplett. Natürlich brauche ich sehr, sehr lange, wenn ich testen will, ob eine sehr, sehr große Zahl eine Primzahl ist. Weil ich dann verdammt viele Rechenoperationen machen muss. Das liegt aber nicht primär an der Größe der Zahl, sondern an der Komplexität des Problems, das mit zunehmender Größe der Eingabe (die Größe der zu testenden Zahl) sehr schnell ansteigt (nicht linear oder polynomiell, sondern exponentiell).

Das mit der Datenmenge ist auch falsch. Im Code wird ein bestimmter Datentyp verwendet, der mit an Sicherheit grenzender Wahrscheinlichkeit eine feste Größe hat. Ob ich dann nun $00 00 00 01 oder $FF FF FF FF hin und herkopiere und in einer Rechnung verwurste, ist egal.

Eine Multiplikation (oder auch sehr viele davon) ist eine einfache Sache. Und solange wir nicht mit Big-Number-Datentypen anfangen (was in D3 sicherlich nicht der Fall ist), ist die Dauer eine Addition oder Multiplikation unabhängig davon, welcher Wert in einer Variable vom Typ Integer, Float, Double, wasweißich steckt. Möglicherweise, wenn man ganz tief in die Architektur einsteigt, gibt es einige Effekte. Aber diese sind ganz sicher nicht der Flaschenhals und die Ursache für die Lags.

Nochmal. Dass das Game stockt, liegt nicht an der Größe der Zahlen, sondern an der Masse der Zahlen, und wie mit Flächenschaden etc. umgegangen wird. Und wie oft ein DoT tickt. Deshalb nimmt man Flächenschaden raus. Um weniger Zahlen zu haben. Nicht kleinere.

Ein bloßes Reduzieren des Schadens (um Faktor 10 oder meinetwegen noch mehr), ohne die grundlegenden Mechaniken zu ändern, wie der Schaden berechnet wird, ändert nichts an den Lags. Gar nichts.

Und das ist kein Glaube meinerseits, das ist Fakt. Oder aber die beiden promovierten bzw. habilitierten Informatiker, mit denen ich heute Mittag gesprochen habe, sind auch dumm und haben keine Ahnung. Kann auch sein. Denn was andere im Internet schreiben, muss ja richtig sein. Sonst stünde es ja nicht im Internet.
Nochmal: Wenn es in Grift >115 STOCKT, dann spiel das ganze mal auf GRift 90 und dort stockt es nicht..

Liegt sicher nicht an den riesen Lebenszahlen der Monstern.. Nein, nur an den Berechnungen, welche zwar auf Grift 90 ident ist wie in Grift 115, aber Hey, das ist es nicht, weil du es sagst.

Wahrscheinlich wird es eine Kombination von beiden sein und deswegen erst bei höheren Grifts auftauchen. Auch wenn du dir noch immer einreden willst, dass es egal ist MIT was man rechnet (ist es nicht). Also wieviele Bytes die Zahlen dann haben.
Weil die muss man auslesen und wieder wo zurückschreiben und das kostet auch Zeit. Desto höhere Zahlen, desto mehr Bytes braucht man.. (frag das mal deine IT-Spezis)

Wie gesagt, die Codebasis ist fürn !@#$%, weil das Game NIE auf das alles ausgelegt war (zB AreaDMG gab es in Vanila-D3 nichtmal).
26.09.2017 14:13Beitrag von thE
Wenn es in Grift >115 STOCKT, dann spiel das ganze mal auf GRift 90 und dort stockt es nicht..


Das halte ich jetzt für einen sehr unrepräsentativen Vergleich. Ich hab zwar wenig bis keine Ahnung von IT aber ich weiß wann man Ergebnisse vergleichen und zusammenfassen darf und wann nicht.

Ich gehe jetzt mal davon aus, dass du @tHe GRIft 115 und GRift 90 mit demselben Build oder derselben Gruppe spielst?! Falls nicht, ist meine ganze Grundannahme falsch und du/ihr könnt den restl. Post gerne vergessen.

Wenn du aber dasselbe Setup hattest und für den Vergleich mal das identische GRiftlevel läufst, passiert folgendes. Aufgrund der deutlich niedrigeren HP der Mobs auf 90 gegenüber 115, benötigt eine Gegnergruppe x Berechnungschritte bevor die Gegner alle tot sind, ergo keine Berechnung mehr nötig ist. Auf 115 benötigt dieselbe Gegnergruppe dann 10x Berechnungsschritte. Hier ist sogar die Wahrscheinlichkeit noch deutlich höher mehr Gegner als auf 90 im Pulk zu haben, eben weil auch der Trash nicht so schnell aus den Latschen kippt. Damit erhöht sich die Anzahl der nötigen Berechnungen von 90 auf 115 um eine vielfaches der Schritte. Und das ist es was dann zum Ruckeln führt. Nicht die Zahl als solche.

Daher würde ich bitten, bei entsprechenden Vergleichen auch eine Vergleichsbasis zu schaffen. Denn ich gehe davon aus, dass bei entsprechender Reduktion des ausgehenden Schadens die Ruckler auch auf niedrigeren GRiftstufen zu reproduzieren sind. Denn ansonsten hätte es ja in früheren Patchen wo 80 die Grenze war, niemals Ruckeln dürfen. Da sagt meine Erinnerung aber etwas anderes.
leute wieso kapiert ihr das nicht???
der lag wird durch die massiven dmgbuffs verursacht! bis einem auffällt, dass man als solo supersayajin dd necro genau den gleichen lag hat wie der lvl 1 barbar. ab diesem zeitpunkt wird der lag nichtmehr durch dmg verursacht, sondern durch die angestiegene griftstufe, i.e.S. durch die angestiegene monster hp (die übrigens praktisch "linear" ansteigt). zuviel darf/sollte man darüber aber nicht nachdenken, weil ja der lag nicht praktisch "linear" zur fallenden stufe/fallenden hp abnimmt...
der grund warum es eindeutig an der größe der zahl hängt (wie immer im richtigen leben gehts es immer um die größe) sieht man auch am beispiel des blizzards hqs. als der necro eingeführt wurde, und seine "gebrechlichtkeit" im verbindung mit des dhs "totgeweiht-gevater tod" eine echt große zahl generierten, sind alle blizzardserver sofort in die luft geflogen, so ein monsterlag gab das... deshalb konnten sie den bug auch nur so spät fixxen :/

@ hebalon: auch wenn du nicht daran zu glauben scheinst, studien belegen, dass alles was im internet iwo steht, tatsächlich richtig ist. gab letztens eine reportage darüber. wenn das nicht so wäre, gäbe es keinen trump, kim, oder die afd, und die menschheit wäre somit verloren.

@the: dir empfehle ich : youtube->die musik der primzahlen-wdr, super ez zu verstehen ;)
natürlich ist der wdr als quelle nicht so hochwissenschaftlich wir rt-deutsch, aber vll reichts ja trotzdem
25.09.2017 15:15Beitrag von Hebalon
Das mit der Datenmenge ist auch falsch. Im Code wird ein bestimmter Datentyp verwendet, der mit an Sicherheit grenzender Wahrscheinlichkeit eine feste Größe hat. Ob ich dann nun $00 00 00 01 oder $FF FF FF FF hin und herkopiere und in einer Rechnung verwurste, ist egal.


Ja, davon ist auszugehen des es feste Größen gibt, nun hat aber der DH/Nec expolit gezeigt was für epische Zahlen überhaupt zusammen kommen können, so das ich da nicht mehr so sicher bin und denke das es ein dynamisches System gibt. Denn wenn selbst für kleine Schadenszahlen auf ca. Level 1-8 dann jeweils so um 10 Bytes (FF.FF.FF.FF.FF.FF.FF.FF.FF.FF) adressiert sind für jede Schadensbrechung halte ich das für seltsam.

http://i.imgur.com/BHCjgu7.png

Im Endeffekt weis das nur Blizzard wie das abläuft, ich gehe aber davon aus das stark kleiner Schadenszahlen nur noch im Millionenbereich, die Berechnungen ein Tick flotter machen können. Denn wenn es z.B. richtig feste Werte sind, sagen wir 3 Bytes maximal (FF.FF.FF) was bis 16 Millionen irgendwas geht, kann das schon die Rechenleistung verbessern. Denn weniger Daten und da muss man kein IT Genius sein, heist auch schneller Berechnung.

Das der Hauptgrund aber die Menge der Zahlen ist habe ich nie angezweifelt, aber selbst du musst doch auch verstehen, das wenn ich die Datenmenge verkleinere, das die Berechnung dann zwangsweise schneller gehen muss. Ob das ausreicht mag auf einen ganz anderen Blatt stehen.

Einfaches Beispiel: 1000 Bilder umwandeln in ein anders Format, Ursprungsgröße 10MB pro Bild. Beispiel 2: 5MB pro Bild, was wird wohl schneller fertig sein?

Natürlich sind Schadenszahlen nur im bit und byte-Bereich, aber wenn tausende in der Sekunde zusammen laufen dann noch hunderte Spieler auf den Servern sich rum tummeln und man z.B. die Schadenszahlen in ihrer Gesamtheit von z.B. 8 Bytes (FF.FF.FF.FF.FF.FF.FF.FF) fest adressiert auf 6 Verkleinert, sind das 25% weniger Daten.
Ich weis nicht was du deine IT-Gurusie gefragt hast, aber wenn das keinen unterschied machen soll, läuft irgendwas falsch in der IT-Branche. Das wenn ich die anfallenden Daten um 25% verringern aber die Berechnung dann immer noch gleich lange dauern, dann ist irgendwo der Wurm drin. Zumindest muss man mir plausible erklären warum denn halt nicht.

Mir persönlich kann es egal sein, da ich weder Builds noch überhaupt die dafür erforderlichen Grift-Höhe bewältigen will, wo lags mir Probleme bereiten könnten. Einziges mal wo ich das massiv hatte, ist wohl behoben worden. Damals meinte man auch zu mir, nimm mal bitte den Flächenschaden raus, deshalb legs es - dann stellte sich aber raus, das war nicht das Problem, weil Flächenschaden raus nehmen nichts änderte. Damals lag es an "Schaden über Zeit", das zu viele Ticks in der Sekunde, auf zu vielen Gegner und dann noch mehrfach belegt werden konnte, so das es zu astronomische Berechnungen führte. Das gibs heute nicht mehr.
Jetzt den Schaden um den Faktor 100 oder 1000 zu verringern kann aber, bei denen die damit Probleme haben zu Verbesserungen führen. Ob und wie stark weis nur Blizzard, schließlich muss der aufwand den nutzen auch gerecht werden. Und sicher haben die interne Test dazu gemacht.
Ich poste einfach mal was von den Devs. Ist zwar schon was älter, aber an der Gültigkeit dürfte sich nichts geändert haben

https://us.battle.net/d3/en/blog/19889980/patch-230-developer-qa-transcript-9-8-2015

It is also worth saying that most of our damage and health calculations on the server are done in floating point numbers. Computationally, the expense between large and small floats is the same, and most of the expense on the server is usually the raw quantity of the calculations we are trying to do rather than values stored in the floats themselves.


Tut mir leid, PaulLoutmann, aber dein Posting zeigt glasklar, dass du nicht die leiseste Ahnung davon hast, worüber du schreibst. Nein, der Wechsel auf 6-Byte-Datentypen (sofern es sowas überhaupt gibt, mir ist da nichts bekannt) bringt keinen Geschwindigkeitsvorteil. Stichwort Registergröße. Und mit 3 Byte zu rechnen ist ungefähr genauso sinnvoll wie an einem Auto ein Rad abzuschrauben, um Gewicht zu sparen, um die Höchstgeschwindigkeit zu erhöhen.
@Thread: Sehe ich genauso, meine Meinung diesbezüglich sollte ja hinreichend bekannt sein und ich/wir predigen das nun auch nicht gerade erst seit gestern runter.

@OT: Die Masse an Hits pro Zeiteinheit sind und waren auch schon immer das Problem, das hat direkt nichts mit der eigentlichen Höhe der Zahlen zu tun, daher tritt es auch ab gewissen Höhen erst auf, weil die Gegner eben mehr Hits fressen bis sie umfallen, 100 Mrd. Schaden sind in Stufe 50 und Stufe 110 exakt gleich, nur, dass die Gegner eben auf 50 direkt umfallen und auf 110 nicht, somit wirken sich Werte wie AD oder allgemein extreme AOE-Builds (Fledermäuse bspw.) umso mehr aus.
Problem noch immer da: https://us.battle.net/forums/en/d3/topic/20759255911

Beim letzten Video stockt es nach 30 seks.. Da hat man schon soviele Hits bei sovielen Monstern, dass es so stockt?
Der Sinn hinter den Buffs ist doch ganz einfach und war vorhersehbar.

hier der Grund: Geld

man erschafft eine neue klasse die man extra kaufen muss, die dann natürlich erstmal etwas stärker ist als andere, die meisten wollen immer das spielen was auch grade am stärksten ist, also steigen die verkaufszahlen.
Damit das spiel aber nicht auf dauer unbalanced wirkt muss dieser zustand nach der ersten großen kaufwelle natürlich wieder behoben werden ohne dass die zahlenden sich beschi**en fühlen durch nen nerf. also werden die anderen klassen nachgezogen.
das nennt man Marktwirtschafft, irgendwie muss D3 halt auch irgendwann mal etwas geld reinbringen wenn schon ebig dafür server stehen, neue patche kommen und Programmierer und Server bezahlt werden müssen.
ingame shop mit kosmetik items bringt nich wirklich viel, und ingame shop ala pay2win ist mist. also ich kann blizz verstehen
28.09.2017 04:11Beitrag von Sethgecko
Damit das spiel aber nicht auf dauer unbalanced wirkt muss dieser zustand nach der ersten großen kaufwelle natürlich wieder behoben werden ohne dass die zahlenden sich beschi**en fühlen durch nen nerf.

Oder:
Es geht einfach nur darum das ALLE Spieler an Edelsteine der Stufe 132 kommen können und nicht nur die Spieler die einen "Fehler" der Spielmechanik ausgenutzt haben.

28.09.2017 04:11Beitrag von Sethgecko
hier der Grund: Geld

In diesem Fall könnte es die Kritik aus dem Forum sein.
Soll ich dir ein paar Beiträge raussuchen?
26.09.2017 15:10Beitrag von ALDEBARAN
@ hebalon: auch wenn du nicht daran zu glauben scheinst, studien belegen, dass alles was im internet iwo steht, tatsächlich richtig ist.

Ist das Ironie?

Diese Studie würde ich gerne sehen. Selten habe ich so einen Schmarn gehört.
Wenn dem so wäre stimmst du doch sicher zu, dass die Erde eine Scheibe ist.

Steht immerhin im Internet:
https://theflatearthsociety.org/home/

25.09.2017 15:15Beitrag von Hebalon
Das mit der Datenmenge ist auch falsch. Im Code wird ein bestimmter Datentyp verwendet, der mit an Sicherheit grenzender Wahrscheinlichkeit eine feste Größe hat. Ob ich dann nun $00 00 00 01 oder $FF FF FF FF hin und herkopiere und in einer Rechnung verwurste, ist egal.

Da Hebalon's Beitrag recht lang ist nur mal diesen Abschnitt hier. Er hat völlig recht mit seiner gesamten Aussage! Die Größe der Zahlen wirkt sich definitiv NICHT auf die Performace des Spiels aus. Dafür müssten Zahlen generiert werden, die ein Diablo 3 nicht einmal nur im Ansatz erreicht.

Anspruchsvoll ist die Komplexität und Menga an Operationen, die "auf einmal" durchgeführt werden müssen.

Aber glaubt doch was ihr wollt. Ich gehe sicher auf keine Diskussion mit thE und seinen äußerst faszinierenden Fachwissen ein.
04.10.2017 12:48Beitrag von Reiterfuchs
Dafür müssten Zahlen generiert werden, die ein Diablo 3 nicht einmal nur im Ansatz erreicht.
Gab es mit dem Necro/DH Exploit, wenn man sich die Videos dazu anschaut, kommt auch immer ein kurzer Lag, dann machts Puff und der Bildschirm ist leer, entspricht dem maximal möglichen Schaden in D3 ;)
26.10.2014 15:21Beitrag von puzzles
Klar kommt die breite Masse der Spieler nicht über Grift 45+ und wir sind euch deshalb (verständlicherweise) egal. Trotzdem macht es einfach keinen Spaß wenn es an einem Sonntag gegen 15Uhr in Grift 50 bereits bei 5 blauen Gegnern ohne Elektrisiert oder dergleichen eine Minute Standbild gibt.

Waren die Zahlen früher .... grösser?

27.10.2014 14:02Beitrag von Killerbug
Ich verstehe auch nicht ganz was die Höhe des GRifts mit der Performance zu tun haben soll, ändern sich da die Effekte oder wie? (mehr Blitze bei elektrisiert? Ist mir bisher nicht aufgefallen).

....
04.10.2017 13:34Beitrag von Jake
26.10.2014 15:21Beitrag von puzzles
Klar kommt die breite Masse der Spieler nicht über Grift 45+ und wir sind euch deshalb (verständlicherweise) egal. Trotzdem macht es einfach keinen Spaß wenn es an einem Sonntag gegen 15Uhr in Grift 50 bereits bei 5 blauen Gegnern ohne Elektrisiert oder dergleichen eine Minute Standbild gibt.

Waren die Zahlen früher .... grösser?

27.10.2014 14:02Beitrag von Killerbug
Ich verstehe auch nicht ganz was die Höhe des GRifts mit der Performance zu tun haben soll, ändern sich da die Effekte oder wie? (mehr Blitze bei elektrisiert? Ist mir bisher nicht aufgefallen).

....
Das ist auch drei Jahre her, da war ich noch blauäugig und das Laggen ein absolut neues Phänomen, vor allem, weil ich zu der Zeit hauptsächlich solo mit FB gepusht habe. Inzwischen gab es ja genügend nachvollziehbare und vor allem reproduzierbare Beweise dafür, dass es direkt mit Grift-Höhe zusammenhängt.

Schaut man sich den nächsten Post der alten Konversation sowie meine Antwort darauf an, wird auch genau erklärt, womit das damals unter anderem zusammengehangen hat.
04.10.2017 13:15Beitrag von Killerbug
04.10.2017 12:48Beitrag von Reiterfuchs
Dafür müssten Zahlen generiert werden, die ein Diablo 3 nicht einmal nur im Ansatz erreicht.
Gab es mit dem Necro/DH Exploit, wenn man sich die Videos dazu anschaut, kommt auch immer ein kurzer Lag, dann machts Puff und der Bildschirm ist leer, entspricht dem maximal möglichen Schaden in D3 ;)

Diese Situation mag so gewesen sein, ich habe den Exploit nie genutzt.

Aber der Delay entsteht nicht durch die Höhe der Zahlen selbst sondern dadurch, dass diese auf die Umgebung der ursprünglichen Wirkung über die DH-Fertigkeit umgerechnet werden mussten. Die Größe der Zahlen mag also ein Faktor sein, sind allerdings dennoch nicht der ausschlaggebende Punkt. Da bin ich mir sicher.
Najo, es musste ja auch wieder der Schaden auf allen Gegnern berechnet werden.
Damit das ordentlich funktionieren konnte, musste man bestenfalls alles mögliche zusammen ziehen, somit viele Ziele, viele Hits durch die Verbreitung der hohen Zahl auf alle Gegner.

Ähnliche Situation lässt bspw. auch mit der Exploding Palm vom Monk reproduzieren, sofern möglichst viele von der Explosion erwischt werden und sich so entsprechend eine Kettenreaktion bildet, hast auch immer nen kurzes Standbild, bis der große Badabumm kommt.

Nimm an der Unterhaltung teil!

Zurück zum Forum