Just because I’m not available doesn’t mean someone else isn’t interested. Like
I said, just MO.
> On Feb 1, 2019, at 7:22 PM, Milind Thombre wrote:
>
> Thanks for the critique.
>
> I guess I will proceed to do a small study for my specific use case without
> external contributors then.
Thanks for the critique.
I guess I will proceed to do a small study for my specific use case without
external contributors then.Keeping the big bucks for myself and not
contributing anything to the community.
Now off to lick my wounds ;)
On Sat 2 Feb, 2019, 6:42 AM Robert Engels I’m sorry,
I’m sorry, but I don’t have the bandwidth. I also think it may be a fools
errand, or so narrowly focused that it isn’t very valuable. Every case is
somewhat unique which is why the architects get the big bucks to make the
“right” call given all the factors.
> On Feb 1, 2019, at 7:05 PM, Milind
Do you think we could jointly author
1. An unbiased research study with an improved methodology, better
statistical analysis and appropriate and varied benchmarking program(s) ?
2. CSP and other cost savings/increase study (ROI) by shifting to go long
term.
Also: if you think this idea is great
Depending on your scale, even 10% greater efficiency can mean a lot of dollars…
But that is where cost / benefit analysis comes in… Cost to develop and
maintain vs. decreased ongoing deployment costs (less servers/cpu needed, etc.)
> On Feb 1, 2019, at 6:51 PM, Milind Thombre wrote:
>
> Agreed
Agreed, though even if it scales horizontally, your cloud service provider
bill could scale vertically as well. :).
Time to market is a greater consideration for me currently , so I've
already chosen python/Django for v1. 0. I am comfortable with Python and
am going to finish faster.
But I wanted
Also, the sites testing methodology is seriously flawed, but for people that
take stock in those sort of tests I guess it serves its purpose.
> On Feb 1, 2019, at 6:39 PM, Milind Thombre wrote:
>
> True. e.g. Development time/effort, availability of developers, support
> community strength and
Exactly. In a lot of cases if the application can horizontal scale, the raw
performance matters little if time to market is the greatest concern.
> On Feb 1, 2019, at 6:39 PM, Milind Thombre wrote:
>
> True. e.g. Development time/effort, availability of developers, support
> community strength
True. e.g. Development time/effort, availability of developers, support
community strength and longetivity of the chosen technology platform to
name a few!
On Sat 2 Feb, 2019, 6:02 AM robert engels Yes, but even those tests don’t provide a real analysis as to which is the
> better platform, bec
No, there are a lot of different tests - you need to click on the tabs.
> On Feb 1, 2019, at 6:36 PM, Milind Thombre wrote:
>
> Wow!
>
> Django is an order of magnitude slower than nodejs. Good to know these
> numbers. Thanks for the link Shulhan! I don't see *go* in the list, which
> framewo
Wow!
Django is an order of magnitude slower than nodejs. Good to know these
numbers. Thanks for the link Shulhan! I don't see *go* in the list, which
framework does a typical go web app use?
But they used a *hello world* program!
On Sat 2 Feb, 2019, 5:53 AM Shulhan On Fri, 1 Feb 2019 15:13:35 -
Yes, but even those tests don’t provide a real analysis as to which is the
better platform, because there is far more to consider than just the runtime
performance - although for some cases it would immediately exclude certain
platforms & frameworks.
> On Feb 1, 2019, at 6:23 PM, Shulhan wrote
You simply need
docker run <...>
which will invoke smth like
go build
at the end.
PS: The above Makefile is garbage.
пятница, 1 февраля 2019 г., 21:59:53 UTC+3 пользователь Bojan Delić написал:
>
> I have Makefile that supports build in docker image, part of it looks
> something like this:
>
On Fri, 1 Feb 2019 15:13:35 -0800 (PST)
thomb...@gmail.com wrote:
>
> However, there has been no comprehensive quantitative study on this
> so far that I am aware of.
>
Did you mean like Web Framework Benchmark by TechEmpower? [1]
[1] https://www.techempower.com/benchmarks/#section=intro&hw=ph
Good thx. I should have specified frameworks. Though there is value in
collecting statistics for a raw benchmarking program too in my opinion.
Django with python
Nodejs with Angular frontend
And idk what framework go user's use.
On Sat 2 Feb, 2019, 5:32 AM robert engels Some thoughts… not to thr
Oh, and before anybody flames me, I am not implying that just because you are
faster at network and disk IO makes it a better web server platform - there are
other considerations (like dynamic code loading and others) that play a major
part - I only offered in the context of the original questio
Some thoughts… not to throw cold water on your idea, but
Not many people write using the “http server/client” layers directly - almost
everyone uses a framework of some sort - now you have hundreds of options on
each platform.
Even if you wrote the programs from scratch as “equally using the bu
There is a general agreement/notion in the developer community that go/golang
is faster than python or node.Js for a typical i/o intensive web application.
However, there has been no comprehensive quantitative study on this so far that
I am aware of.
I would like to propose a joint development
This looks like the question asked a week ago. Look at the first post for
answers.
On Fri, Feb 1, 2019 at 3:44 PM John wrote:
> Dear Gophers,
> I have made a connect five game, and am planning to make it a website.
> But first, there is a diagnostic problem. My win function depends on if a
> po
Dear Gophers,
I have made a connect five game, and am planning to make it a website. But
first, there is a diagnostic problem. My win function depends on if a
points neighbouring 4 dots ..x.. are all the same type. But if its on the
edge it will not run, as it only has 2 neighbours X .. I made
The pseudo code for the correct code would look like:
struct {
a int
}
go routine #1:
for {
atomic.Store(&A.a,A.a + 1) // this is ok since only a single writer
or even better the following:
atomic.Increment(&A.a,1)
}
go routine #2 :
for {
if atomic.Load(&A.a) > 100 {
br
Making things worse, Go’s "memory model" is very loosely defined, so even the
correct use of atomics may not work on all platforms. You can read up on
“happens before” which is the key aspect.
> On Feb 1, 2019, at 4:32 PM, robert engels wrote:
>
> Because there is no write barrier - so the cha
Because there is no write barrier - so the changes that Go routine #1 makes may
all be local (in a register), and never flushed to memory. Go routine #2 is
also free to keep using the last read value from the cache since there is
nothing that would force the cache to be refreshed.
The is an imp
When machines (compilers or processors) are allowed to optimise things,
reality gets weird.
The compiler may elide the check because it is not conformant with the
spec via the memory model, or value A.a may be in a local CPU cache and
so never be altered as far as the core is concerned.
On Fri, 2
Hello Gophers,
The go-formal github organisation at http://github.com/go-formal is a
GitHub organisation
for sharing and coordinating work related to formal logic technologies in
and for Go.
Effective immediately, Marko Ristin-Kaufmann (marko.ris...@gmail.com) is
the new acting steward of go-f
On Friday, February 1, 2019 at 11:11:24 AM UTC-5, robert engels wrote:
>
>
> for {
>if A.a > 100 {
> break
> }
>
>
> Go routine #2 may never see the value of A.a change and so never exit the
> loop.
>
I'm confused. I can see how that would fail if the test were A.a == 100
since Go ro
I have Makefile that supports build in docker image, part of it looks
something like this:
NAME :=
PACKAGE := github.com/username/repo
.PHONY: build
build: clean gobuild ## Build application
.PHONY: gobuild
gobuild: LDFLAGS=$(shell ./scripts/gen-ldflags.sh $(VERSION))
gobuild:
@echo "Build
It is not the writing - it is the reading, and what is “visible”.
The point was that you need to use atomics if you write to ANY structure field
and read that field from another Go routine - barring any other synchronization
method (WaitGroup, Lock, etc.)
The secondary point is, if you use atom
On Fri, 1 Feb 2019, 4:11 pm robert engels There is nothing reading the value in that code - so that would always be
> safe…
>
> Here is a more common example that many people get wrong (pseudo code)
>
> struct {
>a int
> }
>
> go routine #1:
>
> for {
>A.a = A.a + 1
> }
>
> go routine #2 :
There is nothing reading the value in that code - so that would always be safe…
Here is a more common example that many people get wrong (pseudo code)
struct {
a int
}
go routine #1:
for {
A.a = A.a + 1
}
go routine #2 :
for {
if A.a > 100 {
break
}
Go routine #2 may never se
On Fri, 1 Feb 2019, 3:18 pm Robert Engels To clarify though, you still need to use atomics.
>
Really? For writing to different fields in a struct? So the following code
is not generally safe?
(I often rely on this kind of code being safe so if it isn't, I need to
know!).
type S struct {
a A
To clarify though, you still need to use atomics.
> On Feb 1, 2019, at 8:52 AM, roger peppe wrote:
>
>
>
>> On Thu, 3 Aug 2017, 8:45 am Dave Cheney >
>>
>>> On Thu, 3 Aug 2017, 17:39 Dave Cheney wrote:
>>> Your first program has a data race, well it has two races, the first is a
>>> data
On Thu, 3 Aug 2017, 8:45 am Dave Cheney
>
> On Thu, 3 Aug 2017, 17:39 Dave Cheney wrote:
>
>> Your first program has a data race, well it has two races, the first is a
>> data race between the goroutines writing to the slice and the println which
>> will read the contents of the slice. That is, i
On Fri, 1 Feb 2019, 2:56 pm Robert Engels That is safe to do. I am referring to the performance hit due to false
> sharing for fields that are updated independently by being close together
> in memory.
>
I'm sorry if my sloppy "I'm replying on my phone" message quoting made it
unclear, but I was
That is not required for simple counters that are incremented by multiple and
read by one. Atomics suffice.
> On Feb 1, 2019, at 8:24 AM, Jesper Louis Andersen
> wrote:
>
>> On Thu, Aug 3, 2017 at 9:21 AM Henrik Johansson wrote:
>
>> I think I am mostly after a mental pattern to easily reco
That is safe to do. I am referring to the performance hit due to false sharing
for fields that are updated independently by being close together in memory.
> On Feb 1, 2019, at 8:52 AM, roger peppe wrote:
>
>
>
>> On Thu, 3 Aug 2017, 8:45 am Dave Cheney >
>>
>>> On Thu, 3 Aug 2017, 17:39 D
On Thu, Aug 3, 2017 at 9:21 AM Henrik Johansson
wrote:
> I think I am mostly after a mental pattern to easily recognise when
> synchronizations are needed.
>
Assume every write to memory takes 10 seconds and is asynchronous, except
that you have Read-Your-Own writes in a goroutine.
You can redu
You can prevent the false sharing by using additional memory and putting gaps
between the elements.
You need to use atomics even if only written by a single if there is a
collating routine that is reading the values.
> On Feb 1, 2019, at 6:37 AM, Marvin Renich wrote:
>
> * johnmr...@gmail.c
* johnmr...@gmail.com [190131 23:50]:
> > Writing to adjacent memory locations [i.e. different array elements, from
> > different goroutines] will cause false sharing between CPU caches. This is
> > a performance, not a correctness issue.
>
> I'm looking to make an array of thread-safe counter
So your example may be unexpected behavior (or bug) of lib/pq.
Please file an issue report on lib/pq.
Done: https://github.com/lib/pq/issues/828
Lutz
--
You received this message because you are subscribed to the Google Groups
"golang-nuts" group.
To unsubscribe from this group and stop re
>
> That's interesting!
>
> Does the code of NextResultSet from sql.go shed any light on this?
>
> https://golang.org/src/database/sql/sql.go?s=76505:76541#L2684
>
> Lutz
No. I read it multiple times already.
I found test for NextResultSet() in lib/pq.
https://github.com/lib/pq/blob/0ac245bc3be
After reading Lutz's sample code. I found lib/pq has different semantics.
I'm not sure which is the right semantics, intended by database/sql APIs.
That's interesting!
Does the code of NextResultSet from sql.go shed any light on this?
https://golang.org/src/database/sql/sql.go?s=76505:76541#L
>
> After reading Lutz's sample code. I found lib/pq has different semantics.
> I'm not sure which is the right semantics, intended by database/sql APIs.
>
>
https://golang.org/pkg/database/sql/driver/#RowsNextResultSet
// NextResultSet advances the driver to the next result set even
Hello, I'm one of maintainer of go-sql-driver/mysql.
When there is only one result set, you don't need NextResultSet().
See this example.
https://play.golang.org/p/rhm4Xp6WejB
Then, when you have multi result set, you need to call NextResultSet() once
to get 2nd result set.
See this example.
h
44 matches
Mail list logo
