Sorry, I just saw that I only answered Jakub and Tobias directly instead of
CCing the List,
so I will just forward my answer to Tobias to avoid wasting anyones time.
Original Message
Subject: Re: GOMP: OMP 5.1: simd construct for non-pointer random access
iterators
Date
Hi,
On 15.12.22 21:31, Grosse-Bley, Paul Leonard wrote:
I just ran into the issue that `#pragma omp simd` does not work on C++ iterator
loops (godbolt).
From going through the specifications I understand that this restriction was
part of 4.5 and 5.0, but was dropped with 5.1.
I assume that i
On Thu, Dec 15, 2022 at 09:31:50PM +0100, Grosse-Bley, Paul Leonard wrote:
>
> Hi together,
>
> I just ran into the issue that `#pragma omp simd` does not work on C++
> iterator loops (godbolt).
> >From going through the specifications I understand that this restriction was
> >part of 4.5 and 5
Hi together,
I just ran into the issue that `#pragma omp simd` does not work on C++ iterator
loops (godbolt).
>From going through the specifications I understand that this restriction was
>part of 4.5 and 5.0, but was dropped with 5.1.
As I couldn't find this change in the table of 5.1 (or 5.2
On Sun, Jun 26, 2022 at 05:49:41AM +0200, Mohamed Atef via Gcc wrote:
> What is the difference between functions with GOMP prefixes and the other
> with gomp?
GOMP_ prefix is used on exported libgomp APIs used by code emitted by the
compiler for OpenMP programs, various OpenMP pragmas tha
What is the difference between functions with GOMP prefixes and the other
with gomp?
Mohamed
out auto, WS etc..)
> > could make the cut for a GSoC 2019 project?
> I think so. If you'd be interested in task scheduling, even better, but if
> not, I think enough work can be done on worksharing loop scheduling.
Great.
I think task scheduling is indeed more important.
I'
On Sat, Mar 02, 2019 at 10:05:25PM +0900, 김규래 wrote:
> > It is on the wish list, but I'm afraid I won't have cycles for it in the
> > next year or two at least (once GCC 9 is released, I need to work on the
> > remaining OpenMP 5.0 features). Of course if somebody implements it and
> > submits
>
> > The clang implementation seem have work stealing.
> clang doesn't have its own runtime library, you mean the Intel OpenMP
> library, right?
I guess so.
> > Also, out of curiosity, is there any plan to add work stealing (affinity
> > schedules) to gomp?
s.
> Last time I looked, it seemed that adding a new scheduling keyword would
> require quite some work.
Not that much.
> Also, out of curiosity, is there any plan to add work stealing (affinity
> schedules) to gomp?
It is on the wish list, but I'm afraid I won't have
e some work.
Also, out of curiosity, is there any plan to add work stealing (affinity
schedules) to gomp?
The clang implementation seem have work stealing.
Ray Kim
-Original Message-
From: "Jakub Jelinek"
To: "김규래";
Cc: "gcc Mailing List";
Sent: 2019-03
On Fri, Mar 01, 2019 at 11:40:50PM +0900, 김규래 wrote:
> Hello everyone,
> I'm an EE student at Sogang University Korea.
> I have recently submitted a paper on parallel loop scheduling algorithm and
> had to modify libgomp a bit in the process.
> It is known that the...
>
>
>
> /* For now map
Hello everyone,
I'm an EE student at Sogang University Korea.
I have recently submitted a paper on parallel loop scheduling algorithm and had
to modify libgomp a bit in the process.
It is known that the...
/* For now map to schedule(static), later on we could play with feedback driven
choic
On Fri, Oct 16, 2015 at 11:44:17AM +0200, Thomas Schwinge wrote:
> But: working on getting our changes into trunk, for example, when we make
> an effort to extract from gomp-4_0-branch self-contained, individual
> patches, but it then takes weeks to get commit approval or review
>
fly. In general I'll try to review
anything I think I can figure out and which doesn't have a super-active
maintainer, but some areas have folks who clearly know the code better.
The whole gomp area is one of those, and when in doubt, I like to err on
the side of allowing (in this case)
Hi!
On Tue, 13 Oct 2015 21:12:14 +0200, Jakub Jelinek wrote:
> I've bootstrapped/regtested on x86_64-linux and i686-linux following
> merge from gomp-4_1-branch to trunk, which brings in most of the OpenMP 4.5
> support for C and C++
With nvptx offloading, I'm seeing the fo
On 17/07/15 14:36, Torvald Riegel wrote:
On Fri, 2015-07-17 at 13:33 +0200, Sebastian Huber wrote:
>On 17/07/15 13:26, Jakub Jelinek wrote:
> >On Fri, Jul 17, 2015 at 01:17:32PM +0200, Sebastian Huber wrote:
> >> >On 17/07/15 08:40, Sebastian Huber wrote:
> >>> > >Hello,
> >>> > >
> >>> > >
On Fri, 2015-07-17 at 13:33 +0200, Sebastian Huber wrote:
> On 17/07/15 13:26, Jakub Jelinek wrote:
> > On Fri, Jul 17, 2015 at 01:17:32PM +0200, Sebastian Huber wrote:
> >> >On 17/07/15 08:40, Sebastian Huber wrote:
> >>> > >Hello,
> >>> > >
> >>> > >the libgomp configuration for RTEMS uses curren
On 17/07/15 13:43, Jakub Jelinek wrote:
On Fri, Jul 17, 2015 at 01:33:41PM +0200, Sebastian Huber wrote:
Attached is a more complete example.
I'd prefer not to share the two implementations, just copy and adjust
the linux/bar.[ch] into rtems/bar.[ch].
Ok, I understand that you want to separa
On Fri, Jul 17, 2015 at 01:33:41PM +0200, Sebastian Huber wrote:
> >>>Attached is a more complete example.
> >I'd prefer not to share the two implementations, just copy and adjust
> >the linux/bar.[ch] into rtems/bar.[ch].
>
> Ok, I understand that you want to separate support for a niche system f
On 17/07/15 13:26, Jakub Jelinek wrote:
On Fri, Jul 17, 2015 at 01:17:32PM +0200, Sebastian Huber wrote:
>On 17/07/15 08:40, Sebastian Huber wrote:
> >Hello,
> >
> >the libgomp configuration for RTEMS uses currently the POSIX
> >implementation. Unfortunately the performance is unacceptable bad,
On Fri, Jul 17, 2015 at 01:17:32PM +0200, Sebastian Huber wrote:
> On 17/07/15 08:40, Sebastian Huber wrote:
> >Hello,
> >
> >the libgomp configuration for RTEMS uses currently the POSIX
> >implementation. Unfortunately the performance is unacceptable bad, so I
> >work currently on a specialized RT
rom 0410937e6f07dd1923dbcf20a0b2cda5953cd1cc Mon Sep 17 00:00:00 2001
From: Sebastian Huber
Date: Wed, 1 Jul 2015 22:14:38 +0200
Subject: [PATCH] [gomp] Add RTEMS configuration
libgomp/ChangeLog
2015-07-18 Sebastian Huber
* config/rtems/bar.c: New.
* config/rtems/bar.h: Likewise.
* config/rtems/mutex.c: Likewise.
* con
Hello,
the libgomp configuration for RTEMS uses currently the POSIX
implementation. Unfortunately the performance is unacceptable bad, so I
work currently on a specialized RTEMS configuration. I would like to
reuse the code of the Linux futex barrier. On RTEMS there is no
kernel/user space se
Hi,
in gcc/libgomp/env.c
the ICV run-sched-var is defined as
run_sched_var = GFS_DYNAMIC
It would be more natural to define it as GFS_STATIC, since
the default schedule is also static in gomp. Is there any reason
for this decision?
Both ICVs run-sched-var and def-sched-var are implementation
Hi!
On Fri, 24 Jan 2014 18:24:56 +0100, I wrote:
> First, pardon the long CC list. You are, in my understanding, the people
> who are interested in collaborating on the topics that are being prepared
> on gomp-4_0-branch: "LTO" streaming, acceleration device offloading,
>
Hi!
First, pardon the long CC list. You are, in my understanding, the people
who are interested in collaborating on the topics that are being prepared
on gomp-4_0-branch: "LTO" streaming, acceleration device offloading,
OpenMP target, OpenACC, nvptx backend -- and more?
As we've
will work with the
> normal build of GCC GOMP (for OpenMP) on GNU/Linux. Up to now, it has
> been necessary for interested parties to build their own GCC in order
> to build a libgomp which uses pthreads rather than Linux clone for
> threading. This is because valgrind only suppor
On Tue, Feb 26, 2013 at 8:42 AM, Jeffrey Walton wrote:
> Hi All,
>
> This came up on another list (Automake). I'm going to quote Bob
> Friesenhahn directly since my paraphrase won't do him justice:
>
> "I am curious if this ThreadSanitizer extension will work wi
> An associated bug report would be appreciated (mailing list
> discussions are useful for raising awareness, but are more likely to
> be forgotten over time than bug reports): http://bugs.python.org
Just did that; thanks!
-- Hoyt
+ Hoyt Koepke
+
Hello,
I've encountered a strange bug that appears to be either in gcc's gomp
implementation or in how python loads extension modules linked against
gomp. Here's the error:
Using gcc (multiple versions) on linux, I compile an empty c extension
module and pass -lgomp as a li
On Sun, Feb 20, 2011 at 3:43 PM, Hoyt Koepke wrote:
> I'd be happy to provide any more information if needed. I attached
> example code that reproduces it. Let me know if I should file a bug
> report (and where to file it -- which is why I haven't yet).
An associated bug report would be appreci
On Mon, Aug 10, 2009 at 02:05, Qihang Huang wrote:
> I found some preliminary documents for the initial GOMP project, but
> it is old and not much detail. I was wondering whether there is a
> design document for OpenMP 3.0? Or something similar. That would be
> really helpful.
Hi list,
I found some preliminary documents for the initial GOMP project, but
it is old and not much detail. I was wondering whether there is a
design document for OpenMP 3.0? Or something similar. That would be
really helpful.
Many thanks.
Cheers,
Tim
On Mon, Mar 16, 2009 at 07:16:33PM +0100, Steven Bosscher wrote:
> On Mon, Mar 16, 2009 at 7:06 PM, Toon Moene wrote:
> > [ Perhaps we need a somewhat larger audience for this one, as it isn't a
> > gfortran specific issue (despite the COMMONs). ]
> >
> > The reporter of this problem (perhaps it'
On Mon, Mar 16, 2009 at 7:06 PM, Toon Moene wrote:
> [ Perhaps we need a somewhat larger audience for this one, as it isn't a
> gfortran specific issue (despite the COMMONs). ]
>
> The reporter of this problem (perhaps it's necessary to open a bugzilla PR)
> uses:
>
> It is GNU/linux on x86_64, f
[ Perhaps we need a somewhat larger audience for this one, as it isn't a
gfortran specific issue (despite the COMMONs). ]
The reporter of this problem (perhaps it's necessary to open a bugzilla
PR) uses:
It is GNU/linux on x86_64, fedora 10
kernel 2.6.27.12-170.2.5.fc10.x86_64
glibc-2.9-3.x
I am looking at a couple of libgomp failures on IA64 HP-UX and I am
pretty sure what the problem is and that it is in omp-low.c but I am
not sure exactly where in omp-low.c it is.
The tests (libgomp.c/loop-5.c and libgomp.c++/loop-8.C) only fail in
32 bit mode on IA64 HP-UX where we use the addp4
On Thu, Apr 17, 2008 at 8:47 PM, Sebastian Pop <[EMAIL PROTECTED]> wrote:
> Ogier proposed to dump the outlined gimple to a file (i.e. LTO could
> do that) and then read this back in the SPU compiler. Does this
> approach sound right?
Yes, this was my idea also which is why I was waiting for L
On Thu, Apr 17, 2008 at 10:36 PM, Andrew Pinski <[EMAIL PROTECTED]> wrote:
> Correct. I was just trying to correct the idea that spu support was
> not committed to the FSF GCC. Considering I am a maintainer of it
> too, I don't want people to get the wrong thought there.
>
Ok, I got an email
On Thu, Apr 17, 2008 at 8:25 PM, Sebastian Pop <[EMAIL PROTECTED]> wrote:
> On Wed, Apr 16, 2008 at 10:44 AM, Andrew Pinski <[EMAIL PROTECTED]> wrote:
> > Huh??? Spu support is in gcc 4.3.0.
> >
>
> Ok, GCC4.3 can compile for Cell, but what is the status of libGOMP on
> Cell? Is there an eff
On Wed, Apr 16, 2008 at 10:44 AM, Andrew Pinski <[EMAIL PROTECTED]> wrote:
> Huh??? Spu support is in gcc 4.3.0.
>
Ok, GCC4.3 can compile for Cell, but what is the status of libGOMP on
Cell? Is there an efficient port of libGOMP for Cell? I assume that
the linux port could be used for Cell, bu
Sent from my iPhone
On Apr 16, 2008, at 6:52, Ogier Maitre <[EMAIL PROTECTED]> wrote:
Hello.
I'm student in master, and I'm at this time in a internship named
"Parallelization on Cell processor".
We are interested in porting libgomp an cell processor.
Like you maybe know, cell proc uses t
Hello.
I'm student in master, and I'm at this time in a internship named
"Parallelization on Cell processor".
We are interested in porting libgomp an cell processor.
Like you maybe know, cell proc uses two different compiler, spu-gcc and
ppu-gcc.
Both are 4.1.1 version of gcc, which doesn't s
On Sat, 2007-11-03 at 10:35 +0100, Sylvain Pion wrote:
> skaller wrote :
> > I can tell you I definitely considered using FS for the
> > Felix thread frame pointer to save passing that pointer
> > between every function..
>
> But then, won't you end up with an implementation very similar
> to __
skaller wrote :
I can tell you I definitely considered using FS for the
Felix thread frame pointer to save passing that pointer
between every function..
But then, won't you end up with an implementation very similar
to __thread??
--
Sylvain Pion
INRIA Sophia-Antipolis
Geometrica Project-Team
On Fri, Nov 02, 2007 at 11:09:33PM -0700, Ian Lance Taylor wrote:
> skaller <[EMAIL PROTECTED]> writes:
>
> > > As I said before, the register is only stolen for code which actually
> > > uses TLS.
> >
> > So scanning that document, for x86_64, fs is used in startup
> > code, presumably if, and o
skaller <[EMAIL PROTECTED]> writes:
> > As I said before, the register is only stolen for code which actually
> > uses TLS.
>
> So scanning that document, for x86_64, fs is used in startup
> code, presumably if, and only if, there is a linker section
> containing __thread variables?
Yes.
Ian
On Fri, 2007-11-02 at 22:35 -0700, Ian Lance Taylor wrote:
> skaller <[EMAIL PROTECTED]> writes:
>
> > Neko, for example, uses a register. AFAIK MLton does the
> > same kind of thing. If gcc team thinks ANY register is free
> > to steal they'd be wrong -- that doesn't mean it shouldn't
> > be use
On Fri, 2007-11-02 at 23:56 -0400, Robert Dewar wrote:
> skaller wrote:
> You really can't be serious in your comment about fs, if you
> understand the architecture ...
You're just not thinking the same way I am. A CPU has state,
the compiler and application program manage that state.
If the co
skaller <[EMAIL PROTECTED]> writes:
> Neko, for example, uses a register. AFAIK MLton does the
> same kind of thing. If gcc team thinks ANY register is free
> to steal they'd be wrong -- that doesn't mean it shouldn't
> be used, just that it definitely is NOT free.
To be clear, it is not the gcc
On Fri, 2007-11-02 at 23:54 -0400, Robert Dewar wrote:
> skaller wrote:
> > On Fri, 2007-11-02 at 18:45 -0700, Andrew Pinski wrote:
> >>> This is not true. If you use a register for any purpose like this,
> >>> it can't be used for anything else and that has a cost.
> >> This is a segment register
skaller wrote:
This is not true. If you use a register for any purpose like this,
it can't be used for anything else and that has a cost.
On x86_64 which I use, every register is valuable. Don't you dare
take one away, it would have a serious performance impact AND
it would stop ME using that r
skaller wrote:
On Fri, 2007-11-02 at 18:45 -0700, Andrew Pinski wrote:
This is not true. If you use a register for any purpose like this,
it can't be used for anything else and that has a cost.
This is a segment register. Please go and read about what segment
registers.
I know how the x86 wo
On Fri, 2007-11-02 at 18:45 -0700, Andrew Pinski wrote:
> > This is not true. If you use a register for any purpose like this,
> > it can't be used for anything else and that has a cost.
>
> This is a segment register. Please go and read about what segment
> registers.
I know how the x86 works
On Sat, 2007-11-03 at 12:27 +1100, skaller wrote:
> On Fri, 2007-11-02 at 10:29 -0700, Ian Lance Taylor wrote:
> Of course there is. It's called design by contract.
> I do it all the time. I am appalled at code bases like
> GTK and interfaces like OpenMP which get such really
> basic things wrong
On Fri, 2007-11-02 at 13:47 -0600, Joel Dice wrote:
> > So any (application) program needing TLS (other than the stack)
> > is automatically badly designed. I've been writing code for
> > three decades without using any global variables, ever since
> > I learned about re-entrancy.
>
> While I a
skaller <[EMAIL PROTECTED]> writes:
> On Fri, 2007-11-02 at 10:29 -0700, Ian Lance Taylor wrote:
> > skaller <[EMAIL PROTECTED]> writes:
> >
> > > On Fri, 2007-11-02 at 07:39 -0700, Ian Lance Taylor wrote:
> > > > skaller <[EMAIL PROTECTED]> writes:
> > >
> > > > In a C executable, TLS requires
On Fri, 2007-11-02 at 15:31 -0400, Robert Dewar wrote:
> Olivier Galibert wrote:
> There are lots of cases where global thread specific variables
> are useful in practice, ask anyone who has programmed real world
> large scale real time embedded programs.
No. And I have done just that myself. Th
> This is not true. If you use a register for any purpose like this,
> it can't be used for anything else and that has a cost.
This is a segment register. Please go and read about what segment
registers. They are not real registers and cannot be used for
anything except memory accesses. They da
On Fri, 2007-11-02 at 20:00 +0100, Olivier Galibert wrote:
> On Sat, Nov 03, 2007 at 03:38:51AM +1100, skaller wrote:
> > My argument is basically: there is no need for any such
> > feature in a well written program. Each thread already has
> > its own local stack. Global variables should not be u
On Fri, 2007-11-02 at 19:56 +0100, Olivier Galibert wrote:
> On Sat, Nov 03, 2007 at 03:31:14AM +1100, skaller wrote:
> > On Fri, 2007-11-02 at 07:39 -0700, Ian Lance Taylor wrote:
> > > I think you need to look at the TLS access code before deciding that
> > > it has bad performance.
> >
> > Yo
On Fri, 2007-11-02 at 10:29 -0700, Ian Lance Taylor wrote:
> skaller <[EMAIL PROTECTED]> writes:
>
> > On Fri, 2007-11-02 at 07:39 -0700, Ian Lance Taylor wrote:
> > > skaller <[EMAIL PROTECTED]> writes:
> >
> > > In a C executable, TLS requires one extra machine register.
> >
> > You mean gc
On Sat, 3 Nov 2007, skaller wrote:
On Fri, 2007-11-02 at 10:46 -0400, Daniel Jacobowitz wrote:
On Fri, Nov 02, 2007 at 07:39:33AM -0700, Ian Lance Taylor wrote:
The only way I can interpret your comments is that you are assuming
that all TLS is Global Dynamic (e.g., accessed from a dlopen'ed sh
Olivier Galibert wrote:
On Sat, Nov 03, 2007 at 03:38:51AM +1100, skaller wrote:
My argument is basically: there is no need for any such
feature in a well written program. Each thread already has
its own local stack. Global variables should not be used
in the first place (except for signals etc
On Sat, Nov 03, 2007 at 03:38:51AM +1100, skaller wrote:
> My argument is basically: there is no need for any such
> feature in a well written program. Each thread already has
> its own local stack. Global variables should not be used
> in the first place (except for signals etc where
> there is no
On Sat, Nov 03, 2007 at 03:31:14AM +1100, skaller wrote:
> On Fri, 2007-11-02 at 07:39 -0700, Ian Lance Taylor wrote:
> > I think you need to look at the TLS access code before deciding that
> > it has bad performance.
>
> You already said it costs a register? That's a REALLY high cost
> to pay t
skaller <[EMAIL PROTECTED]> writes:
> On Fri, 2007-11-02 at 07:39 -0700, Ian Lance Taylor wrote:
> > skaller <[EMAIL PROTECTED]> writes:
>
> > In a C executable, TLS requires one extra machine register.
>
> You mean gcc?
I don't understand the question. I mean in a C/C++ executable which
use
On Fri, 2007-11-02 at 10:46 -0400, Daniel Jacobowitz wrote:
> On Fri, Nov 02, 2007 at 07:39:33AM -0700, Ian Lance Taylor wrote:
> > The only way I can interpret your comments is that you are assuming
> > that all TLS is Global Dynamic (e.g., accessed from a dlopen'ed shared
> > library). But stac
On Fri, 2007-11-02 at 07:39 -0700, Ian Lance Taylor wrote:
> skaller <[EMAIL PROTECTED]> writes:
> In a C executable, TLS requires one extra machine register.
You mean gcc?
> TLS
> variables are accessed via offsets from that register. So what's the
> significant difference between that and
On Fri, Nov 02, 2007 at 07:39:33AM -0700, Ian Lance Taylor wrote:
> The only way I can interpret your comments is that you are assuming
> that all TLS is Global Dynamic (e.g., accessed from a dlopen'ed shared
> library). But stack based thread local storage won't work for
> dlopen'ed shared librar
skaller <[EMAIL PROTECTED]> writes:
> A really cool (non-Posix) implementation would put TLS globals
> on the stack base .. but this does require at least one extra
> machine register in languages like C which don't provide
> a static display (pointer to parent function). For languages
> that do,
On Thu, 2007-11-01 at 21:02 -0700, Gary Funck wrote:
> On Thu, Oct 18, 2007 at 11:42:52AM +1000, skaller wrote:
> >
> > DO you know how thread local variables are handled?
> > [Not using Posix TLS I hope .. that would be a disaster]
>
> Would you please elaborate?
Sure ..
> What's wrong with
On Thu, Oct 18, 2007 at 11:42:52AM +1000, skaller wrote:
>
> DO you know how thread local variables are handled?
> [Not using Posix TLS I hope .. that would be a disaster]
Would you please elaborate? What's wrong with the
POSIX TLS implementation? Do you know of any studies?
I ask, because we
On Sat, 2007-10-20 at 22:32 +0400, Tomash Brechko wrote:
> I'm not sure what OpenMP spec says about default data scope (too lazy
> to read through),
> but it seems that examples from
> http://kallipolis.com/openmp/2.html assume default(private), while GCC
> GOMP defaults
I'm not sure what OpenMP spec says about default data scope (too lazy
to read through), but it seems that examples from
http://kallipolis.com/openmp/2.html assume default(private), while GCC
GOMP defaults to shared. In your case,
#pragma omp parallel for shared(A, row, col)
for (i = k+1; i
On 19 October 2007 02:45, tim prince wrote:
> skaller wrote:
>> On Thu, 2007-10-18 at 06:00 -0700, Tim Prince wrote:
>>
>>> skaller wrote:
>>>
>>
>>
>>> I don't know of any OpenMP compiler which would correct the nesting of
>>> parallel loops in your LU. I have assumed that OpenMP doesn't all
skaller wrote:
On Thu, 2007-10-18 at 06:00 -0700, Tim Prince wrote:
skaller wrote:
I don't know of any OpenMP compiler which would correct the nesting of
parallel loops in your LU. I have assumed that OpenMP doesn't allow
such optimization; you have to get it right yourself.
On Thu, 2007-10-18 at 13:04 +0200, Jakub Jelinek wrote:
> On Thu, Oct 18, 2007 at 02:47:44PM +1000, skaller wrote:
> On LU_mp.c according to oprofile more than 95% of time is spent in the inner
> loop, rather than any kind of waiting. On quad core with OMP_NUM_THREADS=4
> all 4 threads eat 99.9%
On Thu, 2007-10-18 at 06:00 -0700, Tim Prince wrote:
> skaller wrote:
> I don't know of any OpenMP compiler which would correct the nesting of
> parallel loops in your LU. I have assumed that OpenMP doesn't allow
> such optimization; you have to get it right yourself.
Can you explain? This co
skaller wrote:
On Thu, 2007-10-18 at 12:02 +0800, Biplab Kumar Modak wrote:
skaller wrote:
On Wed, 2007-10-17 at 18:14 +0100, Biagio Lucini wrote:
skaller wrote:
It would be interesting to try with another compiler. Do you have access
to another OpenMP-enabled compiler
On Thu, Oct 18, 2007 at 02:47:44PM +1000, skaller wrote:
>
> On Thu, 2007-10-18 at 12:02 +0800, Biplab Kumar Modak wrote:
> > skaller wrote:
> > > On Wed, 2007-10-17 at 18:14 +0100, Biagio Lucini wrote:
> > >> skaller wrote:
> > >
> > >> It would be interesting to try with another compiler. Do yo
started at 828
integration done at 8015
pi done at 8703
integration started at 8703
Values: e*pi = 9.267763, integral = 9.67
Total elapsed time: 15.609 seconds
C:\Projects\Test\bin\Release>
This indicates that GOMP is working well. :)
My system specs:
Windows XP SP2, 1GB RAM, [EMAIL
skaller wrote:
OK, attached.
Hi skaller,
I think I've wasted my money. They do not ship OpenMP headers and libs
with Standard Edition. :(
Best Regards,
Biplab
On Thu, 2007-10-18 at 12:02 +0800, Biplab Kumar Modak wrote:
> skaller wrote:
> > On Wed, 2007-10-17 at 18:14 +0100, Biagio Lucini wrote:
> >> skaller wrote:
> >
> >> It would be interesting to try with another compiler. Do you have access
> >> to another OpenMP-enabled compiler?
> >
> > Unfort
skaller wrote:
On Wed, 2007-10-17 at 18:14 +0100, Biagio Lucini wrote:
skaller wrote:
It would be interesting to try with another compiler. Do you have access
to another OpenMP-enabled compiler?
Unfortunately no, unless MSVC++ in VS2005 has openMP.
I have an Intel licence but they're too ti
Ross Ridge wrote:
skaller writes:
Unfortunately no, unless MSVC++ in VS2005 has openMP.
I don't know if Visual C++ 2005 Express supports OpenMP, but the
Professional edition should. Alternatively, the free, as in beer,
Microsoft compiler included in the Windows SDK supports OpenMP.
Visual
On Thu, 2007-10-18 at 11:18 +1000, skaller wrote:
> On Wed, 2007-10-17 at 10:09 -0700, Joe Buck wrote:
> > On Thu, Oct 18, 2007 at 03:00:02AM +1000, skaller wrote:
> > > Hi, I have just run and timed a couple of tutorial examples for
> > > openMP using gcc (GCC) 4.2.1 (Ubuntu 4.2.1-5ubuntu4) on a
On Wed, 2007-10-17 at 10:09 -0700, Joe Buck wrote:
> On Thu, Oct 18, 2007 at 03:00:02AM +1000, skaller wrote:
> > Hi, I have just run and timed a couple of tutorial examples for
> > openMP using gcc (GCC) 4.2.1 (Ubuntu 4.2.1-5ubuntu4) on a dual core
> > Athlon amd64, with OMP_NUM_THREADS set to 1
skaller writes:
> Unfortunately no, unless MSVC++ in VS2005 has openMP.
I don't know if Visual C++ 2005 Express supports OpenMP, but the
Professional edition should. Alternatively, the free, as in beer,
Microsoft compiler included in the Windows SDK supports OpenMP.
On Wed, 2007-10-17 at 10:09 -0700, Joe Buck wrote:
> On Thu, Oct 18, 2007 at 03:00:02AM +1000, skaller wrote:
> > Hi, I have just run and timed a couple of tutorial examples for
> > openMP using gcc (GCC) 4.2.1 (Ubuntu 4.2.1-5ubuntu4) on a dual core
> > Athlon amd64, with OMP_NUM_THREADS set to 1
On Wed, 2007-10-17 at 18:14 +0100, Biagio Lucini wrote:
> skaller wrote:
> It would be interesting to try with another compiler. Do you have access
> to another OpenMP-enabled compiler?
Unfortunately no, unless MSVC++ in VS2005 has openMP.
I have an Intel licence but they're too tied up with co
skaller wrote:
Hi, I have just run and timed a couple of tutorial examples for
openMP using gcc (GCC) 4.2.1 (Ubuntu 4.2.1-5ubuntu4) on a dual core
Athlon amd64, with OMP_NUM_THREADS set to 1 and 2, and occasionally
8 I found that 1 thread outperforms 2 by almost 2:1 on all the examples,
and 8 i
On Thu, Oct 18, 2007 at 03:00:02AM +1000, skaller wrote:
> Hi, I have just run and timed a couple of tutorial examples for
> openMP using gcc (GCC) 4.2.1 (Ubuntu 4.2.1-5ubuntu4) on a dual core
> Athlon amd64, with OMP_NUM_THREADS set to 1 and 2, and occasionally
> 8 I found that 1 thread outperfor
Hi, I have just run and timed a couple of tutorial examples for
openMP using gcc (GCC) 4.2.1 (Ubuntu 4.2.1-5ubuntu4) on a dual core
Athlon amd64, with OMP_NUM_THREADS set to 1 and 2, and occasionally
8 I found that 1 thread outperforms 2 by almost 2:1 on all the examples,
and 8 is only fractionall
FYI, gomp in mainline is broken:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31722
Possible cause may be:
http://gcc.gnu.org/ml/gcc-patches/2007-03/msg01965.html
H.J.
FX Coudert wrote:
Is there any reason why libgomp and libdecnumber don't have a svn:ignore
property containing autom4te.cache? I noticed the following always
showing up in my "svn status" after a maintainer-mode build:
? libdecnumber/autom4te.cache
? libgomp/autom4te.cache
Go ahead
Is there any reason why libgomp and libdecnumber don't have a
svn:ignore property containing autom4te.cache? I noticed the
following always showing up in my "svn status" after a maintainer-
mode build:
? libdecnumber/autom4te.cache
? libgomp/autom4te.cache
Thanks,
FX
On Thursday 23 November 2006 05:11, you wrote:
> On Wed, 2006-11-22 at 22:52 +0100, Daniel Franke wrote:
> > The tarball of 4.1.1 includes fastjar/fastjar.info, but not
> > libiberty/libiberty.info. The config file fastjar/configure.ac has the
> > enable-...-srcdir flag, libiberty/configure.ac does
> This is because libiberty's API is all internal really and is always
> changing and never stable. It is not really a well defined library
> unlike say libgomp.
... although we do try to keep backward compatiblity when possible, so
that newer libiberties work with older gcc/binutils/gdb/whateve
1 - 100 of 171 matches
Mail list logo
