I wholeheartedly agree and would add an important point, that ease of
development/understanding leads to easier refactoring allowing for improvements
in the algorithm- which are usually far more important to performance - which
is exactly what you’ve demonstrated.
> On Mar 6, 2019, at 9:22 PM,
There is another problem about these microbenchmarks as well--they often
are ports of an originating C-version.
I just implemented the Rabbit stream cipher and after reading the papers I
reviewed several versions online in Java and two in Go, as well as the now
open-source C version. It seems that
On Wednesday, March 6, 2019 at 4:03:52 PM UTC-8, Bakul Shah wrote:
>
> Thanks for an interesting read!
>
> Curious to know if you guys have any estimates on the number of lines,
> development time and number of bugs for each language implementation? I
> realize this is subjective but this compari
Thanks for an interesting read!
Curious to know if you guys have any estimates on the number of lines,
development time and number of bugs for each language implementation? I realize
this is subjective but this comparison may be quite meaningful given that the
authors had an existing reference
Unclear… revise… “it requires a lock & unlock for every get and put of an item"
> On Mar 6, 2019, at 5:31 PM, robert engels wrote:
>
> Any use of sync.Pool is kind of a misuse in my opinion. If you review the
> code, it requires unlock/lock to get/put an item - not very cheap, and not
> great
Ask yourself, if the pools are that important for performance, why are they
external? Because some (often?) times the pool provides worse performance - in
this particular small benchmark they do not - but a large applications using
tons of different pools in the goal of “being fast” just might b
Any use of sync.Pool is kind of a misuse in my opinion. If you review the code,
it requires unlock/lock to get/put an item - not very cheap, and not great for
highly concurrent situations - best to only use it for objects that are shared
that are very expensive to instantiate, or unshared pools
On Wednesday, March 6, 2019 at 5:44:21 AM UTC-8, Robert Engels wrote:
>
> As I pointed out long ago on stackoverflow the benchmark games are
> seriously flawed and should not be used for language performance
> comparisons.
>
> As a simple example, look at binary trees. In all of the “fast”
> im
Go 1.12
package: golang.org/x/mobile
Based on the 'basic' example I got something running quite easily on
Android.
iOS was slightly harder, since it was appending 'ProductName' to my
bundleId, but I worked around that by creating a provisioning profile
'.ProductName'. Also 'gomobile: rename ..
Is this a misuse of sync.Pool?
How would a Go programmer re-write the ugly `t.left =` `self.left =` ?
package main
import (
"fmt"
"sync"
)
type Node struct {
left, right *Node
}
var pool = sync.Pool {
New: func() interface{} {
re
It should be pointed out that these three implementations have close to
zero testing. In the absence of that, there is little that should be
drawn from the integration benchmarks that this suggests.
If we relax correct correctness requirements we can get answers in O(1)
with small constants.
On T
Ah! That looks very promising. I now see the section in `go help modules`.
Thanks, Dan!
On Wed, Mar 6, 2019 at 12:58 PM Dan Kortschak wrote:
> Alternatively, setting GOFLAGS=-mod=readonly may help depending on what
> go tool subcommands you are running.
>
> On Wed, 2019-03-06 at 12:45 -0800,
Alternatively, setting GOFLAGS=-mod=readonly may help depending on what
go tool subcommands you are running.
On Wed, 2019-03-06 at 12:45 -0800, Evan Borgstrom wrote:
> Our CI pipeline already does `git status -s -uno` and if there is any
> output prints the diff & exits.
>
> However, this happens
On Wednesday, March 6, 2019 at 12:41:21 PM UTC-8, Bradlee Johnson wrote:
>
> As the saying goes, "there are lies, damned lies and benchmarks."
>
After all, facts are facts, and although we may quote one to another with a
chuckle the words of the Wise Statesman, 'Lies--damned lies--and
statistic
Wrap the go tool with shell code that does the same check after
invoking the real go tool?
On Wed, 2019-03-06 at 12:45 -0800, Evan Borgstrom wrote:
> Our CI pipeline already does `git status -s -uno` and if there is any
> output prints the diff & exits.
>
> However, this happens at the END of a b
It's worth mentioning that I've tried displaying exactly the same piece of
text in Goland 2018.3 and it displays totally correctly!
[image: Screenshot 2019-03-06 at 20.47.02.png]
I think it's fair to say that this is an issue in 2019.1 EAP.
Cheers,
Carl
On Wednesday, March 6, 2019 at 8:41:
Our CI pipeline already does `git status -s -uno` and if there is any
output prints the diff & exits.
However, this happens at the END of a build (after running lint, build,
test, doc generation, etc), which means you could wait ~minutes before you
get the feedback. We have specialized checks for
As the saying goes, "there are lies, damned lies and benchmarks."
Java is particularly difficult to get good benchmarks in due to the nature
of HotSpot and JIT compilation. I was listening to James Gosling recently
and he pointed out that there are over 100 flavors of JIT compilation on
the JV
Hi Florin,
I've just started using Goland 2019.1 EAP, and so far it seems pretty
stable, except for one strange thing. In my code, I had occasion to type
the word "filter". Bizarrely, the "fi" characters are being displayed as a
telephone emoji. Like so...
[image: Screenshot 2019-03-06 at 19.5
Can you just check that the vcs diffs them as no diff?
e.g.
```
if [ -n "$(git diff -- go.mod go.sum)" ]; then
git diff -- go.mod go.sum
exit 1
fi
```
On Wed, 2019-03-06 at 11:07 -0800, eborgst...@nerdwallet.com wrote:
> Hi fellow Gophers,
>
> My company has a requirement in o
Hi fellow Gophers,
My company has a requirement in our CI builds that no files which are part
of the repository are modified as part of the build.
For our Go builds this bites us sometimes because there are circumstances
where someone can push a commit where when `go build`/`go test` are called
On Wed, Mar 6, 2019 at 3:30 AM Jan Mercl <0xj...@gmail.com> wrote:
>
> To someone owning a github account: Please forward to the issue tracker,
> while there's still no bot for that, thanks in advance.
Done. Thanks.
> @Ian Lance Taylor: Last time we've discussed the forwarding problem, the
> q
With regards the size of the struct, elements are aligned by the go
compiler automatically as demonstrated by the following tool:
http://golang-sizeof.tips/
Are you asking why the compiler doesn't automatically change the order
of fields in the struct to make the struct a minimal size?
Re
Hi Ian,
You are right.
Thanks for a link. I'm going to look at that discussion.
ср, 6 бер. 2019 о 15:57 Ian Lance Taylor пише:
> On Wed, Mar 6, 2019 at 5:39 AM Viktor Packhuchyi
> wrote:
> >
> > As I know Go compiler provide self-managed alignment for fields inside a
> structure.
> >
> > I do
On Wed, Mar 6, 2019 at 5:39 AM Viktor Packhuchyi
wrote:
>
> As I know Go compiler provide self-managed alignment for fields inside a
> structure.
>
> I don't understand why the fields order must impact additional allocations.
> It's not clear for me, why the compiler doesn't manage this automatic
As I pointed out long ago on stackoverflow the benchmark games are seriously
flawed and should not be used for language performance comparisons.
As a simple example, look at binary trees. In all of the “fast”
implementations, they resort to specialized memory pools that wouldn’t be
useable in
Hi,
As I know Go compiler provide self-managed alignment for fields inside a
structure.
I don't understand why the fields order must impact additional
allocations.
It's not clear for me, why the compiler doesn't manage this automatically.
Is this a future which I can't understand or a des
1. What version of Go are you using (`go version`)?
go1.11.4 darwin/amd64
2. What operating system and processor architecture are you using?
GOOS="darwin"
GOARCH="amd64"
3. What did you do?
I attempted to generate android bindings using gomobile bind.
4. What did you expe
Benchmarks are always limited, I know. But this might indicate some
direction:
https://benchmarksgame-team.pages.debian.net/benchmarksgame/faster/go-gpp.html
Am Mittwoch, 6. März 2019 14:07:03 UTC+1 schrieb JuciÊ Andrade:
>
> That doesn't surprises me at all.
>
> A couple years ago I worked for
That doesn't surprises me at all.
A couple years ago I worked for a company where I created prototypes in Go
and production code in C++, using the same architecture and algorithms. Go
version usually ran 15% faster. After some work both versions could be
tuned to run faster, but it amazed me to
>
> My thought then is that access to reads and writes on the req.Body must
> be serialized to avoid a race condition.
>
Could you elaborate on how you concluded that? Preserves, does not mean
'takes ownership' as I understand.
Using a mutex for this prevented the race conditions.
But this
Seems like your git repo is just misconfigured. $ go get does not actually
download things, it calls out git or other VCS to do that. I'm also using
gitlab for private repositories and have no issues with go get.
Example https (wrong) config:
jnml@4670:~/src/modernc.org/ql> cat .git/config
[
According to the doc on client.Do, a 307 or 308 redirect preserves the original
http method and body provided that the request.GetBody function is defined
My thought then is that access to reads and writes on the req.Body must
be serialized to avoid a race condition.
Using a mutex for this preven
33 matches
Mail list logo
