Merge pull request #53 from zhangzhuang15/dev

Dev

Author: zhangzhuang15

.vitepress/config.ts

@@ -359,6 +359,10 @@ export default defineConfig({
               text: 'crossbeam 学习笔记',
               link: '/blog/crossbeam-learning-notes'
             },
+            {
+              text: 'GPU介绍',
+              link: '/blog/gpu'
+            },
             {
               text: "博客文章阅读系列",
               collapsed: true,

docs/blog/crossbeam-learning-notes.md

@@ -27,6 +27,15 @@ struct CachedPadded<T> {
 }
 ```
 
+一个C语言内存对齐的例子：
+```c 
+struct M {
+    int64_t a;
+    int32_t b;
+}
+```
+a必须8字节对齐，b必须4字节对齐，而默认情况下，M就必须按照成员中，内存对齐要求最大的那个对齐，也就是8字节对齐。这就意味着，b不足8字节，需要在b的后边补充4字节，这4个字节就是padding。实际上，我们还可以让M按照8的整数倍对齐，比如按照16字节对齐，32字节对齐。但是，我们不能按照4字节对齐。这是因为按照4字节对齐，b占用的起始内存地址一定是4的整数倍，但是对于a来说，它的起始内存地址不一定是8的整数倍。在x86_64平台来说，可能没什么，但是在arm平台中，如果没有对齐，访问a的时候就会出现硬件错误。
+
 ## BackOff
 用于控制线程自旋。在自旋的基础上，如果超过指定次数的尝试后，调用操作系统API使得线程交出CPU，等待下一次操作系统调度后，重新执行。BackOff的执行效果就是，让线程自旋一会儿，或者自旋一会儿后交出CPU。
 
@@ -148,3 +157,27 @@ Release/Acquire的内存顺序，在落实到汇编代码层面的时候，根
 
 但是，aarch64体系就不同了，它是弱内存顺序的类型，会有单独的汇编指令实现Release/Acquire的内存顺序要求，比如读取数据的时候会用ldar（load-accquire）指令，写入数据用stlr(store-release)指令。
 :::
+
+
+## sync tool 
+### WaitGroup
+WaitGroup提供一个wait方法，当所有的线程都执行到wait的时候，就会唤醒所有线程继续往下执行。
+
+WaitGroup内部用`Arc`包含了一个Inner，Inner由 `Mutex<usize>`和`CondVar`构成。在 wait 方法被调用时，会修改 `Mutex<usize>`, 令其内部的数据减1，如果不等于0，意味着还有其他的线程没有执行wait方法呢，于是当前线程会利用`CondVar.wait`进入阻塞状态；如果等于0，意味着所有的线程都执行过wait方法了，于是当前线程使用`CondVar.notify_all`唤醒所有线程。WaitGroup在多线程之间传送时，必须在当前线程内，调用WaitGroup.clone创造一个副本，将副本发送给另一个线程，也就是在创建副本的时候，`Mutex<usize>`内部的数据增1.
+
+### Parker 
+Parker是阻塞线程和恢复线程的工具，当调用`parker.park`的时候，就会把当前线程挂起，当调用`parker.unpark`的时候，就会使得某个线程从挂起中恢复。
+
+做到这些也不难。Parker内部有一个原子数据，一个Mutex, 一个CondVar。阻塞和恢复线程，就是通过Mutex和CondVar完成的。原子数据用来标记当前现场的情况，是刚从挂起中恢复，还是空闲。
+
+
+## channel
+Channel的实现原理并不难。按照Channel的使用形式来看，它应该有一个东西，让用户写入数据，这就是Sender；它还要有一个东西，让用户读取数据，这就是Receiver。而作为数据的存储地，Channel应该有一个数据容器，比如数组或者列表。数组的容量是有限的，这样的Channel就是 bounded Channel。列表的容量是无没有限制的，这取决于操作系统的内存，这样的Channel就是 unbounded Channel。后边，我们把这种数据容器称为channel。这样，Channel就等同于 Sender + Receiver + channel。
+
+Sender和Receiver共享channel的引用，这样就可以做到一个发送数据，一个接受数据。如果发送方和接收方不是操作同一个channel，那么它们之间无法达成数据交流。
+
+你定会好奇，channel什么时候被drop呢？别担心，在 Sender 和 Recevier 内部，拥有计数器。当Sender或者Receiver被drop的时候，计数器会减1，当计数器为0的时候，它们就会触发 channel 的 drop。
+
+还有一个问题是，如果channel满了，如何阻塞Sender? 如果channel空了，如何阻塞Receiver呢？秘密在channel身上，它除了封装读、写数据的操作外，还拥有Senders属性和Receivers属性，分别记录被阻塞的Sender和Receiver。要阻塞Sender的时候，只需要将Sender写入到channel.Senders，然后调用上一节中提到的Parker.park，就能实现阻塞，当然也可以使用Rust标准库的thread::park，也可以使用上一节提到的Mutex+CondVar的方法。Receiver的情况同理，写入到Receviers。
+
+crossbeam在实现的时候做了优化，比如用无锁技术去实现写入和读取，在正式阻塞线程之前，会用自旋锁的方法反复尝试争取资源，阻塞和恢复线程的封装在Context里实现，而Context放在了thread_local里，Senders和Receivers会持有Context的引用。

docs/blog/gpu.md

@@ -0,0 +1,34 @@
+---
+title: "GPU介绍"
+page: true
+aside: true
+---
+
+# GPU介绍
+以英伟达cuda下的GPU为准
+
+## GPU结构
+![GPU结构简图](/gpu-structure.png)
+
+值得注意：
+1. GPU拥有多个SM
+2. 每个SM拥有多个CUDA核心
+3. 每个SM的CUDA核心可以访问L1缓存和共享内存
+4. 每个CUDA核心负责执行一个线程
+5. CUDA核心只负责数据计算和逻辑计算，不负责控制，SM负责控制
+6. 所有的SM共享L2 cache
+7. GPU显存全局共享
+8. 访存速度：寄存器 > 共享内存 >= L1缓存 > L2 缓存 > GPU显存
+
+## GPU计算流程
+1. CPU申请一部分主机内存，存入要计算的数据
+2. CPU向GPU发送指令，让GPU从GPU显存中开辟一块内存空间
+3. CPU向GPU发送指令，GPU将要计算的数据从主机内存复制到GPU显存刚才开辟的空间
+4. CPU向GPU发送计算指令，GPU驱动SM开始并行计算
+5. GPU将计算结果从GPU显存拷贝到主机内存，通知CPU拿结果
+
+## CUDA编程
+使用CUDA编程，驱动GPU工作。CUDA可以简单理解为一个定制化的C语言，其语法结构主体上和C/C++很像，不能用普通的C/C++编译，要使用专门的编译器编译。CUDA编写的程序是并行运行的，跑在每一个CUDA核心上。假设有一个矩阵乘法运算，A矩阵（M行K列）和B矩阵（K行N列），如果放在CPU计算，CPU要计算出M*N中每一个数据，GPU却不同，每个CUDA核心只需要计算M*N中的一个数据即可。由于GPU的CUDA核心众多，可以完成M*N个CUDA核心并行计算，而CPU的核心数量少，无法支持那么多的并行量，比如 M3 Pro 入门版芯片的CPU核心是6+6的，意味着最多也就16个线程的并行计算。
+
+
+<Giscus />

docs/blog/learning-cpp.md

@@ -1127,6 +1127,138 @@ int main() {
 }
 ```
 
+### module
+C++20支持Module，代码编写单元是Module，不再是 `.h` + `.cpp` 的组合。
+
+`.h`有着缺陷：
+1. 拖慢编译速度
+2. 符号污染
+3. 重复声明
+
+在开始介绍如何使用之前，请确保c++编译器支持C++20标准。我这里以macOS平台的Clang为例，Clang版本号是19.1.5, 安装方法是 `brew install llvm`。虽然Clang官网文档里说，Clang15已经支持C++20 module的很多特性，但是经我实验，发现`global module` `module partition` 支持的有问题。
+
+:::code-group
+```cpp [src/util/util.cppm]
+export module util;
+export import :math;
+export import :console;
+```
+
+```cpp [src/util/console.cppm]
+module;
+#include <string>
+export module util:console;
+
+export namespace util {
+ void error_toast(std::string s);
+}
+```
+
+```cpp [src/util/console.cpp]
+module;
+#include <iostream>
+#include <string>
+module util:console;
+
+namespace util {
+void error_toast(std::string s) {
+    std::cout << "error: " << s << std::endl;
+}
+}
+```
+
+```cpp [src/util/math.cppm]
+export module util:math;
+
+namespace util {
+int add(int a, int b);
+}
+```
+
+```cpp [src/util/math.cpp]
+module util:math;
+
+namespace util {
+int add(int a, int b) {
+    return a + b;
+}
+}
+```
+
+```cpp [src/main.cpp]
+import util;
+
+int main() {
+    util::error_toast("help me");
+    return 0;
+}
+```
+
+```makefile [src/makefile]
+CC = /opt/homebrew/opt/llvm/bin/clang++
+Flags = -std=c++20
+
+
+version:
+	$(CC) --version 
+
+clear:
+	rm -f *.o
+	rm -f *.pcm
+	rm -rf util/*.o
+
+build-util:
+	$(CC) $(Flags) --precompile util/console.cppm -o util-console.pcm 
+	$(CC) $(Flags) -c util/console.cpp -fmodule-file=util:console=util-console.pcm  -o util.console.impl.o
+	$(CC) $(Flags) --precompile util/math.cppm -o util-math.pcm 
+	$(CC) $(Flags) -c util/math.cpp -fmodule-file=util:math=util-math.pcm -o util.math.impl.o 
+	$(CC) $(Flags) --precompile util/util.cppm -fmodule-file=util:console=util-console.pcm \
+	-fmodule-file=util:math=util-math.pcm -o util.pcm
+	
+build: build-util
+	$(CC) $(Flags) -c main.cpp -fmodule-file=util=util.pcm  \
+	-fmodule-file=util:console=util-console.pcm \
+	-fmodule-file=util:math=util-math.pcm \
+	-o main.o
+	$(CC) $(Flags) main.o util.console.impl.o  util.math.impl.o \
+	-o main
+
+run: clear build
+	@./main 
+	make clear
+
+.PHONY: clear build-util build run version
+```
+:::
+
+编译：
+```shell 
+make build
+```
+
+运行：
+```shell 
+./main
+```
+
+`.cppm`就是采取模块化的cpp文件扩展名，一般来讲，我们只在这个文件里编写函数、类、结构体等等声明，但是也能给出实现。考虑到扩展，不建议在`.cppm`中给出实现。而`.cppm`里的声明，我们放在`.cpp`里实现。
+
+你可以看到，`src/util/console.cppm`里写的是声明，`src/util/console.cpp`是模块的实现。二者的区别在于，声明的一方，用 `export module` 交代模块名；实现的一方没有`export`。无论是哪一个，如果想要引入`.h`，必须放在`module;`后边， 本模块名的前边（`export module util:console`, `module util:console`）.
+
+`util:console`令你很奇怪吧？这个就是`module partition`, 标识它是 `module util`的一部分，因此你在 `src/util/util.cppm` 里看到 `export import :console;`，意思就是把 `util:console`声明的东西引入进来，并且暴露出去，供上层调用。
+
+module最麻烦的地方就是编译逻辑。你可以这样理解，`.cppm`要编译为`.pcm`，这个`.pcm`的作用是：
+1. 在编译`.cpp`的时候，遇到`import <module_name>`了，告诉编译器到哪里找到`<module_name>`的符号信息
+2. 在编译另外一个`.cppm`的时候，遇到`import <module_name>`了，告诉编译器到哪里找到`<module_name>`的符号信息
+
+所以，你看到了，在编译`util.cppm`的时候，我们用到了`util-console.pcm`和`util-math.pcm`。在编译`main.cpp`的时候，我们用到了`util.pcm`,`util-console.pcm`和`util-math.pcm`。
+
+但最终，是`.o`文件编译为最终的可执行文件，和`.pcm`无关了。值得注意的是，如果`.cppm`你不仅声明了，还给出定义了，你除了将这个文件编译为`.pcm`，还要编译为`.o`，毕竟你给出了实现。
+
+`util-console.pcm`的名字是有讲究的，对于声明了`export module A`的`.cppm`文件，我们编译的结果应命名为`A.pcm`，对于声明了`export module A:B`的`.cppm`文件，我们编译的结果应命名为`A-B.pcm`。
+
+更详细的指引，请看[Clang 15.0.0 | Standard C++ Modules](https://releases.llvm.org/15.0.0/tools/clang/docs/StandardCPlusPlusModules.html#quick-start)
+
 
 ## lvalue, rvalue and movable semantic
 lvalue: 有明确内存地址的数据；

docs/blog/swift-package-manager.md

@@ -5,7 +5,7 @@ aside: true
 ---
 
 ## Description 
-我是一个很痴迷Rust的人，就是因为它里边有个叫做类型模式匹配的东西，表达能力极强。偶然的时候，我发现Swift里边也有，又看了下其他语法，感觉Swift也很不错，想深入了解一下。我是写前端的，要想写起来一个前端项目，npm/pnpm/yarn这样的工具必不可少，webpack/rollup/vite这样的工具也不能丢。在Rust, 这些功能由统一的工具cargo实现，非常方便。那么，我要了解swift，自然而然就想到了它有没有包管理工具，它是如何拆分模块的。
+我是一个很痴迷Rust的人，因为它里边有个叫做类型模式匹配的东西，表达能力极强。我发现Swift里边也有，又看了下这门语言的语法，感觉Swift也很不错，想深入了解一下。我是写前端的，要想写一个前端项目，npm/pnpm/yarn这样的工具必不可少，webpack/rollup/vite这样的工具也不能丢。在Rust, 这些功能由统一的工具cargo实现，非常方便。那么，我要了解swift，自然而然就想到了它有没有包管理工具，它是如何拆分模块的。
 
 ## Fucking Module
 在夸swift之前，我必须要喷它，它的module管理太垃圾了。在前端，你如果想使用一个模块，你需要：
@@ -14,8 +14,8 @@ import { hello } from "../hello.js"
 ```
 Good：
 - 能看到我要使用的函数是什么
-- 能看到这个函数在哪个地方
-- 即便是自定义的模块，只需按照文件路径引入即可
+- 能看到这个函数定义在哪个地方
+- 自定义的模块，只需按照文件路径引入即可
 
 但是，swift就不一样：
 ```swift
@@ -24,13 +24,13 @@ import Foundation
 
 Bad:
 - Foundation 在哪里我不知道
-- 用什么函数不知道
+- 什么函数可以用，我不知道
 - 如果是自定义的模块，该怎么引入也不知道
 
 问了GPT，也没告诉我什么有效信息。我决定自己趟一次浑水。
 
 ## swift package manager 
-swift据说由若干个包管理工具，我只尝试了官方的工具。
+swift据说有多个包管理工具，我只尝试了官方的工具。
 
 创建个项目看看吧。
 ```shell
@@ -420,6 +420,58 @@ let package = Package(
 )
 ```
 
+## 入口文件
+在上边的例子中，`Sources/Main`里边，只有一个`main.swift`，如果我增加一个swift文件行不行，如果把`main.swift`换成另一个文件名，行不行呢？
+
+::code-group
+```swift [Package.swift]
+// swift-tools-version: 6.0
+// The swift-tools-version declares the minimum version of Swift required to build this package.
+
+import PackageDescription
+
+let package = Package(
+    name: "module-demo",
+    targets: [
+        // Targets are the basic building blocks of a package, defining a module or a test suite.
+        // Targets can depend on other targets in this package and products from dependencies.
+        .executableTarget(
+            name: "hello",
+            path: "Sources/Main"
+        ) 
+    ]
+)
+```
+```swift [Sources/Main/b.swift]
+func hello() {
+    print("hello peter")
+}
+```
+```swift [Sources/Main/a.swift]
+func main() {
+    hello()
+}
+hello()
+```
+:::
+
+执行:
+```shell 
+swift run hello
+```
+很遗憾，无法执行。因为swift无法知道a.swift和b.swift到底谁才是入口文件。
+
+给出swift入口文件的方法有两种，第一种就是给出`main.swift`，也就是说将`a.swift`改为`main.swift`。另外一种是将`a.swift`的内容调整为：
+```swift 
+@main 
+struct App {
+    static func main() throws {
+        hello()
+    }
+}
+```
+
+
 
 ## 感受
 只能说功能都覆盖到了，但是和他宣传的样子相比，实在算不上简单，教程也少，Fuck! 和 Go，Rust相比，特别是Rust相比，就是个弟弟。