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

Groups > comp.arch > #25688 > unrolled thread

Reading the Mill wiki: comments and a concern

Back to article view | Back to comp.arch

Contents

  Reading the Mill wiki: comments and a concern jgd@cix.co.uk (John Dallman) - 2014-12-12 19:15 +0000
    Re: Reading the Mill wiki: comments and a concern Ivan Godard <ivan@ootbcomp.com> - 2014-12-12 11:31 -0800
      Re: Reading the Mill wiki: comments and a concern peterfirefly@gmail.com - 2014-12-12 11:46 -0800
        Re: Reading the Mill wiki: comments and a concern Ivan Godard <ivan@ootbcomp.com> - 2014-12-12 12:06 -0800
          Re: Reading the Mill wiki: comments and a concern peterfirefly@gmail.com - 2014-12-12 13:37 -0800
            Re: Reading the Mill wiki: comments and a concern Ivan Godard <ivan@ootbcomp.com> - 2014-12-12 16:50 -0800
      Re: Reading the Mill wiki: comments and a concern jgd@cix.co.uk (John Dallman) - 2014-12-12 20:24 +0000
        Re: Reading the Mill wiki: comments and a concern Ivan Godard <ivan@ootbcomp.com> - 2014-12-12 12:35 -0800
          Re: Reading the Mill wiki: comments and a concern Quadibloc <jsavard@ecn.ab.ca> - 2014-12-12 15:03 -0800
            Re: Reading the Mill wiki: comments and a concern Ivan Godard <ivan@ootbcomp.com> - 2014-12-12 17:01 -0800
      Re: Reading the Mill wiki: comments and a concern Quadibloc <jsavard@ecn.ab.ca> - 2014-12-12 14:54 -0800
        Re: Reading the Mill wiki: comments and a concern Ivan Godard <ivan@ootbcomp.com> - 2014-12-12 17:11 -0800
          Re: Reading the Mill wiki: comments and a concern Melzzzzz <mel@zzzzz.com> - 2014-12-13 04:36 +0100
            Re: Reading the Mill wiki: comments and a concern Ivan Godard <ivan@ootbcomp.com> - 2014-12-12 19:59 -0800

#25688 — Reading the Mill wiki: comments and a concern

The Mill seems interesting, but I am partially sighted, and thus find
watching videos extremely hard work. So I've been reading through Mill
Computing's wiki, and have a few comments:

In many ways, this seems to take the smart ideas from Itanium and handle
them better, hopefully to a better outcome. 

The handling of floating point flags is particularly fine, as is the
automatic generation of Verilog, simulator, debugger and specialiser.

Something that I worry about because it was a problem on Itanium is
profile-guided optimisation. This was claimed to improve performance
considerably on Itanium, but was pretty much impractical for large codes.
Is it envisaged as important for Mill? 

John 

[toc] | [next] | [standalone]

#25692

On 12/12/2014 11:15 AM, John Dallman wrote:
> The Mill seems interesting, but I am partially sighted, and thus find
> watching videos extremely hard work. So I've been reading through Mill
> Computing's wiki, and have a few comments:
>
> In many ways, this seems to take the smart ideas from Itanium and handle
> them better, hopefully to a better outcome.
>
> The handling of floating point flags is particularly fine, as is the
> automatic generation of Verilog, simulator, debugger and specialiser.
>
> Something that I worry about because it was a problem on Itanium is
> profile-guided optimisation. This was claimed to improve performance
> considerably on Itanium, but was pretty much impractical for large codes.
> Is it envisaged as important for Mill?
>
> John
>
  If you can wade through the "Prediction" talk, you will find there how 
the Mill self-tuning prediction works. Beyond that, we have put a lot of 
effort into making the Mill ISA optimization-proof. When code can be 
optimized it means that the architecture design was lacking IMO, YMMV.

As for our site: I am quite sympathetic to the difficulties the site 
presents, although my own "partial" is hearing, not sight. At some point 
we want to fold the talks into a series of white papers, but for now 
simply lack the resources to do so.

[toc] | [prev] | [next] | [standalone]

#25694

On Friday, December 12, 2014 8:31:36 PM UTC+1, Ivan Godard wrote:
> On 12/12/2014 11:15 AM, John Dallman wrote:
> > The Mill seems interesting, but I am partially sighted, and thus find
> > watching videos extremely hard work. So I've been reading through Mill
> > Computing's wiki, and have a few comments:
> >
> > In many ways, this seems to take the smart ideas from Itanium and handle
> > them better, hopefully to a better outcome.
> >
> > The handling of floating point flags is particularly fine, as is the
> > automatic generation of Verilog, simulator, debugger and specialiser.
> >
> > Something that I worry about because it was a problem on Itanium is
> > profile-guided optimisation. This was claimed to improve performance
> > considerably on Itanium, but was pretty much impractical for large codes.
> > Is it envisaged as important for Mill?
> >
> > John
> >
>   If you can wade through the "Prediction" talk, you will find there how 
> the Mill self-tuning prediction works. Beyond that, we have put a lot of 
> effort into making the Mill ISA optimization-proof. When code can be 
> optimized it means that the architecture design was lacking IMO, YMMV.

Inlining and data layout (say, structure splitting)?
Which conditional code to put far away (because it is rarely run) and which to put right next the code for the conditional?

-Peter

[toc] | [prev] | [next] | [standalone]

#25696

On 12/12/2014 11:46 AM, peterfirefly@gmail.com wrote:
> On Friday, December 12, 2014 8:31:36 PM UTC+1, Ivan Godard wrote:

>>    If you can wade through the "Prediction" talk, you will find there how
>> the Mill self-tuning prediction works. Beyond that, we have put a lot of
>> effort into making the Mill ISA optimization-proof. When code can be
>> optimized it means that the architecture design was lacking IMO, YMMV.
>
> Inlining and data layout (say, structure splitting)?
> Which conditional code to put far away (because it is rarely run) and which to put right next the code for the conditional?
>
> -Peter
>

I was only addressing things that profiling might help with. Inlining 
(done in the specializer on the Mill) becomes rather unimportant when 
call overhead has been reduced to the trivial: one op, one cycle on a 
Mill. We expect (no numbers yet, patience) that the biggest impact will 
be on internal fragmentation in the iCache and other second-order effects.

I've never seen a case where the benefit of structure splitting is 
profile dependent. Please explain a use-case.

I'm not saying that all optimization is useless. But (to take an 
especially egregious example) the optimization involved in address-mode 
instruction selection on a VAX says more about the VAX architectural 
design than about the cleverness of the VAX compiler writers.

[toc] | [prev] | [next] | [standalone]

#25701

On Friday, December 12, 2014 9:06:26 PM UTC+1, Ivan Godard wrote:
> On 12/12/2014 11:46 AM, peterfirefly@gmail.com wrote:
> > On Friday, December 12, 2014 8:31:36 PM UTC+1, Ivan Godard wrote:
> 
> >>    If you can wade through the "Prediction" talk, you will find there how
> >> the Mill self-tuning prediction works. Beyond that, we have put a lot of
> >> effort into making the Mill ISA optimization-proof. When code can be
> >> optimized it means that the architecture design was lacking IMO, YMMV.
> >
> > Inlining and data layout (say, structure splitting)?
> > Which conditional code to put far away (because it is rarely run) and which to put right next the code for the conditional?
> >
> > -Peter
> >
> 
> I was only addressing things that profiling might help with. Inlining 
> (done in the specializer on the Mill) becomes rather unimportant when 
> call overhead has been reduced to the trivial: one op, one cycle on a 
> Mill.

I don't really believe you.

Inlining lets you do more common subexpression elimination, constant propagation, strenght reduction, dead code elimination.  It is an enabler of other optimizations.  If it was just about eliminating call/return overheads it would be rather uninteresting.

Whether or not inlining at a given call site is actually worth the trouble is hard to tell statically.  Profiling should be able to help.

> We expect (no numbers yet, patience) that the biggest impact will 
> be on internal fragmentation in the iCache and other second-order effects.
> 
> I've never seen a case where the benefit of structure splitting is 
> profile dependent. Please explain a use-case.

Why wouldn't it be profile dependent?  How else would you know where to split the structure(s) if not by measuring which items are (dynamically) hot and which aren't?

-Peter

[toc] | [prev] | [next] | [standalone]

#25706

On 12/12/2014 1:37 PM, peterfirefly@gmail.com wrote:
> On Friday, December 12, 2014 9:06:26 PM UTC+1, Ivan Godard wrote:

>> I was only addressing things that profiling might help with.
>> Inlining (done in the specializer on the Mill) becomes rather
>> unimportant when call overhead has been reduced to the trivial: one
>> op, one cycle on a Mill.
>
> I don't really believe you.

Well our experience, or our terminology, seem to differ.

> Inlining lets you do more common subexpression elimination, constant
> propagation, strenght reduction, dead code elimination.  It is an
> enabler of other optimizations.  If it was just about eliminating

In the presence of call-site spcialization (which the compiler should be 
doing anyway, and is profile-independent) inlining provides none of 
those, and really is a trivial saver of call overhead.

True, some uses of function pointers precludes call-site specialization, 
but those uses also preclude inlining.

> Whether or not inlining at a given call site is actually worth the
> trouble is hard to tell statically.  Profiling should be able to
> help.

Inlining always pays for call-once (possibly after call-site 
specialization has reduced the incidence), although you discover 
call-onceness at different points along the chain and sometimes there 
will be several points where inlining happens. One must be careful to 
properly order the inlining, because one inline can turn another call 
contained in the inlined code from call-once to call-many.

For call-many, it is platform dependent whether the second-order costs 
of inlining are greater than the call costs of not inlining, and like 
all optimization heuristics the choice is fuzzy. In my experience I've 
never felt the need for profile-driving inlining, even when profile was 
available. Can you cite anything that shows a gain?

>> We expect (no numbers yet, patience) that the biggest impact will
>> be on internal fragmentation in the iCache and other second-order
>> effects.
>>
>> I've never seen a case where the benefit of structure splitting is
>> profile dependent. Please explain a use-case.
>
> Why wouldn't it be profile dependent?  How else would you know where
> to split the structure(s) if not by measuring which items are
> (dynamically) hot and which aren't?

Perhaps we are referring to different optimization but using the same 
name. I am using the meaning in e.g. 
http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.faqs/ka3742.html 
item #8. With that meaning, you should split every component of a struct 
that is statically used at all; dynamic usage and hotness are irrelevant.

[toc] | [prev] | [next] | [standalone]

#25697

In article <m6ffq3$cm$1@dont-email.me>, ivan@ootbcomp.com (Ivan Godard)
wrote:

>   If you can wade through the "Prediction" talk, you will find 
> there how the Mill self-tuning prediction works.

I'll give that a try this weekend. 

Meanwhile, another question. It seems necessary to save and restore the
belt for interrupts, and the scratchpad can do that. But that implies you
need to be able to save scratchpad items, complete with metadata, to main
memory, if that's required to make room for saved belt items. Is this
correct, or is there some other trick? 

John 

[toc] | [prev] | [next] | [standalone]

#25698

On 12/12/2014 12:24 PM, John Dallman wrote:
> In article <m6ffq3$cm$1@dont-email.me>, ivan@ootbcomp.com (Ivan Godard)
> wrote:
>
>>    If you can wade through the "Prediction" talk, you will find
>> there how the Mill self-tuning prediction works.
>
> I'll give that a try this weekend.
>
> Meanwhile, another question. It seems necessary to save and restore the
> belt for interrupts, and the scratchpad can do that. But that implies you
> need to be able to save scratchpad items, complete with metadata, to main
> memory, if that's required to make room for saved belt items. Is this
> correct, or is there some other trick?
>
> John
>

Mill code does not contain function-call save/restore; that's all done 
for you. An interrupt is an involuntary function call, and belt and 
scratchpad are both transparently saved by the spiller. Spiller 
droppings eventually do get to memory, but you are not concerned with 
that, and only some specialized system code (like the library the 
debuggers use to probe down-stack) need care.

[toc] | [prev] | [next] | [standalone]

#25704

On Friday, December 12, 2014 1:36:00 PM UTC-7, Ivan Godard wrote:

> Mill code does not contain function-call save/restore; that's all done 
> for you. An interrupt is an involuntary function call, and belt and 
> scratchpad are both transparently saved by the spiller. Spiller 
> droppings eventually do get to memory, but you are not concerned with 
> that, and only some specialized system code (like the library the 
> debuggers use to probe down-stack) need care.

That sounds like a very good idea. It takes one of the messiest parts of 
programming out of the way; it allows your architecture which doesn't use 
registers to work; instead of saving registers to memory with every subroutine 
call, what you're doing is like the trick of having a second set of registers 
some old machines did, but in a transparent fashion.

Where it sounds scary to people used to conventional machines, though, is that 
while it's OK for a thing like an _operating system_ to have a save area or a 
stack somewhere in memory, for the *hardware* to do stuff like that, where the 
hardware is a chip that can be put into many different configurations of other 
hardware - i.e. with varying amounts of memory - is complicated.

It's starting to sound as if the Mill at least behaves like a hardware-software 
system; that it includes, built into it, some functionality that is associated 
with the operating system on conventional architectures. So it will have to 
figure out how much memory is available to it on startup, for example... or 
maybe it will just have a lot of reserved locations in low memory addresses, 
which would be more conventional, instead of trying to put that stuff at the 
high end of memory.

John Savard

[toc] | [prev] | [next] | [standalone]

#25707

On 12/12/2014 3:03 PM, Quadibloc wrote:
> On Friday, December 12, 2014 1:36:00 PM UTC-7, Ivan Godard wrote:
>
>> Mill code does not contain function-call save/restore; that's all done
>> for you. An interrupt is an involuntary function call, and belt and
>> scratchpad are both transparently saved by the spiller. Spiller
>> droppings eventually do get to memory, but you are not concerned with
>> that, and only some specialized system code (like the library the
>> debuggers use to probe down-stack) need care.
>
> That sounds like a very good idea. It takes one of the messiest parts of
> programming out of the way; it allows your architecture which doesn't use
> registers to work; instead of saving registers to memory with every subroutine
> call, what you're doing is like the trick of having a second set of registers
> some old machines did, but in a transparent fashion.
>
> Where it sounds scary to people used to conventional machines, though, is that
> while it's OK for a thing like an _operating system_ to have a save area or a
> stack somewhere in memory, for the *hardware* to do stuff like that, where the
> hardware is a chip that can be put into many different configurations of other
> hardware - i.e. with varying amounts of memory - is complicated.
>
> It's starting to sound as if the Mill at least behaves like a hardware-software
> system; that it includes, built into it, some functionality that is associated
> with the operating system on conventional architectures. So it will have to
> figure out how much memory is available to it on startup, for example... or
> maybe it will just have a lot of reserved locations in low memory addresses,
> which would be more conventional, instead of trying to put that stuff at the
> high end of memory.

You make it much more complicated than it really is, in part because you 
are thinking memory and the Mill works with address spaces.

Hardware doesn't allocate memory and thereby have to deal with 
configuration issues, neither at startup or in operation; hardware 
doesn't do heaps well. Hardware *does* allocate address spaces, or at 
least it statically knows those it needs for function, but address space 
is immutable per member so there's no configuration, and the spaces the 
hardware knows about are static and never returned, so there's no heap. 
Think of those systems that used one address bit for OS access 
permission - half of the static address space was known to the hardware, 
but no configuration was required.

The boot ROM does supply some info, for example where the system MMIO 
block lives, and the BIOS entry point, but that's true of every chip.

There will be another talk about all this coming up when we can get to it.

[toc] | [prev] | [next] | [standalone]

#25703

On Friday, December 12, 2014 12:31:36 PM UTC-7, Ivan Godard wrote:
> Beyond that, we have put a lot of 
> effort into making the Mill ISA optimization-proof. When code can be 
> optimized it means that the architecture design was lacking IMO, YMMV.

Now this is an interesting perspective.

Generally speaking, the conventional way of thinking of computer architectures 
is that they present the hardware to the programmer. If it's well designed, the 
programmer has an opportunity to get lots of performance out of the hardware - 
but that it's possible to get things wrong, and that there's a right way of 
using a given computer, is only reasonable.

But that is partly thinking from the "old days" - specifically, before the IBM 
360 came along, and ended the pattern of having a different ISA for each new 
machine, specifically designed for that machine's hardware.

For a compiler to do things once, rather than chip hardware to do the same 
things on every loop iteration, seems to make sense. I've recently learned, I 
think, that why current RISC architectures are the way they are, including 
some, but not all, features of the original RISC model, is that they are 
oriented towards removing the need for out-of-order execution.

But many RISC chips have OOO implementations now, and that is, I think, not a 
contradiction of my conclusiion - instead, it's that a RISC design makes it 
possible to avoid OOO for a given number of pipeline stages; if you have more 
pipeline stages, then you don't have enough registers to avoid the need for OOO 
any more.

Since the Mill transforms its code once - at load time - to its internal model-
dependent code, it avoids that particular bit of wastefulness associated with 
OOO.

John Savard

[toc] | [prev] | [next] | [standalone]

#25708

On 12/12/2014 2:54 PM, Quadibloc wrote:
> On Friday, December 12, 2014 12:31:36 PM UTC-7, Ivan Godard wrote:
>> Beyond that, we have put a lot of
>> effort into making the Mill ISA optimization-proof. When code can be
>> optimized it means that the architecture design was lacking IMO, YMMV.
>
> Now this is an interesting perspective.
>
> Generally speaking, the conventional way of thinking of computer architectures
> is that they present the hardware to the programmer. If it's well designed, the
> programmer has an opportunity to get lots of performance out of the hardware -
> but that it's possible to get things wrong, and that there's a right way of
> using a given computer, is only reasonable.
>
> But that is partly thinking from the "old days" - specifically, before the IBM
> 360 came along, and ended the pattern of having a different ISA for each new
> machine, specifically designed for that machine's hardware.
>
> For a compiler to do things once, rather than chip hardware to do the same
> things on every loop iteration, seems to make sense. I've recently learned, I
> think, that why current RISC architectures are the way they are, including
> some, but not all, features of the original RISC model, is that they are
> oriented towards removing the need for out-of-order execution.
>
> But many RISC chips have OOO implementations now, and that is, I think, not a
> contradiction of my conclusiion - instead, it's that a RISC design makes it
> possible to avoid OOO for a given number of pipeline stages; if you have more
> pipeline stages, then you don't have enough registers to avoid the need for OOO
> any more.
>
> Since the Mill transforms its code once - at load time - to its internal model-
> dependent code, it avoids that particular bit of wastefulness associated with
> OOO.
>
> John Savard
>

Another way to look at my viewpoint is to sat that ISAs should directly 
match what HLLs actually do, before compilation removes all the 
structure that was present in the original program. That is, for each 
construct that is a primitive in the (union of all) HLL, there should be 
one machine operation that does that primitive. Optimization is neither 
necessary nor useful.

I use our call operation as an example: if the program contains 
"F(a,b,c)", you get the machine code "call(f,a,b,c)". What else would 
you want? Why should you deal with things like stack pointers and 
register saving?

Yes, HLLs vary in their selection of primitives, and the ISA designer 
has to make sure that the ISA machine primitives don't leave some HLL in 
the lurch. But at the primitive level HLLs are far more similar than 
different, and the differences tend to be things that have to be done by 
the RTS anyway because they are too complex to move to hardware.

[toc] | [prev] | [next] | [standalone]

#25713

On Fri, 12 Dec 2014 17:11:29 -0800
Ivan Godard <ivan@ootbcomp.com> wrote:

> On 12/12/2014 2:54 PM, Quadibloc wrote:
> > On Friday, December 12, 2014 12:31:36 PM UTC-7, Ivan Godard wrote:
> >> Beyond that, we have put a lot of
> >> effort into making the Mill ISA optimization-proof. When code can
> >> be optimized it means that the architecture design was lacking
> >> IMO, YMMV.
> >
> > Now this is an interesting perspective.
> >
> > Generally speaking, the conventional way of thinking of computer
> > architectures is that they present the hardware to the programmer.
> > If it's well designed, the programmer has an opportunity to get
> > lots of performance out of the hardware - but that it's possible to
> > get things wrong, and that there's a right way of using a given
> > computer, is only reasonable.
> >
> > But that is partly thinking from the "old days" - specifically,
> > before the IBM 360 came along, and ended the pattern of having a
> > different ISA for each new machine, specifically designed for that
> > machine's hardware.
> >
> > For a compiler to do things once, rather than chip hardware to do
> > the same things on every loop iteration, seems to make sense. I've
> > recently learned, I think, that why current RISC architectures are
> > the way they are, including some, but not all, features of the
> > original RISC model, is that they are oriented towards removing the
> > need for out-of-order execution.
> >
> > But many RISC chips have OOO implementations now, and that is, I
> > think, not a contradiction of my conclusiion - instead, it's that a
> > RISC design makes it possible to avoid OOO for a given number of
> > pipeline stages; if you have more pipeline stages, then you don't
> > have enough registers to avoid the need for OOO any more.
> >
> > Since the Mill transforms its code once - at load time - to its
> > internal model- dependent code, it avoids that particular bit of
> > wastefulness associated with OOO.
> >
> > John Savard
> >
> 
> Another way to look at my viewpoint is to sat that ISAs should
> directly match what HLLs actually do, before compilation removes all
> the structure that was present in the original program. That is, for
> each construct that is a primitive in the (union of all) HLL, there
> should be one machine operation that does that primitive.
> Optimization is neither necessary nor useful.
> 
> I use our call operation as an example: if the program contains 
> "F(a,b,c)", you get the machine code "call(f,a,b,c)". What else would 
> you want? Why should you deal with things like stack pointers and 
> register saving?

Nice. I cannot imagine doing it without register saving in stack :p

> 
> Yes, HLLs vary in their selection of primitives, and the ISA designer 
> has to make sure that the ISA machine primitives don't leave some HLL
> in the lurch. But at the primitive level HLLs are far more similar
> than different, and the differences tend to be things that have to be
> done by the RTS anyway because they are too complex to move to
> hardware.

Well, there will be ABI? (if not already) and all HLL's honor ABI,
therefore not a problem.
Is there a plan to make something like qemu for Mill so that people
can at least write assembler (and test) for it? 

[toc] | [prev] | [next] | [standalone]

#25715

On 12/12/2014 7:36 PM, Melzzzzz wrote:

>> Yes, HLLs vary in their selection of primitives, and the ISA designer
>> has to make sure that the ISA machine primitives don't leave some HLL
>> in the lurch. But at the primitive level HLLs are far more similar
>> than different, and the differences tend to be things that have to be
>> done by the RTS anyway because they are too complex to move to
>> hardware.
>
> Well, there will be ABI? (if not already) and all HLL's honor ABI,
> therefore not a problem.
> Is there a plan to make something like qemu for Mill so that people
> can at least write assembler (and test) for it?
>

There is an ABI, although I expect it will get tweaked as we port bigger 
programs and people bring up "bit <language X> needs to be able to,,,"

There won't be a Qemu, or at least I don't expect so. Qemu would totally 
choke on Mill code :-) However the sim and tool chain will be made 
available as soon as everything they disclose that's still NYF gets filed.

[toc] | [prev] | [standalone]

Back to top | Article view | comp.arch

csiph-web