Post by @hipsterelectron@circumstances.run

@hipsterelectron@circumstances.run 5 mo. 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)

0 Boosts

0 Likes

d@nny disc@

@hipsterelectron@circumstances.run 5 mo. 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 5 mo. 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 5 mo. 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 5 mo. 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 5 mo. 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 5 mo. ago

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

POSIX is DONE!!!!!

d@nny disc@

@hipsterelectron@circumstances.run 5 mo. 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 5 mo. 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?