Re: [go-nuts] Re: Why copy is much slower than append when clone a slice?
If Element was a pointer type, it would need to zero it first though, right? On Tuesday, June 27, 2017 at 8:11:01 PM UTC-7, Keith Randall wrote: > > This looks like it is all due to the extra zeroing required for the Copy > test. CloneWithAppend does not need to zero the newly allocated slice > before copying the contents of x into it. CloneWithCopy does. > > Benchmark_CloneWithAppend-4 3000480247 ns/op > Benchmark_CloneWithCopy-41000 1109543 ns/op > > If I hack the runtime to remove the no-zeroing-on-append optimization, the > performance difference disappears (it actually reverses): > > Benchmark_CloneWithAppend-4 1000 1443989 ns/op > Benchmark_CloneWithCopy-41000 1161912 ns/op > > I'm actually quite surprised that the differences seen here are so large. > I don't understand how it can be more than a factor of 2. Zeroing should > be no more expensive than copying. > If anyone has any idea why, let me know. > > > On Tuesday, June 27, 2017 at 7:04:33 PM UTC-7, Kevin Malachowski wrote: >> >> Hit send too early... Your benchmarks do show that something is strange >> hen comparing the make (memclr) and copy (memory copy) cases. Out of my >> element here :) >> >> On Jun 27, 2017 7:01 PM, "Kevin Malachowski" wrote: >> >>> But memclr+copy is slower than just copy, right? >>> >>> On Jun 27, 2017 6:53 PM, "T L" wrote: >>> On Tuesday, June 27, 2017 at 8:55:48 PM UTC-4, Kevin Malachowski wrote: > > It's best to compare the assembly, but my guess: 'make' has to zero > out the memory, whereas allocation using append does not. allocation using append will copy each element, which should be slower than memclr. -- You received this message because you are subscribed to a topic in the Google Groups "golang-nuts" group. To unsubscribe from this topic, visit https://groups.google.com/d/topic/golang-nuts/nDYYHKwvYhQ/unsubscribe. To unsubscribe from this group and all its topics, send an email to golang-nuts...@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+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[go-nuts] Re: bit twiddling API survey
Are bit rotations complied to single instructions? Specifically things like: var a uint32 (a << 5) | (a >> (32 - 5) On Monday, January 9, 2017 at 3:46:45 PM UTC-8, mo...@google.com wrote: > > Hello! > > I'm working on a proposal for a compiler/hardware supported bittwidling > API. See discussion at https://github.com/golang/go/issues/17373. The > current set of functions I have in mind are: count trailing zeros, count > leading zeros, byte swap and population count for 32 and 64 bits integers. > Which other functions do you thing should be in this API? What are the > popular packages that implement (even without exporting) a subset of these > functions? > > Regards, > > > -- 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. For more options, visit https://groups.google.com/d/optout.
[go-nuts] Re: float32 vs float64 precision lost when casting to int
Is this just due to IEEE754 rounding mode? I think the spec says round to even. On Wednesday, December 14, 2016 at 9:36:23 AM UTC-8, Mauro Trajber wrote: > > The float to int conversion behaves different for 32 and 64 precision. > https://play.golang.org/p/-zkCNSTbNa > > Is this the correct behavior? > > I'm using go version go1.7.4 linux/amd64 > -- 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. For more options, visit https://groups.google.com/d/optout.
[go-nuts] Re: memclr optimazation does worse?
Be wary of slice size, as caching is going to have an extremely strong
effect on the results. I submitted a CL that made append, only clear
memory that was not going to be overwritten
( https://github.com/golang/go/commit/c1e267cc734135a66af8a1a5015e572cbb598d44
). I thought this would have a much larger impact, but it only had a small
impact. memclr would zero the memory, but it also brought it into the
cache, where it was hot for being overwritten.
Have you tried running with perf to see dcache misses for each benchmark?
On Wednesday, December 14, 2016 at 6:12:08 AM UTC-8, T L wrote:
>
> I just read this issue thread: https://github.com/golang/go/issues/5373
> and this https://codereview.appspot.com/137880043
> which says:
>
> for i := range a {
> a[i] = [zero val]
> }
>
> will be replaced with memclr.
> I made some benchmarks, but the results are disappointing.
> When the length of slice/array is very large, memclr is slower.
>
> Result
>
> BenchmarkMemclr_100-4 137.2 ns/op
> BenchmarkLoop_100-4 170.7 ns/op
> BenchmarkMemclr_1000-4 2000 351 ns/op
> BenchmarkLoop_1000-41000 464 ns/op
> BenchmarkMemclr_1-4 100 3623 ns/op
> BenchmarkLoop_1-4100 4940 ns/op
> BenchmarkMemclr_10-4 10 49230 ns/op
> BenchmarkLoop_10-410 58761 ns/op
> BenchmarkMemclr_20-4 5 98165 ns/op
> BenchmarkLoop_20-4 5115833 ns/op
> BenchmarkMemclr_30-4 3170617 ns/op
> BenchmarkLoop_30-4 2190193 ns/op
> BenchmarkMemclr_40-4 2275676 ns/op
> BenchmarkLoop_40-4 2288729 ns/op
> BenchmarkMemclr_50-4 1410280 ns/op
> BenchmarkLoop_50-4 1416195 ns/op
> BenchmarkMemclr_100-4 5000 1025504 ns/op
> BenchmarkLoop_100-4 5000 1012198 ns/op
> BenchmarkMemclr_200-4 2000 2071861 ns/op
> BenchmarkLoop_200-4 2000 2032703 ns/op
>
> test code:
>
> package main
>
> import "testing"
>
> func memclr(a []int) {
> for i := range a {
> a[i] = 0
> }
> }
>
> func memsetLoop(a []int, v int) {
> for i := range a {
> a[i] = v
> }
> }
>
> var i = 0
>
> func BenchmarkMemclr_100(b *testing.B) {
> var a = make([]int, 100)
> b.ResetTimer()
> for i := 0; i < b.N; i++ {
> memclr(a)
> }
> }
>
> func BenchmarkLoop_100(b *testing.B) {
> var a = make([]int, 100)
> b.ResetTimer()
> for i := 0; i < b.N; i++ {
> memsetLoop(a, i)
> }
> }
>
> func BenchmarkMemclr_1000(b *testing.B) {
> var a = make([]int, 1000)
> b.ResetTimer()
> for i := 0; i < b.N; i++ {
> memclr(a)
> }
> }
>
> func BenchmarkLoop_1000(b *testing.B) {
> var a = make([]int, 1000)
> b.ResetTimer()
> for i := 0; i < b.N; i++ {
> memsetLoop(a, i)
> }
> }
>
> func BenchmarkMemclr_1(b *testing.B) {
> var a = make([]int, 1)
> b.ResetTimer()
> for i := 0; i < b.N; i++ {
> memclr(a)
> }
> }
>
> func BenchmarkLoop_1(b *testing.B) {
> var a = make([]int, 1)
> b.ResetTimer()
> for i := 0; i < b.N; i++ {
> memsetLoop(a, i)
> }
> }
>
> func BenchmarkMemclr_10(b *testing.B) {
> var a = make([]int, 10)
> b.ResetTimer()
> for i := 0; i < b.N; i++ {
> memclr(a)
> }
> }
>
> func BenchmarkLoop_10(b *testing.B) {
> var a = make([]int, 10)
> b.ResetTimer()
> for i := 0; i < b.N; i++ {
> memsetLoop(a, i)
> }
> }
>
> func BenchmarkMemclr_20(b *testing.B) {
> var a = make([]int, 20)
> b.ResetTimer()
> for i := 0; i < b.N; i++ {
> memclr(a)
> }
> }
>
> func BenchmarkLoop_20(b *testing.B) {
> var a = make([]int, 20)
> b.ResetTimer()
> for i := 0; i < b.N; i++ {
> memsetLoop(a, i)
> }
> }
>
> func BenchmarkMemclr_30(b *testing.B) {
> var a = make([]int, 30)
> b.ResetTimer()
> for i := 0; i < b.N; i++ {
> memclr(a)
> }
> }
>
> func BenchmarkLoop_30(b *testing.B) {
> var a = make([]int, 30)
> b.ResetTimer()
> for i := 0; i < b.N; i++ {
> memsetLoop(a, i)
> }
> }
>
> func BenchmarkMemclr_40(b *testing.B) {
> var a = make([]int, 40)
> b.ResetTimer()
> for i := 0; i < b.N; i++ {
> memclr(a)
> }
> }
>
> func BenchmarkLoop_40(b *testing.B) {
> var a = make([]int, 40)
> b.ResetTimer()
> for i := 0; i < b.N; i++ {
> memsetLoop(a, i)
> }
> }
>
> func BenchmarkMemclr_50(b *testing.B) {
> var a = make([]int, 50)
> b.ResetTimer()
> for i := 0; i < b.N; i++ {
> memclr(a)
[go-nuts] Re: Best practice when creating temporary files
One approach that I use is to make new invocations of the program try to
clean up after older ones. For example, if you name your temp directories
with a particular pattern, you can delete old directories on start up.
Ideally you _should_ try to clean up in the same process, but it isn't
always possible. Even cleaning up 99.99% of the time is still not 100%.
What I do is something like:
tmp := filepath.join(os.Tempdir(), "mydir")
os.RemoveAll(tmp)
t, err := ioutil.TempFile(tmp, "prefix")
if err != nil {
// ...
}
defer os.Remove(t.Name())
defer t.Close()
Some random other thoughts about temp files:
1. If you are running on Windows, you have to make sure to close all
references to the file before you can delete it.
2. If you press Ctrl-C in the middle of your program (or it terminates
abnormally), none of the defers will be run. You can try to catch this,
but its kind of moot, since the signal handler is usually not in the same
scope as the file access.
On Monday, November 21, 2016 at 9:08:03 AM UTC-8, Ondrej wrote:
>
> I already noted that in my very first post, "How do I clean up? As I said,
> the app does not persist (so I can't defer os.Remove)"
>
> I guess I wasn't quite clear about my intentions, so never mind, I'll just
> handle it somehow.
>
> Thanks all for your suggestions.
>
> On Monday, 21 November 2016 16:57:56 UTC, Val wrote:
>>
>> OK, I had overlooked the fact that cleanup is important to you, which
>> makes sense for security and to save disk space early.
>> TempFile, TempDir don't do the cleanup, but the OS will sooner or later.
>> Here is my new suggestion for a file
>>
>> and for a dir
>>
>> :
>>
>> tmpfile, err := ioutil.TempFile("", "")
>> checkerr(err)
>> defer os.Remove(tmpfile.Name())
>>
>>
>> dir, err := ioutil.TempDir("", "")
>> checkerr(err)
>> defer os.RemoveAll(dir)
>>
>
--
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.
For more options, visit https://groups.google.com/d/optout.
