Inline:
On Saturday, November 11, 2017 at 2:52:30 PM UTC-5, Dave Cheney wrote:
>
> Hi,
>
> Thanks for following up here.
>
>
>
> On Sunday, 12 November 2017 03:35:27 UTC+11, Petar Maymounkov wrote:
>>
>> Consider a chain of functions that call each other:
>>
>>
>> func f1(x X) { ... f2(y) ... }
>> func f2(y Y) { ... f3(z) ... }
>> and so on.
>>
>>
>> Assume also that their arguments and return values are static Go types
>> (no interfaces).
>>
>>
>> Generally, such a chain of statically-typed invocations will fall within
>> the domain of the SSA optimizer and will be rewritten (theoretically)
>> optimally.
>>
>
> What do these functions do? Can how show some working examples? What do
> you mean by rewritten?
>
We have a system that code-generates a Go simulator for large
microprocessor circuits (> 1M gates and subsystems).
Both hardware gates and subsystems are represented as Go functions with
statically-typed arguments and return values.
Subsystems use/call each other (the recursion).
As is, if we want to benefit from code optimization, we need to
code-generate the whole micro-processor in one package.
This produces millions of functions per package.
>
>
>>
>> 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) ... }
>>
>>
>> and the user desires to implement f1 and f3 in different packages.
>>
>>
>> This is not possible due to the design of the packaging system (as the
>> packages of f1 and f3 would have to import each other).
>>
>> Consequently, large amounts of recursive code cannot be spread across
>> packages.
>>
>>
>> This situation has arisen in practice for us at a pretty large scale
>> (many/long recursive chains).
>>
>>
>> I am wondering a couple of things:
>>
>> (a) Is there any technical consideration prohibiting large-scale SSA,
>>
>
> There are lots of phases in the compiler, SSA occurs relatively late in
> the process, and the one that's probably more relevant here is inlining.
> Inlining does work across package boundaries, exported functions from one
> package aren't supposed to be treated differently from functions in
> another, although there could always be a bug. This is where a practical
> example of what problem you're facing would be really helpful.
>
SSA as an algorithmic technology applies to chains of static calls
regardless of packaging considerations. (Inlining is a special case of SSA.)
Whether Go/LLVM implement/apply SSA to its full potential is something I
don't know. Hence the question.
>
>
>> (b) Is there any technical consideration prohibiting go packages from
>> importing each other.
>>
>
> The prohibition on import loops exists because it would significantly
> complicate the type checking of the compiler and the package import/export
> mechanism. it's also just not a good idea from a program design point of
> view as circular imports often denote high coupling which limit isolation
> and effective code reuse.
>
I personally disagree with all considerations stated. But to keep my
question practical:
I am simply wondering whether the Go compiler is designed to handle
packages with ~10M static functions,
which invoke each other in cyclical ways.
>
>
>>
>>
>> Thank you.
>>
>>
>>
--
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.
