Ergebnis 1.061 bis 1.080 von 1418

Thema: Technik-Sammelthread für Probleme und Antworten

Baum-Darstellung

Vorheriger Beitrag Vorheriger Beitrag   Nächster Beitrag Nächster Beitrag
  1. #11
    Zitat Zitat von elvissteinjr Beitrag anzeigen
    Also bei mir läuft ja jetzt alles. Destiny wollt ich jetzt nicht auch noch reinhauen und schon gar nicht kurzfristig lernen damit umzugehen(ist Contestprojekt, Abgabe: heute*hust*). Achja, ich hoffe übrigends dass du nicht extra für Zählschleifen den Destiny brauchst, würde mir sorgen machen.^^'
    Und selbst wenn ein PP den Frame abwartet, ohne Wait wird das auf Singlecores oft unverhältnismäßig lahm.

    Die Frage ist ja, wie man die klassische direkte Positionsabfrage denn für die Menge sinnvoll aufteilen könnte. Wenn ich das ganze jetzt mit Flächen gebraucht hätte, wär's erst recht was geworden.

    Aber naja, bei läuft ja jetzt alles soweit. Hoffe nur dass wirklich schwache Rechner da nicht irgendwie trotzdem überfordert werden(die Schalter sind ja nicht die einzigen Sachen die als PP laufen), hab sowas aber leider nicht mehr im Haus.
    Nein, natürlich kann man kopf- und fußgesteuerte Schleifen im Maker nachbauen - keine Frage. Damit dann halt auch Zählschleifen. Aber dennoch ist es wesentlich komfortabler, wenn man sie direkt benutzen kann - darauf wollte ich eigentlich hinaus. Rein »theoretisch« kann man wirklich vieles mit dem Maker nachbilden - mehr oder weniger aufwändig, und mehr oder weniger performant. Und gerade Koordinaten getten scheint für die Maker-Engine echt schwerstarbeit zu sein. Hatte das mal getestet indem ich die Zeit gemessen habe, wie lange es dauert 500.000 mal die Koordinaten eines Events zu getten. Dabei hatte ich einmal komplett die Maker-Engine verpflichtet, einmal DynRPG für das getten der Koordinaten (dabei die Schleife per Maker Engine) und einmal die komplette Schleife in DynRPG/C++. Zeit war Maker > Maker/DynRPG > DynRPG/C++ (Wobei DynRPG/C++ extrem schnell war ( <1s ) )
    Wobei ich glaube, dass das jetzt nicht sonderlich neu und interessant war xDD

    Und normalerweise sollte es - wie Cherry schon sagte - egal sein, ob Dual- oder Singlecore, solange die Pro-Kern-Leistung hoch genug ist. Wobei ich dir Recht gebe, dass beim DualCore der Vorteil ist, dass Windows-Hintergrunddienste auf den zweiten Kern verteilt werden können.

    Was vor allem beim Maker noch zu beachten ist, ist dass JEDE Variablen-Operation die gleiche Zeit zu kosten scheint. Egal ob "+", "-" usw. Das interessante: Die Variablen-Range-Funktion braucht anscheinend auch genauso lange, wie eine normale Variablen-Operation an einer einzigen Variable o.O

    Und bzgl. sinnvoller Aufteilung kommt das wohl auch ganz auf die Aufgabe des Skriptes an.

    Zitat Zitat von Cherry Beitrag anzeigen
    Ob Singlecore oder Hexadecacore macht beim Maker keinen Unterschied, alles wird da auf einem Prozessorkern ausgeführt.
    Hexadecacore = 16 Kerne? ^^

    PeAcE
    MorDen

    Geändert von Morden (17.06.2013 um 08:06 Uhr)

Berechtigungen

  • Neue Themen erstellen: Nein
  • Themen beantworten: Nein
  • Anhänge hochladen: Nein
  • Beiträge bearbeiten: Nein
  •