Tried Stack Overflow, but got nothing. Normal?

[blacksheeplogic]

Since all of human knowledge is on Google and their question is unlikely to be cutting edge, there is a Google reply out there.  All the user has to do is look.

Sometimes Google gives you thousands of results that don't answer the question, or thousands of similar but not the same, or thousands of wrong answers, or worse still vague answers that don't actually tell you what the answer are just that your stupid for asking etc. Then there's the thousands of answers from morons quoting documentation they don't understand etc....

Mr Google has it's uses but sometimes a generic search engine is not what you need.

[rstofer]

Sometimes Google gives you thousands of results that don't answer the question, or thousands of similar but not the same, or thousands of wrong answers, or worse still vague answers that don't actually tell you what the answer are just that your stupid for asking etc. Then there's the thousands of answers from morons quoting documentation they don't understand etc....

Mr Google has it's uses but sometimes a generic search engine is not what you need.

Google can certainly lead you astray, no question about it.  Yet, for all of it, I have been retired and playing with various projects for 16 years.  I seem to find the information I want by way of Google, even though I may have to manipulate the search string, but I have never gotten an answer from SO.  Every single time I click there all I get is "Already answered" without so much as a hint as to where.  Of course it's already answered, there are no new questions!  I want to know WHERE it is answered.

Others have a different experience, no doubt, but for me SO is a complete waste of pixels.

And, yes, some of the links from Google have outright wrong answers.  Some of the stuff is not worth the storage space it consumes and filtering the replies is often an exercise in futility.  Wikipedia can be a lot like that.

I can understand a bit of frustration on the part of SO contributors.  Questions are asked that are clearly spelled out in a User Manual which, obviously, the poster hasn't bothered to read.  Others relate to programming where it is clear the poster has not a clue as to how the constructs are supposed to work.  It's like "Hey, I found this site, I'm going to post a truly stupid question and see what happens!"  Well, what happens is that the universe crashes in on them.  And maybe that's exactly what should happen.  Do your own homework, I did mine!  Something like that...

In the meantime, for me, SO is my absolute last choice for a useful response to any query I may post.  But that's just me!  I'm old, I'm cranky and I don't want people wasting my time with "Already answered".

[Nominal Animal]

I completely lost my shit when a self-professed "MPI expert" on StackOverflow with high reputation score told new MPI programmers that asynchronous sends/receives (MPI_Isend(), MPI_Irecv()) should not be used, because they tend to cause deadlocks.

This is one of my buttons, because not using asynchronous communications is a huge waste of resources in current distributed simulations: they compute, then transfer data, then compute, and so on, even when in most cases, the simulation can easily compute and transfer data at the same time.  Depending on the simulation, the time spent transferring data and not computing anything can be a significant fraction (like 10-25% in the real world, even when using fast InfiniBand) of the total simulation wall clock time.  Wasted.

There obviously are caveats to using asynchronous communications, but those are really about cases where computing and data transfers cannot be mixed.

If you have a regular lattice of computing nodes, then asynchronous comms with neighbours is easy: just use a separate tag per neighbor direction (so six tags for a regular cubic lattice; 28 if you include second and third neighbors in the diagonal directions), and one pending asynchronous receive and one send per neighbor.  The tag is set based on the direction the message flows in the lattice.  So, if you use tag L when sending to "left" neighbor, and tag R when sending to "right" neighbor, you receive a message from your "left" neighbor using tag R (because the message flows "right"), and a message from your "right" neighbor using tag L (because the message flows "left").  With this scheme, you won't have a deadlock using any current MPI implementation.  Then, you just need to partition your data so that you'll immediately send the data your neighbors receive, calculate the data you can without the data from the neighbors, then wait for the neighbors to send the data you need, and finally calculate the data you needed the neighbor data for.  If the internal data set is large enough compared to the data shared with the neighbors, you end up doing communications and calculations at the same time, and not waste real world time and resources.

[rstofer]

I completely lost my shit when a self-professed "MPI expert" on StackOverflow with high reputation score told new MPI programmers that asynchronous sends/receives (MPI_Isend(), MPI_Irecv()) should not be used, because they tend to cause deadlocks.

But, for a new user, lacking a great deal of insight into messages, that might be a perfectly reasonable answer.

Take a simple example:  Serial IO.  We can have polled input or interrupt driven input with a queue.  If a new user came by and asked "how do I implement serial IO", we probably wouldn't give the interrupt driven answer.  The topic seems to be too advanced for the question posted.  If the question was "what's the proper way to implement interrupt driven serial IO" then maybe the more advanced answer is more appropriate.

That's a problem with forums:  How much does the poster know?  Where are they on the learning curve?

[Nominal Animal]

I completely lost my shit when a self-professed "MPI expert" on StackOverflow with high reputation score told new MPI programmers that asynchronous sends/receives (MPI_Isend(), MPI_Irecv()) should not be used, because they tend to cause deadlocks.

But, for a new user, lacking a great deal of insight into messages, that might be a perfectly reasonable answer.

I forgot to mention that the original asker was specifically trying to learn about async messaging using MPI_Irecv()/MPI_Isend(), and the response from that high-score dude was "don't do that, it's bad; I'm a high-reputation MPI expert, and we never do that in practice".

(I was trying to find the question, but I think the asker or moderators deleted it.  My own comments needed a bit of moderator intervention, I got so heated up.)

It's when high reputation score, or otherwise trusted/popular people talk garbage and refuse to acknowledge any errors, that I get angry.
I don't mind people being wrong -- I'm often wrong myself --; it's the unwillingness to acknowledge an error when you must know better, willingly leading others astray with known incorrect advice, that yanks my chains too much.

I would not push async transfers on a new user, of course.  Getting initial tests and calculations going with normal synchronous sends and receives with MPI is hard enough   Step by step, getting visible progress, while climbing the learning curve, works.

Take a simple example:  Serial IO.  We can have polled input or interrupt driven input with a queue.  If a new user came by and asked "how do I implement serial IO", we probably wouldn't give the interrupt driven answer.

Right.  I would probably write a three-stage answer: use a library; examine existing implementations to understand blocking I/O, nonblocking I/O or polled I/O, interrupt driven, and DMA driven; then implement your own from scratch.  Progress as deep into the rabbit hole as you wish, forking into the different approaches, or stay with the library approach if that part is not a key point in the learning experience yet.

For new users, it is important to get some visible/tangible examples done from the get go, no matter how simple, because the suckage at the beginning of the learning curve hurts, but the newness and even simple achievements make it bearable, often fun.  The trick is to not lie to them and say "this is how you do it" if you don't really do stuff that way in real life, but explain that this is a simple way to get going, although harder ways that can be more efficient do exist, and one might wish to learn about them at a later date.

It's like when a student asks a chemistry teacher whether electrons really orbit nuclei like planets orbit a sun.  No, they don't; but what they do is pretty odd (to anyone not familiar with particle-wave dualism or quantum mechanics), and the orbits or orbitals are a pretty good approximation of their observed behaviour.

[Mr. Scram]

I thought it was fairly commonly accepted that Stack Overflow is closing threads for supposed duplicates to such an extreme degree it's comedic. It seems similar to how people on Wikipedia squat certain articles they wrote and reverse any helpful changes made for vague reasons until the helpful people just give up. It seems some people have made these sites their playground for reasons other than the intended purpose.