互斥与同步

在进程/线程并发执行的过程中，进程/线程之间存在协作的关系，例如有互斥、同步的关系。

为了实现进程/线程间正确的协作，操作系统必须提供实现进程协作的措施和方法，主要的方法：

• 基于原子操作指令(汇编) —— 测试和置位（Test-and-Set）指令, 或者（如Compare-And-Swap，CAS）
• 锁：加锁、解锁操作；
  • 自旋锁(spin lock， 忙等待锁)，
  • 无等待锁：思想，把当前线程放入到锁的等待队列，然后执行调度程序
• 信号量：P、V 操作；

这两个都可以方便地实现进程/线程互斥，而信号量比锁的功能更强一些，它还可以方便地实现进程/线程同步。

常见问题

悲观锁

1. 读写操作时，需要预先加锁，防止其他进程对资源的访问。
2. 通过互斥锁（Mutex）和信号量（Semaphore）来实现。

乐观锁

1. 在读取或修改共享资源时，并不先进行加锁操作，而是先读取资源，然后在对资源进行写操作时再进行一次比较，看看在这个时间间隔内是否发生了竞争。如果没有发生竞争，就可以将更新后的值写入共享资源，并结束操作；如果发生了竞争，则需要放弃本次更新，并进行重试
2. 通过版本号的方式来实现。在共享资源中记录该资源的版本号，当一个进程想要修改共享资源时，需要先获取当前资源的版本号。如果当前版本号与自己保存的版本号相符，说明没有其他进程在这段时间内修改该资源，则可以进行写操作；如果版本号已经发生变化，则说明有其他进程对该资源进行了修改，当前进程需要放弃本次写操作，更新版本号，重新获取新的资源，并重新执行操作。

原子操作

Test-and-Set 和 Compare-and-Swap (CAS) 都是并发编程中的重要原子操作指令，通常用于同步和处理多线程或多进程环境中的竞争条件。它们的作用是确保某些操作在执行时不会被中断，以保持数据一致性和避免并发冲突。我们来详细了解这两个命令。

1. Test-and-Set (TAS) 指令

• 通常用于控制锁定状态，通过设置标志位来获取锁，它返回原始值（通常是锁状态），用于判断锁是否已经被占用。
• 它通常用于实现自旋锁、互斥锁（mutex）或锁标志位。

它的操作过程如下：

• Test: 检查指定位置（通常是一个布尔标志位或整数）当前的值。
• Set: 将这个位置的值设置为 1 或 “true”。

操作是原子的，即不会被中断或干扰，保证在并发环境下，多个线程或进程不能同时修改同一位置。

用途：

• 实现自旋锁（Spinlock）：线程反复检查一个共享变量，如果该变量表示未被锁定，线程会尝试获得锁。
• 防止竞争条件：确保在并发操作时，只有一个线程能够设置锁标志，其他线程需要等待。

1
2
3
4
5
6

lock = false;

while (Test_and_Set(lock)) {
    // 如果 lock 已经被设置为 true，则继续自旋等待
}
// lock 成功设置为 true，获取锁

2. Compare-and-Swap (CAS) 指令

• 通常用于无锁编程，它通过比较期望值与当前值来决定是否进行更新（检查指定的内存位置的值是否等于一个预期的值，如果相等，则将该位置的值替换为新的值），适用于复杂的数据结构操作。
• 常用于无锁数据结构和其他更高效的并发操作。

它的操作步骤如下：

• Compare: 比较目标内存位置的当前值是否与预期值相等。
• Swap: 如果当前值等于预期值，就将目标位置的值替换为新的值。如果不相等，则什么也不做。

CAS 也具有原子性，这意味着它在操作期间不会被中断。CAS 是实现无锁编程和避免线程同步问题的常用工具，尤其在需要高性能的并发程序中。

用途：

• 实现无锁数据结构（如无锁队列、栈、哈希表等）。
• 实现线程安全的计数器或标志位操作。
• 用于一些算法（如版本控制或并发计数器）中，确保多个线程不冲突地更新共享数据。

1
2
3
4
5
6
7
8

int expected = 10;
int new_value = 20;

if (Compare_and_Swap(&x, expected, new_value)) {
    // 如果 x 的值为 expected (10)，就将 x 更新为 new_value (20)
} else {
    // 如果 x 的值不为 expected，CAS 操作失败
}

3. TAS的汇编实现

• Test-and-Set (TAS) 操作通常可以通过 XCHG 指令（交换）在 x86 汇编中实现。虽然 x86 没有直接的 Test-and-Set 指令，XCHG 被用作实现类似功能的原子操作。

1
2
3
4
5
6

; x86 示例，使用 XCHG 实现 Test-and-Set
; 假设锁变量位于 memory_location
; eax 是存储旧值的寄存器
mov eax, 0          ; eax 设为 0，表示“未锁定”
xchg eax, [lock]    ; 将 eax 与锁变量交换，如果锁变量是 0，就设置为 1
                    ; 如果返回的 eax 仍为 0，说明锁成功设置

4. CAS的汇编实现

• Compare-and-Swap (CAS) 指令在 x86 中有专门的 CMPXCHG 指令，ARM 等其他架构也有类似的原子操作指令（如 LDREX 和 STREX）。

1

CMPXCHG destination, source

1
2
3
4
5
6
7

; x86 示例，使用 CMPXCHG 实现 Compare-and-Swap
; 假设目标内存位置是 lock，期望值是 eax，新的值是 ebx

mov eax, expected_value    ; 将期望的值加载到 eax
mov ebx, new_value        ; 将新的值加载到 ebx
cmpxchg [lock], ebx        ; 比较 [lock] 的值与 eax（期望值），如果相等则将 [lock] 更新为 ebx（新值）
                        ; 如果不相等，eax 会保存 [lock] 的原值

1
2
3
4
5

; ARM 示例，使用 LDREX 和 STREX 实现 CAS
LDREX R0, [lock]    ; 加载锁的当前值到 R0
CMP R0, R1           ; 比较 R0（当前锁的值）与 R1（期望值）
BNE CAS_FAIL         ; 如果不相等，跳转到失败处理
STREX R2, R3, [lock] ; 如果相等，将 R3（新值）写入 [lock]，并将成功标志存储在 R2

atomic 封装

std::atomic 是对 Test-and-Set 和 Compare-and-Swap 等底层原子操作的高级封装，使得 C++ 开发者可以在多线程环境中更方便、更安全地使用这些原子操作。

原子操作（std::atomic）有如下特点：

• 线程安全：原子操作保证了即使在多线程环境下也能正确地修改和读取共享变量。
• 高效：没有加锁开销，适用于需要频繁检查和修改标志的场景。
• 原子操作的限制：std::atomic 只能用于一些简单的类型（如整数、指针和布尔类型），对于复杂的数据结构，仍然需要其他同步机制（如锁）。

1
2
3
4
5
6
7
8
9
10
11

#include <atomic>

std::atomic<bool> isInited(false);

void initFunction() {
    // 原子操作，检查并更新 isInited
    if (!isInited.exchange(true)) { // mutex  std::call_once 和std::once_flag 也可以实现类似功能。
        // 执行初始化逻辑
        // ...
    }
}

1
2
3

std::atomic<int> counter(0);
counter = 5;  // 这种赋值操作不是原子操作，可能导致线程不安全。
int value = counter;  // 直接读取可能没有同步, 导致缓存不一致问题，多个线程读取的值不一定是最新的。

内存顺序：std::memory_order

对于一个线程里的同一个代码块内的无依赖关系的指令，处理器在运行时会重排序乱序执行。这对原子指令也是一样的。但实际生产中，多个原子操作之间，可能会有依赖关系，比如一个线程读取另一个线程写入的数据。为了确保这些依赖关系的正确性，需要使用内存顺序来控制处理器对指令的重排序。

std::atomic 的操作支持指定内存顺序，这控制了编译器和硬件对操作的优化和重排序。常见的内存顺序选项有：

• std::memory_order_relaxed：没有限制，运行时会乱序。
• std::memory_order_acquire 和 std::memory_order_release：分别用于“获取”和“释放”同步，确保操作顺序。
  • std::memory_order_acquire：保证在此操作之前的所有操作不会被重排序到它之后。
  • std::memory_order_release：保证在此操作之后的所有操作不会被重排序到它之前。
• std::memory_order_seq_cst：默认的内存顺序，保证在多线程程序中，所有原子操作按顺序执行，不允许重排序。但性能可能会略受影响。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26

#include <atomic>
#include <iostream>
#include <thread>

std::atomic<int> counter(0);
std::atomic<bool> ready(false);

void producer() {
    counter.store(42, std::memory_order_release);  // 确保 counter 写入在 ready 之前
    ready.store(true, std::memory_order_release);  // 标记准备好
}

void consumer() {
    while (!ready.load(std::memory_order_acquire)) {}  // 等待 ready 为 true
    std::cout << "Counter: " << counter.load(std::memory_order_acquire) << std::endl;
}

int main() {
    std::thread t1(producer);
    std::thread t2(consumer);

    t1.join();
    t2.join();

    return 0;
}

1. 直接赋值：store

在原子操作中，store 用来将一个值存储到原子变量中。与普通赋值不同，store 会确保在多线程环境下，赋值操作是原子性的（即不会被打断）。

1
2

std::atomic<int> counter(0);
counter.store(5, std::memory_order_relaxed);  // 存储 5

• store 会保证在指定的内存顺序下将值存储到原子变量中，因此它是线程安全的。

2. 加载：load

load 用于从原子变量中读取值。它会确保在多线程环境中，读取操作是线程安全的，并且可以指定内存顺序。

1

int value = counter.load(std::memory_order_acquire);  // 从原子变量读取

• load 会确保读取的是正确同步后的值，避免在多线程场景下出现读取错误。

3. 比较并交换：compare_exchange_strong

• compare_exchange_strong（以及 compare_exchange_weak）广泛应用于实现锁和无锁算法。它会尝试将原子变量的值与一个预期值进行比较，如果相同，则将其更新为新值。如果比较失败，原子变量的值不会更改，并且返回 false。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16

std::atomic<int> value(0);
int expected = 0;
int desired = 42;

if (value.compare_exchange_strong(expected, desired)) {
    std::cout << "CAS succeeded! Value updated to " << value.load() << "\n";
} else {
    std::cout << "CAS failed! Expected: " << expected << ", Actual: " << value.load() << "\n";
}

// 尝试比较并交换
while (!value.compare_exchange_weak(expected, desired)) {
    std::cout << "CAS failed, retrying...\n";
    // 可以执行一些其他的操作或稍微延迟再重试
}
std::cout << "CAS succeeded! Value updated to " << value.load() << "\n";

4. exchange

exchange 是一种常见的原子操作，类似于 store，但它会返回原子变量的先前值。

1

int oldValue = counter.exchange(5);  // 返回更新前的值，并将 counter 设置为 5

• exchange 在多线程环境下是安全的，并且可以返回修改前的值，适用于某些需要获取旧值的场景。

常见锁的优缺点和实现

自旋锁(spinlock)

多线程同步的一种忙等待锁，线程反复检查锁变量是否可用。

• 优点：避免了操作系统进程调度和线程切换，所以自旋锁通常适用在时间比较短的情况下。由于这个原因，操作系统的内核经常使用自旋锁。
• 缺点：如果长时间上锁的话，自旋锁会非常耗费性能，它阻止了其他线程的运行和调度
  • 线程持有锁的时间越长，则持有该锁的线程将被 OS(Operating System) 调度程序中断的风险越大。
• 解决办法：
  • TicketLock 是采用排队叫号的机制。
  • CLHLock和MCSLock通过链表的方式避免了减少了处理器缓存同步，极大的提高了性能，区别在于CLHLock是通过轮询其前驱节点的状态，而MCS则是查看当前节点的锁状态。

1
2
3
4
5
6
7
8
9

std::atomic_flag lock = ATOMIC_FLAG_INIT;

void spinlock() {
    while (lock.test_and_set(std::memory_order_acquire)) {
        // 自旋等待，直到锁被释放
    }
    // 临界区代码
    lock.clear(std::memory_order_release);  // 解锁
}

互斥锁(mutex)

把自己阻塞起来（内核态和用户态之间的切换进入阻塞状态，可能上下文切换），等待重新调度请求。

• 互斥锁的实现
  1. 软件实现：软件互斥锁需要借助操作系统提供的原子操作（如Compare-And-Swap，CAS）来实现 优点是灵活性高 缺点是性能较低，
  2. CAS操作需要三个参数，内存地址A，期望值V，新值N。执行过程如下：
     • 读取内存地址A的原始值，保存在临时变量Value中
     • 比较Value和期待值V是否相等，如果相等则将内存地址A的值更新为新值N
     • 如果内存地址A的值已经被其他线程改变，则不进行更新操作
• TAS（test and set）
  • 一个TAS指令包括两个子步骤，把给定的内存地址设置为1，然后返回之前的旧值。
  1. 硬件实现：硬件互斥锁使用计算机硬件提供的特殊指令（如锁总线指令）来实现。当线程要获取锁时，它会发出一个锁总线指令，这个指令会占用系统总线，使得其他CPU无法读写内存。
     1. 当lock前缀指令执行时，它将锁定处理器总线，确保其他处理器无法同时访问同一内存区域，

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25

#include <iostream>
#include <mutex>
#include <thread>

std::mutex init_mutex_;  // 互斥量，防止多个线程同时初始化

void some_function() {
    // 创建一个 lock_guard 对象，自动锁住 init_mutex_
    std::lock_guard<std::mutex> lock(init_mutex_);

    // 在此作用域内，init_mutex_ 被锁定
    std::cout << "Doing some work inside the critical section...\n";

    // lock_guard 在作用域结束时会自动解锁 mutex
}

int main() {
    std::thread t1(some_function);
    std::thread t2(some_function);

    t1.join();
    t2.join();

    return 0;
}

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39

#include <iostream>
#include <thread>
#include <mutex>
#include <condition_variable>
#include <atomic>

std::mutex mtx;
std::condition_variable cv;
std::atomic<bool> thread_done{false};

void worker_thread() {
    std::this_thread::sleep_for(std::chrono::seconds(2)); // 模拟工作
    std::cout << "Worker thread finished." << std::endl;
    thread_done = true;  // 设置线程完成标志
    cv.notify_one();     // 通知主线程
}

void Final() {
    std::cout << "Final: Waiting for worker thread to finish..." << std::endl;

    // 等待子线程完成
    std::unique_lock<std::mutex> lock(mtx);
    cv.wait(lock, [] { return thread_done.load(); });
    // cv.wait(lock, [this] { return thread_done.load(); }); // in class

    std::cout << "Final: Worker thread finished. Proceeding with cleanup." << std::endl;
}

int main() {
    // 启动子线程
    std::thread t(worker_thread);

    // 在主线程中调用 Final
    Final();

    t.join();  // 等待子线程结束

    return 0;
}

读写锁（ReadWrite Lock）

• 在读操作和写操作之间提供了更细粒度的同步控制。
• 多个线程可以同时获取读锁，但只有一个线程能够获取写锁。
  • 读写锁有三种状态：读加锁状态、写加锁状态和不加锁状态
  • 规则
  • 当读写锁在写加锁模式下，任何试图对这个锁进行加锁的线程都会被阻塞，直到写进程对其解锁。
  • 当读写锁在读加锁模式先，任何线程都可以对其进行读加锁操作，但是所有试图进行写加锁操作的线程都会被阻塞，直到所有的读线程都解锁。
• 缺点：当读者源源不断到来的时候，写者总是得不到读写锁，就会造成不公平的状态。
  • 避免方法： 当处于读模式的读写锁接收到一个试图对其进行写模式加锁操作时，便会阻塞后面对其进行读模式加锁操作的线程。这样等到已经加读模式的锁解锁后，写进程能够访问此锁保护的资源。
• 优点：
  • 读写锁可以提高并发性，允许多个线程同时读取数据，而只有在需要修改数据时才会互斥。
  • 适合对数据结构读的次数远远大于写的情况。

RCU（Read-Copy-Update）

• 对读写锁的一种改进。适用于读多写少场景的数据同步机制。
• 具体内容
  • 并发读取数据不再需要加锁
  • 写数据时，RCU机制通过创建一个副本来实现读写分离，确保在更新过程中没有线程正在读取旧的数据。
    • 写者修改数据前首先拷贝一个被修改元素的副本，然后在副本上进行修改，修改完毕后它向垃圾回收器注册一个回调函数以便在适当的时机执行真正的修改操作。
    • 读者必须提供一个信号给写者以便写者能够确定数据可以被安全地释放或修改的时机。
    • 有一个专门的垃圾收集器来探测读者的信号，一旦所有的读者都已经发送信号告知它们都不在使用被RCU保护的数据结构，垃圾收集器就调用回调函数完成最后的数据释放或修改操作。

通知与同步

适用于大段的修改和同步。

eventfd 事件通知

eventfd 是 Linux 提供的一种用于线程安全的事件通知机制，类似于文件描述符，可以通过读写操作来实现跨线程或跨进程的同步。通过 eventfd，线程或进程可以通过某些事件（例如计数器增减、通知等）来触发其他线程或进程的动作。

eventfd 可以通过两种方式工作：

• 计数器模式：通过 eventfd_write 增加计数器，其他线程或进程可以通过 eventfd_read 来读取这些计数器的值。
• 通知模式：使用 eventfd 进行事件通知，线程或进程通过 eventfd_read 来等待并响应这些事件。

eventfd_read 的功能 : eventfd_read 是一个用于从 eventfd 文件描述符读取事件的系统调用。它会从 eventfd 中读取一个 64 位无符号整数，并返回这个值。这个值通常表示某个事件的状态或计数器的值。

1
2
3
4

#include <sys/eventfd.h>

ssize_t eventfd_read(int efd, uint64_t *value);
ssize_t eventfd_write(int efd, uint64_t value);

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34

#include <sys/eventfd.h>
#include <unistd.h>
#include <iostream>
#include <cstring>

int main() {
    // 创建 eventfd 文件描述符
    int efd = eventfd(0, EFD_NONBLOCK);
    if (efd == -1) {
        std::cerr << "Failed to create eventfd: " << strerror(errno) << std::endl;
        return -1;
    }

    // 写入事件
    uint64_t u = 1; // 写入一个事件值
    ssize_t s = write(efd, &u, sizeof(u));
    if (s == -1) {
        std::cerr << "Failed to write to eventfd: " << strerror(errno) << std::endl;
        close(efd);
        return -1;
    }

    // 读取事件
    uint64_t read_value;
    s = eventfd_read(efd, &read_value);
    if (s == -1) {
        std::cerr << "Failed to read from eventfd: " << strerror(errno) << std::endl;
    } else {
        std::cout << "Read value: " << read_value << std::endl;
    }

    close(efd);
    return 0;
}

概念题

1
2
3
4

P(S):
  while S <= 0:
    // 等待，直到S大于0
  S = S - 1

1
2

V(S):
  S = S + 1

参考文献

https://www.cswiki.top/pages/f398f1/#blocking-i-o

原文链接：https://blog.csdn.net/qq_15437629/article/details/79116590

https://zhuanlan.zhihu.com/p/161936748

Introduction

LLVM Machine Code Analyzer 是一种性能分析工具，它使用llvm中可用的信息（如调度模型）静态测量特定CPU中机器代码的性能。

性能是根据吞吐量和处理器资源消耗来衡量的。该工具目前适用于在后端中使用LLVM调度模型的处理器。

该工具的主要目标不仅是预测代码在目标上运行时的性能，还帮助诊断潜在的性能问题。

给定汇编代码，llvm-mca可以估计每个周期的指令数（IPC）以及硬件资源压力。分析和报告风格的灵感来自英特尔的IACA工具。

github

https://github.com/llvm/llvm-project/tree/main/llvm/tools/llvm-mca

docs

https://llvm.org/docs/CommandGuide/llvm-mca.html

options

architecture

1
2
3
4
5
6

-mtriple=<target triple>
    eg. -mtriple=x86_64-unknown-unknown
-march=<arch>
    Specify the architecture for which to analyze the code. It defaults to the host default target.
-march=<arch>
    Specify the architecture for which to analyze the code. It defaults to the host default target.

1
2
3
4

# 查看支持的arch
llc --version
# 查看具体支持的CPU Architecture
llc -march=x86 -mattr=help

output-report

1
2
3
4
5
6
7
8

-output-asm-variant=<variant id>
    为工具生成的报告指定输出程序集变量。???
-print-imm-hex
    优先16进制输出。
-json
    除了瓶颈分析，基本都支持json格式输出视图
-timeline
    打印指令流水线情况

runtime options

1
2
3
4
5
6
7
8
9
10
11
12
13

-dispatch=<width>
    为处理器指定不同的调度宽度。调度宽度默认为处理器调度模型中的“IssueWidth”字段。
-register-file-size=<size>
    指定寄存器文件的大小。指定时，该项会限制可用于寄存器重命名的物理寄存器的数量。此标志的值为零意味着“无限数量的物理寄存器”。
-iterations=<number of iterations>
    指定要运行的迭代次数。如果此标志设置为 0，则该工具会将迭代次数设置为默认值（即 100）。
-noalias=<bool>
    loads and stores don’t alias
-lqueue=<load queue size>
-squeue=<store queue size>
    在工具模拟的加载/存储单元中指定加载队列的大小。默认情况下，该工具假定加载队列中的条目数量不受限制。此标志的零值将被忽略，而是使用默认加载队列大小。
-disable-cb
    强制使用通用的 CustomBehaviour 和 InstrPostProcess 类，而不是使用目标特定的实现。通用类从不检测任何自定义危险或对指令进行任何后处理修改。

more values/Info

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17

-resource-pressure
    Enable the resource pressure view. This is enabled by default.
-register-file-stats
    启用注册文件使用统计。
-dispatch-stats
-scheduler-stats
-retire-stats
-instruction-info
    启用额外的调度/发出/retire control unit统计。该视图收集和分析指令分派事件，以及静态/动态分派停顿事件。默认情况下禁用此视图。
-show-encoding
    打印指令16进制
-all-stats
-all-views
-instruction-tables
    这与资源压力视图不同，因为它不需要模拟代码。相反，它按顺序打印每个指令的资源压力的理论均匀分布。
-bottleneck-analysis
    打印有关影响吞吐量的瓶颈的信息。这种分析可能很昂贵，并且默认情况下是禁用的。瓶颈在摘要视图中突出显示。具有有序后端的处理器目前不支持瓶颈分析。???

实现逻辑

样例分析

quick overview of the performance throughput

1
2
3
4
5
6
7
8
9

Iterations:        300
Instructions:      900
Total Cycles:      610
Total uOps:        900

Dispatch Width:    2
uOps Per Cycle:    1.48
IPC:               1.48
Block RThroughput: 2.0

1. IPC
   1. 理论最大值是$$\frac{OneLoopInstructions}{Block_RThroughput}=(OneLoopInstructions)*(Block_Throughput)$$
2. uOps Per Cycle
   1. simulated micro opcodes (uOps)
   2. 每个周期的simulated micro opcodes数
   3. 在不考虑循环依赖的情况下，理论上最大值是$$\frac{OneLoopUOps}{Block_RThroughput}=(OneLoopUOps)*(Block_Throughput)$$
   4. A delta between Dispatch Width and this field is an indicator of a performance issue.
   5. The delta between the Dispatch Width (2.00), and the theoretical maximum uOp throughput (1.50) is an indicator of a performance bottleneck caused by the lack of hardware resources, and the Resource pressure view can help to identify the problematic resource usage.
3. Dispatch Width
   1. 发射到乱序后端的最大微指令操作数(the maximum number of micro opcodes/uOps)？
4. Block RThroughput (Block Reciprocal Throughput)
   1. 在不考虑循环依赖的情况下，理论上的每次循环的最大block或者iterations数
   2. 受限于dispatch rate和the availability of hardware resources.

Instruction info view

1
2
3
4
5
6
7
8
9
10
11
12

Instruction Info:
[1]: #uOps
[2]: Latency
[3]: RThroughput
[4]: MayLoad
[5]: MayStore
[6]: HasSideEffects (U)

[1]    [2]    [3]    [4]    [5]    [6]    Instructions:
 1      2     1.00                        vmulps      %xmm0, %xmm1, %xmm2
 1      3     1.00                        vhaddps     %xmm2, %xmm2, %xmm3
 1      3     1.00                        vhaddps     %xmm3, %xmm3, %xmm4

显示了指令里队列每条指令的延迟和吞吐量的倒数。

RThroughput是指令吞吐量的倒数。在不考虑循环依赖的情况下，吞吐量是单周期能执行的同类型指令的最大数量。

Resource pressure view

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25

Resources:
[0]   - JALU0
[1]   - JALU1
[2]   - JDiv
[3]   - JFPA
[4]   - JFPM
[5]   - JFPU0
[6]   - JFPU1
[7]   - JLAGU
[8]   - JMul
[9]   - JSAGU
[10]  - JSTC
[11]  - JVALU0
[12]  - JVALU1
[13]  - JVIMUL

Resource pressure per iteration:
[0]    [1]    [2]    [3]    [4]    [5]    [6]    [7]    [8]    [9]    [10]   [11]   [12]   [13]
 -      -      -     2.00   1.00   2.00   1.00    -      -      -      -      -      -      -

Resource pressure by instruction:
[0]    [1]    [2]    [3]    [4]    [5]    [6]    [7]    [8]    [9]    [10]   [11]   [12]   [13]   Instructions:
 -      -      -      -     1.00    -     1.00    -      -      -      -      -      -      -     vmulps      %xmm0, %xmm1, %xmm2
 -      -      -     1.00    -     1.00    -      -      -      -      -      -      -      -     vhaddps     %xmm2, %xmm2, %xmm3
 -      -      -     1.00    -     1.00    -      -      -      -      -      -      -      -     vhaddps     %xmm3, %xmm3, %xmm4

每次循环或者每条指令执行，消耗的资源周期数。从而找到高资源占用的部分。

Timeline View

可打印流水线情况

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26

Timeline view:
                    012345
Index     0123456789

[0,0]     DeeER.    .    .   vmulps   %xmm0, %xmm1, %xmm2
[0,1]     D==eeeER  .    .   vhaddps  %xmm2, %xmm2, %xmm3
[0,2]     .D====eeeER    .   vhaddps  %xmm3, %xmm3, %xmm4
[1,0]     .DeeE-----R    .   vmulps   %xmm0, %xmm1, %xmm2
[1,1]     . D=eeeE---R   .   vhaddps  %xmm2, %xmm2, %xmm3
[1,2]     . D====eeeER   .   vhaddps  %xmm3, %xmm3, %xmm4
[2,0]     .  DeeE-----R  .   vmulps   %xmm0, %xmm1, %xmm2
[2,1]     .  D====eeeER  .   vhaddps  %xmm2, %xmm2, %xmm3
[2,2]     .   D======eeeER   vhaddps  %xmm3, %xmm3, %xmm4


Average Wait times (based on the timeline view):
[0]: Executions
[1]: Average time spent waiting in a scheduler's queue
[2]: Average time spent waiting in a scheduler's queue while ready
[3]: Average time elapsed from WB until retire stage

      [0]    [1]    [2]    [3]
0.     3     1.0    1.0    3.3       vmulps   %xmm0, %xmm1, %xmm2
1.     3     3.3    0.7    1.0       vhaddps  %xmm2, %xmm2, %xmm3
2.     3     5.7    0.0    0.0       vhaddps  %xmm3, %xmm3, %xmm4
       3     3.3    0.5    1.4       <total>

影响因素包括：

1. 数据冲突/依赖：读后写，写后读依赖 。无法指令级并行，也可以通过寄存器重命名解决
2. 结构冲突：占用发射位 或者 同一硬件
3. 控制冲突：分支？
4. instructions must retire in program order, so [1,0] has to wait for [0,2] to be retired first

Bottleneck Analysis

• 可以分析出数据冲突/依赖和结构冲突的影响大小
• 准确性取决于模拟和是否有对应CPU模型。
• 暂时不支持有序后端。

1
2
3
4
5
6
7
8
9

Cycles with backend pressure increase [ 91.52% ]
Throughput Bottlenecks:
  Resource Pressure       [ 0.01% ]
  - SBPort0  [ 0.01% ]
  - SBPort1  [ 0.01% ]
  - SBPort5  [ 0.01% ]
  Data Dependencies:      [ 91.51% ]
  - Register Dependencies [ 91.51% ]
  - Memory Dependencies   [ 10.76% ]

• 端口信息来自TableGen llvm/lib/Target/X86/X86SchedSandyBridge.td
• 鲲鹏920的来自 llvm/lib/Target/AArch64/AArch64SchedTSV110.td

额外信息

1. Dynamic Dispatch Stall Cycles
2. Dispatch Logic
   1. 可以看出流水线发射满带宽或几条指令的时间占比
3. Schedulers
   1. 每个周期微指令发射数占比
4. Scheduler’s queue usage

   1. 执行时使用的平均或最大buffer entries (i.e., scheduler queue entries)

   2. AMD Jaguar

   3.   JALU01 - A scheduler for ALU instructions.
        JFPU01 - A scheduler floating point operations.
        JLSAGU - A scheduler for address generation.
        
      1
      2
      3
      4
      5
      6
      7
      8
      9
      10
      11
      12
      13
      14
      15
      16
      17
      18
      19
      20
      21
      22
      23
      24
      25
      26
      27
      28
      29
      30
      31
      32
      33
      34
      35
      36
      37
      38
      39
      40
      41
      42
      43
      44
      45
      46
      47
      48
      49
      50
      51
      52
      53
      54
      55
      56
      57
      58
      59
      60
      61
      62
      63
      64
      65
      66
      67
      68
      69
      70
      71
      72
      73
      74
      75
      76
      77
      78
      79
      80
      81
      82
      83
      84
      85
      86
      87
      88
      89
      90
      91
      92
      93
      94
      95
      96
      97
      98
      99
      100
      101
      102
      103
      104
      105
      106
      107
      108
      109
      110
      111
      112
      113
      114
      115
      116
      117
      
      5. Retire Control Unit
         1. 在一个周期里有多少指令retired的占比(好吧，感觉有语病)
      6. A re-order buffer (ROB) 的使用情况
      7. Register File statistics
         1. physical register file (PRF)
         2. floating-point registers (JFpuPRF)
         3. integer registers (JIntegerPRF)
      
      ## Instruction Flow
      
      llvm-mca 假设指令在模拟开始之前已经全部解码并放入队列中。因此，指令提取和解码阶段没有被计算。未考虑前端的性能瓶颈。此外，llvm-mca 不模拟分支预测。
      
      ### Instruction Dispatch
      
      处理器的默认 dispatch width值等于LLVM’s scheduling model里的IssueWidth值。
      
      An instruction can be dispatched if:
      
      * The size of the **dispatch group** is smaller than processor’s dispatch width.
      * There are enough entries in the **reorder buffer**.
      * There are enough **physical registers** to do register renaming.
      * The schedulers are **not full**.
      
      reorder buffer负责跟踪命令，使之按照程序顺序retired结束。其默认值为 MicroOpBufferSize 。
      
      各种Buffered resources 被视作scheduler resources.
      
      ### Instruction Issue
      
      每个处理器调度器实现一个指令缓冲区。指令必须在调度程序的缓冲区中等待，直到输入寄存器操作数可用。只有在那个时候，指令才符合执行的条件，并且可能会被发出（可能是乱序的）以供执行。 llvm-mca 在调度模型的帮助下计算指令延迟。
      
      llvm-mca 的调度器旨在模拟多处理器调度器。调度器负责跟踪数据依赖关系，并动态选择指令消耗哪些处理器资源。它将处理器资源单元和资源组的管理委托给资源管​​理器。资源管理器负责选择指令消耗的资源单元。例如，如果一条指令消耗了一个资源组的1cy，则资源管理器从该组中选择一个可用单元；默认情况下，资源管理器使用循环选择器来保证资源使用在组的所有单元之间均匀分配。
      
      llvm-mca’s scheduler internally groups instructions into three sets:
      
      * WaitSet: a set of instructions whose operands are not ready.
      * ReadySet: a set of instructions ready to execute.
      * IssuedSet: a set of instructions executing.
      
      ### Write-Back and Retire Stage
      
       retire control unit
      
      1. When instructions are executed,the flags the instruction as “ready to retire.”
      2. Instructions are retired in program order
      3. free the physical registers
      
      ### Load/Store Unit and Memory Consistency Model
      
      load/store unit (LSUnit)用来模拟乱序memory操作
      
      The rules are:
      
      1. A younger load is allowed to pass an older load only if there are no intervening stores or barriers between the two loads.
      2. A younger load is allowed to pass an older store provided that the load does not alias with the store.
      3. A younger store is not allowed to pass an older store.不能交换顺序的意思
      4. A younger store is not allowed to pass an older load.
      
      假设 loads do not alias (-noalias=true) store operations.Under this assumption, younger loads are always allowed to pass older stores. ???
      
      LSUnit不打算跑alias analysis来预测何时load与store不相互alias???
      
      in the case of write-combining memory, rule 3 could be relaxed to allow reordering of non-aliasing store operations.???
      
      LSUnit不管的其余三点：
      
      1. The LSUnit does not know when store-to-load forwarding may occur.
      2. The LSUnit does not know anything about cache hierarchy and memory types.
      3. The LSUnit does not know how to identify serializing operations and memory fences.
      4. The LSUnit does not attempt to predict if a load or store hits or misses the L1 cache(不考虑cache命中，默认是命中L1,产生the load-to-use latency的最乐观开销)
      
      llvm-mca 不知道序列化操作或内存屏障之类的指令。 LSUnit 保守地假设同时具有“MayLoad”和未建模副作用的指令的行为类似于“软”load-barrier。这意味着，它在不强制刷新load队列的情况下序列化加载。类似地，“MayStore”和具有未建模副作用的指令被视为store障碍。完整的memory-barrier是具有未建模副作用的“MayLoad”和“MayStore”指令。LLVM的实现是不准确的，但这是我们目前使用 LLVM 中可用的当前信息所能做的最好的事情。
      
      load/store barrier会占用在load/store 队列里占用一项。
      当load/store barrier是其队列里oldest项时，其会被执行
      
      ![](https://pic.shaojiemike.top/img/440472FD7AB14BC3C1F29BD2D565ACDF.png)
      
      ### In-order Issue and Execute
      
      有序处理器被建模为单个 InOrderIssueStage 阶段。它绕过 Dispatch、Scheduler 和 Load/Store 单元。一旦它们的操作数寄存器可用并且满足资源要求，就会发出指令。根据LLVM的调度模型中IssueWidth参数的值，可以在一个周期内发出多条指令。一旦发出，指令就会被移到 IssuedInst 集，直到它准备好retire。 llvm-mca 确保按顺序提交写入。但是，如果 RetireOOO 属性for at least one of its writes为真，则允许指令提交写入并无序retire???
      
      ## Custom Behaviour 自定义行为
      
      某些指令在该模型中并不能被准确的模拟。为了几条指令而修改模型不是个好的选择，一般通过**CustomBehaviour**类对某些指令进行特殊建模：自定义数据依赖，以及规避、单独处理特殊情况。
      
      为此，llvm-mca设置了一个通用的以及多个特殊的**CustomBehaviour**类。下面两种情况下会使用通用类：
      
      1. 开启了`-disable-cb`选项
      2. 不存在针对某目标的特殊类(通用类也做不了什么，我什么也做不到😥)
      
      但是注意目前只有in-order流水线实现了**CustomBehaviour**类，out-order流水线将来也会支持。
      
      该类主要通过`checkCustomHazard()`函数来实现，通过当前指令和真正流水线中执行的指令，来判断当前指令需要等待几个周期才能发射。
      
      如果想对没有实现的目标添加**CustomBehaviour**类，可以参考已有的实现，比如在`/llvm/lib/Target/AMDGPU/MCA/`目录下。
      
      ## Custom Views 自定义视图
      
      关于自定义的视图的添加路径，如果**没有输出**从未在MC layer classes (MCSubtargetInfo, MCInstrInfo, etc.)里出现过的**新后端值**，请把实现加入`/tools/llvm-mca/View/`。相反，请加入`/lib/Target/<TargetName>/MCA/`目录。
      
      关于Custom Views所需内容，需要写特殊的**CustomBehaviour**类来覆写`CustomBehaviour::getViews()`函数，根据位置的不同还有三种实现`getStartViews(), getPostInstrInfoViews(),getEndViews()`。
      
      ## 影响准确性的因素
      
      调度模型不仅用于计算指令延迟和吞吐量，还用于了解可用的处理器资源以及如何模拟它们。
      
      llvm mca进行分析的质量不可避免地受到**llvm中调度模型质量**的影响。
      
      ## 功能（能估计的值
      
      1. IPC
      2. 硬件资源压力resource-pressure
      3. 一些额外Info？
         1.
      
      
       register-file-stats
       -dispatch-stats
       -scheduler-stats
       -retire-stats
       -instruction-info
       instruction-tables
       
      1
      2
      3
      4
      5
      6
      7
      
      4. 吞吐量瓶颈？
      
      ### 支持对特定代码块的分析
      
      1. 汇编代码，支持命名和嵌套
      
      
      

   LLVM-MCA-BEGIN block-name

   add %eax, %eax

   LLVM-MCA-END

   1 2 3

   2. 高级语言，通过内联汇编实现

   int foo(int a, int b) {
   __asm volatile(“# LLVM-MCA-BEGIN foo”);
   a += 42;
   __asm volatile(“# LLVM-MCA-END”);
   a *= b;
   return a;
   }

   
   但是，这会干扰循环矢量化等优化，并可能对生成的代码产生影响。具体影响请对比汇编代码。
   

相关论文

Google学术搜llvm-mca，一堆论文。但是不急着看，因为没有预备知识，没有问题的去看论文。效率和收获很低的，而且会看不懂。

相关项目

mc-ruler

mc-ruler是整合了llvm-mca的cmake,可以打印指定部分的代码分析信息。如果之后要测试可能用得上。

需要进一步的研究学习

1. 具体功能
2. llvm如何实现的，要看代码。

遇到的问题

1. (llvm-mca detects Intel syntax by the presence of an .intel_syntax directive at the beginning of the input. By default its output syntax matches that of its input.)
2. ？？？的地方
3. 大概看了一下功能，但是性能怎么对比呢。准确值是多少呢？
   1. arm kunpeng pmu-tools 实现
4. 每次的估计值会波动吗？

如何和大神交流呢+提问的艺术

开题缘由、总结、反思、吐槽~~

参考文献

llvm 后端 概述

• 后端（backend）由一套分析和转换Pass组成，它们的任务是代码生成，即将LLVM中间表示（IR）变换为目标代码（或者汇编）。
• LLVM支持广泛的目标：ARM，AArch64，Hexagon，MSP430，MIPS，Nvidia PTX，PowerPC，R600，SPARC，SystemZ，X86，和XCore。
• 所有这些后端共享一套共用的接口，它是目标无关代码生成器的一部分，以通用API的方法抽象化后端任务。每个目标必须特殊化代码生成通用类，以实现目标特定的行为。

后端的基本流程

• 下图给出了将LLVM IR转换为目标汇编代码必需的步骤

• 浅灰色的中间框，也叫super pass，是必需的，它们是后端的核心部分。
• 白色框所指示的，可以执行非必需的优化Pass以进一步改进翻译的质量。对于提高所生成的代码的效率更重要。
  • 比如-O3的优化，而且其顺序对结果也有影响。

详细解释各阶段：

1. 指令选择（Instruction Selection）：将三地址结构的LLVM IR变换为DAG（Directed Acyclic Graph）
   • 每个DAG能够表示单一基本块的计算。DAG内节点表示机器指令，边表示数据依赖关系。
2. 第1次指令调度（Instruction Scheduling），也称为前寄存器分配（RA）调度，对指令排序，同时尝试发现尽可能多的指令层次的并行。然后这些指令被变换为MachineInstr三地址表示。
3. 寄存器分配（Register Allocation），它将无限的虚拟寄存器的引用转换为有限的目标特定的寄存器集，寄存器不够时挤出（spill）到内存。
4. 第2次指令调度，也称为后寄存器分配（RA）调度。因为此时在这个点可获得真实的寄存器信息，某些类型寄存器存在额外的风险和延迟，它们可被用以改进指令顺序。
5. 代码输出（Code Emission）阶段将指令从MachineInstr表示变换为MCInst实例。这种新的表示更适合汇编器和链接器，它有两种选择：输出汇编代码或者输出二进制块（blob）到一种特定的目标代码格式。

后端代码结构

后端的实现分散在LLVM源代码树的不同目录中。代码生成背后的主要程序库位于lib目录和它的子文件夹CodeGen、MC、TableGen、和Target中， 具体参考文档

Tablegen位置在类似 llvm/lib/Target/X86/X86.td的地方

llvm 编译优化

• 通过llvm的分析和转换Pass相结合实现的。
• 首先，通过分析Pass获取程序的一些特性和数据流等信息，例如控制流分析、数据流分析、依赖分析等。
• 然后，根据所得到的分析信息，llvm会执行转换Pass，对程序进行一系列的重构、优化和变换，例如常量传播、死代码消除、内联函数、循环展开等。

举例：O3优化实现

程序优化选项 -O3 是通过启用 LLVM Pass Manager 并按照顺序执行包含多个具体优化 Pass 的过程实现的。包括：

1. 函数内部优化 Pass，如内联、函数内联、无用函数清理、控制流扁平化；
2. 函数间优化 Pass，如基于静态单走边分析的间接调用目标推导、函数每次调用的参数的重复计算消除、通过符号解析执行的函数简介化等。
3. 模块优化 Pass，如死代码消除、全局优化、常量传播、数值宽化和窄化、整除优化等；
4. 特定于架构的优化 Pass，包括指令调度和寄存器分配等。

这些 Pass 的执行范围涵盖 LLVM IR 与 LLVM 后端。

TableGen

• LLVM的TableGen是一种表格驱动代码生成工具，主要用于生成汇编器、反汇编器、指令选择器、调度器等代码。
• 它使用基于LLVM IR的DSL(Domain-Specific Language)来描述目标指令集的特性和规则，然后将这些信息转换为C++代码。
• 使用TableGen可以将目标指令集的实现与源代码分离，从而提高代码的可读性和可维护性。

TableGen的输入文件使用扩展名“.td”（TableGen的缩写），它们可以描述如下内容：

1. Instruction Set Architecture (ISA) - 描述目标机的指令集特性，例如指令集架构、寄存器、寄存器类、操作数类型、地址模型、端对齐性等。
2. Selection DAG - 描述了如何将LLVM IR节点映射到目标机指令集的指令，例如指令的操作码、操作数、调用约定、指令延迟等。
3. Pattern Matching - 对匹配到的指令模板做出生成想要的IR节点的选择。
4. Instruction Scheduling - 描述调度器行为、指令之间的时间关系，以及如何将指令插入到调度图中的规则等。

• TableGen自动化了目标机指令集的大部分工作，同时也使得自定义目标机变得相对容易。
• 该工具支持针对多种平台和编译器的后端代码生成。
• 对于嵌入式系统和非标准指令集架构等领域，TableGen有着广泛的应用。

相关的概念

• 目标描述语言（Target Description Language，TDL）来定义目标架构特定的指令和寄存器。其中，TDL可用于目标架构中指令定义和寄存器定义的映射关系和动态生成机器指令的规则。

实践：llvm IR 后端

实现一个简单的LLVM IR后端，将LLVM IR转换为x86汇编代码，能line by line的输出。

参考LLVM官方文档中的“Writing an LLVM Backend”以及“TableGen Backends”

需要进一步的研究学习

暂无

遇到的问题

暂无

开题缘由、总结、反思、吐槽~~

参考文献

https://getting-started-with-llvm-core-libraries-zh-cn.readthedocs.io/zh_CN/latest/ch06.html#id2

简介

• Pass就是“遍历一遍IR，可以同时对它做一些操作”的意思。翻译成中文应该叫“传递”。
• 在实现上，LLVM的核心库中会给你一些 Pass类 去继承。你需要实现它的一些方法。
  • ModulePass , CallGraphSCCPass, FunctionPass , or LoopPass, or RegionPass
• 最后使用LLVM的编译器会把它翻译得到的IR传入Pass里，给你遍历和修改。

作用

1. 插桩： 在Pass遍历LLVM IR的同时，自然就可以往里面插入新的代码。
2. 机器无关的代码优化：编译原理一课说：IR在被翻译成机器码前会做一些机器无关的优化。 但是不同的优化方法之间需要解耦，所以自然要各自遍历一遍IR，实现成了一个个LLVM Pass。 最终，基于LLVM的编译器会在前端生成LLVM IR后调用一些LLVM Pass做机器无关优化， 然后再调用LLVM后端生成目标平台代码。
3. 静态分析： 像VSCode的C/C++插件就会用LLVM Pass来分析代码，提示可能的错误 (无用的变量、无法到达的代码等等)。

理解 llvm Pass

理解Pass API

　　Pass类是实现优化的主要资源。然而，我们从不直接使用它，而是通过清楚的子类使用它。当实现一个Pass时，你应该选择适合你的Pass的最佳粒度，适合此粒度的最佳子类，例如基于函数、模块、循环、强联通区域，等等。常见的这些子类如下：

• ModulePass：这是最通用的Pass；它一次分析整个模块，函数的次序不确定。它不限定使用者的行为，允许删除函数和其它修改。为了使用它，你需要写一个类继承ModulePass，并重载runOnModule()方法。
• FunctionPass：这个子类允许一次处理一个函数，处理函数的次序不确定。这是应用最多的Pass类型。它禁止修改外部函数、删除函数、删除全局变量。为了使用它，需要写一个它的子类，重载runOnFunction()方法。
• BasicBlockPass：这个类的粒度是基本块。FunctionPass类禁止的修改在这里也是禁止的。它还禁止修改或者删除外部基本块。使用者需要写一个类继承BasicBlockPass，并重载它的runOnBasicBlock()方法。

　　被重载的入口函数runOnModule()、runOnFunction()、runOnBasicBlock()返回布尔值false，如果被分析的单元（模块、函数和基本块）保持不变，否则返回布尔值true。

Pass的执行顺序/依赖

• ChatGPT说默认顺序是：FunctionPass -> Module Pass -> LoopPass ?
• 当然我们是可以修改插入Pass的执行顺序的。

1
2
3
4
5
6
7
8
9
10
11
12
13
14

char PIMProf::AnnotationInjection::ID = 0;
// 注册 llvm pass
static RegisterPass<PIMProf::AnnotationInjection> RegisterMyPass(
    "AnnotationInjection", "Inject annotators to uniquely identify each basic block.");

static void loadPass(const PassManagerBuilder &,
                           legacy::PassManagerBase &PM) {
    PM.add(new PIMProf::AnnotationInjection());
}

// Ox 的代码 llvm pass 在EP_OptimizerLast 位置load
static RegisterStandardPasses clangtoolLoader_Ox(PassManagerBuilder::EP_OptimizerLast, loadPass);
// O0 的代码 llvm pass EP_EnabledOnOptLevel0 位置load
static RegisterStandardPasses clangtoolLoader_O0(PassManagerBuilder::EP_EnabledOnOptLevel0, loadPass);

流程

1. 编写LLVM pass代码
2. 配置编译环境(cmake or make)
3. 运行(opt or clang)

1 代码框架

最简单框架hello.cpp如下，注意Important一定需要：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32

#include "llvm/Pass.h"
#include "llvm/IR/Function.h"
#include "llvm/Support/raw_ostream.h"
#include "llvm/IR/LegacyPassManager.h"
#include "llvm/Transforms/IPO/PassManagerBuilder.h"

using namespace llvm;

namespace {
 // Important
  struct Hello : public FunctionPass {
    static char ID;
    Hello() : FunctionPass(ID) {}
 // Important
    bool runOnFunction(Function &F) override {
      errs() << "Hello: ";
      errs().write_escaped(F.getName()) << '\n';
      return false;
    }
  };
}

char Hello::ID = 0;

// Important:Register for opt
static RegisterPass<Hello> X("hello", "Hello World Pass");

// Important:Register for clang
static RegisterStandardPasses Y(PassManagerBuilder::EP_EarlyAsPossible,
  [](const PassManagerBuilder &Builder, legacy::PassManagerBase &PM) {
    PM.add(new Hello());
  });

2 编译动态库

使用cmake

参考官方文档。

An example of a project layout is provided below.

1
2
3
4
5
6
7
8

<project dir>/
    |
    CMakeLists.txt
    <pass name>/
        |
        CMakeLists.txt
        Pass.cpp
        ...

Contents of <project dir>/CMakeLists.txt:

1
2
3
4
5
6
7

find_package(LLVM REQUIRED CONFIG)

separate_arguments(LLVM_DEFINITIONS_LIST NATIVE_COMMAND ${LLVM_DEFINITIONS})
add_definitions(${LLVM_DEFINITIONS_LIST})
include_directories(${LLVM_INCLUDE_DIRS})

add_subdirectory(<pass name>)

Contents of <project dir>/<pass name>/CMakeLists.txt:

1

add_library(LLVMPassname MODULE Pass.cpp)

运行cmake编译。产生LLVMPassname.so文件

1
2

mkdir build && cd build
cmake .. && make

使用命令行

请阅读知乎的文章

3 使用

opt加载Pass

1
2

clang -c -emit-llvm main.c -o main.bc # 随意写一个C代码并编译到bc格式
opt -load path/to/LLVMHello.so -hello main.bc -o /dev/null

把源代码编译成IR代码，然后用opt运行Pass实在麻烦且无趣。

clang加载Pass

1
2
3

clang -Xclang -load -Xclang path/to/LLVMHello.so main.c -o main
# or
clang++ -Xclang -load -Xclang ./build/hello/libLLVMPassname.so test.cpp -o main

实践

插入代码

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26

void InjectSimMagic2(Module &M, Instruction *insertPt, uint64_t arg0, uint64_t arg1, uint64_t arg2)
{
    LLVMContext &ctx = M.getContext();
    std::vector<Type *> argtype {
        Type::getInt64Ty(ctx), Type::getInt64Ty(ctx), Type::getInt64Ty(ctx)
    };
    FunctionType *ty = FunctionType::get(
        Type::getVoidTy(ctx), argtype, false
    );
    // template of Sniper's SimMagic0
    InlineAsm *ia = InlineAsm::get(
        ty,
        "\tmov $0, %rax \n"
        "\tmov $1, %rbx \n"
        "\tmov $2, %rcx \n"
        "\txchg %bx, %bx\n",
        "imr,imr,imr,~{rax},~{rbx},~{rcx},~{dirflag},~{fpsr},~{flags}",
        true
    );
    Value *val0 = ConstantInt::get(IntegerType::get(ctx, 64), arg0);
    Value *val1 = ConstantInt::get(IntegerType::get(ctx, 64), arg1);
    Value *val2 = ConstantInt::get(IntegerType::get(ctx, 64), arg2);
    std::vector<Value *> arglist {val0, val1, val2};
    CallInst::Create(
            ia, arglist, "", insertPt);
}

这段代码使用内联汇编嵌入到 LLVM IR 中，指令如下：

1
2
3
4

mov $0, %rax
mov $1, %rbx
mov $2, %rcx
xchg %bx, %bx

其中：

• mov $0, %rax 将立即数 arg0 装载到通用寄存器 %rax 中。
• mov $1, %rbx 将立即数 arg1 装载到通用寄存器 %rbx 中。
• mov $2, %rcx 将立即数 arg2 装载到通用寄存器 %rcx 中。
• xchg %bx, %bx 是一条无操作指令，用于保证该汇编代码的原子性。

打印每个BBL内的汇编指令

由于直接打印的是llvm IR的表示，想要打印特定架构比如x86的汇编代码，其实需要进行llvm后端的转换。（取巧，可执行文件反汇编，然后根据插入的汇编桩划分）

1

需要进一步的研究学习

暂无

遇到的问题

暂无

开题缘由、总结、反思、吐槽~~

复现PIMProf论文时，用到了使用 llvm pass来插入特殊汇编

参考文献

https://www.llvm.org/docs/WritingAnLLVMPass.html

https://zhuanlan.zhihu.com/p/122522485

GNU汇编语法

伪指令

• 指示（Directives）: 以点号开始，用来指示对编译器，连接器，调试器有用的结构信息。指示本身不是汇编指令。

• 语法：.type name , description
  • description取值如下：
    • %function 表示该符号用来表示一个函数名
    • %object 表示该符号用来表示一个数据对象

至于其它的指示你可以忽略。

实践：阅读汇编文件

从最简单的C文件入手

1
2
3

int main(){
 return 0;
}

运行gcc -S -O3 main.c -o main.s，得到main.s文件

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33

 .file "simple.cpp"
 .text
 .section .text.startup,"ax",@progbits
 .p2align 4
 .globl main
 .type main, @function
main:
.LFB0:
 .cfi_startproc
 endbr64
 xorl %eax, %eax
 ret
 .cfi_endproc
.LFE0:
 .size main, .-main
 .ident "GCC: (Ubuntu 9.4.0-1ubuntu1~20.04.1) 9.4.0"
 .section .note.GNU-stack,"",@progbits
 .section .note.gnu.property,"a"
 .align 8
 .long  1f - 0f
 .long  4f - 1f
 .long  5
0:
 .string  "GNU"
1:
 .align 8
 .long  0xc0000002
 .long  3f - 2f
2:
 .long  0x3
3:
 .align 8
4:

• 下面回答来自ChatGPT-3.5，暂时没有校验其可靠性(看上去貌似说得通)。

section

• .section .rodata.str1.1,"aMS",@progbits,1
  • rodata.str1.1是一个标号（label）, 意思是只读数据段的字符串常量
  • aMS是一个属性值：
    • 可分配的（allocatable），即程序运行时需要动态分配空间才能分配该代码段，
    • 不可执行 （M），
    • 数据的类型为串（S）
    • 其余属性值：对齐方式的通常为 b（byte对齐），w（word对齐），或者其他更大的对齐单位，例如 d（double word对齐）。
  • @progbits: 表示该段的类型是程序数据段（PROGBITS），这种类型的段包含程序的代码和数据。
  • 1: 表示该段的对齐方式是2^1 = 2个字节（按字节对齐）。如果不写这个数字，默认对齐到当前机器的字长。
• .section .text.startup,"ax",@progbits 其中ax表示该段是可分配的（allocatable）和可执行的（executable）。
• “.section .note.GNU-stack“指令用于告诉链接器是否允许在堆栈上执行代码。
• “.section .note.gnu.property“指令用于指定一些属性，这里是一个GNU特性标记。

汇编的入口

• 汇编的执行流程：入口函数在哪里
• 入口函数在该文件中的名称为“main”，定义于“.text.startup” section，其首地址为“.globl main”。

1
2
3
4

.section .text.startup,"ax",@progbits
.p2align 4
.globl main
.type main, @function

构造函数

• 为了确保这些初始化操作可以在程序启动时正确执行，编译器将把这些构造函数和析构函数的调用代码打包成若干个函数，统一放在名字为“_GLOBAL__sub_I_xxx”的section中。
  • 因为在C++程序编译后的二进制文件中，全局变量、静态变量和全局对象等信息都需要进行初始化操作，包括构造函数（初始化对象）和析构函数（清理对象）。
  • 在这段汇编代码中，也就是那个”_GLOBAL__sub_I_main”函数，它是C++全局变量和静态变量的构造函数，它调用了预初始化函数 “ios_base::Init()“，并注册了一个在程序退出时调用的析构函数 “__cxa_atexit“。
• 在”.init_array“ section中，定义了一个”_GLOBAL__sub_I_main”的地址，这是在程序启动时需要调用的所有C++全局和静态对象的初始化函数列表，编译器链接这个列表并在程序启动时依次调用这些初始化函数。
• 总之，这两个section的存在是为了保证C++全局变量和静态变量的正确初始化。

其中四条指令都定义了一些符号或变量，并分配了一些内存空间，这些在程序里的意义如下：

1. “.quad _GLOBAL__sub_I_main“:

在程序启动时，将调用所有全局静态对象的构造函数。这些构造函数被放在一个名为”_GLOBAL__sub_I_xxx”的section中，而每个section都是由一个指向该section所有对象的地址列表所引用。这里的”.quad _GLOBAL__sub_I_main”是为了将”_GLOBAL__sub_I_main”函数的地址添加到该列表中。

2. “.local _ZStL8__ioinit“:

这条指令定义了一个本地符号”_ZStL8__ioinit”，它表示C++标准输入输出的初始化过程。由于该符号是一个本地符号，所以只能在编辑该文件的当前单元中使用该符号。

3. “.comm _ZStL8__ioinit,1,1“:

这条指令定义了一个名为”_ZStL8__ioinit”的未初始化的弱符号，并为该符号分配了1个大小的字节空间。这个弱符号定义了一个C++标准输入输出部分的全局状态对象。在全用动态库时，不同的动态库可能有自己的IO状态，所以为了确保C++输入输出的状态正确，需要为其指定一个单独的段来存储这些状态数据。在这里，”.comm _ZStL8__ioinit,1,1”将会为”_ZStL8__ioinit”符号分配一个字节大小的空间。

4. “.hidden __dso_handle“:

这条指令定义了一个隐藏的符号 “__dso_handle”。这个符号是一个链接器生成的隐式变量，其定义了一个指向被当前动态库使用的全局数据对象的一个指针。该符号在被链接进来的库中是隐藏的，不会被其他库或者main函数本身调用，但是在main返回后，可以用来检查库是否已经被卸载。

末尾的元数据

这段代码是一些特殊的指令和数据，主要是用于向可执行文件添加一些元数据（metadata）。这些元数据可能包含各种信息，如调试信息、特定平台的指令集支持等等。

具体来说：

• “.long”指令用于定义一个长整型数值，这里用来计算地址之间的差值。
  • 例如，第一行”.long 1f - 0f“建立了一个长整型数值，表示”1:”标签相对于当前指令地址（即0f）的偏移量。偏移量可以用来计算标签对应的指令地址，从而可用于跳转或计算指针偏移量。
  • “4f - 1f“，即”4:”标签相对于”1:”标签的偏移量；
• “.long 0xc0000002“表示这是一个特殊的属性标记，标识这个文件可以在Linux平台上执行。它是用来告诉操作系统这个程序是用特定指令集编译的。
• “.long 0x3“表示另一个属性标记，表示这个文件可以加载到任意地址。

总之，这些元数据可能对程序运行起到关键作用，但在大多数情况下可能都没有明显的作用，因此看起来没有用。

比较汇编的debugging symbols

执行gcc -S -g testBigExe.cpp -o testDebug.s，对比之前的汇编文件，由72行变成9760行。

.loc

1
2
3
4

.LBE32:
 .file 3 "/usr/include/c++/9/bits/char_traits.h"
 .loc 3 342 2 is_stmt 1 view .LVU4
 .loc 1 5 11 is_stmt 0 view .LVU5

• 第一行：.loc 3 342 2 表示当前指令对应的源代码文件ID为3，在第342行，第2列（其中第1列是行号，第2列是第几个字符），同时is_stmt为1表示这条指令是语句的起始位置。
• 第二行：.loc 1 5 11 表示当前指令对应的源代码文件ID为1，在第5行，第11列，同时is_stmt为0表示这条指令不是语句的起始位置。
• view .LVU4 表示当前指令所处的作用域（scope）是.LVU4。作用域是指该指令所在的函数、代码块等一段范围内的所有变量和对象的可见性。在这个例子中，.LVU4 是一个局部变量作用域，因为它是位于一个C++标准库头文件中的一个函数的起始位置。

debug section

新增的这些 section 存储了 DWARF 调试信息。DWARF（Debugging With Attributed Record Formats）是一种调试信息的标准格式，包括代码中的变量、类型、函数、源文件的映射关系，以及代码的编译相关信息等等。

具体来说，这些 section 存储的内容如下：

• .debug_info：包含程序的调试信息，包括编译单元、类型信息、函数和变量信息等。
• .debug_abbrev：包含了 .debug_info 中使用到的所有缩写名称及其对应的含义，用于压缩格式和提高效率。
• .debug_loc：存储每个程序变量或表达式的地址范围及其地址寄存器、表达式规则等信息。在调试时用来确定变量或表达式的值和范围。
• .debug_aranges：存储简化版本的地址范围描述，允许调试器加速地定位代码和数据的位置。
• .debug_ranges：存储每个编译单元（CU）的地址范围，每个范围都是一个有限开区间。
• .debug_line：存储源代码行号信息，包括每行的文件、行号、是否为语句起始位置等信息。
• .debug_str：包含了所有字符串，如文件名、函数名等，由于每个调试信息的数据都是字符串，因此这是所有调试信息的基础。

需要注意的是，这些 section 中的信息是根据编译器的配置和选项生成的，因此不同编译器可能会生成略有不同的调试信息。

需要进一步的研究学习

• 在编译的过程中，哪个阶段 label会变成真实执行地址

遇到的问题

暂无

开题缘由、总结、反思、吐槽~~

参考文献

https://www.cnblogs.com/zuofaqi/articles/12853734.html

https://www.cnblogs.com/zuofaqi/articles/12853734.html

常见的web服务器

常见的web服务器有Apache、nginx、IIS

1. Apache
   1. Apache音译为阿帕奇, 是全世界最受欢迎的web服务器，因其快速、可靠并且可通过简单的API扩充，能将Python\Perl等解释器部署在其上面等优势，受到广泛的关注与使用。
   2. 但是现在用的人少了，而且性能没nginx好
2. nginx
   1. Apache的致命缺陷就是在同时处理大量的（一万个以上）请求时，显得有些吃力，所以“战斗民族”的人设计的一款轻量级的web服务器——nginx, 在高并发下nginx 能保持比Apache低资源低消耗高性能 ，
3. IIS
   1. iis是Internet Information Services的缩写，意为互联网信息服务，是由微软公司提供的基于运行Microsoft Windows的互联网基本服务,

合法使用

虽然 Ryujinx 模拟器项目本身是开源免费且合法的，但它默认情况下并不能直接运行市面上发行的各种商业游戏，因为它并不包含 Switch 系统固件，也没有游戏 ROM。

而按照国外的法规，如果你用户购买了主机和游戏，将其内容 DUMP (提取) 出来自己使用是合法的。

所以，无论是 Ryujinx 还是 Yuzu 等模拟器，想要开玩都需要先完成

• 安装系统固件和
• prod.keys 密钥等步骤。
  • 如果游戏要求最新的key和firmware你需要去更新

基本流程

1. 下载 Ryujinx 模拟器主程序
2. 下载 prod.keys 密钥文件以及 Switch 的系统固件 (Firmware)
3. 自行网上搜索下载你喜欢的任天堂游戏文件，支持 .NSP 或者 .XCI 格式

密钥文件以及 Switch 的系统固件

• 通过decode 知道 网站中编码的下载地址
  • 为key

Ryujinx (龙神)模拟器

率先支持了ARM和苹果 M 系列芯片

简易步骤教程：

1. 下载模拟器对应github
2. 将 Ryujinx 模拟器主程序解压到「不包含中文的路径」下。
3. 首次启动 Ryujinx 模拟器后，会提示找不到 key 文件的错误
   1. 点击菜单 文件 (File) → 打开 Ryujinx 文件夹 (Open Ryujinx Folder)，会弹出模拟器数据所在的目录。
   2. 将 prod.keys 文件放进到 Ryujinx 目录中的 system 文件夹里，重启模拟器
4. 放置好 keys 文件之后就开始安装固件 (Firmware) 了，
   1. 点击菜单 工具 (Tools)→安装固件 (Install Firmware)→从 XCI 或 ZIP 安装固件 (Install a firmware from XCI or ZIP)，选择你下载到的 Firmware 压缩包(不需解压)，
   2. 模拟器就会开始安装，直到显示安装完成即可。
5. 此时已经可以运行 Switch 游戏了，
   1. 点击菜单 选项 (Options) → 设置 (Settings)，在 用户界面 (General) → 游戏目录 (Game Directories) 下点击 添加 (Add) 来「添加一个游戏 ROM 文件存放目录」。
   2. 此后，模拟器会自动加载出存放在这些文件夹里的游戏列表。

安装nsp DLC文件

不是

而是

性能优化

YUZU(柚子)模拟器

yuzu，奶刃2好像都是用这个

密钥缺失

将你原来的User文件夹和ROM文件夹拖到新版模拟器文件夹的根目录即可。

将 prod.keys 文件放在Yuzu\user\keys

更新密钥和固件

• 下面两个目录的内容都可以删除，然后解压
• keys解压到Yuzu\user\keys
• 固件解压到Yuzu\user\nand\system\Contents\registered

YUZU模拟器使用教程

https://www.playdanji.com/yuzu

YUZU金手指

https://www.playdanji.com/yuzujinshouzhi

YUZU软件升级方法

Early Access版本是需要花钱订阅才能下载的。

github的release直接下载zip后解压替换即可。

YUZU存档位置

游戏右键，打开存档位置。

退出全屏

F11

YUZU 安装 nsp和xci文件

key和中文的问题，建议用之前好的文件

https://zhuanlan.zhihu.com/p/406048136

安装升级补丁nsp文件和DLC

导入NAND文件即可

异度之刃2

打包本体1

30帧720P

https://switch520.com/23050.html

推荐OpenGL模式

v模式，暗场景会过曝。

画质补丁

贴吧老哥的放入目录

1

E:\gamePojie\NaiRen2\A3285 v2.0.2_yuzuEA2077\user\sdmc\atmosphere\contents

但是没什么用。

ini配置原理是，如下图对应配置目录

放入如下修改的ini文件来修改画质

如下图成功

贴吧10楼：刚试了下，我把属性的mod选项关掉，然后把0100F3400332C000的画质mod删掉，效果一样有，所以效果应该只能在0100F3400332D001\画质mod\romfs\monolib\shader下的lib_nx.ini里改，其他的都没用

1
2
3
4
5
6
7
8
9
10
11
12

red_sclX=2.0
red_sclY=2.0
red_hdsclX=2.0
red_hdsclY=2.0


red_Auto=on
red_AtMaxX=2.0
red_AtMaxY=2.0
red_AtMinX=2.0
red_AtMinY=2.0
red_AtRate=100.0

2.0就是1440p，1.0就是原版720p。你们可以试试改其他的

帧数补丁

60帧补丁实际效果远没有60帧而且一堆副作用，不用浪费时间了

bug花屏

按照B站设置，主要改了GLSL

塞尔达-旷野之息

游侠论坛的cemu模拟的效果就不错

塞尔达-王国之泪

• yuzu 1414以上
• keys firmware 16.0.2以上

龙神模拟器，会经常闪退，暂时不知道解决办法(Cache PPTC rebuild?)。yuzu没有闪退的问题

需要进一步的研究学习

暂无

遇到的问题

暂无

开题缘由、总结、反思、吐槽~~

之前买了正版的switch，游戏也入了两三千。旷/荒野之息，奥德赛，奶刃2都通关了。可惜被妈妈没收了~

想研究一下，PC模拟，记录踩坑过程

参考文献

BT简述

BitTorrent (简称 BT) 协议是和点对点（point-to-point）的协议程序不同，它是用户群对用户群（peer-to-peer, 或简写为 P2P) 传输协议, 它被设计用来高效地分发文件 (尤其是对于大文件、多人同时下载时效率非常高)。该协议基于HTTP协议，属于TCP/IP应用层。

将文件划分成多块(默认256Kb一块)，每块可以从网络中不同的用户的BT客户端处并行下载。

1
2
3

BT 下载的文件都是别人上传给你的。
BT 下载速度均来自其他下载同一资源的用户上传速度。
上传的用户越多，你的下载速度越快，相反没用户上传你就没有下载速度。

比特彗星，包括其他 BT 软件（迅雷除外，迅雷不是会员会限速，高速通道下载提高的速度一部分就是接触限速后获得的）都不会限制下载速度。

BT分享规则

与迅雷不同，BT旨在“人人为我，我为人人”。用户和用户之间对等交换自己手中已有的资源。如果任何一方试图白嫖另外一方的资源，而自己不愿意上传自己的资源，那么那方就会被人视作吸血者而被踢出这个交换，下场是没有人会愿意和你交换数据，你的下载速度也就归零。

如果把上传速度限制为了10KB/s，10KB/s是BitComet上传最低限速，很大时候就这10KB会被包含DHT查询、向Tracker服务器注册，连接用户所产生的上传全部占满。在下载种子的时候，其他用户连上你是只能拿到1～2KB/s甚至一点都没有的。

现在的BT下载客户端都可以做到智能反吸血，所以基本想和交换数据的用户都把你当作Leecher（吸血鬼）Ban（封禁）处理了，故没有下载速度不足为奇。

一般来说，只要预留50KB/s的上传给其他网页浏览、聊天就可以了，在下载时应该尽量把上传留给那些和你交换资源的用户，这样才不会被他们视作你在吸血进而屏蔽你。

如果上传不足，就应该主动限制自己的下载速度，否则单位时间下载量远超过上传量反而会遭来更多的屏蔽，对下载速度提升更加不利。

BT基本流程

.torrent 种子文件本质上是文本文件，包含Tracker信息和文件信息两部分。Tracker信息主要是BT下载中需要用到的Tracker服务器的地址和针对Tracker服务器的设置。

1. 下载时，BT客户端首先解析种子文件得到Tracker地址，然后连接Tracker服务器。
2. Tracker服务器回应下载者的请求，提供下载者其他下载者（包括发布者）的IP。
3. 下载者再连接其他下载者，根据种子文件，两者分别告知对方自己已经有的块，然后交换对方所没有的数据。
   1. 此时不需要其他服务器参与，分散了单个线路上的数据流量，因此减轻了服务器负担。
4. 下载者每得到一个块，需要算出下载块的Hash验证码与种子文件中的对比，如果一样则说明块正确，不一样则需要重新下载这个块。这种规定是为了解决下载内容准确性的问题。

常规部署

• 安装qBittorrent-nox, tmux下运行，在8080端口挂载WebUI
• 安装qbittorrent, 用户运行qbittorrent, x11弹出应用窗口
  • 问题：
    • 怎么维持窗口？sudo XAUTHORITY=/home/qcjiang/.Xauthority qbittorrent
    • 关于写文件权限，如何写网络硬盘
    • node5 上传很快, 网络原因？种子原因？(不是，是因为网络硬盘，所以下载多少要占用多少上传)

docker部署

以qBit的docker为例，参考linuxsever的docker-compose如下：(qBit相对于Transmission有多线程IO的优势) 也可以使用其余docker镜像

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17

---
version: "2.1"
services:
  qbittorrent:
    image: lscr.io/linuxserver/qbittorrent:latest
    container_name: qbittorrent
    environment:
      - PUID=0 # 这里是root 如果想以其他用戶A修改文件，可以改成其他用户的UID。通過id A 查看
      - PGID=0
      - TZ=Etc/UTC
      - WEBUI_PORT=8080
    volumes:
      - /addDisk/DiskNo4/qBit:/config
      - /addDisk/DiskNo4/bt:/downloads

    network_mode: host
    restart: unless-stopped

默认账号 admin 默认密码 adminadmin
然后通过webUI http://222.195.72.218:8080/管理。

如果不想网络通过wireguard，而是本地可以如下设置

同一台机器实现两个账号做种

• 思路：两个docker，同一个网络出口
• 問題：
  • qBit要有权限写文件
  • 两个docker兼容性：
    • WebUI有bug，不一定会显示。重启刷新即可
    • 其次有一个docker会没有网络。
      • 这是由于端口随机错误导致的，会导致下面连接状态显示火焰。换端口刷新即可解决。
      • 
• 关于封号
  • 由于国内环境下载一般都是大内网。同一个网络出去应该没有问题。
  • 大多数做种是通过ipv6，会被检测出同一个机器多个账户做种，导致封号
  • 还有关于盒子刷上传，一方面通过速度，另一方面由于盒子的ip是固定的，所以会被检测出重复导致封号。

测速

1. 先用 https://www.speedtest.net 测速
   1. 
2. 考虑热门种子测试 http://releases.ubuntu.com/19.10/ubuntu-19.10-desktop-amd64.iso.torrent
   1. 
   2. 没通过代理能找到的用户变少，速度也变慢了。
3. 如果跑不到网络上限，可能和软件设置有关

上传速度

m站刷上传的时候，发现基本都是对方基本都是通过ipv6下载

uTP是一种基于UDP的协议，它可以根据网络拥塞情况自动调节传输速度，从而减少对其他网络应用的影响。

BT连接是一种基于TCP的协议，它可以保证数据的完整性和可靠性，但是可能会占用较多的网络带宽和资源。

在qBittorrent中，标志U K E P分别表示以下含义：

1
2
3
4

U：表示你正在上传数据给对方，或者对方正在从你那里下载数据。
K：表示对方支持uTP协议，即基于UDP的传输协议。
E：表示对方使用了加密连接，即通过加密算法保护数据的安全性。
P：表示对方使用了代理服务器或VPN服务，即通过第三方网络隐藏自己的真实IP地址。

PT设置

• 虽然说PT下载，客户端要关闭DHT,PeX, LSD。
• 但是其实种子是默认关闭的，无序额外设置，北洋和M站一样。
• 

基本概念

Tracker

收集下载者信息的服务器，并将此信息提供给其他下载者，使下载者们相互连接起来，传输数据。

种子

指一个下载任务中所有文件都被某下载者完整的下载，此时下载者成为一个种子。发布者本身发布的文件就是原始种子。

做种

发布者提供下载任务的全部内容的行为；下载者下载完成后继续提供给他人下载的行为。

分享率

上傳資料量 / 下傳資料量的比率,是一種BT的良心度,沒實際作用.(一般为了良心，至少大于1)

长期种子

BitComet的概念，相对于种子任务的上传能够控制。

长效种子就是你不开启任务做种，只要你启动了比特彗星，软件挂后台，当有其他用户也是用比特彗星下载你列表里的存在的文件时候就会被认为是长效种子 。

DHT

.DHT全称叫分布式哈希表(Distributed Hash Table)，是一种分布式存储方法。在不需要服务器的情况下，每个客户端负责一个小范围的路由，并负责存储一小部分数据，从而实现整个DHT网络的寻址和存储。新版BitComet允许同行连接DHT网络和Tracker，也就是说在完全不连上Tracker服务器的情况下，也可以很好的下载，因为它可以在DHT网络中寻找下载同一文件的其他用户。

类似Tracker的根据种子特征码返回种子信息的网络。

在BitComet中，无须作任何设置即可自动连接并使用DHT网络，完全不需要用户干预。

用户交换Pex

Peer Exchange (PEX)， 每个peer客户端的用户列表，可以互相交换通用。可以将其理解为“节点信息交换”。前面说到了 DHT 网络是没有中心服务器的，那么我们的客户端总不能满世界去喊：“我在下载这个文件，快来连我吧.”（很大声）。所以就通过各个 BT 客户端自带的节点去同步路由表实现 DHT 网络连接。

本地用户发现

LSD（LPD）就是本地网络资源，内网下载，没什么几把用的东西，可能学校等私有网络好使

ISP

網絡業務提供商(Internet Service Provider，簡稱ISP)，互聯網服務提供商，即向廣大用户綜合提供互聯網接入業務、信息業務、和增值業務的電信運營商。

反吸血机制

基本原理

1. 根据流量： 默认设置为120秒，持续对某个peer产生上传，并且从该peer用户获取的下载流量没有超过1KB文件（1024字节）大小，即拉黑该peer，预警颜色为黄色，合法为绿色，红色为封禁。
2. 可组合检测指定客户端进行反吸血，比如说指定屏蔽qbittorrent、utorrent等吸血客户端选择（可多选客户端，可对下载任务和做种任务生效）
3. 可组合检测客户端连接端口号进行反吸血，比如说指定屏蔽15000迅雷X版本客户端等吸血端口（可多选端口号，可对下载任务和做种任务生效）
4. 可组合检测客户端连接peer_id标志符进行反吸血屏蔽，例如屏蔽XL0018客户端等吸血标志符（可多选标志符，可对下载任务和做种任务生效）

高级设置

1
2
3
4
5

bittorrent.anti_leech_min_byte
设定反吸血保护流量：要求对方在指定时间（秒）内需要上传的最少流量（byte）， 取值范围：1-10000。

bittorrent.anti_leech_min_stable_sec
设定反吸血保护时间：指定与对方连接多长时间（秒）后开始检查流量（byte），取值范围：1-10000。

常见问题

需要软件开着吗？

需要

原文件改名或者移动，还会上传吗？

文件下载后不能移动，不能删除，不能重命名（但可以在软件内改）。 一但BT 软件找不到文件，或删除了任务，就无法做种上传了。

晚上避免上传

可以在Bitcomet高级设置里设置时段限速

对硬盘损害大吗？

分享上传也需要频繁读取硬盘。

以Bitcomet为例，该软件就是通过磁盘缓存技术减小频繁随机读写对硬盘的损伤。

磁盘缓存就是利用物理内存作为缓冲，将下载下的数据先存放于内存中，然后定期的一次性写入硬盘，以减少对硬盘的写入操作，很大的程度上降低了磁盘碎片。

因为通常我们设置内存（磁盘缓存）为每任务XX兆，意味着，这个缓冲区可以存放数兆甚至几十兆的“块”，基本上可以杜绝碎片了。

现在BT软件都是自动设置缓存的，它是根据你物理内存的大小分配的。

注意设置

1. 设置了“反吸血”，应对迅雷
2. 校园网设置9，不限制P2P
   1. 国内各省份不同运营商限速策略（QOS）

需要进一步的研究学习

路由器下载？

参考文献