Good point. How do I check this? `uname -a` only reports machine
architecture. There's nothing in the kernel that suggests it's a 64-bit
OS. A `dmesg | grep 64` doesn't display anything related to the OS
installed. I know for sure it's RHEL3 with SMP but how do I tell if it's
the 64-bit version? My college who installed it is on leave for a weeks
and none of the other developers have an idea.
With regards to Benno's code:
After trying raw mallocs and performing quite well, I think it might
have to do with the code. I have different versions of my software,
hashed linked lists, hashed binary trees, etc. With 87 million mallocs I
expect binary trees of a hash table with size 100,001 to have a 800
entries each. Testing the same code with 1 million mallocs with a hash
table of 1,001 still gives me good results (that's an average of about
1000 per tree) at less than 5 minutes. I tried to insert 87 million to a
hash of 100,001 yesterday at 4pm and it wasn't finished at 9am today. I
think that's just way too slow. By the way i just use a simple for loop
and % hash size so all trees should have the same depth.
87 million / 100,001 = 869 (4pm-9am still not complete)
1 million / 1,001 = 999 (by 5 mins)
I would attach my source but it contains proprietary code :/
Thanks in advance.
Carlo
Erik de Castro Lopo wrote:
Jamie Wilkinson wrote:
I hate to say it, but I think Oscar pinned the tail on the donkey with the
link to high memory on 32 bit x86.
Carlo has since stated that he is running on 64 bit CPUs. He
hasn't yet stated whether his kernel and app are compiled as
64.
If both his kernal and app are 64 bit then this has nothing to
do with 32 bit x86 :-).
Erik
_______________________________________________
coders mailing list
[email protected]
http://lists.slug.org.au/listinfo/coders
