Wine support Intel quad-core cpu? Thank you.
On Wed, May 14, 2008 at 1:15 PM, psychok9 <wineforum-user at winehq.org> wrote:> Wine support Intel quad-core cpu? > Thank you. >Yes wine supports whatever amount of cpu cores you have. John
John Drescher wrote:> On Wed, May 14, 2008 at 1:15 PM, psychok9 <wineforum-user at winehq.org> wrote: > >> Wine support Intel quad-core cpu? >> Thank you. >> >> > > Yes wine supports whatever amount of cpu cores you have. > > John > >It only uses on core at a time. There is an issue referencing this. James McKenzie
James McKenzie wrote:> It only uses on core at a time. There is an issue referencing this.Wrong. [Exclamation] Wine uses everythin available to the system. If your system sees all those 4 cores, then Wine will happily use all those 4 cores.
James McKenzie wrote:> Is Wine cleanly multi-threaded?Well yes it uses posix threads when they are available (most platforms now days). The only two bottlenecks I can think of - wineserver and x11lock. Wineserver is single-threaded. And x11lock - used to limit all communications with X11 server to one thread at a time.
vitamin wrote:> James McKenzie wrote: > >> Is Wine cleanly multi-threaded? >> > > Well yes it uses posix threads when they are available (most platforms now days). > >Thank you for clearing this up. As I stated I have two cores and maybe MacOSX is not POSIX thread compliant.> The only two bottlenecks I can think of - wineserver and x11lock. Wineserver is single-threaded. And x11lock - used to limit all communications with X11 server to one thread at a time. >Maybe that is where I got the one-thread for Wine from. This old dog is never too old to learn new tricks. James McKenzie
Has wine bothered messing with CPU affinity? For instance, binding all other wine processes and threads to other cores, cores that the GUI/OpenGL/D3D is not running on?
On Saturday 17 May 2008 03:58:01 pm ulberon wrote:> Has wine bothered messing with CPU affinity? For instance, binding all > other wine processes and threads to other cores, cores that the > GUI/OpenGL/D3D is not running on?Am I wrong in thinking that the Linux scheduler is smart enough to not assign additional work to a core grinding on something heavy? If not, what benefit would second-guessing the scheduler bring? -- Paul Johnson baloo at ursine.ca Explaination of .pgp part: http://linuxmafia.com/faq/Mail/rant-gpg.html -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part. Url : http://www.winehq.org/pipermail/wine-users/attachments/20080517/a062d4cf/attachment.pgp
Just based on some limited testing, yes, you are incorrect in thinking that the Linux Scheduler is smart enough not to assign additional work. It passes the process around the cores like a party favor. I was just curious if anyone pursued it, there are performance benefits to binding a process to a specific core (in the general case), increased cache hits being one. To cut to the chase, I think there would be performance benefits to binding the opengl/d3d process to a core, and binding the other processes to the remaining cores.