@kkocdko @liprais 👍 查了一番，我之前的理解的确不到位，通过 cpupower 设置为 performance 在睿频开启的情况下的确还是有波动，谢谢两位！之后我会重新出一个关闭了 Turbo Boost 的结果

@kkocdko 谢谢您的提醒！
我之前一直认为，设置了 `cpupower frequency-set -g performance`, 那么默认都应该是固定在最高频率上跑，频率应该是稳定的；您要表达的意思是，如果 turbo boost 开着，我这样设置之后频率依然是不稳定的吗？

@cnbatch 👍 哈哈哈，这位朋友总结的专业！
更严谨一点，应该是: 高吞吐 -> 低时延且高吞吐

@liprais 是的，支持睿频，在测试之前，我已经直接 cpupower 设置成了 performance

这帖子发的和狗啃的一样，先下沉了，重写发一贴

= = 大意了！第一次发图，没显示出来，囧

---


@hitmanx
@icyalala
感谢两位上周的建议，这几天我写了一个 C/C++ Benchmark 项目, 用于横向对比一些知名的或以低延时为目标的 C/C++ 日志库, 并图表化显示
地址: https://github.com/MuggleWei/cc_log_benchmark

我想每个人学的时候都只会走一条路线，无法直接对比同时学和先后学哪个更好，属于小马过河了；不过条条大路通罗马，只要对技术有兴趣，定下目标，持续推进，最后应该能殊途同归，融会贯通吧

至于有网友说到不如学其他语言，或者学什么工资高之类的，请直接忽略这些说法；连后天(毕竟明天周天不开盘)股市涨跌都很难预测，怎么能确定等楼主四年后毕业时啥语言工资高，好找工作？语言只是工具而已，就像拿勺子喝汤，用锤子锤钉子一样，不同的场景用不同的工具这是很自然的道理，而编程语言也是一样
如果只学一门语言，很容易就加入这个语言相关的讨论环境中，每个语言都有自己的狂热分字，初学者更容易由于缺乏经验盲目陷入这个语言的井中，坐进观天，得出某某语言更牛逼的结论(现代的说法是信息茧房)，比如下面就是我遇到过的一些趣事
* 很早之前看过杂志的一篇文章，叫"学好 .net ，让你可以早下班"
* 十几年前，做游戏的同事表示:"国内用 Java 的人应该不是很多吧，估计也就写写网站后端会用到吧，后端用 c++ 很方便呀" (他们 MMORPG 从引擎到客户端，再到后端全是 c++，最多再加一点 lua)
* 前几年互联网行业的朋友对我说: "什么？现在还有人用 c/c++，疯了吧！后端 Java, 前端 js 一把梭不就好了吗"
* golang 大火的那几年，铺天盖地的说要全面替代 Java
* 去年有人发邮件用 Rust 教 Linus 做人，最后如愿被喷(参考: https://lkml.org/lkml/2022/9/19/1105)

我直接在工作中使用过 c++, lua, c#, java, go, python, 平时自己还爱用 c 写一些小玩意，就我的体验来说，每个语言都会有一些独特的东西，学习只后也能促进你对其余语言的认识，明白各个语言优劣势

而且你才大一，你有大把的时间可以尝试不同的东西，打下基础，多实践，等到大三下学期再决定未来是面向工资编程，还是更愿意为了兴趣而选择某个语言也不迟！

------
最后要说，其实更有趣的事情是：学好数学，学好数学，学好数学！ : )

@Masoud2023 是的，Nanolog 编译会生成一个 decompressor ，如果要以文本形式展示，得通过这程序解压一下日志~

@junmoxiao 谢谢！我平时不太用 xmake ，我之后去探索一下要如何加，哈~

@bashbot 啊哈，只能保证同一线程的顺序，不能保证多线程的顺序；不过想了一下即使是单缓冲区，其实也是不能完全保证，除非是把加时间戳的代码段都包含在某个锁中，这个就太废了; 回到日志本身，因为带有时间戳，所以即使不同线程在日志文件中乱序，而且乱序也只是在一个消费者循环中，问题也不太大，得看使用场景权衡取舍吧

@icyalala 👍 感谢提醒！上面也有位朋友提到了可以横向对比一下，我之后准备另外开一个库，跑 C/C++ 的不同日志库的 benchmark 看看，这样也可以发现还有什么库是特别快的

@zooo 啊~ 刚刚打漏了~ 谢谢你的夸奖！(*^_^*)

@zooo 啊哈，是的呢，如果感兴趣可以看看我这边的源码，或者也可以看看 Nanolog 那边的源码，虽然思路相同，但是实现是完全不一样的，不过都藏了很多有趣的东西呢！
就比如一个很简单的问题：为什么 haclog 和 Nanolog 都要限定 format 字符串为字符串常量呢？ 感兴趣可以去代码里探索一下呀，哈哈哈哈哈

@hitmanx 感谢提醒！的确是一个好建议！我之后会另外开一个库，可以用同一个 benchmark 的参数，来测多个不同的库，届时来回复您~

另外，项目中的 benchmark 确实我没在 README 中解释很详细，这个我的锅
其实就是使用 google benchmark 在测两部分场景
1. 设定最小的测试时间(google benchmark 中的 MinTime)，这时间中尽可能的压力测试写日志，看看当缓冲区高度紧张的情况下，日志前端写入效率如何。这个场景下测试了当线程数为 1/2/${CPU 数量的一半}/${CPU 数量 - 1} 的情况
2. 设定迭代和重复次数(google benchmark 中的 Iterations + Repetitions)，看看当缓冲区没被打满的情况下，能跑多快。这个场景下测试了当线程数为 1/${CPU 数量的一半}/${CPU 数量}/${2 倍 CPU 数量} 的情况

@zhs227 之后我加好了，一定来回复您！ (*^_^*)

@zhs227 这个的确可以加一下，但是考虑到保持日志库本身的简单，不对外部的有依赖；所以得想一下如何实现
* 自己实现
* 或是从允许商用的 LICENSE 开源压缩库里扒代码
* 或是以 extra 的形式增加一个依赖外部 gzip 的 handler
十分感谢提醒！！！

@huangzongzhuan 谢谢夸奖！纯粹是兴趣，乐在其中，祝你也能对技术保持长久好奇心！

看完标题：OP 搁着炸鱼？
看完下面回复：难道这 OP 真的不懂？
看了一下 OP 的其他帖子：哦，原来是真小白啊