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
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
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
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
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
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
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
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.
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
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
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
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
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
* 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
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
: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
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
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
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
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
20 matches
Mail list logo
