前段时间看到了一个完成读比较高的协程库-libgo，里面提供了线程安全的协程实现，并且也是使用锁。本来我并没有给libcopp里的功能加锁的打算，因为上层dispatcher还是比较容易做到安全分发的，所以原来并不保证线程安全。而且线程安全这种问题单元测试比较难写，可能还得碰点运气。但是思来想去，还是为线程安全做点什么吧。反正也不是很复杂。
作者:张富春(ahfuzhang)，转载时请注明作者和引用链接，谢谢！ cnblogs博客 zhihu Github 公众号:一本正经的瞎扯 ---- (本文的pdf版本: https://files
Hello大家好,很高兴可以在这里和大家分享一下我的个人开源项目Microflow的相关工作。 我是BII天地互连的工程师，在公司里负责SDN产品和技术的开发，同时在ONF、OPNFV、ONOS等社区也有大量标准、开源，项目搭建等工作，目前在ONF担任工作组的副主席。 因为之前在做SDN控制器性能测试的缘故，对目前主流的开源控制器的性能都做了一些定量的测评，结果显示并不令人满意。 上周的那个paper里也同样认为当下控制器的性能是限制SDN网络部署的瓶颈，虽说分析得并不全面，但也部分说明了现状。 分析过CB
这本书讲的是如何用verilog，以riscv为指令集，设计一款CPU。也就是书中说的蜂鸟E200。之前没有看过类似的书，对CPU的工作流程也不熟悉。这本书以verilog为载体，介绍了CPU的基本原理，对于第一次接触CPU内部眼里的菜鸟来说，简直不要太神奇。而且本书开源代码，只要有一块fpga，你也能够自己做出一块CPU来。
业务中在高频调用代码段会出现条件判断语句, 因此联想cpu架构中的分支预测功能, 进行简要分析.
我们经常会听到分支预测失败或者虚函数调用会影响计算性能，那么为什么它们会影响性能呢？带着这个疑问，我最近也看了一些博客和论文，这里结合之前看的一些点，整体做一个总结，和大家一起学习。
不要等待计算结果保存到目的寄存器，增加一条额外数据通路，将计算的结果直接传给下一条指令计算的输入
我要再和生活死磕几年。要么我就毁灭，要么我就注定铸就辉煌。如果有一天，你发现我在平庸面前低了头，请向我开炮。
程序提前申请一块大内存由自己的内存池管理，并分成小块使用。程序使用完小块内存之后将内存归还到内存池中（并没有真正的从系统释放），当程序再次请求内存时，内存池将池中的可用内存块分给程序使用。
以下是c++的一段非常神奇的代码。由于一些奇怪原因，对数据排序后奇迹般的让这段代码快了近6倍！！
这次本来是打算写一篇 RocketMQ 相关文章的，但是被插队了，我也是没想到的，对了本号也有留言了哟。
我一看这个问题，竟然是 2012 年，也就是 8 年前的老问题。而其中的高票答案，都已经有 30000 多个赞了。
分支预测( Branch predictor):当处理一个分支指令时,有可能会产生跳转,从而打断流水线指令的处理,因为处理器无法确定该指令的下一条指令,直到分支指令执行完毕。流水线越长,处理器等待时间便越长,分支预测技术就是为了解决这一问题而出现的。因此,分支预测是处理器在程序分支指令执行前预测其结果的一种机制。在ARM中,使用全局分支预测器,该预测器由转移目标缓冲器( Branch Target Buffer,BTB)、全局历史缓冲器( Global History Buffer,GHB) MicroBe,以及 Return Stack组成。
根据《大话计算机》内容你点我贴一贴中所述，冬瓜哥收集了 “大话存储” 和 ”大话计算机” 中帖子下的留言如下（蓝色表示往期已回答，红色表示本期选中）：
条件分支指令通常具有两路后续执行分支。即不采取（not taken）跳转，顺序执行后面紧挨JMP的指令；以及采取（taken）跳转到另一块程序内存去执行那里的指令。是否条件跳转，只有在该分支指令在指令流水线中通过了执行阶段（execution stage）才能确定下来。
今天和实验室同学去听了周斌老师讲的《GPU并行计算和CUDA程序开发及优化》（课程主页：http://acsa.ustc.edu.cn/HPC2015/nvidia/），觉得老师讲得非常清晰，举了很多恰当的例子，将复杂的计算机中的情景和术语准确地描述成了简单的生活中的场景，使学生很容易就理解了。而我在今天的课程中也学到了很多东西，我想趁热打铁记下来，以后看起来更方便点。
说来也是巧最近在看 Dubbo 源码，然后发现了一处很奇怪的代码，刚好和这个 switch 和 if else 有关！
来源于stackoverflow上的一个问题为什么处理有序数组比处理无需数组快，原文中已经有了一些探讨，这里我们首先来复现下结果，然后再解释下为什么！
按道理说，也不应该是缓存造成的。仔细看一下这些代码，做的无非就是判断，加法这些很平常的运算。到底是什么导致了这样的差异呢？
近日，美国四所大学的一组学者发现了全新的边信道攻击方法，他们能够利用现代CPU中的推测执行功能来获取用户CPU数据，泄漏敏感数据和数据安全边界。这种边信道攻击方法与今年年初的 Meltdown 和 Specter 漏洞利效果相似，但研究人员这次利用的是CPU推测执行功能中的一个新片段。
Normal memory 可以设置为 cacheable 或 non-cacheable，可以按 inner 和 outer 分别设置。
最近有读者问我，面试被问到高性能，但因为自己都是靠死记硬背，没有消化理解，所以答的不是很好。
自从我们车间用上了乱序执行和分支预测后，生产效率那是大大提升，领导不仅在全厂的员工大会表扬了我们，还把这两项技术向全厂推广，在我们8个CPU核心车间都铺开了，性能甩开竞争对手CPU几条街。
4. Hardware Implementation The NVIDIA GPU architecture is built around a scalable array of multithreaded Streaming Multiprocessors (SMs). When a CUDA program on the host CPU invokes a kernel grid, the blocks of the grid are enumerated and distributed to
选自raspberrypi.org 作者：Eben Upton 机器之心编译 参与：路雪、黄小天、李泽南 过去几天，对 Meltdown 和 Spectre 安全漏洞的讨论甚嚣尘上。该漏洞影响了所有的现代英特尔处理器，Spectre 还影响了 AMD 处理器和 ARM 内核。Spectre 漏洞使得攻击者可以绕过软件检查读取当前地址空间中的任意位置数据；Meltdown 漏洞使得攻击者可以读取操作系统核地址空间的任意位置数据（用户程序通常不可访问该数据）。这两种漏洞皆通过边信道攻击（side-channel
针对海量的网络流量，转发性能是我们最关键的一个方面，那构建高性能的后台服务器有哪些关键的技术和需要注意的地方。
随着计算机的不断发展，摩尔定律似乎已经失去了作用，工艺的升级逐渐需要越来越长的时间，但其中计算机存储架构的瓶颈也限制着性能的发展。
这篇文章给大家盘一下“分支预测”这个听起来玄乎，但是对写业务代码没有任何卵用的小技巧。
最近爆出来的 Intel CPU 的底层漏洞可谓是影响巨大，过去20年的电脑都可能会受影响。前几天 Raspberry Pi 的官方 Twitter（@Raspberry_Pi） 转推了这篇文章，通过简单的 Python 程序分析了各种硬件术语和漏洞攻击模式，内容简单易懂，看后神清气爽。今天抽空将其翻译，分享给大家。本人英语也不算太好，对着百度磕磕绊绊的翻译了出来，如有错误请多多包涵。——2018年1月8日 *原文地址：https://www.raspberrypi.org/blog/why-raspber
现代计算机体系结构上，CPU执行指令的速度远远大于CPU访问内存的速度，于是引入Cache机制来加速内存访问速度。除了Cache以外，分支预测和指令预取也在很大程度上提升了CPU的执行速度。随着SMP的出现，多线程编程模型被广泛应用，在多线程模型下对共享变量的访问变成了一个复杂的问题。于是我们有必要了解一下内存模型，这是多处理器架构下并发编程里必须掌握的一个基础概念。
针对海量的网络流量，转发性能是我们最关键的一个方面，那构建高性能的后台服务器有哪些关键的技术和需要注意的地方，今天邀请了后台开发同学童琳和郑胜利来和大家一起谈谈。 一、引言 随着互联网的高速发展，内容量的提升以及对内容智能的需求、云产业的快速突起，作为互联网的计算基石服务器的形态以及使用成为了炙手可热的话题，全球各家大型互联网公司都持续的在服务器平台上有非常大的动作，譬如facebook的OCP等，而整个服务器的生态链也得到了促进和发展。随着服务器硬件性能的提升和网络硬件的开放，传统PC机的处理性能甚者可
一 前言 阿尔法实验室研究人员通过结合POC对整个漏洞原理流程还有漏洞细节做了进一步更详细的技术分析。 在本文中将详细分析POC中每个环节的关键点和漏洞的所有细节，包括漏洞形成的原因、漏洞攻击思路和方
用java语言编写的递归下降语法分析器，是一种适合手写语法编译器的方法，且非常简单。递归下降法对语言所用的文法有一些限制，但递归下降是现阶段主流的语法分析方法，因为它可以由开发人员高度控制，在提供错误信息方面也很有优势。就连微软C#官方的编译器也是手写而成的递归下降语法分析器。
前面介绍了乱序的概念及去相关,这里开始介绍处理器的乱序执行结构。 1. Buffer的作用去耦合 在顺序执行内核中,指令依次流经各个流水线单元,不需要进行缓存,而为了要能乱序执行,首先需要一个Buff
在追求高效代码的路上，我们不可避免地会遇到代码的性能瓶颈。为了了解、解释一段代码为什么低效，并尝试改进低效的代码，我们总是要了解硬件的工作原理。于是，我们可能会尝试搜索有关某个架构的介绍、一些优化指南或者阅读一些计算机科学的教科书（如：计算机组成原理）。但以上的内容可能都太过繁琐、细节太多，在阅读的过程中，我们可能会迷失在纷繁的细节中，没法很好地将知识运用到实践中。
开发过程中我们多少都会关注服务的性能，然而性能优化是相对比较困难，往往需要多轮优化、测试，属于费时费力，有时候还未必有好的效果。但是如果有较好的性能优化方法指导、工具辅助分析可以帮助我们快速发现性能瓶颈所在，针对性地进行优化，可以事半功倍。
StackOverflow发展到目前，已经成为了全球开发者的金矿。它能够帮助我们找到在各个领域遇到的问题的最有用的解决方案，同时我们也会从中学习到很多新的东西。
今天，我们一起看几个 StackOverflow 上关于 Java 的几个高赞答案。
我们在进行性能优化的时候，往往会应用各种花式的优化手段：优化算法复杂度（从 O(N) 优化到 O(logN) ），优化锁的粒度或者无锁化，应用各种池化技术：内存池、连接池、线程池、协程池等。压缩技术、预拉取、缓存、批量处理、SIMD，内存对齐等等手段后，其实还有一种手段就是 Profile-Guided Optimization （PGO）。本文会介绍 PGO 的原理，以及 Go/C++ 语言进行 PGO 的实践。
“骑士”漏洞是我国研究团队发现的首个处理器硬件漏洞，该漏洞是因为现代主流处理器微体系架构设计时采用的动态电源管理模块DVFS存在安全隐患造成的。 DVFS模块的设计初衷是降低处理器的功耗，允许多核处理器根据负载信息采用相应的频率和电压运行。一般说来，高运行频率配备高电压，反之采用低电压。但是，当某一个核出现电压和频率不太匹配的情形，如电压偏低无法满足较高频率运行需求时，系统就会出现短暂“故障”，就像是电压不稳灯泡闪烁一样，有时虽然不会影响系统整体运行，但如果该故障发生在安全等级较高的操作过程中，如加解密程序，会因为故障对系统行为结果的干扰会泄露出重要的系统行为信息，影响系统安全。“骑士”攻击正是利用这一漏洞，采用电压故障精准注入的方式，迫使处理器可信执行区（TEE，如ARM TrustZone、Intel SGX等）内的高安全等级程序运行出现故障，从而逐渐暴露其隐含的秘钥信息或者绕过正常的签名验证功能。 针对“骑士”漏洞的攻击完全是在DVFS允许的电压范围内进行，且攻击过程可以完全使用软件在线、远程实现，不需要额外的硬件单元或者线下辅助。“骑士”漏洞广泛存在于目前主流处理器芯片中，可能严重波及当前大量使用的手机支付、人脸/指纹识别、安全云计算等高价值密度应用的安全，影响面广。 攻击者的进程运行在一个低频率的处理器核心，受害者的进程运行在一个高频率的处理器核心上，攻击者进程提供一个短时间的故障电压，控制好电压的大小，使得这个电压对攻击者进程所在处理器核心没有影响，但是能使受害者进程所在处理器核心产生硬件错误，从而影响受害者进程。 具体的利用细节是，准备一个适当的能够发生电压故障的环境，做三件事，一是将受害者程序运行的处理器核心配置成高频率，其它处理器核心配置成低频率；二是攻击者程序用一个固定、安全的电压初始化处理器；三是清楚目标设备的剩余状态，包括Cache布局、分支预测表、中断向量表和状态寄存器等。 通常情况下，能够被VoltJockey注入错误的函数在受害者程序中只占很小的一部分，我们并不能确定其具体的执行时间，因此，攻击者程序需要在受害者程序产生错误之前对其中间执行过程进行监控，等待能够用来注入错误的函数被执行。 硬件注入攻击的目标是改目标函数的一小部分指令和数据，而且，这部分被影响的代码应该尽可能小。因此，错误注入点应该能被精确控制。到能够产生错误注入之前需要的时间，称为“预延迟”。 故障电压的大小和持续时间，是使产生的硬件错误能够被控制的两个因素。找到恰当的电压和持续时间，使得数据按照预期被改变，从而影响原有的程序流程，是非常重要的。 攻击的最终目的是获取受害者程序的敏感数据，或者篡改受害者进程的函数，而不是使受害者程序所在内核崩溃，因此，需要错误注入完成后，尽快恢复处理器核心电压为修改之前的正常值，确保受害者程序继续执行。
写完代码调试的时候，如果我们能够了解代码的执行过程往往能帮助我们更好的进行调试；而如果我们的代码性能出现了问题，我们又该如何处理呢？也许我们会想知道执行机上到底发生了什么，于是我们尝试通过perf、ebpf这样的工具来获取一些数据，比如了解这台机器上到底发生了多少次cache-miss；在获取到咋这么多数据后，我们又该如何判断性能的瓶颈究竟在哪里呢？
对开发人员来说， StackOverflow就像一个金矿。对具体的问题，它能帮我们找到最有用的答案，并且我们也可以从上面学习新的知识。
在英特尔处理器的“熔断”（Meltdown）和“幽灵”（Spectre）漏洞风波还未完全平息的时候，研究人员又在英特尔的处理器上发现了新的漏洞，此前的“熔断”与“幽灵”补丁可能无法完全应对这种攻击手段。
CPU执行一条指令也是类似的操作：取址-》解码-》执行，不断重复。此时一条指令需要三个时钟周期才能完成（取址，解码，执行）。
经常使用一些循环，进行耗时计算的操作，特别是 for 循环，它是一种重复计算的操作，如果处理不好，耗时就比较大，如果处理书写得当，将大大提高效率，下面总结几条 for 循环的常见优化方式。
领取专属 10元无门槛券
手把手带您无忧上云
