T********i
发帖数: 2416 | 1 其实你再想想？
别说现在抢票用单线程，就算是多线程，也能让它想同步就同步，想异步就异步。
代价就是那么几个微秒毫秒而已。
你真以为我们做高频的萝卜快了不洗泥？这个系统的可控性也是强实时的。 |
|
|
T********i
发帖数: 2416 | 3 来自主题: Programming版 - 简单就是美 计算机系统的设计，有时候竟然能够通吃。比如，简化设计，有时候（并不总是）能够
提高性能，降低开发成本，降低维护成本。
这个理念在其他领域也能应用。比如著名的AK47，几十年的世界名枪。就得益于其设计
的相对简单，性能可靠性俱佳。
我最先和zhaoce交换的帖子。因为他提到J2EE。我说那一坨屎。就此交恶。J2EE为啥一
坨呢？很简单。因为开发者认识到一个一个重要的问题，广大Java程序员不合格比例太
高。让他们开发数据库应用不让人放心。于是他们就想提供标准类吧数据，以及数据访
问标准化。最好能够自动（实际上半自动）和地和数据库绑定（无非reflection之类，
加上自动生成代码）。观念无所谓好坏。问题是，如果你认为很多Java程序员狗屁不懂
，多写几行就崩的那种，那么J2EE几千页文档，上千行所谓的XML descriptor file难
道不是语言？而且是另外一种语言。
J2EE能做出稳定可靠的应用，丝毫不能否认它是的事实。再贫瘠的土地，屎多放点，一
样可能长出庄稼。投入了，多少都会产出。关键是这个比例。
后来即使那些脑袋不大灵光的信徒，也懂得开始算账。两三行程序就能创建一个线程，... 阅读全帖 |
|
T********i
发帖数: 2416 | 4 别忘了，1m/s是核心机的速度。
外围可接无穷多cache机。每台cache机都是1m/s。
而且cache机更新是实时的。微秒级别的延迟。只有确认有票才送核心机。
这个是无穷scalability。 |
|
T********i
发帖数: 2416 | 5 2008年我做过一个实时Java系统，用Object Pool + RTSJ，响应能达到两位数的微秒。
这个每天要重启数次的系统。不是我的系统。用Java做的。干脆就是连Object pool都
懒得用。是2010年以后做的新系统。现在还在production。
这个系统号称是disable GC。现在看来也可能是不停monitor heap。别人的系统我没兴
趣搞细节。但是其以前用户是我的搭档。每天可控的重启是肯定的。
我当时想说的是，即使用duct tape做一个系统，也能用。 |
|
T********i
发帖数: 2416 | 6 我不关注Java GC已经有6-7年了。
2008年左右做过一个基于RTSJ的系统。响应能达到几十微秒左右。当时就有一个问题，
即使你memory足够用，也不能保证不产生小的碎片。
对实时系统，我们只能有两个方案：
1. 用所谓的Concurrent GC
问题是，虽然号称是concurrent的，到底能多大程度保持实时性。
当年根据我对RTSJ的测试，结果是令人失望的。这也是我为什么对disable GC一直有所
期盼的原因。
今天，牵狗搜了一下。发现了一个叫做C4的concurrent GC，感觉还是靠谱的。
http://www.azulsystems.com/technology/c4-garbage-collector
C4需要用户代码的配合（当然是编译器实现的，当用户线程access object的时候可能
会配合主动移动memory block）。
2. 比较准确地预测GC将会发生，提前做好准备
这个我没有做过。貌似缺省的GC方案在Eden space没有填满的情况下不会进行任何GC。
这个我还需要确认。如果这个确实属实，确实和Disable GC的效果一样。因为GC基本... 阅读全帖 |
|
T********i
发帖数: 2416 | 7 你傻逼是不是，我的系统个位微秒延迟也是有缓存的。
再往下，硬件上，memory controller，QPI bus，cpu都带缓存。你丫基本功不是一般
的糙。 |
|
x****u
发帖数: 44466 | 8 让你用C++写一个还赶不上人家呢。
工业界实时性强的东西，很多人都是DOS环境裸搞，不然一个任务切换差了几微秒，火
箭早爆炸了。 |
|
g*****g
发帖数: 34805 | 9 工业上追求微秒的延迟的系统应该不多，我不敢说没有。每微妙能造成的价值能跟
stock exchange相比的应该没有。
最有钱的系统可以追求最好的解决方案，如果windows的实时效果更好，LSE没法解释。
人是不差钱，换上去用了两年又换下来了。 |
|
g*****g
发帖数: 34805 | 10 我老10多年前开始混这个版的时候，internet bubble刚破，CS不算吃香，F2大妈们纷
纷转向统计和护士，这个版上讨论问题的大多是科班出身的。语言之类的争吵虽然有，
但很少有外行出来指点江山，一看就错得离谱的。自从上次经济危机之后，码农的收入
节节上升，酸葡萄多了，各路牛鬼蛇神开始出来鄙视职业码农的事情也开始层出不穷。
诸如12306不行，就有学EE没写过商业网站的出来打包票，明明是Scalability问题非要
追求微秒级latency，把高并发生生写成计数器。有觉得WhatsApp容易，C10K没实践过
，要挑战C10M的。有千老只写过自己用的一次性C++程序，就推荐以C&P替代代码复用的
。有改现成的商业PHP网站都吐血精分，非要强调码农的能力表现在底层，以对流水线
调度的认识深度区分。最新的又有智商论，编程纯工具论，反正ID边上也没标着智商，
大意就是我智商比你高，学个CS小菜呀，做码农轻松比你科班的强。
我老想起来魏老师千辛万苦写个计数器，用了高大上的compare&exchange之类的技术来
达到non-blocking的目的。我老质疑联票没有integrity... 阅读全帖 |
|
g*****g
发帖数: 34805 | 11 LOL，数据耦合的问题是我提的，不是太监，他上来就是80G全双工要用完，微秒级
latency，完全不着调。对CAP theorem一无所知，连计数器都是逼出来的。你别站错了
队现在要来重写历史。 |
|
g*****g
发帖数: 34805 | 12 不错，所以先弄明白12306是干啥的就不会追求啥微秒级latency。Priceline可以让你
等一分钟，但基本不会404。 |
|
g*****g
发帖数: 34805 | 13 太监了一年，低调了嘛。上次还是银河系，微秒级，一下子降低了无数个数量级。 |
|
x****k
发帖数: 2932 | 14 先前看到了毫秒忍住了没吱声，又来一个。
郑重说一下，hft里面的时延单位通常是微秒，us, micro-sec. 10^-6 sec. 不是毫秒
。一毫秒内人家几百个order都出去了 |
|
T********i
发帖数: 2416 | 15 Transaction也是有Isolation Level的。就为了这个值得你狂吠两年说我不懂
transaction？
我那个isolation没考虑周到又如何。我那个是dirty read，几个微秒以后就正确了。
我这辈子，犯的比那个严重的错误也不是没有。
现在我怀疑，你到底懂不懂Transaction Isolation Level？胡说什么"transaction的
要求之一"？ |
|
T********i
发帖数: 2416 | 16 你这就又属于无耻了。
那个系统，即使我当时考虑不周，用来卖全世界所有的票，任何一个时刻，也顶多只有
10张票在几个微秒内暂时被锁。
至于为什么是10张票？你当时没搞懂，现在也不会懂。你这辈子就这样了，指望下辈子
投胎变聪明点好了。
了。 |
|
s*i
发帖数: 5025 | 17 当年老魏本来开始上的PhD program。可惜牛哄哄的整天指出导师和上课老师的错误，
再加上突然花街甩出一把票子，这厮就退学了。
老魏不久快速搞出的绝对低延迟的 trading 平台，当年引起了小震动！说个大家不太
相信的事儿，知道为什么很多搞证券的要在花街那里不？电子的传输，比如在迈阿密，
到交易所的延迟，已经是花街之狼们所不能容忍的了。老魏的牛逼之处在量（频率）和
实时性！更牛的是，相当一部分Code是Java写的。要知道 Java 的垃圾回收首先就要超
过毫秒了，人家talking about的是微秒级的。 |
|
T********i
发帖数: 2416 | 18 当时实现有一个小bug，导致最多10张票在几微秒的短时间内可能有票不能出。而且很
快也被fix了。 不支持transaction票怎么可能会被临时锁住？
就这么个小bug，被这个人渣造谣不支持transaction说了两年，每次还要加上其它侮辱
性字眼。
你倒是说说，是设计不能支持transaction，还是实现不能？
你丫要是会做你做一个，我做一个秒你10倍的。
你丫要是不会做，这两年多这么下作难道不是作死么？ |
|
t**********1
发帖数: 550 | 19 别不要脸，我问过你很多次了，你号称计数器不支持transaction，造谣上百次，这回
换个说法继续造谣。
1. 计数器震荡是个小bug。当时马上就fix了。多线程fix以后遇到race就自动重试一次
而已。本来就是微秒级别的延迟，甚至纳秒。10核race相当罕见。因为马上无效请求就
会被cache机屏蔽。你看不懂是你自己的问题。单线程也没有问题。都是每秒5M以上票
数的。
现在我问你，你要是能证明我没有fix，那我公开道歉，再也不来。你要是不能证明，
那你自己自杀ID以后滚出去好不好？ Come on. Be a man!
你证明不了我没有fix。还继续散步谣言，污言秽语，我当然要搞你。反正我手头信息
足够。LOL
2. 3. 智能控温是我平台的应用。我和谁都是这么说的。你爱懂不懂。爱咋说咋说。我
不在乎。对我的business毫无影响。
今天打你，是因为上百次造谣计数器不支持transaction，连续两年持续造谣。我手头
信息足够。整你绰绰有余。反正我时间也足够。呵呵。
hobby |
|
t**********1
发帖数: 550 | 20 别不要脸。这个计数器是针对中途允许换座卖票。
单线程都可以每秒50M票。比10核多线程性能都好。程序我都贴出来了。
这样好吧，当时讨论的是允许换座位，每秒5M票。
按照我的单线程帖子的假定，如果单线程throughput没问题，你自杀ID从此不来好不好？
如果单线程throughput有问题，我公开道歉从此不来好了。
SSA的fix没有问题。只不过有个纳秒到微秒级别的延迟而已。 |
|
b*******g
发帖数: 603 | 21 关键要每秒百万次，不说写，给个初始输入。光确认一下有票没票100万次，两个查询
不能并行。也就是 1 微秒找座位已经是必挂的节奏了。 |
|
t**********1
发帖数: 550 | 22 5000车次，每车次10站，3000票。输入车次，上车下车站，给回有 票没票信
息，有票要占住，中途不换座，要1微秒完成。我不管你单线程多线程。 |
|
|
|
t**********1
发帖数: 550 | 25 5000车次，每车次10站，3000票。输入车次，上车下车站，给回有 票没票信 息，有票
要占住，中途不换座，要1微秒完成。我不管你单线程多线程。
好虫又加上网络输入和输出。
这个我也同意。反正1M/s。千兆网没压力。
仅限一个TCP输入和输出。
如果我做出来，好虫自杀所有ID, 从此滚出这个BBS。不许再注册进来。
benchmark，输入要严格限制在1M/s。误差正负5%以内。
虽然输入时间任意。但是为了benchmark。不应超过1小时。 |
|
t**********1
发帖数: 550 | 26 1微秒根本不可能准确测量。
我们可以选择1小时内1M/S请求都正确响应。总延迟不超过3秒。
好虫。等你确认。
这次再chicken out没人瞧得起你了。 |
|
g*********e
发帖数: 14401 | 27 就算全cache miss也还是没问题 一个微秒够用了
64 |
|
t**********1
发帖数: 550 | 28 5000车次，每车次10站，3000票。输入车次，上车下车站，给回有 票没票信 息，有票
要占住，中途不换座，要1微秒完成。我不管你单线程多线程。
仔细阅读，输入和输出。这是好虫的要求。
这就是赌约。
你想其他输入，那是另外的合同了。 |
|
t**********1
发帖数: 550 | 29 来自主题: Programming版 - 代码开源了 股票市场每天quote比这个负载多几个数量级了。
这么多家客户端，都是interday说恢复就恢复。还要微秒级的latency。难道人家都有
很多问题没解决？
状态恢复，小儿科而已。 |
|
k*******r
发帖数: 90 | 30 因为这个版上二把刀太多
也不能怪他们
计算机这门科学好多半道出家的以为学点皮毛就以为可以关公耍大刀
殊不知很多时候能知其所以然都做不到
的确，如果计算机的频率一直往上跑， 1M qps并不是什么大不了的问题
但是关键是现在频率没法加了，多核的情况下不是简单的堆机器就能搞定 1M qps
teacherwei还说什么一个核处理网络，一个核处理订票
一看就是完全不懂其中的利害的
一个系统调用就能超过1微秒，还一个核搞定 |
|
g*****y
发帖数: 7271 | 31 其实trade off也不难做，先到的当然先买到的票，不能因为后面
人的request填空好而被改掉。
后到的，如果没有一个seat能做到底，可以给他一个connection的票，
中途要换座位。他要是不怕换位置麻烦，就坐上这趟火车。他要是嫌麻烦，
改买飞机票了，或者决定不回去了，反正是他自己的决定。别怨政府就行了。
就像你小两口买飞机票，想排排坐，结果飞机上已经没有排排坐的座位了，
你多半也就是上飞机后找人商量换座位而已。有啥大不了的。
至于说什么微秒民工看不懂，你是真傻还是装傻，不会给个序号，看
大小就完了！阿拉伯数字都不认识的，坑了也就坑了。他敢放个屁？ |
|
s******d
发帖数: 6 | 32 发表一点对benchmark 的看法，首先数据是对的，但是在一个屋里，可能10尺范围内。
大家都知道，对一个单个网络请求的latency的上限是距离／光速。光速是miles per
second: 186000。也就是说186miles的距离，最小latency是2ms，这和
CPU多快，code多牛没关系，这也是为什么老魏做trading 抢股票的机器一定要在
nasdaq的机房。
现在老魏做一个巨牛的单机的核心机，微秒级的。我不怀疑。这时候的问题是外围机放
那儿，要多少台。要喂饱核心机的话，外围机放得越远，需要机器越多。而且还有外围
的外围机。其实最外的外围机就是用户的device了，这个距离是我们不能控制。所以这
时候就有需求做distributed system，当然也有别的好处，disaster recovery 等等。
虽然抢股票和抢车票都需要机器和网络，但抢法是不一样。
我看最后的结果是老魏没赢，德霸也没输，因为各找服务器后，发现离的太远，client
服务器又太少，push不到这6，7M/s的throughput来。
CPU |
|
T********i
发帖数: 2416 | 33 其实数据库可以就是一个book keeping功能。就要他的ACID特性就好了。
退票和抢票一样，都要先经过抢票机。抢票机先更新状态，然后送到数据库。数据库
ACK，退票成功。
查询其实是多个抢票机的hotstandby完成。无限scalable。multicast消息更新状态，
unicast recovery。都是现成的架构。
查询可能会有微秒级别的延迟。但是因为退票很少。即使有延迟，也是查询有票结果抢
不到，很正常。查询就是个pre filter。
这东西，和其他的大型网购网站一样，都是message based。message based system是
唯一靠谱的东西。这里大多数人都意识不到。 |
|
T********i
发帖数: 2416 | 34 coroutine和iterator根本就是两个概念。coroutine有自己的stack，yield以后也要有
context switch，iterator不一定。
基于coroutine可以有multi-task和scheduler。因此coroutine yield以后，可以直接
回到scheduler，执行权落在那一行程序是由scheduler决定，不一定是确定的。
因此coroutine和thread很像。但是就是yield的含义不一样。我不确定std::thread实
现coroutine是不是一个好主意？因为为了能够做到兼容，因为thread多任务不需要
yield也能保证响应，但是coroutine必须yield，因此为了保证兼容性长任务要插入
yield才能保证响应，但是会带来额外的负担。
goroutine这种就是coroutine，context switch只需要切换stack和register，不需要
flush cache，switch TLB，security check，这些都是微秒级别的操作。而且内置
scheduler
，还要在I/O函数外面包上w... 阅读全帖 |
|
h**********c
发帖数: 4120 | 35 这样，请算一下从公元0到3000年到每一个周末月末重合的微秒值，
因为java program首先提供的代码（verifiable),而且python的实现基本和java
gregoriancalendar calss 里的代码一样。
所以我们提高一下gorgeousness |
|
h**********c
发帖数: 4120 | 36 这样，请算一下从公元0到3000年到每一个周末月末重合的微秒值，
因为java program首先提供的代码（verifiable),而且python的实现基本和java
gregoriancalendar calss 里的代码一样。
所以我们提高一下gorgeousness |
|
T********i
发帖数: 2416 | 37 回复你一下，其他那些烂人俺都懒的理。
俺的第一张注册交易员执照(Series 7)是2003拿到的，紧接着是63, 55, 3。这方面这
个版面还真找不到比我懂的。
首先，区块链根本解决不了货币超发。除非你不相信合法货币区相信比特币或者马勒戈
币。那样俺们根本没有讨论的必要。即使比特币，也解决不了货币超发的问题，那东西
最小单位能split到1亿分之一，还能不断地无监管操纵市场一茬茬割韭菜。
其次，完全的去中心化交易用什么交易？again，你要用比特币或者马勒戈币，咱俩也
不用讨论了。你要是用任何其他物理实体，比如美金人民币？谁能证明你有那么多钱？
你还是要有第三方给你背书。那个第三方，不管你叫什么，就是券商。
第三，市场没有监管，操纵起来太容易。这是美国20-30年代就已经玩烂了的招数。被
监管的市场一目了然，bid/ask两个梯子，微秒级别交易。你有啥信不着的？
第四，法律上承认的，可追溯，就是两个私钥互相签名。任何技术都能做。凭啥非要通
过区块链？脱裤子放屁非要全球百万机器给你证明？你现在在线买股票需要区块链证明
么？你害怕了么？ |
|
T********i
发帖数: 2416 | 38 回复你一下，其他那些烂人俺都懒的理。
俺的第一张注册交易员执照(Series 7)是2003拿到的，紧接着是63, 55, 3。这方面这
个版面还真找不到比我懂的。
首先，区块链根本解决不了货币超发。除非你不相信合法货币区相信比特币或者马勒戈
币。那样俺们根本没有讨论的必要。即使比特币，也解决不了货币超发的问题，那东西
最小单位能split到1亿分之一，还能不断地无监管操纵市场一茬茬割韭菜。
其次，完全的去中心化交易用什么交易？again，你要用比特币或者马勒戈币，咱俩也
不用讨论了。你要是用任何其他物理实体，比如美金人民币？谁能证明你有那么多钱？
你还是要有第三方给你背书。那个第三方，不管你叫什么，就是券商。
第三，市场没有监管，操纵起来太容易。这是美国20-30年代就已经玩烂了的招数。被
监管的市场一目了然，bid/ask两个梯子，微秒级别交易。你有啥信不着的？
第四，法律上承认的，可追溯，就是两个私钥互相签名。任何技术都能做。凭啥非要通
过区块链？脱裤子放屁非要全球百万机器给你证明？你现在在线买股票需要区块链证明
么？你害怕了么？ |
|
|
b****y
发帖数: 169 | 40 Thank you.
But according to my test, it's also with
precision 0.01second.
There is another possiblility on SunOS:
gethrvtime(). which does not work on Linux. |
|
l******t
发帖数: 108 | 41
it's gethrtime()
hr means high resolution
someone tell me that if you run your program using
'ptime your_program'
then the timing is the process time |
|
|
P***y
发帖数: 2885 | 43 LightWeight Process (LWP) is thread. A thread is owned by one process, while
the same process can own several different threads at the same time. Threads
share all the resources the process owns. Traditional process has only one
single thread (Indeed it has no concept of thread). Later Unix has the concept
of thread, especially in Solaris.
Process represents the resource ownership relation at OS level as a whole.
Thread represnts the manipulation of resources at the process level. |
|
t****o
发帖数: 181 | 44 【 以下文字转载自 Programming 讨论区 】
发信人: tookoo (tookoo), 信区: Programming
标 题: Linux/Unix下时间的精度
发信站: BBS 未名空间站 (Sun Oct 9 20:51:38 2005), 站内
发信人: tookoo (tookoo), 信区: Linux
标 题: Linux/Unix下时间的精度
发信站: BBS 未名空间站 (Sun Oct 9 20:51:07 2005), 转信
Linux下面的C编程，
想计算一段程序的执行时间，
我现在用time()来取时间，
它的精度太差了，
只能精确到秒，
有什么函数可以取到更高的时间精度吗？
譬如，微秒，毫秒什么的，
谢谢。 |
|
j*****g
发帖数: 980 | 45 use QueryPerformanceCounter. |
|
S***n
发帖数: 330 | 46 揭密：“2012末日流言”中的真实成分(组图) 网易
2012年世界末日作为谈资，在新年伊始被讨论地越发热烈。为了打消人们的顾虑，一时
间关于2012的辟谣铺天盖地。当已经确定这末日预言并不靠谱后，我们不妨再认真的分
析一下这些末日流言，看看这些流言中到底有多少真实和科学的成分。
2012流言的根本玛雅历法的确很准
2012年12月21日的末日流言始于现代人对古玛雅人的历法循环结束的误解，在电影《
2012》使得这误解加深后，无数的专家都指出了玛雅历法与世界末日之间没有直接证据
相联。事实上除去末日预言，玛雅人的历法是十分精准的，误差足以和现代科技所观测
的结果媲美。
玛雅历法以精确著称，计算出的太阳历法仅与现代人测算的相差0.0002日。
玛雅历法很精准，5000年才会误差一天
根据玛雅文化学者、美国德克萨斯大学奥斯汀分校教授David Stuart的研究：玛雅文明
共有三种历法，分别用来祭祀、耕种和记录历史。虽然用处不同但玛雅历法的准确性却
是公认的。指导祭祀工作的历法，规定260天是一年。指导耕种的是太阳历法，和季节
轮替、时令节气相对应，规定365天是一年。对于太阳历法，玛雅人... 阅读全帖 |
|
发帖数: 1 | 47 从北极星方向往下看，地球是逆时针自转的，这个自转方向与地球公转方向大致相同（
有约23.5°的夹角），而地球公转与太阳的自转、其它七大行星及绝大多数矮行星、太
阳系小天体的公转方向也几乎相同，这些天体基本上都是在一个近似盘面内朝同一个方
向运转。比较另类的是长周期彗星，它们的公转方向与太阳系主流的方向不一定相同。
地球自转角动量中的绝大部分与整个太阳系的角动量来源相同，据信是来源于当初形成
太阳系的星云的原始角动量，它导致了大家都朝同一个方向转。
但是地球自转方向与公转方向（也就是太阳系盘面旋转方向）的夹角，则提示地球自转
角动量还有另外的来源，这个在后面会谈到。
地球自转周期（恒星日）目前为23小时56分2.1秒，且每年延长16微秒。由于地球同时
还在公转，所以以太阳为参照系的周期（太阳日，即我们通常所说的一天）为24小时整
（86400秒）。
地球自转轴像陀螺一样，还略有摆动，其根源在于其它天体引力对地球的影响。大的摆
动称为岁差，小的则有章动和极移。相关概念可自行搜索，我就不详细介绍了。 |
|
a*q
发帖数: 2109 | 48 时间尺度不一样吧。分子扩散造成的涨落都在微秒到毫秒级的，细胞自己的运动可以很
容易分辨出来。 |
|
a*q
发帖数: 2109 | 49 时间尺度不一样吧。分子扩散造成的涨落都在微秒到毫秒级的，细胞自己的运动可以很
容易分辨出来。 |
|
c****r
发帖数: 576 | 50 非线性复杂巨系统当然有办法分析，只要有数据。理论不是问题，计算也不是问题，生
物的问题就在于数据无法收集。如果说生物体内的一举一动都能记录下来，小到分子，
短到微秒级或更短，那搞清机理还很困难吗？ |
|
