On Sunday, November 12, 2017 at 12:33:11 PM UTC-5, Jesper Louis Andersen
wrote:
>
> In addition to tail-call optimization, you also need a "contification"
> pass, which removes intermediate functions in the SSA basic blocks where
> possible. The observation is that if a function always returns to the same
> point, then it can be turned into a continuation, which is exactly what an
> SSA block is. Such a chain can then in certain situations be fused which in
> turn makes it easier to expose loop information in the SSA graph.
>
> However, considering Go's balance of producing fast compile times,
> extensive CF/DF analysis is probably out of bounds.
>
> My personal solution would be:
>
> 1. Get a machine with MASSIVE amounts of memory (initial bet: 128Gig and
> up)
> 2. CodeGen to the MLton compiler (mlton.org
> <http://www.google.com/url?q=http%3A%2F%2Fmlton.org&sa=D&sntz=1&usg=AFQjCNEjU72NMzqOCEDZwBG4RW1ofcXYeQ>
> )
> 3. Do a whole-program compilation. This might take several coffee breaks.
> 4. Enjoy the fastest simulator ever.
>
> However, for development you probably want something like SML/NJ because
> your lead time could be measured in hours.
>
> This is an interesting suggestion. But it makes me wonder how this
compares against generating directly a bag of LLVM statically-typed
functions
and trying the intelligence of the LLVM SSA optimizer. Do you know if this
one resorts to global analysis?
The SSA basically has to catch all cycles in the call graph. So this is a
global optimization process, but real world call graphs have "narrow width"
which makes global analysis fast over them in practice.
> Another path is to cheat in the simulator. Replace circuitry with
> hand-coded blocks (i.e., VLSI blocks) which doesn't simulate as much as
> they run. I remember we did this at university some 15 years ago in order
> to simulate circuits, because they would otherwise be too slow (mind you,
> 2000 hardware).
>
>
> On Sun, Nov 12, 2017 at 6:12 PM Bakul Shah <ba...@bitblocks.com
> <javascript:>> wrote:
>
>> On Nov 11, 2017, at 5:33 AM, Petar Maymounkov <pet...@gmail.com
>> <javascript:>> wrote:
>> >
>> > Generally, such a chain of statically-typed invocations will fall
>> within the domain of the SSA optimizer and will be rewritten
>> (theoretically) optimally.
>> >
>> >
>> >
>> > The issue arises when the invocation chain is recursive, e.g.
>> >
>> >
>> >
>> > func f1(x X) { ... f2(y) ... }
>> > func f2(y Y) { ... f3(z) ... }
>> > func f3(z Z) { ... f1(x) ... }
>>
>> Are you building a state-machine?
>>
>> Looks like what you really want is tail-call optimization....
>> I don't think Go implements this. I tested this with two
>> mutually recursive functions and the program ran out of stack
>> space. IMHO you are better off using another language or a
>> different scheme. For example, each function returns a
>> function and its args as a struct to a driver routine.
>>
>> func f1(x X)(Fn, Arg) { ... return f2, &Arg{y} ... }
>>
>> A driver (much like an interpreter main loop) based approch
>> will be somewhat slower.
>>
>> > (b) Is there any technical consideration prohibiting go packages from
>> importing each other.
>>
>> When I needed this I defined a common package that declared a
>> table and common types. Then each individual package added
>> its own entries to this table via their init() function. The
>> table can be a map or an array (in the latter case you'd have
>> to define a constant for each package globally, which makes it
>> less flexible).
>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "golang-nuts" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to golang-nuts...@googlegroups.com <javascript:>.
>> For more options, visit https://groups.google.com/d/optout.
>>
>
--
You received this message because you are subscribed to the Google Groups
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
