RE: Improvements to the Speed of Calculations?

Matrix Games Forums

Forums Register Login Photo Gallery Member List Search Calendars FAQ

My Profile Inbox Address Book My Subscription My Forums Log Out

RE: Improvements to the Speed of Calculations?

View related threads: (in this forum | in all forums)

Logged in as: Guest

Users viewing this topic: none

Printable Version

All Forums >> [Current Games From Matrix.] >> [World War II] >> Norm Koger's The Operational Art Of War III >> RE: Improvements to the Speed of Calculations?

Page: << < prev 1 [2]

Message

<< Older Topic Newer Topic >>

RE: Improvements to the Speed of Calculations? - 6/27/2006 9:34:29 AM

larryfulkerson

Posts: 39932
Joined: 4/17/2005
From: Tucson, AZ
Status: offline

quote:

ORIGINAL: ralphtrick
As a short term fix, I also might look into moving things out of this 300x300x48 array, and into a 300x300 array. Then things like clearing the array, etc. might be faster

If it's an array of chars, then if it's contiguous, then why not do a memove of '0' for 90000 chars. Would that be any faster?

(in reply to ralphtricky)

Post #: 31

RE: Improvements to the Speed of Calculations? - 6/27/2006 10:05:38 AM

Szilard

Posts: 386
Joined: 1/3/2001
Status: offline

quote:

ORIGINAL: JAMiAM

quote:

ORIGINAL: Szilard

The optimal-reentry-point issue should be easy to fix. Delete "optimal", and just do something like: on/adjacent to unit's formation HQ; or if none, on/adjacent to a cooperative HQ close to evaporation position; or if none, on/adjacent to a nearby supply point; or if none, don't reconstitute.

I don't know about that being an "easy" fix, since it would require a major departure from the current model of a 1-4 week window, and fixed position, for the reconstituted units appearing. Now, if sufficient equipment is available, then it is pulled, committed to a unit, and the unit is stuck on the scheduled reinforcements track to appear at a specific position, at some point in time 1-4 weeks away. To have it dependent upon "finding" an HQ to reappear next to, when the time comes for it to show up on the map, and failing that either redump the equipment into inventory, or continually be reassigned a new reconstitution point based on HQ's that may or may not still exist on the map, seems to me to be inherently more problematic.

Fair enough. I'd be OK with just reconstituting at a supply point.

(in reply to JAMiAM)

Post #: 32

RE: Improvements to the Speed of Calculations? - 6/27/2006 12:44:36 PM

a white rabbit

Posts: 2366
Joined: 4/27/2002
From: ..under deconstruction..6N124E..
Status: offline

quote:

ORIGINAL: golden delicious

quote:

ORIGINAL: geozero

BTW - I used a Commodore which only booted up from a 5.25" floppy.

That's nothing. Before the ST we had a Commodore which loaded of cassette tapes. Those were the days.

..16K Spectrum then upgraded to a 48K, coal fired

_____________________________

..toodA, irmAb moAs'lyB 'exper'mentin'..,..be�n'tus all..?,

(in reply to golden delicious)

Post #: 33

RE: Improvements to the Speed of Calculations? - 6/27/2006 2:05:08 PM

golden delicious

Posts: 5575
Joined: 9/5/2000
From: London, Surrey, United Kingdom
Status: offline

quote:

ORIGINAL: JAMiAM

I don't know about that being an "easy" fix, since it would require a major departure from the current model of a 1-4 week window, and fixed position, for the reconstituted units appearing. Now, if sufficient equipment is available, then it is pulled, committed to a unit, and the unit is stuck on the scheduled reinforcements track to appear at a specific position, at some point in time 1-4 weeks away. To have it dependent upon "finding" an HQ to reappear next to, when the time comes for it to show up on the map, and failing that either redump the equipment into inventory, or continually be reassigned a new reconstitution point based on HQ's that may or may not still exist on the map, seems to me to be inherently more problematic.

A quick thought here: you could bar reconstitution of component units of a formation which has lost its HQ, with the exception of the HQ itself. This serves to make HQs more valuable and also means that if a formation really gets smashed up it'll take a good deal longer to recover.

_____________________________

"What did you read at university?"
"War Studies"
"War? Huh. What is it good for?"
"Absolutely nothing."

(in reply to JAMiAM)

Post #: 34

RE: Improvements to the Speed of Calculations? - 6/27/2006 7:44:27 PM

ralphtricky

Posts: 6685
Joined: 7/27/2003
From: Colorado Springs
Status: offline

quote:

ORIGINAL: larryfulkerson

quote:

ORIGINAL: ralphtrick
As a short term fix, I also might look into moving things out of this 300x300x48 array, and into a 300x300 array. Then things like clearing the array, etc. might be faster

If it's an array of chars, then if it's contiguous, then why not do a memove of '0' for 90000 chars. Would that be any faster?

_____________________________

Ralph Trickey
TOAW IV Programmer
Blog: http://operationalwarfare.com
---
My comments are my own, and do not represent the views of any other person or entity. Nothing that I say should be construed in any way as a promise of anything.

(in reply to larryfulkerson)

Post #: 35

RE: Improvements to the Speed of Calculations? - 6/27/2006 7:47:12 PM

ralphtricky

Posts: 6685
Joined: 7/27/2003
From: Colorado Springs
Status: offline

quote:

ORIGINAL: a white rabbit

quote:

ORIGINAL: golden delicious

quote:

ORIGINAL: geozero

BTW - I used a Commodore which only booted up from a 5.25" floppy.

That's nothing. Before the ST we had a Commodore which loaded of cassette tapes. Those were the days.

..16K Spectrum then upgraded to a 48K, coal fired

..Altair 8800, built from a kit, fully loaded with 1024 Bytes of memory. Directly set the inputs using toggle switches, the only output is direct read of memory, or toggling the memory protect light (also played Mary had a Little Lamb on the AM radio.)

Top that

_____________________________

(in reply to a white rabbit)

Post #: 36

RE: Improvements to the Speed of Calculations? - 6/27/2006 11:50:44 PM

Captain Cruft

Posts: 3652
Joined: 3/17/2004
From: England
Status: offline

Here's an off the wall idea. I have no clue as to whether it's feasible or not.

Have a background thread which maintains a separate copy of the map array and unit data. Each action in the orders phase needs to update this copy, obviously. These updates would need to have a notion of the set of "affected hexes" and "affected units". Then, have the background thread continually doing the supply calcs and whatnot. So, come end of turn, it's probably about 95% of the way there already.

This is something like the way virtual memory works. Or database caching. We need to get away from only doing one thing at once.

Probably a nightmare to program mind you.

(in reply to ralphtricky)

Post #: 37

RE: Improvements to the Speed of Calculations? - 6/28/2006 2:12:02 AM

ralphtricky

Posts: 6685
Joined: 7/27/2003
From: Colorado Springs
Status: offline

quote:

ORIGINAL: Captain Cruft

Here's an off the wall idea. I have no clue as to whether it's feasible or not.

Have a background thread which maintains a separate copy of the map array and unit data. Each action in the orders phase needs to update this copy, obviously. These updates would need to have a notion of the set of "affected hexes" and "affected units". Then, have the background thread continually doing the supply calcs and whatnot. So, come end of turn, it's probably about 95% of the way there already.

This is something like the way virtual memory works. Or database caching. We need to get away from only doing one thing at once.

Probably a nightmare to program mind you.

There are a bunch of things I can do. I need to find the bottlenecks first. I hope to cut down the speed using some simple things first.

A thread is probably overkill unless I decide to use monte carlo simulation for the AI.

_____________________________

(in reply to Captain Cruft)

Post #: 38

RE: Improvements to the Speed of Calculations? - 6/28/2006 3:32:48 AM

Szilard

Posts: 386
Joined: 1/3/2001
Status: offline

quote:

ORIGINAL: ralphtrick

There are a lot of things I can do. Probably the biggest help for the supply lookups is to look into rewriting it using the newer A* pathfinding algorithms. I'll have to write all that first, of course.

Would that make such a big difference? I'd have thought it'd be the normal kind of thing where pruning the number of paths would give much bigger wins than optimizing individual path finding. Fun to play around with, anyway :)

(in reply to ralphtricky)

Post #: 39

RE: Improvements to the Speed of Calculations? - 6/28/2006 3:55:54 AM

ralphtricky

Posts: 6685
Joined: 7/27/2003
From: Colorado Springs
Status: offline

quote:

ORIGINAL: Szilard

quote:

ORIGINAL: ralphtrick

There are a lot of things I can do. Probably the biggest help for the supply lookups is to look into rewriting it using the newer A* pathfinding algorithms. I'll have to write all that first, of course.

Would that make such a big difference? I'd have thought it'd be the normal kind of thing where pruning the number of paths would give much bigger wins than optimizing individual path finding. Fun to play around with, anyway :)

Maybe not, but it's a lot more fun to play around with.

_____________________________

(in reply to Szilard)

Post #: 40

RE: Improvements to the Speed of Calculations? - 6/28/2006 4:21:39 AM

CommC

Posts: 467
Joined: 8/3/2002
From: Michigan, USA
Status: offline

"thousands of calculations" is indeed a trivially small number for modern computers.

"C++, integer arithmetic"

Well, that explains it. C++ is primarily a business language and while it is far better than Fortran, Visual Basic and similar, it is still a pretty slow, high level language. If more of TOAW's calculation intensive operations can be done using machine language calls (or another faster language) that might greatly speed things up.

I like where this thread is going, with brainstorming on ways to speed things up. I like the idea of simplifying the supply calculations as a potentially easy fix to the slowness observed.

< Message edited by CommC -- 6/28/2006 4:23:20 AM >

_____________________________

(in reply to ralphtricky)

Post #: 41

RE: Improvements to the Speed of Calculations? - 6/28/2006 4:49:08 AM

Captain Cruft

Posts: 3652
Joined: 3/17/2004
From: England
Status: offline

Hey that's the answer, just re-write the entire game in assembler! Better yet, blow the code onto a chip and get somebody to manufacture it on a PCI card. No digital download that way though ...

Sorry

Seriously, I don't think it's an issue of language. C/C++ are fast enough, indeed they are generally regarded as the fastest compiled languages in common use.

It's more a matter of algorithms and methodologies, like Ralph said.

(in reply to CommC)

Post #: 42

RE: Improvements to the Speed of Calculations? - 6/28/2006 5:01:30 AM

larryfulkerson

Posts: 39932
Joined: 4/17/2005
From: Tucson, AZ
Status: offline

quote:

ORIGINAL: CommC
C++ is primarily a business language....

Hmmmm....that's strange I'm a retired computer programmer, worked with computers for over twenty years and I've never heard it described that way. I've never thought of it that way. I have seen it used to build operating systems. I have seen it used to build some of the fastest games on the planet. CommC, my man, you've probably never met Cobol.

(in reply to CommC)

Post #: 43

RE: Improvements to the Speed of Calculations? - 6/28/2006 5:40:00 AM

ralphtricky

Posts: 6685
Joined: 7/27/2003
From: Colorado Springs
Status: offline

quote:

ORIGINAL: Captain Cruft
Seriously, I don't think it's an issue of language. C/C++ are fast enough, indeed they are generally regarded as the fastest compiled languages in common use.

It's more a matter of algorithms and methodologies, like Ralph said.

Given that it's C++ in name only, and is still essentially C code, I don't think that it gets any faster than that. Even C++ with the modern compilers and a bit of attention to the design is going to be fast enough.

I can do a lot with the algorithms. The original code was written to be understandable and take up little memory. There also weren't a lot of published works on game programming when it was written.

Don't worry, there are a lot of concepts that I can borrow from the RTS and other communities. I've got all the game programming gems books to reference, plus some others.

_____________________________

(in reply to Captain Cruft)

Post #: 44

RE: Improvements to the Speed of Calculations? - 6/28/2006 10:28:33 AM

XPav

Posts: 550
Joined: 7/10/2002
From: Northern California
Status: offline

My first advice as someone who just spend the day figuring out why his own C++ code was running slow:

1) Don't trust yourself to guess why the code is going slow. Ignore your gut. Time your code.
2) See rule 1.

If you're not using Visual Studio 6.0 (the last version that had a profiler without going for the $$$ Edition), you can cobble together some timing classes that should work well. Start timer on construction, output tim on destruction when they fall out of scope. Helped me find my problems.

Sounds like Norm did a good job though with his original code, and the main thing making the huge scenarios run slow is, well, because they're huge.

Have fun.

_____________________________

I love it when a plan comes together.

(in reply to ralphtricky)

Post #: 45

RE: Improvements to the Speed of Calculations? - 6/28/2006 1:47:53 PM

a white rabbit

Posts: 2366
Joined: 4/27/2002
From: ..under deconstruction..6N124E..
Status: offline

..as far as speed goes, i'd say toaw3 is faster than toaw-acow

..based on the Imphal scen

_____________________________

..toodA, irmAb moAs'lyB 'exper'mentin'..,..be�n'tus all..?,

(in reply to XPav)

Post #: 46

RE: Improvements to the Speed of Calculations? - 6/28/2006 4:43:57 PM

ralphtricky

Posts: 6685
Joined: 7/27/2003
From: Colorado Springs
Status: offline

quote:

ORIGINAL: XPav
If you're not using Visual Studio 6.0 (the last version that had a profiler without going for the $$$ Edition), you can cobble together some timing classes that should work well. Start timer on construction, output tim on destruction when they fall out of scope. Helped me find my problems.

Visual Studio 2005. The same tools still work, BTW. I've been doing more the Break and see where I am style of timing at the moment<g>. It is C code, so there are no objects. I plan to fix that for my own sanity over the next coupld of years.<g>

quote:

Sounds like Norm did a good job though with his original code, and the main thing making the huge scenarios run slow is, well, because they're huge.

That's a large part of it. He also has some algorithems that scale geometrically. 300x300 is 10 times bigger than 100x100. If you multpliy by the extra units, it gets even worse.

quote:

Have fun.

Oh, I definitely am. Picture scenario design on a HUGE scale<g>

_____________________________

(in reply to XPav)

Post #: 47

RE: Improvements to the Speed of Calculations? - 6/28/2006 6:05:26 PM

a white rabbit

Posts: 2366
Joined: 4/27/2002
From: ..under deconstruction..6N124E..
Status: offline

..is there any way to slow Elmer down ? esp when he's moving units, blink and he's attacking, how he got there remaining a mystery..

_____________________________

..toodA, irmAb moAs'lyB 'exper'mentin'..,..be�n'tus all..?,

(in reply to ralphtricky)

Post #: 48

RE: Improvements to the Speed of Calculations? - 6/29/2006 6:30:26 AM

XPav

Posts: 550
Joined: 7/10/2002
From: Northern California
Status: offline

quote:

ORIGINAL: ralphtrick
That's a large part of it. He also has some algorithems that scale geometrically. 300x300 is 10 times bigger than 100x100. If you multpliy by the extra units, it gets even worse.

Ahhh.... O(N^2)

Yay!

_____________________________

I love it when a plan comes together.

(in reply to ralphtricky)

Post #: 49

RE: Improvements to the Speed of Calculations? - 6/29/2006 6:55:23 AM

ralphtricky

Posts: 6685
Joined: 7/27/2003
From: Colorado Springs
Status: offline

quote:

ORIGINAL: XPav

quote:

ORIGINAL: ralphtrick
That's a large part of it. He also has some algorithems that scale geometrically. 300x300 is 10 times bigger than 100x100. If you multpliy by the extra units, it gets even worse.

Ahhh.... O(N^2)

Yay!

Yep. I'm thinking I can find some algorithms that are O(n log n) at worst, or teach it about land masses, and cut down on how big the search space is.

I can also do a lot to trade storage space for time, and avoid the calculation altogether.

_____________________________

(in reply to XPav)

Post #: 50

Page: << < prev 1 [2]

All Forums >> [Current Games From Matrix.] >> [World War II] >> Norm Koger's The Operational Art Of War III >> RE: Improvements to the Speed of Calculations?

Page: << < prev 1 [2]