better performance with 32 bit ! why?

Sven Eschenberg sven at whgl.uni-frankfurt.de
Wed Jun 29 21:28:43 UTC 2011


That is, if all of those threads have work to do, because the task can be
distributed accordingly. Which is not easy even if you know the number of
cores (threads for that matter) and the whole task is known a priori.

Unfortunately Queries to a DNS-Server like bind do not follow parameters
known a priori, so distributing the tasks (work) to threads with the goal
of equal load aswell as minimum response time is an online-scenario and
all but trivial. ;-)

Regards

-Sven

P.S.: If all parts of bind were optimized towards multicore processing and
the pattern of queries fits, yes, then the 8 core machine could probably
outrun the 4 core machine, even when having a slower clock. But this might
worsen the performance on single or dual core CPUs on the other hand.

On Wed, June 29, 2011 19:58, Lightner, Jeff wrote:
> I'm not sure I agree with that - multiple single threaded processes can
> be distributed across cores/CPUs.   That is to say ONE single thread
> process doesn't gain from multiple cores but more than one can because
> they don't have to compete against each other on the same core.
>
> -----Original Message-----
> From: bind-users-bounces+jlightner=water.com at lists.isc.org
> [mailto:bind-users-bounces+jlightner=water.com at lists.isc.org] On Behalf
> Of Ryan Novosielski
> Sent: Wednesday, June 29, 2011 9:59 AM
> To: iharrathi.ext at orange-ftgroup.com
> Cc: bind-users at lists.isc.org
> Subject: Re: better performance with 32 bit ! why?
>
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Not necessarily. They are not apples to apples. Multi-core machines only
> excel at multi-threaded computational loads. I don't know how BIND does
> or does not qualify. I suspect, however, there may be some other
> differences between the two chips anyhow (cache size differences, etc.).
>
> On 06/29/2011 09:33 AM, iharrathi.ext at orange-ftgroup.com wrote:
>> on server1(64 bit) i have 2 Intel E5310 *quad*-core 1.6Ghz and on
>> server2(32 bit) i have 2 Intel Xeon *dual*-core 2.33Ghz.
>> means 8*1.6 Ghz on server1 and 4*2.33 on server2.
>>
>> 8*1.6 is better and faster than 4*2.33, no?
>> //
>> /Regards /
>> /Issam Harrathi./
>>
>>
>>
>>>/ The 64 bit server(server1) is faster than the 32 bit server
> (server2).
>> /
>> Really? I thought you said the 64 bit server had a CPU with 1.6GHz
> cores,
>> and the 32 bit server had 2.33GHz cores?
>>
>> Regards
>> Eivind Olsen
>>
>>
> ************************************************************************
> ********
>> IMPORTANT.Les informations contenues dans ce message electronique y
> compris les fichiers attaches sont strictement confidentielles
>> et peuvent etre protegees par la loi.
>> Ce message electronique est destine exclusivement au(x)
> destinataire(s) mentionne(s) ci-dessus.
>> Si vous avez recu ce message par erreur ou s il ne vous est pas
> destine, veuillez immediatement le signaler  a l expediteur et effacer
> ce message
>> et tous les fichiers eventuellement attaches.
>> Toute lecture, exploitation ou transmission des informations contenues
> dans ce message est interdite.
>> Tout message electronique est susceptible d alteration.
>> A ce titre, le Groupe France Telecom decline toute responsabilite
> notamment s il a ete altere, deforme ou falsifie.
>> De meme, il appartient au destinataire de s assurer de l absence de
> tout virus.
>>
>> IMPORTANT.This e-mail message and any attachments are strictly
> confidential and may be protected by law. This message is
>> intended only for the named recipient(s) above.
>> If you have received this message in error, or are not the named
> recipient(s), please immediately notify the sender and delete this
> e-mail message.
>> Any unauthorized view, usage or disclosure ofthis message is
> prohibited.
>> Since e-mail messages may not be reliable, France Telecom Group shall
> not be liable for any message if modified, changed or falsified.
>> Additionally the recipient should ensure they are actually virus free.
>>
> ************************************************************************
> ********
>>
>>
>>
>> _______________________________________________
>> Please visit https://lists.isc.org/mailman/listinfo/bind-users to
> unsubscribe from this list
>>
>> bind-users mailing list
>> bind-users at lists.isc.org
>> https://lists.isc.org/mailman/listinfo/bind-users
>
>
> - --
> - ---- _  _ _  _ ___  _  _  _
> |Y#| |  | |\/| |  \ |\ |  | |Ryan Novosielski - Sr. Systems Programmer
> |$&| |__| |  | |__/ | \| _| |novosirj at umdnj.edu - 973/972.0922 (2-0922)
> \__/ Univ. of Med. and Dent.|IST/CST-Academic Svcs. - ADMC 450, Newark
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.10 (GNU/Linux)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
>
> iEYEARECAAYFAk4LL5gACgkQmb+gadEcsb7iMwCg08huQWUMJ/I2COhwc7mzN5ix
> 6mwAnifUFtFJi5fQb10Tpf1iaul9Nn7X
> =HbQB
> -----END PGP SIGNATURE-----
>
> Proud partner. Susan G. Komen for the Cure.
>
> Please consider our environment before printing this e-mail or
> attachments.
> ----------------------------------
> CONFIDENTIALITY NOTICE: This e-mail may contain privileged or confidential
> information and is for the sole use of the intended recipient(s). If you
> are not the intended recipient, any disclosure, copying, distribution, or
> use of the contents of this information is prohibited and may be unlawful.
> If you have received this electronic transmission in error, please reply
> immediately to the sender that you have received the message in error, and
> delete it. Thank you.
> ----------------------------------
> _______________________________________________
> Please visit https://lists.isc.org/mailman/listinfo/bind-users to
> unsubscribe from this list
>
> bind-users mailing list
> bind-users at lists.isc.org
> https://lists.isc.org/mailman/listinfo/bind-users
>





More information about the bind-users mailing list