为啥进行python标准化

Posted 2023-04-23

参考技术A 解决因变量之间量纲不同，无法比较的问题。通过标准化使数据之间具有可比性。同时因为是线性变换，所以不改变原有的数据分布。 参考技术B 进行python标准化，是因为它们可以将不同的数据特征统一到同一个尺度上，从而消除特征值之间的量级差异，提高模型的准确性和鲁棒性

为啥使用非标准 C（gcc 特定功能）对 linux 内核进行编码？ [关闭]

【中文标题】为啥使用非标准 C（gcc 特定功能）对 linux 内核进行编码？ [关闭]

【英文标题】：Why is linux kernel coded using non-standard C (gcc specific features)? [closed]为什么使用非标准 C（gcc 特定功能）对 linux 内核进行编码？ [关闭]

【发布时间】：2011-12-29 21:57:15

【问题描述】：

Linux 内核代码使用“语句表达式”和 typeof 扩展，使其只能在 gcc 下编译。

越想越没道理。

它违背了可移植性和标准 C 的目的。 （现在 linux 内核代码需要支持 gcc 扩展的特定编译器）。

这是一个糟糕的设计选择，还是有特定的原因让 linux 内核代码特定于 gcc？

编辑：当我说它破坏了可移植性时，我在不同的上下文中使用了它。我在想，通过符合标准 C，任何支持标准 C 的编译器都可以接受它（这正是创建标准的目的——统一 C 的所有不同方言），因此更具可移植性。当然，由于 gcc 如此流行，而且 gcc 支持无数的架构，这条线几乎没有意义。我只是在问不符合标准 C 背后是否有特定的理由。

【问题讨论】：

为什么 GNU Linux 被编写为使用 GNU 编译器编译会很奇怪？谁说 Linux 是为移植到其他编译器而设计的？

Linux 与代码质量或可移植性无关。这是关于世界统治的。

这听起来不像是 SO 的主题。我对Programmers 的范围知之甚少，无法说是否应该将其移到那里。

@OliCharlesworth Linux 内核不是 GNU/Linux，GNU/Linux 指定发行版中包含的核心实用程序是 GNU 实现。应该可以将 Linux 内核与核心实用程序的另一个实现一起使用，例如BSD，那就不是 GNU/Linux。

@SHH 一旦发生这种情况，它们就不再是“gcc 扩展”了。它们是“某些人需要的东西，由某些编译器实现”。许多以前的 gcc 扩展现在是标准 C99 功能。

【参考方案1】：

这里有一些关于使用的特定扩展的良好背景。它并没有真正从“为什么？”的角度来写，但它应该为您提供一些关于选择这种方法的原因的良好背景：

https://developer.ibm.com/tutorials/l-gcc-hacks/

【讨论】：

哇，感谢这篇精彩的文章。

【参考方案2】：

为什么 Linux 内核开发人员会担心让他们的代码在 Microsoft Visual Studio 编译器或 IBM xlC 编译器上运行？

当您编写内核时，您需要比（通常）在用户空间中更精确地控制更多的东西，例如精确的内存布局。在 C 标准中并没有真正考虑到此类控件（例如，保留为实现定义的特征），因此要么需要一些扩展，要么您需要依赖编译器的怪癖。

坚持使用一个特定的编译器，利用它的扩展，是一个理性的决定。代码不需要跨编译器可移植 - 它需要高效且可跨不同硬件平台移植。

【讨论】：

我不知道哪些 gcc 扩展功能可以让您精确控制更多内容，例如内存布局或最大化效率。这不是特定于架构的汇编语言的工作吗？我的意思是，如果内核开发人员想要最大的效率，他们为什么不使用汇编语言呢？看起来内核中使用的任何 gcc 扩展都可以被标准 C 替换（如果我错了，请纠正我）。

编写汇编比编写 C 更加耗时和困难。即使在内核中，它也仅限于 a) 根本不可能用 C 表达，或 b) 非常C 编译器没有得到“完美”的特定的、性能关键的代码片段。使用的一些扩展可能会被标准 C 替换，但有什么意义呢？如果使用 exts 更容易编写，为什么还要麻烦呢？还要记住，C 标准是不断发展的。随着时间的推移，一些扩展被许多编译器实现，因为它们有用。然后，最终，它们可以成为标准

最后，这非常很重要：Linux 内核不像普通应用程序那样关心可移植性根本。他们编写他们运行的环境并提供给用户空间。内核关心的可移植性与“普通”应用程序的可移植性完全不同。

@Mat：Linux 内核确实关心可移植性，这就是为什么它使用已移植的编译器并为无数架构生成代码的原因。

受限于 gcc 可能是一个特性而不是一个 bug，如果他们支持其他编译器，人们会尝试在这些编译器下编译内核，这将成倍增加不同配置的数量内核可以像其他使用空间程序一样被编译。支持噩梦可能不值得。

【参考方案3】：

Linux 内核代码是一个复杂的软件。 gcc 为他们提供的设施越多，他们就越高兴。

他们为什么要关心可移植性？ gcc 几乎可以在每种硬件配置下编译代码，并为它们提供良好的功能。为什么他们会关心 Linux 是否可以用其他编译器编译？

今天，可移植代码对我们来说是一个非常普遍的概念，我们认为它应该无处不在。但事实并非如此。例如，如果编译器提供了对 C 的实时扩展，NASA 会在不考虑可移植性的情况下使用它。重要的一点是功能太好了，不能为了从未使用过的可移植性而牺牲（我的意思是，谁会用 MS Visual Studio 编译内核？）

【讨论】：

并非 gcc 支持的所有硬件都具有 gcc 的良好特性。

什么意思？我想到的功能是 OP 要求的 "statement-expression" and typeof 类型。

我的意思是 gcc 并没有为每个支持的平台提供良好的性能。

【参考方案4】：

一旦内核被编译，它就不会留下其编译环境的“痕迹”来污染正在运行的内核体验。

我想说这只是权宜之计。内核还包含一些程序集，并且程序集也不是完全可移植的。也许如果内核的“使命”是编写一个可以在多个 C 编译器上编译的内核，那么抱怨就会落到更细心的耳朵里。