Code center > Darwinbots Program Source Code
C++ refactoring
Numsgil:
--- Quote from: EricL ---Here's my $0.02.
The first 90% of a software project takes 90% of the time. The last 10% takes the other 90% of the time.
--- End quote ---
I saw this in someones signature in gamedev.net. No truer statement has ever been made! They don't teach you that in University
--- Quote ---3) Do a staight across port to C# or whatever with absolutely no architectural changes. I mean none. Get it stable first. We use the same lousy data structures, the same update loops, all in a single thread. No getting nuts with classes and methods and all that crap. Straight across. I'd even suggest we fake out some of the VB methods like Circle() to preserve the investment in code at least for the initial port. We get it stable and usable and everyone using it before we make ANY major architectural changes. This includes threading. The current architecture will be easy enough to thread where it counts when the time comes.
--- End quote ---
C# enforces a strict OO approach, which is going to make a straight port difficult. What I'd like to do is get both the VB and some C# code to meet each other half way. If we update both code bases at the same time to reach some sort of agreed upon middle ground, we can address fundamental architecture at the same time.
Most of the problem lies in the fact that VB just doesn't let you program the same way that C#, C++, etc. do.
--- Quote ---An alternative order would be to back port some or all of Num's new physics into the VB source before freezing and porting.
--- End quote ---
I plan on doing a little of this, though not nearly to the degree its done in the current C++ source. I want to move to a seperate 3rd party library for that.
--- Quote ---Now, my $0.02 would not be complete unless I pointed out that a port is a lot of work. A lot of work, a lot of sideways work. We have to be very very sure we want to do it and we want to be very very sure of the reasons why we are doing it. Let me play devils advocate for a moment. Why do we want to do it? So we can have multiple code authors? We can do that on the VB source by moving it to SVN or some other source code management system. For performance reasons? Don't be so sure. I could probably double the perfromance of the current VB code with a couple of weeks of focused work without losing stability. If perf is the main goal, some serious profiling and code reviews would reap more gains for less pain. For scalability across multiple CPUs? Yes, VB is single threaded, but DB is processor bound and does basically no I/O. That one thread is always busy, making maximum use of a single processor. You think moving to multiple threads will speed things up? Not on a single processor machine it won't. All else being equal, the added context switching will slow it down on single proc machines by maybe 10% or so. Got a dual core box you say? Use teleporters, run two connected sims and utilize 100% of both processors. Don't get me wrong, I love theads. Hell, I even like fibers when used right. DB would love threads and scale well, but only on machines with the processors to take advantage of a threaded architecture. Better physics maybe? Look, code is code. If you want elastic collisions or bouncy walls, back port the algorthims. Moving to a differet programming language is no panacia. It's the algorthms that count, not the programming language as far as physics go. Separating the UI from the engine? Future client-server versions? Graphics packages? All good stuff and admittably, harder to do from VB. But we need to be realistic about why we are porting. Those things are nice, but not near term and not the first reasons many people site for porting.
--- End quote ---
My primary issue with VB is that it makes programming complex data structures a pain. If DB were in just about any other language, I would never had considered switching. Heck, FORTRAN, Lisp, Matlab, even Lino would probably be fine.
You don't realize until you move back to C++ how extremely constricted VB is. And, what's amazing to me at least, is that I had that same sort of feeling when I moved to C# from C++. Managed code is so nice.
In brief, just about any other language than VB is going to be just fine, and I've personally fallen in love with .NET
--- Quote ---EDIT - Oh, I should point out we will take a perf hit with C#. Managed code is wonderful, you don't have to worry (as much) about memory leaks and such, but the garbage collection costs you maybe 10% on the client.
--- End quote ---
I've realized this too, but speed is becoming less of an issue in my mind because the fundamental algorithmic data structures are going to make 10 times as much of a difference as any code overhead. Usually 100 lines of code take up 80% of your CPU time. You're usually better off implementing more complex algorithms than trying to refine those 100 lines. (For instance, collisions and collision algorithms, like quad trees). Any code overhead in a language is going to only multiply existing orders of complexity, not bump them up to higher orders.
Testlund:
--- Quote from: EricL ---Use teleporters, run two connected sims and utilize 100% of both processors.
--- End quote ---
Does it really work like that? I thought a program had to be designed for a dual core to take advantage of that, or does two instances of a program allways use each of the processors by default?
Numsgil:
Each instance of a program is run in its own thread (otherwise you couldn't run two instances of a program). So yes, you can do this to take advantage of dual cores.
frankle:
Really, if we're talking about any of the .NET languages, the algorithmic routines will compile down to roughly the same MSIL code. Garbage collection costs 10%, yes, but with .NET, you can use unmanaged c++ code interspersed with managed c++ code. For the more time-intensive stuff that will run millions of times, it would be unmanaged. As long as the C++ was well written, the overhead would be negligible.
Bottom line for me is that I'm not going to invest a lot of time into learning VB6. I know enough to be dangerous, but not enough to really be anything but that in this codebase. Learning VB would be like learning FORTRAN or COBOL: a waste of my time. Sure, they can still tow the cart, but there are new and better languages available.
Straight porting from VB6 is not a pretty option. Ask anyone and they will tell you that porting a VB6 app into VB.2005 is a nightmare. With 90% of the coding done already in c++, the last 10% should go fairly smoothly.
The VB fork has a lot of usability as it is, and I think if _just_ the critical bugs could be eliminated, it would stand on its own for 6 months or so while the C++ app were built.
Anyway, I am an aspiring opera singer, and I'm still in college, so I can't commit a lot of time to this project. But I can say that I like it, and that I'll code when and where I can. My primary language is PHP, but I am pretty good with C++, and I think I could help a lot.
EricL:
--- Quote from: frankle ---Bottom line for me is that I'm not going to invest a lot of time into learning VB6. I know enough to be dangerous, but not enough to really be anything but that in this codebase. Learning VB would be like learning FORTRAN or COBOL: a waste of my time. Sure, they can still tow the cart, but there are new and better languages available.
--- End quote ---
There's nothing to VB. I'd never used it seriously before DB. If you are any good in any procedural language, you know enough VB to get by. A For loop is a For loop, syntax not withstanding. But learning VB or any other language is not the hard part. It's not the hard part in any project more complex than a school assignment. Learning the code itself is the hard part. DB is a small project as projects go but it still has over 20k lines of source. The ramp up is learning that, in any language.
--- Quote from: frankle ---Straight porting from VB6 is not a pretty option. Ask anyone and they will tell you that porting a VB6 app into VB.2005 is a nightmare.
--- End quote ---
If you think straight porting is hard, try porting while rearchitecting. Trust me. By a straight port, I mean maintaing flat data structures, continuing to use arrays not lists, etc. Minimal changes to data structures. Of course the syntax will change and there will be some places where we must make some small archtiectural changes, but the point is to limit those.
--- Quote from: frankle ---With 90% of the coding done already in c++, the last 10% should go fairly smoothly.
--- End quote ---
Care to make a wager? Seriously, I don't want to be insulting. I could really use some help and I really would like to see the code ported but that is very naive statement you are making there.
--- Quote from: frankle ---The VB fork has a lot of usability as it is, and I think if _just_ the critical bugs could be eliminated, it would stand on its own for 6 months or so while the C++ app were built.
--- End quote ---
Hopefully it would not take 6 months.
Navigation
[0] Message Index
[#] Next page
[*] Previous page
Go to full version