On Wed, 27 May 2003, Florin Andrei wrote:
> On Tue, 2003-05-27 at 20:27, Alexandru N. Barloiu wrote:
> > se vorbea ieri pe #mumu de ht de la intel si de icc. dimineata la 4 m-am
> > trezit si n-aveam ce face asa ca m-am apucat sa ma distrez cu icc.
>
> geek :-P
>
> > printre altele am compilat si php4 ( de la snaps.php.net ultima versiune
> > de 4.5 deci non_STABLE ) cu icc. nu mica mi-a fost mirarea cand am vazut
> > ca scriptele se accelereaza cu 40-50%. u ppl might want to try that some
> > time.
>
> Ar fi interesant de comparat optiunile pe care le-ai folosit cu icc, si
> optiunile pe care le-ai folosit cu gcc. De asemenea si versiunile exacte
> ale celor doua compilatoare.
> Niste teste destul de extensive pe care le-am vazut nu demult aratau ca,
> desi icc e inca lider per total, gcc s-a apropiat destul de tare.
linux root # cat /proc/cpuinfo ; gcc -v ; icc -V
processor : 0
vendor_id : GenuineIntel
cpu family : 15
model : 2
model name : Intel(R) Pentium(R) 4 CPU 2.00GHz
stepping : 4
cpu MHz : 1993.981
cache size : 512 KB
fdiv_bug : no
hlt_bug : no
f00f_bug : no
coma_bug : no
fpu : yes
fpu_exception : yes
cpuid level : 2
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca
cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm
bogomips : 3971.48
---
BTW ca paranteza de ce procesorul meu are flag ht ?
---
Reading specs from /usr/lib/gcc-lib/i686-pc-linux-gnu/3.2.3/specs
Configured with: /var/tmp/portage/gcc-3.2.3-r1/work/gcc-3.2.3/configure
--prefix=/usr --bindir=/usr/i686-pc-linux-gnu/gcc-bin/3.2
--includedir=/usr/lib/gcc-lib/i686-pc-linux-gnu/3.2.3/include
--datadir=/usr/share/gcc-data/i686-pc-linux-gnu/3.2
--mandir=/usr/share/gcc-data/i686-pc-linux-gnu/3.2/man
--infodir=/usr/share/gcc-data/i686-pc-linux-gnu/3.2/info --enable-shared
--host=i686-pc-linux-gnu --target=i686-pc-linux-gnu --with-system-zlib
--enable-languages=c,c++,ada,f77,objc,java --enable-threads=posix
--enable-long-long --disable-checking --enable-cstdio=stdio
--enable-clocale=generic --enable-__cxa_atexit
--enable-version-specific-runtime-libs
--with-gxx-include-dir=/usr/lib/gcc-lib/i686-pc-linux-gnu/3.2.3/include/g++-v3
--with-local-prefix=/usr/local
--enable-shared --enable-nls --without-included-gettext
Thread model: posix
gcc version 3.2.3 20030422 (Gentoo Linux 1.4 3.2.3-r1, propolice)
Intel(R) C++ Compiler for 32-bit applications, Version 7.1 Build
20030307Z
Copyright (C) 1985-2003 Intel Corporation. All rights reserved.
FOR NON-COMMERCIAL USE ONLY
> Spre exemplu, si cu gcc obtii rezultate interesante d.p.d.v. al vitezei
> daca bagi chestii gen "-march=athlon-xp (sau =pentium3 sau 4, depinde)
> -mfpmath=sse" si-apoi adaugi -funroll-loops si-altele de-astea (depinde
> de context).
sorry. as testa, pt ca sunt curios daca icc chiar merge pe athloane cu se
zvoneste, dar nu am nici un amd ( doar un k6 ). so toate testele pe care
le-am facut au fost pe sisteme intel ia-32 - p2, p3 si p4. Nici un HT
momentan pt inca o saptamana.
la compilare system wide am folosit gcc-3.2.3 cu optiuniile:
-mcpu=pentium4 -march=pentium4 -mmmx -msse -msse2 -O3 -pipe
din ce am citit am dedus ca daca pun -march=pentium4 implica si mmmx msse
si msse2 dar eu totusi le-am pus. tot din ce am citit am dedus ca O6/O5
este mit si ca cele mai bune optimizari sunt O3. Mai mult nu m-am
documentat.
la compilare cu icc am folosit DOAR -march=pentium4 -O3.
cele doua comparatii cu php le-am facut pe acelasi sistem. diferentele
intre teste au fost legate doar de libphp4.so. NIMIC MAI MULT. scripturile
in mare parte s-au accelerat cu 40-50%, atat cele care erau doar
php_standard, cat si legate de alte module ( mysql, imap, libgd etc).
am crezut un pic mai devreme ca am reusit sa compilez si mysql cu icc dar
nu fusesem foarte atent. s-a agatat de threaduri multiple. am o vaga
impresie ca totusi e ceva simplu legat de PATH si nicidecum o limitare a
lui icc. nu ma prea pricep la C/C++ asa ca ma dumiresc mai greu.
sunt foarte curios cum se va misca php cand toate sau macar o parte
importanta din modulele lui adiacente sunt facute cu icc.
> Problema este ca trebuie sa gasesti idealul intre un program foarte
> optimizat dar foarte mare (majoritatea optimizarilor umfla marimea
> binarului) si unul mic dar neoptimizat. Cauza este marimea ridicol de
> mica a cache-ului la procesoarele x86 (256k, 512k); daca optimizezi prea
> tare, incepe de fapt sa mearga mai incet, pentru ca executabilul devine
> prea mare si "oboseste" cache-ul.
de la gcc cu optiuniile precizate anterior la icc .so-ul meu a crescut
doar cu 100k ( ne stripuit ) ceea ce nu pare sa fie mult. total nestripuit
are around 4Mb. stripuit 3.4Mb :)
> /me, uitindu-se la un sistem cu procesor MIPS din anii '90, cu cache de
> 2MB
---
Alexandru N. Barloiu <[EMAIL PROTECTED]>
Dale Media
