Giorgos Keramidas wrote:
> On 2002-03-07 16:45, Simon 'corecode' Schubert wrote:
> > to everybody who doesn't believe that: it really generates bad code.
> > i've been having severe problems with my tcp and udp stack lately (on a
> > i586/mmx machine). guess what, -O2 resulted in code which >>some
On 2002-03-07 16:45, Simon 'corecode' Schubert wrote:
> to everybody who doesn't believe that: it really generates bad code.
> i've been having severe problems with my tcp and udp stack lately (on a
> i586/mmx machine). guess what, -O2 resulted in code which >>sometimes<<
> generated bad tcp and/
On Fri, 8 Mar 2002, David Xu wrote:
> Unfortunately, I havn't Linux kernel 2.4.17 installed, is Linux kernel 2.4.17
>faster?
> --
> David Xu
Well, the VM in it is certainly different. Since he's using SUSE 2.4.17,
I believe that would mean that he's actually using 2.4.17-AA; you'd want
to tr
David Xu wrote:
> I have done some tests on my machine, the machine has both
> Linux and FreeBSD installed, the following is the data:
>
> MALLOC_SIZE = 1024*1024*400
> has bzero
>
> Red Linux 6.2(kernel 2.2.14)
> 5.09u 5.62s 1:15.33 14%
> 4.70u 5.73s 1:17.13 13%
> 4.88u 5.68s 1:17
I have done some tests on my machine, the machine has both Linux and FreeBSD
installed,
the following is the data:
MALLOC_SIZE = 1024*1024*400
has bzero
Red Linux 6.2(kernel 2.2.14)
5.09user 5.62system 1:15.33elapsed 14%CPU (0avgtext+0avgdata 0maxresident)k
0inputs+0outputs (115298majo
On Thu, 7 Mar 2002 11:12:03 -0800 (PST)
Matthew Dillon <[EMAIL PROTECTED]> wrote:
> Hmm. well, I don't think this test is very meaningful. If the
> machines have 256M of ram and the test is doing a two-swipe access of
> 256M of VM. This doesn't represent any real test and I would no
On Thu, 07 Mar 2002 11:19:25 -0800
Terry Lambert <[EMAIL PROTECTED]> wrote:
> > #include
> > #include
> > #include
> >
> > #define MALLOC_SIZE 1024*1024*256
> >
> > int main(int argc, char **argv) {
> >char *ptr;
> >int i, i_count;
> >int j;
> >
> >ptr = (char *) malloc(MALL
On Thu, 7 Mar 2002 10:42:05 -0800
"David O'Brien" <[EMAIL PROTECTED]> wrote:
> On Thu, Mar 07, 2002 at 08:09:06AM -0600, GB Clark wrote:
> > > I've tested it with :
> > >
> > > cc -O6 -o malloc_test malloc_test.c
> >
> > That -O6 does not look right from here. Do we support anything over
> > -
On Thu, 7 Mar 2002 11:41:28 + (GMT)
Mike Silbersack <[EMAIL PROTECTED]> wrote:
>
> On Thu, 7 Mar 2002, cjp wrote:
>
> > In order to handle the kruft that occurs, there is the out of memory
> > killer, oom_killer.
> > Which merrily goes through the list of processes, killing off the low
> >
>Another point that I should bring up in regards to swap performance:
>systems that require good swap performance will almost always have
>more then one physical disk to swap to. FreeBSD is very good at
>paging to swap with a single disk, but it kicks ass paging to swap
>with
Matthew Dillon wrote:
> :The bzero is unnecessary on FreeBSD. Allocated pages start out
> :zero'ed. Part of the performance issue might be that FreeBSD is
> :being asked to zero the pages twice, instead of once.
>
> malloc() does not guarentee a zero'd page, even though the
> side effec
:>ptr = (char *) malloc(MALLOC_SIZE);
:>bzero(ptr, MALLOC_SIZE);
:
:The bzero is unnecessary on FreeBSD. Allocated pages start out
:zero'ed. Part of the performance issue might be that FreeBSD is
:being asked to zero the pages twice, instead of once.
malloc() does not guarentee a z
> #include
> #include
> #include
>
> #define MALLOC_SIZE 1024*1024*256
>
> int main(int argc, char **argv) {
>char *ptr;
>int i, i_count;
>int j;
>
>ptr = (char *) malloc(MALLOC_SIZE);
>bzero(ptr, MALLOC_SIZE);
The bzero is unnecessary on FreeBSD. Allocated pages start
Hmm. well, I don't think this test is very meaningful. If the machines
have 256M of ram and the test is doing a two-swipe access of 256M of VM.
This doesn't represent any real test and I would not be surprised by
the difference in timing.
It all comes down to how much real
:...
:> > This is a comparison of how fast Linux can do something
:> > STUPID versus how fast a real OS can do something intelligently. Your
:> > test is giving you misleading, and dangerous numbers. Do not go waving
:> > them around until you have actually looked at mallocs behavior on the
:>
On Thu, Mar 07, 2002 at 11:41:28AM +, Mike Silbersack wrote:
> In any case, we can't make any useful comparisons until Dimitar posts the
> source to his test program.
>
> Dimitar, post the source for the test program!
Does your MTA strip attachments?
-> I 1 [text/plain
Simon 'corecode' Schubert wrote:
> to everybody who doesn't believe that: it really generates bad code.
> i've been having severe problems with my tcp and udp stack lately (on a
> i586/mmx machine). guess what, -O2 resulted in code which >>sometimes<<
> generated bad tcp and/or udp checksums (depe
On Thu, Mar 07, 2002 at 08:09:06AM -0600, GB Clark wrote:
> > I've tested it with :
> >
> > cc -O6 -o malloc_test malloc_test.c
>
> That -O6 does not look right from here. Do we support anything over -O2?
>
> And how about some source for malloc_test.c? The fact of running
> something at -O6
On Thu, 7 Mar 2002, Rogier R. Mulhuijzen wrote:
>
> >Once Dimitar posts his test program, we'll be able to generate a more
> >clear picture about what's really happening. Until then, please control
> >the ranting.
>
> Am I the only one who saw that he attached it to his 1st mail?
Apparently no
>Once Dimitar posts his test program, we'll be able to generate a more
>clear picture about what's really happening. Until then, please control
>the ranting.
Am I the only one who saw that he attached it to his 1st mail?
Here you go:
#include
#include
#include
#define MALLOC_SIZE 1024*102
On Thu, 7 Mar 2002, Tom wrote:
> But when you lose that data, do you not get burnt by that same situation?
> I have written a 1GB file to a linux box, and then within 5 seconds of it
> finishing, yanked the power cord. When I booted it back up, the file was
> *JUST NOT THERE*, I tried it a few o
> > This is a comparison of how fast Linux can do something
> > STUPID versus how fast a real OS can do something intelligently. Your
> > test is giving you misleading, and dangerous numbers. Do not go waving
> > them around until you have actually looked at mallocs behavior on the
> > different
On Thu, 7 Mar 2002, cjp wrote:
> In order to handle the kruft that occurs, there is the out of memory killer,
> oom_killer.
> Which merrily goes through the list of processes, killing off the low priority
> processes
> until enough memory is free to satisfy what was most recently used. It's the
On Thu, 7 Mar 2002 16:36:15 +0100 Erik Trulsson <[EMAIL PROTECTED]> wrote:
> > > > I've tested it with :
> > > >
> > > > cc -O6 -o malloc_test malloc_test.c
> > >
> > > That -O6 does not look right from here. Do we support anything over -O2?
> >
> > ISTR that -On is exactly the same for -O2 f
On Thu, Mar 07, 2002 at 04:47:24PM +0200, Peter Pentchev wrote:
> On Thu, Mar 07, 2002 at 08:09:06AM -0600, GB Clark wrote:
> > On Thu, 7 Mar 2002 14:27:59 +0200
> > Dimitar Peikov <[EMAIL PROTECTED]> wrote:
> >
> > > On Thu, 7 Mar 2002 04:01:58 -0800 (PST)
> > > Julian Elischer <[EMAIL PROTECTED
On Thu, Mar 07, 2002 at 09:42:44AM -0500, cjp wrote:
> This is a comparison of how fast Linux can do something
> STUPID versus how fast a real OS can do something intelligently. Your
> test is giving you misleading, and dangerous numbers. Do not go waving them
> around until you have actually lo
On Thu, 7 Mar 2002 09:42:44 -0500
"cjp" <[EMAIL PROTECTED]> wrote:
> This is a comparison of how fast Linux can do something
> STUPID versus how fast a real OS can do something intelligently. Your
> test is giving you misleading, and dangerous numbers. Do not go waving
> them around until you h
On Thu, 7 Mar 2002, cjp wrote:
You are probably misinformed, because FreeBSD also does overcommit of
memory. If you look up the mail archives you will find long battles about
the pros and cons of this.
harti
c>This is a comparison of how fast Linux can do something
c>STUPID versus how fast a re
This is a comparison of how fast Linux can do something
STUPID versus how fast a real OS can do something intelligently. Your
test is giving you misleading, and dangerous numbers. Do not go waving them
around until you have actually looked at mallocs behavior on the different
systems.
Here's wh
On Thu, 7 Mar 2002 08:09:06 -0600
GB Clark <[EMAIL PROTECTED]> wrote:
> On Thu, 7 Mar 2002 14:27:59 +0200
> Dimitar Peikov <[EMAIL PROTECTED]> wrote:
>
> > On Thu, 7 Mar 2002 04:01:58 -0800 (PST)
> > Julian Elischer <[EMAIL PROTECTED]> wrote:
> >
> > > he said -stable..
> > >
> > > what are th
On Thu, Mar 07, 2002 at 08:09:06AM -0600, GB Clark wrote:
> On Thu, 7 Mar 2002 14:27:59 +0200
> Dimitar Peikov <[EMAIL PROTECTED]> wrote:
>
> > On Thu, 7 Mar 2002 04:01:58 -0800 (PST)
> > Julian Elischer <[EMAIL PROTECTED]> wrote:
> >
> > > he said -stable..
> > >
> > > what are the malloc opti
On Thu, 7 Mar 2002 14:27:59 +0200
Dimitar Peikov <[EMAIL PROTECTED]> wrote:
> On Thu, 7 Mar 2002 04:01:58 -0800 (PST)
> Julian Elischer <[EMAIL PROTECTED]> wrote:
>
> > he said -stable..
> >
> > what are the malloc options on -stable?
> >
> > maybe we should make sure that they are null
> >
On Thu, 7 Mar 2002 04:01:58 -0800 (PST)
Julian Elischer <[EMAIL PROTECTED]> wrote:
> he said -stable..
>
> what are the malloc options on -stable?
>
> maybe we should make sure that they are null
>
> ln -s ">" /etc/malloc.conf
> (I hope that helps) :)
>
I've tested it with :
cc -O6 -o mall
he said -stable..
what are the malloc options on -stable?
maybe we should make sure that they are null
ln -s ">" /etc/malloc.conf
(I hope that helps) :)
On Thu, 7 Mar 2002, Alfred Perlstein wrote:
> * Dimitar Peikov <[EMAIL PROTECTED]> [020307 00:45] wrote:
> > I start some performance test
* Dimitar Peikov <[EMAIL PROTECTED]> [020307 00:45] wrote:
> I start some performance tests on -stable and on SuSE 7.1 / 2.4.17. I
> don't comment about 'bzero' performance, but when RAM is over, Linux
> is much faster. I have no idea what is the algorithm of swapping but it seems that
>the granu
On Thu, 7 Mar 2002, Dimitar Peikov wrote:
> I start some performance tests on -stable and on SuSE 7.1 / 2.4.17. I
> don't comment about 'bzero' performance, but when RAM is over, Linux
> is much faster. I have no idea what is the algorithm of swapping but it seems that
>the granularity of swapp
* Dimitar Peikov <[EMAIL PROTECTED]> [020307 00:45] wrote:
> I start some performance tests on -stable and on SuSE 7.1 / 2.4.17. I
> don't comment about 'bzero' performance, but when RAM is over, Linux
> is much faster. I have no idea what is the algorithm of swapping but it seems that
>the granu
37 matches
Mail list logo
