Post by @hipsterelectron@circumstances.run

@hipsterelectron@circumstances.run · 4 hours ago

lawrence berkeley national laboratory keeps telling me i'm right https://gasnet.lbl.gov/pubs/upc_ft.pdf

A key advantage to the one-sided communication model is that no such tradeoff is required, because the
initiator always provides complete information describing the data transfer to be performed.

this is for "shared memory" operations in distributed supercomputers. i can only imagine that even more structured i/o requests that come even further ahead of time would enable such optimizations

There are no overheads imposed by matching or synchronization semantics, and the implementation is free to perform the data transfer using the most efficient mechanism available.

it's me and POSIX file write semantics in the cage match and i'm winning

View (PDF)

d@nny disc@

@hipsterelectron@circumstances.run · 4 hours ago

this one does slightly more similar i/o https://scispace.com/pdf/the-deep-computing-messaging-framework-generalized-scalable-2owrzz8sm5.pdf

Multiple messaging contexts: To prepare a message transfer, the processes create messaging contexts.

that's absolutely write

For two-sided communication, the context is created via the DCMF_Send_register() call . This call takes the reception callback (the cb recv in Figure 2) as an argument and associates it with a new context stored in the opaque persistent protocol object.

oh i'm totally stealing this though. sometimes writeahead logs induce compaction delays

Multiple contexts can co-exist and
be used simultaneously in the same application.

that absolutely answers that question

Multisend protocol: DCMF provides a novel multisend protocol. In a multisend, many point-to-point messages to different destinations can be sent through a single operation, thus amortizing the software startup overheads.

stealing this too

ERROR: The request could not be satisfied (PDF)

d@nny disc@

@hipsterelectron@circumstances.run · 4 hours ago

this is crazy i love being right https://sci-hub.st/10.1109/SC.2005.75

The overarching thesis of this effort is that the performance of many parallel applications can be improved by trans-
forming message passing operations based on application data dependencies and platform particularities of the specific cluster environment.

computer, i have poured all my love and my soul into this data-dependency graph. please O computer, grant me your strength

Sci-Hub. Transformations to Parallel Codes for Communication-Computation Overlap / ACM/IEEE SC 2005 Conference (SC'05),

d@nny disc@

@hipsterelectron@circumstances.run · 4 hours ago

Our experimental results support the observation that non-blocking and asynchronous I/O are not the same [10].

oh worm?

Truly asynchronous I/O is achieved only if the network hardware can perform the transfer on its own, letting the host processor continue with its computation.

i think this is less true today than in 2005 because CPUs have much richer page table entries and prefetching hints. and we have L3 cache now. gluttonous

d@nny disc@

@hipsterelectron@circumstances.run · 4 hours ago

4.3 Preserving Semantics

i'm gonna scream

For correctness to be preserved when one-sided asynchronous communication is used, the application needs to keep D + 1 send buffers and 2 × D receive buffers.

i totally hadn't figured out at all how to handle streaming data or really any other non-transactional messaging yet. receive buffers are a great idea

~30 more replies

d@nny disc@

@hipsterelectron@circumstances.run · 4 hours ago

There are three message types: memory FIFO, direct-put, and remote-get. For a memory FIFO message, the packets (including torus headers) are placed in a reception FIFO on the destination node. For a direct-put, the payloads of the packets are deposited directly into an arbitrary memory buffer whose physical address is known to the source. For a remote-get, the payload of the message is one or more message descriptors that are placed into an injection FIFO on the destination node to be eventually processed by the DMA. For example, the payload descriptor could be a direct-put of a long message back to the source node.

ok hell yeah. so we can have cross-process atomic writes when we really need them. we can play house with POSIX

d@nny disc@

@hipsterelectron@circumstances.run · 4 hours ago

Unfortunately, matching individual send and receive operations statically is undecidable in the general case.

POSIX is DONE!!!!!

d@nny disc@

@hipsterelectron@circumstances.run · 3 hours ago

Our proposed extensions would
allow the users to specify the blocks of data involved and let the underlying runtime system handle the problem of mapping data blocks to threads and packing the data into contiguous blocks.

ok so at least i am now VERY convinced that application-level data layout and automatic i/o compaction is not only a good idea, but one i can just cite instead of building up from scratch. sick

d@nny disc@

@hipsterelectron@circumstances.run · 3 hours ago

hell yes https://sci-hub.st/10.1109/2.467577

The compiler configures the machine as an abstract multidimensional mesh of processors and determines how program data is distributed on this mesh.

this one is really big on automatic data partitioning and i think that's right too

Sci-Hub: are you are robot?

d@nny disc@

@hipsterelectron@circumstances.run · 3 hours ago

now we got a typewriter paper that agrees with me https://dl.acm.org/doi/10.1145/338407.338547

For instance, VIA includes an explicit API for memory management: the application has to register the memory areas which are involved in communication.

yes!!!! yes!!!!!

We believe that such difficult decisions are not the programmer's job in many cases.

WE CAN MAKE PROGRAMMING FUN IF WE WORK AS A TEAM!

In specific domains such as high performance distributed multithreaded runtimes,

(build tools)

these tasks can be most efficiently handled by an additional mediumlevel software layer. Based on a number of simple directives, it can decide upon the best policy for memory management.

everything is so much easier if you have even the tiniest iota of structure from the application

Also, it can choose the best way of handling asynchronous communications depending on the appropriate trade-off between the responsiveness requirements and the affordable overhead.

every single filesystem in the history of OS design screaming crying throwing up

https://dl.acm.org/doi/10.1145/338407.338547

d@nny disc@

@hipsterelectron@circumstances.run · 3 hours ago

stealing ideas from intel now https://sci-hub.st/10.1109/40.671404

Synchronization. VIA provides both polling and blocking mechanisms to synchronize between the user process and completed operations. When descriptor processing completes, the NIC writes a done bit and includes any error bits associated with that descriptor in its specified fields. This act transfers ownership of the descriptor from the NIC back to the process that originally posted it.

great idea. it's mine now

Sci-Hub. The Virtual Interface Architecture / IEEE Micro, 1998

d@nny disc@

@hipsterelectron@circumstances.run · 3 hours ago

now IBM is telling me they love my ideas https://www.seltzer.com/assets/publications/The-Case-Against-Userlevel-Networking.pdf they're telling me they listened to the user's specifications for file caching and network buffering and the user told them i was right

View (PDF)

d@nny disc@

@hipsterelectron@circumstances.run · 3 hours ago

oh hell yes https://people.eecs.berkeley.edu/~culler/papers/fastsockets.pdf this is some top shelf ARPANET trash talk:

Current TCP/IP implementations use a complicated memory management mechanism.

they just made their own protocol. apparently you can do that

View (PDF)

Federation Bot

@Federation_Bot · 3 hours ago

so this is kind of a horrifying cope to avoid just doing a microkernel but https://people.cs.uchicago.edu/~ftchong/290N-W12/isca92.pdf this is cited a million times and they do NOT fuck around when it comes to latency:

Tolerating communication latency has been raised as a fundamental architectural issue[1]; this is not
quite correct.

GODDAMN FUCKING RIGHT MOTHERFUCKER!

The real architectural issue is to provide the ability to overlap communication and computation,
which, in-turn, requires low-overhead asynchronous communication. Tolerating latency then becomes a
programming problem: a communication must be initiated sufficiently in advance of the use of its result.

IT'S LITERALLY THAT FUCKING SIMPLE!