https://github.com/bytemaster/fc_malloc #lowlevel #backend
才想起来 CAS 是 compare-and-swap 非阻塞并行同步 Atomic 操作的意思
才想起来 CAS 是 compare-and-swap 非阻塞并行同步 Atomic 操作的意思
GitHub
GitHub - bytemaster/fc_malloc: Super Fast, Lock-Free, Wait-Free, CAS-free, thread-safe, memory allocator.
Super Fast, Lock-Free, Wait-Free, CAS-free, thread-safe, memory allocator. - GitHub - bytemaster/fc_malloc: Super Fast, Lock-Free, Wait-Free, CAS-free, thread-safe, memory allocator.
https://mrale.ph/blog/2018/02/03/maybe-you-dont-need-rust-to-speed-up-your-js.html#profiling-the-pure-javascript-version #Rust #JS #web #editors #lowlevel
这篇文章讲得真好啊!作者用类似
作者最后的寄语也很好,要让程序员注意 profiler 和使用的算法、不要过度依赖 VM 的优化并且懂得帮助 VM 优化自己的代码; 编译器工程师要知道把优化拿上台面而不是在后台默默试图接受全部代码,真的是大佬的眼界。
这篇文章讲得真好啊!作者用类似
sort(xs, comparator, /*显式指定余参*/false)
、用 UintArray
替代 JS 的 class definition ,把可复用的存储做成一整块 struct 的方法来提升性能,还有很多有意思的地方,写的非常全、耗时折线图(iteration-ms)很多,是 PGO (基于评测优化),即便没打算看的我第一遍也能理解很多。作者最后的寄语也很好,要让程序员注意 profiler 和使用的算法、不要过度依赖 VM 的优化并且懂得帮助 VM 优化自己的代码; 编译器工程师要知道把优化拿上台面而不是在后台默默试图接受全部代码,真的是大佬的眼界。
duangsuse::Echo
http://sargunv.github.io/cakeparse/ https://github.com/h0tk3y/better-parse/ 草, Kotlin 居然还有 cakeparse 这个解析组合子库…… 完事后我也应该把 ParserKt 弄上 awesome list 还好
两个大佬都比我聪明,都用了 Kotlin sequences 和大量的 infix notation ,而且是 LL(*) 的 (regex)tokenizer-parser 架构;并且,我也见到不少和函数式领域有交叉的名词(总之高大上就是了)
CakeParse 的包结构相当复杂,而且还用的是
better-parse 的 Tuple 和 And 用了
的确很厉害,但它们都没做到能弄出(即便还有缺陷的) HanCalc 那样复杂的文法,止于玩具的程度而已。 想写出好东西光靠聪明是不行的…… 还要懂得如何分配自己的聪明 ☹️
一个作为底层为高层服务的库,就应该简单。 应该首先为使用它的东西的目的着想,尽可能少的使用不能使代码变好看的技巧或在API上制造麻烦。
聪明才智都用到设计这种“复用”库上了,如何才能真正在它上面轻松构造和谐优美的应用?
或许这样的代码,单独放到台面上是 A 级;但作为应用程序忠实的仆从,反而大放光华、喧宾夺主,就会毁了所依赖它的应用以及它自己。 写好复用库的关键在于看到它不是单独一个“人”。
顺便: CakeParse 真可爱,它的子解析器调用动词是
#statement #fp #kotlin #ce #lowlevel #dev
CakeParse 的包结构相当复杂,而且还用的是
CachedSequence<TokenInstance>
…… 真不是一般的复杂,尤其是命名上。better-parse 的 Tuple 和 And 用了
codegen(n_max, output)
Gradle task 代码生成,而且它的 (a and b)
还能针对 skip(a)
这种特例创建不同的 tuple ,这种思路我是想不到如何尽可能优化地实现……的确很厉害,但它们都没做到能弄出(即便还有缺陷的) HanCalc 那样复杂的文法,止于玩具的程度而已。 想写出好东西光靠聪明是不行的…… 还要懂得如何分配自己的聪明 ☹️
一个作为底层为高层服务的库,就应该简单。 应该首先为使用它的东西的目的着想,尽可能少的使用不能使代码变好看的技巧或在API上制造麻烦。
聪明才智都用到设计这种“复用”库上了,如何才能真正在它上面轻松构造和谐优美的应用?
或许这样的代码,单独放到台面上是 A 级;但作为应用程序忠实的仆从,反而大放光华、喧宾夺主,就会毁了所依赖它的应用以及它自己。 写好复用库的关键在于看到它不是单独一个“人”。
顺便: CakeParse 真可爱,它的子解析器调用动词是
eat
() , 吃输入 😂 #statement #fp #kotlin #ce #lowlevel #dev
GitHub
ParserKt/examples
Example parsers for the ParserKt library. Contribute to ParserKt/examples development by creating an account on GitHub.