Re: [go-nuts] Why traversing Go hashmap so slower then C++ hashmap

On Tue, Jun 28, 2022 at 9:56 PM Yan Li wrote: > > Question: > Go 161.385148ms vs C++ ms:31 > Go 851.517707ms vs C++ ms:104 > My question is why traversing go map Significantly slowly? > Can it be improved? I don't know exactly why there is a speed difference. That said, there are significant dif

[go-nuts] Why traversing Go hashmap so slower then C++ hashmap

*System env:* $ lsb_release -a No LSB modules are available. Distributor ID: Ubuntu Description:Ubuntu 18.04.6 LTS Release:18.04 Codename: bionic $ go version go version go1.18.3 linux/amd64 $ g++ -v gcc version 7.5.0 (Ubuntu 7.5.0-3ubuntu1~18.04) *Test traversing Go hashmap:*

Re: [go-nuts] Temporary prevent preemption?

The "asyncpreemptoff" debug option may be useful. See https://pkg.go.dev/runtime. Specifically, try running your program after doing "export GODEBUG=asyncpreemptoff=1". I'll leave it to others to explain why this can be risky; especially in a context like you described. On Tue, Jun 28, 2022 at 6:4

[go-nuts] Re: Temporary prevent preemption?

Btw. I forgot to mention that CPU load is typically <2-5% on a 32 core server. - Running in stand-alone as testing purposes speed is let say 100% - Running two pieces code separately and connected via IPC methods, speed is also 100%, but IPC latency jitter is a problem - But running two pieces cod

[go-nuts] Temporary prevent preemption?

Hey, I'm writing some latency & speed sensitive routines that are processing large amount of signal data in batches. When I run this in a standalone program the speed is fine. However when I combine this to the rest of software (>1000 goroutines, mainly network code) the speed gets reduced by

Re: [go-nuts] ListenAndServeTLS() (pem and key files for private network)

the package only helps to setup a special tls listener to be used with the http server, as shown in the example. the http handler code and routing is not affected in any way and is completely independent. the special listener uses a ca cert to generate new server certs every time you reach under

Re: [go-nuts] Is this a compilation optimization bug ?

On Tue, Jun 28, 2022 at 5:47 AM 'Dan Kortschak' via golang-nuts wrote: > > On Mon, 2022-06-27 at 23:32 -0700, iori yamada wrote: > > Running the code in the link below times out, is this a bug? > > Looking at the assembly, it seems that the instructions corresponding > > to the if statement have b

Re: [go-nuts] Is this a compilation optimization bug ?

On Mon, 2022-06-27 at 23:32 -0700, iori yamada wrote: > Running the code in the link below times out, is this a bug? > Looking at the assembly, it seems that the instructions corresponding > to the if statement have been removed due to optimization. > > https://go.dev/play/p/CZX4mbyrp37 > > The fol

[go-nuts] Is this a compilation optimization bug ?

Running the code in the link below times out, is this a bug? Looking at the assembly, it seems that the instructions corresponding to the if statement have been removed due to optimization. https://go.dev/play/p/CZX4mbyrp37 The following is a description of how I thought it was a bug. In the fi

Re: [go-nuts] ListenAndServeTLS() (pem and key files for private network)

hi hugh, i played around with the same idea six years ago, resulting in https://github.com/mb0/localca it will use a self signed root cerificate and creates new child certificates specific to the requested hostname, be it an ip or a name like my_local.box i haven't tested it for awhile, bu

[go-nuts] Re: ListenAndServeTLS() (pem and key files for private network)

If it helps, I put this together for my own project - it's not a package but a bunch of convenience functions/methods for generating TLS certs and keys (there is a lot of implementation specific stuff), but the general shape may help you: https://github.com/itrs-group/cordial/blob/main/tools/ge