Accéder au contenu.
Menu Sympa

starpu-devel - Re: [Starpu-devel] StarPU on IBM Power8 systems

Objet : Developers list for StarPU

Archives de la liste

Re: [Starpu-devel] StarPU on IBM Power8 systems


Chronologique Discussions 
  • From: Samuel Thibault <samuel.thibault@inria.fr>
  • To: vedran.novakovic@stfc.ac.uk
  • Cc: starpu-devel@lists.gforge.inria.fr
  • Subject: Re: [Starpu-devel] StarPU on IBM Power8 systems
  • Date: Thu, 3 Aug 2017 17:35:11 +0200
  • List-archive: <http://lists.gforge.inria.fr/pipermail/starpu-devel/>
  • List-id: "Developers list. For discussion of new features, code changes, etc." <starpu-devel.lists.gforge.inria.fr>
  • Organization: I am not organized

Hello,

vedran.novakovic@stfc.ac.uk, on mar. 20 juin 2017 15:10:32 +0000, wrote:
> Good news:
>
> StarPU (SVN version 21567) indeed builds on Power8LE, with CUDA support.

Cool :)

> Bad news (but not really bad at all):
>
> Unless some debugging flags that XL compilers don't understand are removed,
> as with:
>
> find . -name 'Makefile' -exec sed -i -e 's/\-gdwarf\-2//g' -e 's/\-g3/-g/g'
> {} \;
>
> (i.e., -gdwarf-2 -g3 to -g)
> they fail with
>
> xlc_r: error: 1501-230 Internal compiler error...

Erf. I'm surprised that we get to pass -gdwarf-2 to xlc. Does it really
get recognized as a gcc compiler? It's really a pain if a compiler
which is not actually compatible with gcc does announce itself as being
gcc...

> Running `make check` gives me these failures so far, for your information
> (it takes a long time to run):

Thanks!

> [starpu][starpu_unistd_o_direct_global_async_write][assert failure] The
> unistd_o_direct variant can only write a multiple of page size 65536 Bytes
> (Here 2183168). Use the non-o_direct unistd variant if your data is not a
> multiple of 65536

Ah, indeed, non-x86 architectures use pages bigger than 4096, so we need
to round it up for the o_direct Out-of-Core support. I have fixed it.

> with these tests skipped or expected to fail:
>
> SKIP: main/static_restartable_using_initializer
> SKIP: datawizard/interfaces/multiformat/advanced/multiformat_cuda_opencl
> SKIP: datawizard/readonly
> XFAIL: errorcheck/invalid_blocking_calls

Yes, errorcheck/invalid_blocking_calls really is expected to fail: it
tests that we do error out on invalid blocking calls :)

Samuel




Archives gérées par MHonArc 2.6.19+.

Haut de le page