Mensa

I scored high enough on an official IQ test (as in, from a clinical psychologist who tested me professionally in person, not some illegitimate online test) to get accepted into Mensa. Should I do it? Some people love it, others claim that it's just a bunch of pretentious cunts playing board games and bragging about how smart they are. What do you think? What have your experiences in Mensa been like?

Being smart autists, I figure that at least some of you might know what Mensa is like. I would appreciate any and all serious insight.

>>39
Can your mom code in Lisp?
Yes. My mom often conses shopping and todo lists.

>>40
What facilitates non-uniform memory access?

>>42
The hardware facilitates it and provides fundamental high-performance hardware interfaces for accessing memory from different types of buffers, and OpenCL and provides a very thin software abstraction over top of this.

Hey OP, using your superior intellect and autism, I would ignore Mensa and focus on becoming a Tetris Champion like this guy:

http://www.youtube.com/watch?v=H_tmFUWu9bI

>>43
What prevents producing hardware for message passing?

>>18
You would obviously be a happy Mensa customer. Think a little harder.

I was invited to join but seriously ...

Who wants to listen to a bunch of fucking neckbeards whine about their lack of social graces.

The other favorite topic for whining is how People Like Us should be in charge since we know so much better. Instead of cleaning toilets on the night shift, even.

Who wants to listen to a bunch of fucking neckbeards whine about their lack of social graces.
Then what are you doing on /prog/?

>>30
OK, this is highly retarded. First, nothing prevents me to rewrite it in Lisp. Second, C is not low level. Third, if it was you wouldn't be able to do low-level optimizations. Fourth, there are real time GCs.

>>49
You have bitch tits.

>>49
Fourth, there are real time GCs.
You can't use GC in massively parallel systems (the ones, that can do fuzzy pattern-matching really fast), where you have gigantic message passing grid of simple processing elements, each with only a few bits of ram, enough to hold it's pattern state.

>>51
And you can't use C/C++ there either.

>>51
You also can't use apostrophes correctly either.

>>52
Yes you can, people are using C/C++ on those massively parallel super computers with like 512-1024 CPU cores per compute node/rack, with near linear scaling.

The problem with garbage collection and even real-time garbage collection is that there is a single global heap for the entire process/program. A single heap implies write sharing among threads. Anytime a thread needs some memory, it has to allocate it from the global heap, and it will be competing against other threads attempting to acquire the global heap lock.

Garbage collected languages like Lisp or Java have a global heap built right into the language requirements. You can't ignore it.

With C and C++, the global heap and free store are not a part of the language itself, but rather a part of the standard libraries, and therefore if you do not use malloc or the global new operator, you don't pay the consequences.

C and C++ allow you to implement your own efficient and scalable memory allocators with different properties--hence you can achieve near perfect scaling, even in non-uniform memory architectures where each compute node has it's own local pool of RAM.

Not possible in Lisp or Java or other garbage collected languages.

>>52
So how come PS3 programmers using C/C++ to program the Cell's SPEs which each have their own DMA channels and register files, which is pretty close to what >>51 described.

You don't know anything, as >>54 has pointed out.

>>53
wat

>>55
You also use C or C++ to program the secondary ARM Cortex M4 DSPs and coordinate DMA transfers on the upcoming OMAP5 ARM Cortex A15 SoC.

C and C++ are quite versatile languages.

>>54
massively parallel super computers
512-1024 CPU cores
You must be kidding. "massively parallel" means that machine has billions of simple processing elements. Basically, every arithmetic operator in your program gets it's own core.

>>55
PS3 is traditional von Neumann architecture.

>>57
use C or C++ to program ARM
ARM is useless for anything other than cell phones.

inb4 someone posts an inline asm lisp DSL to troll >>1-1000

>>54
single global heap
You don't have a clue what you are talking about.. Sweeping generalizations everywhere

What prevents a garbage collected language to have a GC process per thread, and use a single global free list? Just the way all other per-thread heap languages do it

>>58
You must be kidding. "massively parallel" means that machine has billions of simple processing elements. Basically, every arithmetic operator in your program gets it's own core.

Wow, you sure are fucking retarded. I said 512-1024 CPU cores per compute node/rack. It just goes to show that you don't even FUCKING understand the general topology of modern super computers. In essence, they are massive clusters of compute nodes networked together with things like ethernet or a faster custom inter-connect. Each compute node consists of multiple blades or racks, upon which are multiple CPUs in SMP configuration, and each CPU itself may have multiple cores. Sometimes there are even GPUs on the racks. Each compute node may consist of only 512-1024 CPU cores with shared memory using a custom inter-connect. But there are many hundreds or perhaps thousands of such nodes that comprise a single super computer, and thus tens or hundreds of thousands of cores total!

>>61
>What prevents a garbage collected language to have a GC process per thread, and use a single global free list? Just the way all other per-thread heap languages do it.

Umm, no. That's not how you do it in C/C++. You do not use a single global free list. Generally, you keep allocations AND deallocations inside a thread so there is no synchronization or write-sharing, which kills performance. Not possible with garbage collectors. Why? Because there may be cross-thread object dependencies if an object in one thread holds a reference to another object in another thread, and so you have to freeze the entire process to analyze the dependency graph and make sure you collect only those objects which are truly garbage. In real-time garbage collectors, an incremental algorithm is employed to collect only as many objects as it can within a fixed time-slice, with strong constraints on time, and the GC is run more periodically dependent on memory pressure.

Per-thread GC heaps don't fix this, yeah you can allocate from per-thread heaps, but the dependency analysis during GC must be process wide. And so a per-thread GC process doesn't really make sense, although per-thread GC allocation heaps could work. You're still fucked.

Also, enjoy your poor cache locality. Cache-aware allocators are far superior, and garbage collected languages just don't impart enough information at time of object allocation in common languages to support this.

>>62
lol u buttmad

>>62
Each compute node may consist of only 512-1024 CPU cores with shared memory using a custom inter-connect.
This is a childish number. Compare it to number of cells in human brain, all working in parallel.

It just goes to show that you don't even FUCKING understand the general topology of modern super computers.
I were talking about "massively parallel" architectures, like Connection Machine, not your "modern super computers".

In essence, they are massive clusters of compute nodes networked together with things like ethernet or a faster custom inter-connect.
This is traditional inefficient von Neumann shit.

>>64
IHBT

>>65
you are just wrong.

>>65
I think it's a matter of definition. We can all be annoyed that we haven't reached the physically possible ``massively parallel architectures'' which sport billions to trillions of very simple processing units. If we would have reached that, some form of AGI would most likely have emerged by now, not to mention how faster certain physical simulations would become. "Supercomputers" of thousands of CPUs are good for certain tasks, but they are terribly wasteful in both time and energy cost.

>>67
x86 is pretty wasteful, being optimized for single-threaded execution with shared memory.

>>54,62
Wow, you sure are retarded.
So, you just let threads access non-atomically shared objects in C/C++?
Do you really think that you're not going to use a specialized GC and sufficiently smart compiler? (yes, the same kind of compiler that makes your C/C++ code go vroom vroom)
analyze the dependency graph and make sure you collect only those objects which are truly garbage.
Your allocator doesn't handle sharing? Enjoy randomly dereferencing null pointers.
You use smart pointers with refcounting? Enjoy your cyclic references.
You don't share? Neither do I, and my sufficiently smart GC and compiler will know.
You use the stack for locals? So does my compiler, thank you.
You have some magical bit set to mark an object as ``local''? (gc:mark-as-local! obj)
You deallocate in-place? (gc:mark-as-dead! obj), it would bump the object's collection priority. Also, enjoy randomly dereferencing null pointers.
You have something else? Nothing that a specialized GC and a little of exposed GC API can't do.
Garbage collected languages like Lisp or Java have a global heap built right into the language requirements. You can't ignore it.
Which chapter of the ANSI Common Lisp Standard specifies the garbage collector? I can't find it. R5RS says nothing, and neither do R6RS and R7RS.
I can't find it in the Java Language Specification, Third Edition, too.
This means you can do what the fuck you want in your implementation: you can use a GC, you can expose whatever allocator API you want, you can just use the stack (if any), you can leak memory, and your implementation will still be conformant.
Thus, how can I ignore something that's not even specified?
Also, enjoy your poor cache locality.
Small heaps can be small enough to fit into the processor's cache. But you clearly live thinking that GCs still use a slow mark-and-copy, with a big, unique global heap traversed every time you need to collect some garbage.

>>69
You use smart pointers with refcounting?
smart pointers are fucking slow, compared to GC.

>>69
sufficiently smart compiler
bahahahaha

>>71
bahahahaha
http://en.wikipedia.org/wiki/Neo-Luddism

>>72
WOW THANKS I SURE DID LEARN SOMETHING TODAY

>>70
proof?

>>74
malloc and reference counting are slow for many small objects, like cons-pairs

>>74
http://www.nambla.org

I got tested at 176 and am not autistic.

>>77
yes, yes you are

>>70
Indeed they are. GCs being slow is just a myth.

>>79,70
okay am I being trolled here?