原文
大家好,我重构和优化了一下jin.go这里:
我去掉了vibe.d依赖,因为它又慢又大,而且我无法与2版本交朋友.当仅运行1000个vibe纤程时,不仅应用崩溃,甚至图形系统驱动也崩溃一次,这需要重启笔记本电脑.

当前,我用小栈大小的本地流(4kb)解决.
我真很期待photon的稳定性,以恢复支持纤程.如果在标准库中看到它,那真是太棒了.
我不得不丢弃移动语义,因为我无法用闭包.当前,由复制构造器控制队列的引用数.

好消息!经过所有优化后,通道在上述基准测试中显示出令人印象深刻的速度,来在两个流间泵送消息.

import std.datetime.stopwatch;
import std.range;
import std.stdio;
import jin.go;
const long n = 100_000_000;auto threadProducer() {return n.iota;}void main() {auto queue = go!threadProducer;StopWatch sw;sw.start();long sum = 0;foreach (p; queue) {sum += p;}sw.stop();writefln("received %d messages in %d msec sum=%d speed=%d msg/msec", n,sw.peek.total!"msecs", sum, n / sw.peek.total!"msecs");assert(sum == (n * (n - 1) / 2));}

在718毫秒内收到100000000条消息sum=4999999950000000,speed=139275msg/msec
我几乎在goroutines基准测试中赶上了Go:

> go run app.go -release

工作者结果时间
849995000000109.7644毫秒

> dub -quiet -build=release

工作者结果时间
049995000000124毫秒
坏消息.有时结果错误,我不知道为什么.

> dub -quiet -build=release

工作者结果时间
049945005000176毫秒
我使用了原子获取和释放操作,尽管它们在x86上不必,但我希望编译器考虑它们且不要重排指令.但即使有更严格的内存栅,我也没有得到非常稳定的结果.
如果有人能告诉我这里可能原因,我将不胜感激.

这里

并发的put和popFront不能避免队列中的竞争.
单独访问_offset是原子的,但它在put和popFront中的使用点都不是原子的.
这两个函数都如下:
1,原子读偏移
2,干活
3,原子写偏移
如果一个函数完成了1,然后另一个函数完成了1+2+3,则你就会得到一个竞争.
链接两个原子对象并不会按整体原子化这两个,这是典型的互斥错误.