w568w 最近的时间轴更新
w568w

w568w

V2EX 第 415660 号会员,加入于 2019-05-26 08:16:51 +08:00
Blessed C:现代 C 生态系统使用指南
分享创造  •  w568w  •  40 天前  •  最后回复来自 icyalala
14
2023 年,有什么原生级性能的跨平台 UI 框架?
  •  4   
    程序员  •  w568w  •  52 天前  •  最后回复来自 layxy
    106
    检测 Xposed 安装、防止应用被劫持的终极解决方案
  •  2   
    Android  •  w568w  •  2022-01-03 18:09:40 PM  •  最后回复来自 knziha
    41
    请问 EMUI 10 上有什么好的应用保活思路吗?
    问与答  •  w568w  •  2020-03-18 20:02:49 PM  •  最后回复来自 MrOange
    18
    w568w 最近回复了
    2 天前
    回复了 AoEiuV020JP 创建的主题 程序员 电脑内存都被谁占了
    @verrickt #79

    事实上关闭 swap 也不能完全防止 thrashing 问题。就像前面说的,swap 的目的是「让匿名页面和文件后备页面具有同等的交换地位,都能够在内存不足时释放」。

    即使禁用了 swap ,当内存高负荷时,系统也会尝试释放内存,只不过它只能释放文件后备页面(例如从磁盘载入内存的代码段、动态链接库、文件系统缓存等):当文件存在脏写时,还是会触发大量写盘;当内存紧缺到即将读取的链接库和文件都要被释放时,还是会导致 thrashing 。

    总之,我觉得楼主的问题还是在于内存不够。Swap 只是一种帮助缓解(也可能加剧) thrashing 的手段,但 16G 内存不能流畅跑需要 32G 的程序,这是任何软件都改变不了的。Swap 最多把「跑不起」变成「勉强跑起」罢了。
    2 天前
    回复了 AoEiuV020JP 创建的主题 程序员 电脑内存都被谁占了
    @luxor

    楼上关于 Overcommit 的问题解释得很清楚了。我可以再总结一下:

    1. 「关闭 pagefile 当然可以提高性能」:关闭 pagefile 和性能无关,只是影响你提交总量的多少;
    2. 「某些应用对已提交内存占用的优化不够,造成实际物理内存占用不高」:正是因为应用会提交更多内存(有的是因为沿袭了 Linux 的习惯,有的纯粹是在设计上难以解决),所以开启 pagefile 才是必须的。否则由于 Windows 的特性,你将连本来的物理内存都不能完全利用;
    3. 「可以减少大量的磁盘读写,延长磁盘的寿命」:一方面,Windows 在交换方面已经很保守了;另一方面,如果出现「大量的磁盘读写」情况,说明平时的工作负载(注意!这里说的是实际的内存使用。仅仅提交很多内存而不使用,并不会产生任何磁盘读写。参考楼上)对内存来说已经不堪重负了,那么升级内存是最佳解决办法,而 pagefile 也能作为一种后备资源来在瞬时高负载时分担一下。关掉 pagefile 属于纯纯的掩耳盗铃、自欺欺人,其结果是工作负载运行不起来了。而且由于第 2 点,就连原本的物理内存都无法完全利用了,百害而无一利。
    2 天前
    回复了 AoEiuV020JP 创建的主题 程序员 电脑内存都被谁占了
    稍微了解一下操作系统原理吧,避免几个误区:

    1. 「已提交」和内存占用没有半毛钱关系,也不是程序「恶意偷内存」。哪怕你的已提交显示 1 TB ,物理内存只有 8 GB ,也完全不能代表你的电脑内存满了或者没满。「已提交」的唯一意义是告诉你「所有应用宣告申请了这么多内存」,但「申请」不等于「用」:很多使用自己的用户空间内存分配器的程序会直接从系统那里「申请」过来一大把内存(甚至比实际物理内存还大),然后慢慢用。真正的内存占用是指程序「用」的部分。这部分你应该通过 Resident Set 或 Working Set 来估算;
    2. 虚拟内存是 Windows 滥用的错误术语之一。虚拟内存本身是操作系统的基本概念,指为每个进程都需要分配一个独立的地址空间,这个地址空间映射到物理内存页面中。你说的这项能关掉的功能应该是指交换空间 / 分页文件( Swap )。
    2. 交换空间关掉并不能让系统在高负载下变快。相反,我不推荐在任何场景下关掉。它的目的是为了让匿名页面和文件后备页面具有同等的交换地位,都能够在内存不足时释放。关掉后,只有后者能释放,所以等于是在高负载下系统能强制释放内存的手段变少了一个,只会让系统更不稳定。
    问题来了,有什么工具刷运营商的 CDN 流量吗
    56 天前
    回复了 w568w 创建的主题 分享创造 Blessed C:现代 C 生态系统使用指南
    @masterclock

    > 这个项目与 awesome-c 、搜索 有什么区别?

    ( 1 ) awesome-c 并非记录了所有库;(2) awesome-c 没有给出任何有关库的详细信息,且其中 80% 的库都是属于「年久失修」的类型,搜索起来非常费时。

    > 如果是精选的,以 C 的生态,必定是 bias 、opinionated 的

    何出此言?

    > 仅仅只是一个条目、一句介绍显得过于单薄了

    是的,所以我在介绍时非常强调对比性。如果列出了多条项目,一定要找到其差异的地方:是否更全面/紧凑?是否兼容特定 C 标准?性能是否有明显差异?是否维护良好?有关这一点,可以在列表中任意查找验证。

    > 同时 OP 应该是专业的 C 程序员,应该在某个领域具有比较深的积累

    「我不是专业的 C 程序员」里的「专业」是指「以写 C 为职业」,不「专业」 != 啥都不会… 要是啥都不了解就来写这种项目,我不是给自己找不痛快嘛。

    至于你说的「某个领域具有比较深的积累」,我做 Linux 内核驱动和嵌入式比较多,不过都不是公开项目。这一点也可以从列表中验证:网络、JSON 解析部分的库改动是最勤快的,因为这一方面我确实了解不深。

    > 否则怎么知道推荐的某个条目是不是这个领域里的常规用例

    谢谢你的建议。正如我反复强调的,目前的评选标准是维护最积极、最流行甚至已成为事实标准(当然还包括可移植性、性能等),我认为这些都是客观的评判方式:如果某个领域最流行的库在 GitHub 上只有几个 star ,很「不常规」的用例反而有几千 star ,或者在 StackOverflow 上根本无人问津,那反倒是一桩怪事了。

    最后,我发到 V 站来自然是为了让更多人看到这一项目,这样才有可能有路过的「这个领域里的」大佬来提出意见,让我有机会修正为你说的「常规用例」。

    这是一个社区共建列表,不是一个个人维护项目。我不明白为什么我被一而再、再而三地要求证明我自己的个人水平或项目的「意义」来为列表背书,因为我的个人水平和列表的质量根本不是一码事。

    如果你认为列表质量低,请直接说明哪一条低、改成什么项目更好;如果你认为有更好的选择,请直接把选择甩到我脸上让我学习,不必拐弯抹角;如果你压根没点进去看过项目,只是看完我的描述就想找个网友来怼一怼,那我也欢迎。虚无缥缈的指责无益于项目的进步。
    56 天前
    回复了 w568w 创建的主题 分享创造 Blessed C:现代 C 生态系统使用指南
    @tool2d #7

    > 现在有了 GPT4 ,需要找啥库问它,十有八九错不了。

    本着谁主张谁举证的原则,请证明这句话。不然全成我一人在说道了,有偏袒自己之嫌。

    如果一定要我举证:(1) GPT-4 不是每个人都在用或者有能力用;(2) 我当然问过这个问题,GPT-4 回复的均是一些年久失修或者在某些 StackOverflow 中回答过的冷门库,反复增加条件好几次才慢吞吞给出 libuv ,而且还是同列在五六项不能用的库之中的。这恰好是我想避免的;(3) 小小滑坡一下,如果 GPT-4 就能解决所有问题,那 GitHub 上所有同类项目都应该不需要存在了。事实是这样吗?我个人从 GPT-4 处获得的回答,有一半都是错误的。

    再强调一次,举证责任不在我。如果你想就这点讨论,请先给出任何一点自己的依据。

    > 小白不会用,指的是新人很少有用 C 语言写项目的

    要么我理解错你的意思,要么你在偷换概念。我们讨论的「小白」就是「学习 C 语言项目的小白」而不是「初次接触编程的小白」吧?怎么这部分人又变成「很少有用 C 语言写项目」呢?

    > 产出和学习周期太长了。都是老人在用 C ,他们写的代码,基准在线,很糟糕的 C 代码项目极少。

    这些是客观事实。我认为,「产出和学习周期太长」的一个(不是全部)重要因素正是 C 语言生态差,各种配套设施杂七杂八得多,而且质量参差不齐。那么提出一个 curated list 我认为是有益的。

    若因此不做,不又陷入「生态差->没人学->生态差」的循环了?而且预想一个完美的庞大「老人」群体(而这部分人很可能没有你说的那么多。看看 GitHub 上 C 库的代码质量就知道了),然后争论他们如何懂,这和项目是否有意义,我认为是关系不大的。总是有人要学习的,我的项目哪怕帮不到别人,能帮到我自己也是好的。
    56 天前
    回复了 w568w 创建的主题 分享创造 Blessed C:现代 C 生态系统使用指南
    @liprais #5 我实在没有理解这句有什么问题,表达了我怎样的自命不凡。烦请高抬贵手指出。总不是指我用 Google 或者自称不专业吧。

    如果你是说「在自己不了解的领域,还好意思挑选出来推荐给别人」的话,我在挑选中参考的都是客观指标( Star 数、维护频次、文档、可移植性、相关搜索数……),尽量不掺杂个人情感;另外,就像我下一句说的,「有的选择可能明显存在我的个人偏见」。事实上这个列表今天在和其他人交流中已经修改很多次了,原先自主主张添加的一些完全不了解的库基本已经轮替一轮。
    56 天前
    回复了 w568w 创建的主题 分享创造 Blessed C:现代 C 生态系统使用指南
    @liprais 你对于推荐的项目或者我的态度有什么建议吗?我反复读了一遍主贴,没有看到任何高高在上或者试图表明「我随手一推荐的都是对的,你们用的都是错的」的观点。相反,我一直在反复强调「我不是专业的 C 程序员」「其中一些领域我也不了解」「人工挑选或是利用 Google 等搜索引擎搜索得到的」。

    至于我给楼上的回复,我也没有看出试图证明「我比你聪明」的意思。你是对哪一句不满意呢?

    如果你认为自己比我聪明,欢迎提出理由。仅仅甩一句阴阳的话不能证明任何观点,除了你的戾气。我不认为你是来这里寻开心的。
    56 天前
    回复了 w568w 创建的主题 分享创造 Blessed C:现代 C 生态系统使用指南
    @tool2d

    > github 上的项目,C 语言应该是存量最多的

    问题就在于存量是最多的。多并非是好事,反而会将那些真正有用的库稀释了,查找起来会更困难。而且大量库(例如 GNU )几乎不在 GitHub 上发布,而是自建服务或者使用其他版本管理服务。

    > 想找什么直接搜关键词,大概率能找到合适的

    就我使用的体验,想找到有用的库很难。C 早期库的特点是很多不能注重模块化,因为类型和接口高度耦合,为了性能必须把一簇功能放在一起发布,例如 Glib 、gnulib 等。就「跨平台 Socket 库」这个需求,我初用 C 时好一顿找,Google 「 portable socket library for c 」翻个底朝天都没找出需要的。最后发现 libuv 的介绍是「 Cross-platform asynchronous I/O 」……汗颜,水平不够是真的没法精准描述自己需要的东西的。

    > 这种推荐,大神不会去参考,小白也不会去用

    大神不会参考我理解,「小白也不会去用」何出此言?

    > 普通人看到茫茫多的 C 代码,也只能劝退。

    哪里有茫茫多的 C 代码?我这应该是个 curated list 类型的项目吧。只有标题、简介和链接啊。

    > C 的爱好者,一般都是希望了解底层运行原理,但是你不自己造一个轮子出来,又怎么能了解原理呢。

    语言有两个目的:使用和学习。使用自不必说,学习时先找到一个好的项目作参考,也不冲突。我猜想你的意思应该不包含「学语言必须闭门造车,不要参考任何项目」这一层观点吧?
    关于   ·   帮助文档   ·   博客   ·   API   ·   FAQ   ·   我们的愿景   ·   实用小工具   ·   2808 人在线   最高记录 6543   ·     Select Language
    创意工作者们的社区
    World is powered by solitude
    VERSION: 3.9.8.5 · 17ms · UTC 11:38 · PVG 19:38 · LAX 04:38 · JFK 07:38
    Developed with CodeLauncher
    ♥ Do have faith in what you're doing.