This is pretty OT, and I am no expert, but the overwhelming consensus on 
the inter-tubes seems to be that *reading *from an SSD causes no 'wear' 
whatsoever. It is only writes and deletes that age an SSD. So this use case 
should not impact SSD life. 

But it is an interesting endeavor on its own. 
On Sunday, January 29, 2023 at 1:01:42 AM UTC-5 ren...@ix.netcom.com wrote:

> Shared dynamic libraries do reduce the “wear and tear” on an SSD.  The 
> binaries are loaded a single time and shared across processes - slightly 
> longer startup times for the dynamic linkage. 
>
> It is highly beneficial with large runtimes vs small standard library 
> usage in tiny utilities.  
>
> On Jan 28, 2023, at 10:46 PM, Kurtis Rader <kra...@skepticism.us> wrote:
>
> 
>
> It does not surprise me that your shared run-time build takes more time 
> than the usual static build. The latter case is highly optimized while your 
> use case has probably been given very little consideration. I am also 
> confused by your argument for supporting linking against a shared Go 
> runtime library. You wrote earlier that the reason you want this is to 
> "reduce ware (sic) and tear on my SSD." I see no reason why linking against 
> a shared Go run-time library would reduce the "wear and tear" on your SSD. 
> I think your premise is flawed.
>
> On Sat, Jan 28, 2023 at 8:29 PM jlfo...@berkeley.edu <jlfo...@berkeley.edu> 
> wrote:
>
>> Thanks for the reply. I had mixed results.
>>
>> On Fedora 37, go version go1.19.4 linux/amd64, in /usr/local/go/src as 
>> root I ran
>>
>> go install -buildmode=shared std
>>
>> That seemed to work.
>>
>> In my normal working directory, as me, not root, I ran
>>
>> go build -linkshared *.go
>>
>> (I do a regular build in this directory by just running "go build *.go")
>>
>> That resulted in a whole bunch of error messages of the style
>>
>> go build internal/goarch: copying /tmp/go-build2481653269/b006/_pkg_.a: 
>> open /usr/local/go/pkg/linux_amd64_dynlink/internal/goarch.a: permission 
>> denied
>>
>> So I became root and ran go build -linkshared *.go again.
>>
>> This time it worked!! The result was 83584 byte binary, whereas the 
>> binary produced 
>> by the standard method is 4186764 bytes. That's a great savings!!! The 
>> small binary seemed
>> to work fine.
>>
>> Just for yuks, I tried building my program as me again (not root). I got 
>> permission error messages
>> again, but now they look like
>>
>> open /usr/local/go/pkg/linux_amd64_dynlink/archive/tar.shlibname: 
>> permission denied
>>
>> There are 238 such lines.
>>
>> There's another problem. Unlike what I would expect, it takes *longer* to 
>> build the shared version
>> than the static version.
>>
>> As root
>>
>> [root@localhost]# time go build *.go
>>
>> real    0m0.298s
>> user    0m0.346s
>> sys     0m0.091s
>>
>> [root@localhost]# time go build -linkshared *.go
>>
>> real    0m1.441s
>> user    0m1.193s
>> sys     0m0.325s
>>
>> That doesn't seem right.
>>
>> Any advice?
>>
>> Cordially,
>> Jon Forrest
>>
>> On Saturday, January 28, 2023 at 7:51:25 PM UTC-8 Ian Lance Taylor wrote:
>>
>>> On Sat, Jan 28, 2023 at 11:27 AM jlfo...@berkeley.edu 
>>> <jlfo...@berkeley.edu> wrote: 
>>> > 
>>> > For people like me who have no intention of ever distributing a Go 
>>> executable, I wonder 
>>> > if it would be useful, and possible, to link to a shared library 
>>> version of the Go 
>>> > Runtime. This would make my binaries much smaller and would reduce 
>>> ware and 
>>> > tear on my SSD. 
>>> > 
>>> > Of course, this presumes that such a shared library could be created 
>>> in the first place. 
>>> > 
>>> > I did a quick Google and I didn't find this issue being previously 
>>> discussed. 
>>> > 
>>> > Comments? 
>>>
>>> At least on Linux systems it should work to run "go install 
>>> -buildmode=shared std" and then to build other Go programs with 
>>> "-linkshared". 
>>>
>>> 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...@googlegroups.com.
>> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/golang-nuts/4dc94780-06e6-4aa3-a9b1-64b97dd85a5en%40googlegroups.com
>>  
>> <https://groups.google.com/d/msgid/golang-nuts/4dc94780-06e6-4aa3-a9b1-64b97dd85a5en%40googlegroups.com?utm_medium=email&utm_source=footer>
>> .
>>
>
>
> -- 
> Kurtis Rader
> Caretaker of the exceptional canines Junior and Hank
>
> -- 
> 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...@googlegroups.com.
>
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/golang-nuts/CABx2%3DD-SBB%3DvFGYUGaXpf-8m6RH4HK4xEKjGUdMXMwjK90NMPg%40mail.gmail.com
>  
> <https://groups.google.com/d/msgid/golang-nuts/CABx2%3DD-SBB%3DvFGYUGaXpf-8m6RH4HK4xEKjGUdMXMwjK90NMPg%40mail.gmail.com?utm_medium=email&utm_source=footer>
> .
>
>

-- 
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/6738f823-336d-41e0-81cf-716148becc6dn%40googlegroups.com.

Reply via email to