comments inline...

On Thu, Nov 1, 2012 at 10:30 AM, Job van der Zwan
On Thursday, 1 November 2012 17:28:51 UTC+1, Michael Jones wrote:


sp := &exact.stack[k]
columns = sp.columns
c = sp.c
r = sp.r
Wow, I never would have thought of doing something like that (including
the manual scoping). Do you have a blog or a summary page where you collect
micro-optimisations like this? Preferably with the reasoning that made you
discover them in the first place? It seems to be kind of your thing.
No. This is not something to "share" really as much as something to prod
the compiler writers with to allow a little bit more of the goodness from
IBM's Fortran-H compiler and the 50 years of research since into their
work. I have a different philosophy about this than they do, but I'm not
working on the compilers. ;-)

I think that a compiler is the tool to help me squeeze every picosecond of
needless expense. I have some research ideas of my own here but no agenda
to push. I just value the whole spectrum from simple and concise on the
human side of the tool chain to time and space efficiency on the machine

The way I thought of the braces was to add the code above sans-braces and
watch the performance drop by half, look at the generated code/profile, see
that a dreaded stack split has fallen where I can't afford it, and then try
to help the compiler realize shorter variable lifetimes with extra scoping
crutches. I do not want people to do this! I want the compiler to traverse
the expression tree BOTTOM UP and realize what can be reused. These are
early days yet and the compilers should get much better.

On Thursday, 1 November 2012 17:53:59 UTC+1, Peter wrote:

Is it necessarily slower?

A compiler could reasonably see that k is not changed and only do bounds
checking once.

Explicit and fast are both good Go principles :)
Do any of the Go compilers do any optimisations that involve avoiding
unnecessary bounds checking? And what do you consider reasonable? I
wouldn't expect this to be optimised:

columns = exact.stack[k].columns
c = exact.stack[k].c
r = exact.stack[k].r
If I gave you...

columns = exact.stack[k].columns
c = exact.stack[k].c
r = exact.stack[k].r

...and paid you to write it in assembler, I would expect you to compute the
address of exact.stack once, exact.stack[k] once, and do a range-check
once. If you did not, after representing yourself as a skilled coder with
deep knowledge of the machine, I would fire you. That's how I think of
compilers. They are the machine experts. They alone have the whole problem
before them (the user's code, the code "inside" for loops and switch
statements, the bounds checking code, the code for maps, etc.) They also
have the result of developer code and generated code, such as from M4 or
setter/getter automation. With all of this before them, and knowledge of
the machine, and much more, they [well, it] are in the best position to
know what is a common expression, what can be safely cached, what is less
expensive to recompute, if x*2 or x<<1 is faster, and much more. I think
this is the job.

But this seems a bit more likely to me:

columns, c, r = stack[k].columns, stack[k].c, stack[k].r

... since I think the evaluation of the left and right side could
reasonably be micro-optimised
Is not yet, but the future is limited only by vision.

P.S. The compiler writers know how to do this. They are just being careful
to keep all the code as clean and understandable as they can. Think "linux
v1." Magic here can happen later. I'm just impatient.
Michael T. Jones | Chief Technology Advocate | mtj@google.com | +1


Search Discussions

Discussion Posts


Follow ups

Related Discussions

Discussion Navigation
viewthread | post
posts ‹ prev | 20 of 22 | next ›
Discussion Overview
groupgolang-nuts @
postedOct 31, '12 at 9:15a
activeNov 2, '12 at 7:51a



site design / logo © 2021 Grokbase