/prog/ - Go — World4ch

Name: Anonymous 2012-06-23 6:16

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.

http://pastebin.com/rqEvpszX
Currently running at: 177 valid IPs/second, 582 IPs/second

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: Anonymous 2012-06-23 7:35

>>1
Because it's not Lisp.

Name: Anonymous 2012-06-23 7:52

time that piece of shit code and then come back

Name: Anonymous 2012-06-23 7:56

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

https://groups.google.com/group/golang-nuts/browse_thread/thread/ab1971bb9459025d

Name: Anonymous 2012-06-23 8:15

Stupid design decisions, like the lack of polymorphism except-when-we-say-so, and error codes instead of a proper exception/condition system.

Name: Anonymous 2012-06-23 8:19

Wait, you're just calling exec("ping")? Why didn't you write this in two lines of bash?

Name: !L33tUKZj5I 2012-06-23 8:27

Jesus christ man, even I'm shaking my head.

Name: Anonymous 2012-06-23 8:43

/prog/ - Constructive Criticism

The only valid metric of code quality is WTFs/minute.

Name: Anonymous 2012-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: Anonymous 2012-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.

Name: Anonymous 2012-06-23 11:07

>>1
No semi-colons? Wtf, looks like FIOC.

Name: Anonymous 2012-06-23 11:40

Because that aint Cilk nigga

Name: Anonymous 2012-06-23 12:02

//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: Anonymous 2012-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: Anonymous 2012-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) - call runtime.GC() (at the right moment)
https://groups.google.com/group/golang-nuts/browse_thread/thread/ab1971bb9459025d

Name: Anonymous 2012-06-23 14:28

>>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.

Name: VIPPER 2012-06-23 14:47

Enjoy your segmentation fault

Name: Anonymous 2012-06-23 15:01

Call me back when Google implements their search engine in Go. (They won't. Go is shit.)

Name: Anonymous 2012-06-23 15:03

>>16
Or you can just use C++.

Name: Anonymous 2012-06-23 15:17

>>17
VIP QUALITY

Name: Anonymous 2012-06-23 15:32

>>13
What he needs is the ability to extract bytes from a single 4-byte integer.

Name: Anonymous 2012-06-23 15:36

>>1
LMAO! Executing the ping command probably takes so much time compared to everything else that you could have written it in Ruby.

Name: Anonymous 2012-06-23 15:52

>>4 i386 is dying/dead. I have not encountered a non x86_64 server in production in the past two years.

>>6
>>22
I plan on rewriting the ping part of this code to use the net package.

>>12
>Cilk
Thats actually pretty cool, wish I had found that a few years ago.

>>13 Nested for loops just look bad and hacky. I'm probably going to use this project as a basis for a few other tools.

>>14 I bet you think gofmt is a bad thing.

>>21 That looks ugly as fuck and the you save a tiny bit of memory. 1990 called.

Name: Anonymous 2012-06-23 15:52

>>21
You're probably giving him too much credit by assuming he understands anything about bitwise operation.

Name: Anonymous 2012-06-23 16:10

>>23
That looks ugly as fuck and the you save a tiny bit of memory. 1990 called.
You literally reinvented the 4-byte increment by 1.

Name: Anonymous 2012-06-23 16:13

>>24

#define HAXYOURANUS(byte, var) ((byte >> (var*8)) & ((1<<8)-1))

#include <stdio.h>

int main() {
    int var = 0xFF00FF00;
    int i;

    for (i = 0; i < 4; i++)
      printf("%d\n", HAXYOURANUS(var, i));

    return 0;
}

Name: Anonymous 2012-06-23 16:19

>>25
Except with about 10 times more instructions, several of which are branches.

Name: Anonymous 2012-06-23 16:20

>>27
And 10 times less readable.

Name: Anonymous 2012-06-23 16:33

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!

Name: Anonymous 2012-06-23 16:41

Can you name a language meant to replace C that isn't actually worse?

Name: Anonymous 2012-06-23 16:43

>>30
No. All of the better languages weren't created with C in mind at all.

Name: Anonymous 2012-06-23 16:45

>>21
Which is stupidly easy in C:

int32_t foo;

uint8_t foo_0 = ((int32_t*)foo)[0];

/* ... */

Name: Anonymous 2012-06-23 16:56

>>32
No. The cast should be (uint8_t*) but even then it's undefined behaviour.

Name: Anonymous 2012-06-23 17:15

>>33
It should be uint8_t, you're right, but why is it undefined? Endianness?

Name: Anonymous 2012-06-23 17:16

>>33
Only with strict aliasing rules, although you could effectively circumvent those with:

union {

    uint32_t u32;

    uint8_t u8[4];

} ip;

There's still the matter of endianness, however for this particular program that's utterly irrelevant.

Name: Anonymous 2012-06-23 17:21

>>35
IIRC casting a pointer into a pointer on an incompatible type is undefined behaviour.

Name: 36 2012-06-23 17:23

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.

Name: Anonymous 2012-06-23 17:24

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: Anonymous 2012-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.

Name: Anonymous 2012-06-23 17:28

>>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

Go

1 Name: Anonymous 2012-06-23 6:16

2 Name: Anonymous 2012-06-23 7:35

3 Name: Anonymous 2012-06-23 7:52

4 Name: Anonymous 2012-06-23 7:56

5 Name: Anonymous 2012-06-23 8:15

6 Name: Anonymous 2012-06-23 8:19

7 Name: !L33tUKZj5I 2012-06-23 8:27

8 Name: Anonymous 2012-06-23 8:43

9 Name: Anonymous 2012-06-23 10:42

10 Name: Anonymous 2012-06-23 11:05

11 Name: Anonymous 2012-06-23 11:07

12 Name: Anonymous 2012-06-23 11:40

13 Name: Anonymous 2012-06-23 12:02

14 Name: Anonymous 2012-06-23 12:43

15 Name: Anonymous 2012-06-23 12:54

16 Name: Anonymous 2012-06-23 14:28

17 Name: VIPPER 2012-06-23 14:47

18 Name: Anonymous 2012-06-23 15:01

19 Name: Anonymous 2012-06-23 15:03

20 Name: Anonymous 2012-06-23 15:17

21 Name: Anonymous 2012-06-23 15:32

22 Name: Anonymous 2012-06-23 15:36

23 Name: Anonymous 2012-06-23 15:52

24 Name: Anonymous 2012-06-23 15:52

25 Name: Anonymous 2012-06-23 16:10

26 Name: Anonymous 2012-06-23 16:13

27 Name: Anonymous 2012-06-23 16:19

28 Name: Anonymous 2012-06-23 16:20

29 Name: Anonymous 2012-06-23 16:33

30 Name: Anonymous 2012-06-23 16:41

31 Name: Anonymous 2012-06-23 16:43

32 Name: Anonymous 2012-06-23 16:45

33 Name: Anonymous 2012-06-23 16:56

34 Name: Anonymous 2012-06-23 17:15

35 Name: Anonymous 2012-06-23 17:16

36 Name: Anonymous 2012-06-23 17:21

37 Name: 36 2012-06-23 17:23

38 Name: Anonymous 2012-06-23 17:24

39 Name: Anonymous 2012-06-23 17:24

40 Name: Anonymous 2012-06-23 17:28

Name: Anonymous 2012-06-23 6:16

Name: Anonymous 2012-06-23 7:35

Name: Anonymous 2012-06-23 7:52

Name: Anonymous 2012-06-23 7:56

Name: Anonymous 2012-06-23 8:15

Name: Anonymous 2012-06-23 8:19

Name: !L33tUKZj5I 2012-06-23 8:27

Name: Anonymous 2012-06-23 8:43

Name: Anonymous 2012-06-23 10:42

Name: Anonymous 2012-06-23 11:05

Name: Anonymous 2012-06-23 11:07

Name: Anonymous 2012-06-23 11:40

Name: Anonymous 2012-06-23 12:02

Name: Anonymous 2012-06-23 12:43

Name: Anonymous 2012-06-23 12:54

Name: Anonymous 2012-06-23 14:28

Name: VIPPER 2012-06-23 14:47

Name: Anonymous 2012-06-23 15:01

Name: Anonymous 2012-06-23 15:03

Name: Anonymous 2012-06-23 15:17

Name: Anonymous 2012-06-23 15:32

Name: Anonymous 2012-06-23 15:36

Name: Anonymous 2012-06-23 15:52

Name: Anonymous 2012-06-23 15:52

Name: Anonymous 2012-06-23 16:10

Name: Anonymous 2012-06-23 16:13

Name: Anonymous 2012-06-23 16:19

Name: Anonymous 2012-06-23 16:20

Name: Anonymous 2012-06-23 16:33

Name: Anonymous 2012-06-23 16:41

Name: Anonymous 2012-06-23 16:43

Name: Anonymous 2012-06-23 16:45

Name: Anonymous 2012-06-23 16:56

Name: Anonymous 2012-06-23 17:15

Name: Anonymous 2012-06-23 17:16

Name: Anonymous 2012-06-23 17:21

Name: 36 2012-06-23 17:23

Name: Anonymous 2012-06-23 17:24

Name: Anonymous 2012-06-23 17:24

Name: Anonymous 2012-06-23 17:28