Since computers have become much more capable, I wonder if it is time to explore giant hills?

Small core sizes brought their own breed of warriors, perhaps huge cores would also spark new developments?

What could be interesting settings? For example what if max warrior size was 10000 and core size 1GB?

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Saturday, 12 February 2022 at 14:26:44 UTC+1, inversed wrote:

- the optimization quality of most tiny warriors is poor
- the optimization quality of most 94nop warriors is very poor

Interesting to know, I had assumed at least the tiny warriors to be pretty optimized by now.

The only well optimized warriors are certain scanners like Recon2 because they have few constants and their choice can be further narrowed down. With state of the art software and a top of the line CPU I can optimize well for coresize 800 and

struggling to optimize for coresize 8000 and you are proposing coresize 1'000'000'000? It won't even be possible to obtain precise scores.

Why no precise scores? I haven't done the math, admittedly.

There is also a conceptual problem with your argument. There is so much to discover even in tiny, there is just no need for giant settings. You are proposing a solution to a nonexistent problem.

Well not necessarily a solution to a problem, just something new to try out.

Max warrior size 10000 would only be useful for enormous quickscans. Larger cores would mean that longer loops (0.8c scans and maybe more) become more attractive. Replicators would also grow in size (more than 3 silks) to cover the larger cores better.

But there won't be any drastic change in strategies. One of the main principles of CoreWar - you have to be small and efficient - would still apply.

Maybe, even probably - but are you sure? :-)

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Saturday, February 12, 2022 at 2:05:56 PM UTC+3, [email protected] wrote:

Since computers have become much more capable, I wonder if it is time to explore giant hills?

It isn't. With the current commodity hardware we can barely scratch the surface of tiny. I have my own warrior optimization software which I believe is best in class. The conclusions I came to after optimizing my new warriors with it are:
- the optimization quality of most tiny warriors is poor
- the optimization quality of most 94nop warriors is very poor
The only well optimized warriors are certain scanners like Recon2 because they have few constants and their choice can be further narrowed down. With state of the art software and a top of the line CPU I can optimize well for coresize 800 and struggling
to optimize for coresize 8000 and you are proposing coresize 1'000'000'000? It won't even be possible to obtain precise scores.

There is also a conceptual problem with your argument. There is so much to discover even in tiny, there is just no need for giant settings. You are proposing a solution to a nonexistent problem.

Small core sizes brought their own breed of warriors, perhaps huge cores would also spark new developments?
For example what if max warrior size was 10000 and core size 1GB?

Max warrior size 10000 would only be useful for enormous quickscans. Larger cores would mean that longer loops (0.8c scans and maybe more) become more attractive. Replicators would also grow in size (more than 3 silks) to cover the larger cores better.
But there won't be any drastic change in strategies. One of the main principles of CoreWar - you have to be small and efficient - would still apply.

What could be interesting settings?

The experimental settings (coresize 55440), but with the regular proportions (max processes = coresize, max cycles = 10 coresize). The 94x settings currently in use at koth.org are balance-breaking.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Saturday, 12 February 2022 at 10:01:28 pm UTC+8, bjoer... wrote:

On Saturday, 12 February 2022 at 14:26:44 UTC+1, inversed wrote:

- the optimization quality of most tiny warriors is poor
- the optimization quality of most 94nop warriors is very poor

Interesting to know, I had assumed at least the tiny warriors to be pretty optimized by now.

The only well optimized warriors are certain scanners like Recon2 because they have few constants and their choice can be further narrowed down. With state of the art software and a top of the line CPU I can optimize well for coresize 800 and

struggling to optimize for coresize 8000 and you are proposing coresize 1'000'000'000? It won't even be possible to obtain precise scores.

Why no precise scores? I haven't done the math, admittedly.

There is also a conceptual problem with your argument. There is so much to discover even in tiny, there is just no need for giant settings. You are proposing a solution to a nonexistent problem.

Well not necessarily a solution to a problem, just something new to try out.

Max warrior size 10000 would only be useful for enormous quickscans. Larger cores would mean that longer loops (0.8c scans and maybe more) become more attractive. Replicators would also grow in size (more than 3 silks) to cover the larger cores

better. But there won't be any drastic change in strategies. One of the main principles of CoreWar - you have to be small and efficient - would still apply.

Maybe, even probably - but are you sure? :-)

Well, I think I can optimise well for coresize 8000 but I struggle with coresize 55400 which is about 10x slower that coresize 8000. Coresize 55440 also runs into overflow problems when building Qscans and with certain other address calculations.
I'm thinking that when Inversed says it won't be possible to obtain precise scores he probably means that the spread of possible scores for different starting positions will be too large allow a precise score to be pinned down to a reasonable confidence
level. I notice this problem when optimising for coresize 8000, everything is too dependent on the particular set of benchmark warriors. More rounds lessens the problem but takes longer to run. Optimising a warrior against a bunch or warriors that you
don't have source code for on a hill is a fairly limited exercise.

I've done a bunch of tests with different length qscans for the 94x hill and it will support longer scans than coresize 8000 but not that much longer. Go too long and onshots will eat you alive. I have had some minor successes linking a oneshot scan to a
Qscan attack.
Steve.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

But if even the current hills can not be optimized against properly, it is not a good argument against giant hills? In any case, it is all about fun, so if there is no interest in this idea, fair enough.

I haven't played in (far too many) years, and it seems to me that the optimization against the current hills is a huge barrier of entry. It is not enough to have a good idea for a warrior, you also have to master the optimization tools.

But granted, the way to play the giant hills would probably require even more tools, because nobody would want to write a 10000 line warrior by hand.

I wouldn't necessarily expect completely new strategies, but perhaps variations. For example since presumably it would take longer to find the enemy, warriors would have more time for their opening strategy. They could perhaps launch multiple strategies
in parallel and so on.

Thinking about it, maybe it would just be annoying, like p-space :-) Even p-space was fun for a while, because it lead to fiddling with switching strategies. But once the switching strategies were fairly optimized, it just lead to more work for creating
warriors. I guess - unless there is still undiscovered potential for p-space we don't know about...

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Sunday, 13 February 2022 at 6:19:13 pm UTC+8, bjoer... wrote:

But if even the current hills can not be optimized against properly, it is not a good argument against giant hills? In any case, it is all about fun, so if there is no interest in this idea, fair enough.

I haven't played in (far too many) years, and it seems to me that the optimization against the current hills is a huge barrier of entry. It is not enough to have a good idea for a warrior, you also have to master the optimization tools.

But granted, the way to play the giant hills would probably require even more tools, because nobody would want to write a 10000 line warrior by hand.

I wouldn't necessarily expect completely new strategies, but perhaps variations. For example since presumably it would take longer to find the enemy, warriors would have more time for their opening strategy. They could perhaps launch multiple

strategies in parallel and so on.

Thinking about it, maybe it would just be annoying, like p-space :-) Even p-space was fun for a while, because it lead to fiddling with switching strategies. But once the switching strategies were fairly optimized, it just lead to more work for

creating warriors. I guess - unless there is still undiscovered potential for p-space we don't know about...

It is an interesting idea but it is not not really practical.

Okay lets break down the problem a bit. A big core requires a big memory footprint and a huge execution time to allow warriors to reasonably stun and kill opponents. You will also want to have a visualiser to debug any problems. A visualiser for 55,440
is big, I can imagine a visualiser for 550,000, I can't imagine a workable visualiser for 5,000,000 core locations. Even if you could usefully visualise that size of core, single stepping through anything beyond the opening stages of the battle would be
the work of months. So we are not going to have old style hand coded and optimised warriors. Development is going to be, draft an idea and feed it to an optimiser/evolver that can tweak the constants and try alternative code and configurations. But that
is still going to take forever. I have driven a 4GB linux machine into thrashing with just 4 parallel 94x optimiser processes. A standard run of my optimiser/evolver takes around 4 to 8 hours for coresize 8000 and 2-4 days for coresize 55440. Running a
hill like Koth is going to take a serious enterprise server class system and a full rewrite of PMARS and you are not going to get back a response in any reasonable amount of time. Picking a one meg core size would need less hardware but you are still
going to need a PMARS re-write and you will have have unreasonable wait times unless you have a truly tiny hill.

Have a go at developing for the 94x hill (it needs more people submitting) and then come back and tell us if bigger hills still seem viable.

Just as an aside I don't think that switching strategies ever really got optimised on the 94 draft hill as such but eventually people found out that small switchable components didn't really compete against the best of the compound strategy monsters
coming back from the 94nop hill.

Steve

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Why would a pmars rewrite be necessary? I think it uses 32 Bits for addresses, or am I mistaken?

At the moment I am trying to get it to run on OS X so that I can play properly. Then perhaps I'll try some tests.

Or maybe it would be an idea for a tournament round.

Difficulty of optimizing could also be a positive, like in the old days before everybody had optimizers.

But in general you have convinced me that there is still enough to try on the existing hills.

You mean switching components was not enough of an advantage agains optimized normal warriors?

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Saturday, 19 February 2022 at 9:58:01 pm UTC+8, [email protected] wrote:

Why would a pmars rewrite be necessary? I think it uses 32 Bits for addresses, or am I mistaken?

At the moment I am trying to get it to run on OS X so that I can play properly. Then perhaps I'll try some tests.

Or maybe it would be an idea for a tournament round.

Difficulty of optimizing could also be a positive, like in the old days before everybody had optimizers.

But in general you have convinced me that there is still enough to try on the existing hills.

You mean switching components was not enough of an advantage agains optimized normal warriors?

Just for context here I have done a lot of work on the 94x hills at coresize 55440 ... about a quarter of all the warriors in 94x Koenigstuhl are from me.
Pmars will get overflows when testing 94x warriors ... the macro calculations and the MUL instruction do not have adequate intermediate representations and the macro calculations try and perform too many operations before applying the coresize modulus.
But the biggest problem is the inefficient memory usage. I have driven a 4GB Unix machine into thrashing with only a few instances of pmars running 94x fights. My professional guess is that the internal data structures are poorly localised for efficient
pageing because that was not really an issue back then. The next biggest problem is hand debugging and optimisation which is what everyone did before optimiser programs became the norm. Once you have a visual interface you need a lot more memory than the
bare server and you need a lot of screen real estate. PMARS is very unsophisticated with its use of screen space that will need re-writing as well. Then there is the sheer size of the search space for reasonably efficient constants. Most experienced
warrior authors should be able to narrow down that search to a reasonable range but that isn't going to be everyone and those reasonable guesses are not likely to be optimal.

If you can get a mega-hill working then by all means try it for a tournament.

The components on a p-switcher are typically quite small and only have a single function. Now have a look at the warriors that dominate the top of the 94 Standard hill ... they are from the 94nop hill and typically have compound strategies Paper/Imps,
Stone/Imps, Paper/Stone or a high efficiency scanner/clear and they usually have a Qscan to hit the large p-switcher footprint. Christian's "deeds of cinder" may be the only p-switcher left on the hill.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)