[go-nuts] the example always fails if the string contains a trailing space before a newline
Not quite sure if this is a bug but it's annoying:
If the example tested string contains a trailing space before a newline,
the test always fails no matter how.
// this test passes
func ExampleFormat() {
fmt.Println("a\nb")
// Output:
// a
// b
}
// this test fails no matter we put "a" or "a " in the first output line.
func ExampleFormat() {
fmt.Println("a \nb")
// Output:
// a
// b
}
The doc says "The comparison
ignores leading and trailing space." I guess what's going on here is that
it cut the trailing space in the desired output, but doesn't handle the
space in the practical output if it's before a newline. Because the
practical output may come from a 3rd party library, we have to respect how
they print things.
--
You received this message because you are subscribed to the Google Groups
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/golang-nuts/c24ffdb6-bde2-43be-b2ed-9735752bfb95n%40googlegroups.com.
[go-nuts] Is something like SIMD "math/vector" planned?
Hi, I'm interested in high performance applications in Go, and I saw the new "math/bits" package. I think it's very nice that the compiler replaces the Go implementation with special CPU instructions when the architecture supports it. My question is, is there a plan to do something similar with basic arithmetic on small floating point vector types (things like [4]float32) implementing them with SSE/AVX/...? Thank you! -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [go-nuts] Freetype performance
I don't know if it is cached or not, but taking 15ms for rendering 300 characters, most of them spaces, size 12 (102 dpi) on a Intel 2500 seems to much. Here is the profiling: <https://lh3.googleusercontent.com/-nJCSqZMDH4A/WBNqE7Q9yYI/AnE/oYN0CnQqrSIO_mD6mUArRqVbHK3xJGMOwCLcB/s1600/Captura%2Bde%2Bpantalla%2Bde%2B2016-10-28%2B17-03-20.png> I call measure string around 3 times per line because the text is colored and I need to know what pixels should I color. El miércoles, 26 de octubre de 2016, 7:20:30 (UTC+2), Nigel Tao escribió: > > On Tue, Oct 25, 2016 at 9:40 PM, David M. <manxi...@gmail.com > > wrote: > > Is the Go freetype library optimized? Should I expect a similar > performance > > from the original C version? Why freetype don't use an internal cache to > > store most frequent characters? > > Go freetype has had some performance work, but not a lot. > > I don't have any hard data, but I'd expect it to be e.g. within 2x > worse of the original C version, but not as bad as than 10x worse. > > Go freetype should use an internal cache for glyph image masks. Do you > have evidence that this cache is not being used? > > Can you link to your code? > > The https://blog.golang.org/profiling-go-programs blog post is a > little old, but it should still give some leads on how to profile your > Go code at the function level, not just a coarse "70 fps" number. > -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[go-nuts] Freetype performance
Hi, I'm using Go freetype (https://github.com/golang/freetype) for a 3D app using OpenGL. At each frame one portion of the text displayed changes, so I call DrawString() and upload the new image to OpenGL. After some profiling I know that the program runs at 350fps without the DrawString() cost, but it goes down to 70 with it. The program is CPU-limited by the freetype code. (I checked that the OpenGL upload and draw aren't the bottleneck). I'm currently using one texture per line of text, and I only call DrawString when a line of text is changed. My question is, how can I improve the performance of this? I have some ideas, but I don't like them very much: - Using one texture per character instead of per line and cache most characters. In this way DrawString will be only called the first times. However, dealing with this is more complex (kerning) and requires more OpenGL draw calls (1 per character instead of 1 per line). - Call DrawString() in a separate goroutine and upload the image to openGL from the main thread after this separated goroutine has completed its work. This should give almost 350fps with texts refreshing at a lower pace. This may work, but it is a work-around after all. Is the Go freetype library optimized? Should I expect a similar performance from the original C version? Why freetype don't use an internal cache to store most frequent characters? -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[go-nuts] Treeless: distributed NoSQL key-value DB written in Go
Hi, I've just released Treeless (https://github.com/dv343/treeless), a new distributed NoSQL key-value DB written in Go. I have been focused on performance and simplicity and I think I have achieved good results. For example, Get performance is 20% slower compared to Redis, but Set performance can be up to 2x faster than Redis. I think I have reached a stable state. Real usage may show critical bugs, but all tests are passed now. I would love to get some feedback about it, I know it's not perfect, and it needs some polish, but I hope you like it. PS: I didn't thought I would achieve those performance results with Go, using Go has been a really good design choice. Congratulations to all Go developers! -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
