可以把数组换成 Vec 试试看。他会抱怨 container.is_empty()使用了 move 后的数据。
你这个例子没问题是因为 container 是[i32;5]类型是 Copy 的，所以所有权没被吃掉。

x86 微架构层面的性能差别：
https://uops.info/html-instr/IDIV_R64.html
https://uops.info/html-instr/IDIV_R32.html

对于有硬件 idiv 支持的的微架构，延迟和吞吐看起来不受输入数据影响。
感觉区别不算很大吧。
至于能否隐藏延迟还是要看你具体的 workload 情况，自己测测。

delay5s 的实现能给么，你说“delay5s 耗时 5s”，是不是线程 sleep 而不是一直占用 cpu 。

作为逻辑问题不考虑生物知识的话，我个人的回答是每个人对颜色的感受都不相同，他和别人不一样是显然的。
这个解释所需的假设很小，连“大部分人对颜色的感受相同”的假设都不需要。

@biggates 所以解决了吗 我在模拟器上跑的运行时间和你给的运行时间区别还是挺大的

作为对比，去掉* 0.3 的代码，只做类型转换 testData2[i] = testData1[i]，模拟器打印时间是 116627 ，和 0.3f 的版本相比性能提升幅度很合理

esp32-s3 模拟： https://wokwi.com/projects/361855375362930689
0.3 打印的时间是 1891678
0.3f 打印的时间是 166518
性能提高 10 倍

godbolt 反汇编： https://godbolt.org/z/or71efds8

double 乘法还是走的软件模拟，类型转换也是。会先后调用 floatsidf muldf3 truncdfsf2 这三个函数，所以很慢吧。
改成 0.3f 之后，就全是正常指令了，float.s mul.s 这类，不需要调用其他方法。

0.3 改成 0.3f

我用 4800h 版本用了挺久了，还是挺符合自己的需求的（屏幕尺寸，纯 CPU 性能，续航，可更换内存这些），脚垫重新粘了一下，其他都没碰到啥问题。总体感觉很不错，期望质量好点多用几年。

@metalvest 我随便选了这昨天看到的项目的代码文件，https://raw.githubusercontent.com/daafu/sokoban/master/src/game.jai ，用这个工具压缩 https://www.zickty.com/texttogzip/
输入：10574 字节
输出：4140 字节

gzip 再 base64 呗，只要压缩率能抵消掉 base64 增加的那三分之一就行。对于有一定长度的文本内容来说应该很容易。

能量转换了形式，用能量转换所损失的熵换来了展示计算结果的熵。

初学感觉确实不是很推荐，第一语言感觉还是稍微严谨一点，打好根基，这样接下来再学 csapp 很方便。
干点儿自己的小活儿小工具之类的，是非常好的选择，又快又方便传播，作为业余语言非常好。

nircmd monitor off

如果不是身体健康的问题，可以跑跑步，做做手工，尝试做做这种需要稍微长时间投入的事情

熟悉 idea 的话，webstorm 尤其是搞 nodejs 我感觉凭直觉用就可以了，除了语言不同，剩下的环节都没啥区别的

我这儿职位是写内部底层库的，并且对性能有很高要求，实际开发经常需要造非常贴近实际用法的轮子，这时候就需要清晰理解内部的需求和性能特征，造出最合理的轮子。这个过程需要开发人员对同类轮子的实现有深入了解，了解有哪些性能特征需要把控，有哪些优化点，优化的代价是什么 是否可以接受。
所以在面试的时候，我会问一些底层的细节，问问各种略有差别的需求下分析问题给出不同的优化方法，至少要知道那些性能指标值得关注。如果这些关键点都不知道，一旦进来写东西肯定在设计上会出严重的问题。

体前屈算么