FAQ
First, I'd like to note that I'm not excessively experienced with x86-64
Intel assembly. I'm mostly doing all of my work as learning, so it's almost
certain I'm doing something dumb. I decided to try some SIMD. I've had
success implementing constant-sized vectors and matrices. I decided to try
something a little more complicated for fun/challenge.

I decided to implement a few basic functions from gonum/floats
<https://github.com/gonum/floats/blob/master/floats.go> with SIMD, since it
seemed like a "step up" from constant-sized vectors to variable-sized
slices of floats. I'm having some very bizarre "context-dependent" issues,
though. The code in question is in a gist <https://gist.github.com/> I just
created, with several commented out sections. Uncommenting any of them, or
running benchmarks will cause a crash on my machine.

For reference, the function signature is

func(dst []float64, slices [][]float64)

(It used to be func(dst []float64, slices ...[]float64), but go vet
complained about that with assembly).

The odd thing is, oftentimes it works fine. The tests ran fine. But when I
started to benchmark it, things started going awry. That's when I found
several very specific types of code that cause it to crash:

1. Any calls involving a package-level slice variable
2. Any copies of those slices into a temporary local variable created with
make
3. Amending the code of the wrapper to anything other than a passthrough
(adding an if-statement or print statement to the wrapper before the call)

[Note: the specific stack traces/panics are in the gist; in addition, there
are a couple errors I got last night that I can't recreate that complained
about split stack boundaries and a couple that outright caused Windows
itself to give me the good ol' "this program has stopped working" error box]

I eventually tracked down that it also always fails (even the tests that
normally work) if I disable compiler optimizations with gcflags="-N"

The line that generally fails is:

MOVUPD 0(DX), X2

Which (assuming I didn't do anything horribly wrong) is essentially
equivalent to

var tmp [2]float32 := [2]float32{slices[i][j], slices[i][j+1]}

In other words, loading two values from a specific slice in a slice of
slices. (Except it's a SIMD load into a register rather than a vector
populated with two calls to MOVSD)

I'd be inclined to think it's an off-by-one error if the test-cases didn't
all work properly. In addition, if I decrease the loop value (CX) by 1, it
fails the way I would expect it to if the program were correct (adding
fewer values or slices than normal).

I'm on Windows amd64, Go 1.3.

I'm probably doing something horribly wrong, but I'm really curious what
the problem is and it's driving me crazy. Is it the pointer arithmetic in
the assembly? Should I reload the pointers from the stack every loop
iteration instead of keeping the values in registers? (I could see it
interfering with the new GC given how unsafe uintptr now is).

--
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+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Search Discussions

  • Ian Lance Taylor at Sep 16, 2014 at 12:23 am

    On Mon, Sep 15, 2014 at 4:58 PM, Jsor wrote:
    The line that generally fails is:

    MOVUPD 0(DX), X2

    Which (assuming I didn't do anything horribly wrong) is essentially
    equivalent to

    var tmp [2]float32 := [2]float32{slices[i][j], slices[i][j+1]}
    I haven't looked at your code and I have no idea what the actual
    problem is, but I want to note that MOVUPD works with a pair of
    float64 values, not float32.

    Ian

    --
    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+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/d/optout.
  • Jeff Juozapaitis at Sep 16, 2014 at 12:31 am
    Oops, sorry, the function signature was for float64s. I'm just so used to
    working with float32 code I did it by habit in the post.
    On Mon, Sep 15, 2014 at 5:23 PM, Ian Lance Taylor wrote:
    On Mon, Sep 15, 2014 at 4:58 PM, Jsor wrote:

    The line that generally fails is:

    MOVUPD 0(DX), X2

    Which (assuming I didn't do anything horribly wrong) is essentially
    equivalent to

    var tmp [2]float32 := [2]float32{slices[i][j], slices[i][j+1]}
    I haven't looked at your code and I have no idea what the actual
    problem is, but I want to note that MOVUPD works with a pair of
    float64 values, not float32.

    Ian
    --
    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+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/d/optout.
  • Michael Jones at Sep 16, 2014 at 12:33 am
    Also be careful about potential alignment restrictions.
    On Sep 15, 2014 5:23 PM, "Ian Lance Taylor" wrote:
    On Mon, Sep 15, 2014 at 4:58 PM, Jsor wrote:

    The line that generally fails is:

    MOVUPD 0(DX), X2

    Which (assuming I didn't do anything horribly wrong) is essentially
    equivalent to

    var tmp [2]float32 := [2]float32{slices[i][j], slices[i][j+1]}
    I haven't looked at your code and I have no idea what the actual
    problem is, but I want to note that MOVUPD works with a pair of
    float64 values, not float32.

    Ian

    --
    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+unsubscribe@googlegroups.com.
    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+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/d/optout.
  • Jeff Juozapaitis at Sep 16, 2014 at 12:44 am
    The link you provided is to gist.github.com, not to a particular gist.
    Oops
    https://gist.github.com/Jragonmiris/157db08374555e856865
    On Mon, Sep 15, 2014 at 4:58 PM, Jsor wrote:
    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
    --
    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+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/d/optout.

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
groupgolang-nuts @
categoriesgo
postedSep 15, '14 at 11:58p
activeSep 16, '14 at 12:44a
posts5
users3
websitegolang.org

People

Translate

site design / logo © 2021 Grokbase