The short answer is yes, but not in this example.
In your example the inline doesn't happen because `foo` is (barely) too
complex so it is not inlined and the closure remains a parameter:
```
go build -gcflags=-m=2 main.go
# command-line-arguments
./main.go:3:6: cannot inline foo: function too
"Vote with YOUR feet, not MY feet".
On Monday, June 26, 2023 at 12:56:12 PM UTC-4 Thomas Bushnell BSG wrote:
> I mean, this is mostly true, except that the protesters do have the right
> to administer the subreddit in the way they choose, as long as they are the
> admins.
>
> As you said, if
Have you considered moving to another platform, either Lemmy or Kbin?
(He says, not having completed his own move of the benchmarking bot to
botsin.space).
On Saturday, June 24, 2023 at 1:51:10 PM UTC-4 Robert Engels wrote:
> I’m fairly certain Reddit will license those tools for moderators use.
Based on studying large bodies of existing code, you should be about 25x
more scared right now that there's an undetected bug in your code from the
existing semantics -- especially if you haven't written many tests. If
this change does cause a failure in existing code, we have a tool to help
And if there is a problem, let us know. Probably around the time 1.21 is
released we should write up "how to debug this problem if you see it" but
we've been working on the tools to automate the search if/when such a bug
appears.
On Saturday, March 25, 2023 at 10:12:43 AM UTC-4 Eli Bendersky
Try also GOMAXPROCS=1 ? At some point not too long ago we made that dial
down the concurrency in the compiler (before, it would do concurrent
builds/compiles anyway) and that should reduce the maximum footprint.
On Wednesday, February 22, 2023 at 1:42:56 PM UTC-5 Jan Mercl wrote:
> The subject
Could you use an applicative data structure? (e.g., a balanced binary tree
where you allocate a new spine for each insertion/deletion)
That has log N overhead to read, log N storage allocated per write, but I
think if you CAS the writes, the reads can proceed with a lightweight
barrier.
On
I just checked with my personal app engine project ("gcloud app deploy",
that's app engine, I think), and with 1.19 specified in go.mod and
"runtime: 119" in app.yaml, the app reported runtime.Version() of 1.19.3.
My understanding is this is a recent change.
On Thursday, December 15, 2022 at
>From the POV of not-runtime-code, preemption can happen anywhere.
Certainly with GOMAXPROCS > 1, there is OS preemption, and Go's default
goroutine preemption is now potentially preemptive in most parts of
non-runtime functions.
On Monday, December 5, 2022 at 7:12:54 PM UTC-5
You could use build tags to write a portable implementation and a (very)
version-specific implementation.
E.g.
//go:build go1.18 && !go1.19
// go1.18-specific
and
//go:build (go1.8 && !go1.18) || go1.19
// not go1.18
We have ideas about changing the ABI in the future -- possible changes
include
The pause also tends to not be large. Except for bugs (which do exist and
some of them are hard to fix) the goal on a modern fast processor is under
100 microseconds of a thread "pausing". There is a period of time where
goroutines will make reduced progress as the garbage collector steals
That debugging is (now) in the runtime package, which is (always) compiled
with optimizations on.
That will tend to interfere with debugging. The 1.17 change to use
registers for passing parameters
has also caused some regressions in debugging quality (and it would be nice
to fix those, but it
I was going to ask, "how do they define/measure that?", decided to look at
the Rust code, and
found http://www.unicode.org/Public/security/10.0.0/confusables.txt
So there's a defined source and everything.
On Friday, June 11, 2021 at 5:48:05 PM UTC-4 Ian Lance Taylor wrote:
> On Fri, Jun 11,
On Sunday, June 6, 2021 at 8:35:02 AM UTC-4 Paul S. R. Chisholm wrote:
> For example, could this code:
>
> func BenchmarkPopCountAlive(b *testing.B) {
> sum = 0
> for i := 0; i < b.N; i++ {
> sum += PopCount(0x1234567890abcdef)
> }
> }
>
> hypothetically be optimized to:
>
>
Also, be aware that work that we really hope lands in 1.17 will tinker with
all the call operations.
The goal is to switch to an ABI that passes parameters to/from calls in
registers, and the way
that ends up expressed in SSA is that first (and we do this part in 1.16)
the parameters to the
Go "cares" because in Go it's common for a single OS thread to correspond
to 25-100% of runnable goroutines.
So the accounting for "how many OS threads are available to run goroutines"
tends to be fine-grained,
otherwise weird failure-to-schedule bugs can occur. It's likely it could be
We could regard the function as a method on the type(s), maybe?
Not sure if this is a good idea or not, especially since we don't have
multimethods (methods applied to multiple values) for ordinary values.
On Monday, June 22, 2020 at 1:53:56 PM UTC-4 Ian Lance Taylor wrote:
> On Mon, Jun 22,
FYI, strided iteration is something we're trying to do better but this is
very tricky code, and it is also possible for it to get very expensive at
compile time.
On Saturday, February 22, 2020 at 4:42:03 PM UTC-5 Nigel Tao wrote:
> On 2/23/20, Bruno Albuquerque wrote:
> > Would adding an
Different, new bug instead: https://github.com/golang/go/issues/36685
On Tuesday, January 21, 2020 at 4:33:00 PM UTC-5 drc...@google.com wrote:
> I reopened an old bug for this, and perhaps it will get some attention.
> https://github.com/golang/go/issues/6623
>
> On Sunday, January 12, 2020 at
I reopened an old bug for this, and perhaps it will get some attention.
https://github.com/golang/go/issues/6623
On Sunday, January 12, 2020 at 1:19:59 AM UTC-5 Fazlul Shahriar wrote:
> I also wrote a tool like that: https://github.com/fhs/golinecov
> It displays coverage report from 'go test'
20 matches
Mail list logo
