I've done a variety of speedups to verge. It would be cool if people could download the zip at:

http://www.kkmfg.com/adderd/VERGEMARK.zip

And try to run both verge-old.exe and verge.exe

verge-old.exe is the stock verge from version Rev115 compiled with the default release settings

verge.exe is the new exe from my modifications to Revision 115.

My machine is being really stupid and I can't seem to get reliable data out of vergemark so I am hoping others can provide me with the data to determine how well the speedups are working.

verge_old.exe
low detail map: 225
high detail map: 857
dynamic lighting: 1750
pathfinding ai: 1368
particles: 700
3d rendering: 2354

total score: 7254

verge.exe
low detail map: 218
high detail map: 857
dynamic lighting: 1580
pahtfinding ai: 1374
particles: 700
3d rendering: 2267

total score: 6996

I'm embarrassed. My computer's getting on in years.

Thanks all..

I have since fixed vergemark so that the results are more consistant on all machines and I made the tests longer to better get a score.

Still, the results are basically the same as what you all posted, the new version is very marginally faster.

Currently I am writing a vergec profiler within the interpreter. There will be an interpreter profiler as well. Then we'll see where the bottle necks in both are.

Still very little improvement.... Well, it helped a bit I suppose.

Someday I'll commit the vergec profiler to SVN. I haven't had time to finish it yet but it does work currently. Then the verge interpreter profiler is next. We'll get this beast purring yet. ;)

Yes, I've heard reference to that before. I'm not *exactly* sure what was changed but I've heard that older versions were much faster.

It seems that code that old isn't easy to come by anymore so I'm sort of at the mercy of people's memories on this one. I'm pretty sure I do know pretty much what is making it so slow but I'm not currently able to spend any time on it. All of my involvement is once again on hold as I work on business related things instead of games. Once I get some free time I'll try to redo things. I have seen some areas where improvement could be made but I hold off because it's time consuming.

Quote:Originally posted by basil

Interesting work. V3 used to be a whole lot faster, and at some point one of the handsome new features slowed it right on down. The 2004 exe I put with all the 3d stuff is considerably faster than both the present exec and your revised one. I don't know whether the old source is still around, but if you're looking for speed improvements it might be interesting to see what makes the old exec so much quicker.

Quote:Originally posted by Kildorf

Might it be a good idea to make a list of places that could use some improvements, speed-wise? Then we have the option of someone else with free time working on it, no? It'd be good to consolidate all such knowledge that anyone may have accumulated.

Not a bad idea.

From memory here (culled from profiling runs in the past):

A big area of speed loss is in opcode decoding. There are huge switch statements and recursive Process and ResolveOperand calls. This makes it very slow because there are many, many instructions necessary to even begin running each vergec opcode. Already vergec uses a sort of heap allocation for things which is good. But, to speed things up it would be nice if each opcode output by the vergec compiler was run by looking up a function entry point in a big opcode table and directly jumping there. That makes the main decoding of opcodes a matter of only a few processor instructions (add a number to the function pointer array to get the offset, read the value, jump there). From there each opcode should be able to use inline functions for getting it's parameters and returning values, etc. The use of inline functions serves two purposes 1: It's quick, no function call 2: Using a function allows for a large amount of code reuse and modularity. Currently vergec is very well organized and modular but not quick. The changes I'm suggesting would make the code sort of ugly but it would operate quickly.

Also, once again just off the top of my head, I believe that certain library calls and string manipulation functions get called way too much. Things like strcpy, memset, memcpy, Rawmem:resize, etc. I'm not really sure what exactly can be done to minimize these calls or eliminate them as I haven't spent any time on it yet. It seems like these sort of calls have the potential to be the sort that get called superfluously. Reducing them could have a big impact on performance. I just found one profile from AMD Code Analyst and most of the time was spent in Memcpy and Memset. So something is up with that. I have no idea under what circumstances that profile was run though.

Anyway, I think that decently sums up my thoughts on the matter. I'd appreciate feedback from others who might be the sort to dig into these things (COUGHOVERKILLCOUGH)