Related: #8893

They should probably also be scheduled concurrently with the compilation of the package. On my machine, compiling the math package (which is a bottleneck) takes 200ms, and occurs entirely before the assembler kicks in.

See https://gist.github.com/josharian/d6bd51c4afd431bcbaee49deff0b2be3 for some raw output (generated with https://github.com/josharian/cmdgosnoop, which is work in progress). The format is: timestamp, number of concurrent jobs, list of concurrent jobs. A new line is started every time a job begins or ends.

They should probably also be scheduled concurrently with the compilation of the package. On my machine, compiling the math package (which is a bottleneck) takes 200ms, and occurs entirely before the assembler kicks in.

You can't do that in general because of -asmhdr.

Ah. It looks like that's just set when compiling the runtime package. Is that right?

It seems to only be used when the runtime package is being compiled, but
the flag is passed and the header generated whenever there are assembly
files in the package.

On 17 May 2016 at 10:57, Josh Bleecher Snyder notifications@github.com
wrote:

Ah. It looks like that's just set when compiling the runtime package. Is
that right?

—
You are receiving this because you commented.
Reply to this email directly or view it on GitHub
#15680 (comment)

I don't think that flag is a problem, go_asm.h is generated by cmd/dist,
and should always be present on disk before building the runtime. As almost
everthing depends on the runtime package, there shouldn't be any reason
asm's cannot be run in parallel (gb runs them in parallel)

On Tue, May 17, 2016 at 9:16 AM, Michael Hudson-Doyle <
notifications@github.com> wrote:

It seems to only be used when the runtime package is being compiled, but
the flag is passed and the header generated whenever there are assembly
files in the package.

On 17 May 2016 at 10:57, Josh Bleecher Snyder notifications@github.com
wrote:

Ah. It looks like that's just set when compiling the runtime package. Is
that right?

—
You are receiving this because you commented.
Reply to this email directly or view it on GitHub
#15680 (comment)

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub
#15680 (comment)

On Tue, May 17, 2016 at 4:38 AM, Dave Cheney notifications@github.com
wrote:

I don't think that flag is a problem, go_asm.h is generated by cmd/dist,
and should always be present on disk before building the runtime. As almost
everthing depends on the runtime package, there shouldn't be any reason
asm's cannot be run in parallel (gb runs them in parallel)

go_asm.h is generated by "go tool compile" for the package that is being
compiled. Watch "go build -x math" for details.

It's true that the only std package that uses such facilities is the
runtime,
but in general, we can't compile the assembly files before building the
Go code for that package.

A better plan here might be teaching the assembler to accept and process multiple asm files in a single invocation. Looking into the timing, it appears that the exec (and command preparation) overhead easily matches or outweighs the time spent in the actual assembler.

That certainly sounds worth investigating. Might be nice if it could just
make a single .o file too.

On 18 May 2016 at 07:46, Josh Bleecher Snyder notifications@github.com
wrote:

A better plan here might be teaching the assembler to accept and process
multiple asm files in a single invocation. Looking into the timing, it
appears that the exec (and command preparation) overhead easily matches or
outweighs the time spent in the actual assembler.

—
You are receiving this because you commented.
Reply to this email directly or view it on GitHub
#15680 (comment)

I now have better ideas for bigger wins. Nevertheless, implemented this; straightforward and easy. Will mail for 1.8.

CL https://golang.org/cl/27636 mentions this issue.

CL https://golang.org/cl/34284 mentions this issue.

The effect of this was rolled back by CL 34284, which changed cmd/go to pass .s files to cmd/asm one at a time. When the assembler is fixed so that the test added by that CL passes, then the non-test part of the CL can be rolled back and this issue will be fixed again.

As I wrote in #19277:

If we want to allow the assembler to process multiple files then we would need to do this.
But I don't think it's particularly important for the assembler to process multiple files:
it is fine to continue to call it once per file, and then this bug, and all other similar
bugs where files are not treated truly independently, will be impossible.
That really seems like the best strategy.
Having any assembly files is rare; having many is even rarer. Not worth the trouble.