Re: [Xenomai-core] [PATCH] speed up building of posix apps
Gilles Chanteperdrix wrote: Jan Kiszka wrote: Gilles Chanteperdrix wrote: Jan Kiszka wrote: Ok, here comes version 2, now with detection of the required ld feature. Falls back to normal behaviour if ld is too old. Could you test it please? [Grmbl, the fun stops where autoconf begins...] Seems to work. But maybe we could find the bottleneck and fix it in a general way. What part of the process is slow ? Don't know. Maybe it's some automake magic (the arguments look different between libtool invocation and linker run), maybe just the long list of arguments. Anyway, it's also annoying how the screen is filled up with this irrelevant information. So besides looking for other optimisations (but things run fine now I think), I definitely vote for the @file approach for the sake of output reduction. I haven't build a larger POSIX project against Xenomai recently, but I could imagine that the dump size can become even more than just annoying... Patch applied, thanks. Since we are talking about optimisation, in shell scripts, I prefer to set a variable to true (or better, the : builtin) or false, this way, it may be used directly as a condition. Sorry, don't get yet what part you are referring to. If you would like to express something in that patch differently, go ahead. I was already happy when it worked. :) Jan signature.asc Description: OpenPGP digital signature ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
[Xenomai-core] [PATCH] speed up building of posix apps
Hi, with the growing number of wrapped posix applications also their fairly slow build process became visible. It somehow scaled badly. I had the idea to pass all wrapping commands to the linker via a file for quite some time. Now I tried it and it gives a nice speedup of roughly 400% for me when building typical single-file apps (mileage may vary, I'm building on vmware box...). Moreover, it beautifies the compiler output. Tested on various setups, no regressions known so far. Jan PS: What about the silence-libtool patch? I've heard neither ack nor nack so far. Index: configure.in === --- configure.in(revision 1453) +++ configure.in(working copy) @@ -525,8 +525,7 @@ XENO_USER_APP_CFLAGS=$XENO_USER_CFLAGS XENO_USER_CFLAGS=$XENO_USER_CFLAGS -D__IN_XENO__ -Wstrict-prototypes XENO_USER_APP_LDFLAGS=$XENO_USER_LDFLAGS -XENO_POSIX_WRAPPERS=`while read symbol; do echo -n -Wl,--wrap,$symbol ; done \ - $srcdir/src/skins/posix/posix.wrappers` +XENO_POSIX_WRAPPERS=-Wl,@`cd $srcdir pwd`/src/skins/posix/posix.wrappers AC_MSG_CHECKING(whether POSIX skin library automatically calls mlockall) AC_ARG_ENABLE(posix-auto-mlockall, Index: src/skins/posix/posix.wrappers === --- src/skins/posix/posix.wrappers (revision 1453) +++ src/skins/posix/posix.wrappers (working copy) @@ -1,89 +1,89 @@ -pthread_create -pthread_detach -pthread_setschedparam -pthread_getschedparam -pthread_yield -sched_yield -sem_init -sem_destroy -sem_post -sem_timedwait -sem_wait -sem_trywait -sem_getvalue -sem_open -sem_close -sem_unlink -clock_getres -clock_gettime -clock_settime -clock_nanosleep -nanosleep -pthread_mutexattr_init -pthread_mutexattr_destroy -pthread_mutexattr_gettype -pthread_mutexattr_settype -pthread_mutexattr_getprotocol -pthread_mutexattr_setprotocol -pthread_mutexattr_getpshared -pthread_mutexattr_setpshared -pthread_mutex_init -pthread_mutex_destroy -pthread_mutex_lock -pthread_mutex_trylock -pthread_mutex_timedlock -pthread_mutex_unlock -pthread_condattr_init -pthread_condattr_destroy -pthread_condattr_getclock -pthread_condattr_setclock -pthread_condattr_getpshared -pthread_condattr_setpshared -pthread_cond_init -pthread_cond_destroy -pthread_cond_wait -pthread_cond_timedwait -pthread_cond_signal -pthread_cond_broadcast -mq_open -mq_close -mq_unlink -mq_getattr -mq_setattr -mq_send -mq_timedsend -mq_receive -mq_timedreceive -mq_notify -open -socket -close -ioctl -read -write -recvmsg -sendmsg -recvfrom -sendto -recv -send -getsockopt -setsockopt -bind -connect -listen -accept -getsockname -getpeername -shutdown -timer_create -timer_delete -timer_settime -timer_getoverrun -timer_gettime -ftruncate -close -shm_open -shm_unlink -mmap -munmap +--wrap pthread_create +--wrap pthread_detach +--wrap pthread_setschedparam +--wrap pthread_getschedparam +--wrap pthread_yield +--wrap sched_yield +--wrap sem_init +--wrap sem_destroy +--wrap sem_post +--wrap sem_timedwait +--wrap sem_wait +--wrap sem_trywait +--wrap sem_getvalue +--wrap sem_open +--wrap sem_close +--wrap sem_unlink +--wrap clock_getres +--wrap clock_gettime +--wrap clock_settime +--wrap clock_nanosleep +--wrap nanosleep +--wrap pthread_mutexattr_init +--wrap pthread_mutexattr_destroy +--wrap pthread_mutexattr_gettype +--wrap pthread_mutexattr_settype +--wrap pthread_mutexattr_getprotocol +--wrap pthread_mutexattr_setprotocol +--wrap pthread_mutexattr_getpshared +--wrap pthread_mutexattr_setpshared +--wrap pthread_mutex_init +--wrap pthread_mutex_destroy +--wrap pthread_mutex_lock +--wrap pthread_mutex_trylock +--wrap pthread_mutex_timedlock +--wrap pthread_mutex_unlock +--wrap pthread_condattr_init +--wrap pthread_condattr_destroy +--wrap pthread_condattr_getclock +--wrap pthread_condattr_setclock +--wrap pthread_condattr_getpshared +--wrap pthread_condattr_setpshared +--wrap pthread_cond_init +--wrap pthread_cond_destroy +--wrap pthread_cond_wait +--wrap pthread_cond_timedwait +--wrap pthread_cond_signal +--wrap pthread_cond_broadcast +--wrap mq_open +--wrap mq_close +--wrap mq_unlink +--wrap mq_getattr +--wrap mq_setattr +--wrap mq_send +--wrap mq_timedsend +--wrap mq_receive +--wrap mq_timedreceive +--wrap mq_notify +--wrap open +--wrap socket +--wrap close +--wrap ioctl +--wrap read +--wrap write +--wrap recvmsg +--wrap sendmsg +--wrap recvfrom +--wrap sendto +--wrap recv +--wrap send +--wrap getsockopt +--wrap setsockopt +--wrap bind +--wrap connect +--wrap listen +--wrap accept +--wrap getsockname +--wrap getpeername +--wrap shutdown +--wrap timer_create +--wrap timer_delete +--wrap timer_settime +--wrap timer_getoverrun +--wrap timer_gettime +--wrap ftruncate +--wrap close +--wrap shm_open +--wrap shm_unlink +--wrap mmap +--wrap munmap Index: scripts/xeno-config.in === --- scripts/xeno-config.in (revision 1453) +++
Re: [Xenomai-core] [PATCH] speed up building of posix apps
On Fri, 2006-08-18 at 14:05 +0200, Jan Kiszka wrote: PS: What about the silence-libtool patch? I've heard neither ack nor nack so far. Still pondering the libtool --module issue. -- Philippe. ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] [PATCH] speed up building of posix apps
Philippe Gerum wrote: On Fri, 2006-08-18 at 14:05 +0200, Jan Kiszka wrote: PS: What about the silence-libtool patch? I've heard neither ack nor nack so far. Still pondering the libtool --module issue. Try a grep -r shouldnotlink `find /usr/lib/ -name *.la` to get an impression what kind of libraries were linked with --module and what most likely not. I cannot imagine they all do such patching like we. :) Jan signature.asc Description: OpenPGP digital signature ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] [PATCH] speed up building of posix apps
Jan Kiszka wrote: Hi, with the growing number of wrapped posix applications also their fairly slow build process became visible. It somehow scaled badly. I had the idea to pass all wrapping commands to the linker via a file for quite some time. Now I tried it and it gives a nice speedup of roughly 400% for me when building typical single-file apps (mileage may vary, I'm building on vmware box...). Moreover, it beautifies the compiler output. Tested on various setups, no regressions known so far. Jan PS: What about the silence-libtool patch? I've heard neither ack nor nack so far. Index: configure.in === --- configure.in (revision 1453) +++ configure.in (working copy) @@ -525,8 +525,7 @@ XENO_USER_APP_CFLAGS=$XENO_USER_CFLAGS XENO_USER_CFLAGS=$XENO_USER_CFLAGS -D__IN_XENO__ -Wstrict-prototypes XENO_USER_APP_LDFLAGS=$XENO_USER_LDFLAGS -XENO_POSIX_WRAPPERS=`while read symbol; do echo -n -Wl,--wrap,$symbol ; done \ - $srcdir/src/skins/posix/posix.wrappers` +XENO_POSIX_WRAPPERS=-Wl,@`cd $srcdir pwd`/src/skins/posix/posix.wrappers Does not work here: the @ is passed to ld which does not know how to handle it. -- Gilles Chanteperdrix. ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] [PATCH] speed up building of posix apps
Gilles Chanteperdrix wrote:
Jan Kiszka wrote:
Hi,
with the growing number of wrapped posix applications also their fairly
slow build process became visible. It somehow scaled badly.
I had the idea to pass all wrapping commands to the linker via a file
for quite some time. Now I tried it and it gives a nice speedup of
roughly 400% for me when building typical single-file apps (mileage may
vary, I'm building on vmware box...). Moreover, it beautifies the
compiler output.
Tested on various setups, no regressions known so far.
Jan
PS: What about the silence-libtool patch? I've heard neither ack nor
nack so far.
Index: configure.in
===
--- configure.in (revision 1453)
+++ configure.in (working copy)
@@ -525,8 +525,7 @@ XENO_USER_APP_CFLAGS=$XENO_USER_CFLAGS
XENO_USER_CFLAGS=$XENO_USER_CFLAGS -D__IN_XENO__ -Wstrict-prototypes
XENO_USER_APP_LDFLAGS=$XENO_USER_LDFLAGS
-XENO_POSIX_WRAPPERS=`while read symbol; do echo -n -Wl,--wrap,$symbol ;
done \
- $srcdir/src/skins/posix/posix.wrappers`
+XENO_POSIX_WRAPPERS=-Wl,@`cd $srcdir
pwd`/src/skins/posix/posix.wrappers
Does not work here: the @ is passed to ld which does not know how to
handle it.
Ok, here comes version 2, now with detection of the required ld feature.
Falls back to normal behaviour if ld is too old. Could you test it please?
[Grmbl, the fun stops where autoconf begins...]
Thanks,
Jan
Index: configure.in
===
--- configure.in(revision 1456)
+++ configure.in(working copy)
@@ -525,8 +525,27 @@ XENO_USER_APP_CFLAGS=$XENO_USER_CFLAGS
XENO_USER_CFLAGS=$XENO_USER_CFLAGS -D__IN_XENO__ -Wstrict-prototypes
XENO_USER_APP_LDFLAGS=$XENO_USER_LDFLAGS
-XENO_POSIX_WRAPPERS=`while read symbol; do echo -n -Wl,--wrap,$symbol ; done
\
- $srcdir/src/skins/posix/posix.wrappers`
+AC_MSG_CHECKING([whether ld supports @file])
+AC_CACHE_VAL(ac_cv_ld_file_option,
+ AC_LANG_SAVE
+ AC_LANG_C
+ save_LDFLAGS=$LDFLAGS
+ [LDFLAGS=-Wl,@/dev/null]
+ AC_LINK_IFELSE([main(){}],
+[ac_cv_ld_file_option=yes],
+[ac_cv_ld_file_option=no])
+ LDFLAGS=$save_LDFLAGS
+ AC_LANG_RESTORE)
+if [[ $ac_cv_ld_file_option = yes ]]; then
+ XENO_POSIX_WRAPPERS=-Wl,@`cd $srcdir
pwd`/src/skins/posix/posix.wrappers
+else
+ XENO_POSIX_WRAPPERS=`while read wrap_option symbol; do \
+ echo -n -Wl,$wrap_option,$symbol ; \
+ done $srcdir/src/skins/posix/posix.wrappers`
+fi
+AC_MSG_RESULT(${ac_cv_ld_file_option:-no})
+LD_FILE_OPTION=$ac_cv_ld_file_option
+AC_SUBST(LD_FILE_OPTION)
AC_MSG_CHECKING(whether POSIX skin library automatically calls mlockall)
AC_ARG_ENABLE(posix-auto-mlockall,
Index: src/skins/posix/posix.wrappers
===
--- src/skins/posix/posix.wrappers (revision 1456)
+++ src/skins/posix/posix.wrappers (working copy)
@@ -1,89 +1,89 @@
-pthread_create
-pthread_detach
-pthread_setschedparam
-pthread_getschedparam
-pthread_yield
-sched_yield
-sem_init
-sem_destroy
-sem_post
-sem_timedwait
-sem_wait
-sem_trywait
-sem_getvalue
-sem_open
-sem_close
-sem_unlink
-clock_getres
-clock_gettime
-clock_settime
-clock_nanosleep
-nanosleep
-pthread_mutexattr_init
-pthread_mutexattr_destroy
-pthread_mutexattr_gettype
-pthread_mutexattr_settype
-pthread_mutexattr_getprotocol
-pthread_mutexattr_setprotocol
-pthread_mutexattr_getpshared
-pthread_mutexattr_setpshared
-pthread_mutex_init
-pthread_mutex_destroy
-pthread_mutex_lock
-pthread_mutex_trylock
-pthread_mutex_timedlock
-pthread_mutex_unlock
-pthread_condattr_init
-pthread_condattr_destroy
-pthread_condattr_getclock
-pthread_condattr_setclock
-pthread_condattr_getpshared
-pthread_condattr_setpshared
-pthread_cond_init
-pthread_cond_destroy
-pthread_cond_wait
-pthread_cond_timedwait
-pthread_cond_signal
-pthread_cond_broadcast
-mq_open
-mq_close
-mq_unlink
-mq_getattr
-mq_setattr
-mq_send
-mq_timedsend
-mq_receive
-mq_timedreceive
-mq_notify
-open
-socket
-close
-ioctl
-read
-write
-recvmsg
-sendmsg
-recvfrom
-sendto
-recv
-send
-getsockopt
-setsockopt
-bind
-connect
-listen
-accept
-getsockname
-getpeername
-shutdown
-timer_create
-timer_delete
-timer_settime
-timer_getoverrun
-timer_gettime
-ftruncate
-close
-shm_open
-shm_unlink
-mmap
-munmap
+--wrap pthread_create
+--wrap pthread_detach
+--wrap pthread_setschedparam
+--wrap pthread_getschedparam
+--wrap pthread_yield
+--wrap sched_yield
+--wrap sem_init
+--wrap sem_destroy
+--wrap sem_post
+--wrap sem_timedwait
+--wrap sem_wait
+--wrap sem_trywait
+--wrap sem_getvalue
+--wrap sem_open
+--wrap sem_close
+--wrap sem_unlink
+--wrap clock_getres
+--wrap clock_gettime
+--wrap clock_settime
+--wrap clock_nanosleep
+--wrap nanosleep
+--wrap pthread_mutexattr_init
+--wrap pthread_mutexattr_destroy
+--wrap
Re: [Xenomai-core] [PATCH] speed up building of posix apps
Jan Kiszka wrote: Ok, here comes version 2, now with detection of the required ld feature. Falls back to normal behaviour if ld is too old. Could you test it please? [Grmbl, the fun stops where autoconf begins...] Seems to work. But maybe we could find the bottleneck and fix it in a general way. What part of the process is slow ? -- Gilles Chanteperdrix. ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] [PATCH] speed up building of posix apps
Gilles Chanteperdrix wrote: Jan Kiszka wrote: Ok, here comes version 2, now with detection of the required ld feature. Falls back to normal behaviour if ld is too old. Could you test it please? [Grmbl, the fun stops where autoconf begins...] Seems to work. But maybe we could find the bottleneck and fix it in a general way. What part of the process is slow ? Don't know. Maybe it's some automake magic (the arguments look different between libtool invocation and linker run), maybe just the long list of arguments. Anyway, it's also annoying how the screen is filled up with this irrelevant information. So besides looking for other optimisations (but things run fine now I think), I definitely vote for the @file approach for the sake of output reduction. I haven't build a larger POSIX project against Xenomai recently, but I could imagine that the dump size can become even more than just annoying... Jan signature.asc Description: OpenPGP digital signature ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] [PATCH] speed up building of posix apps
Jan Kiszka wrote: Gilles Chanteperdrix wrote: Jan Kiszka wrote: Ok, here comes version 2, now with detection of the required ld feature. Falls back to normal behaviour if ld is too old. Could you test it please? [Grmbl, the fun stops where autoconf begins...] Seems to work. But maybe we could find the bottleneck and fix it in a general way. What part of the process is slow ? Don't know. Maybe it's some automake magic (the arguments look different between libtool invocation and linker run), maybe just the long list of arguments. Anyway, it's also annoying how the screen is filled up with this irrelevant information. So besides looking for other optimisations (but things run fine now I think), I definitely vote for the @file approach for the sake of output reduction. I haven't build a larger POSIX project against Xenomai recently, but I could imagine that the dump size can become even more than just annoying... Patch applied, thanks. Since we are talking about optimisation, in shell scripts, I prefer to set a variable to true (or better, the : builtin) or false, this way, it may be used directly as a condition. -- Gilles Chanteperdrix. ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
