Should I switch platforms
Author
I'm working on a ALife simulation in VB6. I hate VB6, but that's what the program is written in, and rewritting it just because I'm not partial to the language is something of a silly idea.
What I am concerned about is speed. This is a simulation, after all. And especially evolution simulations should be as fast as possible.
Given that the bottleneck in speed is computational (that is, not graphics, or whatever), should I spend the time to switch from VB6 to something like, say, C++? I would consider it if I could expect something like >60% speed increase.
What sort of speed gains could I expect? Does anyone have any benchmarks? I'm sure this has been asked like a billion times, but the only google results I've found have been for .net, which is considerably different in overhead than VB6.
Yes VB6 is quite slow. C++ would be much better. However, you could still use a VB front end, and perhaps put the CPU heavy stuff in a DLL. Best of both?
Author
Hmm, that's not a bad idea. I already know how to do DLLs, so it wouldn't be incredibly difficult.
I think I should start the annoying Common Lisp recommendation messages.
*clears throat*
Why don't you try with Common Lisp? You'd get a faster program than with VB, but you'd also get the benefit of working with what is arguably the most flexible language out there.
</shameless CL advocacy>
*clears throat*
Why don't you try with Common Lisp? You'd get a faster program than with VB, but you'd also get the benefit of working with what is arguably the most flexible language out there.
</shameless CL advocacy>
Is VB.Net included in the current beta test Microsoft has going on? If so, that could be an option. Supposedly, VB.Net runs circles around VB6 in just about every area, but I assume the porting would be less time consuming than going to C++ [note: completely unfounded assumption]. Or, if you go to C++ anyhow, you could use .Net to make the interaction between the two parts more straight forward.
CM
CM
You might find that rewriting the core sections using more efficient VB coding will do it.
I take it you have a profiler and are able to see which parts are taking the time - in which case, consider optimising them.
You could also port it to VB.NET which might prove easier than C++ for your developers (although VB.NET is very different from VB semantically)
VB.NET may outperform VB6 in many cases (obviously nobody can say what effect it will have in your individual case)
Mark
I take it you have a profiler and are able to see which parts are taking the time - in which case, consider optimising them.
You could also port it to VB.NET which might prove easier than C++ for your developers (although VB.NET is very different from VB semantically)
VB.NET may outperform VB6 in many cases (obviously nobody can say what effect it will have in your individual case)
Mark
Author
Yes, I've profiled and redone about as much of the code as I can.
What's taking up clock ticks now is things inside the msvbblah blah dll. Functions that I don't know what they do, so I have a hard time figuring out how to make it go faster.
Speaking of which, if anyone knows of a list of the functions in the Visual Basic Virtual machine, and what they do, that would be really helpful.
From what I've read, the .net framework is incredibly slow compared to simple C++. It tends to make up for it in sheer GUI power, but I'm after every ounce of speed I can muster.
What's taking up clock ticks now is things inside the msvbblah blah dll. Functions that I don't know what they do, so I have a hard time figuring out how to make it go faster.
Speaking of which, if anyone knows of a list of the functions in the Visual Basic Virtual machine, and what they do, that would be really helpful.
From what I've read, the .net framework is incredibly slow compared to simple C++. It tends to make up for it in sheer GUI power, but I'm after every ounce of speed I can muster.
If you going with heavy mathamatical calls please remember that you will have to deal with that extra lookup each time a function is called from a DLL. this can get a we bit taxing, but then again to my knowledge everything in VB itself involves running through an annoying virtual table in the vb dll (which is one of the many things that slows down your app).
My personal recommendation is if this is a highly mathamatical program (i dont understand what you are working on, so im shooting in the dark here), to switch over COMPLETELY to C/C++, or some other compiled language (this may actualy be a good time to try out some of you 'l33t' haskel skills :)....
That being said, any way the increase in performance will go up heavily (though greater then 80% may be an extreem.. i honetly dont know). If you do use a DLL, try to minimize the number of calls into the DLL. A good idea for instance , make the DLL a state based machine. Then use some simple calls to manage it. You will need to create a new thread or process in the dll of course, and remember, you CANNOT ACCESS THAT MEMORY FROM WITHIN YOUR VB APP.
Richard P. Cesar
My personal recommendation is if this is a highly mathamatical program (i dont understand what you are working on, so im shooting in the dark here), to switch over COMPLETELY to C/C++, or some other compiled language (this may actualy be a good time to try out some of you 'l33t' haskel skills :)....
That being said, any way the increase in performance will go up heavily (though greater then 80% may be an extreem.. i honetly dont know). If you do use a DLL, try to minimize the number of calls into the DLL. A good idea for instance , make the DLL a state based machine. Then use some simple calls to manage it. You will need to create a new thread or process in the dll of course, and remember, you CANNOT ACCESS THAT MEMORY FROM WITHIN YOUR VB APP.
Richard P. Cesar
Author
Yes, that's good advice.
I was thinking of keeping all the window selections/menus/etc. in VB since VB kicks butt at making forms and such.
Speaking of which, how does everyone else make menus, etc. in C++?
I was thinking of keeping all the window selections/menus/etc. in VB since VB kicks butt at making forms and such.
Speaking of which, how does everyone else make menus, etc. in C++?
Quote:Original post by Numsgil
Yes, that's good advice.
I was thinking of keeping all the window selections/menus/etc. in VB since VB kicks butt at making forms and such.
Speaking of which, how does everyone else make menus, etc. in C++?
Use one of the libraries out there. GTK, FLTK, QT are the one's I can think of off the top of my head.
http://www.trolltech.com/
http://www.fltk.org/
http://www.gtk.org/
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
