Graph Compilation Common Infrastructure Constraint Document【免费下载链接】geGEGraph Engine是面向昇腾的图编译器和执行器提供了计算图优化、多流并行、内存复用和模型下沉等技术手段加速模型执行效率减少模型内存占用。 GE 提供对 PyTorch、TensorFlow 前端的友好接入能力并同时支持 onnx、pb 等主流模型格式的解析与编译。项目地址: https://gitcode.com/cann/geGraph and other data structures as common infrastructure,usability, compatibilityshould be prioritized when designing. Common infrastructure is the foundation of the entire system, its design quality directly affects maintainability and extensibility of upper layer modules. Below summarizes core principles from architecture design level.Core Design ConceptsCommon infrastructure design should follow these core ideas:Stability First: Once infrastructure is established, change cost is extremely high, must consider long-term evolution when designingMinimal Dependencies: Reduce dependencies on other modules, improve independence and portabilityBackward Compatibility: Interface evolution must maintain backward compatibility, avoid breaking existing codeSeparation of Concerns: Infrastructure only provides generic capabilities, does not perceive specific business logicObservability: Built-in necessary debugging and monitoring capabilities, reduce problem localization cost1. Module Independence and CohesionDesign Philosophy:Modules should have clear boundaries and explicit responsibilities, dependency relationships should be explicit and minimized. Module internal implementation details should not leak, external dependencies should be controllable.Architecture Principles:Dependencies between modules should be explicit and unidirectional, avoid implicit dependencies causing couplingModule splitting should be based on responsibility cohesion, not implementation technical detailsModules should be self-contained, their dependency relationships should be declared through explicit interfacesConcrete Manifestation in GE:SO file dependencies should be explicit, avoid implicit symbol dependencies (verified throughldd -r)Infrastructure SO splitting (libgraph.soandlibgraph_base.so) should consider different deployment scenariosHistorical implicit dependencies (specifically libgraph_bases dependency on libgraph) should not continue to expand, need gradual cleanup2. Module Boundary Stability and EvolvabilityDesign Philosophy:Module boundaries should be relatively stable, able to maintain external interface compatibility while internal implementation evolves. Boundary adjustments need careful impact scope assessment.Architecture Principles:Module internal implementation details can freely evolve, but external interfaces must remain stableBoundary adjustments (such as module归属 changes) need to consider all usage scenariosBackward compatibility is the primary constraint of interface evolutionConcrete Manifestation in GE:CC file归属 adjustments between different SOs need to evaluate multiple deployment scenarios (stub package, non-stub package, tiny scenario)Resource-constrained scenario module size constraints need to be consideredBoundary change impact analysis should cover all possible combination scenarios3. Interface Evolution Compatibility AssuranceDesign Philosophy:Interfaces are contracts for module collaboration, interface evolution must guarantee not breaking existing code. Even non-public internal interfaces need to consider compatibility.Architecture Principles:Interface design should consider possible future extension requirementsInterface evolution should prefer adding new interfaces, not modifying existing interfacesInterface changes (including parameters, return values, semantics) need to evaluate all callersConcrete Manifestation in GE:External interfaces (external) and internal interfaces both need to consider ABI compatibilityOld version component and new version infrastructure combination scenarios need special attentionInterface extension preferentially adds new interfaces, avoid modifying existing interface default parameters4. Observability and Performance BalanceDesign Philosophy:Observability (logging, monitoring, debugging) is the foundation of system maintainability, but must balance between performance overhead and observability value.Architecture Principles:Infrastructure should provide moderate observability capabilities, but avoid excessive loggingHot path observability operations must be carefully designed, avoid performance degradationObservability granularity should be configurable, adapt to different scenario requirementsConcrete Manifestation in GE:Infrastructure interface logging needs to consider call frequency constraints (such as no more than 2 times within 1 second)ERROR logs must be used cautiously (callers cannot ignore, must handle)High-frequency call scenarios need special logging strategies (sampling, grading, etc.)5. Interface Design Robustness PrincipleDesign Philosophy:Interface design should anticipate various possible calling scenarios, including normal scenarios, boundary scenarios, misuse scenarios, guarantee correct usage through design not documentation.Architecture Principles:Interfaces should explicitly declare their calling constraints (such as reentrancy, thread safety)Interfaces should prevent misuse through type system, assertions and other mechanismsInterface performance characteristics should be reflected in design, not optimized afterwardsConcrete Manifestation in GE:Graph operation interfaces need to consider reentrancy and idempotencyNested calls, repeated calls and other scenarios need提前设计 foolproof mechanismsHot path interface performance optimization needs to be considered at design stage (avoid repeated calculation, temporary object creation)6. Separation of Concerns and Layered DesignDesign Philosophy:Common infrastructure should focus on providing generic, abstract foundational capabilities, should not perceive specific business logic. Business logic should be implemented in higher layer modules.Architecture Principles:Infrastructure should provide domain abstractions, not business rulesInfrastructure state should be generic and reusable, not business-specificBusiness logic changes should not affect infrastructure interfaces and implementationConcrete Manifestation in GE:Graph data structures should not contain business state (such asis_valid_flag_,need_iteration_, etc.)Business-related markers and attributes should be maintained in upper layer modulesInfrastructure-provided operations should be generic graph operations (storage, query, modification)7. Concurrency Model Clarity PrincipleDesign Philosophy:Concurrency model is an important constraint of module design, must be明确 at design stage. Unclear concurrency model will lead to hard-to-reproduce concurrency issues.Architecture Principles:Modules must明确 their concurrency model (single-threaded, multi-threaded read, thread-safe, etc.)Concurrency model selection should be based on usage scenario and performance requirement trade-offsConcurrency model changes are destructive changes, need to be determined at design stageConcrete Manifestation in GE:Graph infrastructure currently adopts single-threaded model, does not support concurrent modificationConcurrency safety is guaranteed by business layer, not provided by infrastructureIf need to support concurrency in future, need to明确 interface semantics and usage constraints at design stage8. Cross-Platform Consistency Portability PrincipleDesign Philosophy:Common infrastructure may be used on different platforms, different compilation environments, must guarantee behavior consistency. Implementation detail choices should not introduce platform differences.Architecture Principles:Avoid relying on implementation-defined or undefined behaviorChoose data structures and algorithms with deterministic semanticsConcrete Manifestation in GE:Avoid using containers with不确定 iteration order (such asunordered_map)Model file compatibility needs to consider differences between different compilers and standard library implementations9. Debuggability and Maintainability Built-in PrincipleDesign Philosophy:Debuggability should not be a feature added afterwards, but should be built-in at design stage. Infrastructure observability is part of its intrinsic quality.Architecture Principles:Data structure complete state should be observable and exportableWhen adding new fields or features must synchronously update observability supportObservability capabilities themselves should also be easy to extend and maintainConcrete Manifestation in GE:Graph serialization is the main维测手段, must guarantee completenessWhen adding new fields need synchronously update serialization logicSerialization format needs to consider version compatibility and readability【免费下载链接】geGEGraph Engine是面向昇腾的图编译器和执行器提供了计算图优化、多流并行、内存复用和模型下沉等技术手段加速模型执行效率减少模型内存占用。 GE 提供对 PyTorch、TensorFlow 前端的友好接入能力并同时支持 onnx、pb 等主流模型格式的解析与编译。项目地址: https://gitcode.com/cann/ge创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考