using the pthreads library would be a bit more performant than Go's concurrency if you can fan out your processing for bulk stuff like what pippellia (nprofile…akns) wants to do, and really the flexibility of Go's concurrency is overkill for simple parallel work, it's a little confusing to do it that way, it's more optimized towards event processing for servers, but the design of it was originally created for GUI (newsqueak)
go is actually not so great at parallelism, you can gain as much as 20% even while adding the overhead of an IPC and using single threaded worker processes (at least that was the situation in 2020, not sure maybe they have improved it by now) - but having said that, it's so much faster than for example python or javascript, that losing that last 20% of parallelism is probably not gonna hurt that much, and if you want it scaled up that much, like on a threadripper or epyc or something, well, you'd probably not be using Go, but C and pthread
go is pretty fast for single thread processing, not much slower than C, especially if you don't allocate and discard a lot of memory, walking trees and graphs is cheap, everything stays on the stack/registers
but yes, explicit types are a thing... i ported a hamming code algorithm from C some years back and the hardest part of the process was figuring out the implied bid widths, and this is pretty much par for teh course with C, your use of explicit types is probably a bit uncommon among C programmers
personally, i would remove the distinction in Go where on 32 bit hardware it treats the `int` type as 32 bits... it should just always be 64 bits, except where used in array indexes, this is one area it's implicit, and 64 bit array indexes is a waste of space, ain't nobody got that much memory lol, but it's not a difference that anyone really encounters because Go on embedded 32 bit devices is pretty much not a thing, except for tinygo, which is not really go, though it is go (has more controls for memory management, but still lets you do all the nice interface/dynamic array stuff, and Go's concurrency can even operate on a single thread
mleku / mleku™️
npub1fj…mleku
2024-09-16 19:08:13
in reply to nevent1q…y2xh
Author Public Key
npub1fjqqy4a93z5zsjwsfxqhc2764kvykfdyttvldkkkdera8dr78vhsmmlekuPublished at
2024-09-16 19:08:13Event JSON
{
"id": "c21419d2177d1e4512cb1b57b2d9c6cf5ae4f43e7a7ba9d1bf25bd691e5026d8",
"pubkey": "4c800257a588a82849d049817c2bdaad984b25a45ad9f6dad66e47d3b47e3b2f",
"created_at": 1726513693,
"kind": 1,
"tags": [
[
"p",
"f683e87035f7ad4f44e0b98cfbd9537e16455a92cd38cefc4cb31db7557f5ef2",
"wss://auth.nostr1.com/",
"pippellia"
],
[
"p",
"036533caa872376946d4e4fdea4c1a0441eda38ca2d9d9417bb36006cbaabf58",
"wss://relay.nostr.band/",
"ChipTuner"
],
[
"e",
"9306fcd196544fa1c6798d9dbcf99b87bf6cb98299d97bbc12b141041aad3c6a",
"wss://relay.nostr.band/",
"root"
],
[
"e",
"574f927db501686ec98f35471f96716a52434cdbe0390d0689f967dd87180a0b",
"",
"mention"
],
[
"e",
"35a7bd6aa8d20ee1d575e2a9c98caade649ac123a4298342bada7e7b9ff921f6",
"wss://relay.nostr.band/",
"reply",
"036533caa872376946d4e4fdea4c1a0441eda38ca2d9d9417bb36006cbaabf58"
]
],
"content": "using the pthreads library would be a bit more performant than Go's concurrency if you can fan out your processing for bulk stuff like what nostr:nprofile1qy2hwumn8ghj7un9d3shjtnyv9kh2uewd9hj7qghwaehxw309aex2mrp0yhxummnw3ezucnpdejz7qgkwaehxw309ash2arg9ehx7um5wgcjucm0d5hsz9mhwden5te0wfjkccte9ec8y6tdv9kzumn9wshsqg8ks058qd0h4485fc9e3naaj5m7zez44ykd8r80cn9nrkm42l677g2aakns wants to do, and really the flexibility of Go's concurrency is overkill for simple parallel work, it's a little confusing to do it that way, it's more optimized towards event processing for servers, but the design of it was originally created for GUI (newsqueak)\n\ngo is actually not so great at parallelism, you can gain as much as 20% even while adding the overhead of an IPC and using single threaded worker processes (at least that was the situation in 2020, not sure maybe they have improved it by now) - but having said that, it's so much faster than for example python or javascript, that losing that last 20% of parallelism is probably not gonna hurt that much, and if you want it scaled up that much, like on a threadripper or epyc or something, well, you'd probably not be using Go, but C and pthread\n\ngo is pretty fast for single thread processing, not much slower than C, especially if you don't allocate and discard a lot of memory, walking trees and graphs is cheap, everything stays on the stack/registers\n\nbut yes, explicit types are a thing... i ported a hamming code algorithm from C some years back and the hardest part of the process was figuring out the implied bid widths, and this is pretty much par for teh course with C, your use of explicit types is probably a bit uncommon among C programmers\n\npersonally, i would remove the distinction in Go where on 32 bit hardware it treats the `int` type as 32 bits... it should just always be 64 bits, except where used in array indexes, this is one area it's implicit, and 64 bit array indexes is a waste of space, ain't nobody got that much memory lol, but it's not a difference that anyone really encounters because Go on embedded 32 bit devices is pretty much not a thing, except for tinygo, which is not really go, though it is go (has more controls for memory management, but still lets you do all the nice interface/dynamic array stuff, and Go's concurrency can even operate on a single thread",
"sig": "4be7163977d9d73601c740efe30c1ccd7be950dc3660d8f7996fecf248259e140da939146dce1bbab7039309a80f2ddb6c1d8126e1ba10b3ee1d696b659d4574"
}