Hi Keith, > The stdlib is organized to take advantage of hardware instructions when they are available and falls back to portable Go code when they aren't. You actually answered my question == the ASM is the latest optimization direction. So the desgin sequences are always:
1. Pure software solution first 2. Abstract some Step #1 and then optimize parts of it to ASM when resources permits / requirement requires The reason I'm asking is to make sure I'm won't end up like "Go vs cGo" case where the efforts are always pure Go whenever possible and only use cGo in absolute no-choice situation. > It sounds to me like you're more interested in portability, so I suggest you just use the portable code (e.g. promote `floor` to `Floor` and get rid of all the other wrapping code (the existing `Floor`, `haveArchFloor`, `archFloor`, the .s files, etc.). Nahh, I'm not going to throw away stable and tested codes. It's very rude considering these efforts were backed by a lot of research papers and efforts. The good news is that I managed to find a "zen" way with gobuild flags to calm my heart and head yesterday. What I did was to offer the portable Go codes and hardware accelerated one as 2 different API and it's up to the customer to decide (It's their design call anyway, not ours). Regards, Holloway On Friday, November 11, 2022 at 7:41:54 AM UTC+8 k...@google.com wrote: > I'm not sure exactly what the question is that you're asking here. "latest > and right optimization direction" doesn't make any sense to me. > > The stdlib is organized to take advantage of hardware instructions when > they are available and falls back to portable Go code when they aren't. > It sounds to me like you're more interested in portability, so I suggest > you just use the portable code (e.g. promote `floor` to `Floor` and > get rid of all the other wrapping code (the existing `Floor`, > `haveArchFloor`, `archFloor`, the .s files, etc.). > > On Wednesday, November 9, 2022 at 10:21:09 PM UTC-8 hollowa...@gmail.com > wrote: > >> Hi all, >> >> To clarify, which one is latest and right optimization development >> direction? >> >> >> Example case: >> >> (floor_asm.go <--> floor_amd64.s VS floor_noasm.go) >> >> 1) >> https://cs.opensource.google/go/go/+/refs/tags/go1.19.2:src/math/floor_asm.go;bpv=0;bpt=0 >> >> 2) >> https://cs.opensource.google/go/go/+/refs/tags/go1.19.2:src/math/floor_amd64.s;bpv=0;bpt=0 >> >> 3) >> https://cs.opensource.google/go/go/+/refs/tags/go1.19.2:src/math/floor.go;l=21;bpv=0;bpt=0 >> >> >> Context: >> >> 1) I'm currently adopt+modifying the standard library to facilitate >> TinyGo and translatable to Rust. => 1 peaceful standard library >> complementing the existing standard libraries. >> >> 2) The objective is support coverage (e.g. works on as many hardware as >> possible) over some performance sacrifice. >> >> >> 3) My heart tells me noasm.go is the latest because: >> >> 3.1) ultimately Go developer can achieve consistent results independnet >> of hardware; thus, does not restrict one to sell kidney for getting MYR10k+ >> hardware. TinyGo can operate with this at no issue (tested as well). >> >> 3.2) Heartbleed bug case proven that relying hardware can cause >> inconsistency results despite proper software. >> >> >> 4) My head tells me asm.go is the latest because: >> >> 4.1) why self-impose limits when hardware can perform better. >> >> >> Thanks in advanced. >> >> >> Regards, >> >> Holloway >> > -- 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+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/9e16ef35-1669-46ca-89e2-96a1952003b2n%40googlegroups.com.
