++> Network is Computing <++

---------- Forwarded message ----------From: Martin Cracauer <cracauer@cons.org>Date: Sep 15, 2006 2:03 AM Subject: Re: numbers don't lie ...To: Danny Braniss <danny@cs.huji.ac.il>Cc: freebsd-hackers@freebsd.org Danny Braniss wrote on Wed, Sep 13, 2006 at 09:36:01AM +0300:> Im testing these 2 boxes, Sun X4100 and Dell-2950, and:>>       SUN X4100:      Dual Core AMD Opteron(tm) Processor 280 (2393.19-MHz K8-class CPU) >                       one 70g sata disk>       DELL 2950:      Intel(R) Xeon(TM) CPU 3.20GHz (3192.98-MHz K8-class CPU)>                       4 sata disks + raid0>> they both run identical 6.1-STABLE.>> my 'cpu benchmark' shows the amd being much better than the intel.> but, doing a make buildworld give interesting results:>> dell-2950 : make -j16 TARGET_ARCH=amd64 buildworld : 24m17.41s real 1h3m3.26s> user 17m15.07s sys> dell-2950 : make -j8 TARGET_ARCH=amd64 buildworld : 24m8.28s real 1h2m59.38s> user 16m16.20s sys>> sunfire : make -j16 TARGET_ARCH=amd64 buildworld : 24m21.38s real 49m6.68s> user 14m22.64s sys> sunfire : make -j8 TARGET_ARCH=amd64 buildworld : 23m47.69s real 48m53.58s> user 13m44.81s sys>> which probably says something about my 'cpu benchmark' :-( > but why is the user time so much different between the boxes?I don't think this has much to do with parallelism or hyperthreading.You can test by running make -j1, the AMD will probably still befaster. Fact is that the AMD64 is much more suitable to run "random" codefast, whereas Intel's Netburst architecture is extremely picky andonly runs fast what it likes (after the programmer went through Intel's 500 pages ia32 optimization manual and could yell at thecompiler writer all the time).  Compilation in gcc and scripting ofany kind, including make(1) are one of the strongest points of AMD64over Netburst. Toy benchmarks usually run fast on Netburst because they fit into thecaches, they don't overtax the trace cache and they usually don't useany good amount of data or any sizeable piece of code with deep call stacks.  That's why toy benchmarks are so evil.  I wish spec wouldkick out more of their toy benchmarks, BTW.Intel's new core2 architecture rectifies this nonsense.  And not onlythat - they now give you a good speedup for some applications that were lousy even on AMD64.Martin--%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%Martin Cracauer <cracauer@cons.org>   http://www.cons.org/cracauer/FreeBSD - where you want to go, today.      http://www.freebsd.org/_______________________________________________ freebsd-hackers@freebsd.org mailing listhttp://lists.freebsd.org/mailman/listinfo/freebsd-hackersTo unsubscribe, send any mail to " freebsd-hackers-unsubscribe@freebsd.org"

Makefile.am, Makefile.in, Makefile文件之间关系以及aclocal, automake, autoconf等命令作用的探究

aclocal # 产生 aclocal.m4
libtoolize --force
automake --add-missing # 根据Makefile.am生成Makefile.in
autoconf # 根据configure.in 生成configure
autoheader

为了弄清楚automake等一系列命令的作用，专门搜集并阅读了一些相关资料。并通过下面一个小例子，熟悉了一下这些GNU工具的使用：

例子：在/hello/目录下创建一个hello.c文件，并编译运行它：

#cd /hello/

(1) 编写源文件hello.c：

include
int main(int argc, char** argv)
{
printf("Hello, GNU!n");
return 0;
}

(2) #autoscan
->生成 configure.scan 和 autoscan.log

(3) 将configure.scan 修改为 configure.in：

# Process this file with autoconf to produce a configure script.
AC_INIT(hello.c)
AM_INIT_AUTOMAKE(hello, 1.0)

# Checks for programs.
AC_PROG_CC

# Checks for library functions.
AC_OUTPUT(Makefile)

(4) #aclocal
->生成 aclocal.m4 和 autom4te.cache (生成aclocal.m4的过程中涉及到configure.in)

(5) #autoconf
->生成 configure (根据 configure.in, 和 aclocal.m4)

(6) 编写Makefile.am：

AUTOMAKE_OPTIONS= foreign
bin_PROGRAMS= hello
hello_SOURCES= hello.c

(7) #automake --add-missing
->生成 Makefile.in， depcomp， install-sh， 和 missing (根据 Makefile.am, 和 aclocal.m4)

(8) #./configure
->生成 Makefile， config.log， 和 config.status

I dont know how to edit the template,
Im not very familiar with the html code. I seldomly used these in the past.