Re: EM64T compiling options?
Hi, I'm migrating from an i686 to an EM64T machine (Intel core 2 quad) and I'd like to know whether there are specific options that I can pass to gcc for an optimization of my code or if everything is blindly set up. How would I manage the 4 cpu cores if I was to write in assembly? GCC has a lot of optimization/architecture flags. Just have a look here [1]. However, this won't make your software use the 4 cores. You should use threads or multiple processes with IPC. I don't know what you want to do but I think you should forget about writing in assembly and use an higher level language. You probably don't need assembly at all. Moreover, higher level language have sometimes concurrency and synchronization facilities which will help you getting the most of your 4 cores. Regards, Cyril Jaquier [1] http://gcc.gnu.org/onlinedocs/gcc/i386-and-x86_002d64-Options.html -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: EM64T compiling options?
Many thanks, I'll read your link with attention. Do you have further links on threads and IPC ? I'm thinking in rewriting an old and unfinished logical interpreter in C that used assembly code (nasm) for truth evaluation of the smallest elements. I'd like also to create a small database for prime numbers (using John Moyer's storage code) in order to test several things on prime numbers distribution. A+ Emmanuel On Tue, 15 Jul 2008 12:56:18 +0200, Cyril Jaquier [EMAIL PROTECTED] said: Hi, I'm migrating from an i686 to an EM64T machine (Intel core 2 quad) and I'd like to know whether there are specific options that I can pass to gcc for an optimization of my code or if everything is blindly set up. How would I manage the 4 cpu cores if I was to write in assembly? GCC has a lot of optimization/architecture flags. Just have a look here [1]. However, this won't make your software use the 4 cores. You should use threads or multiple processes with IPC. I don't know what you want to do but I think you should forget about writing in assembly and use an higher level language. You probably don't need assembly at all. Moreover, higher level language have sometimes concurrency and synchronization facilities which will help you getting the most of your 4 cores. Regards, Cyril Jaquier [1] http://gcc.gnu.org/onlinedocs/gcc/i386-and-x86_002d64-Options.html -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: EM64T compiling options?
On Tue, Jul 15, 2008 at 11:37:52AM +0200, [EMAIL PROTECTED] wrote: I'm migrating from an i686 to an EM64T machine (Intel core 2 quad) and I'd like to know whether there are specific options that I can pass to gcc for an optimization of my code or if everything is blindly set up. How would I manage the 4 cpu cores if I was to write in assembly? You almost certainly wouldn't. Very few people have any reason to write in assembly anymore. You might write a critical section of code in assembly, but all the glue ought to be in C, inluding anything to manage pthreads to do multiple threads, which is how you take advantage of multiple cores. As for optimizing, there really aren't any options yet since there are very few amd64 designs so far and they all have the same instruction set and features pretty much and hence the code should be pretty much optimal for all of them (in as much as gcc produces optimal code for anything). -- Len Sorensen -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: EM64T compiling options?
The Tuesday 15 July 2008 14:39:41 Lennart Sorensen, You wrote : You almost certainly wouldn't. Very few people have any reason to write in assembly anymore. You might write a critical section of code in assembly, but all the glue ought to be in C, inluding anything to manage pthreads to do multiple threads, which is how you take advantage of multiple cores. You also can take a look at openmp which allow you to parallelize for loops and make easy synchronization. The support of openmp is included in latests gcc versions. -- Len Sorensen -- Thomas Preud'homme Why debian : http://www.debian.org/intro/why_debian -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: EM64T compiling options?
The loop sharing looks exciting but openmp seems difficult to use too. Does openmp replace pthreads or work in combination ? Emmanuel On Tue, 15 Jul 2008 14:55:24 +0200, Thomas Preud'homme [EMAIL PROTECTED] said: The Tuesday 15 July 2008 14:39:41 Lennart Sorensen, You wrote : You almost certainly wouldn't. Very few people have any reason to write in assembly anymore. You might write a critical section of code in assembly, but all the glue ought to be in C, inluding anything to manage pthreads to do multiple threads, which is how you take advantage of multiple cores. You also can take a look at openmp which allow you to parallelize for loops and make easy synchronization. The support of openmp is included in latests gcc versions. -- Len Sorensen -- Thomas Preud'homme Why debian : http://www.debian.org/intro/why_debian -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: EM64T compiling options?
The Tuesday 15 July 2008 15:46:06 E. Rens, you wrote : The loop sharing looks exciting but openmp seems difficult to use too. Does openmp replace pthreads or work in combination ? AFAIK it use pthread to work but it create all necessary pthread at startup to avoid creating them at each loop parallelization. It should work properly with pthreads, it wouldn't be packaged with gcc if it wasn't the case. However I didn't test this combination. openmp is really simple to use, easier than programming the same thing with pthreads. You can see examples on wikipedia : http://en.wikipedia.org/wiki/OpenMP The purpose is to do simple parallelization. If you want to write an algorithm which needs modification to support multi-cores, you have to do it yourself with pthreads. Regards Emmanuel -- Thomas Preud'homme Why debian : http://www.debian.org/intro/why_debian -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: EM64T compiling options?
There is an environment variable GOMP_AFFINITY in libgomp that binds threads to single cpus. Can I use it the same way with multi-cores (i.e GOMP_CPU_AFFINITY=0 1 2 3 in order to bind thread 1 to core 0 etc..)? Is this a good way to take advantage of the quad architecture? Emmanuel On Tue, 15 Jul 2008 16:24:49 +0200, Thomas Preud'homme [EMAIL PROTECTED] said: The Tuesday 15 July 2008 15:46:06 E. Rens, you wrote : The loop sharing looks exciting but openmp seems difficult to use too. Does openmp replace pthreads or work in combination ? AFAIK it use pthread to work but it create all necessary pthread at startup to avoid creating them at each loop parallelization. It should work properly with pthreads, it wouldn't be packaged with gcc if it wasn't the case. However I didn't test this combination. openmp is really simple to use, easier than programming the same thing with pthreads. You can see examples on wikipedia : http://en.wikipedia.org/wiki/OpenMP The purpose is to do simple parallelization. If you want to write an algorithm which needs modification to support multi-cores, you have to do it yourself with pthreads. Regards Emmanuel -- Thomas Preud'homme Why debian : http://www.debian.org/intro/why_debian -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: em64t
Lennart Sorensen wrote: I thought IA-32e was something entirely different (I thought that was PAE and such). No, its the term used for the EM64T extensions in most of their technical documentation (e.g., the SDM for IA-32 processors). Why, I don't know. They just like to be difficult. Intel's logic in terminology selection still eludes me. Thanks, Adam -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: em64t
On Sat, Oct 07, 2006 at 09:15:44AM -0500, Gnu_Raiz wrote: It's now Intel 64, if that wasn't confusing enough. http://www.theinquirer.net/default.aspx?article=34722 So intel went from IA-32e to EM64T to Intel 64! I guess you know why upstream left it amd64. I guess they suffer from the not invented here syndrome. For all those people who need to be special, you can always append-to-version when you compile your own kernel. But still it freaks out those who are not knowledgeable to see a Woodcrest, or Conroe running something saying amd64. You just got to love the irony in that. Does this mean intel wants their users even more confused by having Intel Architecture 64 and Intel 64 being two different incompatible things? We already had people asking if ia64 for was em64t systems. What a mess. I thought IA-32e was something entirely different (I thought that was PAE and such). -- Len Sorensen -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: em64t
On 10/8/06, Lennart Sorensen [EMAIL PROTECTED] wrote: On Sat, Oct 07, 2006 at 09:15:44AM -0500, Gnu_Raiz wrote: It's now Intel 64, if that wasn't confusing enough. http://www.theinquirer.net/default.aspx?article=34722 So intel went from IA-32e to EM64T to Intel 64! I guess you know why upstream left it amd64. I guess they suffer from the not invented here syndrome. For all those people who need to be special, you can always append-to-version when you compile your own kernel. But still it freaks out those who are not knowledgeable to see a Woodcrest, or Conroe running something saying amd64. You just got to love the irony in that. Does this mean intel wants their users even more confused by having Intel Architecture 64 and Intel 64 being two different incompatible things? We already had people asking if ia64 for was em64t systems. What a mess. I thought IA-32e was something entirely different (I thought that was PAE and such). Yes, but their marketing scheme is such that the majority of people that are going to purchase a new CPU will never have to know the difference. They'll just know that they're the best processors around... just like the ads say. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: em64t
On Friday 06 October 2006 16:07, Lennart Sorensen wrote: On Fri, Oct 06, 2006 at 01:34:47PM -0700, Enrique Morfin wrote: I'm using etch with kernel 2.6.15-1-em64t-p4-smp. I want to upgrade the kernel, but the images are: linux-image-2.6.17-2-amd64 is no smp? or using smp-alternatives? What about em64t? Thanks. As of 2.6.17-9 amd64 only has one flavour, and always supports smp as far as I understand it. Changelog entry: * [amd64] Add smp-alternatives backport. * [amd64] Drop smp flavours. * [amd64] Merge k8 and p4 flavours into a generic one, following upstreams advice. -- Len Sorensen It's now Intel 64, if that wasn't confusing enough. http://www.theinquirer.net/default.aspx?article=34722 So intel went from IA-32e to EM64T to Intel 64! I guess you know why upstream left it amd64. I guess they suffer from the not invented here syndrome. For all those people who need to be special, you can always append-to-version when you compile your own kernel. But still it freaks out those who are not knowledgeable to see a Woodcrest, or Conroe running something saying amd64. You just got to love the irony in that. Gnu_Raiz -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: em64t
On Fri, Oct 06, 2006 at 01:34:47PM -0700, Enrique Morfin wrote: I'm using etch with kernel 2.6.15-1-em64t-p4-smp. I want to upgrade the kernel, but the images are: linux-image-2.6.17-2-amd64 is no smp? or using smp-alternatives? What about em64t? Thanks. As of 2.6.17-9 amd64 only has one flavour, and always supports smp as far as I understand it. Changelog entry: * [amd64] Add smp-alternatives backport. * [amd64] Drop smp flavours. * [amd64] Merge k8 and p4 flavours into a generic one, following upstreams advice. -- Len Sorensen -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: EM64T Machine available for porting
On Tue, Mar 15, 2005 at 09:58:18PM +, Martin Michlmayr wrote: It would be nice if someone could re-build the whole archive since this would give the box some good stress testing. I'm not sure why you're asking this? Is it because it's an Intel? Do you think it's going to behave differently than an AMD chip? Kurt -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: EM64T Machine available for porting
* Kurt Roeckx [EMAIL PROTECTED] [2005-03-15 23:09]: It would be nice if someone could re-build the whole archive since this would give the box some good stress testing. I'm not sure why you're asking this? Is it because it's an Intel? Yes. Do you think it's going to behave differently than an AMD chip? No, but building the archive would give us more evidence. Also, it stress tests the hardware and kernel and I assume (w/o checking) that there are some differences in the kernel support for Intel and AMD x86_64 chips. I know most of the AMD64 work has already been done on AMD hardware, and I'm grateful for that work. But I obtained this EM64T box for Debian so we can *test* whether Debian works rather than just assume it will. -- Martin Michlmayr http://www.cyrius.com/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: EM64T Machine available for porting
On Tue, Mar 15, 2005 at 10:15:50PM +, Martin Michlmayr wrote: I know most of the AMD64 work has already been done on AMD hardware, and I'm grateful for that work. But I obtained this EM64T box for Debian so we can *test* whether Debian works rather than just assume it will. We got various reports that it worked, but it sure couldn't hurt to give it a good test. :) Kurt -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
RE: EM64T Machine available for porting
I hope it works! I have 8 1850's (2.8 GHz EM64T's) running unstable at the moment (with the test SMP kernel), and have another 34 on order! Adrian Wolfson Brain Imaging Centre University of Cambridge -Original Message- From: Kurt Roeckx [mailto:[EMAIL PROTECTED] Sent: 15 March 2005 22:25 To: Martin Michlmayr Cc: debian-amd64@lists.debian.org Subject: Re: EM64T Machine available for porting On Tue, Mar 15, 2005 at 10:15:50PM +, Martin Michlmayr wrote: I know most of the AMD64 work has already been done on AMD hardware, and I'm grateful for that work. But I obtained this EM64T box for Debian so we can *test* whether Debian works rather than just assume it will. We got various reports that it worked, but it sure couldn't hurt to give it a good test. :) Kurt -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: EM64T Machine available for porting
Kurt Roeckx wrote: On Tue, Mar 15, 2005 at 10:15:50PM +, Martin Michlmayr wrote: I know most of the AMD64 work has already been done on AMD hardware, and I'm grateful for that work. But I obtained this EM64T box for Debian so we can *test* whether Debian works rather than just assume it will. We got various reports that it worked, but it sure couldn't hurt to give it a good test. :) I think it would be great to have a pure64 AMD64 machine rebuild its own packages, reinstall them, then rebuild the whole archive. In parallel, have an EM64T machine do exactly the same thing - also for the current state of the source repository. Then see whether there are any packages where one of them fails and the other succeeds ... Hmm ... 8-) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: EM64T Machine available for porting
On Tue, Mar 15, 2005 at 02:33:29PM -0800, Alex Perry wrote: I think it would be great to have a pure64 AMD64 machine rebuild its own packages, reinstall them, then rebuild the whole archive. In parallel, have an EM64T machine do exactly the same thing - also for the current state of the source repository. One problem with that is that alot of new sources become available. Even for testing. You would have to take a snapshot of all sources and binaries to do that. Kurt -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: EM64T Machine available for porting
That's true. Kurt Roeckx wrote: On Tue, Mar 15, 2005 at 02:33:29PM -0800, Alex Perry wrote: I think it would be great to have a pure64 AMD64 machine rebuild its own packages, reinstall them, then rebuild the whole archive. In parallel, have an EM64T machine do exactly the same thing - also for the current state of the source repository. One problem with that is that alot of new sources become available. Even for testing. You would have to take a snapshot of all sources and binaries to do that. Kurt -- Alexander R Perry GE Infrastructure, Security Center of Excellence for Magnetics Group Leader, Advanced Systems T: 858 605 5514 F: 858 605 5501 D: *722-1404 E: [EMAIL PROTECTED] W: http://www.gesecurity.com/ 15175 Innovation Drive San Diego, CA, 92128, USA Quantum Magnetics, Inc -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: EM64T Machine available for porting
Alex Perry schrieb: That's true. Kurt Roeckx wrote: On Tue, Mar 15, 2005 at 02:33:29PM -0800, Alex Perry wrote: I think it would be great to have a pure64 AMD64 machine rebuild its own packages, reinstall them, then rebuild the whole archive. In parallel, have an EM64T machine do exactly the same thing - also for the current state of the source repository. One problem with that is that alot of new sources become available. Even for testing. You would have to take a snapshot of all sources and binaries to do that. Kurt Shouldn't be a problem with a local mirror for the 2 boxes just stopy the sync process for the time needed. I would do it myself but I don't have a unused EM64T box in pyiscal range right now :-( greets Uwe -- Jetzt will man das Internet nicht einfach ein paar Leuten wie der IETF überlassen, die wissen, was sie tun. Es ist zu wichtig geworden. - Scott Bradner http://www.highspeed-firewall.de/adamantix/ http://www.x-tec.de
