Currently running this bitch on a server with 24 processors clocked at 2.6Ghz, 16GB of ram and fiber connection. Currently pinging about 300-400 IP addresses/second. And the glue holding this bitch together is Go. Look at that simple concurrency model and message passing, it's a thing of fucking beauty. Now to get this running on the other 4 servers just like it.
because the memory management is fucked. You're keeping ints and pointers in automatic storage, and only cleaning them out with non-exact GC, that blows out all your memory all the time on i386 since the runtime is too stupid to tag values properly according to their type
The only valid metric of code quality is WTFs/minute.
Name:
Anonymous2012-06-23 10:42
Haskell, Python, Clojure, r5rs/r6rs, and C are my languages. I'm not sure why I should invest effort into writing new software in Go.
Name:
Anonymous2012-06-23 11:05
>>1 Why aren't you using Go /prog/?
Because I'm using C, C11 threads, OpenCL, and OpenMP and getting twice the performance of Go for socket and networking code. And if I were to use a stateless TCP/IP stack, commonly used by networking professionals for stress-testing, I could get even more performance.
//Ugly as fuck. Needs to be cleaned
I'm constantly perplexed by what /prog/ believes is ugly/sloppy code. That looks like an entirely straightforward implementation of what it is meant to do, excepting that it ignores what happens when i.a > 255.
You could probably revector the whole thing into a function that adds one to one property, checks whether it is still in range, and, if it is not, zeros it and calls itself to add one to the next property. I don't see why you'd need to in such a simple program, though.
Name:
Anonymous2012-06-23 12:43
>>11
If you're thinking semicolon and newline are both separators, like in bash, you'd be wrong. Go actually has ``semicolon insertion'' like JavaShit, so they could attract BASIC/Ruby/Python programmers who use newlines. You might think it's harmless, but it makes the grammar meaningless. In the grammar, all statements are terminated by semicolons, but the lexer inserts ``pretend'' semicolons before newlines depending on the last token. http://golang.org/ref/spec The formal grammar uses semicolons ";" as terminators in a number of productions. Go programs may omit most of these semicolons using the following two rules: [...] http://stackoverflow.com/questions/10826744/semicolon-insertion-ala-google-go-with-flex One caveat. You should never put the opening brace of a control structure (if, for, switch, or select) on the next line. If you do, a semicolon will be inserted before the brace, which could cause unwanted effects. FORCED K&R BRACING OF CODE!
Name:
Anonymous2012-06-23 12:54
You are right about the fact that it is an issue for long-running 32-bit
programs. It may be possible to improve the situation by adhering to the
following rules throughout your program:
- avoid struct types which contain both integer and pointer fields
- avoid struct types containing arrays such as [100]byte (replace it with
*[100]byte or with []byte)
- avoid data structures which form densely interconnected graphs at run-time
- avoid deep call chains at run-time
- replace pointer identity with value equivalence (this can lead to a more
explicit memory management in your program)
- if a data structure contains both long-lived and short-lived fields, move
the short-lived fields into a separate data structure or into local
variables of a function
- avoid integer values which may alias at run-time to an address; make sure
most integer values are fairly low (such as: below 10000)
- if you are using caches to speed up your program, apply the rules
mentioned here to redesign the cache. It may also help to use strings
instead of structs as map keys.
- lower the overall memory consumption of your program
- carefully speed up your program (this may lead to a lower memory
consumption in certain situations)
>>15
Oh my god, that whole thread is awesome. It's got everything: It's not GOs fault, it's your hardware's fault. It's not GOs fault, it's your software's fault. Nobody ever said that GO was a systems language. GC is not shit -- it's just that *this* GC is shit! Nobody ever said that 1.0 would be stable. 32 Bit doesn't exist anymore anyway.
... guess we'll have to stick with C for another 40 years.
http://www.syntax-k.de/projekte/go-review The most important aspect of Go is the target audience. It was designed as a systems programming language, so it aims at lower level software, maybe even an OS kernel. Memory management is handled by a garbage collector. Finally! The benefit of an integrated garbage collector over a bolt-on one like boehm-gc is that you can safely pass a pointer to a local variable or even take the address of a temporary value, and it will just work! Yay!
Go's conservative GC sounds like just the thing I want in my OS kernel!
By the way, using a union as you suggest is also undefined behaviour. The contents of a field of a union become undefined after writing to another field.
uint8_t foo_0 = ((int8_t *)foo)[0];
is perfectly fine, and since it's the first byte: uint8_t foo_0 = (int8_t *)foo;
neverminding endianness
Name:
Anonymous2012-06-23 17:24
>>36
It's not, however C's strict aliasing rule states that no two types must alias the same memory. If you were to compile that with gcc -fstrict-aliasing, the resulting code would probably fail.
>>37
that's not exactly true either, quoting the K&R: the results are implementation-dependent if something is stored as one type and extracted as another. page 148, 2nd Edition
Name:
Anonymous2012-06-23 17:32
>>37
You sure about that? I thought that the fields of a union had to occupy the same region of memory, which would be the size of the largest field (so a union { uint64_t u64; int32_t i32; }; would be 8 bytes).
Name:
Anonymous2012-06-23 17:36
>>41
As a sidenote: The size occupied by a symbol in memory is not necessarily the minimum size possible, for optimization issues.
>>37,41
I suppose that if the union was volatile it would be required to actually update the field, but there's still endianness, padding bits, and integer representations to worry about.
And this thread has officially devolved into a C pissing match.
Name:
Anonymous2012-06-23 18:21
>>37,41,43
It doesn't matter if it's volatile or not, they do overlap in size but after writing to one field it is undefined behavior to read from another.
Name:
Anonymous2012-06-23 18:28
>>46
This is hardly a pissing contest, it's just people who don't know the basics of C and some who do.
>>45
Yes it does. It ensures that the memory is actually written to. union {
char c;
unsigned char u;
} u;
volatile union {
char c;
unsigned char u;
} vu;
u.c = 10; /* may be stored in a register or optimized away */
printf("%u", (unsigned)u.u); /* accessing u.u is undefined behavior */
vu.c = 10; /* must be written to memory */
printf("%u", (unsigned)vu.u); /* vu.u is guaranteed to contain 10 */
Name:
Anonymous2012-06-23 18:45
>>49
but that's just plain wrong... volatile ensures the memory is read, not written, because it warns the compiler that there might be code that is doesn't know about that also uses that memory address
in your example u.c = 10; can surely be optimized but only if the other symbol is not used like you do just after, decent compilers aren't that stupid yet, if u.c = 10; is optimized then u.u will use the same register
but go ahead test it, gcc -O3 that code and see for yourself
Use Perl, OP. join '.', unpack 'C4', pack 'N', $ip++
Name:
Anonymous2012-06-23 22:23
Check em ninjas
Name:
Anonymous2012-06-24 5:34
>>49
It is still undefined behavior to write to the c field and then read from the u field. This is very clear in the standard and it's quite obvious as well considering how many different types of architectures there are out there.
I use Python for everyday programming and web development, C where I must (commercial compiled stuff) with Lua for embedded scripting capabilities, Bash for simple shell scripting, and newLISP for exploratory programming.
Name:
Anonymous2012-06-24 10:18
>>57
Do you even know what a trap representation is? Honest to god I can't believe how unbelievably slow some people on /prog/ are, that very footnote specifically states that the value is unspecified and therefore the program contains undefined behavior.
>>62 When a value is stored in a member of an object of union type, the bytes of the object representation that do not correspond to that member but do correspond to other members take unspecified values.
Name:
Anonymous2012-06-24 12:23
>>30-53,56-57,60-62
Hey! We're supposed to be talking about a shit language, not C!
Let me get you guys back on track: - Go has a shit GC that's worse than Boehm GC.
- Go only runs on x86, ARM and x86-64.
- Go has semicolon insertion.
- Go has forced K&R bracing of code.
- Go has an ugly declaration syntax.
- Go proponents think constant crashes aren't a bug.
- The Go compiler creates a 1 MB Hello World.
Name:
Anonymous2012-06-24 12:26
>>64 - Go has a shit GC that's worse than Boehm GC.
Is that... possible?
>>64,65
I thought it used the Boehm GC, they just tune it poorly.
Name:
Anonymous2012-06-24 12:36
To use Go efficiently you must,
- avoid struct types which contain both integer and pointer fields
- avoid struct types containing arrays such as [100]byte (replace it with *[100]byte or with []byte)
- avoid data structures which form densely interconnected graphs at run-time
- avoid deep call chains at run-time
- replace pointer identity with value equivalence (this can lead to a more explicit memory management in your program)
- if a data structure contains both long-lived and short-lived fields, move the short-lived fields into a separate data structure or into local variables of a function
- avoid integer values which may alias at run-time to an address; make sure most integer values are fairly low (such as: below 10000)
- if you are using caches to speed up your program, apply the rules mentioned here to redesign the cache. It may also help to use strings instead of structs as map keys.
- lower the overall memory consumption of your program
- carefully speed up your program (this may lead to a lower memory consumption in certain situations)