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.
And I know that the last part is a little hacky and that the IP functions should be moved to their own source file. Bite me.
Why aren't you using Go /prog/?
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)