FESADev/docs/calculation-performance

계산 성능 개선

Hex8와 reduced-coordinate shell HHT의 실제 병목을 VTune으로 조사하고, 승인된 물리·입력·정밀도·결과 의미를 유지하며 실행 시간을 줄이는 작업이다. 새 요소·하중·적분법·공용 cache framework 추가는 범위 밖이다. 요구사항 FEM-REQ-PERF-001..009의 시간 목표와 검증은 별개이며 현재 최종 완료 상태는 아니다.

채택한 계산 경로와 수명

Matrix::Multiply는 dense GEMV/GEMM, SparseMatrix::Multiply는 CSR validate·finite/RHS/checked MKL_INT 확인 후 mkl_sparse_d_create_csr → mkl_sparse_d_mv → destroy를 사용한다. Const 호출마다 변환 배열·values 복사·handle을 소유하므로 copy/move·동시 호출에 backend pointer를 공유하지 않는다. Empty shape도 입력 검증 뒤 zero vector를 반환한다. 지속 symbolic cache나 scalar fallback은 없다. 호출마다 CSR 배열 복사 비용이 있으므로 MKL 연결만으로 전체 성능 향상을 주장하지 않는다.

Dense adapter가 MKL 세부를 감싸고 PARDISO와 tangent solver가 factor/solve/release를 소유한다. 성공한 동일 matrix의 여러 RHS는 재사용하지만 새 matrix·실패 분해의 stale factor는 쓰지 않는다. 기본1×1 SPD 호출의 기존 heap failure에만 local1-thread/TLS 복원을 적용했으며 vendor 원인은 미확정이다. Public core에 MKL 타입을 노출하지 않는다.

Hex8 high+low는 normalized pair의 원래 graph·ordered reduction·RN64 observable을 유지한다. LinearTangentCache는 동일 요소 복사본 사이의 불변 paired Hessian 두24×24 matrix만 call_once로 준비하고 nonlinear trial은 접근하지 않는다. Packet 경계·AVX2 구현·dispatch는 독립 b-lane의 순서를 유지하고 지원되지 않는 환경은 원래 scalar 경로를 사용한다. 이는 실패한 수치 계산을 다른 물리식으로 재시도하는 fallback이 아니다.

HHT trial context와 reduced procedure는 position 의존량과 rate 의존량의 재사용 수명을 구분한다. Nonlinear shell의 private Jet 영 seed는 정의된 numeric zero/도함수 provenance만 최적화하고 NaN/Inf·singular composition 실패를 지우지 않는다. 절점6×6 outer/full24 scatter 후보는 관련 검사가 통과했어도 단일 micro 차이 약1.44%와 production 호출 빈도 미확인으로 보류·복원됐으며 현재 채택 경로가 아니다.

일반 Float64 행렬 곱은 MKL을 쓰지만 작은 고정 좌표 계산, high+low·보상 누적·outward interval 인증은 해당 정밀도와 오차 의미를 보존한다. Thermal RHS를 두 행곱 차로 재배치한 후보는 cancellation oracle를 깨뜨려 폐기했다. 현재 entry association (c/delta)*(old-g)-k*g와 row 순서를 유지한다. 연산 순서·zero 부호·floating exception 상태도 실제 계약에 필요한 범위에서 검증한다.

시간·결과·reference 계약

공통 CLI·source identity·lease·atomic HDF5·비교 기준은 solver-core, 물리 의미는 Hex8·HHT를 따른다. Time step·increment·Newton gate·질량·적분점·출력량·schema·정밀도를 성능 때문에 줄이거나 바꾸지 않는다.

기준 환경은 Ryzen7 5800H Windows/MSVC x64 최적화 Release다. 동일 thread·runtime·전원·compiler 조건에서 워밍업 없이 모델별 별도 process를 한 번 측정한다. Process 시작 요청 직전부터 정상 종료 직후까지 읽기·계산·복구·로그·HDF5 close/final 교체를 모두 포함한다. 빌드·입력 복사·VTune·비교는 구간 밖이다. Debug 시간·CPU 합계·계측 elapsed·반복 중 최솟값을 목표 판정에 쓰지 않는다.

원본 case	목표 초	기존 단일 baseline 초	당시 수치 비교
hexa_nonlinearstatic	2	10.914924	U/constrained RF/point S 통과
hexa_dynnonlinear	100	402.069447	101-frame 전체 U 통과
shellNL-dyn-meshfine	100	6372.325621	729-node inventory·101-frame 확인,9-node U blocking 통과·UR warning200 entries

이 baseline은 세 목표 모두 미달이다. 최종 source의 세 모델 새 결과·공식 시간·전체 Debug·필수 reference·독립 검토가 모두 필요하다. 공유 consumer 회귀에는 Hex8 원본5개(정적2·고유치·동적2)의 기존 비교도 포함한다. 수치 판정은 source/frame/component·finite/schema 검사를 먼저 통과하고 공통 near-zero1%·일반 행5%·family RMS1%·zero-scale exact-zero를 적용한다. MITC4 eigen 예외를 Hex8에 쓰지 않는다.

실제 근거와 남은 범위

Hex8 기하 packet 수정본의 관련 Debug/Release82개씩, 독립 snapshot9,804행·전체 bytes 일치 기록이 있다. 이전 Release ordered-overflow 사례는 값 bit가 같아도 INVALID FE/MXCSR가 달라 실패했다. Nonfinite 첫 sum에서 원래 checked scalar bridge로 돌아가 error 계산을 생략하는 수정 후 통과했으며 flags clear·기대값 완화로 숨기지 않았다. 이 검증을 전체 모델 시간이나 모든 source의 현재 PASS로 확대하지 않는다.

그 수정본의 단일 동적 개발 실행은 native0·117.7986225초로 완료됐으나100초 목표 초과다.101 U frame 비교는 blocking PASS, 최대 relative RMS 약2.155586e-6이었다. Outer wrapper는 종료 자식의 null StartTime 처리에서1로 끝났고 실제 FESA native0·후속 comparator0과 구분한다. 이전135.9302297초와의 차이는 서로 다른 source의 단일 개발 표본이며 반복 통계나 특정 함수 비용이 아니다.

Shell 명시 영 seed 이후 SW60 수집은 partial이며 collector native4·target 종료 미관측, increment1까지 진행했다. 함수 sample의 Jet 산술·할당·작은 MKL 호출·OpenMP spin은 비용 후보지만 sample 부재를 cache hit 보장으로 바꾸거나 nested inclusive CPU를 합산해 wall time을 만들지 않는다. 전체 shell100초·최종 전체 Debug·원본5개 재실행·최종 물리 평가는 미완료다. 보류 후보의 PASS를 복원 source나 최신 통합본에 승계하지 않는다.

Refactor 통합 후 남은 성능 한계

Refactor의 2026-10-16 0b8de3a 당시 기록은 ShellNL whole elapsed가 원본 대비 Native+86.52%·CMake+120.91% 회귀했다고 보고한다. 이는 해당 source·환경의 과거 단일 기록이며 변산·메모리·배경 부하와 원인은 미확정이다. 이후 객체 복사 제거 revision의 정적 검증을 새 Release 성능 향상으로 승계하지 않는다. 원본 .build archive는 통합 작업 공간으로 자동 전달되지 않았으며 이번 병합에서 해당 시간의 원시 근거를 새로 재현한 것은 아니다. 통합된 코드와 정적 검증 범위는 병합 현황을 따른다. 새 Release 성능은 측정하지 않았다. 지속 SpMV cache나 새 산술 최적화를 도입한 것은 아니며, 성능 회귀 원인 해결·새 benchmark는 별도 작업으로 남긴다.