w***g
发帖数: 5958 | 1 显而易见，光从技术上来说老魏的套路是最优的。
但是无奈的是实现这个对程序员技术要求太高，
没法铺开了干。我自己觉得可能有这种能力吧，
如果不是走投无路了这种扣鸡毛蒜皮的事情我也
不愿意干。
所以我觉得出路是要实现一个big compiler，
把本来在运行时操统干的事情挪到compiler里面
去干。各种实时性verification在编译时做了。
因为可计算性问题无法验证的，通过给程序加显式
annotation来处理。无非就是一堆小的状态图拼出
一个大的状态图。然后出来一个big binary blob，
烧到板子里面去运行。程序自动分析各种时序，
绝对保证硬实时。然后因为模块化了，各个模块
性能指标一定下，就可以包出去让人干了。
实时和操统，确实是两个有冲突的概念。 |
l*********s
发帖数: 5409 | |
w***g
发帖数: 5958 | 3 不能干。本质上是一样的东西。但是simulink只能做小规模的东西。
用户界面/编程界面决定了simulink处理全系统级别复杂程度的东西，
缺乏很多抽象工具。比如“进程”这个概念。传统OS里其实涵盖了
virtualization, isolation, scheduling等众多方面。做实时系统，
scheduling需要全改，但是isolation肯定还是要的。
然后需要一套系统来做编译时的验证，确保各种实时性的要求和
正确性测试。simulink从名字就能看出来，是偏重于开发和建模
用的。
其实我是说最好要画一个圈，然后让各类码工往里面钻。
【在 l*********s 的大作中提到】
: simulink 能干这个不？
|
T********i
发帖数: 2416 | 4 哪有那么麻烦？硬件才几个核啊？最不济直接编译了上去跑一遍计一下时。一般情况下
毛估估就好了。
这种硬实时，自己不会调度，指望别人帮你调度，不是扯蛋么？
自己会调度，剩下的就都省事了。用啥操作系统都一样。我看把FreeRTOS改改，10000
行以内代码，比啥都好。
说白了，这个问题和操作系统基本没啥关系。
还说什么GPU必须要用操作系统。凭啥啊？都是把NVDA惯的。GPU最适合做成kernel
bypass的了。
关键的是，你要自己调度，就必须bypass kernel。没啥中间状态。这种都不懂的马工
，啥事干不出来？coroutine里都能上spin lock。直接买棺材吧。
最最重要的是，别扯蛋。once 扯蛋, always 扯蛋。 |
c*******v
发帖数: 2599 | 5 几个while，然后一些汇编自己写个yield什么的。
这个可以scale。我参与过好几个新的芯片都这个结构。
每年至少几十M的量出去。
我以前写过ROM里的库。还设计过一些异常处理。
后来是只写算法，代码别人写。
【在 w***g 的大作中提到】
: 显而易见，光从技术上来说老魏的套路是最优的。
: 但是无奈的是实现这个对程序员技术要求太高，
: 没法铺开了干。我自己觉得可能有这种能力吧，
: 如果不是走投无路了这种扣鸡毛蒜皮的事情我也
: 不愿意干。
: 所以我觉得出路是要实现一个big compiler，
: 把本来在运行时操统干的事情挪到compiler里面
: 去干。各种实时性verification在编译时做了。
: 因为可计算性问题无法验证的，通过给程序加显式
: annotation来处理。无非就是一堆小的状态图拼出
|
c*******v
发帖数: 2599 | 6 实时系统关键部分的物理或者需求到最后往往big picture是非常简单的。
或者工程师脑子里达到最高理解之后一个事情的物理过程是很简单的。
掌握这些的人都是卡住位置的人。
需求简单的话，就不需要软件架构的复杂性。
软件架构复杂反而会添乱。对单一任务，买一个general purpose的isolation
以及scheduler。肯定打不过和domain knowledge结合的几个while jump，
以及手写的yield什么的。
例如，一根管脚的电压高了，需要jump到另一个程序模块这件常用的事。
OS一定打不过自己写的C。OS添乱的部分太多了。
归根结底其实还是图灵停机问题。
对程序的逻辑分析是有限度的。
所以对鲁棒性要求极高的系统，
不能追求一般性。
【在 w***g 的大作中提到】
: 不能干。本质上是一样的东西。但是simulink只能做小规模的东西。
: 用户界面/编程界面决定了simulink处理全系统级别复杂程度的东西，
: 缺乏很多抽象工具。比如“进程”这个概念。传统OS里其实涵盖了
: virtualization, isolation, scheduling等众多方面。做实时系统，
: scheduling需要全改，但是isolation肯定还是要的。
: 然后需要一套系统来做编译时的验证，确保各种实时性的要求和
: 正确性测试。simulink从名字就能看出来，是偏重于开发和建模
: 用的。
: 其实我是说最好要画一个圈，然后让各类码工往里面钻。
|
c*******v
发帖数: 2599 | 7 我们是一块程序跑完后把一个管脚电压放高。示波器看执行时间。
10000
【在 T********i 的大作中提到】
: 哪有那么麻烦？硬件才几个核啊？最不济直接编译了上去跑一遍计一下时。一般情况下
: 毛估估就好了。
: 这种硬实时，自己不会调度，指望别人帮你调度，不是扯蛋么？
: 自己会调度，剩下的就都省事了。用啥操作系统都一样。我看把FreeRTOS改改，10000
: 行以内代码，比啥都好。
: 说白了，这个问题和操作系统基本没啥关系。
: 还说什么GPU必须要用操作系统。凭啥啊？都是把NVDA惯的。GPU最适合做成kernel
: bypass的了。
: 关键的是，你要自己调度，就必须bypass kernel。没啥中间状态。这种都不懂的马工
: ，啥事干不出来？coroutine里都能上spin lock。直接买棺材吧。
|
w***g
发帖数: 5958 | 8 lidar, gps, 照相机啥的，每一个都是一个大坑。
我没机械背景，控制那块无法想象。
只能是在一定的抽象之下每个人把自己屁股擦干净。
系统的调度部分可能也用不了10000行。
但是每个模块都罗嗦得不得了，不是一个人能搞定的。
问题不是调度，而是怎么把不同人写的一大堆乱七八糟
的东西纳入一个能够调度的体系。
10000
【在 T********i 的大作中提到】
: 哪有那么麻烦？硬件才几个核啊？最不济直接编译了上去跑一遍计一下时。一般情况下
: 毛估估就好了。
: 这种硬实时，自己不会调度，指望别人帮你调度，不是扯蛋么？
: 自己会调度，剩下的就都省事了。用啥操作系统都一样。我看把FreeRTOS改改，10000
: 行以内代码，比啥都好。
: 说白了，这个问题和操作系统基本没啥关系。
: 还说什么GPU必须要用操作系统。凭啥啊？都是把NVDA惯的。GPU最适合做成kernel
: bypass的了。
: 关键的是，你要自己调度，就必须bypass kernel。没啥中间状态。这种都不懂的马工
: ，啥事干不出来？coroutine里都能上spin lock。直接买棺材吧。
|
x*****2
发帖数: 117 | 9 把不同人写的东西纳入一个可以调度的体系，这不就是广义上的OS了吗？早期的计算机
也没有OS，后来发现像isolation、scheduling什么的每台机器都搞一遍太麻烦，才逐
步形成了现在的OS。在我看来，所谓OS不过是一台机器上的一些公用服务，写起来很费
精力，还一点不能错，所以如果能够只造一遍轮子最好。至于在实现上是通过经典OS的
system call，还是像你主帖中说的compile的时候以硬代码嵌入程序中都是可以的，这
只是实现手段的不同。
：lidar, gps, 照相机啥的，每一个都是一个大坑。
：我没机械背景，控制那块无法想象。 |
g****t
发帖数: 31659 | 10 需求未定的时候把公用服务拿出来单独专门做不划算这是第一。第二要兼顾多客户一定
会牺牲性能。所以新产品往自己撸这个方向偏一些没问题。
: 把不同人写的东西纳入一个可以调度的体系，这不就是广义上的OS了吗？早期的
计算机
: 也没有OS，后来发现像isolation、scheduling什么的每台机器都搞一遍太麻烦
，才逐
: 步形成了现在的OS。在我看来，所谓OS不过是一台机器上的一些公用服务，写起
来很费
: 精力，还一点不能错，所以如果能够只造一遍轮子最好。至于在实现上是通过经
典OS的
: system call，还是像你主帖中说的compile的时候以硬代码嵌入程序中都是可以
的，这
: 只是实现手段的不同。
: ：lidar, gps, 照相机啥的，每一个都是一个大坑。
: ：我没机械背景，控制那块无法想象。
【在 x*****2 的大作中提到】
: 把不同人写的东西纳入一个可以调度的体系，这不就是广义上的OS了吗？早期的计算机
: 也没有OS，后来发现像isolation、scheduling什么的每台机器都搞一遍太麻烦，才逐
: 步形成了现在的OS。在我看来，所谓OS不过是一台机器上的一些公用服务，写起来很费
: 精力，还一点不能错，所以如果能够只造一遍轮子最好。至于在实现上是通过经典OS的
: system call，还是像你主帖中说的compile的时候以硬代码嵌入程序中都是可以的，这
: 只是实现手段的不同。
:
: ：lidar, gps, 照相机啥的，每一个都是一个大坑。
: ：我没机械背景，控制那块无法想象。
|
|
|
s********k
发帖数: 6180 | 11 所以才要每个模块都要隔离，类似microservice，不能整个系统被某个模块给卡死。这
东西最后要设计成比如perception 模块和核心控制系统有类似网络的协议，怎么处理
信息，怎么处理信息获取不到情况，怎么处理信息超时。
【在 w***g 的大作中提到】
: lidar, gps, 照相机啥的，每一个都是一个大坑。
: 我没机械背景，控制那块无法想象。
: 只能是在一定的抽象之下每个人把自己屁股擦干净。
: 系统的调度部分可能也用不了10000行。
: 但是每个模块都罗嗦得不得了，不是一个人能搞定的。
: 问题不是调度，而是怎么把不同人写的一大堆乱七八糟
: 的东西纳入一个能够调度的体系。
:
: 10000
|
g****t
发帖数: 31659 | 12 这些目前可能都定不下来。
核心算法和产品定义没有收敛。
: 所以才要每个模块都要隔离，类似microservice，不能整个系统被某个模块给卡
死。这
: 东西最后要设计成比如perception 模块和核心控制系统有类似网络的协议，怎
么处理
: 信息，怎么处理信息获取不到情况，怎么处理信息超时。
【在 s********k 的大作中提到】
: 所以才要每个模块都要隔离，类似microservice，不能整个系统被某个模块给卡死。这
: 东西最后要设计成比如perception 模块和核心控制系统有类似网络的协议，怎么处理
: 信息，怎么处理信息获取不到情况，怎么处理信息超时。
|
s********k
发帖数: 6180 | 13 所以这行发展其实还很远，现在能把L2.5类似TSLA autopilot做好已经很不错
【在 g****t 的大作中提到】
: 这些目前可能都定不下来。
: 核心算法和产品定义没有收敛。
:
:
: 所以才要每个模块都要隔离，类似microservice，不能整个系统被某个模块给卡
: 死。这
:
: 东西最后要设计成比如perception 模块和核心控制系统有类似网络的协议，怎
: 么处理
:
: 信息，怎么处理信息获取不到情况，怎么处理信息超时。
:
|
g****t
发帖数: 31659 | 14 实际的小问题哪怕解决一点也是很好的进步。
以前tsla有会在两条白线之间振荡的问题。这次更新看录像
好多了。类似这种问题，我觉得才是核心问题。像这种核心的算法，可能就是一点点东
西起作用了。你找到了就是找到了。
这个白线之间振荡，在数学上和调参师傅们碰到的深度学习振荡其实是一样的。师傅
们的诀窍可能谁也不会告诉。
: 所以这行发展其实还很远，现在能把L2.5类似TSLA autopilot做好已经很
不错
【在 s********k 的大作中提到】
: 所以这行发展其实还很远，现在能把L2.5类似TSLA autopilot做好已经很不错
|
g****t
发帖数: 31659 | 15 除了前面一个长贴之外。我怀疑自动驾驶的控制部分最后可能要有感知部分的模型在里
面。
不过这说来话长就不说了。
: 实际的小问题哪怕解决一点也是很好的进步。
: 以前tsla有会在两条白线之间振荡的问题。这次更新看录像
: 好多了。类似这种问题，我觉得才是核心问题。像这种核心的算法，可能就是一
点点东
: 西起作用了。你找到了就是找到了。
: 这个白线之间振荡，在数学上和调参师傅们碰到的深度学习不收敛其实是一样的
。师傅
: 们的诀窍可能谁也不会告诉。
:
【在 g****t 的大作中提到】
: 实际的小问题哪怕解决一点也是很好的进步。
: 以前tsla有会在两条白线之间振荡的问题。这次更新看录像
: 好多了。类似这种问题，我觉得才是核心问题。像这种核心的算法，可能就是一点点东
: 西起作用了。你找到了就是找到了。
: 这个白线之间振荡，在数学上和调参师傅们碰到的深度学习振荡其实是一样的。师傅
: 们的诀窍可能谁也不会告诉。
:
:
: 所以这行发展其实还很远，现在能把L2.5类似TSLA autopilot做好已经很
: 不错
:
|
w***g
发帖数: 5958 | 16 我感觉在公司干，这个也就是解决了jira上一个ticket吧。
算一星期的工作量？
【在 g****t 的大作中提到】
: 实际的小问题哪怕解决一点也是很好的进步。
: 以前tsla有会在两条白线之间振荡的问题。这次更新看录像
: 好多了。类似这种问题，我觉得才是核心问题。像这种核心的算法，可能就是一点点东
: 西起作用了。你找到了就是找到了。
: 这个白线之间振荡，在数学上和调参师傅们碰到的深度学习振荡其实是一样的。师傅
: 们的诀窍可能谁也不会告诉。
:
:
: 所以这行发展其实还很远，现在能把L2.5类似TSLA autopilot做好已经很
: 不错
:
|
g****t
发帖数: 31659 | 17 一星期肯定不行。这是量产的产品。测试可能一星期都不够。
我这么打个比方吧。比如你做人脸识别。训练发现了大的振荡。既然不收敛，那么原理
上可能就是减小步长。然后试一下这批数据这个case修好了。
但是如果是要求一万组人脸识别不同类型的都不会再出现这个问题呢？那可能就要思考
原理，多次试验才行。照
片的角度，明暗，背景等等是不是会有影响？
汽车上最简单的问题，例如汽车的操控步长是有下限的。温度湿度都影响轮胎。下雪天
会不会飞了？等等这些都要考虑。另外上下坡呢？另外从数学原理上来讲。平滑了，减
少了
高频误差。但是低频的bias呢？会不会导致很长时间回不到中线？这对应于深度学习看
着收敛了，不振荡，但收敛的不是最优解。
所以拿goog这些试验品和大批上路的tsla比其实没多少意义。这类问题写文章容易。量
产要处理的不确定性很多很多，难度比prototype高一个或者很多个数量级。
当然那也有可能他家就是多加了个传感器。或者一个非常规的创造性想法。那就可以很
快解决了。
: 我感觉在公司干，这个也就是解决了jira上一个ticket吧。
: 算一星期的工作量？
【在 w***g 的大作中提到】
: 我感觉在公司干，这个也就是解决了jira上一个ticket吧。
: 算一星期的工作量？
|
