Re: [go-nuts] Re: golang as ML backend v/s C++

2024-04-14 Thread envee
in c++ because of features like garbage > collection. additionally the concurrent features of go are great but > concurrent ML backends will probably be used a lot more than they are read > + written, so probably a fair tradeoff to sacrifice readability for > performance here. > On

[go-nuts] golang as ML backend v/s C++

2024-04-14 Thread envee
After reading briefly about ML and how Python is used as a "veneer" for C++ code, I was wondering why Go is not used as the backend, given it's excellent concurrency support and ease of use. Basically, I was thinking if the backend is written as a shared object in Go, and then used in Python

Re: [go-nuts] Re: HTTP client timeout

2023-05-05 Thread envee
Hi Robert, Yes I have tried HTTP request via curl. That yields a response in about 200ms. On Friday, 5 May 2023 at 22:56:58 UTC+10 Robert Engels wrote: > Have you tried using curl as the client in order to narrow down the > problem? > > On May 5, 2023, at 7:45 AM, envee wrote: &g

Re: [go-nuts] Re: HTTP client timeout

2023-05-05 Thread envee
Jan Mercl wrote: > On Fri, May 5, 2023 at 2:45 PM envee wrote: > > > Still, I don't understand why I cannot achieve higher throughput than > 9000 per second. > > What is the max bitrate of the network interface used in the > measurement and what is the size of the

[go-nuts] Re: HTTP client timeout

2023-05-05 Thread envee
5gclient 40753 411400.39s 1.90s 0K -11.7M mtxmtx-- - 1 R 2923% 5gclient On Friday, 5 May 2023 at 08:33:12 UTC+10 envee wrote: > Hi All, > I have an a

[go-nuts] HTTP client timeout

2023-05-04 Thread envee
Hi All, I have an application which sends HTTP requests at a rate of say 6000 per second. In addition, my application also has about 100K goroutines and these 6000 requests are basically issued by a subset of these goroutines. When I increase the rate to more than 6000, I get the error :

Re: [go-nuts] HTTP2 client sending RST_STREAM to Netty server

2022-05-16 Thread envee
, it does not have enough time to get written out to the socket. This causes the "RoundTripper context deadline exceeded" errors. On Thu, May 12, 2022 at 5:58 PM envee wrote: > Hi Robert, do you have any inputs about this ? > > On Wednesday, 11 May 2022 at 08:31:24 UTC+10 envee

Re: [go-nuts] HTTP2 client sending RST_STREAM to Netty server

2022-05-12 Thread envee
Hi Robert, do you have any inputs about this ? On Wednesday, 11 May 2022 at 08:31:24 UTC+10 envee wrote: > Ok, so you can ignore my comment about the incomplete payload being sent. > It is just that it is being sent in 2 frames as "partial entities". > But I am

Re: [go-nuts] HTTP2 client sending RST_STREAM to Netty server

2022-05-10 Thread envee
just 100ms which have elapsed since the last part of the payload was sent in the DATA frame. On Wednesday, 11 May 2022 at 07:47:15 UTC+10 envee wrote: > Thanks for your reply, Robert. > > I enabled GODEBUG for http2 in my client application and noticed the > following sequenc

Re: [go-nuts] HTTP2 client sending RST_STREAM to Netty server

2022-05-10 Thread envee
t(err error) > > but you should be getting the underlying error when you perform the next > write on the stream - maybe you are not processing this error properly > (there is a code - CANCEL, but also an err). > > On May 10, 2022, at 6:59 AM, Robert Engels wrote: > > Set a b

[go-nuts] HTTP2 client sending RST_STREAM to Netty server

2022-05-10 Thread envee
Hi All, I am using a Go HTTP/2 client (no SSL) to send requests at the rate of around 3000 transactions per second (TPS) to a Web-server which is based on Netty. At lower rates of say around 500 TPS , I do not see this issue, but at rates as high as 2500 - 3000 TPS, I can see that my Go HTTP/2

[go-nuts] HTTP/2 client creating multiple TCP Connections

2022-03-27 Thread envee
I have a telecom client application which connects to an HTTP/2 server (5G telecom application server, to be exact). At startup, I create an HTTP/2 client using the net/http2 Transport. It starts multiple goroutines each of which share/use the same HTTP/2 client connection to send HTTP POST

Re: [go-nuts] Issues when using time.Ticker microsecond duration

2022-02-15 Thread envee
- with no loss of TPS. On Friday, 4 February 2022 at 17:27:43 UTC+11 envee wrote: > Uli, Robert, > I finally settled on using the rate limiter package to achieve what I > need. I have a machine with 40 vCPUs and when I use a rate limiter with a > rate limit of 1000, I am able to generate H

[go-nuts] Go scheduler tracing questions

2022-02-04 Thread envee
Hi All, I have an application which always has about 2000 goroutines running. (I checked this by querying prometheus metrics at regular intervals.) This number sounds reasonably correct to me because at the start I launch 1000 goroutines and each of these 1000 goroutines spawns 1 goroutine each

Re: [go-nuts] Issues when using time.Ticker microsecond duration

2022-02-03 Thread envee
> increases, so with the jitter in the tick time. > > On Thu, Feb 3, 2022 at 1:19 AM Robert Engels wrote: > >> I am unclear why you need to use an N of M. I would make sure the hardest >> case is handled and you can use a variety of techniques to partition the >> work. &

Re: [go-nuts] Issues when using time.Ticker microsecond duration

2022-02-02 Thread envee
or even use a Semaphore. I presume using a Semaphore, will allow a good amount of random N goroutines out of M goroutines to execute. On Thursday, 3 February 2022 at 10:26:28 UTC+11 envee wrote: > Thanks Robert, Uli and Ian for your suggestions. > > I think what I will probably do is use

Re: [go-nuts] Issues when using time.Ticker microsecond duration

2022-02-02 Thread envee
Thanks Robert, Uli and Ian for your suggestions. I think what I will probably do is use a Ticker with a duration of 1ms. At every 1ms, I will "wake-up" N number of goroutines to trigger HTTP requests. That number N = (request rate per second / 1000) = requests per ms. So, if I need to ensure a

Re: [go-nuts] Issues when using time.Ticker microsecond duration

2022-01-30 Thread envee
ire > specialized constructs if not a real time OS to efficiently (or even at > all). > > On Jan 30, 2022, at 9:16 PM, envee wrote: > > Thanks, but I am not sure how that reference solves the issue ? > > Or are you suggesting that the only way is to use Cgo and invoke

Re: [go-nuts] Issues when using time.Ticker microsecond duration

2022-01-30 Thread envee
ang/go/issues/27707 > > On Jan 30, 2022, at 5:50 PM, envee wrote: > > Hi All, > > I understand this issue has been discussed in the past, and I have seen a > few comments from Ian and Russ Cox about this topic, but I could not arrive > at a conclusion about how I can m

[go-nuts] Issues when using time.Ticker microsecond duration

2022-01-30 Thread envee
Hi All, I understand this issue has been discussed in the past, and I have seen a few comments from Ian and Russ Cox about this topic, but I could not arrive at a conclusion about how I can make the time.Ticker send me ticks at atleast close to the Ticker duration I specify. At the moment, I am

[go-nuts] behaviour (issue) of time.Ticker microsecond duration ticks

2022-01-30 Thread envee
Hi All, I understand this issue has been discussed in the past, and I have seen a few comments from Ian and Russ Cox about this topic, but I could not arrive at a conclusion about how I can make the time.Ticker send me ticks at atleast close to the Ticker duration I specify. At the moment, I am

[go-nuts] Comparing QuickUnion with WeightedQuickUnion (from Bob Sedgewick's book on Algorithms)

2021-09-28 Thread envee
Hi All, Last year, I had asked something similar about comparing QuickUnion with QuickFind although that turned out to be a flaw in my benchmarking function. This time, I am comparing the QuickUnion with WeightedQuickUnion. I ran benchmarking on this code and noticed that the WeightedQuickUnion

Re: [go-nuts] Re: go scheduler tracing

2020-06-17 Thread envee
Hi Robert, It is in my first post in this thread. Basically, I want to know why all my logical processors are not being used in my program. Thanks. On Thursday, 18 June 2020 07:24:40 UTC+10, Robert Engels wrote: > > What is the question? > > On Jun 17, 2020, at 4:06 PM, envee >

[go-nuts] Re: go scheduler tracing

2020-06-17 Thread envee
Closer GoRoutine /// go func() { wg.Wait() close(qObjChannel) fmt.Println("Quarantined Objects List") fmt.Println("") }() qFound := false for qObjList := range qObjChannel { for _, qObj := range qObjLis

[go-nuts] go scheduler tracing

2020-06-15 Thread envee
I am running a program which reads multiple gzipped input files and performs some processing on each line of the file. It creates 8 goroutines (1 per input file which is to be processed. the number of such files can be thought to remain 8 at the max). Each of the go routines send to a buffered

[go-nuts] Re: QuickUnion slower than QuickFind : array lookup taking too long ?

2020-02-16 Thread envee
> 1488236 ns/op > BenchmarkQuickFind/BenchmarkQuickFind1-4 7 > 150857786 ns/op > PASS > ok command-line-arguments 443.341s > > QuickUnion outperforms QuickFind in every case, and massively outperforms > on large sets. Again, I have no

[go-nuts] Re: QuickUnion slower than QuickFind : array lookup taking too long ?

2020-02-16 Thread envee
takes about 200 milliseconds and is one of the longest time-taking instruction. On Saturday, 15 February 2020 22:24:02 UTC+11, envee wrote: > > Hi, > > I am using the following version of go : > PS C:\Temp> go version > go version go1.13.5 windows/amd64 > > I am trying

[go-nuts] Re: QuickUnion slower than QuickFind : array lookup taking too long ?

2020-02-15 Thread envee
: > > On Saturday, February 15, 2020 at 6:24:02 AM UTC-5, envee wrote: >> >> Hi, >> >> I am using the following version of go : >> PS C:\Temp> go version >> go version go1.13.5 windows/amd64 >> >> I am trying to compare the performance of Qui

[go-nuts] QuickUnion slower than QuickFind : array lookup taking too long ?

2020-02-15 Thread envee
Hi, I am using the following version of go : PS C:\Temp> go version go version go1.13.5 windows/amd64 I am trying to compare the performance of QuickUnion (just the basic one with no weighting/ranking/path compression) and QuickFind algorithms. My benchmarking test cases basically create a