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/d66c39df-b433-4517-8098-2054d8c55b7an%40googlegroups.com.
