关注

Ubuntu自带的numpy/scipy是过不了测试的……Debian就从来不出这种问题……

要不是各种闭源软件只默认保证支持rhel和ubuntu,谁用ubuntu啊………

还好有装完每个python包跑一遍测试的习惯……虽然好像并不是什么严重的问题,但要是因为这种原因在奇怪的地方卡住就太……

一个发行版能做成这样也真是惊人

我记得archlinux都不至于自带的包跑不通自带的测试

然而rhel是2.28的glibc……我一点都不想一装系统就配全局jemalloc……为什么就不能2.30呢……要是rhel 8是2.30的话,估计我的所有工作系统都会是rhel了……

@vxst 感觉现在能用的只有ubuntu,渗透的太吓人了
for me有显卡闭源驱动强需求,更别提诸如tensorflow这种东西也只是ubuntu-friendly,在中国网络环境下可能也就ubuntu可以用,还跟broadcom这类厂商串通,以至于我现在觉得可能Microsoft都比Canonical有良心。。
PS 那个仿unity的gnome是真的难看,装好ubuntu后还是要马上换壳。

@siyuanlau GPU的话服务器级别的支持大概只有Ubuntu和RHEL是Official的,但RHEL没有2.30以上的glibc真的很麻烦,基本上2.30的Glibc对有一堆malloc的程序(大部分动态语言、各种科学库)最多可以直接加速2倍以上,到jemalloc的水平,2.30以下必须插入jemalloc或者别的内存分配器,否则真的就是不能用的......以及如果你想要简单地安装tf stack之类的可以试试pop os,但既然是ubuntu based,里面的包有没有跑过测试再发布恐怕很难保证。archlinux其实可以很方便地安装scipy/tf/torch stack,但一大问题是把archlinux部署集群这种事情......我感觉是给自己找大麻烦;里面的包估计是跑过测试的(?),但所有包搭起来能不能一起用就看运气了。毕竟租一个上百节点的A100集群跑上半个星期,然后一个进程因为奇奇怪怪的原因崩溃了(),那可是......

@siyuanlau 当你搞OI的时候会有学长建议你别用malloc/new,静态分配,速度会有数量级差别;这个就是纯粹的glibc问题,jemalloc / mimalloc的话,就可以随便用了......比如动态线段树之类的东西,换一个分配器,两三倍的速度差别是很正常的

@siyuanlau 毕竟你写一个预分配的数组然后把 a = malloc 变成 a = prealloc_array + prealloc_array_n++,就可以提升几倍速度,很显然说明系统哪里坏掉了(),你能一行写出来的东西为什么设计内存分配器的人会写不出来呢()

登录以加入对话
MtF Party


我打开屋檐看到的是蓝天。
Hinc itur ad astra.