Fons,
Thanks for the suggestion but that doesn't change anything.
Damir
Fons Rademakers wrote:
>
> Damir,
>
> could you try to make the shared lib read-only on the Alpha:
>
> chmod 555 bla.so
>
> On HP-UX this makes a huge difference, because when a shared lib is
> writable
> the OS makes all kind of extra checks to see that the lib is not
> changed.
> Might also be the case on Alpha.
>
> Cheers, Fons.
>
> Damir Buskulic wrote:
> >
> > Hi,
> >
> > I have a very strange (for me) problem on alpha.
> > First we noticed a very big (5 times) slowdown in one of our programs in
> > very particular circumstances. It was for example depending on the value
> > of the DISPLAY variable on one machine (:0.0 fast, virgoa3:0.0 slow !).
> > I tracked down the problem to a very simple program :
> >
> > #include <time.h>
> > #include <stdio.h>
> > #include <stdlib.h>
> > #include <fcntl.h>
> >
> > //int main_dada()
> > int main()
> > {int fd;
> > char header [40];
> > char *buf;
> > unsigned short type;
> > unsigned int length;
> > clock_t t1,t4;
> >
> > fd = open("FR0-26.dat", O_RDONLY, 0644);
> > if(fd < 0) {return (0);}
> >
> > length = 11;
> > while(length> 10) {
> > t1 = clock(); // begin timing
> >
> > buf = malloc(255);
> > if(read(fd, buf, 25) == 0) return(0);
> > free (buf);
> >
> > t4 = clock(); // end timing
> >
> > printf("length=%8d t4 - t1 = %d\n",length,t4-t1); // print it
> > }
> > }
> >
> > In this code, I'm just timing the successive reads of chunks of data in
> > a file.
> >
> > Now the interesting part : when I compile the program alone, I get t4-t1
> > = 0 (time needed to read one chunk) most of the time, except around 10
> > times (over 2500), where I get 16666. I suppose this is simply time
> > sharing made by the kernel.
> > If I compile a shared lib containing this code, renaming my function
> > main_dada(), then dynamically load this lib with .L and execute this
> > function from the interpreter, I get around 50 times 16666 for t4-t1.
> > That seems to slow down the execution very much.
> > If I make an executable myroot.exe that is linked with this library,
> > then everything is normal and runs fast.
> > This seems to indicate that dynamically loading the shared lib does
> > something special on alpha's (OSF). Anyway, our big program runs fast
> > now that we link everything with a main executable.
> >
> > I don't see this behaviour on linux. It's always fast and I always get
> > a small number of interuptions from the kernel.
> >
> > I tried to do a small program using dlopen but I get a message "The
> > shared library loader cannot be activated for this process" and I don't
> > know what to do.
> >
> > Did anybody see this kind of behaviour on Alpha ? Does anyone has
> > suggestions on what to do apart from always binding the shared libs to a
> > main executable ? I would really like to load/unload shared libs.
> >
> > Damir
> > --
> > =====================================================================
> > | Damir Buskulic | Universite de Savoie/LAPP |
> > | | Chemin de Bellevue, B.P. 110 |
> > | Tel : +33 (0)450091600 | F-74941 Annecy-le-Vieux Cedex |
> > | e-mail: buskulic@lapp.in2p3.fr | FRANCE |
> > =====================================================================
> > mailto:buskulic@lapp.in2p3.fr
>
> --
> Org: CERN, European Laboratory for Particle Physics.
> Mail: 1211 Geneve 23, Switzerland
> E-Mail: Fons.Rademakers@cern.ch Phone: +41 22 7679248
> WWW: http://root.cern.ch/~rdm/ Fax: +41 22 7677910
--
=====================================================================
| Damir Buskulic | Universite de Savoie/LAPP |
| | Chemin de Bellevue, B.P. 110 |
| Tel : +33 (0)450091600 | F-74941 Annecy-le-Vieux Cedex |
| e-mail: buskulic@lapp.in2p3.fr | FRANCE |
=====================================================================
mailto:buskulic@lapp.in2p3.fr
This archive was generated by hypermail 2b29 : Tue Jan 04 2000 - 00:43:30 MET