> This is an amazing piece of work, congratulations!
Thanks! I appreciate it.
> The first part has a very nice introduction to the Factor language and
> compiler implementation too.
Glad you think so.
> I wonder if the performance regressions were due to increased register
> pressure? Factor's linear scan is pretty crappy compared to contemporary
> implementations in LLVM and LuaJIT.
The thought had crossed my mind, though I'm not sure if that would explain the
difference between my Pentium 4 and Core 2 results. Suppose we'd have to
verify benchmarks on various machines.
There was something else I noticed after looking at some of the results on
larger CFGs. I'm thinking there could be issues with expressions that have
canonical leaders that aren't available in later blocks. Like in the
following, the canonical leader of the value 100 is defined in an unfoldable
branch, so vregs 5 and 6 aren't converted into copies in block 4---not even
just copies of the definitely-available vreg 4, though they all have the same
value number. Have to eventually rewrite the redundancy elimination to search
for available registers that compute the same value number, instead of just
relying on the availability of the canonical leader.
```
V{ T{ ##branch } } 0 test-bb
V{
T{ ##inc-d { n -1 } }
T{ ##peek { dst 1 } { loc D -1 } }
T{ ##compare-imm-branch { src1 1 } { src2 f } { cc cc/= } }
} 1 test-bb
V{
T{ ##inc-d { n 1 } }
T{ ##load-integer { dst 2 } { val 100 } }
T{ ##branch }
} 2 test-bb
V{
T{ ##inc-d { n 1 } }
T{ ##load-integer { dst 3 } { val 200 } }
T{ ##branch }
} 3 test-bb
V{
T{ ##load-integer { dst 4 } { val 100 } }
T{ ##load-integer { dst 5 } { val 100 } }
T{ ##load-integer { dst 6 } { val 100 } }
} 4 test-bb
test-diamond
```
Regards,
--Alex Vondrak
________________________________________
From: Slava Pestov [sl...@factorcode.org]
Sent: Saturday, August 04, 2012 12:42 AM
To: factor-talk@lists.sourceforge.net
Subject: Re: [Factor-talk] Global Value Numbering
This is an amazing piece of work, congratulations!
The first part has a very nice introduction to the Factor language and compiler
implementation too.
I wonder if the performance regressions were due to increased register
pressure? Factor's linear scan is pretty crappy compared to contemporary
implementations in LLVM and LuaJIT.
Doug and John are the current maintainers, I think they should probably merge
this in after the release they're planning. Or was that supposed to be a secret
:-)
On Fri, Aug 3, 2012 at 6:52 PM, Alexander J. Vondrak
<ajvond...@csupomona.edu<mailto:ajvond...@csupomona.edu>> wrote:
http://weknowmemes.com/wp-content/uploads/2012/01/op-will-surely-deliver-lets-just-wait.jpg
Yes, I did actually work on the GVN pass---even got my master's degree. After
finally defending my thesis (available at https://github.com/ajvondrak/thesis),
I started a teaching job at my university, which proved to be a lot of work.
Thus, I didn't find time to clean up the issues I wanted to fix before pushing
this to the public. But it's been a long time, and I figured I should actually
put *something* out one way or another.
So, here it is: https://github.com/ajvondrak/factor/tree/gvn
Right now, the global value numbering pass lives in extra/compiler/cfg/gvn,
thus you can simply switch out the USING: in compiler.cfg.optimizer to give it
a whirl. Now that it's summer, I hope to be able to work on the broken parts
some more. To wit,
* I never updated the old value-numbering unit tests, so gvn-tests will fail
(whether because the global optimization changes test outcomes or just
because of the tweaked interface).
* The same tests that fail on my personal machine [1] from a load-all
test-all without GVN still fail using GVN. The only previously-passing
tests that now fail unexpectedly were in math.vectors.simd (memory
protection faults), so there's something buggy going on with SIMD stuff.
(This failure isn't mentioned in the thesis because I hadn't done a
load-all back then.)
Otherwise, the work seems interesting, if nothing else:
* My thesis lends some documentation to the project, I hope.
* With GVN, Factor still bootstraps in about the same amount of time.
* The GVN pass should, ideally, replace the compiler.cfg.copy-prop pass.
* When I ran them for my thesis a year ago, the benchmarks showed some
impressive improvements across the board (summarized in the PDF). These
were run on my old single-core 3.2 GHz Pentium 4 machine with 2 GB RAM,
running Debian (testing). Nowadays, on my 2.83 GHz Intel Core 2 Quad with
8 GB RAM, I get more erratic / less dramatic results. Not sure why, but
it'd probably be interesting to find out.
Factor code has been a pleasure to work with. Hope these changes are worth
anything.
Thanks,
--Alex Vondrak
[1] Most of the failures were from DLLs I didn't have installed (libpq.so,
libsqlite3.so, libudis86.so.0, libncursesw.so, and libblas.so for tests in db,
furnace, site-watcher, webapps.mason.backend, math.blas.matrices,
math.blas.vectors, tools.disassembler, and curses). Other than that, some http
tests failed with 500 errors (expecting 404s), io.launcher.unix had a killed
process, and memcached tests fail with Connection refused (111). Nothing that
seems like a big deal.
------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
Factor-talk mailing list
Factor-talk@lists.sourceforge.net<mailto:Factor-talk@lists.sourceforge.net>
https://lists.sourceforge.net/lists/listinfo/factor-talk
------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
Factor-talk mailing list
Factor-talk@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/factor-talk
