tttt's

学习一下这个帖子内的东西22种设计模式的C++实现 - 知乎 (zhihu.com)1. 工厂方法模式（Factory Method） (yuque.com)

[下面这个帖子有一些从硬件开始讲的内容，包含一些运维命令： GPU服务器中的PCIe与NUMA性能优化

ClashVerge上的HTTPS的端口，得和环境变量中的一样 export HTTPS_PROXY=http://127.0.0.1:7890 查看7890端口是否被占用：sudo netstat -nlp | grep “7890” 在终端用wget来判断，终端是否已经成功设置proxy 用下面来找一下所有的环境变量env | grep “53”

101_npmnpm 是 Node Package Manager（Node 包管理器）的缩写，它是 JavaScript 运行时环境 Node.js 的默认包管理工具。 简单来说，npm 主要做两件事： 包管理仓库 (Registry)： 它是一个巨大的在线仓库，存放了全球开发者共享的、可复用的 JavaScript 代码模块（称为“包”或“模块”）。这些包可以是库、框架、工具、命令行程序等等（例如 React, Vue, Express, Lodash 等）。 开发者可以把自己的包发布到这个公共仓库供他人使用。 命令行工具 (CLI - Command Line Interface)： 它是一个安装在开发者电脑上的命令行程序（通常随 Node.js 一起安装）。 通过运行 npm 命令（如 npm install, npm start, npm publish 等），开发者可以： 安装包：从 npm 仓库下载所需的包及其依赖到本地项目中。 管理依赖：在项目根目录下的 package.json 文件中记录项目所依赖的包及其版本信息。 运行脚本：定义和执行项目相关的任务...

本篇目前是占位页(原文较短),正文待后续用 AI 工具充实。原始笔记: OSCFD_tutorial湍流在simpleFOAM求解器中，是靠在simpleFoam.C中定义： 1#include "turbulentTransportModel.H" 这个文件位于$FOAM_SRC/TurbulenceModels/incompressible/turbulentTransportModels，见下： LESModel为一个typedef[PDF 素材:OSCFD2019_ImplementTurbulenceModel.pdf] 湍流模型在求解器createFields.H中，构建了一个湍流相关的指针： [PDF 素材:OSCFD2019_ImplementTurbulenceModel.pdf] 上述的laminarTransport，由createFields.H中构建： 1singlePhaseTransportModel laminarTransport(U,phi); 有这个laminalTranpsort的原因是，eddy-viscosit...

ABI概述一、什么是 ABI Info，以及它的作用 ABI（Application Binary Interface，应用二进制接口）定义了在二进制层面上，程序与运行时环境之间如何进行交互的规范。它包含但不限于： 调用约定（calling convention）：参数传递方式（寄存器还是栈）、返回值位置、调用方与被调用方的协作方式。 数据类型的大小与对齐方式（int、指针、结构体等的字节大小、对齐边界）。 符号命名与链接符号的命名约定（name mangling 的规则，C、C++ 等语言的差异）。 栈帧布局、异常处理、栈展开、线程本地存储（TLS）的约定。 动态链接时的符号解析、模块边界（如共享库的接口导出/导入、ABI 版本）。 作用： 让不同语言、不同编译器、不同版本的库/模块能够在同一二进制层面正确交互。 保障二进制兼容性：你编译的程序能在目标系统上正确运行、调用系统库和其他库时不会崩溃或行为异常。 方便移植与复用：同一份二进制接口可以在不同平台/硬件上实现，只要实现相同的 ABI。 二、ABI 兼容性是什么 兼容性本质上是“...

为什么 C++ 引入 import（C++20 Modules）特性C++ 在 C++20 中引入了模块（Modules），通过 import 关键字替代传统的 #include 头文件机制的部分用途。其核心动机是解决 C/C++ 头文件模型长期存在的工程痛点，并显著提升编译速度、可维护性与可用性。 背景：传统 #include 的问题 文本拼接模型的固有缺陷#include 只是预处理期的文本复制粘贴： 重复解析同一份头文件（即便有 include guard 也只是避免重复定义，解析仍会发生）。 容易引入宏污染（宏全局可见，互相干扰，难以约束可见性）。 依赖顺序敏感（宏/类型前置声明的顺序问题）。 编译速度与可扩展性差大型工程动辄数千头文件，编译器反复解析同样的声明，导致： 冷启动全量编译慢。 增量编译常常因为依赖扇出大而不够快。 ODR（One Definition Rule）风险与可见性混乱模板/内联函数在多个翻译单元重复实例化与定义，容易触发 ODR 问题。 封装性和接口表达能力不足头文件暴露过多实现细节；没有“接口/实...

在“面向DCU的OpenFOAM并行加速研究”中，DCU通常指的是数据处理单元（Data Compute Unit ）。 在计算机硬件领域，DCU是一种专门设计用于高效处理数据密集型计算任务的芯片或硬件模块。与传统的CPU（中央处理器）和GPU（图形处理器）不同，DCU针对特定的数据处理任务进行了优化，比如在大规模数据处理、机器学习和高性能计算等领域有着广泛的应用。 在OpenFOAM的语境下，OpenFOAM是一款用于计算流体动力学（CFD）等工程模拟的开源软件。使用DCU对OpenFOAM进行并行加速研究，目的是利用DCU强大的并行计算能力，加速OpenFOAM模拟过程中的计算，提高计算效率 ，从而更快速地完成复杂的流体动力学模拟等任务。 DCU（Deep Computing Unit）与GPU的区别 这里的DCU的D是Data还是该是Deep？ 确认是deep DCU 加速卡是一种协处理器，其架构类似于GPU，具有相似的特性，本文通过在新型国产超算平台上安装OpenFOAM，并在单节点实现了多块DCU 加速卡与OpenFOAM 的结合，创建了全新的基于DCU 加速卡的求...

GDB 相关操作笔记（OpenFOAM-Laplacian 跟踪示例）常用命令总结1234567891011121314151617181920212223242526info locals //显示所有局部变量，OpenFOAM里别用，会爆炸info variables/classes/functions/selectors //顾名思义，但都别乱用，容易爆炸info break //显示所有breakpointsinfo source //显示当前位置的文件调用关系，非常有用，尤其是被调用的文件是link的时候n //next，单个文件里的下一行s //step，下一步，能够跳转进入function内部finish //从当前function跳出return //取消当前函数的执行，并立即返回，后面可以跟一个数值，作为函数的返回值c //continue直到下一个breakpointr //run，开始运行codeb //设置brea...

逻辑处理器、线程（Thread）和核心（Core）是计算机处理器架构中的三个相关但不同的概念。以下是它们之间的区别和联系： 核心（Core）： 核心是CPU内部的一个物理单元，能够独立执行计算任务。 每个核心都有自己的一套执行单元和缓存。 在多核心处理器中，每个核心可以并行处理不同的任务。 线程（Thread）： 线程是操作系统能够进行运算调度的最小单位，是被系统独立调度和分派的基本单位。 一个进程（Process）可以包含多个线程，每个线程可以并行执行不同的任务。 线程共享进程的内存空间和资源，但拥有自己的程序计数器、寄存器集合和堆栈。 逻辑处理器（Logical Processor）： 逻辑处理器是指从操作系统的角度看，能够独立执行线程的处理器。 逻辑处理器可以是物理核心，也可以是超线程技术（Hyper-Threading Technology，HT）创建的虚拟核心。 超线程技术允许单个物理核心模拟多个逻辑核心，每个逻辑核心可以执行不同的线程。 区别： 物理核心是实际存在的硬件单元，而线程是操作系统层面的概念，用于任务的并行执行。 逻辑处理器可以是物理...