AMD64 vs i386

Dan Lukes dan at obluda.cz
Sun Aug 19 11:43:36 CEST 2007


Roman Divacky wrote:
>>>>>> Priznam se, ze freebsd pouzivam uplne na jinych platformach nez
>>>>>> enterprise serverech a tam je i386 uplne v pohode a nikdy nepresahnu 1GB
>>>>>> pameti. 

> 	Nevadi, tak nabidni nejaky jiny priklad typickeho nasazeni jak jsem uz psal.. treba ten varnish nebo zfs.

	Oboji veci, ktere vlastne jeste neexistuji. Prinejmensim ne pro FreeBSD 
v produkcnim nasazeni. Tim by se vysvetloval rozpor mezi tvrzenim shora 
a tvym tvrzenim.

	Tam slo, zrejme, seriozni produkcni nasazeni, u tebe jde o nasazeni 
ladicich a experimentalnich verzi (ovsem to, ze ty takove nasazujes i na 
produkcni servery vime a prejeme ti to ;-) ).

> bude je inteligentne zpracovavat pres mmap misto read/write

	To je argumentace kruhem. Nejprve vyresis problem pomoci algoritmu, 
ktery je navrzen tak, aby k jeho efektivni implementaci byl potrebny 
mmap() - a pak timto algoritmem dokazujes potrebnost mmapu.

	To neni dukaz, ze AMD64 je lepsi, ale ze existuji smysluplne aplikace, 
ktere lze optimalizovat "jemu na telo". ;-)

	Tim se nesnazim rikat, ze mmap() a/nebo AMD64 jsou zbytecne, jen se 
snazim zjistit, jestli tvuj zcela vyhraneny pohled na ma AMD64/i386 je 
podepren nejakymi argumenty, ktere bych mohl nejak pouzit pri svych 
uvahach.

	Zatim jsem vyrozumel, ze pro soucasne produkcni nasazeni (vyjma situaci 
kdy potrebujes vic nez 4GB pameti) celkem beze smyslu, ale musime 
ocekavat, ze se na nas hrnou nektere specializovane aplikace, ktere 
budou AMD64 vyzadovat.

> http://varnish.projects.linpro.no/wiki/ArchitectNotes
> tam je celkem dost pekne popsane proc je potreba hodne virtualni pameti

To jsem tam nenasel. Tam jsem nasel, ze:
"Virtual memory was meant to make it easier to program"

	Nicmene, o detailech rozdilu mezi timhle tvrzenim a vyznamu, ktery mu 
ty pripisujes tom bych se tu s tebou nerad dohadoval. Uz v pristim kole 
diskuse bychom narazili na rozdily zebricek hodnot a o tom davno vime, 
ze ho mame jiny a nedohodneme se ;-)


						Dan




More information about the Users-l mailing list