丁丁的博客

语音 AI 技术（e.g. 语音识别、语音合成）是人工智能重要的研究和应用方向。但是，不同于 CV、NLP 等“显学”，语音相关的从业人员（学界和业界）相对较少，语音领域的学术会议和期刊影响力也比较有限。比如语音顶级会议 ICASSP 也仅是 CCF-B 类，InterSpeech 更是被划在 C 类；并且两个会议接近 50% 的文章接收率也经常为人诟病。语音 AI 是一个多学科交叉的技术方向，涉及到信号处理、语言学、语音学（e.g. 发音规律）、心理学（e.g. 听觉感知）、传统机器学习以及深度学习等。

By Gary M. Johnson: Too Big to FLOP? From HPCWire在高性能计算（HPC）的领域前沿，我们一般认为计算机系统的规模越大越好，用户也需要规模更大的计算机。不过，在我们着手开发计算速度超过petaflops（10的15次方浮点运算每秒）量级的计算机，并向着exaflops量级的目标努力之时，我们的这些观点依然正确吗？计算机是否已经变得过于庞大，

我们经常会提到两种“线程”（thread）。一种线程存在于操作系统（OS）中。对OS而言，进程是资源分配的基本单位，每个程序在一个进程中分配相应的内存等系统资源。而每个进程可以包含多个“线程”。这些线程共享进程分配的资源，但是独立地被OS调度执。我们可以称这种线程为“软线程”。另一种线程则是我们将要介绍的，因为它与处理器密切相关，我们不妨称之为“硬线程”。可以认为，这两种线程除了名称相

OpenCL本身（至少目前）并不支持模版。在许多场景下（例如移植CUDA代码），这会带来一些麻烦。 这里，我们介绍一种解决方案。主要思路是，利用OpenCL在运行时编译的特点，通过宏定义实现类似C++模型的功能。首先我们要解决动态获取类型名称的问题 解决方法如下：template<typename T>struct TypeParseTraits { static const ch

在编写OpenCL代码时，为了方便起见，我们更喜欢将kernel源代码放在单独的文件中（一般为*.cl）。这各做的缺点在于，程序需要在运行时动态读入文件中的代码为字符串，然后再传递给OpenCL的RT编译、执行。因此，在可执行文件之外，我们还需要单独分发*.cl文件。下面，我们介绍一种简单的技巧，将*.cl文件在编译时静态的包含在可执行文件中。首先，将所有源代码由”STRINGFY()”括起来。

基于模版的惰性求值

介绍 AMD 的 ROCm GPU 计算平台。

在之前的文章中，我们探讨了如何通过 cffi，扩展 pytthon （pytorch）。利用 cffi 方法，我们需要单独的 C 和 CUDA 源文件，还需要事先进行编译，不但过程比较繁琐，代码结构也稍显凌乱。对于一些简单的 CUDA 扩展（代码量不大，没有复杂的库依赖），显得不够友好。这里，我们介绍如何通过在线编译的方式，直接为 pytorch 提供 CUDA 扩展（当然，也可以是纯 C 的