massiv-crap Mailing List for Massively multiplayer game middleware

>
> mingw:
> Allocation: 0.370533s, 0.0370533ms per element.
> Iteration: 0.741066s, 0.00370533ms per element.
> Total: 1.1116s.
>
> msvc6 (stlport):
> Allocation: 8.49221s, 0.849221ms per element.
> Iteration: 0.630909s, 0.00315454ms per element.
> Total: 9.12312s.

No jeste se uvidi. Zkusim tu novou hashovaci funkci pro objectid a zkusim
naimplementovat lazy verzi property pointeru.

> Coz je docela hodne v neprospech msvc6...
> Co potrebuju ke spusteni tech javovskych testu?

Tedka jsem to upravil jako applet, takze by to melo jit pustit normalne bez
nutnosti instalovat JDK. Ty vystupy jsou vypisovany na konzoli, kterou je
treba rucne zapnout (IE).

-- Markoid

Ahoj,
mam tady zas jednou malou buzeracni poznamecku k datovym zpravam. V =
massivu mame krome properties definovane jeste tzv. stypes, coz jsou =
odlehcene properties. V internich objektech/zpravach massivu se pak =
misto nativnich atributu pouzivaji tyto (serializovatelne) typy. =
Konkretne teda napriklad DataMessage by mela obsahovat tyto atributy:
buffer_size -> SInt<Int32, 32>
buffer_len -> SInt<Int32, 32>
offset -> SInt<Int32, 32>

-- Markoid

http://www.volny.cz/laredo/krtek/k01.html

> Zde uz ma tracked flag vliv. Pokud info neni v lokalizacni cache,
> a neni object tracked, pouziva se broadcast search  (3*N zprav);
> pokud je tracked, je velka pravedpodobnost ze prijde odpoved
> okamzite (+-2 zpravy).

To uz tam mame naimplementovany broadcast?

-- Markoid

Pristi tyden budu mit na schuzi cas takhle:
- v pondeli a ve stredu skoncit max v 16:30
- v utery zacit nejdriv v 18:00
- jinak kdykoli

A pokud bude schuze jeste tenhle tyden, tak ve ctvrtek
mi do toho neco vlezlo, musel bych se klidit nejdele
ve 13:00.

Marek

> Caues,=20
> Tak zitra jedu domu, takze na schuzi (zda vubec nejaka
> bude) se nedostavim. Prijedu v nedeli nabo v pondeli.


--------------------
NOVINKA na Centrum.cz SMS! Nahrajte si nov=E9 logo a vyzv=E1n=ECn=ED na=
 V=E1=B9 mobiln=ED telefon! http://sms.centrum.cz/loga

Caues, 

Tak zitra jedu domu, takze na schuzi (zda vubec nejaka

bude) se nedostavim. Prijedu v nedeli nabo v pondeli.


Petr

>Nechapu moc dobre, co tim myslis... CodeString je k zakodovani
>retezce, aby neobsahoval blanks, aspon podle dokumentace - k

Jo, sorry, kdyby CodeString mohl obsahovat blanks (coz nesmi z jinych
duvodu; napr. aby slo std::cin >> s; CodeString::decode( s ); ), pak by bylo
dobre, kdyby kodoval C-style. Takhle to mame ale tak, ze nekde se koduje
C-style (registry), jinde (zalohy napr.) jinak. Mozna by stalo za to se nad
tim jeste zamyslet.
-- Markoid

Caues, kdyz uz te Marek prudi za komity, tak si taky pridam :-)
Mozna vzhledem k predchozimu kontextu to nejsou bugy, ale moc tomu neverim.

Petr


> From: Marek Svantner <ma...@us...>

> Index: registry.cpp
> ===================================================================
> RCS file: /cvsroot/massiv/massiv/src/core/registry/registry.cpp,v

> !         /* string value has to be handled a special way... */
> !         if( line[ begpos ] == '"' )
> !             {
> !             std::string::iterator       it_end = line.begin() + begpos +
1;
> !             bool                        was_bslash = false;
> !             bool                        found_quote = false;
> !
> !             while( it_end != line.end() )
> !                 {
> !                 if( *it_end == '\\' )
> !                     {
> !                     if( was_bslash )
> !                         {
> !                         it_end = line.erase( it_end - 1 );
> !                         was_bslash = false;
> !                         }
> !                     else
> !                         {
> !                         was_bslash = true;
> !                         }
> !                     }
> !                 else
> !                 if( *it_end == '"' )
> !                     {
> !                     if( was_bslash )
> !                         {
> !                         it_end = line.erase( it_end - 1 );
> !                         was_bslash = false;
> !                         }
> !                     else
> !                         {
> !                         found_quote = true;
> !                         break;
> !                         }
> !                     }
> !                 else
> !                     {
> !                     was_bslash = false;
> !                     }
>
> +                 it_end++;
> +                 }

>>>>>>>>>>>>>>>>>>>>> Co kdyz zde je it_end == line.end()? Viz while cyklus
nahore.

> +             if( *it_end != '"' )
> +                 {
> +                 throw_syntax( "wrong string syntax, final quote not
found", line_number );
> +                 }
> +


>>>>>>>>>>>>>>>>>>>>> Co kdyz zde je it_end == line.end()?

> +             endpos = it_end - line.begin() + 1;
> +             }
> +         else
> +             {
> +             /* Variable value is not a string. */
> +             endpos = line.find_first_of( " \t", begpos );
> +             }
> +


>>>>>>>>>>>>>>>>>>>>>>>>> enpos muze byt end(), nebo end() + 1, ale oboje
>>>>>>>>>>>>>>>>>>>>>>>>> je _ruzne_ od std::string::npos.

> +         if( endpos == std::string::npos )  endpos = line.length();
>           var_value = line.substr( begpos, endpos - begpos );

From: "Marek Vondrak" <mvo...@ce...>
> > Ne, na release. Jeste pred stepanovymi zmenami.
> > Alokace bezela na gcc 8x rychleji nez msvc6,
> > ale samotna iterace bezela na gcc o trosku pomalejc nez msvc.
>
> Co jsem se ted dival, tak je tam akorat pridano nove mereni, nic navic.
Proc
> by to tedka melo bezet 6sec, kdyz stara verzi ti pry bezela 0.97s a me asi
> 2.5s ?


To nevim. Reportim jen vystupy.
Aktualni verse z cvska:

msvc6 release:
Allocation: 8.75258s, 0.875258ms per element.
Iteration: 0.680981s, 0.0034049ms per element.
Total: 9.43357s.

msvc6 debug:
Allocation: 20.89s, 2.089ms per element.
Iteration: 3.63523s, 0.0181761ms per element.
Total: 24.5253s.

Petr

> > Jinak nove testy (tvoje uprava) jsem netestoval, takze nechapu proc
Boovie
> > pise, ze to v MSVC jede najednou 8x pomalejc  - zrejme to asi meril na
> > debug?
>
>
> Ne, na release. Jeste pred stepanovymi zmenami.
> Alokace bezela na gcc 8x rychleji nez msvc6,
> ale samotna iterace bezela na gcc o trosku pomalejc nez msvc.

Co jsem se ted dival, tak je tam akorat pridano nove mereni, nic navic. Proc
by to tedka melo bezet 6sec, kdyz stara verzi ti pry bezela 0.97s a me asi
2.5s ?
-- Markoid

On Mon, 27 Jan 2003, Marek Vondrak wrote:

> Jinak nove testy (tvoje uprava) jsem netestoval, takze nechapu proc Boovie
> pise, ze to v MSVC jede najednou 8x pomalejc  - zrejme to asi meril na
> debug?


Ne, na release. Jeste pred stepanovymi zmenami.
Alokace bezela na gcc 8x rychleji nez msvc6,
ale samotna iterace bezela na gcc o trosku pomalejc nez msvc.

Petr

> + static const char * const EnvVarNodeConfigFile = "MASSIV_NODE_CONFPATH";
Wrong codestyle.

> +     cvar = &registry->access_variable( "str_with_bslash" );
> +     test_condition_( cvar->read_string() ==
"\\\\\\\\abc\\\\\\def\\\\" );

Nepouzivej prosim nove kodovani stringu. Mame tu uz CodeString. Pokud se ti
zda, ze kodovani stavajicim zpusobem je necitelne, mas pravdu a muzes to
predelat na C-style-string kodovani.

-- Markoid

> Pred zmenama v hashovani:
>
> > Allocation: 5.72s, 0.572ms per element.
> > Iteration: 1.12172s, 0.00560862ms per element.
> > Total: 6.84172s.
>
> Po zmenach v hashovani:
>
> Allocation: 0.727154s, 0.0727154ms per element.
> Iteration: 1.29487s, 0.00647436ms per element.
> Total: 2.02203s.
>
> Ok, alokace se trosku urychlila :-)
> Co nechapu je proc se iterace zpomalila. Zmenilo se jeste neco?

Protoze ten enumerator je normalni objekt, tak jak se s nim pohybuje v tom
seznamu, tak se meni properties a musi se stupidne neustale preregistrovavat
backward pointery (kvuli enumeraci migracnich skupin). Backward pointers
jsou hash_multimap<ObjectId, ...>. Planuju, ze to tohle jeste zoptimalizuju
(jakysi lazy mod, kdy se backward pointery prubezne neaktualizuji - az v
pripade, kdy se zjisti, ze pri enumeraci skupiny jsou neaktualni, cely se to
prepocita pruchodem celyho grafu).

Jinak nove testy (tvoje uprava) jsem netestoval, takze nechapu proc Boovie
pise, ze to v MSVC jede najednou 8x pomalejc  - zrejme to asi meril na
debug?

-- Markoid

Petr Tovarys wrote:
> Pristi tyden (za 15 minut "tento tyden" ) urcite schuze bude,
> minimalne ja, stoupik a markoid, ostatni vrele vitani.
> Proresit stoupikovy repliky + probrat aktualni stav
> spusteni vice serveru.
> Ja muzu kdykoliv kdekoliv.


Jo a jeste Markoid se tvaril ze by rad schuzi s vedoucim.
Me je to jedno, ale v tom pripade se ujmi ogranizace.

Petr

On Saturday 25 of January 2003 02:25, Petr Tovarys wrote:

> mingw:
> Allocation: 0.370533s, 0.0370533ms per element.
> Iteration: 0.741066s, 0.00370533ms per element.
> Total: 1.1116s.
>
> msvc6 (stlport):
> Allocation: 8.49221s, 0.849221ms per element.
> Iteration: 0.630909s, 0.00315454ms per element.
> Total: 9.12312s.
>
> Coz je docela hodne v neprospech msvc6...
> Co potrebuju ke spusteni tech javovskych testu?

Rekl bych, ze je na tom msvc porad lip, protoze mi jako dulezita prijde spis 
ta iterace - tam je jasne, co to dela a dela se to dost casto. Alokace je 
naprosta mlha diky tomu hashovani a drobnou zmenou v ObjectId se to muze 
zmenit dost hodne. Proto mi prijde divny tam jako hashovaci fci strkat pri 
provider_relative_id nebo podobne veci misto neceho "nahodneho". Takhle to 
sice mozna v tomto pripade funguje dobre (protoze se vyrabeji objekty s 
postupne inkrementovanym id), ale v obecnem to nekdy muze dost strasne selhat 
(jako tomu bylo pred tema zmenama).

Tady prikladam diffik na objectid.cpp, ktery z toho udela tak trochu "nahodne" 
hashovani. V testu to je u me pomalejsi, ale stejne bych to preferoval. 
Vyzkousej si zmenit ty ifdefy tak, aby se to pouzilo i v msvc. Schvalne, jak 
to dopadne.

Zatim to necommituju, protoze nevim, jaky je na todle obecny nazor.

diff -u -r1.9 objectid.cpp
--- objectid.cpp        23 Jan 2003 13:18:35 -0000      1.9
+++ objectid.cpp        26 Jan 2003 22:24:13 -0000
@@ -59,8 +59,26 @@
     #else

     // Unknown.
+    // Use  the Robert Jenkins' 32 bit mix function.
+
+    // TODO: Look if there is a 64 bit version here (or somewhere else):
+    // http://www.concentric.net/~Ttwang/tech/inthash.htm

-    hash = static_cast<size_t>( object_id.id * 12345678 );
+    // Stoupik's note:
+    // Even though this code does not result in fastest pointer test times,
+    // I think it's safer to use this "randomized" hash than only 
object_id.id.
+
+    hash  = static_cast< size_t >( object_id.id );
+    hash ^= static_cast< size_t >( object_id.id >> 32 );
+
+    hash += hash << 12;
+    hash ^= hash >> 22;
+    hash += hash << 4;
+    hash ^= hash >> 9;
+    hash += hash << 10;
+    hash ^= hash >> 2;
+    hash += hash << 7;
+    hash ^= hash >> 12;

     #endif

-- Stoupik

oc...@ma... wrote:
> ...
> 
>>net/net.cpp:2973: no matching function for call to 
>>`Massiv::Core::SystemMessage
>>  ::dispatch_system_message_from_packet(Massiv::Core::NetIBuffer,
>>  Massiv::Core::NodeId&)'
>>sysevent/system_msg.h:309: candidates are: static void   
>>Massiv::Core::SystemMessage::dispatch_system_message_from_packet
>>(Massiv::Core::BitIStream&,
>>  Massiv::Core::NodeId)
> 
> 
>>(stejne si to teda asi opravim driv nez se znova budu pripojovat, ale kdo 
>>vi...)
>>-- Stoupik
> 
> 
> 
> Zdar, rikal jsem Booviemu, ze mu predavam NetIBuffer, pravdepodobne si to
> zapomnel upravit. Je to triv, jen se upravi ta jedna funkce.
> Octa


Nee todle neni moje chyba.
Ty jsi totiz predaval argument jako
dispatch( (NetIBuffer) buffer )
cimz zakazes kompilatoru pouzit default konverzi
na "BitIStream &", kterou pouziva dispatch
Takze staci predavat argument bez pretypovani jako
dispatch( buffer ) a je to.


Petr

On Thursday 23 of January 2003 13:38, Stepan Vondrak wrote:

Pred zmenama v hashovani:

> Allocation: 5.72s, 0.572ms per element.
> Iteration: 1.12172s, 0.00560862ms per element.
> Total: 6.84172s.

Po zmenach v hashovani:

Allocation: 0.727154s, 0.0727154ms per element.
Iteration: 1.29487s, 0.00647436ms per element.
Total: 2.02203s.

Ok, alokace se trosku urychlila :-)
Co nechapu je proc se iterace zpomalila. Zmenilo se jeste neco?

-- Stoupik

=2E=2E=2E
>net/net=2Ecpp:2973: no matching function for call to=20
>`Massiv::Core::SystemMessage
>   ::dispatch_system_message_from_packet(Massiv::Core::NetIBuffer,
>   Massiv::Core::NodeId&)'
>sysevent/system_msg=2Eh:309: candidates are: static void  =20
>Massiv::Core::SystemMessage::dispatch_system_message_from_packet
>(Massiv::Core::BitIStream&,
>   Massiv::Core::NodeId)

>(stejne si to teda asi opravim driv nez se znova budu pripojovat, ale kdo=
=20
>vi=2E=2E=2E)
>-- Stoupik


Zdar, rikal jsem Booviemu, ze mu predavam NetIBuffer, pravdepodobne si to
zapomnel upravit=2E Je to triv, jen se upravi ta jedna funkce=2E
Octa

--------------------------------------------------------------------
mail2web - Check your email from the web at
http://mail2web=2Ecom/ =2E

On Thu, 23 Jan 2003, Stepan Vondrak wrote:
> Tak jsem ten testik trochu poupravil, snad to nebude konfliktit s pripadnejma
> zmenama od markoida. Na release:
>
> Allocation: 5.72s, 0.572ms per element.
> Iteration: 1.12172s, 0.00560862ms per element.
> Total: 6.84172s.



No me zajimalo, proc je mingw (gcc 3.2) pomalejsi nez
mcv6. A zjistil jsem, ze v makegenu pro gcc je nastavena
pouze optimalizace O2, ktera nedela napr. inlajnovani funkci
a dalsi optimalizace.
Takze jsem zapl este nejake dalsi optimalizace,
a vysledky na mem kompu (duron 600) pro release optimized
jsou uz daleko zajimavejsi:

mingw:
Allocation: 0.370533s, 0.0370533ms per element.
Iteration: 0.741066s, 0.00370533ms per element.
Total: 1.1116s.

msvc6 (stlport):
Allocation: 8.49221s, 0.849221ms per element.
Iteration: 0.630909s, 0.00315454ms per element.
Total: 9.12312s.

Coz je docela hodne v neprospech msvc6...
Co potrebuju ke spusteni tech javovskych testu?

Petr

Pristi tyden nejsem v praze, takze pokud
to neni problem, navrhuji  presunout schuzku az na ten
dalsi tyden (zacatek unora).

DataObjectManager ma naimplementovano stahovani dat,
ale jeste je treba to odladit - pod linuxem to pada.

Hafik

On Fri, 10 Jan 2003, Marek Vondrak wrote:

> > Jinak predelaval jsem STime na Float64, ale pak mi kompilator MSVC 6.0
> > nahlasit internal error pri kompilaci factgen_objects_factory.cpp nebo
> > factories.cpp, nejsem si uz presne jist.
> > Posilam v priloze stype_time.h upraveny na Float64, zkuste to nekdo,
> > jestli vam to pujde prelozit.
> >
> > Takze jsem STime zatim nechal byt, a je stale UInt64.
>
> Podivam se na to.
> -- Markoid


Uz by se to konecne mohlo predelat.

Petr

Compile error v aktualnim CVS.

net/net.cpp: In member function `int  
Massiv::Core::Network::receive_in_connected_state(Massiv::Core::ConnectionInfo*,
   Massiv::Core::NodeId)':
net/net.cpp:2873: no matching function for call to 
`Massiv::Core::SystemMessage
   ::dispatch_system_message_from_packet(Massiv::Core::NetIBuffer,
   Massiv::Core::NodeId&)'
sysevent/system_msg.h:309: candidates are: static void   
Massiv::Core::SystemMessage::dispatch_system_message_from_packet(Massiv::Core::BitIStream&,
   Massiv::Core::NodeId)
net/net.cpp:2973: no matching function for call to 
`Massiv::Core::SystemMessage
   ::dispatch_system_message_from_packet(Massiv::Core::NetIBuffer,
   Massiv::Core::NodeId&)'
sysevent/system_msg.h:309: candidates are: static void   
Massiv::Core::SystemMessage::dispatch_system_message_from_packet(Massiv::Core::BitIStream&,
   Massiv::Core::NodeId)

(stejne si to teda asi opravim driv nez se znova budu pripojovat, ale kdo 
vi...)
-- Stoupik

On Tuesday 21 of January 2003 23:18, Stepan Vondrak wrote:
> On Tuesday 21 of January 2003 22:11, Petr Tovarys wrote:
> > Caues,
> > Pointer server test, linux, gcc 3.2 release mode,
> > AMD Duron 600MHz: 4.87
> > Na debug mode neco kolem 103 sekund :)
>
> AMD Athlon 500MHz na debug: asi 150 sekund (trochu jsem do toho klikal a
> swapil). Na release nejsem schopen sdelit, budu muset uvolnit par set MB
> disku a pres noc to prelozit.

Tak jsem ten testik trochu poupravil, snad to nebude konfliktit s pripadnejma 
zmenama od markoida. Na release:

Allocation: 5.72s, 0.572ms per element.
Iteration: 1.12172s, 0.00560862ms per element.
Total: 6.84172s.

-- Stoupik

Bohuzel je to porad asi 2x pomalejsi nez stejny program v Jave (viz
priloha). Je treba si ale uvedomit, ze mi od toho pozadujeme vic nez Java -
napr. monitorovani pristupu do properties, registrovani zpetnych pointeru
kvuli migracnim skupinam apod.
-- Markoid