lubit / lubit.github.io

0 stars 0 forks source link

chitchat · tictoc #2

Open utterances-bot opened 2 years ago

utterances-bot commented 2 years ago

chitchat · tictoc

chitchat

https://lubit.github.io/posts/first/

lubit commented 2 years ago

1.程序员掉头发严重 2.程序员是键盘的高频用户 3.为什么没有防止进头发的键盘。

最近清理键盘恶心坏了

lubit commented 2 years ago

带有rebalance功能的共识算法可以说是后端程序员的基本尊严了。 ----2021年底,某大厂还在努力物理hash有感

lubit commented 2 years ago

一句话总结:rust是用把c++的一些精深些的用法固化为常用语法的更现代更亲和的编译语言。

lubit commented 2 years ago

昨天把有线HHKB改成了无线HHKB,对抗熵增从清理桌面线路开始。

lubit commented 2 years ago

《明朝事儿》最后写:“所有的错误,不管你读了多少史,你该犯的错,一样都不会少。因为人性使然。"
靠很多很多机制来保障一些问题。 却很少去优化一些流程让人少面对这些问题,算是给人性增添更多考验

lubit commented 2 years ago

年龄越大越能感觉到知识总结和沉淀的重要性,之前工作做了些什么都快忘差不多了。

lubit commented 2 years ago

审美的真实,不在时尚圈和舆论的引导,而在色情网站的浏览点击趋势上。 工作的真实,不在平时的汇报和组织关系中,而在下一份工作的面试中。。

lubit commented 2 years ago

“简单说,缺点就像大便一样。看到自己的大便觉得还好,但看到别人的大便就难以忍受了。” 原作者:蔡智恒 《阿尼玛》

lubit commented 2 years ago

最近一年学到了很多的方法论,中规中矩步坦结合的解决问题的能力提升了, 但是于此也失去了创新能力。 最明显的17年最成功的结算可能会因为对标/学习了凤巢的慧宝就陷入泥潭了。

lubit commented 2 years ago

早期的计算机内存资源十分宝贵, 有了动态链接。 现在他所消耗的人力/知识资源已经远大于硬件资源了, 非必须硬性条件下可以弃之。

lubit commented 2 years ago

各种行数据库都是通过btree构建引擎为啥效果差距那么大? 各种malloc库都同样是各种分级/缓存为啥差别也那么大?

lubit commented 2 years ago

https://www.ruanyifeng.com/blog/2013/04/processes_and_threads.html 这个对os进程和线程说的很清楚, 协程可以理解为规范化的线程基础上更轻量级的工作单元

lubit commented 2 years ago

之前对云原生一直质疑啊,今天早上观念突然就改变了: 不可变基础设施的内涵已不再局限于方便运维、程序升级和部署的手段,而云原生升华为一种为向应用代码隐藏环境复杂性的手段,是分布式服务得以成为一种可普遍推广的普适架构风格的必要前提。

lubit commented 2 years ago

MT: 向faiss/milvus这种向量化召回服务, 怎么不部署在GPU硬件场景下?

lubit commented 2 years ago

RedisDB主体数据结构 RedisDB主体数据结构

lubit commented 2 years ago

递归 (自顶向下) -> 动态规划(自底向上) 动态规划(状态转移) -> DQN (Q网络&R网络)

lubit commented 2 years ago

redis-server 网络结构 821646471069_ pic

lubit commented 2 years ago

知识体系化总结,存储: OLTP

OLAP

lubit commented 2 years ago

昨天给人解释RTA没讲清楚, 接着RTA简单系统的讲一下互联网广告

0. 问题

首先RTA(RealTimeApi), 是每次投放都去问询广告主本次请求要不要参竞。RTA的产生这里很大的一部分原因主要是广告平台侧数据的缺失而无法解决实时的定向而导致的。比如有这么一个广告主,他希望针对已安装不活跃的用户进行拉活,但是绝大部分的广告平台(排除厂商拥有系统权限之外)都只知道应用是否安装的状态,但是并无法知道应用到底有没有活跃,并且活跃用户到底怎么定义的也是只有广告主才能明确,比如有些定义为一周内曾打开过APP且使用了某个功能的才能叫活跃,那么这个数据就只有广告主有,广告平台是无法提供这样的一种定向的。如果直接使用广告平台的投放能力进行投放定向,是无法满足这样的一种需求的,而使用上传人群包,又无法解决实时用户数据更新的问题(也有些广告主不想将人群包信息同步到广告平台)。所以必须要以实时接口响应的方式进行定向或者出价。这样RTA就产生了。

1. 背景

1.1 广告大体分为两类

内循环(直投广告或者自营广告)整体广告流程的点击率预估和转化率预估以及由此预估计算得到的ECPM竞价排序都由广告系统统一完成 外循环(RTB|ADX广告或者程序化广告)广告主针对每一次的广告请求按ECPM出价,RTB将属于广告系统对点击率以及转化率的预估转移到了广告主的DSP端进行。

1.2 广告主要特征

A-广告Ad的各类特征,包括广告的行业,类别,转化目标,创意素材等(广告主和广告平台都有) U-用户User特征 ,包括个人资料和在广告主侧的状态动作(广告主和广告平台都有,广告主更新) C-媒体和上线文Context特征, (广告平台更多)

总之,不管是内循环还是外循环 都要借助AUC的特征进行精准投放。

2.演进

2.1 内循环

2.2 外循环

有无RTA区别


以上, RTA可以解决内循环中的信息滞后性, 可以解决外循环中的特征数据更新更安全问题。 RTA很优秀但是对广告主的要求也比较高,而有能力搞RTA的广告主可能又会跟媒体和DSP侧搞更先进的联邦学习去了。

lubit commented 2 years ago

从广告产品的售卖灵活程度,就能基本反应广告平台的技术水平。 那些还在支持CPT的产品也就是三流团队的水准

lubit commented 2 years ago

go 的waitgroup处理的很细致, state=count+waiter, sema=信号量 实时检查系统指针的对齐情况,后面把counter和waiter合并为一个64位bit处理,去掉了锁

func (wg *WaitGroup) state() (statep *uint64, semap *uint32) {
    if unsafe.Alignof(wg.state1) == 8 || uintptr(unsafe.Pointer(&wg.state1))%8 == 0 {
        // state1 is 64-bit aligned: nothing to do.
        return &wg.state1, &wg.state2
    } else {
        // state1 is 32-bit aligned but not 64-bit aligned: this means that
        // (&state1)+4 is 64-bit aligned.
        state := (*[3]uint32)(unsafe.Pointer(&wg.state1))
        return (*uint64)(unsafe.Pointer(&state[1])), &state[0]
    }
}

waitgroup

lubit commented 2 years ago

对象池-sync.pool

sync.pool解析  Pool 结构体

dequeue 实现

lubit commented 2 years ago

团队的熵增定律与庞加莱回归

熵近期被互联网圈的一些文章引用特别的广泛,我印象最深刻的是阿西莫夫的科幻小说《最后的问题》,整个小说背景是上亿年之后的人类与超级计算机AC,人类不断在探索宇宙/消耗能量,熵不断在增加正在走向它的最大值。人类也问AC如何抵抗熵增,但是AC一直没有答案“数据不足,无法计算”。 最终是我们的宇宙,随着熵增迈进向死亡的坟墓, 作为小说文章结尾最后两句来了个新转折。 在这里熵增定律让人看上去很绝望,有序到无序居然是科学原理。 但是科学又给出了另一个定理“庞加莱回归” : 宇宙总会回到原来的一个状态,只要时间足够长。 可以拿我稍微魔方来类比,对于不懂他的人打乱他很容易,恢复他却非常困难,把所有的组合随机过一遍大约需要1371亿年, 但是如果你掌握了原理/公式就比较容易。 热寂毁灭还是回归重现,在熵增定律和庞加莱回归两个定理背景下, 只要我们外部做功+引入一定的规则/定理,我们是能够找到我们想要答案的。

规则 -> 专业 -> 领导 魔方有魔方的公式,相应的我们的行业有我们的专业,只有相应的专业能力才能给团队一个正确的目标, 才能带领团队确立正确的方向,而不至于走弯路。

做功 -> 执行 -> 管理 拧魔方相当于做功,是一种执行。 实现目标的这个过程既为管理,使团队更为有效的执行。

一个团队要想 需要有洞察规则/犀领专业的指引,也需要做组织‘如身使臂,如臂使指’有效组织管理

lubit commented 2 years ago

很多名词以人名或者数字起名真的是太有认知/记忆成本了, 像之前跟着瞎扯过的WEB3.0 看名字完全不知道干啥, 概率论里面的一些各种函数起名也那也是一个头疼,特别容易混淆。 可能搞学术和算法等概念的人没有命名规范的概念, 而码农会起名也是一种生产力。

lubit commented 2 years ago

群里一个网友对人性本善的观点 。 “我们的道德观念是历史的产物,小孩有些行为偶然得符合或者不符合道德,是总会发生的事情。说性本善或者本恶,实际上是假设一种超越历史的观念,为其是虚幻的,这事实上已经等于主张一种有神论。“

lubit commented 2 years ago

最近辅导孩子,思考了很多她接下来长期面对的教育到底是个什么东西,如何应对。 我们的教育不仅仅是教育,更是竞争,是分配社会资源的工具,是社会价值观的培养皿。 所以除了鸡娃还得给她找一个安抚自我的地方。

lubit commented 2 years ago

以前的工作和思维方式是问题驱动 , 问题解决了就算胜任自己的工作。 现在需要系统性的驱动自己, 不仅要解决眼下的问题还需要看到以后的路径方向,最好还要能给老板输入。

lubit commented 2 years ago

Q:广告为什么要对CTR/CVR/CTCVR单独建模? A: 因为,我们最终排序的目标,不是只依靠CTCVR,而是CTR,CVR,CTCVR三个指标的融合打分。 首先,CTR肯定是需要单独建模的,因为它影响用户的长期的参与度,也影响未来收益。CTCVR低,不代表用户不喜欢,也可能是因为其他原因(比如没钱,这个很容易建模,拿用户过去消费的金额,与当前商品的价格,一比就能知道)这个时候,如果只按CTCVR排序,只给用户显示那些物美价廉的东西,一来用户审美疲劳,二来也失去了给用户种草的机会。万一哪天用户中彩票了,或者一狠心想剁手了,在你们的app上却不展示合适的商品,岂不是白白浪费了机会。

其次,可能有一些复杂的收费规则,对CTR, CVR, CTCVR三个阶段有不同的计费模式,所以三个阶段都要预估出来,并且尽量准确。

另一个关键是,CTCVR你也预估不准。其实哪个XTR都不可能绝对预估准,因此需要修正。有了CTR,CVR,我修正CTCVR起来,还能多有一些信息可咨利用。

lubit commented 2 years ago

Q:前些年骂惨的程序员着装,就是特别实用的冲锋衣、格子衫、工装裤,被称为直男审美。这些衣服难看么?我觉得也不见得。在西方社会里,这些都是体力劳动者的标配,在美国最流行格子衫的群体是农场牛仔和工人,这是正儿八经的劳动者的服装。

A:时尚业为什么不骂那些穿格子衫的工农阶级?只骂穿格子衫的程序员?因为他们很清楚工农阶级不富裕,他们再怎么忽悠工农阶级也不会去穿西服打领带买昂贵的定制皮鞋。但是程序员有钱,程序员是潜在的新兴贵族,有能力消费,时尚业希望驯化这个富裕的群体,让他们也去消费那些高档男装。

但是计算机行业是个很奇特的行业,这个行业里有一种反叛旧的阶级文化的成分。比如乔布斯从来都是T恤衫牛仔裤运动鞋,而且在苹果公司的广告里经常揶揄讽刺喜欢穿正装的比尔盖茨。

lubit commented 2 years ago

但愿那海风再起,只为那浪花的手,恰似你的温柔 。