<figure><img src="image_1.png" /></figure>

ifip

International Federation for Information Processing

This document is the original author manuscript of a paper submitted to an IFIP
conference proceedings or other IFIP publication by Springer Nature. As such, there
may be some differences in the official published version of the paper. Such
differences, if any, are usually due to reformatting during preparation for publication or
minor corrections made by the author(s) during final proofreading of the publication
manuscript.
# Exploiting heterogeneity in PIM architectures
for data-intensive applications

Rafael Fão de Moura¹ and Luigi Carro¹

Informatics Institute - Federal University of Rio Grande do Sul - Porto Alegre, Brazil
{rfmoura, carro}@inf.ufrgs.br

**Abstract.** The scaling of common architectures for data-intensive applications is limited by the memory wall issues that culminate in energy and performance losses. Near-data or Processing in Memory (PIM) approach has been revisited to tackle this problem, along with a wide variety of architectural designs. However, these devices commonly rely on Application Specific Integrated Circuit (ASIC) designs, which in turn fail to cover the heterogeneity found in such applications. This paper discusses and exploits the heterogeneity present in the data-intensive realm by using a range of permutations for the tuple (algorithm, dataset, programming language). Relying on commonplace hardware performance metrics, we show how to identify the main changes in the processing demands and select the best near-data configuration. Using the proposed strategy, one could see a performance difference of 1.52x, and an Energy Delay Product of 2.86x in the studied examples.

**Keywords:** Data-intensive applications · Near-data · Heterogeneous processing.

## 1 Introduction

Today's hardware and software industries have witnessed rapid growth in the realm of data-intensive applications. The processing of Neural Networks (NNs), data science, and the Internet of Things (IoT) inhibits both the scaling and the straightforward adoption of common architectures, giving their high energy consumption and slowdown, and unexploited performance potential. Such energy and performance losses are caused by the massive off-chip communication and data movements performed along the memory hierarchy. For example, up to 59% of the total processing time of the NN AlexNet and 81% of the polybench suite are spent in the cache hierarchy [7, 20].

Hence, and in addition to the constraints imposed by the end of Dennard scaling and Moore's law [5], computer architects are required to develop solutions to extract performance providing the best speedup and energy savings for these modern application domains [21]. Alternatively, the concept of near-data processing or Processing in Memory (PIM) conceives a mature solution for this problem. By placing computing units closer to where the data resides and bypassing the memory bottleneck, the desired computing capabilities can
be achieved. Thus, several near-data designs have been proposed, most of them
relying on the specialization of Functional Units (FUs) for a specific group of
algorithms [12].

Designing specialized hardware for algorithms undoubtedly provides the best gains, but lacks versatility and fails to cover the heterogeneity that the actual industry scenario may exhibit, especially when adding new variables to be optimized: the **dataset** and the **programming language**. Regarding the dataset, several algorithms are known to scale their processing demands according to the input size. As an example of this property, in the YOLOv3 NN, for inputs of 320x320, 416x416, and 608x608 pixels, this processing requires 39, 66, and 141 GFLOPS (Billions of Floating-Point Operations Per Second) [18], which configures a polynomial growth, but still predictable demand. However, heterogeneous demands appear in applications where the input data's meaning dictates the processing flow (i.e., graphs and pointer chasing, genomics, decision problems) [27].

When adding the programming language, a new horizon of possibilities and
constraints opens. Targeting fast software development and a short Time to Mar-
ket (TTM), according to Cass et al. [4], five out of 10 of the top programming
languages of 2020 are interpreted or require a Virtual Machine (VM) to run, with
the two most popular belonging for this class. Building ASIC accelerators for
VMs is certainly a challenging task, since they are known to present a plethora
of different operations. Looking only at how the two most used interpreted lan-
guages work (Java and Python), the Java bytecode's processing configures a
stack machine, while Python bytecode follows a load-store-like architecture [24,
8]. Hence, several approaches try translating the input application to a synthe-
sizable version, such as the High-Level Synthesis (HLS) and Pynq tools [15].
However, such tools provoke several ruptures caused by the high-level language
development cycle, since they cannot sustain the same generality and resources
the original programming language offers.

The main **problem** that this paper tackles is to call attention to the het-
erogeneity found in the processing of current data-intensive applications. As our
**goal**, we present clues on how to exploit these traits in the future of near-data
architectures. By varying parameters in the tuple (algorithm, dataset, program-
ming language), we collect and identify the hardware implementation possibili-
ties that give us directions on choosing the best near-data configuration for the
given iteration.

The following section presents an overview of state-of-the-art near-data ar-
chitectures according to the FU type present in the design. Also, a discussion
about the main features of performance and energy harvesting is made. Section
3 discusses heterogeneity found in data-intensive execution, and points out how
future near-data engines could benefit from it. Following the related works, we
select the most straightforward design that offers the best versatility for het-
erogeneous processing demands, and introduces the near-data architecture for
data-intensive applications in Section 4. Section 5 describes the methodology
used to compare the efficiency metrics of each scenario explored, and we explore
the design space of the in-memory General Purpose Processor (GPP) and cache,
and compile the results. Finally, Section 6 concludes the paper and enumerates
the next steps of this work.

## 2 Background and related work

This section provides an overview of fundamental aspects and a description of state-of-the-art near-data architectures. As aforesaid, the main goal of performing computation closer to where the data resides is to exploit the smaller latency and higher memory bandwidth, which is internally available in the memory device. Regarding the integration model, most PIM designs rely on stacking custom logical fabric in a 3D-DRAM arrangement [1-3, 23]. However, processing elements can also be placed at different levels of the memory hierarchy and combined with different memory technologies. Once several near-data designs have been proposed and studied, we follow the PIM categorization into three classes, as proposed by de Lima et al.[12] and illustrated in Fig. 1.

<figure><img src="image_2.png" /><figcaption>Fig. 1: Overview of different PIM classes</figcaption></figure>

- **Non-computable logic in-memory:** As the name suggests, this class of PIM does not properly perform computation inside the main memory. Instead, logic in-memory is added to provide software-transparent operations, such as atomic and non-cacheable instructions. An example of this type of PIM is Micron's HMC, which incorporates a proper Instruction Set Architecture (ISA) to support several memory operations [16].

- **Fixed-function PIM:** This class encloses devices with pre-defined or fixed operations, which are established by custom logic design (ASICs) attached to the main memory, or even the organization or an intrinsic property of the memory. As their main feature, such PIM devices are tuned to compute an
algorithm or a set of procedures, relying on the specialization of processing. Hence, such an approach undoubtedly delivers the best gains in performance and energy. As an example of this approach, we refer to Zhuo et al.[27] that adopts ASIC accelerators coupled to a DRAM module to accelerate graph processing, and Wang et al. [25] that exploits intrinsic dot-product operations in an RRAM device to accelerate NNs. However, the two main drawbacks of this approach are the lack of versatility for general-purpose processing, and the disruption of software development and basic Operating Systems (OS) foundations.

- **Fully programmable PIM:** The last class comprises complete or simplified general-purpose processors with the basic blocks required to fetch, decode and execute instructions. Since these devices do not lean on the specialization of the processing, they harvest performance by lessening the memory wall effects due to the poverty of data locality. To represent this class, we refer to [17, 6, 13, 26]. The big advantage of this approach is its straightforward implementation, since it provides natural compatibility with SO and programming language resources.

## 3 PIM opportunities for heterogeneous data-intensive processing

This section conducts a design space exploration to highlight the processing heterogeneity in the data-intensive realm. We analyze how permutations in the (algorithm, programming language, dataset) tuple dictate/impact overall system and hardware counters' performance. Hence, we select a few data-intensive algorithms, running a C and a Python version, over different datasets. The choice for C and Python stems from the fact that these two languages occupy the first position, regarding low and high-level languages, respectively, in the ranking of most used languages in 2020 [4]. Then, based on the experiments, we disclose heuristics for designing future near-data architectures for data-intensive applications.

Table 1 and Fig. 2 present a compilation of the system’s performance metrics and execution time breakdown for different iterations. The algorithm’s running was conducted on an Intel10500 GPP platform, coupled to an 8GB@2666MHz DDR4 DRAM. The applications chosen are the Breadth-First Search (BFS) and Page rank. BFS and Page rank’s selection comprises two common ways of data representation and processing within the data-intensive realm: linked-lists management/pointer chasing (BFS), and matrix operations (Page rank). The tags small and big refer to the graph datasets mouse-retina-1 and twitter-higgs respectively, both extracted from [19]. Aiming to identify the guidelines to decide whether to execute a data-intensive application on a near-data architecture, we target hardware counters that reflect the overall performance (CPU cycles) and the memories’ status (Prefetch hit ratio, Data-cache Level One (DL1) hit ratio, as DL2 and DL3 hit ratios).

The main observations regarding the results are:
<table><caption>Table 1: System's performance indicators for running different permutations of (algorithm, language, dataset).</caption><thead><tr><th>Algorithm</th><th>Language</th><th>Input size</th><th>CPU cycles (thousands)</th><th>Mem. inst.(%)</th><th>Prefetch hit(%)</th><th>DL1 hit(%)</th><th>DL2 hit(%)</th><th>DL3 hit(%)</th></tr></thead><tbody><tr><td rowspan="4">BFS</td><td rowspan="2">C</td><td>small</td><td>524</td><td>40</td><td>32</td><td>92</td><td>53</td><td>35</td></tr><tr><td>big</td><td>747.499</td><td>41</td><td>20</td><td>73</td><td>34</td><td>43</td></tr><tr><td rowspan="2">Python</td><td>small</td><td>4.925</td><td>49</td><td>46</td><td>99</td><td>63</td><td>82</td></tr><tr><td>big</td><td>55.880.176</td><td>60</td><td>24</td><td>88</td><td>11</td><td>99</td></tr><tr><td rowspan="4">Page rank</td><td rowspan="2">C</td><td>small</td><td>8.003</td><td>45</td><td>54</td><td>97</td><td>54</td><td>93</td></tr><tr><td>big</td><td>27.692.649</td><td>44</td><td>12</td><td>84</td><td>26</td><td>46</td></tr><tr><td rowspan="2">Python</td><td>small</td><td>524.511</td><td>54</td><td>57</td><td>98</td><td>95</td><td>96</td></tr><tr><td>big</td><td>614.118.403</td><td>54</td><td>27</td><td>95</td><td>86</td><td>64</td></tr></tbody></table>

- Python applications spend more cycles on CPU and DL1, and perform a larger number of memory accesses than the C counterpart. This result suggests a higher demand for processing and more pressure over the memory system due to the VM's presence. In fact, according to Ismail et al. [9], up to 70% of the processing time of Python applications is spent running the VM's routines instead of the algorithm itself.

- The two leading indicators when increasing the input size are the CPU cycles, and the prefetch hit ratio. It is predictable to have more CPU cycles as we increase the input size. However, as a big dataset is used as input, the prefetch hit ratio drastically decreases. Such reduction may indicate poor data locality, reflecting a lower hit ratio on the cache levels.

<figure><img src="image_3.png" /><figcaption>Fig. 2: Execution time breakdown for several (algorithm,language,dataset) permutations</figcaption></figure>

It is possible to conclude that there exists heterogeneity in terms of processing demands in the data-intensive realm. One can observe that a single/one variable
change of the experimented tuple leads to different time percentages spent on
memories and CPU, but with contrasting behaviors. For example, to accelerate
the Page rank algorithm over the big dataset, we do not need to put our efforts
on the CPU or the DL1 cache. However, considering the same experiment, if we
choose to run it on a Python VM, now CPU and DL1 are a bottleneck for the
execution. Hence, an efficient design of future near-data engines must consider
such algorithm, language, and size-related impacts, as will be presented in the
following section.

4 Near-data architecture for heterogeneous execution

As presented in Section 2, the Fully-programmable class of PIM offers the best tradeoff regarding versatility and performance. Hence, based on the opportunities for heterogeneous processing in data-intensive applications in Section 3, we select this class as the base for our PIM model. Fig. 3 presents the PIM datapath to be explored in our design space exploration. As one can observe, the three main blocks that compose our design are a GPP host processor, the 3D-stacked memory arrangement, and the near-data processor built on the memory’s logic layer.

<figure><img src="image_4.png" /><figcaption>Fig. 3: Near-data architecture datapath</figcaption></figure>

**Migrating the execution to PIM** Since we claim to deliver versatility allied to software/binary compatibility, the central premise of our design is to keep both host and PIM CPUs running under the same ISA. This decision relieves us of setting up an *offloading mechanism* to dispatch near-data instructions. Instead, our architecture moves the application’s context along with the host-PIM pair.

The hardware component responsible for triggering and coordinating the mi-
gration of an application to the near-data processor is the *PIM monitor*. The
PIM monitor works by watching the host CPU's performance counters and evaluating whether the application can benefit from moving its execution to the near-data CPU. Relying on the experiments conducted in Section 3, the most straightforward way to determine the feasibility of near-data execution for a data-intensive application is based on the data locality diagnosis. Hence, we chose the memory's prefetch hit ratio as the metric to indicate such data locality. This approach simplifies the heuristic to choose whether to execute on the near-data CPU: *if the memory's prefetch hit ratio is less than a threshold, move the execution to PIM*.

Once the PIM monitor detects the near-data as the target processor, the
following steps are performed to pair the host and near-data CPUs:

1. Host CPU flushes its pipeline.

2. Host and near-data CPUs synchronize their states by transferring all the physical register's values.

3. Data coherence protocol starts, as explained below.

4. The host CPU is set to a low-power state.

5. Near-data CPU starts processing according to the last Program Counter (PC)'s value.

**Keeping data coherent** Keeping data coherence in PIM architectures must
handle shared data between host processors, the cache hierarchy, and the main
memory with its logic layer (where the near-data CPU resides). Since both the
near-data and the host CPUs may have access to a shared memory region, tra-
ditional data coherence mechanisms (e.g., the MOESI protocol) are not enough
for this task. Adopting current data coherence protocols entails heavy traffic of
snooping messages, since the narrow communication channel between memories
in the hierarchy may introduce losses for bandwidth and time. Thus, we opt to
synchronize the host-near-data CPUs pair only during an application's migration
to minimize overhead and keep data coherent throughout a fine-grain protocol.
Hence, the PIM monitor coordinates all actions regarding data coherence at the
third step of an application's migration, as indicated above.

The proposed data coherence management works: after the host CPU flushes
its pipeline and synchronizes its state with the near-data pair, the PIM monitor
sends a flush request to the first data cache level (DL1) for all the cache blocks
having their dirty bit status set. All flush requests are transmitted from the DL1
and forwarded to the next cache level until they arrive at the main memory,
where the requests are sent back to the PIM monitor. Inside each cache level, the
flush requests are treated as lookups: if there is a cache block match, a writeback
or an invalidate command is enqueued in the write buffer of the current cache
level. One can notice that the proposed mechanism does not replace the role of
current data coherence protocols. Hence, any existing cache coherence, such as
MOESI, must be in charge of this task.

**Enabling VM processing on PIM** As Section 3 explored, applications that
still present considerable levels of data locality may still benefit from near-data
execution. Also, the high-level languages running on VMs reveal a particular case: the VM's data locality inhibits a straightforward (CPU directly coupled to the main memory) PIM adoption. Thus, as shown in Fig. 3, we add a DL1 to our near-data CPU to enable the VM execution on PIM devices. Similarly, as performed by the PIM monitor, the *Locality monitor* watches the DL1's hit ratio of the near-data CPU to decide whether to enable caching in the PIM execution. Likewise, *if the DL1's hit ratio is less than a threshold, the locality monitor performs flushes for all dirty blocks in the DL1 and turns it off*.

# 5 Experimental setup and results

## 5.1 Evaluation setup

This section presents the methodology used to evaluate the near-data mechanism. To provide broad coverage for the design space exploration of (algorithm, language, dataset) tuple and a heterogeneous setup, we select several data-intensive algorithms, with C and Python implementations, running on big and small datasets. We pick the BFS, Page rank, Apriori, and CRISPR-CAS9 synthesis as algorithms. For the BFS and Page rank, we refer to the datasets mouse-retina-1 and Twitter-Higgs as the small and big datasets, respectively. Apriori algorithm runs the NYC Small Business Services dataset [14]. CRISPR-CAS9 uses the human genome (hg38), taken from [10].

<table><caption>Table 2: Hardware setup.</caption><thead><tr><th>Scenario</th><th>HW setup</th></tr></thead><tbody><tr><td rowspan="5">Baseline</td><td>8-issue@2GHZ OoO RISCV CPU</td></tr><tr><td>32kB IL1/DL1 cache</td></tr><tr><td>256kB L2 cache</td></tr><tr><td>16MB L3 cache</td></tr><tr><td>8GB DDR4@2666Mhz DRAM</td></tr><tr><td rowspan="3">2-issue PIM</td><td>2-issue@2GHZ OoO RISCV CPU</td></tr><tr><td>32kB IL1/DL1 cache</td></tr><tr><td>8GB DDR4@2666Mhz DRAM</td></tr><tr><td rowspan="3">8-issue PIM</td><td>8-issue@2GHZ OoO RISCV CPU</td></tr><tr><td>32kB IL1/DL1 cache</td></tr><tr><td>8GB DDR4@2666Mhz DRAM</td></tr></tbody></table>

Also, we synthesize two different Out-of-Order (OoO) configurations using the RISCV rocket chip generator [11]. Then, we set up two near-data CPUS comprising the 2-issue and the 8-issue CPUS with IL1 and DL1 caches, as described in Table 2. As the host processor and baseline for all the results, we refer to the 8-issue OoO, with $L1, $L2, and $L3. To accurate our simulation, we have implemented all the mechanisms mentioned in Section 4 on the NDA framework presented in [22].
## 5.2 Results

To support further evaluation of the two experimented near-data setups, we present in Table 3 a compilation of the hardware counters taken as indicators for the PIM monitor and Data locality blocks to decide whether to execute on near-data and caching the applications.

<table><caption>Table 3: Hardware counters compilation.</caption><thead><tr><td>Scenario</td><td>DL1 hit(%)</td><td>Prefetch hit(%)</td></tr></thead><tbody><tr><td>BFS_C:small</td><td>92</td><td>32</td></tr><tr><td>BFS_C:big</td><td>72</td><td>20</td></tr><tr><td>BFS_PY:small</td><td>99</td><td>46</td></tr><tr><td>BFS_PY:big</td><td>99</td><td>24</td></tr><tr><td>Page_rank_C:small</td><td>97</td><td>54</td></tr><tr><td>Page_rank_C:big</td><td>84</td><td>12</td></tr><tr><td>Page_rank_PY:small</td><td>98</td><td>57</td></tr><tr><td>Page_rank_PY:big</td><td>96</td><td>27</td></tr><tr><td>CRISPR_PY:big</td><td>99</td><td>53</td></tr><tr><td>Apriori_PY:big</td><td>98</td><td>31</td></tr></tbody></table>

Fig. 4 presents the speedup and the normalized Energy Delay Product (EDP) over the baseline for all the experimented scenarios. Regarding the 8-issue PIM scenario, which has the same CPU configuration as the baseline, one can observe speedup values ranging from 1.02x to 1.52x. In several cases, the most significant performance gains occur with the employment of big datasets, since these scenarios present poor data locality (Table 3) and benefit more from near-data execution. Further, changing the programming language from C to Python reveals a diminished but favorable acceleration. Compared to the C counterparts, the smaller speedup that Python scenarios present arises due to the necessity of a DL1 and the interpreter/VM's overhead.

<figure><img src="image_5.png" /><figcaption>Fig. 4: Speedup and EDP for the experimented scenarios</figcaption></figure>
Also, when examining the EDP results, gains vary from 1.03x to 2.48x. These
results expose, on average, more expressive reductions in energy consumption
than speedup. Such more significant energy reduction occurs due to the absence
of the elevated levels of power dissipated in the intermediate cache levels along
the memory hierarchy. Moreover, it is known that the SRAM cells composing
current cache memories present a higher power density than DRAM and CPU's
circuitry, leading to the results. Likewise, those scenarios with big datasets and
C as the programming language present the most significant EDP improvements.

With the employment of a smaller (in terms of processing power), 2-issue
OoO CPU in the near-data engine, two new points come to analysis: First, there
is a noticeable reduction of the presented speedup values, sometimes leading to
a slowdown (values less than one). The such slowdown can be expected, since
we are decreasing the number of instructions the CPU can issue and execute by
a factor of four times, on average. However, the most remarkable observation
regarding performance is that Python's VM benefits better from a smaller CPU.
To disclose such behavior, we present Fig. 5, which shows the average Cycles Per
Instruction (CPI) metric for C and Python execution, when ranging the number
of issues in the OoO processor.

<figure><img src="image_6.png" /><figcaption>Fig. 5: Average CPI values for different issue sizes</figcaption></figure>

Such property unearthed on the execution of the Python VM leads to the
second point of interest in analyzing a 2-issue CPU as the near-data engine: the
Python scenario has better EDP results than the C counterpart, achieving 2.86x
gains over the baseline. On average, the setup of a smaller CPU (replacing the
8-issue for a 2-issue) introduces 1.4x and 2.6x of slowdown for Python and C
applications, respectively. However, the 8-issue CPU dissipates up to five times
more power than the 2-issue, reducing energy consumption and boosting the
EDP gains.
# 6 Conclusion and future work

This paper presents and discusses the heterogeneity found in executing data-
intensive applications. Through the design space exploration of (algorithm, lan-
guage, dataset) permutations, we disclaimed how the dataset size and the em-
ployment of high-level interpret languages require different processing demands,
thus raising opportunities for future near-data processing. Then, we built two
near-data engines to run and adapt their execution by supporting on-the-fly
processing requirements. Evaluation results reported EDP gains up to 2.86x,
with Python applications benefiting from adopting smaller OoO CPUs. In fu-
ture work, we intend to study heterogeneous CPUs inside a Big-Little approach
to exploit high-level language demands for processing better.

References

1. Ahn, J., Hong, S., Yoo, S., Mutlu, O., Choi, K.: A scalable processing-in-memory accelerator for parallel graph processing. In: Proceedings of the 42nd Annual International Symposium on Computer Architecture. pp. 105–117 (2015)

2. Alves, M.A., Diener, M., Santos, P.C., Carro, L.: Large vector extensions inside the hmc. In: 2016 Design, Automation & Test in Europe Conference & Exhibition (DATE). pp. 1249–1254. IEEE (2016)

3. Azarkhish, E., Rossi, D., Loi, I., Benini, L.: Design and evaluation of a processing-in-memory architecture for the smart memory cube. In: International Conference on Architecture of Computing Systems. pp. 19–31. Springer (2016)

4. Cass, S.: The top programming languages: Our latest rankings put python on top-again-[careers]. IEEE Spectrum 57(8), 22–22 (2020)

5. Dennard, R.H., Gaensslen, F.H., Yu, H.N., Rideout, V.L., Bassous, E., LeBlanc, A.R.: Design of ion-implanted mosfet’s with very small physical dimensions. IEEE Journal of Solid-State Circuits 9(5), 256–268 (1974)

6. Drumond, M., Daglis, A., Mirzadeh, N., Ustiugov, D., Picorel, J., Falsafi, B., Grot, B., Pnevmatikatos, D.: The mondrian data engine. ACM SIGARCH Computer Architecture News 45(2), 639–651 (2017)

7. Gonçalves, L.R., Moura, R.F.D., Carro, L.: Aggressive energy reduction for video inference with software-only strategies. ACM Transactions on Embedded Computing Systems (TECS) 18(5s), 1–20 (2019)

8. Ike-Nwosu, O.: Inside the python virtual machine (2015)

9. Ismail, M., Suh, G.E.: Quantitative overhead analysis for python. In: 2018 IEEE International Symposium on Workload Characterization (IISWC). pp. 36–47. IEEE (2018)

10. Kent, W.J., Sugnet, C.W., Furey, T.S., Roskin, K.M., Pringle, T.H., Zahler, A.M., Haussler, D.: The human genome browser at ucsc. Genome research 12(6), 996–1006 (2002)

11. Lee, Y.: Risc-v “rocket chip” soc generator in chisel. In: Online slides:” https://riscv.org/wp-content/uploads/2015/01/riscv-rocket-chip-generator-workshop-jan2015.pdf (2015)

12. de Lima, J.P.C., Santos, P.C., Alves, M.A., Beck, A.C., Carro, L.: Design space exploration for pim architectures in 3d-stacked memories. In: Proceedings of the 15th ACM International Conference on Computing Frontiers. pp. 113–120 (2018)
13. Nair, R., Antao, S.F., Bertolli, C., Bose, P., Brunheroto, J.R., Chen, T., Cher, C.Y., Costa, C.H., Doi, J., Evangelinos, C., et al.: Active memory cube: A processing-in-memory architecture for exascale systems. IBM Journal of Research and Development 59(2/3), 17–1 (2015)

14. Okamoto, K.: What is being done with open government data? an exploratory analysis of public uses of new york city open data. Webology 13(1) (2016)

15. O'Loughlin, D., Coffey, A., Callaly, F., Lyons, D., Morgan, F.: Xilinx vivado high level synthesis: Case studies (2014)

16. Pawlowski, J.T.: Hybrid memory cube (hmc). In: 2011 IEEE Hot Chips 23 Symposium (HCS). pp. 1–24. IEEE (2011)

17. Pugsley, S.H., Jestes, J., Zhang, H., Balasubramanian, R., Srinivasan, V., Buyuktosunoglu, A., Davis, A., Li, F.: Ndc: Analyzing the impact of 3d-stacked memory+logic devices on mapreduce workloads. In: 2014 IEEE International Symposium on Performance Analysis of Systems and Software (ISPASS). pp. 190–200. IEEE (2014)

18. Redmon, J., Farhadi, A.: Yolov3: An incremental improvement. arXiv preprint arXiv:1804.02767 (2018)

19. Rossi, R.A., Ahmed, N.K.: An interactive data repository with visual analytics. SIGKDD Explor. 17(2), 37–41 (2016), http://networkrepository.com

20. Santos, P.C., de Lima, J.P., de Moura, R.F., Alves, M.A., Beck, A.C., Carro, L.: Enabling near-data accelerators adoption by through investigation of datapath solutions. International Journal of Parallel Programming 49(2), 237–252 (2021)

21. Santos, P.C., Oliveira, G.F., Tomé, D.G., Alves, M.A., Almeida, E.C., Carro, L.: Operand size reconfiguration for big data processing in memory. In: Design, Automation & Test in Europe Conference & Exhibition (DATE), 2017. pp. 710–715. IEEE (2017)

22. Santos, P.C., de Lima, J.P.C., de Moura, R.F., Ahmed, H., Alves, M.A., Beck, A.C., Carro, L.: Exploring iot platform with technologically agnostic processing-in-memory framework. In: Proceedings of the Workshop on INtelligent Embedded Systems Architectures and Applications. pp. 1–6 (2018)

23. Scrbak, M., Islam, M., Kavi, K.M., Ignatowski, M., Jayasena, N.: Exploring the processing-in-memory design space. Journal of Systems Architecture 75, 59–67 (2017)

24. Venners, B.: The java virtual machine. Java and the Java virtual machine: definition, verification, validation (1998)

25. Wang, Q., Wang, X., Lee, S.H., Meng, F.H., Lu, W.D.: A deep neural network accelerator based on tiled rram architecture. In: 2019 IEEE International Electron Devices Meeting (IEDM). pp. 14–4. IEEE (2019)

26. Zhang, D., Jayasena, N., Lyashevsky, A., Greathouse, J.L., Xu, L., Ignatowski, M.: Top-pim: Throughput-oriented programmable processing in memory. In: Proceedings of the 23rd international symposium on High-performance parallel and distributed computing. pp. 85–98 (2014)

27. Zhuo, Y., Wang, C., Zhang, M., Wang, R., Niu, D., Wang, Y., Qian, X.: Graphq: Scalable pim-based graph processing. In: Proceedings of the 52nd Annual IEEE/ACM International Symposium on Microarchitecture. pp. 712–725 (2019)