9fans - fans of the OS Plan 9 from Bell Labs
 help / color / mirror / Atom feed
From: Kenny Lasse Hoff Levinsen <kennylevinsen@gmail.com>
To: Fans of the OS Plan 9 from Bell Labs <9fans@9fans.net>
Subject: Re: [9fans] Go: FP in note handler
Date: Tue, 23 Feb 2016 16:52:32 +0100	[thread overview]
Message-ID: <68D3A127-CECA-4E8D-951F-756992D11710@gmail.com> (raw)
In-Reply-To: <45fced5cac8155366565f0195c0b47b9@lilly.quanstro.net>

A benchmark was supposedly made of the new duffcopy/duffzero which claimed significant speedup for larger copies: https://github.com/golang/go/commit/5cf281a9b791f0f10efd1574934cbb19ea1b33da

I have no clue whether this holds true or not. My intention to reenable duffcopy and continue to use duffzero is mostly to avoid differences and ensure that the note handlers are floating point free in the future. Whether the duffcopy/duffzero’s current form is an actual optimization or just a complexity, I cannot say. A test was made in #cat-v out of annoyance where the result seemed to be that it was indeed faster to use MOVUPS, but I don’t remember the details.

Best regards,
Kenny Levinsen

> On 23 Feb 2016, at 16:27, erik quanstrom <quanstro@quanstro.net> wrote:
> 
> On Tue Feb 23 02:36:41 PST 2016, kennylevinsen@gmail.com wrote:
>> Ah, no - it is not a system-wide adjustment, but adjustment of the plan9 specific runtime.sighandler implementation and everything called by it directly. Notes that don't exit the process are queued and should run outside the actual note handler.
>> 
>> I think the "magic" code will be isolated, and might fend off accidental future additions of floating point registers. The magic-ness also only revolves around avoiding duffzero and duffcopy in some way. I also think that removing conditionals in the compiler will be a positive thing.
>> 
>> I still do not know the feasibility of my plan, whether it is possible to do cleanly, or possible at all. Maybe someone smarter than me with knowledge on the matter could chime in and call me an idiot?
>> 
>> Avoiding duffcopy should be easy with a simple memmove implementation. If done right, we can also remove the plan9 specific runtime.memmove and only use the slow memmove in sighandler (The globlal runtime.memmove is implemented using MOVUPS just like duffcopy. Duffcopy is used for blockcopies by the compiler in some cases, although I must admit to not know all the cases yet).
>> 
>> Avoiding duffzero without compiler assistance is a bit more tricky - global variables, stack on assembly functions, something like that.
> 
> fwiw, on modern amd64 machines, using the xmm and ymm registers has a benefit only in a narrow range
> of sizes (384-511 bytes) and a subset of (mis-)alignments that i've forgotten.  at least for the exact test setup
> i used on 3-4 different µarches.  intel claims rep; movs is the (architecturally) fastest way to go.
> 
> i am not sure any of this makes much difference, as it's hard to know what a real-world memory
> access pattern looks like, and that seems to dominate all but gigantic moves, for which rep; movs
> is actually no slower than even the trickiest use of ymm registers.
> 
> - erik
> 




  reply	other threads:[~2016-02-23 15:52 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <e115154c5bab8971d7b88f64ba5d4402@proxima.alt.za>
2016-02-23 10:17 ` Kenny Lasse Hoff Levinsen
2016-02-23 15:27   ` erik quanstrom
2016-02-23 15:52     ` Kenny Lasse Hoff Levinsen [this message]
2016-02-23 17:02       ` erik quanstrom
2016-02-23 17:14         ` Kenny Lasse Hoff Levinsen
2016-02-23 17:31           ` lucio
2016-02-23 17:56             ` Kenny Lasse Hoff Levinsen
     [not found] <83031ee52a34de15facd95dcbcabbad9@proxima.alt.za>
2016-02-23  8:26 ` Kenny Lasse Hoff Levinsen
     [not found] <fb16aa69c6b73a2e8f0260b4e6ee025c@hamnavoe.com>
2016-02-22 21:56 ` Kenny Lasse Hoff Levinsen

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=68D3A127-CECA-4E8D-951F-756992D11710@gmail.com \
    --to=kennylevinsen@gmail.com \
    --cc=9fans@9fans.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).