VisualBasic RAM-Ausnutzung und Rechenperformance

Stephan78

Ensign
Registriert
Sep. 2010
Beiträge
162
Hallo,

ich will ein Excel-VBA-Script schreiben, daß Daten aus txt/csv-Dateiein ausließt, weiterverarbeitet und
Ergebnisse in Excel abspeichert.
Mein 32 Bit-Rechner hat 2 Kerne und 3GB RAM und läuft unter WinXP.
Mein VBA ist unter Excel 97.
Meine Fragen beziehen sich auf die Rechengeschwindigkeit.
Soweit ich weiß, arbeitet VBA Excel mit nur 500MB RAM, Excel selbst mit 2 GB RAM.

1)Ich will zum einen sehr große Datenmengen einlesen und weiterverarbeiten.
2)Zum anderen möchte ich eine sehr hohe Anzahl von Rechenoperationen an einer moderaten Datenmenge vornehmen.

Kommen in beiden Fällen nur die 500MB zum Einsatz oder ebenfalls die 2GB von Excel selbst?
Ist für eine hohe Rechenperformance (bei wenigen im RAM abgelegten Daten) überhaupt die RAM-Größe
oder die Menge benutzten RAMs ausschlaggebend oder lediglich der Prozessor mit seiner Taktung?

Vielen Dank im Vorraus für Eure Hilfe!
 
Für die Performance bei Zugriff auf Daten ist es wichtig, den RAM möglichst vollständig ausgelastet zu haben, denn dort kann man am schnellsten auf sie zugreifen. Wenn Excel dir für dein Skript 500MB gibt, dann nutze diese auch komplett (aber rechne damit, dass es in der Realität unter Umständen weniger ist).

Moderne Programmiersprachen haben ein Feature, um die Illusion zu erzeugen, man habe unendlich viel RAM zur verfügung (den Garbage Collector). Ich kenne die Interna von VBA nicht, aber gehe davon aus, dass du dich um die reale Verwaltung des Speichers überhaupt nicht kümmern musst, und deshalb darauf vertrauen solltest, dass VBA das schon richtig für dich macht. Denn wenn nicht, kannst du eh nichts dagegen tun.
 
Zuletzt bearbeitet:
Du willst viel rechnen, dann überleg dir erst mal, ob man die Anzahl der Rechenschritte reduzieren kannst.

Dann: Wie viel Speicher brauchst du wirklich? (In Excel hast du pro Sheet 64k*256 Zellen, das sind 224=16 Mio., wenn du für jede Zelle 100 Byte berechnest (könnte so sogar hinkommen), sind das 1,6 GB).

Muss es Excel sein? Für große Datenmengen nimmt man normalerweise eine Datenbank (z.B. Access oder MSSQL oder MySQL).
Für schwierige Kalkulationen nimmt man auch nicht VBA (zu langsam).

500 MB vs. 2 GB: Aktiv haben kannst du nur die 500 MB (wenn deine Aussage stimmt), im Hintergrund wird Windows aber schon den Rest als Puffer für die HDD nutzen.

Solange alles in RAM passt, ist allein die Prozessorgeschwindigkeit entscheidend (bei GC-Sprachen sollte der Speicher mindestens 2-3 Mal so groß sein wie die maximale aktive Belegung durch das Programm). Falls die Daten, auf die du (quasi) zufällig bzw. oft zugreifen musst, nicht mehr in den RAM passt, hast du verloren. Das kann dir aber nicht passieren, da du selbst mit dem /3GB-Switch nicht so weit deinen virtuellen RAM nutzen werden kannst, dass dir dein physikalischer ausgeht. (Und die Limitationen von VB halten dich schon viel früher auf.)
 
Ich vermute jetzt einfach mal wild, dass wir hier von Datenmengen reden, wo es keinen Sinn macht, vorher groß zu optimieren. Selbst wenn du 100k Zeilen hast, sowas rechnet man auf halbwegs aktueller Hardware bei linearen Operationen locker unter ner Minute.

Probiers einfach mal aus - wenns dir zu lange dauert, kannst du immer noch optimieren.
 
Hallo, danke für die vielen Antworten.

Was ich konkret mache bzw. machen will:

Tests/Backtests von Handelsstrategien auf
Aktien, Indizes ,Optionen. Die Strategien selber sind rechentechnisch bisher meist simpelster Natur.
Ein paar boolsche Ausdrücke werden für jeden Tag berechnet und auf Entry/Exitsignale geprüft.
Der einfachste Fall ist der Test mit nur einer Datenreihe
Tagesdaten. Dabei fallen ca. 50000 Datenpunkte zur Verarbeitung an. Soweit kein Problem.
Bisher habe ich eine fertig verfügbare Software dafür genutzt, die C# basiert ist.
Wenn ich hier Optimierungen bzw. Parameteruntersuchungen gefahren habe,
also immer wieder die selbe Strategie mit veränderten Parametern auf die gleiche historische Zeitreihe
losgelassen habe und dabei zusätzlich noch Daten aus einem txt-File einlesen musste,
ging das Programm schon in die Knie und so ein Test hat gern mal ne halbe Stunde gedauert.
Warum, weiss ich nicht. Nachdem ich nun bei dem Programm den xten Workaround programmieren muss,
weil es für die Sachen, die ich damit mach, eigentlich nicht vorgesehen ist,
will ich nun auf eine Umgebung wechseln, die mir die notwendige Flexibilität gibt.

Wenn ich aber schon die ganze Backtestumgebung selber aufsetzte, will ich gern sicher sein, dass ich früher oder später nicht in irgendein Limit laufe, z.B. laufzeitmäßiger Natur oder Aufgrund zu vieler Daten.

ich möchte später auch mehrere Zeitreihen parallel auswerten, genetische Algorithmen verwenden und mögl.
Online über die Daten laufen lassen, MonteCarlosimulationen fahren, bei denen schnell mal 10000 Durchläufe zusammen kommen, evtl. NN's und SVMs testen und später auch Intradaydaten verwenden.
Dann fährt die Performance vermutlich recht schnell in den Keller, falls dann überhaupt noch was geht.

So, daß ist mal so der Hintergrund der ganzen Sache. Momentan bin ich gerade dabei, mich von der idee zu verabschieden,
VBA zu nutzen, wegen der 500MB. Möglicherweise verwende ich besser Scilab oder Python, die sind beide flink zu programmieren, haben Module für alles, was ich noch so vorhabe und haben nicht diese ätzenden Speicherlimits.
Scilab kenne ich bereits, Python noch nicht. Hättte also nix dagegen, weiterhin mit Scilab zu arbeiten.
Es sei denn, es spricht was dagegen.

Was ist Euer Tip?
 
Zuletzt bearbeitet:
Mein Tip ist: Mach es nicht mit VBA. Das war ursprünglich nur dafür gedacht, Viren in Dokumenten zu verstecken und der Schuster sollte bei seinen Leisten bleiben.

Python klingt nach einer sinnvollen Möglichkeit, aber es gibt auch speziell für solche Fälle gedachte Programmiersprachen wie R. Am Ende ist unter allen Werkzeugen,
die du für deine Arbeit verwenden kannst, immer das am sinnvollsten, dessen Umgang du am besten beherrschst.
 
Zurück
Oben