PIRA
v0.6.0
ประสิทธิภาพ และ การปรับแต่ง การ ปรับ แต่ง กรอบ งาน utomation PIRA เข้าใกล้งานที่ใช้เวลานานในการสร้างการวัดประสิทธิภาพที่เหมาะสมสำหรับฐานโค้ดที่ไม่รู้จักเมื่อใช้ Score-P สำหรับข้อมูลเพิ่มเติม โปรดดูเอกสารของเรา:
| [PI18] | แยน-แพทริค เลห์, อเล็กซานเดอร์ ฮุค, คริสเตียน บิชอฟ PIRA: ระบบอัตโนมัติในการปรับแต่งเครื่องมือวัดประสิทธิภาพ ใน การประชุมเชิงปฏิบัติการนานาชาติ ACM SIGPLAN ครั้งที่ 5 เกี่ยวกับปัญญาประดิษฐ์และวิธีการเชิงประจักษ์สำหรับวิศวกรรมซอฟต์แวร์และระบบคอมพิวเตอร์คู่ขนาน (AI-SEPS) หน้า 1-10, ACM, 2018 |
| [PI19] | แยน-แพทริค เลห์, อเล็กซานดรู กาโลโทอู, คริสเตียน บิชอฟ, เฟลิกซ์ วูล์ฟ การปรับแต่งเครื่องมือวัดอัตโนมัติสำหรับการสร้างแบบจำลองประสิทธิภาพเชิงประจักษ์ ใน การประชุมเชิงปฏิบัติการระดับนานาชาติเกี่ยวกับเครื่องมือการเขียนโปรแกรมและการแสดงภาพประสิทธิภาพ (ProTools) หน้า 40-47, IEEE, 2019 |
| [PI21] | ปีเตอร์ อาร์ซท์, ยานนิค ฟิชเลอร์, ยาน-แพทริค เลห์, คริสเตียน บิสชอฟ การตรวจจับความไม่สมดุลของโหลดค่าโสหุ้ยต่ำอัตโนมัติในแอปพลิเคชัน MPI ใน Euro-Par 2021: การประมวลผลแบบขนาน Lecture Notes in Computer Science, เล่ม 12820 , หน้า 19-34, Springer, 2021. |
PIRA ดำเนินการสี่ขั้นตอนต่อไปนี้ (ทำซ้ำ 2-4):
PIRA รองรับการกรองฟังก์ชันทั้ง เวลาคอมไพล์ และ รันไทม์ รวมถึงการกรองรันไทม์ของฟังก์ชัน MPI ผ่าน Wrapper ที่สร้างขึ้นโดยอัตโนมัติ ในการกรองเวลาคอมไพล์ เฉพาะฟังก์ชันที่ต้องการเท่านั้นที่ได้รับการกำหนดไว้ ณ เวลาคอมไพล์ ช่วยลดอิทธิพลของการวัดโดยรวมได้อย่างมาก ในทางตรงกันข้าม ในการกรองรันไทม์ คอมไพลเลอร์จะแทรก hooks การวัดเข้าไปใน ทุก ฟังก์ชันของแอปพลิเคชันเป้าหมาย และการกรองจะเกิดขึ้นที่รันไทม์
PIRA ต้องใช้ CMake (>=3.16), Clang/LLVM 10, Python 3, Qt5 และ OpenMPI 4 โดย (หรือ MetaCG) จะดาวน์โหลดเพิ่มเติม (และสร้าง)
หากคุณต้องการสร้าง PIRA ในสภาพแวดล้อมที่ไม่มีอินเทอร์เน็ต โปรดดูสคริปต์ resources/build_submodules.sh และปรับเปลี่ยนตามความต้องการของคุณ
โคลนที่เก็บ PIRA
$> git clone https://github.com/tudasc/pira
$> cd pira
ประการที่สอง สร้างโมดูลย่อยที่ต้องพึ่งพาโดยใช้สคริปต์ที่ให้มา หรือส่งค่าสำหรับตัวเลือกต่างๆ (ดูข้อมูลการใช้งานผ่าน -h สำหรับตัวเลือกที่มี) ไฟล์ที่ดาวน์โหลดและสร้างทั้งหมดจะถูกวางไว้ใน external/src/ ในขณะที่การติดตั้งทั้งหมดจะถูกวางไว้ใน external/install/ ระบุจำนวนของกระบวนการคอมไพล์ที่จะวางไข่สำหรับการคอมไพล์ภายนอกของ PIRA สคริปต์จะดาวน์โหลดการอ้างอิงของ PIRA ในเวอร์ชันเริ่มต้น เวอร์ชันเหล่านี้ได้รับการทดสอบใน CI ของเราด้วย และคาดว่าจะใช้งานได้
$> cd resources
$> ./build_submodules.sh -p <ncores>
ในขั้นตอนสุดท้าย สคริปต์บิลด์จะเขียนพาธการติดตั้งของโมดูลย่อยลงในไฟล์ resources/setup_paths.sh หากคุณต้องการสร้าง PIRA ใหม่ โปรดอย่าลืมคอม git restore ไฟล์นี้
นอกจากนี้เรายังมี Dockerfile (ทดลอง) เพื่อสร้าง PIRA และทดลองใช้อีกด้วย
$> podman build -t pira:master -f docker/Dockerfile .
เมื่อทำงานภายในคอนเทนเนอร์ เช่น การทดสอบการรวม โปรดเรียกใช้สคริปต์ดังต่อไปนี้
$> cd resources
$> . setup_paths.sh
$> cd ../test/integration/GameOfLife # Example test case
# By default PIRA will look into $HOME/.local, which is not currently existent in the docker
# XDG_DATA_HOME signals where to put the profiling data PIRA generates
$> XDG_DATA_HOME=/tmp ./run.sh
หากต้องการดูตัวอย่างวิธีใช้ PIRA ทั้งหมด ให้ชำระเงินสคริปต์ run.sh ในโฟลเดอร์ /test/integration/* จุดเริ่มต้นที่ดีคือโฟลเดอร์ GameOfLife และกรณีทดสอบ
ขั้นแรก ให้ตั้งค่าเส้นทางที่จำเป็นโดยการจัดหาสคริปต์ในโฟลเดอร์ resources
$> cd resources/
$> . setup_paths.sh
จากนั้น คุณสามารถเรียกใช้แอปพลิเคชันตัวอย่างของ PIRA ในการใช้งาน Game of Life ของ Conway อย่างง่ายดาย โดยใช้สคริปต์ run.sh ที่ให้มาในโฟลเดอร์ ./test/integration/GameOfLife GameOfLife
$> cd ./test/integration/GameOfLife
$> ./run.sh
สคริปต์ดำเนินการทุกขั้นตอนที่จำเป็นตั้งแต่เริ่มต้น เช่น การเตรียมส่วนประกอบทั้งหมดสำหรับโค้ดเป้าหมายใหม่ เพื่อเรียกใช้ PIRA ในที่สุด ในส่วนถัดไป จะมีการอธิบายขั้นตอนต่างๆ อย่างละเอียดยิ่งขึ้น ขั้นตอนคือ:
config เส้นทางไปยังไฟล์ปรับแต่ง (อาร์กิวเมนต์ที่จำเป็น)--config-version [1,2] เวอร์ชันของการกำหนดค่า PIRA 2 เป็นค่าเริ่มต้นและสนับสนุน 1 เลิกใช้แล้ว--runtime-filter ใช้การกรองรันไทม์ค่าเริ่มต้นคือเท็จ ในการกรองเวลาคอมไพล์ ฟังก์ชันต่างๆ จะไม่ถูกควบคุม ณ เวลาคอมไพล์ ซึ่งจะช่วยลดอิทธิพลของการวัดโดยรวมลงอย่างมาก แต่จำเป็นต้องสร้างเป้าหมายใหม่ในการวนซ้ำแต่ละครั้ง ในทางตรงกันข้าม ด้วยการกรองรันไทม์ คอมไพเลอร์จะแทรก hooks ของเครื่องมือวัดในทุกฟังก์ชันของแอปพลิเคชันเป้าหมาย--iterations [number] จำนวนการวนซ้ำของ Pira ค่าเริ่มต้นคือ 3--repetitions [number] จำนวนการวัดซ้ำ ค่าเริ่มต้นคือ 3--tape ตำแหน่งที่ควรเขียนเทปบันทึกข้อมูล (ค่อนข้างครอบคลุม)--extrap-dir ไดเร็กทอรีฐานที่วางโครงสร้างโฟลเดอร์ Extra-p--extrap-prefix คำนำหน้า Extra-P ควรเป็นลำดับของอักขระ--version พิมพ์หมายเลขเวอร์ชันของการติดตั้ง PIRA--analysis-parameters พาธไปยังไฟล์คอนฟิกูเรชันที่มีพารามิเตอร์การวิเคราะห์สำหรับ PGIS จำเป็นสำหรับทั้งโหมด Extra-P และ LIDe--slurm-config [path to slurm cfg file] เปิดใช้งานการเรียกใช้โค้ดเป้าหมายบนคลัสเตอร์ slurm จำเป็นต้องมีไฟล์กำหนดค่า slurm โปรดดูส่วนนี้สำหรับข้อมูลเพิ่มเติม --hybrid-filter-iters [number] คอมไพล์ใหม่หลังจากการวนซ้ำ [number] ให้ใช้การกรองรันไทม์ในระหว่างนั้น--export แนบโมเดล Extra-P ที่สร้างขึ้นและขนาดชุดข้อมูลลงในไฟล์ IPCG ของเป้าหมาย--export-runtime-only ต้องการ --export ; แนบเฉพาะค่ามัธยฐานรันไทม์ของการทำซ้ำทั้งหมดเข้ากับฟังก์ชัน ใช้ได้เฉพาะเมื่อไม่ได้ใช้ Extra-P--load-imbalance-detection [path to cfg file] เปิดใช้งานและกำหนดค่าโหมดการตรวจจับความไม่สมดุลของโหลด โปรดอ่านส่วนนี้สำหรับข้อมูลเพิ่มเติม PIRA ใช้ข้อมูลซอร์สโค้ดเพื่อสร้างเครื่องมือวัดเริ่มต้น และตัดสินใจว่าจะเพิ่มฟังก์ชันใดให้กับเครื่องมือวัดในระหว่างการปรับแต่งแบบวนซ้ำ มีเครื่องมือกราฟการโทรแบบ Clang ซึ่งรวบรวมข้อมูลที่จำเป็นทั้งหมดและส่งออกข้อมูลเป็นไฟล์ .json คุณสามารถค้นหาเครื่องมือ cgcollector ได้ในไดเร็กทอรีย่อย ./extern/src/metacg/cgcollector cgcollector PIRA กำหนดให้ไฟล์ callgraph อยู่ในรูปแบบไฟล์ MetaCG ในเวอร์ชัน 2 (MetaCG v2)
ข้อมูลเพิ่มเติมเกี่ยวกับ CGCollector และส่วนประกอบต่างๆ สามารถพบได้ในเอกสารประกอบ MetaCG
การใช้ CGCollector มักจะเกิดขึ้นในสองขั้นตอน
ในตอนแรก cgc จะถูกเรียกใช้กับทุกไฟล์ต้นฉบับในโปรเจ็กต์ เช่น:
for f in $(find ./src -type f ( -iname "*.c" -o -iname "*.cpp" ) ); do
cgc --metacg-format-version=2 $f
done
จากนั้น .ipcg -files ที่สร้างในขั้นตอนที่ 1 จะถูกรวมเข้ากับไฟล์ทั่วไปโดยใช้ cgmerge
"null" เท่านั้น 2. หากโปรเจ็กต์ของคุณมีฟังก์ชัน main มากกว่าหนึ่งฟังก์ชัน โปรดรวมไฟล์กับฟังก์ชัน main ที่ถูกต้องเท่านั้น echo "null" > $IPCG_FILENAME
find ./src -name "*.ipcg" -exec cgmerge $IPCG_FILENAME $IPCG_FILENAME {} +
กราฟสุดท้ายจะต้องถูกวางลงในไดเร็กทอรีของ callgraph-analyzer เนื่องจากปัจจุบัน PGIS ใช้สำหรับการวิเคราะห์ CG ไฟล์โปรแกรมทั้งหมดที่สร้างขึ้นจึงถูกคัดลอกไปยังไดเร็กทอรี PGIS ในปัจจุบัน สิ่งสำคัญคือไฟล์ในไดเร็กทอรี PGIS จะต้องตั้งชื่อตามรูปแบบ item_flavor.mcg รายการย่อมาจากแอปพลิเคชันเป้าหมาย ข้อมูลเพิ่มเติมเกี่ยวกับข้อกำหนดรสชาติและรายการในส่วนถัดไป
# Assuming $PIRA holds the top-level PIRA directory
$> cp my-app.mcg $PIRA/extern/install/pgis/bin/item_flavor.mcg
การกำหนดค่า PIRA ประกอบด้วยข้อมูลที่จำเป็นทั้งหมดสำหรับ PIRA เพื่อรันกระบวนการอัตโนมัติ ไดเร็กทอรีต่างๆ ที่ต้องระบุในไฟล์คอนฟิกูเรชันอาจเป็นพาธ สัมบูรณ์ หรือ พาธที่สัมพันธ์กับพาธการดำเนินการของ pira เส้นทางอาจมีตัวแปรสภาพแวดล้อม เช่น $HOME ตัวอย่างนี้นำมาจากตัวอย่าง GameOfLife ใน . ./test/integration/GameOfLife GameOfLife
ผู้ใช้ระบุ: ไดเร็กทอรี ที่จะค้นหา รายการ ที่กำหนดไว้ในภายหลัง ในตัวอย่าง ไดเร็กทอรีคือ ./gol/serial_non_template ไดเร็กทอรีเหล่านี้ได้รับนามแฝง ซึ่งถูกยกเลิกการอ้างอิงโดยใช้เครื่องหมาย '%' รายการใน PIRA เป็นแอปพลิเคชันเป้าหมายที่สร้างขึ้นในลักษณะเฉพาะ ซึ่งเป็นสาเหตุที่ทำให้รายการดังกล่าวถูกจัดกลุ่มในการกำหนดค่าภายใต้ builds
{
"builds": {
"%gol": {
"items": {
"gol": {
...
}
}
}
}
"directories": {
"gol": "./gol/serial_non_template"
}
}
ทุกรายการระบุว่าควรใช้ เครื่องวิเคราะห์ ใด ตัววิเคราะห์ เริ่มต้นมา พร้อมกับ PIRA และแหล่งที่มาสามารถพบได้ใน ./extern/src/metacg/pgis หรือการติดตั้งใน ./extern/install/pgis/bin install/pgis/bin ตามลำดับ เครื่องวิเคราะห์มีหน้าที่รับผิดชอบในการควบคุมการปรับแต่งเครื่องมือวัด และดังนั้นจึงเป็นส่วนสำคัญของกรอบงาน PIRA
ฟิลด์ argmap ระบุอาร์กิวเมนต์ต่างๆ ที่ส่งผ่านไปยังแอปพลิเคชันเป้าหมายเมื่อรันการทดสอบประสิทธิภาพ วิธีที่อาร์กิวเมนต์ถูกส่งผ่านไปยังแอปพลิเคชันเป้าหมายนั้นถูกกำหนดโดย ผู้ทำแผนที่ ที่แตกต่างกัน ในตัวอย่าง มีการใช้ตัวแมป เชิงเส้น ซึ่งจะวนซ้ำค่าของพารามิเตอร์ที่มีชื่อ ขนาด ตามลำดับที่กำหนดในรายการ
"argmap": {
"mapper": "Linear",
"size": [50, 80, 110, 150, 300, 500]
}
ฟิลด์ คิวบ์ คือตำแหน่งที่ PIRA ควรจัดเก็บโปรไฟล์ Score-P ที่ได้รับ มันจะสร้างแผนผังไดเร็กทอรีในตำแหน่งนั้น เพื่อให้ผู้ใช้สามารถเรียกใช้เครื่องมือสร้างแบบจำลอง Extra-P ได้อย่างง่ายดายหลังจาก PIRA เสร็จสิ้น เพียงแค่ส่งตำแหน่งตามลำดับ เช่น /tmp/pira ในตัวอย่าง
"cubes": "/tmp/pira"
ช่อง รสชาติ จะเพิ่มความแตกต่างที่เป็นไปได้อีกระดับหนึ่ง เนื่องจากสามารถสร้างแอปพลิเคชันเป้าหมายใน รสชาติ ที่แตกต่างกันได้ ตัวอย่างคือการระบุไลบรารีคณิตศาสตร์ต่างๆ ที่แอปพลิเคชันเป้าหมายควรเชื่อมโยงด้วย
สุดท้าย ไดเร็กทอรี functors จะชี้ PIRA ไปยังตำแหน่งที่ใช้ค้นหาฟังก์ชัน Python ที่ผู้ใช้จัดเตรียมไว้ ซึ่งท้ายที่สุดแล้วจะบอก PIRA ถึงวิธีการสร้าง เรียกใช้ และวิเคราะห์แอปพลิเคชันเป้าหมาย ในตัวอย่าง PIRA ชี้ไปที่ไดเร็กทอรีที่เรียกว่า functors ซึ่งสัมพันธ์กับตำแหน่งของการกำหนดค่า
"flavors": [
"ct"
],
"functors": "./functors",
"mode": "CT"
ช่อง โหมด ใน PIRA เวอร์ชันนี้จะถูกละเว้น
ณ ตอนนี้ ผู้ใช้จำเป็นต้องใช้งานห้าฟังก์ชันที่แตกต่างกัน:
analyze_<ITEM>_<FLAVOR>.py : เรียกใช้ตัววิเคราะห์clean_<ITEM>_<FLAVOR>.py : ทำความสะอาดไดเร็กทอรีบิลด์<ITEM>_<FLAVOR>.py : สร้างเวอร์ชันเครื่องดนตรีno_instr_<ITEM>_<FLAVOR>.py : สร้างเวอร์ชันวานิลลาrunner_<ITEM>_<FLAVOR>.py : รันแอปพลิเคชันเป้าหมาย โดยทั่วไปแล้ว Functors รองรับการเรียกใช้สองโหมด: ใช้งาน และ แฝง functor จะบอก PIRA ว่าโหมดใดที่ใช้โดยการตั้งค่าตามลำดับเป็น True ในพจนานุกรมที่ส่งคืนโดยฟังก์ชัน get_method()
ในโหมดแอคทีฟ ฟังก์ชันจะเรียกใช้คำสั่งที่จำเป็น เช่น เพื่อสร้างซอฟต์แวร์ เมื่อเรียกใช้ functor จะถูกส่งผ่านการเก็บพารามิเตอร์ **kwargs ตัวอย่างเช่น ไดเร็กทอรีปัจจุบันและอินสแตนซ์ของเชลล์กระบวนการย่อย
โหมดพาสซีฟจะส่งคืนคำสั่งเพื่อดำเนินการเท่านั้น เช่น สตริง make เพื่อเรียกใช้ Makefile แบบธรรมดาที่ไดเร็กทอรีระดับบนสุดของรายการ นอกจากนี้ยังส่งผ่านพารามิเตอร์ kwargs ที่เก็บข้อมูลเฉพาะ เช่น ค่าที่กำหนดไว้ล่วงหน้าซึ่งจำเป็นในการเพิ่มลงใน CXXFLAGS หรือแฟล็กตัวเชื่อมโยงเพิ่มเติม ตัวอย่างของฟังก์ชันพาสซีฟอาจพบได้ใน examples และไดเร็กทอรี test ในปัจจุบัน ฟังก์ชันที่นำไปใช้งานทั้งหมดใช้โหมดพาสซีฟ
PIRA ส่งผ่านอาร์กิวเมนต์ของคำหลักต่อไปนี้ไปยังฟังก์ชันทั้งหมด นอกจากนี้ ส่วนประกอบ PIRA ที่แตกต่างกันอาจผ่านการโต้แย้งเพิ่มเติม
สิ่งสำคัญ : ตอนนี้เราจัดส่งเวอร์ชัน Score-P ของเราเองแล้ว ดังนั้นจึงไม่จำเป็นต้องปรับคำสั่งคอมไพล์ใน PIRA อีกต่อไป ตรวจสอบฟังก์ชันใน test/integration/AMG2013 สำหรับตัวอย่างการใช้ข้อมูลต่างๆ
ขณะนี้ยังไม่มีการส่งข้อมูลไปยังผู้ปฏิบัติงานทุกคน
[0] เข้าถึงอาร์กิวเมนต์แรก [1] ที่สอง และอื่นๆ.so ที่ใช้ฟังก์ชันตัวตัด MPI (สำคัญสำหรับการกรอง MPI) จำเป็นต้องมีพารามิเตอร์เพิ่มเติมสำหรับโหมดการวิเคราะห์บางโหมด โดยเฉพาะอย่างยิ่ง PIRA LIDe (ดูด้านล่าง) และการวิเคราะห์แบบจำลอง Extra-P จำเป็นต้องมีพารามิเตอร์ที่ผู้ใช้ระบุ สร้างไฟล์ JSON และระบุเส้นทางไปยัง PIRA โดยใช้ --analysis-parameters -switch ตัวอย่างต่อไปนี้มีพารามิเตอร์สำหรับโหมดการสร้างแบบจำลอง Extra-P กลยุทธ์ที่มีอยู่เพื่อรวมโมเดล Extra-P หลายรายการ (เมื่อมีการเรียกใช้ฟังก์ชันในบริบทที่แตกต่างกัน) ได้แก่: FirstModel , Sum , Average , Maximum
{
"Modeling": {
"extrapolationThreshold": 2.1,
"statementThreshold": 200,
"modelAggregationStrategy": "Sum"
}
}
สำหรับรายละเอียดเพิ่มเติมเกี่ยวกับคุณสมบัติการตรวจจับความไม่สมดุลของโหลด โปรดดูที่ [PI21] จัดเตรียมเส้นทางการร้องขอ PIRA ไปยังไฟล์การกำหนดค่าโดยใช้ --load-imbalance-detection -parameter ไฟล์ JSON นี้จำเป็นต้องมีโครงสร้างดังต่อไปนี้:
{
"metricType": "ImbalancePercentage",
"imbalanceThreshold": 0.05,
"relevanceThreshold": 0.05,
"contextStrategy": "None",
"contextStepCount": 5,
"childRelevanceStrategy": "RelativeToMain",
"childConstantThreshold": 1,
"childFraction": 0.001
}
หากต้องการเรียกใช้ PIRA บนคลัสเตอร์ด้วย SLURM workload manager ให้เรียกใช้คลัสเตอร์ด้วยแฟล็ก --slurm-config กำหนดเส้นทางไปยังไฟล์การกำหนดค่าระบบแบตช์ของคุณด้วย ดูการทดสอบการรวมที่ต่อท้ายด้วย _Slurm ( test/integration/*_Slurm/ ) ปัจจุบัน PIRA รองรับระบบแบตช์ด้วย SLURM workload manager PIRA รองรับการใช้ module -system ซึ่งอาจพบได้ในกลุ่มสเลม
ไฟล์การกำหนดค่าระบบแบตช์เป็นไฟล์ JSON ซึ่งมีโครงสร้างดังนี้:
{
"general": {
"backend": "slurm",
"interface": "pyslurm",
"timings": "subprocess"
},
"module-loads": [
{
"name": "gcc",
"version": "8.5"
},
{
"name": "llvm",
"version": "10.0.0",
"depends-on": [
{
"name": "gcc",
"version": "8.5"
}
]
}
],
"batch-settings": {
"time_str": "00:10:00",
"mem_per_cpu": 3800,
"number_of_tasks": 1,
"partition": null,
"reservation": null,
"account": "your_account_here",
"cpus_per_task": 96
}
}
รายละเอียด:
general : ให้คุณเลือกว่า PIRA จะดำเนินการโค้ดของคุณบนระบบแบตช์ด้วยวิธีใด เนื่องจากทุกตัวเลือกในส่วนนี้เป็นทางเลือก คุณสามารถละเว้นส่วนทั้งหมดได้ หากคุณพอใจกับการใช้ค่าเริ่มต้น:backend : ตัวจัดการเวิร์กโหลดใดที่จะใช้ ตัวเลือก: slurm สำหรับผู้จัดการภาระงานของ slurm ค่าเริ่มต้น: slurm ดังนั้นจึงเป็นทางเลือกinterface : ในลักษณะใดที่ PIRA ควรโต้ตอบกับผู้จัดการระบบแบตช์ของคุณ สำหรับแบ็กเอนด์ SLURM สิ่งเหล่านี้คือ: pyslurm เพื่อใช้ PySlurm (ซึ่งจำเป็นต้องติดตั้ง PySlurm โปรดดูส่วนนี้ sbatch-wait เพื่อใช้ sbatch มาตรฐานพร้อมกับแฟล็ก --wait ; os สำหรับการโต้ตอบ sbatch และ squeue มาตรฐาน ค่าเริ่มต้น: pyslurm ดังนั้นจึงเป็นทางเลือกtimings : ควรกำหนดเวลาของโค้ดเป้าหมายอย่างไร ตัวเลือก: subprocess สำหรับการกำหนดเวลาด้วย python wrapper และ os.times ในกระบวนการย่อย (เหมือนกับที่ PIRA ทำหากรันในเครื่อง) os เพื่อใช้ /usr/bin/time ดีฟอลต์: subprocess ดังนั้น เป็นทางเลือกforce-sequential : ค่าเริ่มต้น false ตั้งค่าเป็น true เพื่อบังคับให้ PIRA/ระบบแบตช์ของคุณดำเนินการทั้งหมดตามลำดับ (เรียกใช้โค้ดเป้าหมายครั้งละหนึ่งครั้งเท่านั้น) ซึ่งหมายความว่า PIRA จะดูแลให้ระบบแบทช์ของคุณดำเนินการซ้ำ รวมถึงงานต่างๆ ในการปรับขนาดการทดลองตามลำดับ หากตั้งค่าเป็น/ซ้ายบน PIRA false จะพยายามสั่งให้ระบบแบตช์ดำเนินการต่างๆ มากที่สุดเท่าที่จะเป็นไปได้ภายในทุกๆ การวนซ้ำแบบขนานmodule-loads : ขณะนี้ไม่ได้ใช้งานใน PIRA อยู่ระหว่างดำเนินการ! ในปัจจุบัน คุณต้องโหลดโมดูลทั้งหมดด้วยตนเองก่อนที่จะเริ่ม PIRA! หมายถึงโมดูลใดที่ควรโหลดด้วยระบบ module สิ่งนี้จำเป็นต้องมีอย่างใดอย่างหนึ่ง ( module load คำสั่งและ module purge อาจใช้โดย PIRA) หากคุณไม่มีระบบ module หรือไม่ต้องการใช้ ให้ละเว้นส่วนนี้ทั้งหมด หรือตั้งค่า "module-loads": null หากต้องการระบุโมดูลที่ PIRA ควรโหลด ให้ระบุรายการโมดูล ดังตัวอย่างข้างต้นnameversion นี้เป็นทางเลือก หากไม่ได้ระบุไว้ จะขึ้นอยู่กับระบบ module ที่โหลดเป็นเวอร์ชันเริ่มต้นของโมดูล ขอแนะนำให้ระบุเวอร์ชันอย่างชัดเจนเสมอdepends-on ก็เป็นทางเลือกเช่นกัน แสดงรายการโมดูลที่โมดูลนี้ขึ้นอยู่กับ โมดูลเหล่านี้ต้องมี name และสามารถเลือกระบุ version ได้ PIRA ใช้การขึ้นต่อกันที่กำหนดไว้ที่นี่เพื่อกำหนดลำดับที่ควรโหลดโมดูลnull จะถือว่าโมดูลนี้ไม่มีการขึ้นต่อกันdepends-on ใดๆ จะ (พยายาม) โหลดโมดูลตามลำดับที่กำหนดในไฟล์กำหนดค่าbatch-setting : ตัวเลือกฮาร์ดแวร์และงานจริงสำหรับระบบแบตช์ ตัวเลือกบางอย่างในส่วนนี้เป็นข้อบังคับ คุณไม่สามารถละเว้นส่วนนี้ได้time : ตัวเลือก sbatch --time บังคับmem-per-cpu : ตัวเลือก sbatch --mem-per-cpu บังคับntasks : ตัวเลือก sbatch --ntasks บังคับpartition , reservation , account (ค่าเริ่มต้นทั้งหมดเป็น null = ไม่ได้ระบุ), cpus-per-task (ค่าเริ่มต้นที่ 4 ), exclusive (ค่าเริ่มต้นเป็น true ; ไม่รองรับ pyslurm ) และ cpu-freq (ค่าเริ่มต้นเป็น null )sbatch บางตัวที่คุณไม่สามารถกำหนดในการกำหนดค่านี้ได้ นี่เป็นเพราะตัวเลือกบางตัวที่ PIRA ใช้เป็นการภายใน เช่น ตัวเลือก --array เพื่อแมปการทำซ้ำกับอาร์เรย์งาน วิธีและเวอร์ชันของ PySlurm ที่จะติดตั้งบนคลัสเตอร์ของคุณ ขึ้นอยู่กับเวอร์ชัน SLURM ของคุณและการติดตั้ง SLURM ของคุณ โซลูชันการติดตั้งและบรรจุภัณฑ์สำหรับ pyslurm ด้วย PIRA อยู่ระหว่างดำเนินการ อ้างถึง README ของพวกเขา คุณอาจลองทำสิ่งต่อไปนี้:
include และ lib dirpython3 setup.py build --slurm-lib=/opt/slurm/21.08.6/lib --slurm-inc=/opt/slurm/21.08.6/includepython3 setup.py install --slurm-lib=/opt/slurm/21.08.6/lib --slurm-inc=/opt/slurm/21.08.6/include
