Install的时候应该是暴力patch的。
编译的时候我没加过选项,记得默认选项就不错,好像是自动把所有动态lib的目录加进来。
【 在 GoGoRoger 的大作中提到: 】
: cmake不用调gcc?
: 【 在 PGP 的大作中提到: 】
: :
: ....................
Install的时候应该是暴力patch的。
编译的时候我没加过选项,记得默认选项就不错,好像是自动把所有动态lib的目录加进来。
【 在 GoGoRoger 的大作中提到: 】
: cmake不用调gcc?
: 【 在 PGP 的大作中提到: 】
: :
: ....................
我设置的是cmake install rpath,这个也会被改?我发帖之前还专门试了一下。
【 在 libgcc 的大作中提到: 】
: 我就是用的cmake,readelf读出来还是runpath
: 【 在 PGP 的大作中提到: 】
: : 还是cmake好,我用cmake设置的rpath还是rpath,gcc 9
还是cmake好,我用cmake设置的rpath还是rpath,gcc 9
【 在 libgcc 的大作中提到: 】
: 用的gcc7.5,编译的时候默认把-wl,-rpath的逻辑从rpath改成runpath了
: 说是rpath优先级太低,runpath优先级高
: 可tm这个runpath根本就不支持间接链接啊
: ....................
说说命令行哪里不友好了?老老实实像楼上说的用miniconda
conda作为一个包管理器早就超出了python的范畴,上面很多库根本和python无关,相当于把env的概念延伸到了整个工具链,新建一个conda的env里面连python都没有。conda比起其他包管理器把所有东西放到path里的强多了,那些迟早会变成linux的原生包管理器一样,依赖关系又臭又长。intel发布他们的高性能数学运算库都开始用conda了,建一个env装好后就只有一堆c和fortran的头文件和lib,没有python。跨平台安装c和c++系列开源以及闭源工具和库的平台我没有发现比conda更舒服的,最近在写各个平台的CI脚本,shell方面linux和
mac基本统一,如果你用的不是很花哨,windows用git bash也能凑合,但时不时还需要切换到powershell,唯独写到conda的时候最舒服,几个平台的写法完全一样。
【 在 Krank 的大作中提到: 】
: 半小時之內崩潰,不代表我玩了她半小時……
: CONDA有一個GUI,用來啟動各種主要部件,以及管理升級各種包。那個玩意特別容易
: ....................
Conda哪来的核心程序,跟pip一样装完包就扔的东西,conda本身有什么功能能让你把玩半个小时的?
你是说python崩溃?
【 在 Krank 的大作中提到: 】
: 如果空大包安裝以後可以讓你隨便PIP不影響穩定性,那用的人會多很多。
: 可事實上,我安裝空大包之後半小時內,空大核心程序就會崩潰。因為PIP添加和升級了
: ....................
今天第一次关注了一下,光intrinsic就好几百页,intel发展了几十年也没整出这么多,而且很多都是我感觉编译器从高级语言里优化不出来的,比如编译器不可能或很难猜出你需要saturated的计算从而直接生成优化的指令,都得靠自己手写。
另外问一下arm64有没有公认比较好的基础计算库,尤其是针对性的用这些neon指令优化过的?
恩,屎山本身是轻易不会动的,给你在屎山上放几个巧克力也算是有诚意了。
【 在 dpblue 的大作中提到: 】
: 我说的是remove并没有remove,C++20也没有。
: 【 在 PGP 的大作中提到: 】
: ....................
几行的patch没有几个几百行的测试谁敢merge?
【 在 doubleback 的大作中提到: 】
: 前些年我还玩Linux的时候,gtk的字体渲染有一个明显的bug,这个问题早就有人提出来,也有人提了patch(就几行代码,很简单的一个问题),但是开发者一直不merge。当时我只好拿下来从源码编译,这么多年也不知正式fix了没。
: 【 在 ilovecpp 的大作中提到: 】
: : 可能跟项目规模和阶段有关。我提过patch的项目,从fishshell到kde这个规模的,对用户意见的关注度都是比较低的。一百个用户去+1某个issue,开发者也不见得关注。他有自己的节奏和路线。
: ....................
加了几个库函数,erase真的remove了!c++标准库设计者就是脑子有病,都是写程序从来不超过100行的主。
【 在 dpblue 的大作中提到: 】
: 看了下标准,没看懂,是怎么拨乱反正的?我感觉还是没有remove任何东西啊
: 【 在 libgcc 的大作中提到: 】
: ....................
哈哈哈哈,农企在软件方面既没有决心又没有能力。vulkan已经很低层了,按说上面搭什么都可以把显卡性能发挥到极致,但按摩店就是做不到。今年intel的mkl升级后彻底把发挥按摩店cpu性能的路子堵死了,以前给amd留了个后门,现在后门关了。
【 在 libgcc 的大作中提到: 】
: 我去按摩店又yes了?
: ....................
vulkan,vulkan版的fft据benchmark已经打败cufft了。
【 在 ble 的大作中提到: 】
: 可惜局限在N加网卡,就没有个通用点的打通所有计算资源的平台。opencl要死不活,oneapi也不太看好。
: 【 在 fanci 的大作中提到: 】
: ....................
犯法了吧?amd都不敢支持cuda的api
【 在 zszqzzzf 的大作中提到: 】
: 如果你有一个.m文件,要到另一个平台上跑,就会感激这种处理的……
: 【 在 cafitren (挿fit人) 的大作中提到: 】
: ....................
都是刚需,现在的库越来越好用了,几个模版就能自动支持各种类型的嵌套组合,pybind11这种利器直接把所有c++库带进了python时代。
最近出的几个神器,比如magic_enum,PFR,都是include一个头文件不写适配代码就可以对现有类型进行各种骚操作。
【 在 hyperLee 的大作中提到: 】
: 而哪些只是点缀?
: 我来说一个lambda绝对是刚需,不然你得写冗长的functor
: ....................
刚刚被这个坑了,boost新出的json,默认支持所有标准和类似标准类型的无限嵌套,很好。对用户类型的支持是通过ADL查找的,然后QString由于没有namespace特化函数只能放在全局空间,有时候能正确转成json的string,但有时候被转成json array。现在还是没想到不改库文件的解决方案。
【 在 lambdai 的大作中提到: 】
: SFINAE和type_traits更多地时候是让库更不容易误用,接近白名单的做法。感觉不是为了提供更好的抽象...
: 你的类想和iterator兼容,ok,请自己举手,定义这些个member type
: ....................
msbuild不还是命令行吗?
【 在 saynothing 的大作中提到: 】
: 十年前用过cl.exe和link.exe,现在msvc 2013/2017编译,都看不到编译命令。 都改成了msbuild
: 基于一个sdk,要编译各种变种版本,手动创工程嫌麻烦。 还是喜欢命令行那套(cygwin + makefile + 命令),不知道是否行得通。
: ....................
里面讲到了mkl是自己实现的所以numpy+mkl没有这个bug
【 在 ble 的大作中提到: 】
: 你没搞清楚,numpy只是个例子。这个是底层c运行(ucrt.dll)时里面基础的浮点运算函数出错,mkl就不用浮点计算了吗?
: 【 在 PGP 的大作中提到: 】
: ....................
微软用户里用numpy的才几个?而且真正做计算的哪有不会用mkl的?所以这个优先级低是很正常的
被这个bug影响的都是玩票性质的一小撮
【 在 ble 的大作中提到: 】
: fmod这样的基础运算出错,10月20报告,得明年一月底才能发布补丁
: ....................
win对java界面渲染不行,mac下看起来就像原生界面,win下看起来就是异端
所以我只在编译的时候打开虚拟机中win版的神器,其他时间不想碰
【 在 hgoldfish 的大作中提到: 】
: intellij 在各家操作系统底下不是一致的吗?从我旁边的前端同事用 mac,没看出有什么区别啊。
: 【 在 PGP (---) 的大作中提到: 】
: ....................