GPU、数据选择方法及芯片

技术领域

本申请实施例涉及处理器技术领域，尤其涉及一种数据选择方法、GPU及芯片。

背景技术

Top-K算法是在N个元素里面，找出最大或者最小的K个元素的算法。随着机器学习的发展，Top-K算法在诸如向量数据库、向量检索中发挥着越来越重要的作用。因GPU（Graphic Processing Unit，图形处理器）在高速计算方面的优势，越来越多的深度学习都交由GPU完成，因此，越来越多的Top-K算法场景也都使用GPU实现。

目前，一种基于GPU的Top-K算法为基数选择radix select算法。radix select算法基于radix sort算法，但与radix sort算法为每个数位保持一个用于排序的桶不同，radix select算法仅使第K大或第K小的元素所在的桶进入下一轮数位的迭代循环，从而可以快速缩减排序规模。radix select算法通常分为两个阶段，分别为选择阶段和过滤阶段。示例性地，一种radix select算法的流程如图1所示，在其选择阶段，根据数位将不同的数据元素放入不同的桶中，并计算对应的直方图；然后，通过基于桶中元素数量的前缀和，确定第K大或第K小的元素所在的桶；接着，选择第K大或第K小的元素所在桶中的全部元素；进而，从中找到目标元素即第K大或第K小的元素（可能有多个）。在其过滤阶段，从找到的第K大或第K小的元素中过滤出最终的元素。

但是，现有的上述radix select算法在计算过程中，存在大量的元素写入或读出的访存操作，且这些访存操作多为原子操作。由此，极大地增大了GPU的计算开销，导致GPU访存性能严重下降。

发明内容

有鉴于此，本申请实施例提供一种数据选择方案，以至少部分解决上述问题。

根据本申请实施例的第一方面，提供了一种GPU，包括：计算部件和显存；其中：所述计算部件包括单任务模块，所述单任务模块用于获取待进行基数选择计算的多个数据元素；针对所述基数选择计算的计算节点中的至少部分计算节点，根据所述GPU的计算性能，对所述多个数据元素中与所述至少部分计算节点的计算相关的数据元素，进行所述至少部分计算节点对应的计算的访存加速处理；根据访存加速处理结果，获得所述多个数据元素的基数选择计算结果；所述显存，用于存储所述基数选择计算过程中的过程数据。

根据本申请实施例的第二方面，提供了一种数据选择方法，包括：获取待进行基数选择计算的多个数据元素；针对所述基数选择计算的计算节点中的至少部分计算节点，根据GPU的计算性能，对所述多个数据元素中与所述至少部分计算节点的计算相关的数据元素，进行所述至少部分计算节点对应的计算的访存加速处理；根据访存加速处理结果，获得所述多个数据元素的基数选择计算结果。

根据本申请实施例的第三方面，提供了一种芯片，包括如第一方面所述的GPU。

根据本申请实施例提供的方案，在使用GPU基于radix select算法进行数据元素选择时，与传统的针对每组数据元素在每次迭代计算时，依次进行串行处理，导致产生大量的访存操作不同，而是针对radix select计算过程中的每个计算节点，从中选取部分或全部，以在选出的相应计算节点，对每组数据元素进行访存加速处理。因访存加速处理可通过一次操作写入或读出多个相应的数据，由此，大大降低了radix select计算过程中的原子访存操作的数量。从而，大大地降低了GPU的radix select计算的计算开销，提升了GPU访存性能。

附图说明

为了更清楚地说明本申请实施例或现有技术中的技术方案，下面将对实施例或现有技术描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本申请实施例中记载的一些实施例，对于本领域普通技术人员来讲，还可以根据这些附图获得其他的附图。

图1为一种radix select算法的过程示意图；

图2A为一种示例性的GPU的架构示意图；

图2B为图2A所示GPU架构中的一种计算部件的架构示意图；

图2C为使用图2A所示GPU进行radix select计算过程中在桶计数节点的访存加速处理示意图；

图2D为使用图2A所示GPU进行radix select计算过程中在候选数据元素选择节点的访存加速处理示意图；

图2E为使用图2A所示GPU进行多任务的radix select计算的示意图；

图2F为一种FP32数据的示意图；

图3为根据本申请实施例的一种数据选择方法的步骤流程图；

图4为根据本申请实施例的一种芯片的结构框图。

具体实施方式

为了使本领域的人员更好地理解本申请实施例中的技术方案，下面将结合本申请实施例中的附图，对本申请实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅是本申请实施例一部分实施例，而不是全部的实施例。基于本申请实施例中的实施例，本领域普通技术人员所获得的所有其他实施例，都应当属于本申请实施例保护的范围。

下面结合本申请实施例附图进一步说明本申请实施例具体实现。

为便于理解本申请实施例的方案，以下首先结合图2A和图2B，对GPU的架构进行示例性说明。

由图2A中可见，GPU主要包括计算部件102和显存104。一般来说，计算部件102通常包括多个计算单元，图1中示意为8个计算单元，负责根据指令执行相应的任务。显存104可以存储相应的数据，具有数据访问接口，通过该数据访问接口，可以从显存104中读取数据或者向显存104写入数据。

除此之外，GPU通过总线，示例性地，如PCIe线，与CPU连接，以通过该PCIe总线，GPU与CPU之间进行指令和数据的传输。在GPU内部，还设置有线程引擎，负责将线程块block分配给计算单元，由计算单元负责执行。GPU中还设置有缓存（如L2 CACHE）、内存控制器、高速集线器和GPU互联接口。缓存可分为多级，以在GPU执行任务过程中缓存数据；内存控制器负责对显存104的访问；高速集线器负责GPU间的内存访问；GPU互联接口负责GPU间的高速互联。

在计算单元的内部，如图2B所示，通常设置有：指令缓存、线程束（Warp）调度器、指令分发器、寄存器、计算核心、双精度浮点数计算单元、特殊函数计算单元、访存单元、缓存（如L1 CACHE）和共享内存等。计算单元在接收到任务（通常为子任务）后，通过线程束调度器将任务再次分解，再通过指令分发器将分解的任务部署到各个计算核心上。在任务执行过程中，可能涉及到指令缓存、寄存器访问操作、双精度浮点数计算操作、特殊函数计算操作、及其访问及存储操作，则可通过上述相应的单元执行相应的操作，在此不再详述。

需要说明的是，上述图2A和图2B仅是GPU的一种示例性架构，在实际应用中，只要至少包括有计算部件和显存的其它类型和架构的GPU也同样可适用本申请实施例的方案。

以下，基于上述示例性架构，通过实施例对本申请的方案进行说明。

如上所述，本申请实施例中的GPU包括计算部件102和显存104。基于该GPU可实现本申请实施例中的基于radix select算法的数据选择方案，例如，计算部件102可获取待进行基数选择计算的多个数据元素；针对基数选择计算的计算节点中的至少部分计算节点，根据GPU的计算性能，对多个数据元素中与至少部分计算节点的计算相关的数据元素，进行至少部分计算节点对应的计算的访存加速处理；根据访存加速处理结果，获得多个数据元素的基数选择计算结果。而显存104，则可用于存储基数选择计算过程中的过程数据。

因本申请实施例中的计算部件102除可进行单radix select计算任务外，还可并行执行多radix select任务。为了便于说明，本实施例中，对计算部件102的功能从逻辑上进行了区分，分别表示为单任务模块和多任务模块，但本领域技术人员应当明了的是，该表示仅为了便于功能区分，而并无实际物理层面的区分。基于此，上述计算部件102的功能可由单任务模块执行，也即，计算部件102中的单任务模块在执行单radix select计算任务时，可获取待进行基数选择计算的多个数据元素；针对基数选择计算的计算节点中的至少部分计算节点，根据GPU的计算性能，对多个数据元素中与至少部分计算节点的计算相关的数据元素，进行至少部分计算节点对应的计算的访存加速处理；根据访存加速处理结果，获得多个数据元素的基数选择计算结果。

其中，待进行radix select计算（即基数选择计算）的数据通常为一组，该一组包括多个数据元素。本申请实施例中，若无特殊说明，“多个”、“多种”等与“多”有关的数量均意指两个及两个以上。

一次radix select计算可针对该一组数据进行Top-K计算，对于radix select计算来说，根据如图1中所示的流程，可将其过程划分为多个计算节点，至少包括：桶计数节点、候选数据元素选择节点、和过滤节点。其中，桶计数节点主要用于根据数位将不同的数据元素放入不同的桶中，并计算对应的直方图；候选数据元素选择节点主要用于通过基于桶中元素数量的前缀和，确定第K大或第K小的元素所在的桶，以及，选择第K大或第K小的元素所在桶中的全部元素；过滤节点主要用于找到目标元素即第K大或第K小的元素，并从中找到最终的元素，也即，利用第K大或第K小的元素，从所有输入元素中选择（或称“过滤”）出前K大或前K小的元素作为最终输出。针对上述多个节点，可对数据元素在该多个节点中的全部或部分节点的计算进行访存加速处理。

GPU的计算性能可依据其包含的硬件元件的相关性能数据确定，在一种可行方式中，该计算性能可以为GPU的硬件算力和/或其显存的存储能力。

基于此，在计算时，一种可行方式中，可以针对radix select计算的计算节点中的全部计算节点，根据GPU的硬件算力，对多个数据元素中与各计算节点的计算相关的数据元素，进行各计算节点对应的计算的访存加速处理；和/或，针对radix select计算的计算节点中的部分计算节点，根据GPU的计算性能（如硬件算力和/或显存的存储能力），对多个数据元素中与部分计算节点的计算相关的数据元素，进行部分计算节点对应的计算的访存加速处理。

其中，GPU的硬件算力意指GPU的硬件计算能力，其可通过GPU的硬件参数（包括但不限于计算单元的数量和性能参数等）确定。不同的GPU硬件算力影响执行radix select计算的线程thread或线程块block的数量。线程thread或线程块block的数量越多，并行处理的能力越强，可同时进行并行处理的数据元素越多。本申请实施例中，对GPU硬件算力的具体确定方式，以及GPU硬件算力与可并行处理的数据元素的数量的对应关系均不作限制。

当针对计算节点中的全部计算节点进行访存加速处理时，一种可行方式中，可根 据GPU的硬件算力，在各计算节点的单次计算中，从多个数据元素中选取至少两个数据元 素，进行各个计算节点的并行计算。在一个示例中，可采用packing（打包）方式，使得radix select计算可一次针对多个数据元素。例如，可采用bit-packing的方式，将N个（

而若针对的是部分计算节点时，可以存在以下访存加速处理方式中的至少一种：

方式一：当计算节点为桶计数节点时，根据GPU的硬件算力，从执行桶计数节点对应的桶计数操作中的线程中，选择出目标线程，通过目标线程执行计数操作。

执行桶计数节点对应的桶计数操作中的线程可以从不同层面，分为线程束中的线程和线程块的线程。

则，在一种可行方式中，当计算节点为桶计数节点时，可以根据GPU的硬件算力，确定执行桶计数节点对应的桶计数操作中的计数器操作的至少一个线程束（warp），针对每个线程束，从该线程束的线程中，选择出目标线程，通过目标线程执行其所属的线程束中所有线程的计数器操作；和/或，确定执行桶计数操作中的计数器操作的至少一个线程块(block)，针对每个线程块，从该线程块的线程中，选择出目标线程，通过目标线程执行其所属的线程块中所有线程的计数器操作。通过一个线程实现对应的多个线程的计数器操作，无需反复进行对全局存储的数据写入，从而有效提升了访存效率。

在GPU上运行函数kernel会对应一个线程网格Grid，每个Grid包括多个线程块block，同一个block中的线程thread可以同步，也可以通过block shared memory通信。而线程束warp则是为了更好地管理和执行线程而提出的，其是硬件层面中GPU的基本执行单元，作为调度单位使用，一个warp中也包含多个线程，示例性地，可包含32个线程。每次GPU调度一个warp里的多个线程执行同一条指令，各个线程对应的数据资源可能不同。基于此，可执行分级的原子操作优化，包括warp层面的优化和block层面的优化。

其中，在warp层面，针对每一个warp，可以从该warp包括的多个线程中选择出一个线程作为桶计数操作中针对block计数器的计数器操作的代表线程，将该代表线程作为目标线程，由其承担该warp中所有线程针对block计数器的计数器操作，通常为加1操作。以warp中包含32个线程为例，可以线程0为目标线程，由线程0对block计数器进行操作，以将32个线程针对block计数器的操作全部由线程0完成。每个block都对应有一组桶，记为R个桶，每个桶分别对应一个计数器，通过该计数器，每个桶可记录block所分配到的数据元素中、落入本桶中的数据元素的数量。通过本方式，可以由线程0将相应的计数统一写入各个桶的block计数器（桶计数器）中。其中，目标线程的选择通常可由GPU根据硬件设定选出。

因每个grid有若干个block，每个block各自对应有R个桶，每个桶里记录了一个数字。此外，全局存储中还有R个全局桶，后续在“候选数据元素选择节点”过程中，所有block的R个桶会分别对应累加起来产生全局桶，即，所有block的第0个桶的计数累加起来成为全局第0个桶的计数，所有block的第1个桶的计数累加起来成为全局第1个桶的计数。

基于此，对于block层面来说，在每个block完成上述R个桶对应的桶计数后，需要将这R个桶的桶计数分别累加到全局存储中对应的R个全局桶计数器中。基于此，针对每一个block，可以从该block包括的多个线程中选择出R个桶对应的R个线程作为桶计数操作中针对全局计数器（全局桶计数器）的计数器操作的代表线程，将该代表线程作为目标线程，由其承担该block中针对全局计数器的计数器操作。以block中包含8个桶，共64个线程为例，针对每个桶，可以按顺序选取一个线程作为该桶的目标线程，由该线程将其所属的桶计数累加到对应的全局计数器。其中，目标线程的选择可由本领域技术人员根据实际需求采用适当方式编程实现，包括但不限于随机选取或者选取序号最小的线程等，本申请实施例对选取的具体方式不作限制。

一个具体的block层级的处理如图2C所示，从图2C中可见，radix select计算通过多个block执行，图中示意为block 0…block n，针对每个block，其中包含有多个warp，图中示意为warp 0…warp n，每个warp中又包含有多个线程thread。从图中可见，每个block会从其包括的多个warp的所有thread中选取出一个目标thread进行全局计数器操作。

方式二：当计算节点为候选数据元素选择节点时，根据显存的存储能力，配置块共享存储空间，以将选择出的候选数据元素存储至块共享存储空间，并在达到预设条件时，将块共享存储空间中的所述候选数据元素一次性写入全局存储空间。

其中，预设条件可以由本领域技术人员根据实际需求灵活设置。

在一种可行方式中，当计算节点为候选数据元素选择节点时，根据显存的存储能力，为执行候选数据元素选择节点对应的元素选择操作的至少一个线程块，配置块共享存储空间，以将选择出的候选数据元素存储至块共享存储空间，并在候选数据元素的占用空间达到预设空间阈值时，将块共享存储空间中的候选数据元素一次性写入全局存储空间。由此，该方式通过减少写入操作的次数，提升了访存效率。

其中，显存的存储能力在本实施例中可以简单理解为显存可提供的可用存储空间。本实施例中，为执行元素选择操作的一个或多个线程块配置了块共享存储空间blockshare memory。理论上讲，block share memory越大越好，但为了取得显存的存储能力与元素选择操作的效率之间的平衡，在一种可行方式中，块共享存储空间的空间大小设置为：数据包向量所占空间与线程块中线程数量的乘积的两倍。这是因为，理想情况下每个 block处理的 block * （数据包中数据元素的数量）里被选出来的只有 1/#bins（#bins意指桶的数量），极端情况下可能为数据包中所有数据元素的数量，因此，可将block shared memory的大小设置为数据包向量所占空间与线程块中线程数量的乘积的两倍，以防数据溢出。然后，直到发现选出的数据元素的占用空间超过数据包向量所占空间与线程块中线程数量的乘积时再一次性写入全局存储空间，以备后续处理使用。

上述过程的一个示例如图2D所示，图中每个block的线程数量设定为2，为便于说明，图2D中packing数据包向量的数量为1，也可认为未进行packing，相对应地，块共享存储空间的block * packing所占空间（设定为1） * 2 = 4。block会将每次选择出的候选数据元素存储入块共享存储空间中，经过i次后，块共享存储空间的存储容量超过了2，则该块共享存储空间中存储的所有被选择出的候选数据元素被一次性写回了全局存储空间globalmemory，而块共享存储空间被清空，以备下次使用。如图中所示，在第i次，block1的存储容量超过了2，其候选数据元素被一次性写回了global memory；在第j 次，block0和blockn的存储容量都超过了2，它们候选数据元素均被一次性写回了global memory。

方式三：当计算节点为过滤节点时，根据显存的存储能力，配置内核共享存储空间，以将待过滤的数据元素存储至内核共享存储空间并进行过滤操作，以获得基数选择计算结果。

在一种可行方式中，当计算节点为过滤节点时，可以根据显存的存储能力，为执行过滤节点对应的过滤操作的过滤器内核配置内核共享存储空间，以将待过滤的数据元素存储至内核共享存储空间并进行过滤操作，以获得基数选择计算结果。由此，该方式通过减少写入操作的次数，提升了访存效率。

在一种可行方式中，内核共享存储空间的空间大小可以设置为：基数选择计算的目标数据元素的数量与单个数据元素所占空间的乘积。

针对过滤节点的filter，与传统的radix select算法仅选出第K个数据元素不同，本申请的方案中可以选出从大到小的前K个，或者从小到大的前K个。因此，基于radixselect算法已事先确定好的固定的K，可以将内核共享存储空间即设置为K个数据元素所需占用的空间，即K与单个数据元素所占空间的乘积，从而实现为filter kernel的访存加速。

通过上述多维度的访存优化，实现了更加高效、实用的radix select算法。

但传统的radix select算法无法适用多batch（批处理，即一次执行多个radixselect计算任务）的radix select计算任务的处理，而在实际应用中，多batch的场景越来越多。为此，本申请实施例中，GPU的计算部件102还可进行多radix select计算任务的并行处理。基于此，计算部件102还可以包括多任务模块，该多任务模块用于并行执行多个radixselect计算的任务。

传统的radix select计算过程中，只简单地使用for循环依次处理多个radixselect计算任务，那么每一个任务执行到后期因为选取出的候选数据元素candidates 很少，会使GPU有较大的空窗期，导致性能下降。为此，本申请实施例中，通过多任务模块针对多个radix select计算任务进行并行处理。例如，根据GPU的硬件算力，对并行执行的多个radix select计算任务中的至少部分迭代轮次的计算任务进行并行处理，以期使得多个任务在每一轮次的迭代计算过程中都能够充分利用GPU的硬件资源。

在一种可行方式中，若GPU硬件资源足够，则多个radix select计算任务可在每一轮次都进行并行处理。但在实际应用中，radix select计算任务通常会在第一轮迭代中占用较多的资源，因此，在另一种可行方式中，可以根据GPU的硬件算力，对并行执行的多个radix select计算任务中的第一轮迭代任务进行串行处理，而其它迭代轮次的计算任务进行并行处理。

示例性地，如图2E所示，图2E中左侧图例示出了传统方式中，三个radix select计算任务被依次进行串行处理，其中，坐标轴的横轴为时间轴，纵轴为GPU硬件资源的利用率轴。由左侧图例可见，每个radix select计算任务在迭代至第二轮时，对资源的利用大大下降，在串行方式下这部分未被利用的资源会被浪费掉。并且，因任务的串行执行，在占用较多资源的同时，还需要更多的执行时间。而本示例的方案如图2E中右侧图例所示，针对这三个radix select计算任务，第一轮迭代分别串行执行，至第二轮、第三轮及第四轮，则这三项任务被并行执行，从而有效利用了GPU硬件资源，减少了资源浪费，且加速了任务执行。

此外，在进行多个radix select计算任务的并行处理时，各个任务的输入地址可能并不相同，也会导致访存性能的下降。为此，在一种可行方式中，多任务模块还用于对并行执行的多个radix select计算任务进行输入地址对齐处理；并在对齐处理后并行执行多个radix select计算任务。

具体地，多个radix select计算任务的并行处理情形下，所有radix select计算任务的输入是一块拼在一起的连续内存，起始位置以 offset（偏移） 形式给出，可能并没有对齐到 PACK（packing打成的包），导致访存性能下降。为此，可以向前padding（填充），以使多读入的elements（元素）局限在 (block 0, thread 0)，进而单独处理（如丢弃）即可。

此外，针对该多个radix select计算任务的并行处理情形下的每个radix select计算任务，仍可采用前述单任务模块中针对单个radix select计算任务的处理方式，对该情形下的每个radix select计算任务进行前述优化处理。

此外，虽然通过前述单任务模块和多任务模块的处理，已能够有效提升GPU进行radix select计算时的访存性能，降低计算开销。但因radix select算法本身存在着某些情况下由于数据元素分布过于集中（偏度过高），使得算法鲁棒性较差的问题。为此，在一种可行方式中，单任务模块还可以基于预设的桶规模参数和/或扩大的数据位宽度，在桶计数节点对多个数据元素进行桶计算操作，以均衡多个数据元素在对应的多个桶中的分布。其中，桶规模参数通过对多个数据元素的均摊分析确定；该桶规模参数用于通过对多个数据元素进行减法操作，均衡多个数据元素在对应的多个桶中的分布。

因目前数据元素分布过于集中问题多出现于FP32数据集中，以下以FP32数据为示例，对上述通过桶规模参数来进行数据元素的均衡分布的方式，简称为scale方式，进行示例性说明，如图2F所示。

在图2F中，浮点数类型的数据元素占据32bit，每次pass（轮次） 12bit。一个浮点数a和一个浮点数b如果在第一轮pass中不能被区分（图中第0个bit位代表符号，第1-8bit代表指数（下面的k），第9-11bit代表尾数的前三位（下面的x和y的前3个bit）），则它们必须满足以下条件：

（1）符号位相同，指数位相同；

（2）基于一假设a = 1.x * 2^k，b = 1.y * 2^k，此时尾数位第1、2、3位为1时分别 代表2^（k-1）、2^（k-2）、2^（k-3），因为a和b在尾数位的前三位也不能有区别，则它们的差值 必须满足：

（3）基于以上可以看出，通过乘法实现scale方式的不可行性，因为都乘以一个参 数s时，式子左边变成了：

（4）而当采用减法时，假定一个极端分布

（5）其中，对于

由上，通过桶规模参数的方式，可以有效改善radix select计算针对稠密数据分布的计算鲁棒性。

而对于通过扩大数据位宽度的方式，则可在根据原数据位宽进行桶数量设定的基础上，通过扩大数据位宽来增加更多的桶数量。示例性地，对于8bit，原桶数量为2

需要说明的是，在上述计算过程中，除待进行计算处理的原始数据及计算获得的结果数据外，还会产生大量的中间数据，所有这些数据都可使用显存进行存储和访问。因此，也可以认为，显存为上述radix select计算任务提供的存储和访问支持。

通过本实施例，在使用GPU基于radix select算法进行数据元素选择时，与传统的针对每组数据元素在每次迭代计算时，依次进行串行处理，导致产生大量的访存操作不同，而是针对radix select计算过程中的每个计算节点，从中选取部分或全部，以在选出的相应计算节点，对每组数据元素进行访存加速处理。因访存加速处理可通过一次操作写入或读出多个相应的数据，由此，大大降低了radix select计算过程中的原子访存操作的数量。从而，大大地降低了GPU的radix select计算的计算开销，提升了GPU访存性能。

总体来说，本实施例的方案具有较高的通用性，第一方面，因设置了块共享存储空间、内核共享存储空间等，使得单个kernel需要的资源和K无关，因此在不损失性能的前提下，可以支持任意大的K；第二方面，通过单任务模块的多种访存加速处理，有效改善了访存的性能；第三方面，提供了针对多 batch 场景的方案，在该多 batch 场景下，不仅不损失性能，甚至可能提高性能（因单 batch 可通过单任务模块加速）；第四方面，通过一种均衡数据分布，有效改善了radix select算法针对高偏度数据的鲁棒性结果。

参照图3，示出了根据本申请实施例的一种数据选择方法的步骤流程图。

本实施例的数据选择方法包括以下步骤：

步骤S202：获取待进行基数选择计算的多个数据元素。

该多个数据元素可以为任意需使用radix select算法进行排序的场景下的数据，如，推荐算法所涉及的数据元素等。

当本实施例的方案场景为多radix select计算任务的batch场景时，本步骤还可实现为：获取多个基数选择计算任务中每个基数选择计算任务对应的多个数据元素。

步骤S204：针对基数选择计算的计算节点中的至少部分计算节点，根据GPU的计算性能，对多个数据元素中与至少部分计算节点的计算相关的数据元素，进行至少部分计算节点对应的计算的访存加速处理。

其中，GPU的计算性能包括但不限于GPU的硬件算力和/或显存的存储能力。

本实施例中，可将radix select算法对应于多个计算节点，至少包括：桶计数节点、候选数据元素选择节点、和过滤节点。

基于此，在一种可行方式中，可以针对radix select计算的计算节点中的全部计算节点，根据GPU的硬件算力，对多个数据元素中与各计算节点的计算相关的数据元素，进行各计算节点对应的计算的访存加速处理；和/或，针对radix select计算的计算节点中的部分计算节点，根据GPU的计算性能（如硬件算力和/或显存的存储能力），对多个数据元素中与部分计算节点的计算相关的数据元素，进行部分计算节点对应的计算的访存加速处理。

当针对计算节点中的全部计算节点进行访存加速处理时，一种可行方式中，可根据GPU的硬件算力，在各计算节点的单次计算中，从多个数据元素中选取至少两个数据元素，进行各个计算节点的并行计算。在一个示例中，可采用packing方式，使得radix select计算减少访存次数、提高访存效率。

而若针对的是部分计算节点时，可以存在以下访存加速处理方式中的至少一种：

方式一：当计算节点为桶计数节点时，根据GPU的硬件算力，从执行桶计数节点对应的桶计数操作中的线程中，选择出目标线程，通过目标线程执行计数操作。

例如，当计算节点为桶计数节点时，可以根据GPU的硬件算力，确定执行桶计数节点对应的桶计数操作中的计数器操作的至少一个线程束（warp），针对每个线程束，从该线程束的线程中，选择出目标线程，通过目标线程执行其所属的线程束中所有线程的计数器操作；和/或，确定执行桶计数操作中的计数器操作的至少一个线程块(block)，针对每个线程块，从该线程块的线程中，选择出目标线程，通过目标线程执行其所属的线程块中所有线程的计数器操作。

方式二：当计算节点为候选数据元素选择节点时，根据显存的存储能力，配置块共享存储空间，以将选择出的候选数据元素存储至块共享存储空间，并在达到预设条件时，将块共享存储空间中的候选数据元素一次性写入全局存储空间。

例如，当计算节点为候选数据元素选择节点时，根据显存的存储能力，为执行候选数据元素选择节点对应的元素选择操作的至少一个线程块，配置块共享存储空间，以将选择出的候选数据元素存储至块共享存储空间，并在候选数据元素的占用空间达到预设空间阈值时，将候选数据元素一次性写入全局存储空间。其中，块共享存储空间的空间大小设置为：数据包向量所占空间与线程块中线程数量的乘积的两倍。

方式三：当计算节点为过滤节点时，根据显存的存储能力，配置内核共享存储空间，以将待过滤的数据元素存储至内核共享存储空间并进行过滤操作，以获得基数选择计算结果。

例如，当计算节点为过滤节点时，根据显存的存储能力，为执行过滤节点对应的过滤操作的过滤器内核配置内核共享存储空间，以将待过滤的数据元素存储至内核共享存储空间并进行过滤操作，以获得基数选择计算结果。其中，内核共享存储空间的空间大小可以设置为：基数选择计算的目标数据元素的数量与单个数据元素所占空间的乘积。

通过上述多维度的访存优化，实现了更加高效、实用的radix select算法。

此外，当本实施例的方案场景为多radix select计算任务的batch场景时，本步骤还可实现为：针对每个基数选择计算任务对应的计算节点中的至少部分计算节点，根据GPU的硬件算力和/或显存的存储能力，对多个数据元素中与至少部分计算节点的计算相关的数据元素，进行至少部分计算节点对应的计算的访存加速处理。

在一种可行方式中，若GPU硬件资源足够，则多个radix select计算任务可在每一轮次都进行并行处理。但在实际应用中，radix select计算任务通常会在第一轮迭代中占用较多的资源，因此，在另一种可行方式中，可以根据GPU的硬件算力，对并行执行的多个radix select计算任务中的第一轮迭代任务进行串行处理，而其它迭代轮次的计算任务进行并行处理。

此外，在进行多个radix select计算任务的并行处理时，各个任务的输入地址可能并不相同，也会导致访存性能的下降。为此，在一种可行方式中，多任务模块还用于对并行执行的多个radix select计算任务进行输入地址对齐处理；并在对齐处理后并行执行多个radix select计算任务。

具体地，多个radix select计算任务的并行处理情形下，所有radix select计算任务的输入是一块拼在一起的连续内存，起始位置以 offset 形式给出，可能并没有对齐到 PACK，导致访存性能下降。为此，可以向前padding，以使多读入的elements局限在(block 0, thread 0)，进而单独处理（如丢弃）即可。

可选地，为提高radix select算法本身的鲁棒性，在一种可行方式中，单任务模块还可以基于预设的桶规模参数和/或扩大的数据位宽度，在桶计数节点对多个数据元素进行桶计算操作，以均衡多个数据元素在对应的多个桶中的分布。其中，桶规模参数通过对多个数据元素的均摊分析确定；该桶规模参数用于通过对多个数据元素进行减法操作，均衡多个数据元素在对应的多个桶中的分布，改善radix select计算针对高偏度数据分布的计算鲁棒性。

步骤S206：根据访存加速处理结果，获得多个数据元素的基数选择计算结果。

当上述过程为单radix select计算任务场景下的过程时，则本步骤中，可基于访存加速处理结果及radix select计算结果，获得最终的多个数据元素中的第K个数据元素，或者，前K大或前K小的数据元素。

当本实施例的方案场景为多radix select计算任务的batch场景时，本步骤还可实现为：根据每个基数选择计算任务对应的访存加速处理结果，获得多个数据元素的基数选择计算结果。在该场景下，每一个radix select计算任务都可获得最终的多个数据元素中的第K个数据元素，或者，前K大或前K小的数据元素。

通过本实施例，在使用GPU基于radix select算法进行数据元素选择时，与传统的针对每组数据元素在每次迭代计算时，依次进行串行处理，导致产生大量的访存操作不同，而是针对radix select计算过程中的每个计算节点，从中选取部分或全部，以在选出的相应计算节点，对每组数据元素进行访存加速处理。因访存加速处理可通过一次操作写入或读出多个相应的数据，由此，大大降低了radix select计算过程中的原子访存操作的数量。从而，大大地降低了GPU的radix select计算的计算开销，提升了GPU访存性能。

需要说明的是，本实施例的数据选择方法可通过前述GPU的计算部件和显存实现，本实施例中各步骤的描述较为简单，相关部分可参照前述GPU实施例中相关部分的描述即可。

参照图4，示出了根据本申请实施例的一种芯片的结构框图。本实施例的芯片包括前述实施例中所描述的GPU。但不限于此，本领域技术人员可根据实际需求，在该芯片上设置除GPU之外的其它电子部件，以实现实际所需的功能，包括但不限于CPU等，本申请实施例对此不作限制。任何的、设置有本申请实施例中所描述的GPU的芯片均在本申请的保护范围内。

需要指出，根据实施的需要，可将本申请实施例中描述的各个部件/步骤拆分为更多部件/步骤，也可将两个或多个部件/步骤或者部件/步骤的部分操作组合成新的部件/步骤，以实现本申请实施例的目的。

上述根据本申请实施例的方法可在硬件、固件中实现，或者被实现为可存储在记录介质（诸如CD ROM、RAM、软盘、硬盘或磁光盘）中的软件或计算机代码，或者被实现通过网络下载的原始存储在远程记录介质或非暂时机器可读介质中并将被存储在本地记录介质中的计算机代码，从而在此描述的方法可被存储在使用通用计算机、专用处理器或者可编程或专用硬件（诸如ASIC或FPGA）的记录介质上的这样的软件处理。可以理解，计算机、处理器、微处理器控制器或可编程硬件包括可存储或接收软件或计算机代码的存储组件（例如，RAM、ROM、闪存等），当所述软件或计算机代码被计算机、处理器或硬件访问且执行时，实现在此描述的方法。此外，当通用计算机访问用于实现在此示出的方法的代码时，代码的执行将通用计算机转换为用于执行在此示出的方法的专用计算机。

本领域普通技术人员可以意识到，结合本文中所公开的实施例描述的各示例的单元及方法步骤，能够以电子硬件、或者计算机软件和电子硬件的结合来实现。这些功能究竟以硬件还是软件方式来执行，取决于技术方案的特定应用和设计约束条件。专业技术人员可以对每个特定的应用来使用不同方法来实现所描述的功能，但是这种实现不应认为超出本申请实施例的范围。

以上实施方式仅用于说明本申请实施例，而并非对本申请实施例的限制，有关技术领域的普通技术人员，在不脱离本申请实施例的精神和范围的情况下，还可以做出各种变化和变型，因此所有等同的技术方案也属于本申请实施例的范畴，本申请实施例的专利保护范围应由权利要求限定。