cudf-polars 开发指南：GPU 执行器架构、IR 翻译规则与完整开发工作流

数据分析数据工程机器学习【免费下载链接】cudfcuDF - GPU DataFrame Library项目地址https://gitcode.com/gh_mirrors/cu/cudf点击查看免费下载本文基于 cuDF 仓库中的开发者文档 developer_docs.md系统讲解 cudf-polars——即 polars 的 GPU 执行器python/cudf_polars子项目——的环境搭建、执行器设计、IR中间表示节点体系、容器与 CUDA 流管理、测试与调试方法。读完本文你将能够独立搭建 cudf-polars 开发环境、理解 polars 查询计划如何被翻译并执行到 GPU并且掌握新增 IR 节点、编写转换规则与调试回退行为的完整开发流程。一、环境准备与构建开发 cudf-polars 需要两类基础环境Rust 开发环境因为需要从源码构建 polars 的 Python 绑定。推荐使用 RAPIDS 的合并版 devcontainer在配置中加入 rust feature否则可用 rustup 安装 Rust 工具链。cudf 开发环境按照仓库根目录 CONTRIBUTING.md 中“setting up your build environment”一节搭建。合并版 devcontainer 可以直接使用也可以采用其他你熟悉的构建方式。从源码安装 polarscudf-polars 的 pyproject.toml 中声明了它兼容的 polars 版本范围当前为polars1.35,1.45。因此纯粹开发 cudf-polars 时正常安装 polars 依赖即可只有当你需要修改 polars 侧代码即 Rust 侧的NodeTraverser、engine 接口等时才需要从源码构建 polarsgit clone https://github.com/pola-rs/polars cd polars在已激活的 cudf 环境conda 或 pip中安装 polars 的构建依赖。注意不要使用 polars 自带的make build它会把构建隔离到独立的虚拟环境中而我们需要与 cudf 构建共用同一个环境# cudf environment (conda or pip) is active pip install --upgrade uv uv pip install --upgrade -r py-polars/requirements-dev.txt普通pip install也能工作但使用uv会快得多。随后构建 polars 的 Python 包cd py-polars # debug 模式构建最适合开发与调试 maturin develop -m Cargo.toml如果是做性能基准测试则应该用 release 模式构建RUSTFLAGS-C target-cpunative maturin develop -m Cargo.toml --release每次更新 polars 源码后都需要重新执行maturin构建命令。以可编辑模式安装 cudf-polars 执行器polars 逻辑计划的执行器就位于本仓库的python/cudf_polars目录。先按常规方式构建 cudf然后以 editable 模式安装该包cd cudf/python/cudf_polars pip install --no-build-isolation --no-deps -e .此后就可以运行测试套件测试位于tests/子目录pytest -v tests从仓库结构看python/cudf_polars下除cudf_polars/源码包与tests/外还有独立的 README包内部按职责划分为dsl/IR 定义与翻译、containers/列/表容器、streaming/流式执行器、engine/、testing/测试工具与 GPU 引擎注入、utils/配置、计时等等子包与下文各章节一一对应。二、执行器设计collect(enginegpu)是如何接入的polars 的LazyFrame.collect支持通过engine参数选择执行引擎。在底层polars 提供了一个“优化后回调”post-optimization callback机制第三方库可以借此把优化后逻辑计划中的某个或多个节点替换为一个 Python 回调由该回调负责交付整个计划的执行结果。cudf-polars 只替换单个节点。这套机制把计划执行切分为两个阶段符号阶段Translation把 polars 的 Rust 侧计划翻译成 cudf-polars 自己的内部表示IR。执行阶段Execution基于 IR 在 GPU 上执行。翻译阶段接收一个低层的 RustNodeTraverser对象它逐个交付计划节点及表达式的 Python 表示。翻译过程中cudf-polars 会尽力对任何不支持的功能抛出NotImplementedError。由此形成一个清晰的契约如果 IR 能翻译成功就默认后续求值会成功如果翻译失败则完全不改动逻辑计划由 polars 走 CPU 路径。启用 cudf 执行器只需指定 gpu 引擎import polars as pl result q.collect(enginegpu)该调用要么透明地在 GPU 上执行并返回一个 polars DataFrame要么失败但被妥善处理后回退到正常 CPU 执行。当环境变量POLARS_VERBOSE为真时回退行为会以PerformanceWarning形式记录。源码印证这一整套流程的入口是 callback.py 中的execute_with_cudf。该函数在ConvertIRNVTX 区间内构造Translator并调用translate_ir()随后通过translator.unsupported_operations_error()检查翻译是否成功若失败读取POLARS_VERBOSE环境变量并在开启时发出PerformanceWarning再依据raise_on_fail决定是否抛出异常否则仅record_fallback()若成功则用nt.set_udf(partial(_callback, ir, ...))把执行回调注入NodeTraverser见 callback.py 第 363-386 行。GPUEngine 配置对象engine参数除了字符串形式还可以传入 polars 的GPUEngine对象用于传入更多配置。当前公开的属性有两个device选择要使用的 GPU 设备memory_resource选择收集阶段分配内存所用的 RMM 内存资源。import polars as pl result q.collect(enginepl.GPUEngine(device1, memory_resourcemr))这里会使用 1 号设备及给定的内存资源。注意所提供的内存资源必须对指定设备上的分配有效系统不会做校验。此外出于调试目的还可以传入未公开文档化的关键字参数目前支持raise_on_fail它在翻译失败时直接抛异常而不是回退到 CPUresult q.collect(enginepl.GPUEngine(raise_on_failTrue))这在编写测试时尤其有用——测试场景下我们期望任何失败都向上传播而不是静默回退到 CPU 模式。raise_on_fail的消费逻辑同样可以在 callback.py 中确认。IR 版本协商polars 侧的NodeTraverser对象会对外通告一个内部版本号通过NodeTraverser.version()返回(major, minor)元组minor版本号提升对应向后兼容的变更例如暴露新的节点类型major提升则对应不兼容变更。因此 cudf-polars 可以独立于 polars 发行版本号来探测 IR 版本并做分派或报错该逻辑应放在 IR 翻译阶段translate.py中处理。三、IR 设计如前所述cudf-polars 把 polars DSL 翻译成自己的 IR。这样做有两个目的一是平滑 polars 小版本间的差异通过NodeTraverser版本号变更来通告二是让我们获得自由可以针对 GPU 执行引入新的 IR 节点和重写规则。为此代码库提供了节点定义、遍历与重写规则编写的完整基础设施。抽象基类Node位于 nodebase.py它定义了实现新节点的接口并提供大量默认方法详见Node类的 docstring。重要约定这套通用实现依赖节点被视为不可变对象。不要实现节点的就地修改否则会出现难以排查的问题。定义节点具体节点类型cudf-polars 有表达式节点Expr和计划节点IR两大类都应继承自Node。节点有两类数据children一个可能为空的具体节点元组非子数据non-child附加在节点上、但本身不是节点的数据。基类Node要求子类在_non_child类变量中声明非子属性的名字列表具体节点的构造函数必须按*_non_child顺序与类变量一致然后*children的顺序接收参数。例如按表达式生成列并对其进行排序的Sort节点class Expr(Node): children: tuple[Expr, ...] class Sort(Expr): _non_child (dtype, options) children: tuple[Expr] def __init__(self, dtype, options, column: Expr): self.dtype dtype self.options options self.children (column,)遵循这一模式后即可免费获得自动的带缓存的__hash__与__eq__实现以及一个方便的reconstruct方法——它用新的 children 重建节点而共享非子数据。如果需要对某个节点定制__hash__/__eq__行为应分别覆写get_hashable和is_equal方法而不是直接覆写 dunder 方法。源码印证nodebase.py 中可以看到Node的__slots__只包含children与若干缓存字段_hash_value、_repr_value、_stable_digest等_non_child是ClassVar[tuple[str, ...]]reconstruct通过type(self)(*self._ctor_arguments(children))完成重建。此外源码还实现了进程间稳定的标识get_stable_id用 MD5 摘要生成 32 位整型 ID规避PYTHONHASHSEED导致的 hash 随机化get_stable_plan_id则基于整棵子树的所有节点稳定 ID 生成 UUID——这些正是后文查询计划序列化输出中节点 ID 的来源。从 polars IR 新增翻译规则计划节点Plan nodes。计划节点定义在 ir.py 中都继承自基类IR。计划节点的求值通过实现do_evaluate方法完成该方法先接收_non_child_args中声明的非子参数然后是已求值的子节点DataFrame对象最后是一个 keyword-only 的context参数IRExecutionContext包含运行时执行上下文。进行求值时应使用基类的通用evaluate方法它会处理子节点的递归求值。计划节点还必须声明_n_non_child_args属性_non_child_args元组的长度。这是给 tracing 用的它让追踪机制无需内省即可知道该节点期望多少非子DataFrame输入。要把一个计划节点翻译进来在 translate.py 的translate_ir中新增一个 case 处理分支即可。除了计划类子节点外大多数计划节点还包含子表达式它们应以当前计划的输入作为上下文来变换。表达式翻译由translate.py中的translate_expr处理。为了让类型解析正确任何表达式都应在对应计划节点“激活”于 visitor 的状态下翻译。例如翻译Join节点时左侧键表达式应在左输入激活时翻译右侧键则在右输入激活时。为此可使用set_node上下文管理器。表达式节点Expression nodes。表达式节点的处理方式与计划节点非常类似表达式定义在cudf_polars/dsl/expressions/下并通过 expr.py 导出到dsl命名空间继承自Expr。表达式通过实现do_evaluate方法来求值其参数为一个DataFrame上下文提供列一个ExecutionContext参数指示当前表达式所处的求值上下文目前尚未使用一个从表达式映射到已求值Column的mapping。这种设计支持一种简单的表达式重写机制——在表达式求值期间通过替换 mapping 实现例如 groupby-聚合的求值就会用到它。求值同样应走基类的通用evaluate方法由它负责在替换 mapping 中查表的样板逻辑。为了简化状态追踪所有列都应在构造后视为不可变。这与逻辑计划中“函数式”的描述方式一致也比较自然。遍历与变换节点在表示与求值之外traversal.py 还提供了节点树遍历和变换规则定义的基础设施。最简单的是traversal它以前序遍历访问表达式中所有唯一节点。如果你只想了解表达式的一些特定性质就用它。例如判断一个表达式是否包含Literal节点def has_literal(node: Expr) - bool: return any(isinstance(e, Literal) for e in traversal(node))在实际场景中我们常需要给 visitor 提供不可变的状态以及做 DAG 感知的重写如果同一个表达式已经处理过就复用其变换结果。因此代码库采用了如下 DAG 感知 visitor 模式。假设我们要写一个在表达式Expr与某个新类型T之间的重写规则rewrite则定义通用变换函数其类型为Expr - (Expr - T) - Tfrom cudf_polars.typing import GenericTransformer from typing import TypedDict class State(TypedDict): ... singledispatch def rewrite(e: Expr, rec: GenericTransformer[Expr, T, State]) - T: ...注意执行递归的函数是作为第二个参数传入的。对于特定重写规则我们偏好自由函数加functools.singledispatch分派而不是为每个节点定义方法。随后按惯例为不同表达式类型注册 handler。要使用这个函数我们需要同时提供“要变换的表达式”和“递归函数本身”即把rewrite包装成只接受单个参数表达式的函数同时随身携带递归所需的信息。traversal.py提供了两个工具make_recursive非常简单的实现不做中间结果缓存被访问的 DAG 会当作树来处理CachingVisitor接口相同但维护中间结果缓存同一表达式再次出现时直接复用。两者都实现了GenericTransformer协议可以把rewrite这类变换函数包装成Expr - T函数并允许通过state字典给 visitor 附加任意不可变状态。state字典最好用TypedDict表示这样变换函数就知道有哪些可用字段。最后对于“输入节点、输出新节点”的变换例如重写规则还有一个工具reuse_if_unchanged可作为节点到节点重写的基线变换它执行深度优先访问并变换 children只有当 children 的重写确实产生了新节点时才返回带新 children 的新节点从而最大化缓存/共享命中。一个完整示例写一个rename函数接收一个表达式可能包含列引用和一个列名映射返回列名被重命名的新表达式。第一步定义分派函数from collections.abc import Mapping from functools import singledispatch from cudf_polars.dsl.traversal import ( CachingVisitor, make_recursive, reuse_if_unchanged ) from cudf_polars.dsl.expr import Col, Expr from cudf_polars.dsl.to_ast import ExprTransformer singledispatch def _rename(e: Expr, rec: ExprTransformer) - Expr: raise NotImplementedError(fNo handler for {type(e)})第二步先为列注册 handler_rename.register def _(e: Col, rec: ExprTransformer) - Expr: mapping rec.state[mapping] # state set on rec if e.name in mapping: # 若存在重命名返回带新名字的 Col 引用 return type(e)(e.dtype, mapping[e.name]) return e第三步为其余表达式注册通用 handler_rename.register(Expr)(reuse_if_unchanged)在这个例子中也可以把通用 handler 直接写在_rename函数体里但那样做的话如果误传了错误类型的对象就不会得到友好的报错信息。最后用公开函数把各部分组装起来from typing import TypedDict class State(TypedDict): mapping: Mapping[str, str] def rename(e: Expr, mapping: Mapping[str, str]) - Expr: Rename column references in an expression. mapper CachingVisitor(_rename, stateState(mappingmapping)) # 或 # mapper make_recursive(_rename, stateState(mappingmapping)) return mapper(e)四、IO 分区统计实验特性IO 分区统计目前是实验特性细节未来可能变化。流式streaming执行器会采样 Parquet footer 元数据来估算每列的存储大小然后结合流式执行器上的target_partition_size字节数来决定如何拆分或融合文件级分区使每个输入分区都尽量接近该目标大小。可通过executor_options或环境变量CUDF_POLARS__EXECUTOR__TARGET_PARTITION_SIZE调整该参数engine pl.GPUEngine( executorstreaming, executor_options{target_partition_size: 2_000_000_000}, )从源码结构看流式执行器的配置以 dataclass 形式集中在 utils/config.py 中如StreamingExecutor、InMemoryExecutor等executor_options中的键最终会被映射到这些带验证的配置对象上。内部实现上collect_statistics会遍历 IR 图把读同一组文件路径的 ParquetScan节点分组对该组做投影列的并集用于采样为每个路径组构建一个DataSourceInfo再把它挂到组内所有Scan上叶子DataFrameScan节点单独处理。结果存放在StatsCollector.scan_stats中。读同一批文件的多个 scan 之间会共享 Parquet 元数据采样避免重复 IO。五、容器Scalar、Column 与 DataFrame容器应当是围绕 pylibcudf 对应对象的轻量级包装。cudf-polars 有三个容器位于cudf_polars/containers/对应源码文件 column.py、dataframe.pyScalar包装 pylibcudf 的ScalarColumn包装 pylibcudf 的ColumnDataFrame包装 pylibcudf 的Table。这些容器的接口仍在演化中但大体上DataFrame就是字符串name到Column的映射同时持有一个 pylibcudfTable。名字只附加在Column上并且经由NamedExpr位于IR节点内部、处于表达式顶层的表达式节点插入DataFrame。这意味着表达式求值器完全不需要关心列名列只在构造DataFrame时才会被加上名字。列会跟踪一些元数据例如是否已排序。未来可以想象跟踪更多元数据如最小值、最大值但那或许更适合交给 libcudf 本身处理。构造新的 DataFrame 和 Column 时容器提供一些便捷方法用于迁移元数据DataFrame和Column都提供sorted_like(like: Self)调用从模板对象复制元数据。最后一条编码约定所有就地修改容器的方法都应返回self以支持“流式fluent”调用风格。在遍历对象并收集结果的场景下只要每个方法都返回值写起来会轻松得多。六、CUDA Streams 的正确使用CUDA 流Streams用于管理并发操作。cudf-polars 的流管理建立在 libcudf 与 pylibcudf 对Column/Table操作使用流的基础之上。在 cudf-polars 中我们给cudf_polars.containers.DataFrame附加一个Stream。该流或者汇入它的新流会被用于该DataFrame底层数据的所有 pylibcudf 操作。构造cudf_polars.containers.DataFrame时必须确保提供的所有 pylibcudf Table / Column 在所给stream上是有效的。特别要留意合并来自多个DataFrame的 pylibcudfTable/Column或合并根本不来自任何DataFrame的“裸”pylibcudf 对象时——DataFrame.with_columns、DataFrame.filter这类接受cudf_polars.containers.Column参数的方法同样适用传入的列可能并不在当前DataFrame的原始流上有效。简单情况的示例——pylibcudf.Table在某个 CUDA 流上创建DataFrame使用同一流import polars as pl import pyarrow as pa import pylibcudf as plc from rmm.pylibrmm.stream import Stream from cudf_polars.containers import DataFrame, DataType stream Stream() t plc.Table.from_arrow( pa.Table.from_pylist([{a: 1, b: 0}, {a: 1, b: 1}, {a: 2, b: 0}]), streamstream ) # t 在 stream 上有效。因此必须提供 stream # 或某个位于其下游的 CUDA Stream df DataFrame.from_table( t, names[a, b], dtypes[DataType(pl.Int64()), DataType(pl.Int64())], streamstream )管理可能位于不同流上的多个容器更复杂一些。代码库提供了工具函数来正确处理来自多个独立来源的数据。例如要向df添加一个在独立 CUDA 流上有效的Column应使用cudf_polars.utils.cuda_stream.get_joined_cuda_stream获得一个同时位于原始stream与stream_b下游的新流from cudf_polars.containers import Column from cudf_polars.utils.cuda_stream import get_joined_cuda_stream stream_b Stream() col Column(plc.Column.from_arrow(pa.array([1, 2, 3]), streamstream_b), dtypepl.Int64(), namec) new_stream get_joined_cuda_stream(upstreams(stream, stream_b)) df2 df.with_columns([col], streamnew_stream)同样的原则适用于用多个cudf_polars.containers.Column对象分别在不同流上有效构造cudf_polars.containers.DataFrame的场景调用方有责任提供一个所有Column都有效于其上的流通常做法是把各个列所基于的流 join 起来。七、编写测试测试使用pytest位于tests/子目录即 python/cudf_polars/tests。组织上顶层测试文件各自对应一个IR节点例如test_groupby.py、test_join.py、test_sort.py等目标是针对每个节点能处理的所有选项做参数化以获得合理的覆盖率。表达式功能的测试应放在tests/expressions/中。写测试并断言正确性的方式是把查询构造成 lazyframe然后用cudf_polars.testing.asserts中的工具断言函数。它会分别用 cudf 执行器和 polars CPU 执行该查询并检查结果一致from cudf_polars.testing.asserts import assert_gpu_result_equal def test_whatever(): query pl.LazyFrame(...).(...) assert_gpu_result_equal(query)测试覆盖与失败模式断言当某查询的翻译因功能不受支持而理应失败时这一点也应该有测试覆盖。要断言翻译阶段抛出异常通常是NotImplementedError使用工具函数assert_ir_translation_raisesfrom cudf_polars.testing.asserts import assert_ir_translation_raises def test_whatever(): unsupported_query ... assert_ir_translation_raises(unsupported_query, NotImplementedError)如果翻译没有抛出异常该测试会失败。这与第二节介绍的“翻译失败即不改计划、回退 CPU”的契约正好互补raise_on_fail让翻译异常在测试中显式传播assert_ir_translation_raises则把回退路径本身变成可回归验证的对象。八、调试如果回调执行在 polarscollect调用中失败我们能拿到错误但无法顺利进入调试器检查调用栈——我们跨不过语言边界Python → Rust → 回调。不过我们可以手工驱动 DSL 的翻译与执行。给定一个表示查询的LazyFrame可以先把它翻译成 IR再执行并转回 polarsfrom cudf_polars.dsl.translate import Translator from cudf_polars.dsl.ir import IRExecutionContext from rmm.pylibrmm.stream import DEFAULT_STREAM import polars as pl q ... # 转换为我们的 IR translator Translator(q._ldf.visit(), pl.GPUEngine()) ir translator.translate_ir() # 位于设备上的 DataFrame result ir.evaluate(cache{}, timerNone, contextIRExecutionContext()) # Polars DataFrame host_result result.to_polars()这样一旦出现异常就可以在 Python 中像平常一样调试。这段手工流程与 callback.py 中_callback自动路径的调用序列Translator→translate_ir→ir.evaluate(cache{}, timer..., context...)→to_polars是一致的只是把cache、timer、context等参数暴露给了开发者。九、配置系统Polars 用户可以通过pl.GPUEngine()配置计划执行的诸多选项其中一部分选项直接定义在 polars 本身。所有额外的关键字参数都会通过engine.config暴露给 cudf-polars。为了集中做校验、并在内部保持良好类型化cudf-polars 把这些附加配置建模为一组定义在 utils/config.py 中的 dataclass例如ConfigOptions、InMemoryExecutor、StreamingExecutor、ParquetOptions等。从用户提供的选项转换到我们内部已验证的选项使用ConfigOptions.from_polars_engine。源码补充从该文件的结构可以推断出配置的取值优先级模式——许多字段以单例哨兵UNSPECIFIED为默认值表示“用户既未显式给出值、也没有匹配的环境变量”由消费组件决定语义环境变量CUDF_POLARS__EXECUTOR__*系列用于在不改代码的情况下调参例如第二节提到的CUDF_POLARS__EXECUTOR__TARGET_PARTITION_SIZE。callback.py 中还可见POLARS_GPU_ENABLE_CUDA_MANAGED_MEMORY环境变量用于控制默认内存资源是否采用托管内存managed memory池。十、性能剖析Profiling可以使用 NVIDIA NSight Systems 对 cudf-polars 做剖析。每次.collect()或.sink()调用在cudf_polarsNVTX 域下有两个顶层区间ConvertIR测量把 polars 查询计划转换为 cudf-polars IR 所花费的时间ExecuteIR测量执行 cudf-polars IR 所花费的时间。大部分时间应当落在ExecuteIR区间内。在ExecuteIR内部每个 IR 节点的do_evaluate方法都被另一个 NVTX 区间包裹如Scan.do_evaluate、GroupBy.do_evaluate等为更底层的 libcudf 调用如read_chunk、aggregate提供了更高一层的分组。源码印证两个顶层区间分别对应 callback.py 中的nvtx.annotate(messageConvertIR, domainCUDF_POLARS_NVTX_DOMAIN)翻译阶段约第 363 行与nvtx.annotate(messageExecuteIR, ...)执行阶段约第 295 行NVTX 域常量定义在 tracing.py。需要注意流式执行器不支持LazyFrame.profile()对它的剖析应使用 NSight Systems见 callback.py 中 streaming 分支的提示。十一、查询计划导出Query Plans模块cudf_polars.streaming.explain提供了针对给定LazyFrame导出查询计划的函数。结构化输出cudf_polars.streaming.explain.serialize_query可以以结构化格式输出查询计划 import dataclasses import polars as pl from cudf_polars.streaming.explain import serialize_query q pl.LazyFrame({a: [a, b, a], b: [1, 2, 3]}).group_by(a).agg(pl.len()) dataclasses.asdict(serialize_query(q, enginepl.GPUEngine())) {roots: [526964741], nodes: {526964741: {id: 526964741, children: [1694929589], schema: {a: STRING, len: UINT32}, properties: {columns: [a, len]}, type: Select}, 1694929589: {id: 1694929589, children: [2632275007], schema: {a: STRING, ___0: UINT32}, properties: {keys: [a]}, type: GroupBy}, 2632275007: {id: 2632275007, children: [], schema: {a: STRING}, properties: {}, type: DataFrameScan}}, partition_info: {526964741: {count: 1, partitioned_on: ()}, 1694929589: {count: 1, partitioned_on: ()}, 2632275007: {count: 1, partitioned_on: ()}}}结构化 schema 有三个顶层字段roots查询计划中“根”最终节点的整型 IDpartition_info查询各阶段的分区信息nodes从整型节点 ID 到节点详情的映射输出中出现的每个节点 ID 都在该映射中存在通过查看children即可理解该节点依赖哪些节点。注意所有整型都以字符串形式保存以便更轻松地往返round-trip到 JSON。这些节点 ID 的来源正是第三节提到的Node.get_stable_id稳定标识机制保证跨进程的确定性。小结cudf-polars 以“翻译-执行”两阶段架构把 polars 查询接到 GPU 上翻译期尽量抛出NotImplementedError保证失败可回退执行期通过不可变的 IR 节点体系Node基类 singledispatch遍历重写、轻量容器Scalar/Column/DataFrame、严格的 CUDA 流纪律以及 NVTX 剖析与serialize_query计划导出构成了从 polars DSL 到 libcudf 执行之间清晰、可测试、可调试的完整链路。新增功能时按“ir.py/expressions/定义节点 →translate.py加翻译分支 →tests/按节点补测试与失败断言”的路径推进即可与仓库现有开发约定保持一致。赞分享数据分析数据工程机器学习【免费下载链接】cudfcuDF - GPU DataFrame Library项目地址https://gitcode.com/gh_mirrors/cu/cudf点击查看免费下载相关推荐cudf-polars 表达式Expression实现与审查完全指南从 IR 翻译到 GPU 全流程落地cudf polars 表达式Expression实现与审查完全指南从 IR 翻译到 GPU 全流程落地 导读 本文以 cudf polars 中实现与审数据分析数据工程机器学习cudf-polars GPU 执行引擎深度解析环境搭建、IR 架构、遍历重写与测试调试实战cudf polars GPU 执行引擎深度解析环境搭建、IR 架构、遍历重写与测试调试实战 本文基于仓库中 cudf polars 开发文档 https:/数据分析数据工程机器学习TVBoxOSC多语言开发国际化架构与翻译工作流TVBoxOSC多语言开发国际化架构与翻译工作流 在全球化应用开发中多语言支持已成为基础功能需求。TVBoxOSC作为电视盒子控制管理系统其国际化架构设计上一篇Cheetah的duration与delay进阶技巧像导演一样控制iOS动画节奏下一篇兼容 Typesense 17 到 30 全版本免费管理面板 typesense-dashboard 特性探测机制完整剖析创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考