- 主题:请教个rust基本问题,Rc<RefCell<T>>有啥坏处?
nim 在探索新路。
确实操心。rust 就是一个例子。cpp 程序也经常搞到内存泄露。
不过如果一个语言不支持 closure 的话,不使用回调函数,gc 的必要性就没有那么高了。以前 qbasic 语言,功能很受限,那会儿就没什么人担心内存泄露。
【 在 beep (菜M.喵星耗子) 的大作中提到: 】
: 说实在的不带gc的语言写起来太操心了。。。
--
FROM 110.85.22.*
refcount 没问题的。但 gc 吧,你可以问最近热火的 rust 项目组吧,为什么你们不搞 gc 呢。
【 在 eGust (十年) 的大作中提到: 】
: 不管是 gc 还是 reference count,上个世纪就已经出现在主流语言和技术里了。这都过去20多年了,还从来没思考过到底是为啥有这些东西?
--
FROM 110.85.22.*
nim是咋个玩法?没接触过,有关于此的链接吗?
【 在 hgoldfish (老鱼) 的大作中提到: 】
: nim 在探索新路。
: 确实操心。rust 就是一个例子。cpp 程序也经常搞到内存泄露。
: 不过如果一个语言不支持 closure 的话,不使用回调函数,gc 的必要性就没有那么高了。以前 qbasic 语言,功能很受限,那会儿就没什么人担心内存泄露。
: ...................
--
FROM 123.120.160.*
非常好奇没有gc同时还能保证内存安全同时还不加重心智负担的玩法是啥样
【 在 hgoldfish (老鱼) 的大作中提到: 】
: nim 在探索新路。
: 确实操心。rust 就是一个例子。cpp 程序也经常搞到内存泄露。
: 不过如果一个语言不支持 closure 的话,不使用回调函数,gc 的必要性就没有那么高了。以前 qbasic 语言,功能很受限,那会儿就没什么人担心内存泄露。
: ...................
--
FROM 123.120.160.*
我不懂 c++,但 reference count 的缺点放哪都一样,weak reference 的分析完全交给人肉。手动分配释放内存的话,至少上个世纪就有很成熟的技术,可以追踪内存泄露是在哪里分配的,重复释放的代码也很容易找。如果想追踪循环引用是如何产生的,难度不比实现一个 gc 更简单,反正我是不知道有没有成熟的技术可以用。
至于速度,swift 自然也没慢到哪去;virtual method 也一样有开销,绝大多数情况下都不会产生质的影响。所以还是那句老话,干嘛非要用一个看似更安全的技术,来写一个实际上更糟糕的实现呢?
【 在 beep (菜M.喵星耗子) 的大作中提到: 】
: 我目前的理解是,即使多使用Rc+RefCell,性能也基本会和c++ shared_ptr可比的。现代c++也已经是unique_ptr shared_ptr满天飞了。
: 需求就是要快呀,传统上EDA软件基本都是c++写的,现在用rust我觉得是合理的,据我所知那几个EDA大厂比如s家里面也用很多rust。用golang反而很奇怪。。。
--
修改:eGust FROM 203.211.111.*
FROM 203.211.111.*
EDA里面很少用到shared_ptr啊,核心数据都是ObjPool管理
很多时候还得用mmap自行管理内存页面
这种开发模式下,绝大多数人只是使用指针,不会create/destroy Obj的
【 在 beep (菜M.喵星耗子) 的大作中提到: 】
: 我目前的理解是,即使多使用Rc+RefCell,性能也基本会和c++ shared_ptr可比的。现代c++也已经是unique_ptr shared_ptr满天飞了。
: 需求就是要快呀,传统上EDA软件基本都是c++写的,现在用rust我觉得是合理的,据我所知那几个EDA大厂比如s家里面也用很多rust。用golang反而很奇怪。。。
--
FROM 111.197.236.182
你说的上个世纪就很成熟的手动分配释放内存的技术给业界带来无穷无尽的大窟窿。
所以微软谷歌脸书等等企业拼命用rust重写你说的那些成熟的内存管理技术写出来的代码。
【 在 eGust 的大作中提到: 】
: 我不懂 c++,但 reference count 的缺点放哪都一样,weak reference 的分析完全交给人肉。手动分配释放内存的话,至少上个世纪就有很成熟的技术,可以追踪内存泄露是在哪里分配的,重复释放的代码也很容易找。如果想追踪循环引用是如何产生的,难度不比实现一个 gc 更简单,反正我是不知道有没有成熟的技术可以用。
: 至于速度,swift 自然也没慢到哪去;virtual method 也一样有开销,绝大多数情况下都不会产生质的影响。所以还是那句老话,干嘛非要用一个看似更安全的技术,来写一个实际上更糟糕的实现呢?
:
--
FROM 111.201.129.*
跟我对立的观点,要么是这些厂家大量发展基于 refrence count 的技术,要么写 rust 的时候大量使用 Rc。你看懂我在说什么了么,就开始喷?
【 在 tsa300 (Tele-Superachromat T*) 的大作中提到: 】
: 你说的上个世纪就很成熟的手动分配释放内存的技术给业界带来无穷无尽的大窟窿。
: 所以微软谷歌脸书等等企业拼命用rust重写你说的那些成熟的内存管理技术写出来的代码。
--
FROM 203.211.111.*
这里关键考虑还是性能。
我原来的理解是,EDA这类场景只能从c/c++/rust里面选,这三个的速度基本是可比的。go也算快的,但是典型计算场景下还是会比第一档的语言慢几倍。你所说的swift慢不到哪里去,具体有benchmark可以参考吗?
只要有可能,当然是希望能写有gc的语言啊,但是这不是第一档语言里都没gc嘛。。。。。。c c++ rust 各有各的恶心之处。。
【 在 eGust (十年) 的大作中提到: 】
: 标 题: Re: 请教个rust基本问题,Rc<RefCell<T>>有啥坏处?
: 发信站: 水木社区 (Wed Dec 8 15:55:43 2021), 站内
:
: 我不懂 c++,但 reference count 的缺点放哪都一样,weak reference 的分析完全交给人肉。手动分配释放内存的话,至少上个世纪就有很成熟的技术,可以追踪内存泄露是在哪里分配的,重复释放的代码也很容易找。如果想追踪循环引用是如何产生的,难度不比实现一个 gc 更简单,反正我是不知道有没有成熟的技术可以用。
:
: 至于速度,swift 自然也没慢到哪去;virtual method 也一样有开销,绝大多数情况下都不会产生质的影响。所以还是那句老话,干嘛非要用一个看似更安全的技术,来写一个实际上更糟糕的实现呢?
:
: 【 在 beep (菜M.喵星耗子) 的大作中提到: 】
: : 我目前的理解是,即使多使用Rc+RefCell,性能也基本会和c++ shared_ptr可比的。现代c++也已经是unique_ptr shared_ptr满天飞了。
: : 需求就是要快呀,传统上EDA软件基本都是c++写的,现在用rust我觉得是合理的,据我所知那几个EDA大厂比如s家里面也用很多rust。用golang反而很奇怪。。。
:
:
: --
:
: ※ 修改:·eGust 于 Dec 8 15:59:47 2021 修改本文·[FROM: 203.211.111.*]
: ※ 来源:·水木社区 mysmth.net·[FROM: 203.211.111.*]
--
修改:eGust FROM 203.211.111.*
FROM 123.120.160.*
嗯,rust里面也可以考虑用arena
【 在 jjfz (每天两壶茶) 的大作中提到: 】
: EDA里面很少用到shared_ptr啊,核心数据都是ObjPool管理
: 很多时候还得用mmap自行管理内存页面
: 这种开发模式下,绝大多数人只是使用指针,不会create/destroy Obj的
: ...................
--
FROM 123.120.160.*