Fehler, Irrtümer, Fragen - Seite 651
Sie verpassen Handelsmöglichkeiten:
- Freie Handelsapplikationen
- Über 8.000 Signale zum Kopieren
- Wirtschaftsnachrichten für die Lage an den Finanzmärkte
Registrierung
Einloggen
Sie stimmen der Website-Richtlinie und den Nutzungsbedingungen zu.
Wenn Sie kein Benutzerkonto haben, registrieren Sie sich
Nein, das ist nicht nur ein Problem des 32-Bit-Terminals. Aber die Lösung für das 32-Bit-Terminal ist heute fertig, während es im 64-Bit-Terminal noch eine Stack-Beschränkung auf 256 KB gibt.
Wenn der Programmierer jedoch die benötigte Stackgröße nicht manuell über eine Eigenschaft angibt, arbeitet EX5 im Terminal mit der Standard-Stackgröße (256 KB).
Über die große Größe.
Jede Variablendeklaration innerhalb einer Funktion (mit Ausnahme von statischen Variablen) belegt Platz auf dem Stack, und die Zuweisung von Platz auf dem Stack für lokale Variablen erfolgt bei jedem Aufruf.
Wenn also eine Funktion 64Kb lokale Variablen hat, reicht der Stack für 3 darin verschachtelte Aufrufe, und bei 4 Aufrufen kommt es zu einem Stack-Überlauf (da ein Teil des Stacks für den internen Bedarf des Terminals verwendet wird). Wenn also ein Bedarf an großen lokalen Daten besteht, ist es besser, dynamischen Speicher zu verwenden - beim Aufruf der Funktion wird dem System Speicher für den lokalen Bedarf zugewiesen (new, ArrayResize) und beim Verlassen der Funktion wird der Speicher gelöscht (delete, ArrayFree).
Ich danke Ihnen für die ausführliche Erklärung. Aber das ist definitiv nicht mein Problem. Ich werde versuchen, einen Test Expert Advisor zu schreiben, um diesen Fehler zu erkennen, da die Funktion, in der die Beine wachsen, bereits gefunden wurde und es keine solchen Volumina gibt (64Kb - 256Kb). Ich werde dann nachts einen Experten mit der Problemfunktion zum Service Desk schicken.
Eine weitere Frage (und eine Bitte, sie in der Hilfe zu erklären) über die Arbeit der gleichen Funktion(CLBufferWrite()).
Wenn ich Informationen direkt aus dem Indikatorpuffer schreibe und das ArrayIsSeries-Flag gesetzt ist (==true), in welche Richtung wird das Eingabe-Array gelesen?
Ich vermute, dass das Kennzeichen ignoriert wird, und außerdem ist nicht klar, von welcher Stelle es gelesen wird? Wird die Verschiebung vom physischen Ende des Arrays oder vom Anfang an gezählt?
Natürlich werde ich auf Wasser blasen, nur für den Fall (ich werde mit ArrayIsSeries== false arbeiten), aber trotzdem ?
offset - diese Funktionen sind wirklich Offsets in Bytes vom Anfang des OpenCL-Puffers und das Array, das an die Funktion übergeben wird, wird von null item kopiert, ohne das ArrayIsSeries Flag zu berücksichtigen.
1) Derzeit ist die Funktionalität der Arbeit mit dem OpenCL-Puffer nicht vollständig und wird hinzugefügt/aktualisiert.
2. offset - diese Funktionen sind eigentlich ein Offset in Bytes vom Anfang des OpenCL-Puffers, während ein Array, das an die Funktion übergeben wird, vom Null-Element aus kopiert wird, ohne das ArrayIsSeries-Flag zu berücksichtigen.
1. Ich habe es irgendwie vermutet... :)
Es gibt also keine Möglichkeit, direkt aus dem Indikatorpuffer in Teilen zu schreiben (vorerst).
Eine gute Idee ist es natürlich, die Startpositionen sowohl in der Quelle als auch im Empfänger zu verschieben. Wie hier:
int ArrayCopy(
void dst_array[], // куда копируем
void src_array[], // откуда копируем
int dst_start=0, // с какого индекса пишем в приемник
int src_start=0, // с какого индекса копируем из источника
int cnt=WHOLE_ARRAY // сколько элементов
);
Bei der Indizierung (Richtung und Einheiten (Bytes/Elemente)) ist in der Hilfe mehr Vorsicht geboten. :)))
--
Vielen Dank für die Antwort, ich schätze Ihre Bemühungen zur Verbesserung der Funktionalität sehr.
Ich freue mich darauf, geduldig auf die Fortsetzung des Banketts zu warten. In der Zwischenzeit muss ich auf der Kante eines Dolches tanzen. :)
Build 597 x64, gerade installiert.
2012.02.23 21:43:24 OpenCLTest (EURUSD,M30) SaveBitmapToFile Fehler beim Öffnen von 'Mandelbrot.bmp'
2012.02.23 21:43:13 OpenCLTest (EURUSD,M30) SaveBitmapToFile Fehler beim Öffnen von 'Mandelbrot.bmp'
2012.02.23 21:43:12 OpenCLTest (EURUSD,M30) SaveBitmapToFile Fehler beim Öffnen von 'Mandelbrot.bmp'
2012.02.23 21:43:10 OpenCLTest (EURUSD,M30) SaveBitmapToFile Fehler beim Öffnen von 'Mandelbrot.bmp'
2012.02.23 21:43:09 OpenCLTest (EURUSD,M30) SaveBitmapToFile Fehler beim Öffnen von 'Mandelbrot.bmp'
2012.02.23 21:43:08 OpenCLTest (EURUSD,M30) SaveBitmapToFile Fehler beim Öffnen von 'Mandelbrot.bmp'
2012.02.23 21:43:07 OpenCLTest (EURUSD,M30) SaveBitmapToFile Fehler beim Öffnen von 'Mandelbrot.bmp'
2012.02.23 21:43:06 OpenCLTest (EURUSD,M30) SaveBitmapToFile Fehler beim Öffnen von 'Mandelbrot.bmp'
Das hat es noch nie gegeben.
// Win7 x64
Build 597 x64, gerade installiert.
Das war früher nicht so.// Win7 x64.
Versuchen Sie, das Beispiel neu zu kompilieren. Ich habe es überprüft - es funktioniert bei mir.
Ich habe es schon hundertmal neu kompiliert und werde jetzt noch einmal neu starten.
... Ich werde noch einmal neu starten.
Nein, hat nicht geholfen.
Renat:
...... Ich habe es überprüft - es funktioniert bei mir.
Bei mir funktioniert es auch, aber alle zehn oder vierzig Zyklen bekomme ich den gleichen Mist:
2012.02.23 23 16:16:43 OpenCLTest (EURUSD,M30) SaveBitmapToFile Fehler beim Öffnen von 'Mandelbrot.bmp'
2012.02.23 23 16:16:42 OpenCLTest (EURUSD,M30) SaveBitmapToFile Fehler beim Öffnen von 'Mandelbrot.bmp'
2012.02.23 23 16:16:36 OpenCLTest (EURUSD,M30) SaveBitmapToFile Fehler beim Öffnen von 'Mandelbrot.bmp'
Nein, hat nicht geholfen.
Das funktioniert bei mir auch, aber alle zehn oder vierzig Zyklen bekomme ich diesen Mist:
Auch entdeckt.
Dies liegt daran, dass die angegebene Datei in zwei verschiedenen Threads ohne Synchronisierung bearbeitet wird und die Datei gelegentlich gesperrt wird:
Da das Beispiel mit dem Bild nur gemacht wurde, um das Prinzip der Arbeit mit OpenCL zu demonstrieren, ist es kein Problem.
Da das Beispiel mit dem Bild nur gemacht wurde, um das Prinzip der Arbeit mit OpenCL zu demonstrieren, ist es kein Problem.