I would caution that reduced performance with ondemand might be a good thing.
If the job is doing lots of IO this means the process has little/less overhead
so less drain on the cpu meaning it takes a while to spin back up.
If both governors show the serious degradation I would be far more
On Fri, Feb 7, 2020 at 11:01 AM Klaus Post wrote:
>
> I am seeing a generally negative impact of Go 1.13 -> 1.14-RC1 in terms of
> speed.
Thanks. Would you mind opening an issue about this (if you haven't already)?
Ian
--
You received this message because you are subscribed to the Google
On my microbenchmarks I'm seeing a huge negative impact (ca. 15%) under the
Linux ondemand governor. Under the performance governor its less than 1%.
--
You received this message because you are subscribed to the Google Groups
"golang-nuts" group.
To unsubscribe from this group and stop
Hi!
I am seeing a generally negative impact of Go 1.13 -> 1.14-RC1 in terms of
speed.
Running benchmarks in my deflate package - and removing the "no change"
entries:
nameold time/opnew time/opdelta
DecodeDigitsSpeed1e5-12903µs ± 0% 940µs ± 1%
On Thu, Feb 6, 2020 at 9:51 AM Dax McDonald wrote:
>
> Hit a small snag while using Go 1.14.
> Running go1.14beta1 build main.go on our project, github.com/rancher/rio
> results in
>
> go: github.com/StrongMonkey/linkerd2@v0.0.0-20191021165729-976fad67457a:
> parsing go.mod: go.mod:3: usage: go
On Wed, Feb 5, 2020 at 11:33 PM Manlio Perillo wrote:
>
> Is there some overhead due to preemption?
Sure, but measurements show that performance is better with this
approach, especially at scale.
> About EINTR, I suspect that some programs will have problems.
> As an example
>
Hello,
Hit a small snag while using Go 1.14.
Running go1.14beta1 build main.go on our project, github.com/rancher/rio
results in
go: github.com/StrongMonkey/linkerd2@v0.0.0-20191021165729-976fad67457a:
parsing go.mod: go.mod:3: usage: go 1.23
It looks like we are hitting
Is there some overhead due to preemption?
About EINTR, I suspect that some programs will have problems.
As an example
https://github.com/golang/go/issues/22838
The issue was reported for MacOS, but technically every signal, including
SIGSTOP, can interrupt a syscall.
Thanks
Manlio
On
On Wed, Feb 5, 2020 at 3:40 PM amr wrote:
>
> I'm seeing the same problem, also.
Sorry about that. It's been fixed.
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
I'm seeing the same problem, also.
--
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
On Wednesday, February 5, 2020 at 6:12:21 PM UTC-5, Andrey Tcherepanov
wrote:
>
> Sorry to mention, but for me https://tip.golang.org/doc/go1.14 returns
> "template:
> main:846: unexpected EOF"
>
> Not sure if this is because it is work in progress, or too many people
> trying to hit this
Sorry to mention, but for me https://tip.golang.org/doc/go1.14 returns
"template:
main:846: unexpected EOF"
Not sure if this is because it is work in progress, or too many people
trying to hit this site after announcement.
Andrey
On Wednesday, February 5, 2020 at 12:43:47 PM UTC-7, Carlos
On Wed, Feb 5, 2020 at 2:05 PM Kaveh Shahbazian
wrote:
>>
>> "Goroutines are now asynchronously preemptible."
>
> Very nice!
>
>> "A consequence of the implementation of preemption is that on Unix systems,
>> including Linux and macOS systems, programs built with Go 1.14 will receive
>> more
>
> "Goroutines are now asynchronously preemptible."
Very nice!
"A consequence of the implementation of preemption is that on Unix systems,
> including Linux and macOS systems, programs built with Go 1.14 will receive
> more signals than programs built with earlier releases. This means that
14 matches
Mail list logo
