用粘包警察的话来说就是粘包了

祝贵公司能找到合适的人

你只在学校做过玩具吧

实际上很多性能要求很高的分布式系统的共识算法都是自己针对特定情况实现了网络层, 比如 polarfs 利用 dpdk 技术完全没有走内核网络栈, 还有 2019OSDI best paper 的那个 eRPC 就是针对机房优化过的 UDP.

我知道阿里可以走学术实习生, 但是就是压力特别大, 每个月都要看论文和写代码做实验来给你服务的项目组汇报成果, 有时候一个月什么都没有就特别难受.

@guonaihong 你可以先做 wrapper 再慢慢把底层替换, 先把功能实现, 要不容易弃坑.

@guonaihong 用 go 做 libcurl 的 wrapper

好的, 我这就去 zs.

咨询公司

不怕开团的时候来个 GC?

boox max3 用户路过

但是 go 这种"modern"语言居然不支持泛型，所以 cache 也用起来难受。

LRUCache 很简单，可以做到查找更新都是 log(N)复杂度。

@crackhopper 就是要覆盖, 要不你游戏中的小人怎么动呢? CPU 负责游戏逻辑(比如改变小人的这个对象的坐标, 然后显存也会延迟更新) , GPU 只是单纯负责让你在屏幕上看到的效果罢了.

1. 如果你不是写驱动的或写系统的, 你能调用的 API 基本都是在应用层.
2. 编译, 因为是跑在显卡上的, 而显卡不是通用计算设备(CPU), 没法给你解释.
3. CPU 对于周边设备控制大部分都是靠写内存, GPU 也不例外.
4. 实际上显卡渲染的是显存的数据, 而显存的数据在内存也有一份相同的, 显卡定时到内存对应地址拿数据更新, 因此 CPU 上下文切换和显卡没什么关系. 如果没有优化基本就是 while 循环遍历每个对象渲染.

@reus 基本是这样的,但是有些策略, 比如 chunk 划分不应该用定长的, 如果两份相同的数据, 把一份前面加一个字节, 定长的 chunk 就找不到重复的. (你可以搜一下 content defined chunking).

@Sasasu 我觉得 writer 不应该和线程池之间共用 index 之类的概念,因为他们是不同的东西. 我觉得按顺序完成应该由线程池来保证的. 比如线程池内部有两个变量, 一个是递增的给任务分配的任务号, 一个用来判断当前可以执行结束的任务号.