FAQ
I've updated it to use buffered rendering and it's now competitive with the
C implementation (around 98% of the C framerate), which I think reflects
quite well on Go. The only thing I found myself missing was the -> operator
(or else automatic pointer dereferencing), but that's just syntax.
On Friday, 18 October 2013 21:17:14 UTC+8, Jim Teeuwen wrote:

As Tom mentioned, it is far more effective to use the shader pipeline.
Modern opengl applications are all expected to use it. For all intents and
purposes, the Fixed Function pipeline should be considered deprecated,
unless you are stuck with really old/limited hardware.

Even with vertex buffers and shaders, you will still not get the same
performance out of Go as you will out of C/C++ or other languages which
have a calling convention in line with C. C calls are fairly expensive out
of necessity. This will get slightly better in Go 1.2, but is still
something you have to keep in mind.

If performance really becomes an issue, it helps to bundle some common
openGL operations in a C function, which you then call from Go.


On Friday, October 18, 2013 3:00:51 PM UTC+2, jonathan....@gmail.comwrote:
Thanks Tom. I was using immediate mode to save time; I'll be writing the
code in a few different languages (including Java), and immediates are
easier to write. But if using immediates is going to turn it into more a
benchmark of FFI speed than of OpenGL, I'll consider using vertex buffers
instead.

-Jonathan
On Friday, 18 October 2013 20:47:27 UTC+8, Tom Payne wrote:
On 18 October 2013 14:37, wrote:

I'm planning on running an OpenGL particle animation benchmark within
the next month or two; I've just finished the Go implementation, and
wondered if anyone here could offer any suggestions for speeding it up. It
currently achieves a framerate of around 39 frames per second on this
machine, compared to around 49 for the C implementation.

I've profiled it, and the OpenGL/GLFW library functions seem to feature
prominently, particularly the calling of 'evacuate' on the maps they use.
There are also some calls to growslice, so I'm thinking I might be able to
set a slice capacity somewhere in the go-gl source to avoid them, but I'm
not sure how to avoid evacuate (the code avoids use of slices and maps, so
any that feature in the profile must be from library calls).

The code is here:
https://github.com/logicchains/ParticleBench/blob/master/Go.go

I'm far from an expert, but as I understand it, calls from Go to C
aren't as quick as we'd all like them to be. The code uses OpenGL's old
fixed-function pipeline and immediate mode, which makes a lot of calls to
C. If you were to use vertex buffers and shaders you'll certainly require
an order of magnitude fewer calls to C and you'll also make more efficient
use of resources (e.g. you'll only need to upload the vertices to the GPU
once, instead of doing it for every frame).

Regards,
Tom
--
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+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Search Discussions

Discussion Posts

Previous

Related Discussions

Discussion Navigation
viewthread | post
posts ‹ prev | 6 of 6 | next ›
Discussion Overview
groupgolang-nuts @
categoriesgo
postedOct 18, '13 at 12:37p
activeOct 25, '13 at 10:24a
posts6
users4
websitegolang.org

People

Translate

site design / logo © 2021 Grokbase