With times under one nanosecond I'm wondering what you're actually
measuring. Aggressive optimization could make this an "empty" loop.
Synthetic benchmarks like this can be tricky to interpret.
On Wednesday, August 3, 2016 at 7:56:32 AM UTC-4, Ondrej wrote:
>
> I wanted to see if there was a
I wanted to see if there was a difference when loading values from a
large-ish slice (1 elements) - to see if caches, locality and other
things had any meaningful impacts. Whilst individual value loading (just a
single element) seemed to be equally fast regardless of element position
(see
Downgrading to 1.6.3, I'm also getting consistent benchmark results. I'll
try 1.7 on my Mac at home later today, to see if it's a 1.7 thing or a
Windows thing or...?
On Wednesday, 3 August 2016 14:55:20 UTC+1, C Banning wrote:
>
> PS - that's with Go v1.6.
>
> On Wednesday, August 3, 2016 at
Have you tried examining the assembler output? go build -gcflags="-S"
program.go if I recall correctly.
On Wednesday, August 3, 2016 at 11:27:36 AM UTC-4, T L wrote:
>
>
> I know a string value can be used as []byte if the first parameter if the
> builtin copy/append function is a []byte
On Wednesday, August 3, 2016 at 11:59:27 PM UTC+8, Hotei wrote:
>
> Have you tried examining the assembler output? go build -gcflags="-S"
> program.go if I recall correctly.
>
yes, the output is different, looks like optimization is not made here, but
I can't make sure.
>
>
> On
On Wednesday, August 3, 2016 at 11:46:43 PM UTC+8, Axel Wagner wrote:
>
> True, but it would still be just the same loop, it wouldn't actually be
> significantly faster. And you'd need to put quite some machinery into a
> pretty rarely used functionality, which means it also wouldn't be
On Wed, Aug 3, 2016 at 7:36 AM T L wrote:
> Often, I need converting a []T to []interface{} to use the []interface as
> a variable length parameter.
> But converting a []T for []interface{} in a for loop is neither clean nor
> efficient.
>
If there was a builtin that did
Don't confuse variadic arguments with slice arguments, by the way.
On Wed, Aug 3, 2016 at 8:20 AM T L wrote:
>
>
> On Wednesday, August 3, 2016 at 10:53:34 PM UTC+8, Jessta wrote:
>
>> On 4 Aug 2016 12:36 a.m., "T L" wrote:
>> >
>> > Often, I need
I know a string value can be used as []byte if the first parameter if the
builtin copy/append function is a []byte value:
> var bs []byte = make([]byte, 10)
> copy(bs, "abcde")
but if do explicit conversion anyway on the second string value
> var bs []byte = make([]byte, 10)
> copy(bs,
On Wed, Aug 3, 2016 at 8:58 AM, Sankar wrote:
>
> I have a .proto2 file, like:
>
> message s {
> optional double a = 1;
> }
>
> When I run protoc and generate the .pb.go file, it contains code like:
>
> type S struct {
> A*float64
Thanks for the explanation. It does look much better in proto3. I will
see if it will be possible to switch to proto3.
2016-08-03 21:37 GMT+05:30 Ian Lance Taylor :
> On Wed, Aug 3, 2016 at 8:58 AM, Sankar wrote:
>>
>> I have a .proto2 file, like:
>>
On 4 Aug 2016 12:36 a.m., "T L" wrote:
>
> Often, I need converting a []T to []interface{} to use the []interface as
a variable length parameter.
> But converting a []T for []interface{} in a for loop is neither clean nor
efficient.
>
> So is there a function in standard lib
Hi
I have a .proto2 file, like:
message s {
optional double a = 1;
}
When I run protoc and generate the .pb.go file, it contains code like:
type S struct {
A*float64 `protobuf:"fixed64,1,opt,name=a"
json:"a,omitempty"`
XXX_unrecognized []byte `json:"-"`
}
Why is the A field
Often, I need converting a []T to []interface{} to use the []interface as a
variable length parameter.
But converting a []T for []interface{} in a for loop is neither clean nor
efficient.
So is there a function in standard lib to convert []T to a []interface{}?
--
You received this message
https://github.com/golang/go/issues/15209
On Wednesday, August 3, 2016 at 11:20:01 AM UTC-4, T L wrote:
>
>
>
> On Wednesday, August 3, 2016 at 10:53:34 PM UTC+8, Jessta wrote:
>>
>> On 4 Aug 2016 12:36 a.m., "T L" wrote:
>> >
>> > Often, I need converting a []T to
You probably don't want to actually call
fmt.Println(s...)
with s an []interface{}. Just do
fmt.Print(s)
instead.
On Wed, Aug 3, 2016 at 5:20 PM, T L wrote:
>
>
> On Wednesday, August 3, 2016 at 10:53:34 PM UTC+8, Jessta wrote:
>>
>> On 4 Aug 2016 12:36 a.m., "T L"
True, but it would still be just the same loop, it wouldn't actually be
significantly faster. And you'd need to put quite some machinery into a
pretty rarely used functionality, which means it also wouldn't be cleaner.
The thing is, that the memory representation of []T and []J, with J being
an
http://dave.cheney.net/2016/04/07/constant-errors
--
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,
done.
https://github.com/golang/go/issues/16596
On Thursday, August 4, 2016 at 12:01:55 PM UTC+8, bradfitz wrote:
>
> Please file a bug.
>
>
> On Wed, Aug 3, 2016 at 8:20 PM, steve wang > wrote:
>
>> https://play.golang.org/p/gYYUDxj6Z5
>>
>> Is this an issue?
>>
>> --
On Thursday, August 4, 2016 at 12:16:37 AM UTC+8, Ian Lance Taylor wrote:
>
> On Wed, Aug 3, 2016 at 9:12 AM, T L
> wrote:
> >
> > On Wednesday, August 3, 2016 at 11:46:43 PM UTC+8, Axel Wagner wrote:
> >>
> >> True, but it would still be just the same loop, it wouldn't
Doh. Thanks. I did the setup but didnt click "execute".
Revisiting this because its now a bottleneck since it directly impact user
experience (how long a request will take to process) and scalability
(requests per second a single instance can handle). It wasn't pre-mature
optimization, rather
I surely will use the first version in practice.
I just want to make things clear, :)
On Thursday, August 4, 2016 at 3:23:11 AM UTC+8, Hotei wrote:
>
> If you create the source as a byte array by converting it ([]byte("abcde")
> then the compiler can NOT optimize it away. However - I don't
https://play.golang.org/p/gYYUDxj6Z5
Is this an issue?
--
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
Because we cannot change symbols covered by the Go 1 contract.
On Thursday, 4 August 2016 14:20:18 UTC+10, T L wrote:
>
> http://dave.cheney.net/2016/04/07/constant-errors
>
--
You received this message because you are subscribed to the Google Groups
"golang-nuts" group.
To unsubscribe from
Looking at the asm it appears that there is a conversion func called in the
second version - right before the copy with memmove.
Based on this I'd say what happens AFTER the conversion is the same in both
version since the destination is the same and the content is the same. The
only
Hi Victor,
There are no "constant" errors in the sql package if thats what you are
looking for.
Generally if .Ping() returns an error there is no connection - afaik the
error string might give some indication but it is totally up to the
driver/database.
If you want to sleep and try again later
I'm a bit uneasy about this. Since checksumming is not collision-resistant,
I would be careful just relying on this.
The goal was to avoid diffing files but I don't know what is the fastest
way.
In any case, I guess a checksum is not enough to guarantee file integrity
(against malice). Maybe
What is the purpose of this? For instance, In govendor the hash of the
files, file names, and path is computed and recorded. That way if they are
modified it is detected. So yeah, md5 or blake2 would work just fine.
On Wednesday, August 3, 2016 at 10:14:53 AM UTC-7, atd...@gmail.com wrote:
>
>
On Thursday, August 4, 2016 at 12:40:41 AM UTC+8, Hotei wrote:
>
> Looking at the asm it appears that there is a conversion func called in
> the second version - right before the copy with memmove.
>
> Based on this I'd say what happens AFTER the conversion is the same in
> both version since
Yes, I suppose that clamping the file size, and the requirement that the
package must pass compilation, even md5 shall do. Thanks to the avalanche
effect.
On Wednesday, August 3, 2016 at 9:36:34 PM UTC+2, Hotei wrote:
>
> The fact that collisions are possible does not make them "easy to create"
Tests are usually included in the package. Testing a package cannot become
easier this way and it is the only way to test internal functions, types,
variables or constants. However if you have large test files, it may make
sense to keep them in a separate repository because go-getting the
Tu cast pola s ktorou pracujes mas v L1/ L2 cache. V momente ked
pristupujes k inej casti pola ktora je niekolko megabajtov vzdialena tak
procesor musi natiahnut tie udaje z ram do cache. Neviem presne cisla ale
trva to zhruba tych 300 strojovych cyklov . Vypadok L2 neviem kolko trva,
je to v
The fact that collisions are possible does not make them "easy to create"
especially when you add the compileable requirement. If you're uneasy
about md5 you could always use more bits - like SHA1 used by "git" or
SHA256 (or larger) if you're really paranoid.
On Wednesday, August 3, 2016 at
If you create the source as a byte array by converting it ([]byte("abcde")
then the compiler can NOT optimize it away. However - I don't think it
will *use* the capacity information in the source since it's not relevant
and it's going to copy the data bytes and length in any case.
If you're
On Wednesday, August 3, 2016 at 6:16:37 PM UTC+2, Ian Lance Taylor wrote:
>
> On Wed, Aug 3, 2016 at 9:12 AM, T L
> wrote:
> >
> > On Wednesday, August 3, 2016 at 11:46:43 PM UTC+8, Axel Wagner wrote:
> >>
> >> True, but it would still be just the same loop, it wouldn't
I perused your blog entry you mentioned. It's very interesting and will
come in handy in the future. Thank you.
I can appreciate your point of view about accepting the fact that currently
listeners are not part of the Server and just proceed to produce code and
get it done ASAP. My
Hi,
i have a program that imports a package from github.com/abc...
when i build the .exe how can i have the package/dependency included in the
.exe ?
thanks,
Al
--
You received this message because you are subscribed to the Google Groups
"golang-nuts" group.
To unsubscribe from this group
I suggest you also take a look at the Go spec that describes method values:
https://golang.org/ref/spec#Method_values
It seems to click on what you want to do.
Also, take a look at this article from Alex Edwards:
http://www.alexedwards.net/blog/organising-database-access more
specifically, the
Please give me your typemap. Thanks!
--
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
Your research revealed the essential lines from ListenAndServeTLS that
basically say:
1. create a tls listener
2. have the server serve using that listener
The LimitListener example follows this same pattern, just with net.Listener
instead of a tls.Listener. A careful reading reveals that
The issue here in essence is that an http.Server doesn't store a
new.Listener to expose, it only operates on one provided to the Serve
method. Without changing the api, there's no way to expose a listener in an
http.Server in a way that doesn't interfere with the other methods.
However, I
Hello,
When you compile go program, all your source and source from all
imported packages is compiled together in the same binary (.exe). You
don't need to worry about it. That's actually one of the go strengths,
no dll hell.
On 03.08.2016 07:57, ov35...@gmail.com wrote:
Hi,
i have a
A few years ago, I uploaded a parallel “find duplicate files in a filesystem”
utility to GitHub. It is called “dup” for “find duplicates.”
https://github.com/MichaelTJones/dup/blob/master/dup.go
In that program, which first groups files by size, then compares the first few
bytes, then
You need to use the values to ensure that compiler does not remove the code.
Even if the compiler does not do this, your Intel CPU will, if effectively runs
an ssa implementation in hardware and will spot the dead stores and skip the
load.
--
You received this message because you are
(I have now recreated it on my Mac, under 1.7rc5, the runtime differences
are still there.) I thought the compiler was removing these as you suggest,
but then StartEnd and EndStart had wildly different running times, despite
using the very same values. So I added dummy assignments to double
What's the "login package"?
On Wed, Aug 3, 2016 at 3:12 PM, wrote:
> Anyone know why the tcp server closes its connection after of answer the
> login package?
>
> --
> You received this message because you are subscribed to the Google Groups
> "golang-nuts" group.
>
Those arguments must live beyond the scope of the enclosing function.
--
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.
I tried just what you mentioned. Unfortunately even my interim solution
when it is outside of the net.http package and within mine, there are many
services that are not exported meaning I can't use them at all and the
variables themselves are inaccessible.
I tried copying pasting some
Anyone know why the tcp server closes its connection after of answer the
login package?
--
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
49 matches
Mail list logo