赵海平与张宏波谈编程语言

本文整理自字节跳动 Web Infra 团队与 稀土掘金技术社区 合办的 大咖面对面 活动,本期嘉宾邀请到了 ReScript 作者张宏波,与字节跳动资深架构师、HipHop for PHP 作者赵海平。正文内容有删减。

编程语言学到什么程度才算掌握?

张宏波:一般来说一门语言,它的本质就是提供一些 API 和运行时,让你可以在之上做一些事情。比如说 Objective-C 你可以写 mobile ,另外一个,它是给你提供一种抽象机制,它可以让你做模块化的编程。

对 JavaScript 来说,它的最大的优点就是你的无处不在。但这个语言它本身它设计的时候是比较草率,一开始设计的时候不是都说是一周设计出来的,所以它从抽象的这种程度来说并不是设计一个非常完美的语言。所以接下来这十几年都在给这语言打补丁。

有一本书叫 JavaScript The Good Parts,其实我觉得像学习 JavaScript 这种语言的话,你只要学习它的 Good Parts, 那个 Bad Parts 你就可以忽略掉,或者说只有等你真正需要的时候,才去了解为什么。而且现在因为有了 TypeScript,很多 Bad Parts 你都可以避免掉。所以你只要学对应你有用的抽象就好,就不要去 focus 在一些犄角旮旯里面去。

如果你需要表达某种抽象机制的话,学经典的设计模式就可以了。就不用纠结在 JavaScript 语言本身,比如说最早的 JavaScript 他有 prototype chain 那个链,是一个 proto 属性,那些很细节的东西,我觉得不需要去纠结。

PHP 的未来在哪里?

赵海平:我觉得对于一个语言来说,就像我想去了解这个博客一样,一定要去了解它的来龙去脉,了解它的 context。我们了解 PHP,也是需要了解它的来龙去脉,了解它的 context ,你们要知道那个 PHP 那个它产生的那个年代是上个世纪末的时候,恰好那个时候 web server 如雨后春笋一样子,出现了很多的这个 WebSite ,互联网才开始出现,那是一个很激动人心的时刻。与此同时,所有的东西都非常的原始。我不知道抱怨 PHP 不好的人,他们有没有听过一个词叫 LAMP, 这个词很关键很重要。这个 LAMP 是什么?英语里面这个词叫灯,但实际上它是 Linux, Apache、MySql、PHP 四个的缩写,LAMP 是 fundamental software for Internet。

这个叫鼻祖,你明白了吗?你现在抱怨雅虎做多么的不好,对不起,雅虎是 Internet 的鼻祖。那你说他为什么不改呢?是因为我们有太多的东西依附他,依靠他,去改的话牵一发动全身。

所以实际上,不是说负责 PHP 的人看不到这些缺点,你可以去敲她的门说,听着,我告诉你 PHP 这些地方不好,但是我都知道,但是我改不了好吧,所以这要去理解和包容。你要去理解现在发生了什么,你要去 understand 说 PHP 它是怎么来的?然后它为什么有今天这样的一个状况?然后其实有很多的时候,甚至对每一个 feature 你觉得这个东西设计得好奇怪,好莫名其妙,你就要去读他的历史,为什么会是这样子的?你就会发现有可能就有一个很有趣的故事。

所以这就是我想说的,你对编程语言有多少的爱,你的包容心就会有多强。所以说看到一些不好事情的时候,最后反而变成一个很有乐趣的事情,其实有很多的故事。所以说我不反对任何的说 PHP 不好的一些评语,确实还有很多的设计是不好的。但是与此同时我又能够理解他,我又知道他为什么不好。

PHP 的缺点,我举一个可能大家诟病最多的就是它有很多的所谓的 semantics 语义,它定义很模糊。比如说这个 false,很多的 value==false 这个怎么去解释?这个除非你要去查那个表,否则的话你自己是猜不出来的。

这种设计,它就所谓的比较 hacky,没有那个 Java 那么 formal 。所以我有时候建议,如果你去学校学一个语言的话,可能你应该去学 Java ,为什么呢?因为 Java 它的设计非常 formal 、正规,非常的 canonical ,canonical 就是很正规军、正规化,然后它有很多的东西是来龙去脉,很有道理的。然后 PHP 的很多的设计,有一些随意性,有一些 on the fly ,比如我今天在这写的时候,就这样定义,结果一下子就错了好多年。

所以如果你要问我 PHP 哪里不好的话,你到网上去一搜,你可以看得到很多这样子的 example。但是就像你刚刚说的那一句话,我觉得我们原来在 Facebook 的时候,大家一边在抱怨 PHP 不好,一边迅速的把这件事情给做完了。明白我说的意思吗?PHP 写东西实际上是很快的,因为他很 hacky 所以说他可以很快的把这个网页攒出来。

Facebook 没有那么在意代码一定要写得非常的完美,为什么呢?是因为当时大家也不知道网站应该建成什么样子,也许第二天代码就被删掉重新写了,所以你去过度的 polish 打磨代码,有的时候反而还不如快速写完,叫所谓快速迭代的过程。

所以 PHP 就跟 Facebook (当时的)研发的模式恰好很匹配,大家也没有那么强的抱怨。但是如果换另外一个公司,你很在意那个代码的这个稳定性和持续性。比如说你是一个搞金融的公司,你很在意代码的可维护性,那可能 PHP 就不是一个好的语言。

Golang 的精华和糟粕

张宏波:其实我用过一些功能,但我不是特别精通,我觉得 Golang 还是一个不错的语言。

比如它的 interface define,据我所知,是第一个主流语言把 structuraltyping 用在工业语言当中,当然其实很多学术语言已经有了。然后他的编译很快,我也非常赞同,编译速度是很重要的。对我来说,Golang 比较缺失的就两块,一个是泛型,但是现在泛型已经加上去了。然后另外一块,我觉得现代语言都应该有代数数据类型和模式匹配。但是 Golang 很遗憾,Golang 作为一个新生语还是没有引入,所以我觉得也是比较遗憾的。

赵海平:对,我觉得对,因为宏波是那个学语言出身的,所以说这个观点都是这个带有强烈的这个 academic (学术)的特点。我说一下 industrial(工业)的观点,互补一下。

Golang 我不知道为什么,说糟粕、精华本身带有强烈的感情色彩。然后我觉得也要像 PHP 一样去理解和了解它的来龙去脉:为什么 Google 要去做 Golang 呢?是因为我们在这个过去的五到十年里面,就发现了实际上绝大多数的公司在写什么呢?在写分布式计算。特别常见的情况是我调你、你调它,它调它。你们知道微服务为什么现在这么 popular 因为现在就是这样子,团队大了之后拆分 engineering task 拆分完了之后,我就要 RPC 调用对吧?所以说这个变成了这个这个很多的 application 就变成了所谓的 IOintensive 的这种形式,就是他不是一个简单的计算,他可能也许跟 20 年前的话,很多的软件都是在做大量的计算对吧,没有太多的 RPC 因为都在一个机器上进行。

后来这拆分了之后,计算的比重相对来说就没有那么多了,更多的是 IO,那么 IO 的话,问题就来了,你的线程模型是什么?好吧,那 Java 说让我来解决这个问题,Java 说我们就有就 thread 对吧。后来结果发现 threadJava 那个 thread does't work 就不行,给你 50 个 thread 是 OK 的,给你 1000 个 threadJava 那个就不要跑了,这个速度太慢了。所以的话大家在沿着这个 IO 如何让 IOintensive 的 application 跑的好,然后就有很多的想法和思想出来。

然后最后就发现了。天,原来我们一定要用比如说 epoll 这种模型,要搞 user thread ,相当于在 user space 里面用户的这个轻量级的这种 thread 来解决 IO 的问题。Go 就是迎合这个趋势。那我想让其他的人都能够很快的去跳到这个模型上,所以他才把 goroutine (协程)这个概念变成了 first classcitizen ,所以其实人家的本意是在这里。

当然你可以抱怨 Go 有很多的不好的地方,你如果问我,我可能会挑他的 error handing 做的不太好,他没有 exception ,我写 C++ 的话,我觉得 exception 还是很有用的,让很多的那个代码变得很整洁,那 Go 的话就不行,一定要 return 一个 error 。

那这个也不是说错误,这个程序语言就跟这个人生一样,只有选择没有对错。千万不要一棒子打死人家这个选择,天哪你没有 exception 那你就是错的。只是人家这样选择的目的是因为 exception 是一个性能损耗点,那我要快,为了极致的性能,对不起你们所有写 Go 语言的人,你们自己累一点,你们自己去 check 一下那个 return value ,就不要说太简单了,所以这就是一个取舍。

所以一个 tradeoff,你可以不同意这个取舍。但是没办法,这个语言是人家发明的,人家帮你做了一个决定,所以说你去理解了人家 decision 背后的为什么之后,可能就会心平气和很多。你不能够去说什么精华或者糟粕,这么多人一起的集体的创造的一个智慧的结晶,他不太可能有糟粕在里面,只是会有选择,可能是你不喜欢的选择这个是完全有可能。

WebAssembly

张宏波:业界有一个错误的观点, WebAssembly 可以让各种语言以接近原生的速度来跑,这个是不对的。因为你只能说对底层语言 C++ 或者它编译出来的部分,是可以跑得很快的。但是你说 JavaScript 或者 PHP 理论上也是可以编译到 WebAssembly 的,但它照样是很慢的,因为它的速度快与慢是由于语言的特性决定的。不是说你有了 WebAssembly ,它就突然就变快了。

然后 WebAssembly 它现在是有两种模式的,一种是跟 Web 平台没有关系,他只是作为一个通用的 IR(中间语言) 你任何语言都可以编到这个 IR 以后,你可以在云端也可以计算,然后它比传统的 IR 有个好处,首先它是一个跨平台的,编译成 WebAssembly 之后就可以扔到任何一个操作系统上跑。另外一个,它设计的初衷是有安全考虑的,它可以很快做安全的校正,然后可以提供一个很好的 sandbox 这是在后端的使用。但前端主要是,它可以把一些计算比较复杂的应用那个移植到 C++,然后把它编译成 WebAssembly 然后再进行调用。比如说一些传统的编码解码这些方面。

现在用的比较多的成功的案例是把一些老的 C++ 程序搬到 Web 平台上。最近的一个比较成功的案例,Adobe 的 photoshop 应该是用 C++ 代码写的,我可以把很多已有的代码直接通过一些这个新的技术把它编到你的 Web 平台。这样你可以把一些老的应用提供给更多的用户。

这是 WebAssembly 的两种使用方式。回到 ReScript 和 PHP,因为 ReScript 是一门静态语言,它是可以编译到 WebAssembly 的,而且调用是可以走通的,已经有人试过了。像 PHP 或者 JavaScript 这种特别动态的语言,目前来说,即使把它变到 WebAssembly 里,性能是得不到提升的,你需要把它的很多语言特性给裁掉,像 TypeScript 有人做了一个子集,做成了一个 AssemblyScript ,它是非常非常小的子集,然后你才可以把它编译成有效的 WebAssembly。所以 WebAssembly 不是一个让你任何东西突然就变快了。

赵海平:我们语言小组对 WebAssembly 也感兴趣,感兴趣的点其实是在他的 inter-operability 上,我不管你以前的语言是什么,这个编译完了之后,然后一下就可以这个相互调用了。这个是我们现在在看的点,但是才刚刚开始看,理解并没有那么深刻。其实但是我觉得这个 WebAssembly 这个事儿挺有意思的,随着到 2021 年,其实就会发现我们有很多种语言了,实际上你看 WebAssembly 也好,LLVM 也好,其实要回答的问题基本上都是怎么样让这么多语言相互之间可以很好的融合,或者说节省 engineering effort ,我觉得这个趋势可能真的还挺好的。

聊聊现在大热的 Rust

赵海平:字节内部其实有很多的人喜欢 Rust,内部的用户群特别大,很多人加入到群里。然后他们会问我喜不喜欢 Rust,我特别谨慎,我特别怕说错话,因为我要说 Rust 好与不好的话,特别怕变成一个站边的问题,所以我保持比较谨慎的态度。但是可能最终我们是要去支持 Rust,毕竟要鼓励大家去尝试一些新的东西。不过,Rust 的优点和缺点其实都是很明显的。在目前看来(2021 年),Rust 的优点的话,毫无疑问比如说它没有 Garbage Collector(垃圾回收机制) ,它是强调 object ownership(所有权),可能写的时候稍微费一些劲,但是在运行的时候没有 Garbage Collection 这个障碍,然后就可以很高效。然后其他比如说像做一些 system program 的话比较安全,优点特别的明显,都非常认可,但是缺点也很明显。比如说这个编译速度比较慢,基础库也不完整,然后这个可能 IDE 的 support 也不是特别的好。然后还有一个是,它不是很好学,learning curve 还是挺高的,你想要搞明白那个 object ownership 可能你还真得要是一个高手,你可能才能够完全彻底的去理解。所以我觉得属于一个我们去跟随着这个社区不断的进步的这么一个状态。

张宏波:我补充一下,Rust 和 ReScript 它有共同的渊源。如果你喜欢 Rust 的话,你也会喜欢 ReScript,因为他们都是从那个 ML(metalanguage) 语言出来的,就是元语言。Rust 最早的编译器是用 OCaml 写的,ReScript 就相当于 Rust 把 GC(前文所指的 Garbage Collection) 给拿掉,你不需要去学那些 lineartypes 那东西确实比较绕。如果你没有 C++ 或者 C 的基础,可能都很难理解。所以如果你喜欢 Rust 的话,你也会喜欢 ReScript,而且 ReScript 因为有了 GC ,模式匹配、用户体验可以做得更好。然后回到最开始的问题,Rust 现在很火,而且生态也在慢慢的建成,但 Rust 客观来说它的门槛是很高,主要是在 linear types ,它的类型已经 leak 到了用户,即使我只是你的 library user (库的使用者),我也必须要了解这个东西怎么回事,门槛还是相对比较高。

编程语言解决的本质问题是什么?

张宏波:编程语言的本质我刚才已经提到了,它就提供两种功能,一种是提供一系列底层的 API, 比如像 GLSL 就 shade language 我可以让你操作 GPU 这是它的一个最本质的东西,因为有了这个平台你能实现自己想要的功能。然后另外一个他提供一种抽象机制,像最早的汇编,它没有 function ,所以它基本上没有任何抽象机制,你很难做大规模的模块化编程。

所以对于你用户来说,首先我要了解他的 API ,像大部分工业语言,其实它的提供的抽象能力是差不多的。比如你学了 C++ ,你再去学 C# 是很快的,因为它的抽象模式基本上是差不多的。但是如果你学一下学术语言,像 haskell 或者那个 prolog 它给你带来一种全新的体验,它会提供另外一种抽象方式。

赵海平:宏波是正儿八经科班出身学语言的,所以一定要听宏波关于这个问题的看法。

如果问我的话,我可能也是更多的从 industrial(工业)的角度去思考语言。我觉得这个问题问的还挺好的,虽然很深刻,但是其实也有它实用的一面。你想想看,其实我们现在所说的语言,它确实可以让我们帮助我们去做很多的事情,那就是说去 instructcomputer 对吧,告诉计算机帮我们做什么事情。

但是实际上有两件事情,目前它做的不是特别的好,或者说还做不到,或者说不在语言的范畴之内,但实际上是值得问这个问题,为什么他不在语言的范畴之内呢?哪两件事情呢?一个就是数据库,database,其实我也是想问宏波这个问题,对于做学术研究的人, database 是一个 camp,programming language(PL)是一个 camp ,然后这两个 camp 的人实际上思考问题的方式, PL 的人更多的是从 CPU 的角度去思考问题, database 的人更多是从 data 的角度去思考问题。彼此都认为自己是可以囊括这个全世界的。

所以说实际上你看语言实际上跟 database 它对接地方,很多的时候并不是说非常非常的完美。所以很多的时候一个语言在访问数据库的时候,很多的有所谓的 data binding ,这个 problem 要解决。有 serialization(序列化)、deserialization(反序列化),有好多类似这样这方面的问题,它并没有把数据库、database 或者 data 的很多东西囊括在语言里面。

当然有这样的尝试,但是貌似这个目前还是两大 camp, database 和 PL。为什么这两个 camp 的人不能在一起,为什么不把两个东西搞在一起?所以你如果能够问这个问题的话,其实可以回答说什么叫语言的本质是什么。

还有一件事情就是分布式计算。目前还没有一个语言说它能够凌驾在众多的机器之上。我去写一个程序,这个程序咔嚓一下,在几千几万个机器上跑。那当然我们有类似的系统,比如说 map-reduce,但是它没有上升到语言这个层面。它没有说我今天字节只需要一个语言就好了,你们都不要去这写这个写那的什么 server 一个 client 一个,就一个语言,我写一个程序下来,然后一下 deploy 到所有不同的机器上跑,这也是一个好问题,为什么语言就不去做这件事情呢?这也是在回答语言的本质的问题,也没有好的答案。

那在今天其实我们去看,这个问题是有意义的。为什么呢?因为我们微服务实际上是一个很大的调用链。一个服务调其他的,其他服务又调更多的服务,它是一个树状的 call tree,它是有 dependency 的,但是还没有一个语言能够把完整的把整个的 call tree 给描述出来,如果真的可以描述出来的话,那 compiler (编译器)就可以去优化这棵树。我怎么样去优化让整个的调用是最 efficient 的,可是语言并没有回答这个问题,现在情况是,留给大家自己去做一些调度也好,或者自己去做一些优化也好,或者用 WebAssembly 让这个不同的微服务之间有一些 inter-operation。

所以我不知道怎么回答这个问题,我的答案是我不知道,因为我也不满意,我也不觉得我充分理解了语言的范畴,这个边界在哪,也许再隔个五年,十年之后语言又被重新定义了,都是有可能的,对吧?任何问这么有意思问题的人都可以去尝试,都可以去创新。

普通业务程序员要参与语言开发吗?

赵海平:因为我不是学语言出身,所以我是当年在 Facebook 被 push 去做这件事情:我们机器不够用了,所以我们必须要优化。然后毫无疑问大家知道 PHP 慢,慢的意思就是消耗 CPU 消耗多,需要的机器比较多,因此大家都想着要去优化 PHP ,所以我是被逼无奈去做的语言,所以至少这是一个途径,被逼着去做语言。

当时我们在美国的语言小组中,大家总是沾沾自喜,因为当时彼此之间流传着一句话:凡是做 compiler 的人,都是最好的的 programmer 。这句话就是有吹牛的地方,但是它也有它有道理的地方。

当你透彻地理解了 compiler 的时候,你在写程序的毫无疑问就很通透。你知道怎么回事了,你知道怎么写是特别 efficient 的,不仅仅是把它给写完了,功能实现了就完了,你一写的话就能够写得让机器也很喜欢,不仅仅是人很喜欢,机器一运行起来速度也很快。所以可能也许了解语言毫无疑问对于对每一个人技术成长是有帮助的,但是它也是一个很高成本的事情,钻到语言里面去学。你们也知道在上学的时候,compiler 那个课可能就是最难通过的一门课,很艰深,你究竟愿意不愿意花这么大的一个 cost 去做这个努力,我倒真觉得不一定。有的时候也还是要随缘一些。我真的有一天我特别想要去学的话,我就去学。但是如果今儿这边闲待着没有什么事情,就逼着自己去学,也不见得就那么有道理。宏波可能是特别的喜欢语言?

张宏波:对我大部分还是认同的。我客观来说,一般人不一辈子可能都不会去设计一门通用语言,或者是设计出来一门大家用的通用语言。但是我觉得,学习语言设计和编译器还是有点用的。首先对于编译器,它有前端和后端,如果你对后端比较了解,那你优化一些底层上的东西是很给力的。拿我个人来说,我对 OCaml 就非常非常熟,我基本上我看到那个 OCaml 的源代码,我就能知道它的那个汇编代码是什么样,那我就知道它的性能是怎么样的。如果你对后端比较了解的话,你去做性能调优是比较有用的。

然后前端其实也有很多有用的地方,像我们在业务中有很多元编程,就像谷歌的 protobuffer 你要去写很多的代码生成,这一块是需要用到编译器前端知识。所以编译器前端、后端也是可以在业务中有使用的价值。而且我想再补充一句,其实现在的编译器的门槛已经不是那么高了。如果你要做后端的话,你有 LVM IR 就不用自己去查汇编的说明,你只要查一些通用的 LVM IR ,生成到 LVM IR 就可以得到机器码了。然后前端有很多通用的 parser generator 让你去 fit ,有很多各种各样的工具可以用,也是很容易就可以上手的,有的时候不需要了解它的理论也是可以用的。

视频回放地址可在公众号对话框回复关键词 编程语言 获取。

b106b31f6ba343f8d31cba79434158a0.png

相关推荐

2024 抖音欢笑中国年(五):Wasm、WebGL 在互动技术中的创新应用

前言随着 Web 前端技术的不断发展,越来越多的新兴技术方案被引入到 Web 开发中,其中 Wasm 和 WebGL 作为前端领域的两大利器,为开发者带来了更多的可能性。本文将结合2024 年抖音欢笑中国年的部分项目,重点介绍如何利用 Wasm 和 WebGL 对目前流行的一些前端互动技术(比如 Lottie、渲染引擎、动画图片等)进行创新和实践,利用 Wasm 和 WebGL 等新技术方案的特性...

字节跳动技术团队官方博客 2万+

2024 抖音欢笑中国年(四):渲染技术实践与探索

作者:陈瑞、欧阳浩铸、王武俊、倪梵云前言抖音在2024年春节期间推出了欢笑中国年系列活动,为用户带来了全新的体验和乐趣。而SAR Creator则为该项目研发工作提供了重要的技术支持。SAR Creator是一款基于 Typescript 的高性能、轻量化的互动解决方案,目前支持了浏览器和跨端框架平台,服务于字节内部的各种互动业务。这些绚烂多彩的互动场景当然也离不开实时渲染技术的支持,因此本文将专...

字节跳动技术团队官方博客 2万+

2024 抖音欢笑中国年(三):编辑器技巧与实践

前言本次春节活动中,我们大部分场景使用内部的 SAR Creator互动方案来实现。SAR Creator 是一款基于 TypeScript 的高性能、轻量化的互动解决方案,目前支持了Web和字节内部跨端框架平台,服务于字节内部的各种互动业务,包括但不限于抖音春节、抖音直播礼物、抖音UG活动等。SAR Creator 编辑器支持了图形化界面,提供了各类完善的系统(光照、动画、脚本等)供用户快速便捷...

字节跳动技术团队官方博客 1万+

2024 抖音欢笑中国年(二):AnnieX互动容器创新玩法解析

本文基于24年抖音春节活动业务背景,介绍了字节跨端容器AnnieX在游戏互动套件上的探索,致力于提升容器在游戏互动场景的优化能力。业务背景AnnieX作为字节一方游戏统一容器,服务字节内部电商、直播、UG等跨端场景业务。在字节一方游戏互动场景,有大量的一方游戏业务对容器有特定的流量、端能力和游戏优化的诉求。因此我们不断深入互动游戏业务特点,为字节游戏提供完善游戏端能力和流量运营能力,同时提供游戏互...

字节跳动技术团队官方博客 1万+

2024 抖音欢笑中国年(一):招财神龙互动技术揭秘

字节跳动旗下的抖音等 App 在 2024 年春节期间推出了欢笑中国年系列活动,在实现增长业务目标的同时,为用户带来了全新的体验和乐趣。「招财神龙」是其中的一个重要玩法。前言本次春节活动,使用到了字节内的主要前端、跨端、互动技术产品。主要涉及:跨端框架提供了首屏直出的方案使其具有较短的首屏时间,能够大大提升业务加载成功率。跨端框架也提供了 Canvas 作为 SAR Creator 等渲染引擎的...

字节跳动技术团队官方博客 1万+

Monorepo 解决方案 — 基于 Bazel 的 Xcode 性能优化实践

背景介绍书接上回《Monorepo 解决方案 — Bazel 在头条 iOS 的实践》,在头条工程切换至 Bazel 构建系统后,为了支持用户使用 Xcode 开发的习惯,我们使用了开源项目 Tulsi 作为生成工具,用于将 Bazel 工程转换为 Xcode 工程。但是在使用的过程中,我们发现了一些问题,其中影响较大的是,Xcode 工程卡顿:对于头条这种大型项目来说,Xcode 卡顿一直是本地...

字节跳动技术团队官方博客 1万+

抖音 ANR 自动归因平台建设实践

背景介绍本文在 2024 年初最新一期『抖音客户端基础技术大揭秘』技术沙龙活动中已做过专题分享,本次将内容重新整理文章进行分享。公众号后台回复技术沙龙可查看沙龙回放及 PPT~抖音作为一个超大型的应用,我们在 ANR 问题治理上面临着很大的挑战。首先对于存量问题的优化,由于缺少有效的归因手段,一些长期的疑难问题一直难以突破解决,例如长期位于 Top 1 的 nativePollOnce 问题。同时...

字节跳动技术团队官方博客 2万+

CVPR 2024 | CAMixerSR 动态注意力分配的超分辨率加速框架

背景随着相关技术和应用的发展,比如超高清屏幕、虚拟现实(VR)等沉浸式体验的增加,用户对超高分辨率图像和视频的需求变得越来越强烈。在这些场景中,图像的质量和清晰度对于提供最佳的用户体验至关重要。超高分辨率不仅能提供更清晰、更真实的视觉效果,还能在一定程度上增强人们的互动和沉浸感,在一些VR场景中我们需要8K甚至16K的才可以满足需求。然而要生成或者处理这些超高分辨率的内容,对算力的要求也是与日增长...

字节跳动技术团队官方博客 1万+

CVPR 2024 | Modular Blind Video Quality Assessment:模块化无参视频质量评估

无参视频质量评估 (Blind Video Quality Assessment,BVQA) 在评估和改善各种视频平台并服务用户的观看体验方面发挥着关键作用。当前基于深度学习的模型主要以下采样/局部块采样的形式分析视频内容,而忽视了实际空域分辨率和时域帧率对视频质量的影响,随着高分辨率和高帧率视频投稿逐渐普及,特别是跨分辨率/帧率视频转码档位画质评估场景中,这种影响变得更加不可忽视。在本文中,我们...

字节跳动技术团队官方博客 1万+

2024 AI & 前端:回首展望,光芒未至,破晓之前!

前言回望 2023 年,ChatGPT 的突然爆火,让 AI 无疑成为最为值得注目的新兴领域之一,我们也一起见证了生成式 AI 的寒武纪大爆发。这一年来,国内外的生成式 AI 、大模型和相关产品以令人眼花缭乱的速度更新迭代,新的创业浪潮风起云涌。在这 AI 浪潮下,也让我们有了新的开发思考,探索着在各个环节中“前端 & AI”的应用场景。勇于探索的前端开发者们已经开始挥舞着 AI 的“魔法...

字节跳动技术团队官方博客 1万+

Kotlin 云端差分缓存技术

本文由字节跳动 Buildinfra 团队出品。在我们的工程上线 Monorepo 全源码后,Kotlin 编译成了整个编译中最耗时的步骤,全源码过程中大量的 BuildCache Miss 导致我们的编译数据落后原来多仓二进制时代很多,且业界没有相关的解决方案。本篇文章我们来具体阐述下 BuildInfra 团队自研的解决方案 - Kotlin 云端差分方案的原理和技术实现。一、Monorepo...

字节跳动技术团队官方博客 1万+

字节跳动基础架构SRE-Copilot获得2023 CCF国际AIOps挑战赛冠军

近日,2023 CCF国际AIOps挑战赛决赛暨“大模型时代的AIOps”研讨会在北京成功举办,活动吸引了来自互联网、运营商、科研院所、高校、软硬件厂商等领域多名专家学者参与,为智能运维的前沿学术研究、落地生产实践打开了新思路。决赛中,从初赛两百多支队伍中脱颖而出的十支入围队伍分别展示了各自的方案,并进行了现场答辩,评审专家从选题方向、创新性、实用性、完整度和实验复现结果等多角度进行了综合评定,最...

字节跳动技术团队官方博客 2万+

字节跳动百万级Metrics Agent性能优化的探索与实践

背景metricserver2 (以下简称Agent)是与字节内场时序数据库 ByteTSD 配套使用的用户指标打点 Agent,用于在物理机粒度收集用户的指标打点数据,在字节内几乎所有的服务节点上均有部署集成,装机量达到百万以上。此外Agent需要负责打点数据的解析、聚合、压缩、协议转换和发送,属于CPU和Mem密集的服务。两者结合,使得Agent在监控全链路服务成本中占比达到70%以上,对Ag...

字节跳动技术团队官方博客 1万+

西瓜视频RenderThread引起的闪退问题攻坚历程

背景影响西瓜之前存在过一类RenderThread闪退,从堆栈上看,全部都是系统so调用,给人的第一印象像是一个系统bug,无从下手。闪退集中在Android 5~6上,表现为打开直播间立即闪退。该问题在2022年占据Native Crash Top5,2023年更是上升到到Top1。因此有必要投入时间和精力再重新审视一下这个问题。在历经多周的源码分析和排查后,逐步明确了问题根因并修复,最终取得了...

字节跳动技术团队官方博客 2万+

字节电商双11 大促容量保障是如何做的?

前言Rhino 简介Rhino是字节自研全链路容量评估产品,致力于构建完整的全链路容量评估解决方案(覆盖:容量预估->资源准备->数据准备->容量验证->监控->分析->决策->处理反馈);围绕容量在稳定性、成本、效率 三方面提供业务全方位基础支撑。Rhino 目前已经成为字节各业务容量评估主流解决方案,并且历年来在业务大型活动稳定性保障中(抖音春节项目、...

字节跳动技术团队官方博客 10万+

使用火山引擎 APMPlus 解决抖音Top 1 Java 崩溃的通用优化方案

背景近3个月,抖音 Android 版面临一个多次触发线上报警的崩溃问题,全量版本和灰度版本的异常数据激增,该问题不仅容易触发报警,更成为了 Java Top 1 崩溃问题,带来巨大困扰,急需攻坚解决。本文展现了具体的分析过程、优化思路和解决方案,同时提供了已集成该方案的实用工具。初步分析多维特征我们以某发版期间数据为例进行分析:机型方面:比较分散,有聚集部分samsung sm-s9180 占比...

字节跳动技术团队官方博客 2万+

用 Addon 增强 Node.js 和 Electron 应用的原生能力

前言Node.js Addon 是 Node.js 中为 JavaScript 环境提供 C/C++ 交互能力的机制。其形态十分类似 Java 的 JNI,都是通过提供一套 C/C++ SDK,用于在 C/C++ 中创建函数方法、进行数据转换,以便 JavaScript / Java 等语言进行调用。这样编写的代码通常叫做 Bindings。此外还有基于 C ABI Calling Convent...

字节跳动技术团队官方博客 2万+

火山引擎 ByteHouse 的增强型数据导入技术实践

作为企业数字化建设的必备要素,易用的数据引擎能帮助企业提升数据使用效率,更好提升数据应用价值,夯实数字化建设基础。数据导入是衡量OLAP引擎性能及易用性的重要标准之一,高效的数据导入能力能够加速数据实时处理和分析的效率。作为一款OLAP引擎,火山引擎云原生数据仓库ByteHouse源于开源ClickHouse,在字节跳动多年打磨下,提供更丰富的能力和更强性能,能为用户带来极速分析体验,支撑实时数据...

字节跳动技术团队官方博客 1万+

打造企业级智能问答系统的秘密:如何使用云数据库 PostgreSQL 版实现向量检索

本文就如何利用火山引擎云数据库 PostgreSQL 版和大语言模型技术(Large Language Model,简称 LLM),实现企业级智能交互式问答系统进行介绍。通过本文,你将会了解交互式问答系统的原理,学习 PostgreSQL 的向量化存储和检索技术,以及大语言模型交互技术等。背景在大数据的浪潮下,众多企业建立了自己的知识库,以便于信息检索和知识查询。然而,随着知识库内容的膨胀,传统的...

字节跳动技术团队官方博客 2万+

抖音大型直播的画质优化实践

面临挑战随着抖音内容生态的不断丰富,越来越多的大型赛事在抖音平台进行直播,世界杯/春晚/亚运会等各项赛事节目引来大量用户观看。卡塔尔世界杯期间,抖音提供的稳定高质直播画面为观众带来了完美的观赛体验,决赛的 PCU 高达 3700W+。不同赛事节目涉及链路众多,且不同赛事之间存在差异,如何保障各链路的画质稳定并进一步提升画质,是一个巨大的挑战。如何应对挑战?画质优化链路大型赛事直播涉及链路较长,不同...

字节跳动技术团队官方博客 2万+

抖音直播新一代BVC编码器正式亮相

面临挑战在直播行业发展如火如荼的今天,用户对视频体验的要求也水涨船高。视频基础体验的关键要素包括清晰度、流畅度、低延迟等,而这些要素的“第一性原理”,就是视频本身的编码效率,也就是压缩率。视频编码是整个技术体系的基座,编码效率的显著提升,能够在同等码率下极大提高画质,从而改善用户体验。视频编码效率的重要性不言而喻,但进一步地提升也并非易事,尤其在直播场景中,对编码速度、延迟、码率控制等方面都有很高...

字节跳动技术团队官方博客 7356

Go Metrics SDK Tag 校验性能优化实践

背景Metrics SDK 是与字节内场时序数据库 ByteTSD 配套的用户指标打点 SDK,在字节内数十万服务中集成,应用广泛,因此 SDK 的性能优化是个重要和持续性的话题。本文主要以 Go Metrics SDK 为例,讲述对打点 API 的 hot-path 优化的实践。用户在使用 SDK API 进行打点时,需要传入指标对应的 Tag:tags:=[]m.T{{Name:"foo...

字节跳动技术团队官方博客 1万+

云上智能驾驶三维重建最佳实践

智能驾驶技术的不断发展,正在改变着我们的出行方式和交通系统。作为其中的一个关键技术,三维重建在智能驾驶系统中起着重要的作用。除去车端本身的感知、重建算法,自动驾驶技术的落地与发展需要庞大的云端重建能力支撑,火山引擎多媒体实验室通过行业领先的自研三维重建技术,结合强大的云平台资源与能力,助力相关技术在云端大规模重建、自动标注、真实感仿真等场景的落地与应用。本文重点介绍火山引擎多媒体实验室三维重建技术...

字节跳动技术团队官方博客 6304

火山引擎实时、低延时拥塞控制算法的优化实践

摘要火山引擎智能拥塞控制算法 VICC(Volcano Intelligent Congestion Control)是一种自适应的拥塞控制算法,旨在解决全球不同网络环境下,不同音视频应用对带宽利用率和延时的差异化要求。它结合了传统拥塞控制算法(如 GCC 和 BBR)的优点,并且能够根据不同的网络条件、业务偏好和码率特征进行自适应调整,包括自适应拥塞响应速度、自适应带宽探测幅度、自适应丢包检测策...

字节跳动技术团队官方博客 6735

veImageX 演进之路:Web 图片加载提速50%

背景说明火山引擎veImageX演进之路主要介绍了veImageX在字节内部从2012年随着字节成长过程中逐步演进的过程,演进中包括V1、V2、V3版本并最终面向行业输出;整个演进过程中包括服务端、客户端、网络库、业务场景与优化等多个角度介绍在图像处理压缩、省成本与体验优化的经验与方案;本篇文章重点介绍在web端演进和提供的能力,图片是 Web 站点中的重要元素,图片体积、格式、分辨率以及渲染方式...

字节跳动技术团队官方博客 6589

自研多模态追踪算法 PICO 为「手柄小型化」找到新思路

作者:张韬、林泽一 、闻超 、赵洋研发背景作为头戴的追踪配件,VR手柄可以通过HMD(头戴显示设备)的inside-out光学追踪定位原理,计算出手柄的空间运动轨迹,同时结合6轴传感器实现6DoF空间定位。与此同时,结合手柄控制器的物理按键、马达反馈、摇杆等,用户还能获得逼真、细腻的触觉反馈,进一步增强虚拟现实人机交互的能力以及沉浸感,这也是目前无手柄方案所难以实现的。目前主流VR手柄的追踪技术方...

字节跳动技术团队官方博客 7812

如何利用播放器节省20%点播成本

点播成本节省的点其实涉及诸多部分,例如:CDN、转码、存储等,而利用播放器降本却是很多客户比较陌生的部分。火山引擎基于内部支撑抖音集团相关业务的实践,播放器恰恰是成本优化中最重要和最为依赖的部分。火山引擎的视频团队做了份数据统计,在一个很经典的视频业务中,我们在2022年至2023年大约1年半的时间里,针对这个业务进行了33次成本优化点,其中13次是播放器主导的优化,其余的有12次也是需要播放器强...

字节跳动技术团队官方博客 6176

火山引擎 ByteHouse:ClickHouse 如何保证海量数据一致性

背景ClickHouse是一个开源的OLAP引擎,不仅被全球开发者广泛使用,在字节各个应用场景中也可以看到它的身影。基于高性能、分布式特点,ClickHouse可以满足大规模数据的分析和查询需求,因此字节研发团队以开源ClickHouse为基础,推出火山引擎云原生数据仓库ByteHouse。在日常工作中,研发人员经常会遇到业务链路过长,导致流程稳定性和数据一致性难保障的问题,这在分布式、跨服务的场...

字节跳动技术团队官方博客 6900

抖音集团都在用的画质评估工具,确定不试试吗?

导读本文从抖音集团内部画质评估体系的建设历程着笔,主要分享了画质评测对于业务的重要性、主要应用场景和内部产品的一些典型实践案例。通过分享业务视角遇到的一些问题和我们的解决思路,希望能抛砖引玉,为遇到类似困扰的伙伴们提供有价值的参考。画质评估体系建设历程为何评测画质如此重要?我们通过线上业务大量实验发现,图片画质优劣对点击率、 停留时长等消费类指标有正相关影响,间接影响用户收益指标。因此,建设一套行...

字节跳动技术团队官方博客 7937

VLDB 2023 | CDSBen: 字节跳动 veDB 数据库存储系统性能测试模型

背景随着业务爆炸式增长与云原生技术的日渐成熟,大量云原生分布式数据库产品如雨后春笋般涌现,其中一部分主打 OLTP 场景的分布式数据库强调的是从计算-存储分离架构获得弹性收益;对于业界各种计算-存储分离架构的数据库而言,怎么用真实的端到端数据库 workload 去 benchmark 其底层存储系统一直存在以下难题:对于数据库专用存储系统,不存在如 fio 一样的“事实标准” benchmark...

字节跳动技术团队官方博客 5895
上一篇: 分布式链路追踪在字节跳动的实践
下一篇: btrace 开源!基于 Systrace 高性能 Trace 工具
 字节跳动技术团队
字节跳动技术团队 企业官方账号 企业官方账号
博客等级 码龄7年 8152粉丝 316原创
评论
成就一亿技术人!
拼手气红包6.0元
还能输入1000个字符
 
 条评论被折叠 查看
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付:10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值