Jump to content
  • Advertisement
Sign in to follow this  
Numsgil

Should I switch platforms

This topic is 4695 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

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.

Share this post


Link to post
Share on other sites
Advertisement
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?

Share this post


Link to post
Share on other sites
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>

Share this post


Link to post
Share on other sites
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

Share this post


Link to post
Share on other sites
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

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
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

Share this post


Link to post
Share on other sites
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++?

Share this post


Link to post
Share on other sites
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/

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

We are the game development community.

Whether you are an indie, hobbyist, AAA developer, or just trying to learn, GameDev.net is the place for you to learn, share, and connect with the games industry. Learn more About Us or sign up!

Sign me up!