Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.arch > #3223

Re: indexing register

Show all headers | View raw

On 8/27/2011 6:39 PM, Andy "Krazy" Glew wrote:
> On 8/24/2011 8:44 PM, MitchAlsup wrote:
>> A) In general, I am a fan of flat register files and in particular
>> when implementing SPARC V8s and V9s found that the windowed register
>> files were a performance impediment and not a performance adder.
>>
>> B) Given that you have the ability to make such a large register file
>> without harming performance (see A above) It is my considered opinion
>> that you would get more performance by sharing that file across
>> several threads than by adding registers to a single context.
>>
>> C) Can anyone name a machine with that 'took the performance world by
>> storm' and also used more than 5-bits to index the register file(s)?
>> {Note this wording expressively allows the CRAY 1 in because it
>> indexes its register files with only 3-bits.}
>>
>> Mitch
>
> Actually, Mitch, I think I'll take the opposite:
>
> register windows<< multiple threads with separate, disjoint, register
> files << a single thread with a big flat register file (and block on
> use) n multiple threads with variable sized register files partitioning
> a big RF
>
> Comparable: in system software, which would you rather do: write a
> really multithreaded program I or use as inch I/o?
>
> Myself, I would rather write the asynch I/o program as a single thread,
> for jobs like fast file copy or backup. Sure, given enough work the
> multithreaded version may heat the asynch I/oversion. But the best
> program willprobably need to do both, and the a synch I/o version is
> often low hanging fruit, easy to get a good speedup. I only jump to
> threads first when the computation is non-trivial, e.g. where I don't
> want to lock out user input while rendering.
>
> Explanation: registers are rather like asynch I/O handles. The more such
> handles or registers, the more such parallelism under user control.
>
> Yes, threads do the same, but threads always have overhead, in both HW &
> SW.
>
> (By the Way, I don't care to discuss a synch I/o implementations that
> require a Kernel thread for each asynch I/O. That's stupid. Asynch I/O
> handles can be much cheaper than a Kernel thread.
>
> Variable size RFs per thread seem to have the best of both worlds.
>
> My main problem with variable size RFs, or large flat RFs in generals is
> architecture: I am by no means certain that multithreaded
> microarchitectures are the best for all systems. Back of the envelope
> calculations southeast MIMD are best in some cases. With small RFs. How
> does code written for a large RF run when there isn't one?
>
> I am not so concerned about fitting into a 32 bit instruction with S bit
> fields. Many codes that use flat large RFs fit in loop buffers, etc.

I may back out from this.

Threads, annoyingly, are scalable.  They can be portable across more 
microarchitectures than large register files.

E.g. threads with a moderate maximum number of registers, say 16, 32, or 64

a) can run on simple machines, e.g. independent MIMD

b) can run on highly multithreaded machines, e,.g. GPU-style 
microarchitectures with 2K registers, split amongst many threads

c) can run on in-orrder, out-of-order, whatever.

Whereas large register files, like 256 regs

A) require fairly big basic machines - i.e. they do not run on the 
really lightweight MIMD procesors that are one of my design points.

B) make OOO more expensive, or at least more difficult.

Back to comp.arch | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread

Thread

indexing register Joe Keane <jgk@jgk.org> - 2011-08-24 19:36 +0000
  Re: indexing register Stephen Fuld <SFuld@alumni.cmu.edu.invalid> - 2011-08-24 13:38 -0700
  Re: indexing register MitchAlsup <MitchAlsup@aol.com> - 2011-08-24 18:44 -0700
    Re: indexing register "Andy \"Krazy\" Glew" <andy@SPAM.comp-arch.net> - 2011-08-24 22:24 -0400
      Re: indexing register Quadibloc <jsavard@ecn.ab.ca> - 2011-08-24 20:08 -0700
        Re: indexing register Quadibloc <jsavard@ecn.ab.ca> - 2011-08-24 20:16 -0700
      Re: indexing register Thomas Womack <twomack@chiark.greenend.org.uk> - 2011-08-25 11:05 +0100
    Re: indexing register nmm1@cam.ac.uk - 2011-08-25 08:29 +0100
    Re: indexing register MitchAlsup <MitchAlsup@aol.com> - 2011-08-26 13:42 -0700
      Re: indexing register EricP <ThatWouldBeTelling@thevillage.com> - 2011-08-26 19:32 -0400
      Re: indexing register Robert Wessel <robertwessel2@yahoo.com> - 2011-08-26 18:53 -0500
        Re: indexing register "Andy \"Krazy\" Glew" <andy@SPAM.comp-arch.net> - 2011-08-26 20:46 -0400
          Re: indexing register Robert Wessel <robertwessel2@yahoo.com> - 2011-08-26 23:34 -0500
            Re: indexing register mac <acolvin@efunct.com> - 2011-08-28 17:23 +0000
          Re: indexing register MitchAlsup <MitchAlsup@aol.com> - 2011-08-27 14:10 -0700
    Re: indexing register "Andy \"Krazy\" Glew" <andy@SPAM.comp-arch.net> - 2011-08-27 18:19 -0500
    Re: indexing register "Andy \"Krazy\" Glew" <andy@SPAM.comp-arch.net> - 2011-08-27 20:39 -0500
      Re: indexing register "Andy \"Krazy\" Glew" <andy@SPAM.comp-arch.net> - 2011-08-28 20:59 -0700
    Re: indexing register jgk@panix.com (Joe keane) - 2011-08-29 21:59 +0000
  Re: indexing register Bakul Shah <usenet@bitblocks.com> - 2011-08-25 22:46 -0700
    Re: indexing register mac <acolvin@efunct.com> - 2011-08-26 14:06 +0000

csiph-web