试了下编译器优化, 准备好板凳:

```c
int main() {
int s = 0;
for (int i = 0; i <= 100; i++) {
s += i;
}
return s;
}
```

```sh
$ gcc -o main -O3 main.c
```

```sh
$ objdump -d main

00000000000004f0 <main>:
4f0: b8 ba 13 00 00 mov $0x13ba,%eax <----------- 0x13ba == 5050
4f5: c3 retq
4f6: 66 2e 0f 1f 84 00 00 nopw %cs:0x0(%rax,%rax,1)
4fd: 00 00 00
```

所以我觉得最好的答案是 return 5050, 因为你已经在写代码的时候就做了编译器优化...

看 c 代码经常能看到 "我知道我在做什么" 的注释然后强制跳过编译器语法检查的…

个人看来这些规范，范式可以拿来用，但不必当教条，适合自己的开发习惯就好。

正常 endian 的逻辑，一般直接强制内存类型转换会快很多

端午牛逼

毕竟如果不每半年改个版公司就会发现有些职位似乎可以不要...

现在还记得第一次编译 llvm 时花了 39 小时。。。目前的话折腾了个云服务器，编译工作就扔上去不会中断本机的工作

close 是一个系统调用, 它出错的情况只有:

```
ERRORS
The close() system call will fail if:
[EBADF] fildes is not a valid, active file descriptor.
[EINTR] Its execution was interrupted by a signal.
[EIO] A previously-uncommitted write(2) encountered an input/output
error.
```

程序中经常遇到的是 EIO, 也就是在在 close 之前, read/write 已经报错了(比如文件 fd 已经提前关闭, 网络的话 TCP 连接已经断开等), 这种情况忽略 close 的 err 才是正确的逻辑. **因为调用 close 的核心目的是释放资源, 而不管在这次调用之前资源是否已经被释放了, 程序只保证在该次调用 close 后资源一定是已经释放的状态即可.**

=服务器前面挂一个反向代理, 反向代理里限制一下并发数就好了.

支持自己动手玩一下, 学一学 parser 和 compiler 也是好的.

水冷普遍噪音比风大，降温效果不如风，价格也更高…

net/http 标准库

RTFD

@testsun 备案了, 当时花了一个月, 很烦躁

节制点用的话还行, 我最早的博客就在 1M 的服务器上, 后来写博客几篇文章中加了 gif 来展示算法, 就不行了, 现在博客还在服务器上, 但图片和 GIF 走又拍云的 CDN, 非常便宜.

我写开源项目的最大成就感是看到有人以非常严肃的态度对待我的项目, 不过目前吗...还没收获太大的成就.

这几年唯一欣慰的是两点:
- 几年前印度某个大学实验课讲义上用了我的项目做教学
- 在某语言的社区有提议人建议将某功能加入标准库, 用我的项目做了最初的 demo

这比收赞助开心多了鸭