Vyznam dual core

[swarm]

Multithreadově by to šlo (částečně) udělat tak, jak navrhuje swarm, tj. namísto plnohodnotného počítání fyziky v prvním kroku použít nějakou velmi hrubou (= velmi rychlou) aproximaci pohybu a v globání paměti označit problémová místa, u nichž hrozí, že se tam panák přesune (pokud se ona aproximace trefí). Ale to je zase o odhadování a může to mít hodně blbé následky - pokud se aproximace netrefí, tak se ti prostě může stát, že buďto:
1) se dva panáci pohnou na stejné místo
2) jednomu panákovi bude odepřen vstup na nějaké místo, kam aproximace předpovídala pohyb jiného panáka, přestože po spočtení detailní fyziky se tam nepohnul

Já bych předpokládal, že pokud v předvýpočtu vyjde, že by se dva objekty teoreticky mohli potkat/ovlivnit, tak ne, že by jim to odepřelo možnost se pohnout někam, ale seřadilo by to všechny elementy, co by se mohli ovlivnit, do jednoho threadu a spočítalo by je to klasicky sekvenčně (tak jak jsme si ujasnili už předtim). To nám ale nezakazuje pokud nám výpočet zjistí, že někde je blízko sebe jiná skupinka panáků (někde dál od té první), že se nemůže prdnout do dalšího threadu a uvnitř něj opět zpočítat sériově (ale zase jenom pro ty dané elementy/panáky). Pokud je těch panáků v aktivní scéně víc, tak se dá dojít ke zrychlení...pokud se všichni nenamačknou k sobě, kde se vlastně všechno hodí do jednoho threadu. Podle umístění panáků tak bude záviset to, jak moc to přinese výkonu navíc.

Samozřejmě základem je ten předvýpočet nastavit tak paranoidně, abychom vyloučili, že se nám potkají (to už by se zase dalo vymyslet různými způsoby).

[Eagle]

Já bych předpokládal, že pokud v předvýpočtu vyjde...

Tak by to šlo samozřejmě vyřešit taky, ale pak je tu ten problém, že když bude skupinka panáků u sebe, bude se to na DC hýbat stejně rychle jako na SC. Opět mi z toho vyplývá, že prioritní je co nejvyšší frekvence CPU, protože jedině ta může zabránit propadu výkonu.