1 / 21

The XPI Interface

The XPI Interface. Early thoughts on the XPI Representation Will be updated/changed frequently. Goals. Provide Programming Execution Model Functionality: ParalleX / HPX Speed: Incur minimal overhead Interface: Similar to MPI when possible Small: minimal set of functions and objects.

wbrandon
Download Presentation

The XPI Interface

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. The XPI Interface

  2. Early thoughts on the XPI Representation Will be updated/changed frequently

  3. Goals • Provide Programming Execution Model • Functionality: ParalleX / HPX • Speed: Incur minimal overhead • Interface: Similar to MPI when possible • Small: minimal set of functions and objects

  4. Things We Rely on Being Fast • Remote Direct Memory Addressing • Light Weight Threads • Active Messages (Parcels) • Atomic Memory Operations • Work Queues

  5. LCO • Constructor • In: receptor, byte_array • get_gid • Out: GID • free

  6. LCO • waitany # listen to multiple lco's • counted_waitany # listen to multiple lco's

  7. LCO • write # possibly remote operation • In: byte_array • In: Offset • In: Len • wait # local, returns when a write occurs • In: Timeout • Out: return code: error, interrupt, success, etc. • counted_wait # local, return when number of writes is # greater than the number of # counted waits • In: Timeout

  8. Complex/Thread: LCO • Complex/Thread constructor • In: Action • In: data, byte_array • In: receptor, byte_array # can be null • Optional In: contin1, (T) Thread, (TL) Thread_list • Optional In: contin2, (G) GID, (GL) GID_list • start • Optional Out: (R) RunningThread • set_state • get_state

  9. Complex • send_and_exit • In: byte_array • In: Offset • In: Length • # This writes to all continuations# and terminates the thread

  10. XPI_Action action; XPI_Thread thread, next1, next2; XPI_RunningThread run; XPI_GID gid; struct BH_data *bh_data; XPI_Buffer_init(sizeof(BH_data),XPI_RECEIVE,&bh_data); ... XPI_Thread_init_T(&thread,&action,bh_data,&next); XPI_Thread_start_R(&thread,&run); XPI_Thread_getgid(&thread,&gid); .... XPI_RunningThread_set_state(&run,XPI_TERMINATE); Pseudo C Code

  11. Action: Portable Function Ref • Action constructor • In: function_id, String • In: data_size, int • In: data_repacker, Action • Name of function used to repackage bytes for use on possibly different architectures available on a machine. Potentially difficult to write, auto generated by XPIPP tool based in on interface definition language. Null used on machines with homogeneous architecture.

  12. Memory Managment • mem_alloc • In: size, int • In: flags, int • RECEIVE: can be a target for RDMA • In: data_repacker, Action • # special value: IMMOBILE • # special value: ARRAY_OF_INT • # rely on tools to generate repackers • Out: ref, (P) byte_array, (G) GID

  13. Memory Management • mem_free • In: data, (P) byte_array, (G) GID • mem_getptr • In: GID • Out: byte_array • mem_getgid, • In: byte_array • out: GID • Use this to unify disk and memory access as Jack Dennis suggests?

  14. // Data managed by XPI void init_data(void *intrinsic,void *recvd) { struct BH_data *bh_data = (struct BH_data *)intrinsic; ... BH_event_horizon *eh; XPI_Buffer_init(sizeof(eh),flags,&eh); XPI_send_and_exit(eh); // received by continuations } XPI_Action action; XPI_Action_init(&action,"black_hole.init_data",10,NULL); Pseudo C Code

  15. WorkQueue: LCO • WorkQueue constructor • Out: id, (R) GID • In: receptor, byte_array • # WorkQueue runs one thread at a time. All threads share# the receptor as the second argument to the action • add: • In: Complex/Thread # called if the GID is a parcel target

  16. Parcels • Parcel constructor: • In: Action • In: Data • In: destination, GID • Optional In: contin, (G) GID, (GL) GID_list • start

  17. Locality • static Locality get_locality() • get_gid: • Out: GID • get_property: • In: name, String • Out: value, int

  18. Process • Process constructor • In: parent, GID • In: Locality_List • set_policy: In: policy, In: param • get_policy: In: policy, Out: param • get_gid: Out: GID

  19. Process • bind_symname • In: sym_name, String # e.g. "console" • In: GID • unbind_symname • In: sym_name, String • get_main: static: Out: GID • get_parent: Out: GID, In: GID • all GID's have a parent process! • get_current: static: Out: GID

  20. Parcels • Semantically similar to Thread • A better way to start a thread: Destination can be a process, that starts a thread at the least loaded of the managed localities

  21. Mobile Objects (AGAS) • WorkQueue (easy) • Suspended Thread (difficult) • Just move work queues to start?

More Related