以一台Linux服务器为例。这台Linux包括两颗Intel(R) Xeon(R) CPU E5-2630 v4 @ 2.20GHz
CPU, 单颗CPU包括 10 个 cpu core, 使用超线程包含20个逻辑cpu core, 具体的官方介绍: E5-2630 V4。
下面让我们通过Linux的命令来查找对应的参数,看看是否符合官方的介绍, 主要是查看/proc/cpuinfo
的信息获得。
以一台Linux服务器为例。这台Linux包括两颗Intel(R) Xeon(R) CPU E5-2630 v4 @ 2.20GHz
CPU, 单颗CPU包括 10 个 cpu core, 使用超线程包含20个逻辑cpu core, 具体的官方介绍: E5-2630 V4。
下面让我们通过Linux的命令来查找对应的参数,看看是否符合官方的介绍, 主要是查看/proc/cpuinfo
的信息获得。
首先来了解一下来自维基百科上关于CPU缓存的介绍。
在计算机系统中,CPU高速缓存(英语:CPU Cache,在本文中简称缓存)是用于减少处理器访问内存所需平均时间的部件。在金字塔式存储体系中它位于自顶向下的第二层,仅次于CPU寄存器。其容量远小于内存,但速度却可以接近处理器的频率。
当处理器发出内存访问请求时,会先查看缓存内是否有请求数据。如果存在(命中),则不经访问内存直接返回该数据;如果不存在(失效),则要先把内存中的相应数据载入缓存,再将其返回处理器。
缓存之所以有效,主要是因为程序运行时对内存的访问呈现局部性(Locality)特征。这种局部性既包括空间局部性(Spatial Locality),也包括时间局部性(Temporal Locality)。有效利用这种局部性,缓存可以达到极高的命中率。
在处理器看来,缓存是一个透明部件。因此,程序员通常无法直接干预对缓存的操作。但是,确实可以根据缓存的特点对程序代码实施特定优化,从而更好地利用缓存。结构上,一个直接映射(Direct Mapped)缓存由若干缓存块(Cache Block,或Cache Line)构成。每个缓存块存储具有连续内存地址的若干个存储单元。在32位计算机上这通常是一个双字(dword),即四个字节。因此,每个双字具有唯一的块内偏移量。每个缓存块还可对应若干标志位,包括有效位(valid bit)、脏位(dirty bit)、使用位(use bit)等。这些位在保证正确性、排除冲突、优化性能等方面起着重要作用。
Intel的x86架构CPU从386开始引入使用SRAM技术的主板缓存,大小从16KB到64KB不等。486引入两级缓存。其中8KBL1缓存和CPU同片,而L2缓存仍然位于主板上,大小可达268KB。将二级缓存置于主板上在此后十余年间一直设计主流。但是由于SDRAM技术的引入,以及CPU主频和主板总线频率的差异不断拉大,主板缓存在速度上的对内存优势不断缩水。因此,从Pentium Pro起,二级缓存开始和处理器一起封装,频率亦与CPU相同(称为全速二级缓存)或为CPU主频的一半(称为半速二级缓存)。
AMD则从K6-III开始引入三级缓存。基于Socket 7接口的K6-III拥有64KB和256KB的同片封装两级缓存,以及可达2MB的三级主板缓存。
今天的CPU将三级缓存全部集成到CPU芯片上。多核CPU通常为每个核配有独享的一级和二级缓存,以及各核之间共享的三级缓存。
对于Go语言的defer语句,或许你回经历一个 赞赏 --> 怀疑 --> 肯定 --> 再怀疑的一个过程,本文带你回顾一下defer的故事,以及如何在代码中使用defer语句。
各种数据库的连接字符串的连接格式(一般叫做database source name, 简称DSN)是不同的,本文汇总了各个数据库驱动程序的字符串连接方式。
依照Java的文档, Java中的字符内部是以UTF-16编码方式表示的,最小值是 \u0000
(0
),最大值是\uffff
(65535
), 也就是一个字符以2个字节来表示,难道Java最多只能表示 65535个字符?
char: The char data type is a single 16-bit Unicode character. It has a minimum value of '\u0000' (or 0) and a maximum value of '\uffff' (or 65,535 inclusive).
from The Java™ Tutorials
首先,让我们先看个例子:
有多种方式可以获得Go程序的汇编代码, 尽管输出的格式有些不同,但是都是方便阅读的汇编代码,可以帮助我们更好的了解程序的底层运行方式。
sync.Mutex是Go标准库中常用的一个排外锁。当一个 goroutine 获得了这个锁的拥有权后, 其它请求锁的 goroutine 就会阻塞在 Lock
方法的调用上,直到锁被释放。
sync.Mutex
的实现也是经过多次的演化,功能逐步加强,增加了公平的处理和饥饿机制。
EOS白皮书官方文档: EOS.IO Technical White Paper v2,
中文翻译: EOS.IO 技术白皮书 v2, 由汪涛,minghua,鞠禹,李晓宇,轻灵紫,陈伟桢,赵余,以及另外两位不具名人士共同翻译,终稿由汪帆审校。