Have you tried Solaris or FreeBSD? You can obtain a developers
CD of Solaris for only $16 USD, and it installs easier than NT
(IMHO) I do believe that it comes with a compiler, other than
gcc, and it also handles SMP and threads better than NT. I have
never tried FreeBSD.
>
> Dammit! I just ordered the MB + CPUs ... My coding environment
> will be in linux but i guess i can run the executable on NT.
> I've
> heard that NT works well for 2-processor systems (but it does
> not
> scale well over two on the other hand).
>
> one statement and six questions for you:
>
> 1. on NT, multiple threads tend to *slow* performance when
> a lot of memory allocation takes place. so much so, that
> i've seen at least one add selling a special malloc lib
> for multi-threaded systems. i'm picking up a lot of frus-
> tration from your reply but apparently i NT sucks less
> than linux under these loads...
<noflame>
NT does do somethings better than Linux and Linux does do
somethings better than NT that is just the way it is. Every OS
has its perks and quirks. I have worked with NT and have noticed
that it's memory management is very different from 95, so be
ware. In 95 someone I worked with allocated memory, and then
freeded it. and then allocated some more. This new mem was
pointint to the old mem location, and had the same info. when we
accessed that info it was all there and hte program did not
crash. In NT this same process caused the program to crash,
same code same program, both compiled under NT and 95 and had
the same results. Apparantly when we reallocated the menory, we
did not get the same memory location or NT had cleared it for us
and the data that we referenced was not there anymore. It was a
case of bad code, worked under 95, but did not under NT.
</noflame>
> 2. do you know why GCC malloc/free is slow? can a person link
> against
> a another, better library? (eg. ala "debug malloc" style).
try libefence? (electric fence) it is a debugging lib for
malloc, but not sure if it is faster, or what you need.
> 3. is GCC merely exagerating an underlying O/S problem or is
> GCC malloc/free *the* problem?
I have heard that there are memory management problems in linux
2.2 but not sure the extent..
> 4. Who has had better SMP experience with respect
> memory management? on HPUX? solaris?
HP who? sorry, but I find that less and less people are using
HPUX. yes people who already have it are using it, but more
people when they buy a new system seem to be going with AIX or
Solaris (this has been my experience, but yours may differ)
> 5. How did you deal with swap with your book size memory job?
> 6. Does linux support the concept of swap zones ala NeXT?
> 7. In my code, I have many smallish objects. Memory pools made
> a huge difference. I wonder if these could help you out.
>
> Thanks-
> Shane
>
> >
> > don't do that in linux.
> > gcc library sucks bigtime.
> > can crash after some hours.
> >
> > It does for my prog which is using bigtime alloc/deallocate
> > when reading a book (about a gigabyte), which is like
> > reading in a buffer then merging. during merging all kind of
>
> > things need to be allocated and after merge deallocated.
> >
> > Under NT no problem.
> > Under 95 ==> 3 times slower than NT
> > under 98 ==> crash , big bugs in caching in 98
> > under linux ==> slow slow slow ==> crash after 12 hours.
> >
> > Greetings,
> > Vincent
> >
> > At 08:13 AM 8/10/99 -0700, you wrote:
> > >Sir;
> > >
> > >i am beginning development of a CAD like program. it will
> be
> > >threaded and multi-processor capable (well thanks to SMP
> O/S
> > >like linux).
> > >
> > >as to the linux's memory management, suppose a program has
> > >30 threads. each thread is allocating and deallocating
> memory.
> > >
> > >does linux block the other 29 threads when thread <X> wants
> > >to malloc/free? how about other threads/processes in the
> process
> > >table?
> > >
> > >in a regular, single-processor system, my original C++
> program
> > >spent 50% of its time in malloc/free. i reduced this time
> very
> > >significantly by implementing memory pools. the basic
> algorithm is fairly
> > >easy to split up across threads. hence linux SMP for more
> performance.
> > >but i am wondering if i might be walking into a "technical
> snare"
> > >with respect to linux and memory management.
> > >
> > >best regards,
> > >Shane
> > >-
> > >Linux SMP list: FIRST see FAQ at
> http://www.irisa.fr/prive/mentre/smp-faq/
> > >To Unsubscribe: send "unsubscribe linux-smp" to
> [EMAIL PROTECTED]
> > >
> > >
> >
>
> -
> Linux SMP list: FIRST see FAQ at
> http://www.irisa.fr/prive/mentre/smp-faq/
> To Unsubscribe: send "unsubscribe linux-smp" to
> [EMAIL PROTECTED]
>
>
_________________________________________________________
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com
-
Linux SMP list: FIRST see FAQ at http://www.irisa.fr/prive/mentre/smp-faq/
To Unsubscribe: send "unsubscribe linux-smp" to [EMAIL PROTECTED]
