p-lang thread: (now (have you (problems two)))

The Something Awful Forums > Discussion > Serious Hardware/Software Crap > YOSPOS > p-lang thread: (now (have you (problems two)))

«‹›1784 »

GameCube: Nov 21, 2006

but mongo is web scale

# ? Oct 13, 2012 08:07

Adbot: ADBOT LOVES YOU

# ? May 9, 2024 16:15

Max Facetime: Apr 18, 2009

OOGA-BOOGA MONGO WEB SCALE

# ? Oct 13, 2012 11:52

shrughes: Oct 11, 2008; (call/cc call/cc)

MononcQc posted:

Which I guess is kind of okay, but annoying. poo poo can be locked up, I need to manually split everything in callbacks that will register themselves in order to know when things are done (something like resource.ready(callback)), I need to keep track of everything manually (is this parse for request 1, 2 or 73?).

Jesus loving christ that's not hard to do at all. You don't keep some table of requests and ask which request the parse is for, this poo poo is called closures.

MononcQc posted:

blah blah blah threads

Yeah and you pay the cost for context switching and overhead of threads or processes, which is why people still do event-based code to this day.

MononcQc posted:

Then at some point, I may gain parallelism on top of it Awesome, poo poo will go great, except maybe my writes, which will need to block to be sane. What I'll be able to do with my concurrent code (not callback-based) is:

Why would your writes block to be sane? Get better at writing. Learn 2 code.

MononcQc posted:

code:

accept -> parse -> dispatch -> read -> read more -> write -> push.
accept -> parse -> dispatch -> read -> read more ->        write -> push.

More like

code:

a -> p -> d -> reeeeeeeeeeeeeeeeead -> reeeeeeeeeeeeeead more -> wriiiiiiiiiiiiiiiiiiite -> push.
a -> p -> d -> reeeeeeeeeeeeeeeeead -> reeeeeeeeeeeeeead more ->                            wriiiiiiiiiiiiiiiiiiiiiiite -> push.

Note that the single-threaded event-based version looks like this:

code:

a -> p -> d -> reeeeeeeeeeeeeeeeead -> reeeeeeeeeeeeeead more -> wriiiiiiiiiiiiiiiiiiite -> push.
                a -> p -> d -> reeeeeeeeeeeeeeeeead -> reeeeeeeeeeeeeead more ->             wriiiiiiiiiiiiiiiiiiiiiiite -> push.

MononcQc posted:

My code that was concurrent is now parallel by default, and I limit how much blocking I need to do (assuming the write is written to block correctly, either via transactions, safe queues, mutexes, locks or whatever). However, if I go back to my callback-based code and get parallel, what I get is still this:
code:
(accept 1) -> (accept 2) -> ... (write 1) -> (write 2) -> (push 1) -> (push 2)

Put event loops on multiple threads, problem solved.

MononcQc posted:

And I want to get the speedup of my friends in the parallel and concurrent worlds. So I know what I'll do! I'll add non-blocking IO and will send poo poo to concurrent drivers in charge of doing poo poo right!
code:
(accept 1) -> ... ->          ->              -> (write 1) -> (write 2) ->
                     (read 1)    (read more 1)                             (push 1)
                     (read 2)    (read more 2)                             (push 2)
See? I got the parallelism going! I only did so at the cost of a shittier way to read and write code, still as sensitive to failures or blocks from independent requests, and relying heavily on the implementation of individual drivers not to gently caress my poo poo up! It's still worse on every level, but hey, I get to keep using my callback-based code (not that it's impossible to do in concurrent/parallel systems anyway). Hooray.

What are you talking about? In all event-based code the reads are going to happen in parallel. You don't schedule a read and then block anybody else from reading while you do your thing. Non-blocking IO is the thing one does with async code, LOL if you're using callbacks with blocking I/O.

MononcQc posted:

While the modern world of programming on servers has moved to concurrent and parallel methods a long while ago (mostly because they are objectively better), Javascript users with node.js came crashing through the door and said "we have a great new model! it's callbacks with non-blocking IO! it's loving great!".

Because that's how Javascript loving works. That's how it works in the browser, that's what Javascript engines support. Have you tried to take javascript engines and run more than one inside a process? Have you tried making them run on top of green threads? Guess what: the fancypants C++ programmers didn't make them compatible with all such notions.

MononcQc posted:

Everyone who is not node.js knows what they propose is worse than what exists. It's like someone inventing PHP again, but for server-side platforms.

Blah blah blah Ryan Dahl is an idiot. We know that. We don't need you to be an idiot too.

shrughes fucked around with this message at 12:08 on Oct 13, 2012

# ? Oct 13, 2012 11:58

0xB16B00B5: Aug 24, 2006; by Y Kant Ozma Post

well on one hand, i respect MononcQc's opinions, and on the other hand, youre breaking anime rules

this is a tough decision

# ? Oct 13, 2012 12:00

0xB16B00B5: Aug 24, 2006; by Y Kant Ozma Post

also youre defending node unironically

# ? Oct 13, 2012 12:01

shrughes: Oct 11, 2008; (call/cc call/cc)

In addition to the fact that single-threaded async callback systems can be fairly straightforwardly migrated to run on multiple threads:

Async callback based systems can be fairly straightforwardly migrated to green thread systems that sit on top. It takes about 3 manweeks to set up your own green thread library, and then code can be migrated incrementally later. So it's not some design decision you're Stuck With.

Async callback based systems never made sense for stuff doing lots of Disk I/O, except maybe for very expensive super-awesome SSD devices. For stuff doing lots of network I/O, with the state of a lot of connections to take care of, that's where they make sense. Guess what Node.JS is designed for.

Which is better: nginx or Apache?

If you want to run a Javascript webserver using v8 you simply can't have multiple threads. You can't have green threads. v8 does not work that way. Javascript code that can run both in-browser and in-process needs to be callback-based in both situations.

If they did use a JS engine that could run on multiple OS threads, that would make things a lot more error prone for the users of Node.JS if they went that path. Just imagine that scenario, what a clusterfuck that would be for retarded javascript programmers who never had to deal with the concept of multi-threading.

So Node.JS made the right choices when it comes to doing javascript on the web server.

You can complain about drivers and filesystems being broken when doing async I/O to disk, but so what? The point of async I/O is not to super-parallelly talk to disk, you can't do enough concurrent I/O requests on most disks for anybody to care if you just spawn a pool of worker threads for that purpose.

# ? Oct 13, 2012 12:45

Zombywuf: Mar 29, 2008

code:

code:

code:

code:

code:

code:

code:

code:

code:

code:

code:

code:

code:

code:

MononCqC posted: