Re: [racket-users] Speeding up the conversion of flvectors to string

Thanks Sam, Robby. Your explanations make perfect sense. I was conflating contract exceptions with the contract library. I had just assumed they were one and the same. Avoiding the contract library for performance reasons in some cases also seems quite reasonable to me. Thanks again! --

Re: [racket-users] Speeding up the conversion of flvectors to string

A little more information about these things. I'd say that there are two obstacles to having the racket/contract library actually be the source of the contract checks in all functions exported by the racket language/library: 1) dependency layering. The racket/contract library is really a

Re: [racket-users] Speeding up the conversion of flvectors to string

On Tue, Jun 29, 2021 at 12:04 PM Jonathan Simpson wrote: > > On Monday, June 28, 2021 at 10:25:36 PM UTC-4 Sam Tobin-Hochstadt wrote: >> >> On Mon, Jun 28, 2021 at 9:46 PM Jonathan Simpson wrote: >> > >> > On Sunday, June 27, 2021 at 10:29:55 AM UTC-4 Robby Findler wrote: >> >> >> >> Replacing `

Re: [racket-users] Speeding up the conversion of flvectors to string

On Monday, June 28, 2021 at 10:25:36 PM UTC-4 Sam Tobin-Hochstadt wrote: > On Mon, Jun 28, 2021 at 9:46 PM Jonathan Simpson wrote: > > > > On Sunday, June 27, 2021 at 10:29:55 AM UTC-4 Robby Findler wrote: > >> > >> Replacing ` (~r x #:precision 1)` with `(number->string x)` and ditto > for

Re: [racket-users] Speeding up the conversion of flvectors to string

On 2021-06-28 21:18, Alessandro Motta wrote:> One thing that is still puzzling / worrying me: I completely failed to > identify the actual bottleneck when profiling the code. > > Did I simply misinterpret the profiling output / flame graph? Or is the > problem rather that memory allocations and

Re: [racket-users] Speeding up the conversion of flvectors to string

On Mon, Jun 28, 2021 at 9:46 PM Jonathan Simpson wrote: > > On Sunday, June 27, 2021 at 10:29:55 AM UTC-4 Robby Findler wrote: >> >> Replacing ` (~r x #:precision 1)` with `(number->string x)` and ditto for >> `y` eliminates the overhead of contracts and brings about another 4x speedup >> on my

Re: [racket-users] Speeding up the conversion of flvectors to string

On Sunday, June 27, 2021 at 10:29:55 AM UTC-4 Robby Findler wrote: > Replacing ` (~r x #:precision 1)` with `(number->string x)` and ditto for > `y` eliminates the overhead of contracts and brings about another 4x > speedup on my machine. > This is because the compiler is able to remove the

Re: [racket-users] Speeding up the conversion of flvectors to string

I think you found a slowdown that's just a severe as the one we've been talking about and, once that one'd been cleared up, you might have seen the other one, perhaps in the calls to string-append. But you are right that some costs (like gc) are smeared out across the whole computation and thus

Re: [racket-users] Speeding up the conversion of flvectors to string

On 27.06.21 19:34, Robby Findler wrote: > On Sun, Jun 27, 2021 at 11:58 AM Alessandro Motta > wrote: > > I also like Jens' code for its pure functional elegance. I'm surprised > that building up a long list of short strings before joining them is so > much

Re: [racket-users] Speeding up the conversion of flvectors to string

Bogdan Popa writes: > Ah! You're right. When I make the change you suggest, the program > takes 5s to run. Filed under "Accidentally Not Quadratic" . The program actually takes 2.5s to run. I missed the fact that I had made two separate calls to `string-append!` in that version of the

Re: [racket-users] Speeding up the conversion of flvectors to string

Matthew Flatt writes: > At Sun, 27 Jun 2021 21:36:09 +0300, Bogdan Popa wrote: > Your program does run fast on my machine, but I think it's because this > line doesn't have the intended bad effect: > >> (string-copy! dst 0 dst 0 len) ;; intentionally performing pointless >>

Re: [racket-users] Speeding up the conversion of flvectors to string

At Sun, 27 Jun 2021 21:36:09 +0300, Bogdan Popa wrote: > While I think the complexity piece is important, I feel like it's worth > pointing out just how much more expensive the allocation -- and its > ramifications, like the resulting GC pressure and CPU cache misses -- is > than one might think.

Re: [racket-users] Speeding up the conversion of flvectors to string

Anyone got an implementation of a mutable StringBuilder-like object? I could use it in Rebellion's implementation of `into-string` which currently isn't quadratic, but it definitely has the allocation problem. On Sunday, June 27, 2021 at 11:36:14 AM UTC-7 bogdan wrote: > While I think the

Re: [racket-users] Speeding up the conversion of flvectors to string

While I think the complexity piece is important, I feel like it's worth pointing out just how much more expensive the allocation -- and its ramifications, like the resulting GC pressure and CPU cache misses -- is than one might think. Here's a quadratic version of the code that avoids

Re: [racket-users] Speeding up the conversion of flvectors to string

Den søn. 27. jun. 2021 kl. 18.58 skrev Alessandro Motta : > I also like Jens' code for its pure functional elegance. I'm surprised > that building up a long list of short strings before joining them is so > much faster. After all, isn't the final `string-join` essentially doing > what the

Re: [racket-users] Speeding up the conversion of flvectors to string

On Sun, Jun 27, 2021 at 11:58 AM Alessandro Motta wrote: > > I also like Jens' code for its pure functional elegance. I'm surprised > that building up a long list of short strings before joining them is so > much faster. After all, isn't the final `string-join` essentially doing > what the

Re: [racket-users] Speeding up the conversion of flvectors to string

Thank you all for these quick and helpful responses! I've noticed the `call-with-output-string` mechanism while browsing various Racket code bases, but was under the impression that this is "just" a convenient abstraction over strings. Based on Bogdan's code and Robby's explanation, it's now

Re: [racket-users] Speeding up the conversion of flvectors to string

Replacing ` (~r x #:precision 1)` with `(number->string x)` and ditto for `y` eliminates the overhead of contracts and brings about another 4x speedup on my machine. That may not work, tho, depending on Alessandro's original usecase, since the strings are different. I was also going to, as

Re: [racket-users] Speeding up the conversion of flvectors to string

I forgot to mention this earlier, but it might be enlightening to run the two versions of the program with the `PLTSTDERR` environment variable set to "error debug@GC" to see GC debug messages. For example: env PLTSTDERR='error debug@GC' racket flvector-to-coordinates-string.rkt >/dev/null

Re: [racket-users] Speeding up the conversion of flvectors to string

As Bogdan writes, the problem is repeatedly calling `string-append`. Instead one can make a list of all the small strings and then use `string-join` at the end. #lang racket (require racket/flonum) (define (xy->string x y) (string-append (~r x #:precision 1) "," (~r y #:precision 1)))

Re: [racket-users] Speeding up the conversion of flvectors to string

Hi Alessandro, Here is a version of your program that is about 30 times faster on my machine (9s -> 300ms): #lang racket/base (require racket/flonum racket/format racket/port) (define (xy-vectors->string x-vec y-vec) (call-with-output-string