几乎没有对的……

单线程程序你可以理解为无论有多少个 CPU 都只能利用其中一个，用哪个 CPU 不是程序决定的，是 OS 决定的。在过去 OS 就是 OS 内核本身；虚拟化时代，所有的现代 OS 都有 hypervisor+内核两部分，在虚拟机中运行时 OS 能检测硬件环境以决定使用自己的 hypervisor 还是虚拟化环境里的。exsi 只有 hypervisor ，没有 OS 内核，而例如 windows 则既有内核（传统的 windows 内核）也有 hypervisor （ hyper-v ，当你启用 hyper-v 组件的时候 windows 会把自己也交给 hyper-v 调度）

超线程是硬件层面的线程机制，打个比方切换线程时要保存上下文，上下文里包括算数寄存器、内存指针（栈寄存器）、程序指针（ PC ）之类的值，软件实现的机制是 OS kernel 打断用户程序的执行然后把这些寄存器的值找块内存放起来，而硬件实现则可以直接换一组寄存器给线程使用。CPU 体系结构里有个概念叫 register file ，x86 cpu 算数寄存器大概 10 几个，但是算数寄存器的 registry file 有上百个大，也就是说 CPU 内部能保存十几个同一寄存器值的副本随时切换。当你软件切换线程上下文还在等内存写入的时候硬件只需要换一下寄存器映射几乎瞬间就完成了，这就是超线程加速的基本原理。

然后再说说主频问题，商用 CPU 和个人终端产品 CPU 在功耗、性能调度上会有很大区别，并不能简单地认为主频越高越快。主频越高能带来更短的指令周期，但内存延迟、睿频、流水线长度、功耗控制……即使不考虑多核性能，都仍有非常多变量因素产生影响。 只能说控制单一变量只有主频变化的时候程序执行时间与主频负相关，但这是正确的废话

如何评价？

https://github.com/search?q=baidu++authkey&type=code

我的评价是，开源真好

@edimetia3d 然而 concept 和 constraint 不就是俩东西来的吗……

应该无解，不如说这看着像个缺陷，不应该合法才对

无论是可变参数 va_args 也好，还是可变模板参数 typename ... TS 也好，本来都只能作为最后一个参数。这个 case 推导不出来不奇怪，但居然没报错

npm cnpm pnpm 都遇到过依赖装不上的破问题
选 yarn 是因为暂时没遇到幺蛾子

贵生态圈是真的一言难尽

@markliu2013 你太大声了（👿

如果能接受非定期贡献者我倒是不介意看看

仔细看了一下描述，你们全都是兼职的，所以你肯定也不能要求合伙人全职无薪。那么远程非定期我觉得也很合理。

另外既然重要的是商业模式，你们代码其实完全闭源的意义也不大，因此在源码隐私性这点我觉得也合理。

mailto: cG5ja3h4QHBtLm1lCg==

关注白雪艾莉娅喵关注白雪艾莉娅谢谢喵


------


喜欢看女孩子打游戏聊心事很奇怪吗？
真人直播约等于你在群里跟一个头像是自拍照的群友聊天
套纸片人皮直播约等于你在群里跟一个头像是冻鳗角色的群友聊天

就这丁点区别，没了

必经之路：
1. 无人光顾
2. 被分享到论坛，开始曝光
3. 约 p 撩骚处理不利，被铁拳
4. 机器人处理不利，被上缴大量流量学费
5. +验证码+手机号实名认证+消息记录全量副本+人工审核
6. 烂完

@ligiggy 啊 msvc 那有点蛋疼，windows 的 libc 好像没有自己的堆管理，直接用的 win32 api 。 可以先试试 HeapAlloc / VirtualAlloc 能不能分配出足够的空间

@iosyyy 你擅长记概念这点我看出来了

那么我替你总结一下你表达过的观点
1. cpp 也有 ioc 框架
2. 改代码不符合开闭原则但改 xml 符合
3. 不要屎山
4. 不流行的做法不代表 bad practice

噢…… 除了第二点不同意其它的我同意啊

所以为啥要有个像 spring 的框架呢，它会好用吗？


OP:
> 真的需要将 Go 写成 Java 的样子吗

#29 :
我的观点是作为一种指导思想，在不同语言里有适合各自的表达形式，复制一个相似的框架并不能起到足够引人注目的效果，而且同一种设计在不同语言机制下能带来的意义也不同。因此我认为不需要或者不应该把 go 写成 java 的样子。

上述观点我后来又重复地显式地总结了一次

#47 :
> … 本身就是 IoC 作为设计原则的体现，而非造一个看起来像 spring 的框架，那根本就不合适啊



这一点我们共识吗？

500m 是很大了，而且比较要命的是，如果你只用标准库而不直接调 OS API 预留内存的话，上一个 500m 的连续空间不知道什么时候就会被 glibc(ptmalloc)拆碎，拆碎了之后还不会优先合并大区块或者热区块，让 glibc 来管这些反复申请的大空间不是个好做法

monotonic buffer 是单调递增 buffer （即指针永不回退，除非整个 buffer 释放），适用于把相对大的一整块内存分给要不停分配小空间折腾的场合，不太符合你的需求


建议尝试 std::pmr::vector 配合 pmr::memory_resource ，然后手动 mmap 一块内存作为 memory_resource 的基底

另外因分配内存导致的性能缓慢通常是因为分配姿势不对引起的，比如是不是用循环依次复制每个对象了？是不是调用太多其实没用的构造 /析构了？ c++里如果发现分配内存占了时间大头绝大多数都是逻辑写得有问题可以优化掉的