From slow to SIMD: A Go optimization story

Re:From slow to SIMD: A Go optimization story by camdencheek on Tuesday January 23, 2024 @05:13PM (#39110692)

Definitely possible! However, I prefer to avoid cgo wherever possible for more than just the overhead.

In my experience:

- It complicates builds by requiring a C toolchain

- It makes single, static binaries more difficult

- It makes portability more difficult (not that assembly is portable though)

- It causes difficult-to-debug issues (I recently ran into an issue where MacOS signing changed, causing all my cgo binaries to be killed on startup)

- Debuggers don't work across Cgo boundaries (they do with go ASM!)

I think Dave Cheney said it best: https://dave.cheney.net/2016/01/18/cgo-is-not-go

[ Parent | on HN ]

Re:From slow to SIMD: A Go optimization story by pjmlp on Wednesday January 24, 2024 @01:33AM (#39114322)

The whole "cgo is not Go" bashing is a kind of joke, maybe if Go 2 ever comes to light, one of the first breaking changes should be to remove cgo.

There, beautiful Go code from that point onwards.

[ Parent | on HN ]

Re:From slow to SIMD: A Go optimization story by beautron on Wednesday January 24, 2024 @02:55AM (#39114770)

Dear Lord, no! I depend on cgo for my game!

What's more, I have no complaints about cgo. It hasn't been a performance problem at all (my game runs smoothly at 240hz). And the interface for binding to C is quite simple and nice to work with (I made my own bindings to SDL2, OpenGL, and Steamworks).

Cgo did make cross-compiling trickier to set up, but I managed to do it with a fair amount of elbow grease (Windows and MacOS builds on my Linux desktop).

[ Parent | on HN ]

Re:From slow to SIMD: A Go optimization story by pjmlp on Wednesday January 24, 2024 @04:30AM (#39115386)

That is my point with my sarcastic remark, cgo should be embraced for the workflows it offers, instead of the whole "cgo is not Go" drama.

[ Parent | on HN ]