V2EX = way to explore
V2EX 是一个关于分享和探索的地方
现在注册
已注册用户请  登录
V2EX  ›  yankebupt  ›  全部回复第 34 页 / 共 62 页
回复总数  1221
1 ... 30  31  32  33  34  35  36  37  38  39 ... 62  
2018-10-15 22:29:07 +08:00
回复了 OMGZui 创建的主题 全球工单系统 斗鱼的弹幕屏蔽和过滤还是可以夸下的
有的平台比如某牙网页端有精简弹幕模式.
在弹幕多的时候自动根据重要程度精简,优先删抽奖刷屏用或互动 /节奏等重复弹幕,实在不行会按等级排序,保持尽量弹幕量不超过半个屏幕...

早期解决弹幕量的方案是分房间的,大直播间有多个弹幕虚拟房间,平均每一定量的人分在一起,只能看到互相弹幕。要不广播风暴。现在即使每个虚拟房间人数很多了,有各类比赛或活动的时候弹幕服务器还经常卡....卡到其他直播间弹幕延迟 1 分钟的都有...
2018-10-08 17:27:08 +08:00
回复了 zek 创建的主题 硬件 500 以内的降噪耳机,求推荐
@xgfan
1.断线的官翻机一般是左->右链路预算不足,不是手机->左链路预算不足,可以手动补足(比如用能跑部分射频的线短接左右耳触点之类)(虽然这样就完全失去了作为豆的意义,还坑续航)
2.安卓部分机型部分视频 app 会自动延迟画面补足检测到的蓝牙延迟,并不是所有视频都不同步.
2018-10-08 13:18:12 +08:00
回复了 agagega 创建的主题 iOS Twitch 国区下架了?
境内访问某些特定 app 的链接不管是哪个国家地区的链接都会 404 了(SSL enabled 所以不像劫持)...
只能说有 itunes 的 ssl 证书绿锁也并不一定没区别了,很可能同域名的证书但并不相同的服务器...
关于 3 4 5 题
看了一个来源 blackhat.com 的<draft>文档可能是关于某种 heap 实现的,里面这么讲的

首先 1k 以上 128k 以下不属于 fastbin,但也没有用 mmap(应该)
说法貌似是说 free()了之后内存因为不够对齐,并没有立刻交还给 OS,而是原 userdata 头部部分填上了用于遍历 free 列表的前进后退两个指针,同时后面的部分有可能被清空了。
这就导致写 yyy 的时候覆盖了指针...同时导致后面的任意 free 失效...

两点疑问:第一这种 heap 尤其是 free()实现方式会不会很小众...
第二:理论上不 free p3,free p4 的话会不会有可能不会 core?
2018-09-25 22:08:57 +08:00
回复了 leoleoasd 创建的主题 程序员 微信支付这样睿智的 api 定义 也是没谁了
@Guaidaodl @xuanbg CSV 那个还能接受,毕竟外面放了字段说明勉强可以算有用....
序列化图片那个简直.....还不是 UINT 是带符号的 INT....表示太强迫症了...
2018-09-19 22:42:54 +08:00
回复了 mytry 创建的主题 程序员 网易盾自称有 20 年的反垃圾经验,为什么自己却不用呢
别看发这些广告不怎么会被删...
你要是找个小号发一条 "上面这些广告都是钓鱼的,就是结合本站 cookie 钓谁会去点这一类的广告" 的谣言评论保证活不过三分钟账号拜拜...

@ Livid 求放过,让这条回复活过 3 分钟就删了吧,我就那么一说,大家都别往心里去...(at 防打扰加过空格了)
看图最小的 size 才 962bytes...
估计可以排除一些标准格式中光 overhead 就上 K 的压缩 /加密...
2018-09-15 13:21:36 +08:00
回复了 mytry 创建的主题 程序员 不懂 Python 就不能注册 V2EX 吗?
@FrankHB 好吧,现在关于 386 486 时代的记忆有两个版本。
一个版本告诉我说只要用户态锁定非 NMI 中断就行,OS 或各种调度不会动用 NMI 中断的,调用 NMI 中断的家伙不会碰你的上下文所以不用管......
另一个版本告诉我尽管当时 x86 的多任务就 win3.x 那一点,win95 刚出,用户态或者保护模式(dos 都有 app 用到)已经相当复杂了,屏蔽中断什么的早就不能用了.....

...那么该信哪个版本...
2018-09-14 23:43:16 +08:00
回复了 mytry 创建的主题 程序员 不懂 Python 就不能注册 V2EX 吗?
@yksoft1 修个 spectre 就砍了 8%左右性能,这大概是在对用户讲,处理器设计不那么严密是有可能得到 8%性能提升的...
至于当初 486DX 怎么设计的,有没有在安全性上放水,有没有过度追求严密使一些看起来应该很简单的操作实际 cost 极高,有没有因为 虽然不能在安全上过度严密或者放水 /又不能牺牲关键操作的 cost/结果相关的其他某些操作 cost 变高......
这些对于我这个不懂处理器的人...
.
.
.
好像都没有发言权.
期待关于进一步的解释啊......
比如就当时桌面普遍 1 核的情况下,C 语言 inline asm 括号那么粒度级别的锁定中断有没有致命 downside 非要加这么一条指令,对比普通 P1 添加了 mmx 指令集的代价估算当时 486 加了这条指令大概可能付出了多少代价,远小于 mmx,差不多 mmx 还是会远大于 mmx,这条指令有没有相较没设计这条指令的 386/286 系统 cpu 周边各种结构非大改不能容得下的破绽,而且(多谢 wiki 的提示)只解决单指令原子性粒度太小解决不了 ABA 会不会大大限制了该指令可能带来的性能提升导致得不偿失......
.
.
*而且当时的 win 系统和 dos 系统用了什么样的线程调度方式......是基于中断的还是.....而且当时还不像现在一天一个补丁,在保持和 386 兼容的情况下 OS 或 application 是不是真的有效利用了这个指令......
.
.
对于不懂处理器(如果新处理器不懂情有可原的话,特别强调老处理器也不懂)的我来说,满脑子都这些问题。。。
1 ... 30  31  32  33  34  35  36  37  38  39 ... 62  
关于   ·   帮助文档   ·   博客   ·   API   ·   FAQ   ·   实用小工具   ·   2885 人在线   最高记录 6679   ·     Select Language
创意工作者们的社区
World is powered by solitude
VERSION: 3.9.8.5 · 35ms · UTC 13:28 · PVG 21:28 · LAX 06:28 · JFK 09:28
Developed with CodeLauncher
♥ Do have faith in what you're doing.