Yebangyu's Blog

Fond of Concurrency Programming , Distributed System and Machine Learning

Memory Consistency和Cache Coherence

Memory Consistency

Memory Consistency(MC),有时候又叫做Memory Consistency Model或者Memory Model。为了理解为什么需要引入这种东西,我们首先看以下程序:

Linux下C++程序计时方法

最近简单学习了下LinuxC++程序计时的一些函数和方法,总结如下。没啥insight了。

方法一:

如果是想统计某个程序的运行时间,那么可以使用

time ./a.out

诡异的程序性能问题

本文所使用的环境是Ubuntu 14.04 32bit系统,Intel I5处理器,X86体系结构

提出问题

如果我说下面的程序存在性能问题,您信吗?

程序员时钟解读

最近购买圣诞礼物,抱着万能的淘宝的想法,在上面搜了一下“数学钟”,也就是非常流行的下面这幅图:

matchclock

以前,只知道其中十一个点钟的分析;对于3点钟,一直没有思路。于是发了一条朋友圈,求助大神解释其中的3点钟。在刘梓溪、贾顾森、黎鸣等大神的指导下,明白了其中是怎么回事。所以这里介绍下这十二个点,应该如何解释。个人观点,仅供参考。

12点

不用说了,1728的立方根。

1点

可能很多人不大知道,这是勒让德常数:

Introduction To Cuckoo Hashing

Motivation & Intuition

为什么引入Cuckoo Hashing

常见的hashing处理冲突方法一般包括两种:Separate ChainingOpen AddressingLinear Probing)。Separate Chaining是将冲突的元素组织成一个链表(其实组织成一个二叉搜索树也是完全没问题的,甚至跳表也行),Open Addressing将冲突的元素还是放在哈希表slot中,使用线性探测等方法进行处理。

那么,这两种方法,都有啥优缺点呢?

利用Distcc和Dmucs构建大规模、分布式C++编译环境(下)

上篇文章,我们介绍了如何利用Distcc来搭建分布式编译环境,但是Distcc的默认调度策略过于简单,并且并不合理。假如我们的配置是

export DISTCC_HOSTS="192.168.1.11 192.168.1.22 192.168.1.33"

那么Distcc会根据DISTCC_HOSTS中机器出现的先后顺序,来安排编译任务,越靠前的机器(比如这里的192.168.1.11)获得越多的任务,这显然是不科学的。

因此,我们可以利用Dmucs提供的调度策略,来优化我们的方案。它可以根据编译机的负载情况和硬件实力,来合理的调度资源。能者多劳嘛。

为了保证本文的完整性,我们还是不厌其烦地把我们的环境再交待下:

利用Distcc和Dmucs构建大规模、分布式C++编译环境(上)

如果您的C++项目非常庞大,含有1000.h文件,2000.cpp文件,那么我敢打赌,每次编译所花的时间,都足够您喝3000杯咖啡了。如何加快编译速度?

Distcc是开源的用于搭建分布式编译环境的利器,它通过利用多台机器的资源,并行编译,来解决这个棘手的问题。然而,它的调度算法过于简单,不大合理,因此我们利用DMUCS提供的调度功能,来搭建一个相对完美的分布式编译平台。本文,我们首先介绍如何(单独)使用Distcc来加速编译,下一篇介绍如何组合使用Distcc+DMUCS来做进一步的完善和优化。

话不多说,我们的编译平台包括: