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....@lists.isc.org > [mailto:bind-users-bounces+jlightner=water....@lists.isc.org] On Behalf > Of Ryan Novosielski > Sent: Wednesday, June 29, 2011 9:59 AM > To: iharrathi....@orange-ftgroup.com > Cc: bind-users@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....@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@lists.isc.org >> https://lists.isc.org/mailman/listinfo/bind-users > > > - -- > - ---- _ _ _ _ ___ _ _ _ > |Y#| | | |\/| | \ |\ | | |Ryan Novosielski - Sr. Systems Programmer > |$&| |__| | | |__/ | \| _| |novos...@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@lists.isc.org > https://lists.isc.org/mailman/listinfo/bind-users > _______________________________________________ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
