Hallo zusammen! Erstmal wünsch ich allen nachträglich ein Frohes Fest. Ich hoffe ihr habt euch über die Weihnachtsfeiertage erholen können! Nun zu meiner Frage: Ich arbeite zur Zeit an einem von mir erstellten Programm welches zum lösen einer partiellen Differentialgleichung gedacht ist. Es handelt sich dabei um eine Berechnung für Gleitlager. MEIN PROBLEM IST FOLGENDES: Das Programm arbeitet "quasi" einwandfrei. ABER: es ist viel zu langsam. Ich muss pro Zeitschritt ein lineares Gleichungssystem mit über 2000 Gleichungen lösen. Anschließend wird noch ein nichtlineares Gleichungssystem gelöst. Je Wellenumdrehung benötige ich ca. 180-300 Zeitschritte. Bei manchen Betriebsfällen benötige ich zusätzlich bis zu 100 Wellenumdrehungen, damit eine konvergente Lösung auftritt. Also: Da geht ordentlich Schamlz rein. Generell wurde das Programm schon ordentlich optimiert (Lösungsalgorithmen für dünn besetzte Matrizen, guter "rate" Algorithmus, ect.) Bei einem Test stellte sich heraus, dass der gleiche Code in C um einiges schneller abgearbeitet wird. ICH MÖCHTE DAHER FOLGENDES: Das User Frontend soll in VB.net bleiben. Ist schon ziemlich schön gestalltet und tut seinen Dienst. Den Solver will ich jetzt in ein C-Programm auslagern. MEINE FRAGE IST: - macht das Sinn, oder mache ich das Programm nur unnötig kompliziert? - Wie kann ich "anständig" mit dem C-Programm kommunizieren? Ich dachte mir, dass ich die "Randbedingungen" einfach von VB.net in eine Textdatei exportiere, dann das C-Programm starte und einlese? - Kann ich mit meinem C-Programm irgendwie mit VB.net kommunizieren? Sprich, kann mein C-Programm quasi einen "Interupt" senden, damit das VB.net Programm merkt, dass ein Iterationsschritt abgeschlossen ist, und die Lösung in einem Digramm darstellt? ICH BITTE UM ZAHLREICHE ANREGUNGEN UND BEDANKE MICH IM VORAUS!
Hallo ja du kannst nativen code und .Net mischen. Eine variante ist das erstellen einer DLL mit C oder was anderem was direkt auf der Machschine läuft und die DLL dann aus deinem .Net programm aufrufen. So bekommst beim aufruf eine leichte verzögerung, jedoch wird der code in der DLL nativ und damit wohl etwas fixer ausgeführt. mfg CalM
Eine vielleicht blöde Frage: wenn ich eine DLL in der .NET Umgebung erstelle, benötigt diese dann das .NET-Framework oder wird der Code nativ ausgeführt?
Num schrieb: > Eine vielleicht blöde Frage: > > wenn ich eine DLL in der .NET Umgebung erstelle, benötigt diese dann das > .NET-Framework oder wird der Code nativ ausgeführt? Nein, der Code wird nativ ausgeführt http://blogs.msdn.com/b/codefx/archive/2010/05/02/invoke-native-c-dll-from-net-code.aspx Andere Lösung: Einen der OpenCL/CUDA-Wrapper oder C++AMP http://www.danielmoth.com/Blog/NET-Access-To-The-GPU-For-Compute-Purposes.aspx Die andere Frage: Warum sind so viele Gleichungen nötig bzw. hat mal jemand abgeschätzt, ob und wie das mit der Rechengenauigkeit aussieht?
Also die Reynolds'sche DGL wird mit Hilfe des Finiten Differenzen Verfahrens Approximiert. Damit eventuell auftretende Kavidation im Lager erfasst werden kann, muss das Rechennetz einfach dem entsprechend fein gewählt werden. Es gibt zwar noch ein paar Möglichkeiten die Gleichungen zu reduzieren (geht in Richtung automatische Netzadaptivität) aber das möchte ich mir im Moment ersparen. (wobei dabei eventuell wirklich was zu holen währ). Vielen Dank für deine Links. Werd mich mal reinlesen.
http://mathnetnumerics.codeplex.com/documentation wäre auch noch eine Idee (unterstützt sowohl Intels MKL, als auch AMDs ACML)
Hallo, ich kenne jetzt VB Net nicht so sonderlich gut und erst recht nicht Dein Programm. Bei VB6 habe ich die Erfahrung gemacht, dass der Zugriff auf Objekte schnarchlangsam ist. Mit simplen Arrays läßt sich um den Faktor bis 100 schneller rechnen. Solltest Du also irgendwelche Rechenwerte als Objekte vorliegen haben, dann wäre vermutlich die einfachste Lösung, die benötigten Werte vor irgendwelchen Iterationen in Arrays oder simplen Variablen zu transferieren. Gruß Andreas
Andreas B. schrieb: > ich kenne jetzt VB Net nicht so sonderlich gut und erst recht nicht Dein > Programm. > Bei VB6 habe ich die Erfahrung gemacht, dass der Zugriff auf Objekte > schnarchlangsam ist. Mit simplen Arrays läßt sich um den Faktor bis 100 > schneller rechnen. VB6 hat mit VB.net außer dem Syntax nix zu tun.
Hallo @Num Deine DLL muss in einer maschienen nahen Sprache geschrieben sein, z.b. C/C++. Wenn du den Quelltext übersetzt wird der Compiler für die eingestellte Architektur Maschienencode draus erzeugen. Ich meine das das Visualstudio noch natives C/C++ unterstützt. Die Dll kanst du dann über einen DLL Import aus dem VB.Net aufrufen und die Berechnung durchlaufen lassen. Auchtung: Eine DLL die du unter einer .Net Sprache (C#, VB.Net, ...) schreibst wird immer durch die CRL verarbeitet werden müssen und du genwinnst keine Zeit. Es muss in Visualstudio oder was auch immer du einsetzt ein Projekt für natives C/C++ gewählt werden, wo bei C/C++.Net noch ein Sonderfall ist. mfg CalM
Ein ähnliches Problem hatten wir hier vor einiger Zeit schon einmal. Der damalige TO wollte auch wissen, wie man einen Grafikfilter in C implementiert und dann von DotNET aus aufruft, weil seine C#-Implementierung zu langsam war. Nachdem hier sein Code zerpflückt wurde lief die Berechung unter C# fast so schnell, wie eine native Implementierung in C. Ich könnte mir vorstellen, dass könnte bei Deinem Problem auch der Fall sein. Das muss natürlich nicht unbedingt zutreffen, aber nach meiner Erfahrung liegt das Problem aber i.d.R nicht an der verwendeten Laufzeitumgebung (.NET oder native C-Runtime), sondern daran, wie gut man die Eigenheiten derselben kennt und etwaige Performance-Fallstricke umgehen kann. Vielleicht postest Du hier mal Deinen Code. Es sind hier genügend DotNET-Experten unterwegs, die sich das anschauen und Tipps zur Optimierung des Codes geben. Gruß Markus
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.