我只是一个小透明, 主要是 FP16(也比较少),FP32(密集), uint8 很少(transforms 最初需要), 然后就需要大量的累乘和加法了, 因为不同类型的运算耗时也是不同的, 所有只能综合考虑.一般 TOPS 应该是只能做 8 位的定点数运算, 浮点运算需要模拟, 一般 GPU 我感觉都是使用 FLOPS, TOPS 用在于 FPGA, 很少看到混合使用. 另外芯片中不同位长, 不同类型的运算所需要的时间都不相同, 不在同一个标准, 有时候很难定量的去比较实际差异, 你可以 google 搜索一下相关的研究论文.

没有直接的换算关系, 否则就不会出现这么多单位了. 主要看你干什么, 因为不同场景下评估一个芯片的算力使用同一个单位是无法准确对比其真实性能的. 不同类型的任务有时候用的操作类型有时候相差很多, 甚至完全不相干. 在做卷积神经网络训练的时候, 我们做报告都使用 GMACs, 因为主要的就是乘积累加运算.

另外不要在携程中试图依赖确定性的调用顺序, 除非你手动同步, 或者使用链式等待

因为规范并不保证 333, 444, 555 的执行顺序, 它唯一保证的就是 444 总应该在 333 后面, 而 333, 444, 555 的确定性顺序是未定义行为, 我猜想是编译器优化了无返回值的情况, 这样 555 就更快的得到了执行(还没有执行到 444, 当你手动编写了 Promise.resolve()后, 这个执行需要消耗时间, 这个期间, 444 的任务链条可能已经结束了执行, 因此就是你看到的 333, 444, 555, 不过正如楼上所说, 这些对实际开发影响很小. 你如果除了对 what, 还对 why 感兴趣, 也可以自己深入去研究一下

volatile 只是告诉 runtime 执行适合需要插入指令禁止乱序执行和缓存 instance 的引用地址(尽可能每次引用 instance 都需要从内存中去读取最新的值), 你要证明这个其实添麻烦的, 因为本质上是要撞运气, 至于你现在写的这个代码应该是不会存在 partially initialized instance 的, 因为 new DclSingleton()被正常构造完毕前, instance 是不会获得引用的, 除非你的 DclSingleton 是一个需要需要后序初始化的操作.

Java 整个体系没啥大问题, 除了啰嗦了点. 否则也不会成为如今后端的 TOP 1 了, 虽然有历史的进程原因.
1. Servlet 规范是没法抛弃的, 这个本质上就是整个 JAVA 生态的原初理念
2. 字段不应该直接暴露, 这个和有无逻辑毫无关系, 暴露细节违反了面向对象最基础封装特性, 这个几乎没有争议
3. 面向接口编程没啥问题, Java 一些解决方案的复杂化是因为大家都过渡追求复用, 然后过度抽象. 如果你确定一个东西不会更改, 你完全就可以直接 new, 你看你的代码是不是到处都在直接构造 String 这些基本类型. 最佳实践都是人们踩过的坑后慢慢总结出来的, 因此公司项目还是要以规范性为主, 因为你需要和其它人协作, 多人协作一致性是最重要的一条原则.

最快确定一个人是否完整,系统且认真的学习过 JavaScript, 而不是将其当作玩具语言, 到处复制粘贴代码. 面试如果招聘前端, 如果原型都无法解释清楚, 肯定会被我淘汰, 因为这个玩意非常简单, 这个都搞不明白, 说明要么智力有问题, 要么根本没花心思在自己使用的工具上. 实际项目手动使用 prototype 非常少, 但它总是在起作用. 编写兼容库的时候, 会通过补全原型来模拟一些原生方法.

编译器没有获取足够的信息, 并不知道自动给你填充足够的类型.
实在想跳过去可以这么做: ref({} as unknow as ICategoryFormData)

另外我们的项目 Query 和 Command 是分开的, 用了不同的数据库, 大部分时候并不需要复杂的 Join

正常直接使用 EFCore, 有需求的情况下直接在 Context 上直接调用原生 SQL, 我们的项目需要根据场景切换数据库(Oracle/MySql/SQL Server/MongoDB), 而且写 SQL 的时候都会使用 Repository 包一层, 按照实际引用的 Provider 做不同的适配, 如果要追求极致的性能, 我直接用 ADO.ENT 了, 另外简单的项目使用 LinqToDB. Framework 时代用 Dapper 比较多, Core 后基本没用过了

这些哲学问题, 有文字记录以来的贤者都深入思考过, 现在哲学的存在主义也试图回答这个问题. 不同时代, 不同境况的人都试图描绘出自己看到的大象的模样, 就这样争吵了几千年. 存在先于逻辑吗? 也许永远不会有答案, 但对这个问题进行深入思考, 还是有意义的, 至少可用让自己活得没有那么糊涂.

应用层按照功能尽可能的多公开数据, 一个模型就不会有太多 dto, 正常情况下就只会有 CreateEntityDto, UpdateEntityDto 和 EnttityDto, 为了节省带宽按需求获取部分参数, 则在上面包一层 GraphQL, 验证的逻辑安全可以不写到 Dto 上, 而是直接使用 Fluent Validation API 使用代码定义, 而不是总是使用 Atttribute, 即便使用 Atttribute, 也不应该对 Dto 做逻辑校验, 一般只做简单的数据格式校验, 这种情况, 重复写多次 Attribute 并不是什么问题, 另外你也可以给 Dto 分层, 使用继承和泛型组合. C#类型运算太弱了, 几乎等于没有, 没法像 TypeScript 那样领域, TypeScript 的类型运算骚操作太多, 对于 C#这种纯静态语言(不考虑 DLR), 按照 TS 的逻辑写肯定是不大行得通的

你不说语言, 谁知道你用的啥?

@petrichor08 自己编写协议库非常麻烦, 除非你需要长期维护一个底层库, 否则建议直接去看你对应语言的第三方开源库, 从哪里开始研究比较靠谱, 主要是要处理的通讯边界条件太多, 要编写的靠谱非常困难. 我之前也尝试过自己写, 然后发现个人精力有限, 最终还是选择了研究第三方库. C#有很多靠谱的 BACnet 库, 其它语言也应该有. 我主要是一直在尝试订阅模式, 在一些项目中发现 UDP 会击穿整个网络的交换机, 后来很多项目对延迟要求不太高(超过 5s),就直接使用了轮询!

@petrichor08 一部不需要管协议的事情, 找一个你使用的语言的库, 然后将你自己的客户端接入 BACnet 网络, 然后就可以读写其它设备的属性(value 是一个特殊属性), WhoIs 命令发出去喊一声就知道网络有那些设备了. 除非你需要编写解析协议的库, 否则并不需要知道具体报的格式, 如果想要知道报文格式, 直接去看 BACnet 官方协议, 这个协议存在历史非常悠久了. 商业大楼的楼宇控制一般会使用这个协议, 或者 OPC 协议.

@moyechen 我现在的想法是先将整个进程 dump 出来, 然后在使用分析工具找到已加载的字节码, 然后看不能不能反编译字节码

@moyechen 好些, 我先试一试, pyc 文件也被覆盖掉了, 就比较悲催