Improvement to Go as new solution?

[mpldr]

I made the following changes to Go solution 2 which yielded drastically improved performance. However, since this solution parallelizes the computation I am not sure whether this is fitting as just an improvement to solution 2 which explicitly states that it is not parallelized.

I'd also like to ask all Go developers whether I maybe made a mistake and just overlooked it, because the results on my Ryzen 7 2700X are as follows:

# before patch
ssovest-go;4411;5.001076872;1;algorithm=base,faithful=yes,bits=1
# after patch
ssovest-go;56936;5.000778586;1;algorithm=base,faithful=yes,bits=1

This improvement is enough to make it suspicious in my eyes, but I can not find an error like just increasing passes without completing the sieve beforehand.

diff --git a/PrimeGo/solution_2/main.go b/PrimeGo/solution_2/main.go
index e2bf12b..c767b1d 100644
--- a/PrimeGo/solution_2/main.go
+++ b/PrimeGo/solution_2/main.go
@@ -1,11 +1,15 @@
 package main
 
 import (
+	"context"
 	"flag"
 	"fmt"
 	"math"
 	"math/bits"
+	"runtime"
 	"time"
+
+	"golang.org/x/sync/semaphore"
 )
 
 var primeCounts = map[uint64]uint64{
@@ -60,7 +64,6 @@ func (s Sieve) ValidateResults() bool {
 func main() {
 	var limit uint64
 	var duration time.Duration
-	var sieve Sieve
 
 	flag.Uint64Var(&limit, "limit", 1000000, "limit")
 	flag.DurationVar(&duration, "time", 5*time.Second, "duration")
@@ -71,15 +74,19 @@ func main() {
 	start := time.Now()
 	time.AfterFunc(duration, func() { stop <- struct{}{} })
 
+	sem := semaphore.NewWeighted(int64(runtime.NumCPU()))
 loop:
 	for {
 		select {
 		case <-stop:
 			break loop
 		default:
-			sieve = Sieve{make([]uint8, (limit+15)/16), limit}
-			sieve.RunSieve()
-			passes++
+			sem.Acquire(context.Background(), 1)
+			go func(sieve Sieve) {
+				defer sem.Release(1)
+				sieve.RunSieve()
+				passes++
+			}(Sieve{make([]uint8, (limit+15)/16), limit})
 		}
 	}
 	fmt.Printf("ssovest-go;%v;%v;1;algorithm=base,faithful=yes,bits=1\n", passes, time.Since(start).Seconds())

[rbergen]

If an alternative implementation changes one or more of the key characteristics (algorithm, faithfulness, bits per prime candidate) then a new solution could be warranted. That being said, we now do have a multithreaded Go solution in place (PrimeGo/solution_3), so then the question becomes if your implementation improves that solution's performance.