T********i
发帖数: 2416 | 1 差不多10年前了。C++。彻底的kernel bypass。NUMA， huge TLB，CPU isolation。
当时连靠谱的NUMA allocation机制都找不到。发现最可靠的就是reserve一个huge
page然后根据CPU socket平均分配一下pool。
custom memory allocator。用的最简单的binary。allocate的时候找最接近的2^n空闲
块，如果找不到就在pool里顺序分配一个。free的时候把这个块归还n的list里边。
allocate和free都是个位数指令。理论上内存浪费可能多一倍。实际上没那么多。其实
系统死循环运行，memory usage pattern可以证明是固定的。
我个人经验。这种lock free架构和传统架构是格格不入的。根本没有任何办法能够把
他们整合起来。多核间通信都是invariant message passing。传递的都是指针。这是
硬实时架构，延迟是guaranteed。除非你哪里写错了，那种情况直接主动崩溃是最好的
选择。如果你写对了，消息都是在一个简单的循环队列里边，在消息被擦除前，保证早
被处理了。说穿了，就是在用空间换时间。
目前看来，这是我发明的架构。还没有看到其他人把架构化简到这个程度。我的系统已
经production多年了。 |
T********i
发帖数: 2416 | 2 另外这种架构，如果不考虑latency因素，其实NUMA带来的性能提升有限。也就30%左右
吧。反正现在CPU LLC都很大。
关键的是你如何思考整个系统？如何实现？这世界上你要取舍。没有斩尽天下便宜的那
个好事。你要这么做，就不要考虑那么做！ |
N*****r
发帖数: 94 | 3
hehe , 任何行业都有两种人，一种人是吃透了东西，会用现有框架，也知道有不足该
怎么改进
另一种就是学了框架，不学明白，到处瞎套，套不上就觉得是世界错了。。。。
这世界上绝大多数都是后者
【在 T********i 的大作中提到】
: 差不多10年前了。C++。彻底的kernel bypass。NUMA， huge TLB，CPU isolation。
: 当时连靠谱的NUMA allocation机制都找不到。发现最可靠的就是reserve一个huge
: page然后根据CPU socket平均分配一下pool。
: custom memory allocator。用的最简单的binary。allocate的时候找最接近的2^n空闲
: 块，如果找不到就在pool里顺序分配一个。free的时候把这个块归还n的list里边。
: allocate和free都是个位数指令。理论上内存浪费可能多一倍。实际上没那么多。其实
: 系统死循环运行，memory usage pattern可以证明是固定的。
: 我个人经验。这种lock free架构和传统架构是格格不入的。根本没有任何办法能够把
: 他们整合起来。多核间通信都是invariant message passing。传递的都是指针。这是
: 硬实时架构，延迟是guaranteed。除非你哪里写错了，那种情况直接主动崩溃是最好的
|
g****t
发帖数: 31659 | 4 what kind of test you have done? Application scenario?
what type of IO?
I used to designed an memory diagnostic algorithm to trigger the CPU reset
automatically.
【在 T********i 的大作中提到】
: 差不多10年前了。C++。彻底的kernel bypass。NUMA， huge TLB，CPU isolation。
: 当时连靠谱的NUMA allocation机制都找不到。发现最可靠的就是reserve一个huge
: page然后根据CPU socket平均分配一下pool。
: custom memory allocator。用的最简单的binary。allocate的时候找最接近的2^n空闲
: 块，如果找不到就在pool里顺序分配一个。free的时候把这个块归还n的list里边。
: allocate和free都是个位数指令。理论上内存浪费可能多一倍。实际上没那么多。其实
: 系统死循环运行，memory usage pattern可以证明是固定的。
: 我个人经验。这种lock free架构和传统架构是格格不入的。根本没有任何办法能够把
: 他们整合起来。多核间通信都是invariant message passing。传递的都是指针。这是
: 硬实时架构，延迟是guaranteed。除非你哪里写错了，那种情况直接主动崩溃是最好的
|
p***o
发帖数: 1252 | 5 估计是HFT，github上有LMAX出的java轮子。
【在 g****t 的大作中提到】
: what kind of test you have done? Application scenario?
: what type of IO?
: I used to designed an memory diagnostic algorithm to trigger the CPU reset
: automatically.
|
T********i
发帖数: 2416 | 6 app是HFT。但是架构是universal的。这东西用Java没戏。虽然也能做，但是属于脱裤
子放屁。
【在 p***o 的大作中提到】
: 估计是HFT，github上有LMAX出的java轮子。
|
p*u
发帖数: 2454 | 7 HFT已死。
【在 T********i 的大作中提到】
: app是HFT。但是架构是universal的。这东西用Java没戏。虽然也能做，但是属于脱裤
: 子放屁。
|
T********i
发帖数: 2416 | 8 死了挺好的。要是一直都欣欣向荣这世界就更操蛋了。
架构是架构，和HFT有个鸟关系啊？不做HFT还可以做12306呢。
不做12306还可以做别的。呵呵。
【在 p*u 的大作中提到】
: HFT已死。
|
s********k
发帖数: 6180 | 9 老魏你做惯了这个高性能，怎么跑来做wireless，继续搞这个高性能啊
【在 T********i 的大作中提到】
: 死了挺好的。要是一直都欣欣向荣这世界就更操蛋了。
: 架构是架构，和HFT有个鸟关系啊？不做HFT还可以做12306呢。
: 不做12306还可以做别的。呵呵。
|
p*u
发帖数: 2454 | 10 这方面已经没啥可做的了，各种软硬solutions不计其数，latency is a commodity
now。
【在 s********k 的大作中提到】
: 老魏你做惯了这个高性能，怎么跑来做wireless，继续搞这个高性能啊
|
|
|
T********i
发帖数: 2416 | 11 还是那句话，这个和latency也没啥大关系。这个架构是通用架构。
latency最低，throughput也最高。这方面现在没啥commodity。
我暂时不需要这么高throughput不见得以后不需要。
【在 p*u 的大作中提到】
: 这方面已经没啥可做的了，各种软硬solutions不计其数，latency is a commodity
: now。
|
p*u
发帖数: 2454 | 12 其实就是一种microkernel架构呗。
【在 T********i 的大作中提到】
: 还是那句话，这个和latency也没啥大关系。这个架构是通用架构。
: latency最低，throughput也最高。这方面现在没啥commodity。
: 我暂时不需要这么高throughput不见得以后不需要。
|
T********i
发帖数: 2416 | 13 哪里那么复杂？就是一个状态自动机而已。
【在 p*u 的大作中提到】
: 其实就是一种microkernel架构呗。
|
g****t
发帖数: 31659 | 14 就是几个goto,reset 吧，哈哈
: 哪里那么复杂？就是一个状态自动机而已。
【在 T********i 的大作中提到】
: 哪里那么复杂？就是一个状态自动机而已。
|
T********i
发帖数: 2416 | 15 我代码里基本没有goto。基本专业素质还是有的。
【在 g****t 的大作中提到】
: 就是几个goto,reset 吧，哈哈
:
:
: 哪里那么复杂？就是一个状态自动机而已。
:
|
g****t
发帖数: 31659 | 16 Linux kernal很多goto
我也用很多，LoL
状态机用goto 不容易出错。
Switch的话，不同c编译器有时候会有小小不同。
: 我代码里基本没有goto。基本专业素质还是有的。
【在 T********i 的大作中提到】
: 我代码里基本没有goto。基本专业素质还是有的。
|
m*****p
发帖数: 39 | 17 我也曾經接觸過低延時架構，應用是SS7信令網關，延時要求高，純C打造，很複雜的狀
態機和callback，socket進程間通信，傳struct指針。看來和HFT一樣啊。 |
T********i
发帖数: 2416 | 18 状态机就俩函数。
sendMessage
onMessage
这应该是世界上最容易写的东东。根本不需要考虑啥thread, I/O之类的。
【在 g****t 的大作中提到】
: Linux kernal很多goto
: 我也用很多，LoL
: 状态机用goto 不容易出错。
: Switch的话，不同c编译器有时候会有小小不同。
:
:
: 我代码里基本没有goto。基本专业素质还是有的。
:
|
p*u
发帖数: 2454 | 19 你这比魏老师的复杂多了，他那个就是kernel接近于零的microkernel架构。
【在 m*****p 的大作中提到】
: 我也曾經接觸過低延時架構，應用是SS7信令網關，延時要求高，純C打造，很複雜的狀
: 態機和callback，socket進程間通信，傳struct指針。看來和HFT一樣啊。
|
g****t
发帖数: 31659 | 20 复杂的C代码往往是一点点修出来的各种corner cases补丁
: 我也曾經接觸過低延時架構，應用是SS7信令網關，延時要求高，純C打造，很複
雜的狀
: 態機和callback，socket進程間通信，傳struct指針。看來和HFT一樣啊。
【在 m*****p 的大作中提到】
: 我也曾經接觸過低延時架構，應用是SS7信令網關，延時要求高，純C打造，很複雜的狀
: 態機和callback，socket進程間通信，傳struct指針。看來和HFT一樣啊。
|
|
|
T********i
发帖数: 2416 | 21 都做差不多的事情。凭啥他那个就复杂啊？
他那就是一个网关，网卡收到消息，送到哪里去。
我那个网卡收到数据，还要经过复杂运算，最后产生order，还要用不同格式送出去。
【在 p*u 的大作中提到】
: 你这比魏老师的复杂多了，他那个就是kernel接近于零的microkernel架构。
|
s********k
发帖数: 6180 | 22 听起来这个是erlang的思想？
【在 T********i 的大作中提到】
: 状态机就俩函数。
: sendMessage
: onMessage
: 这应该是世界上最容易写的东东。根本不需要考虑啥thread, I/O之类的。
|
T********i
发帖数: 2416 | 23 其实说来说去就那么几招而已。
关键就是底层给你搞好，高层只需要考虑算法而已。
底层也就那么几招。memory model也很简单，说白了就是一个message object的alloc
和free。
thread model都没有了，取而代之的是partition，就是这个message handler分配到哪
几个core上而已。
【在 s********k 的大作中提到】
: 听起来这个是erlang的思想？
|
p*u
发帖数: 2454 | 24 他那个要handle的traffic比你的market data要多不少吧。
【在 T********i 的大作中提到】
: 都做差不多的事情。凭啥他那个就复杂啊？
: 他那就是一个网关，网卡收到消息，送到哪里去。
: 我那个网卡收到数据，还要经过复杂运算，最后产生order，还要用不同格式送出去。
|
T********i
发帖数: 2416 | 25 你是来抬杠的么？呵呵。
无脑收发很困难么？也就几十行代码吧。
【在 p*u 的大作中提到】
: 他那个要handle的traffic比你的market data要多不少吧。
|
c*********e
发帖数: 16335 | 26 求你写的状态机源码，这2个参数的。
【在 T********i 的大作中提到】
: 状态机就俩函数。
: sendMessage
: onMessage
: 这应该是世界上最容易写的东东。根本不需要考虑啥thread, I/O之类的。
|
f******2
发帖数: 2455 | 27 老魏可以研究研究nginx，找到感觉后看看能不能提出一个让latency提高一个量级的办法
: 都做差不多的事情。凭啥他那个就复杂啊？
: 他那就是一个网关，网卡收到消息，送到哪里去。
: 我那个网卡收到数据，还要经过复杂运算，最后产生order，还要用不同格式送
出去。
【在 T********i 的大作中提到】
: 你是来抬杠的么？呵呵。
: 无脑收发很困难么？也就几十行代码吧。
|
n******t
发帖数: 4406 | 28 Nono, 真正的latency大部分情況下都不是commodity，如果認為是commodity的case，
是人沒把latency和throughput分清楚。
此外，99%的人感覺到的所謂latency問題其實都是throughput的問題，只不過和大部分
人講不通，同時還搞得別人覺得自己是傻逼一個不好賣東西，何必呢?
【在 p*u 的大作中提到】
: 这方面已经没啥可做的了，各种软硬solutions不计其数，latency is a commodity
: now。
|
s**********3
发帖数: 4 | 29 嗯，资源固定情况下，低latency和高throughput是互相矛盾的设计需求。 |
m*****p
发帖数: 39 | 30 其實挺複雜的，幾十行肯定寫不出來VoIP信令交互和媒體控制網關，支持各種信令：
SS7／SIP／H.248等等，插上DSP卡還可以當媒體網關使用，內部crossbar走ATM，外部
TDM走SONET，IP走10GE，信令走SCTP，媒體走RTP，硬件是私有刀片服務器，Power架構
，當年還是挺先進的，不是普通交換機網關。裏面的狀態特別多，其實是Trillium的中
間件，出問題會core，然後熱切換。後來華為發達了，我就轉行了。
【在 T********i 的大作中提到】
: 都做差不多的事情。凭啥他那个就复杂啊？
: 他那就是一个网关，网卡收到消息，送到哪里去。
: 我那个网卡收到数据，还要经过复杂运算，最后产生order，还要用不同格式送出去。
|
|
|
m*****p
发帖数: 39 | 31 提高latency一個數量級，必須是搞硬件的人，軟件工程師不懂latency。
軟件強調抽象、虛擬化，時間都是虛的，function大部分都是blocking，這樣debug才
容易。
硬件強調Timing、Latency，至少cycle級別，一般都ps級別，全部並行化，軟件的人理
解不了。
這就是為什麼要徹底轉行碼農：硬件學得越好，軟件技能就會越差 or vice versa
办法
【在 f******2 的大作中提到】
: 老魏可以研究研究nginx，找到感觉后看看能不能提出一个让latency提高一个量级的办法
:
:
: 都做差不多的事情。凭啥他那个就复杂啊？
:
: 他那就是一个网关，网卡收到消息，送到哪里去。
:
: 我那个网卡收到数据，还要经过复杂运算，最后产生order，还要用不同格式送
: 出去。
:
|
T********i
发帖数: 2416 | 32 老方说latency的时候，其实他的意思是throughput。
即使latency，做low latency软件的还是搞软件的。除非是FPGA硬件。
我个人认为他山之石可以攻玉。我就啥都搞。Web，Java，C/C++，ASM，MCU/X86/ARM，
RF，UART，SPI/SSI，i2c还有上百个RFC。还其他一些有些乱七八糟的东东。
【在 m*****p 的大作中提到】
: 提高latency一個數量級，必須是搞硬件的人，軟件工程師不懂latency。
: 軟件強調抽象、虛擬化，時間都是虛的，function大部分都是blocking，這樣debug才
: 容易。
: 硬件強調Timing、Latency，至少cycle級別，一般都ps級別，全部並行化，軟件的人理
: 解不了。
: 這就是為什麼要徹底轉行碼農：硬件學得越好，軟件技能就會越差 or vice versa
:
: 办法
|
m******r
发帖数: 1033 | 33 太牛逼了， 我都看傻了， 还有和华为PK的。
我挺好奇你们懂这么多，是书上看的，还是单位里学的 ，还是业余时间鼓捣出来的？
我见过的牛人和我看同一本书， 看完人家就明白了。 我是得看好几本书，才能琢么出
来，还没人家琢磨透。
你们什么都搞的是看了什么《葵花宝典》 还是纯自己想出来的? |
p*u
发帖数: 2454 | 34 electronic trading里面的ultra low latency，和你说的普通server里面latency/
throughput的trade off根本是两回事。
【在 n******t 的大作中提到】
: Nono, 真正的latency大部分情況下都不是commodity，如果認為是commodity的case，
: 是人沒把latency和throughput分清楚。
: 此外，99%的人感覺到的所謂latency問題其實都是throughput的問題，只不過和大部分
: 人講不通，同時還搞得別人覺得自己是傻逼一個不好賣東西，何必呢?
|
p*u
发帖数: 2454 | 35 electronic trading做的基本都是在普通commodity servers上降低latency，而不是
design new hardware。
【在 m*****p 的大作中提到】
: 提高latency一個數量級，必須是搞硬件的人，軟件工程師不懂latency。
: 軟件強調抽象、虛擬化，時間都是虛的，function大部分都是blocking，這樣debug才
: 容易。
: 硬件強調Timing、Latency，至少cycle級別，一般都ps級別，全部並行化，軟件的人理
: 解不了。
: 這就是為什麼要徹底轉行碼農：硬件學得越好，軟件技能就會越差 or vice versa
:
: 办法
|
