By: Mark Roulo (markroulo.delete@this.yahoo.com), February 5, 2013 10:55 am
Room: Moderated Discussions
Michael S (already5chosen.delete@this.yahoo.com) on February 5, 2013 10:35 am wrote:
> Mark Roulo (markroulo.delete@this.yahoo.com) on February 5, 2013 8:40 am wrote:
> > Michael S (already5chosen.delete@this.yahoo.com) on February 5, 2013 2:51 am wrote:
> > > After you ported to Linux/x64, shouldn't porting to Linux/IPF be close
> > > to "just recompile"? Esp, if the same code already runs on SPARC?
> >
> > This is only an option when you have the source.
> >
>
> Richard had the source.
>
> > If your system needs a binary that hasn't been compiled for the new architecture:
> >
> > *) For x86 to x64 you can keep running the 32-bit binary
> >
> > *) For x86 to ia64 you are kinda done
>
> IA32EL should be good enough for non-performance-critical 3rd-party binaries.
> They claimed 50% of native speed, which is pretty impressive.
>
> >
> > Which makes it harder for people to migrate gradually.
> >
> > Which causes fewer people to migrate.
> >
> > Which lessens the obvious demand for the 3rd party to port to ia64.
> >
> > There is nothing new here and my company is seeing the same thing with respect to Xeon
> > Phi (which is only x86 for scalar code) ... no SSE support, so we can't move gradually.
> > It will be an all or nothing move, which probably means nothing. AVX2 in Haswell
> > we *will* support gradually and all the old SSE code will continue to run.
>
> That is your only problem with Xeon Phi? Do your apps have 4000-way
> parallelism (or 2000-way for double-precision) readily available?
Our loads are "embarrassingly" parallel :-) Right now, the biggest configuration that we ship with our tool has 15 blade centers, each stuffed with dual-socket 8-core chips. The communication between cores is minimal.
In theory, we'd be happy replacing some of these with Xeon Phis. In practice ... well, the price/performance numbers are not working out well for *our* loads and we'd have to move the whole thing over because of the previously mentioned lack of SSE :-(
[To be fair, part of the "problem" is that we have a psycho optimization team that optimizes the critical routines. This makes our baseline performance on x86/SSE pretty good. Which makes a higher hurdle for Xeon Phi to clear.]
Not happening.
> Mark Roulo (markroulo.delete@this.yahoo.com) on February 5, 2013 8:40 am wrote:
> > Michael S (already5chosen.delete@this.yahoo.com) on February 5, 2013 2:51 am wrote:
> > > After you ported to Linux/x64, shouldn't porting to Linux/IPF be close
> > > to "just recompile"? Esp, if the same code already runs on SPARC?
> >
> > This is only an option when you have the source.
> >
>
> Richard had the source.
>
> > If your system needs a binary that hasn't been compiled for the new architecture:
> >
> > *) For x86 to x64 you can keep running the 32-bit binary
> >
> > *) For x86 to ia64 you are kinda done
>
> IA32EL should be good enough for non-performance-critical 3rd-party binaries.
> They claimed 50% of native speed, which is pretty impressive.
>
> >
> > Which makes it harder for people to migrate gradually.
> >
> > Which causes fewer people to migrate.
> >
> > Which lessens the obvious demand for the 3rd party to port to ia64.
> >
> > There is nothing new here and my company is seeing the same thing with respect to Xeon
> > Phi (which is only x86 for scalar code) ... no SSE support, so we can't move gradually.
> > It will be an all or nothing move, which probably means nothing. AVX2 in Haswell
> > we *will* support gradually and all the old SSE code will continue to run.
>
> That is your only problem with Xeon Phi? Do your apps have 4000-way
> parallelism (or 2000-way for double-precision) readily available?
Our loads are "embarrassingly" parallel :-) Right now, the biggest configuration that we ship with our tool has 15 blade centers, each stuffed with dual-socket 8-core chips. The communication between cores is minimal.
In theory, we'd be happy replacing some of these with Xeon Phis. In practice ... well, the price/performance numbers are not working out well for *our* loads and we'd have to move the whole thing over because of the previously mentioned lack of SSE :-(
[To be fair, part of the "problem" is that we have a psycho optimization team that optimizes the critical routines. This makes our baseline performance on x86/SSE pretty good. Which makes a higher hurdle for Xeon Phi to clear.]
Not happening.
