Selective OpenCL Code Collection from Online Repositories: an Automated Approach

(1)

Bachelor Informatica

Selective OpenCL Code

Collection from Online

Repositories:

an Automated Approach

Jordy Briggeman

June 8, 2018

Supervisor(s): Ana Lucia Varbanescu

Inf

orma

tica

—

Universiteit

v

an

Ams

terd

am

(2)

(3)

Abstract

Searching the internet for the source code that you want can be a dull task. Fil-tering options are often too general to be of use, or too specific to group certain pieces of code. In this thesis we are going to answer the question whether it is feasible to make an efficient search system that searches online code collections, finds OpenCL code and shows results relevant to the user query. We propose a new tool built from the ground up to search for OpenCL code on GitHub. This tool uses patterns that can often be found in OpenCL to group pieces of code under. After the implementation we evaluate the search system by testing how fast and efficient it is, and by pointing out the limitations. The conclusion is that our system in itself is a proof that it is possible automatically find OpenCL code in online repositories. Using an automated solution as presented in this thesis provides an advantage in the form of speed and ease of use, but also has the disadvantage of potentially missing the interpretation of a human who can quickly determine what piece if code is relevant.

(4)

(5)

Introduction

During the age of the internet it has become increasingly easier over time to find find and share source code. Large in part due to the rise of online code repositories. GitHub is the largest online software development platform as of right now, hosting more than 85 million code repositories [2]. These repositories get used as an online backup for code, and also as a way to easily work together on a project. A lot of GitHub users decide to put there projects public, so that everyone can look at the source code. This makes GitHub the largest online code collection there is, and thus an interesting place to search for specific pieces of code. Developers often use code search to look for specific functionalities in the code, or how to use a certain API [11].

Searching for code in online repositories can be a dull task, because the available search options are often too general to be of any use, or too specific to group certain pieces of code. This is inherent to the way code gets indexed into online code repositories like GitHub: repositories have metadata and the files themselves. The metadata, which enables (some) search operations, includes features like name, date of creation, size, and language. Aside from that, one can search at micro-level, for specific pieces of code within the files themselves. However, when one needs to find pieces of code using certain patterns, these search options are insufficient. Repositories do not really provide a systematic way to perform such a search, probably because the mechanisms could be very dependent on the language of the code, and the external libraries that can be used.

1.1 Research question

In this research we will look at the possibilities of making a user query based search system for finding OpenCL code. OpenCL is a programming model designed and implemented to support portability across multi- and many-core systems [8].

(8)

repositories, and the filter that selects only the data matching the user require-ments. During the crawling, a database is filled with data about specific OpenCL code patterns that have been pre-determined, like the amount of kernels that an OpenCL routine uses, or the device type that is used in the context. Afterwards the user can use the filter to find all pieces of code that portray those patterns. Our system is evaluated for functionality (to determine whether it indeed collects code), for correctness (to determine whether it collects OpenCL code hat matches the user requests), and for performance (to determine how fast the collection happens). The question that we will try to answer during this re-search is: Is it feasible to make an efficient re-search system that re-searches online code collections, finds OpenCL code, and selects and stores only functioning code that fits the user query?

To answer this question we assess the efficiency of the system based on a ratio of the collected code and the amount of effort it took, wherein empirical evidence is provided in the form of a working search system. Other problems include: determining basic functionality, defining acceptable user queries, and the validation and checking of all these criteria.

The product of this project is a prototype OpenCL search system that can return code collections of OpenCL that are suitable for the query that has been given within a reasonable amount of time.

(9)

Chapter 2

Theoretical background

2.1 OpenCL

These days it is very common that a program fully supports multithreading, and parallelism is seen as important progress towards increased performance. Both CPUs and GPUs have developed from single core and fixed function rendering devices to highly parallel processors. Modern systems often contain multiple processing devices, and it is therefore important to be able to let software de-velopers take advantage of heterogeneous processing systems.

There is a reason why it is difficult to build programs for all these different types of processors; they all have different underlying structures. CPUs are largely standardized but typically rely on shared address space and do not have dedicated vector operations. GPUs on the other hand are not standardized across the market, have very complex memory space hierarchies, and do have dedicated vector operations. It is obvious from these examples that it is hard to make a program that can both reliably run on CPUs, GPUs, and other types of devices that were not even mentioned.

OpenCL is a programming interface that opens up the ability to create applications for heterogeneous parallel processing platforms. With the help of OpenCL you can achieve performance portability for HPC solutions. This means no more rewriting for different devices, but instead you write it once, and run it everywhere with comparable performance. [8]

The OpenCL framework consists of three main parts:

• OpenCL Platform layer: Discover devices and create contexts. • OpenCL Runtime: Manipulate contexts with host program

• OpenCL Compiler: Create program executables with kernels. These ker-nels get used during runtime and are written in OpenCL C.

The first two items will be grouped throughout this thesis as ’host’. While the third will be referred to by ’kernel’.

(10)

Figure 2.1: Example of kernel code. Code has been taken from Piero Lanucara of SCAI [6]

Figure 2.2: Example of host code. Code has been taken from Piero Lanucara of SCAI [6]

(11)

The figures above are an example of a simple OpenCL ’routine’. A lot of the host code is boilerplate code. When you want to execute a kernel you always go through the routine the you can see in figure 2.1. First the context gets created for the program. Secondly, memory is allocated for the buffers. Thirdly, the program gets created. Fourthly, the kernel gets created. And finally the kernel gets executed. After that the output can be read by reading the memory buffers. This code could almost be written automatically since it always does the same routine, although there are some slight variations. The biggest choices one makes is what type of device you use to execute your kernel, and which kernel one actually wants to execute.

The example of the kernel code is the most basic version of a kernel that can be created. It simply adds two numbers and returns the answer. Still there are a few interesting details in this code that has to be explained. All the function parameters have ” global” in front of their type. OpenCL supports multiple address spaces, where global is one of them. This simply means that the memory is allocated on the device. There is also a ” kernel” in front of the function return type. In OpenCL you have to indicate that a function is a kernel, since you can also write non-kernel functions that you can call from within a kernel function to help you out. The last thing is the ”get global id” function. This is a typical function for all parallel programming that gets the number of the entry that it needs to get from memory to execute.

2.2 Previous work

There has been some previous research on the general subject of source code search engines. There are multiple ways that you can make a search engine. For example [5] uses a low-level ’code-to-code’ search approach. This means that you use existing code to search for pieces of code that are semantically similar to the input. Another study[7] uses a more high-level input in the form of a description of the ’tactic’ and technical problem, which will be used by machine learning algorithms to determine the best solution. An easier to understand approach to searching code is to use a natural-language inputs for high-level concepts that can then be used as a filter on code that has been heavily analyzed. [10]

These methods are all unnecessarily complex for the scope of this thesis. Due to the nature of OpenCL it is not hard to find patterns in the code that can be used as features in a search system. These features are not open to interpretation by a machine learning algorithm or any kind of scoring system.

(12)

(13)

Chapter 3

Design and Implementation

To prove the feasibility of our selective OpenCL collection framework, we design and build the envisioned search system as a tool combining the crawler and the filter. We present in this chapter the design requirements and the most relevant implementation details of the envisioned tool.

3.1 High-level design

Designing our collection system starts with defining requirements. Specifically, we collect functional and non-functional requirements, and propose a high-level design providing features supporting these requirements.

3.1.1 Functional requirements

Specifically, our system needs to be able to perform the following:

1. Find a repository;

2. Check if this repository contains OpenCL code;

3. Analyse the OpenCL code, and properly index the found patterns into an entry;

4. Add this entry to a database;

5. Make queries to filter the database;

6. Find entries by filtering the database;

We note that points 1-3 refer to the functionality of the crawler, 5-6 refer to the functionality of the filter, and 4-5 refers to the support infrastructure in the form of a database.

(14)

3.1.2 Non-functional requirements

Besides the actual actions that our system needs to perform, we must take into account several non-functional requirements that are likely to increase the number of users for our system. Specifically, aiming to have a high-performance system, in terms of both execution time and filter/selection correctness is very important. We discuss these requirements in the following paragraphs.

Speed

When a user puts a query in the system, he/she expects an answer within a few seconds time. We note that speed is dependent on multiple factors. First, the complexity of the query is an essential factor: a simple select within a database executes much faster than looking for specifics, especially when the requested information is not already preprocessed and/or stored into some sort of cache. Therefore it is essential to a fast search that data has been preprocessed already before the filter that is built from the query is applied.

Quality

The quality of the solution refers to how well the results match the user query. Informally, we can measure quality by the ratio of true positives, i.e., results reported and found to match the user query. By this definition, 100% quality means all results are correct.

Moreover, given that queries are expected to have multiple correct answers, a proper ranking - e.g., the most relevant results first -is also desirable. However, providing such a ranking automatically devolves in devising some kind of a scoring system.

Our results will not be ranked by the means of such a scoring system, because we only use preset options. Only entries that comply to all of the filtering options will be presented in the results.

Completeness

Complementary to quality, completeness is fairly easy from a user’s perspective: the search must provide all code that is related to the query. In practice, our system is best effort, and strives to deliver as many results as possible, and to provide answers to as many queries as possible.

Ease of use

The queries that go into the system need to be understandable and easy to use for the end user. This means that the user interface should mask the underlying query language to simplify the interaction with the system. This does not mean that the interface should restrict the possibilities of the query language, but it should be obvious how to build the query that the user really wants to use

(15)

during the search.

Timeliness

Timeliness is an assessment of how actual the data stored in the database is, compared to the most recent copy of the repository. Ideally, one always wants to have the latest copy of a repository. In turn, enabling timeliness requires periodic checks to determine if the online commit identifier is still the same (and, when needed, automatic updates) or periodic (re)fresh searches (i.e., re-runnig the same queries, periodically). If timeliness is not guaranteed (e.g., updates are not automated), the user should be informed he/she is working with outdated data when that is the case. This information enables him/her to decide to download stale data or re-fresh local information before the download.

Verifiability

Finally, we aim for the provided information to be verifiable, or checked for correctness. The goal for the system is to support additional checks to ultimately detect usefulness. For example, this can be done by searching for Makefile/Bash files and attempt to build the projects. Other forms of functional testing should also be feasible.

3.1.3 Crawling with the GitHub API

We used the GitHub API to download and look at repositories available on GitHub. The API provides functions for almost all the actions available via the website interface: search for repositories, request pieces of code, look at information of users, and even download or clone repositories.

Building the crawler such that it uses the API to determine whether certain repositories contain OpenCL code sounds like a good solution: all the data can be kept remote, saving a lot of disk space, and most of the computation of going through repositories will be done by the API. The content of files returned by the API can then be used by our own program to further analyze whether or not there is OpenCL code present, and from that figure out the important patterns in the code.

3.1.4 Crawling with downloaded repositories

Another way to perform repository crawling is by downloading the repositories and walking through them locally. This approach requires minimum interaction with the API, which is only used to bring the repositories locally by requesting the download link. After a repository has been downloaded, it can be used for the search of OpenCL code. This method requires more disk space because we need the storage space for the repository, and it also requires more CPU computations because everything needs to be done locally, instead of it being handled by an API somewhere in the cloud.

(16)

3.2 System implementation

Figure 3.1 presents a high-level overview of the collection system. In the follow-ing paragraph, we discuss in more detail both the crawler and the filter.

Figure 3.1: A high-level schematic of the system design and implementation.

3.2.1 Crawler

The crawler is where the search for OpenCL code starts. To make the filtering as fast as possible we decided to use an Elasticsearch database to serve as a cache. The crawler is used to preprocess the data found on GitHub, and put entries into the database. The crawler and filter can thus optimally not be run at the same time, as the crawler will keep adding entries, and the filter will possibly not return all the results.

High-level design

A search in our system starts with placing a GitHub search request via the API. The search, using the key term ”OpenCL”, provides a good start by detecting as many OpenCL code repositories as possible. Next, a set of target repositories must be selected to start fetching code. The first repository is popped from the top of the stack, and goes through a first filter to determine if it actually contains OpenCL code. If this is the case, it further passes through a second

(17)

filter to set up for the database. Basic information needed during a search (e.g., the number of kernels), will be extracted during this period and passed to the database.

After the current filtering, new repositories can be found from information in the current repository. For example, one way of finding new repositories is to look at other repositories from the contributors of the current project. These candidates can be added to the list of target repositories, and will be (eventually) processed.

To reject duplicate repositories there needs to be a check on the repository set before it is added. This ”Repo set” is simply a list of all the target repositories plus the list of repositories that have already been searched.

When all this process is completed for one repository, a new repository will be popped from the stack to be searched, filtered, and parsed. Eventually, the list of target repositories will be empty, and then the crawling stops.

One cycle through the crawler is entirely separate from another, so the crawler will be multithreaded to achieve the best performance possible.

GitHub API

During the design the GitHub API seemed like a great idea, but when it was implemented it did not run properly at all. There were two reasons for that.

The first one is the rate limit. The API has a rate limit of 60 requests per hour for unauthorized users, and 5000 requests per hour for authorized users [3]. Furthermore, the limit for searching on GitHub has a separate counter, and can handle 10 requests per minute for unauthorized users and 30 requests per minute for authorized users [4]. The system processes a lot of repositories and these can be very large with a lot of subdirectories. Moving through a repository requires going to subdirectories and requesting the content of a file. These both count as requests to the Github API, and these add up pretty quickly. With only 5000 requests per hour, this method reaches the limit within 10 minutes. This means the remaining 50minutes of every potential search-hour are wasted. The second reason is the speed at which the API responds. The API has a big delay for the responses, which causes a lot of busy waiting time. The waiting also accumulates pretty fast, meaning that going through a big repository can cost an extremely long time.

Because of these slowdown factors, we decided to go further with our second design option, where the crawling is not done by the API. Instead, we use the API for the searching of repositories and for requesting the download link of the repository. To stop excessive use of disk space, the repository gets deleted after it has been analyzed.

OpenCL code filter

When a repository goes through the code filter, the system will start looking for signs that OpenCL code is present. These repositories get selected using the following criteria:

(18)

• There is a file with the extension “.cl”.

• A file in the repository includes the OpenCL header file.

• The file frequently uses OpenCL types, these are types that start with “cl ”.

The first two criteria are pretty self-explanatory. If a repository contains a file with a “.cl” extension, there is a big chance that it actually gets executed as well, so this is a good reason to select the repository to be further analyzed. The same is true for any C file that has the OpenCL header included. This can either be “OpenCL/opencl.h” for Apple systems or “CL/cl.h” otherwise. One cannot only use the first criteria because not every host code imports the OpenCL kernel from another file: the kernel can be defined as a string in the host code. The third criterion is used as more of an insurance that the right files will get analyzed. The OpenCL Runtime uses types defined by the OpenCL specification that all start with “cl ”. In this way, one can check whether or not a file uses OpenCL independent from which headers were included. This is necessary since the include for the OpenCL header can be hidden within another header file. All of the files that are deemed to contain OpenCL code get flagged as important files. These important files are the ones used to build entries for the database in the parser.

OpenCL parser

The parser is used to find OpenCL routines and to build entries for the database. These entries will be used during the searching and filtering. One entry is built up by an OpenCL routine, which mainly consists of the 5 following parts:

1. Define platform and queues

2. Define memory objects

3. Create the program

4. Create and setup kernel

5. Execute the kernel

Finding a routine means locating all these different parts within the repos-itory. For all these parts, critical functions were chosen as markers. Locating these functions would mean that the part is present in the code, and finding all these parts would finish the search, resulting in a new entry. The functions that are searched for are, respectively: clGetDeviceIDs, clCreateBuffer, clCreatePro-gramWithSource, clCreateKernel, clEnqueueNDRangeKernel. These functions can be spread out through multiple files so local files that are included will be searched as well. From these functions, relevant data gets extracted to eventu-ally be added to the entry itself. The following data will be extracted during the search for the entry:

(19)

• Amount of kernels

• Explicit device specification (CPU/GPU) • Important files

• Target repository • Possible errors

3.2.2 Filter

Elasticsearch

All found entries are added to a database. The choice to use Elasticsearch as database was made because of the easy integration into Python, the program-ming language which was also used for the crawler. Furthermore, Elasticsearch is especially made for search systems while more traditional database systems like SQL are better suited for management systems. Elasticsearch is the most used database system for search engines according to [1], and is incredibly fast with simple databases like the one used in this research.

The frontend of the filter itself is made in HTML, jquery and ajax. A form is made in HTML which gets used to filter the results of the search engine. A Elasticsearch query is built from the various filters that have been selected, and interacts with the database using ajax. The results get displayed on screen and from that point the user can go directly to the GitHub page to download or clone any project that is of interest.

User Interface

To interact with the Elasticsearch database, we need to send queries. However, our goal is to keep the user disconnected from the underlying query language. Therefore, we need some for of a User Interface (UI), which enables the user to select the features it wants to include in the query. Figure 3.2 shows what this UI looks like.

(20)

Each selected field becomes a condition that needs to be met. Each entry that is provided as a result of this search must meet all the conditions. For example, requesting the device type to be CPU and the OpenCL code to contain 2 kernels requires both conditions to be true; therefore, the search will ignore cases that use 2 kernels but have a GPU as a device type.

(21)

Chapter 4

Evaluation

To evaluate our system, we investigate the performance of two of its aspects: the speed at which the system goes through repositories, and the rate of success-fully finding OpenCL code. The core of the evaluation focuses on performance measurements when using the system, followed by an assessment of whether it is worth it to automate the search for OpenCL code, i.e., whether the pros outweigh the cons. Finally, we also indicate limitations of the current imple-mentation, as highlighted by this evaluation.

4.1 Speed test

A big advantage in the automation of a process is the speedup that can be achieved by it. When handpicking code it takes a lot of time to go through an entire repository to find out whether or not OpenCL code has been found. It costs even more time when you want a piece of OpenCL code been written within a specific context, e.g., OpenCL code written to run on a CPU device.

For determining how fast the search system is, we perform two experiments on an Asus UX305L notebook equipped with an Intel Core i5-5200U CPU with 4 cores, running at 2.20GHz, and 8 GB RAM.

Both experiments focus on the execution time for parsing 100 repositories. Note that not all of these repositories have to contain OpenCL code and that these repositories can vary in size. Our first experiment puts no restrictions on the size of the repository; in our second experiment we restrict the size of a repository to 100 kB. The size restriction was put in place so that the effect of the download time can be more easily demonstrated. This also causes less dispersion in the sizes of the repositories, which leads to a better interpretation of the speed at which the system goes through a single repository.

We measure performance with four metrics.

The first metric is real time, which is the wall-clock time of the crawler. In other words the actual time that has elapsed.

(22)

Table 4.1: The time taken by an OpenCL code search through 100 repositories with no size limitation (experiment 1).

Threads Real Execution Download Execution -time time time Download 1 545.92 545.92 464.27 81.64 2 357.73 713.21 615.97 97.24 4 275.94 1081.27 970.00 111.27 8 245.32 1585.29 1459.49 125.77

Table 4.2: The time taken by an OpenCL code search through 100 repositories of up to 100kB each (experiment 2).

Threads Real Execution Download Execution -time time time Download 1 176.16 176.16 120.75 55.41 2 104.07 207.44 136.10 71.33 4 72.74 288.09 193.36 94.73 8 65.45 510.65 316.56 194.09

the program has been actually busy combined over all the threads. When there is only 1 thread in use, the total execution time will be the same as the wall-clock time, but when multiple threads are being used you can see that the total execu-tion time combined over all the threads begins to add up. As more threads are being used the overhead becomes bigger and bigger, losing efficiency per thread in the process. Despite this overhead, the real elapsed time is still significantly lower, meaning that parallelization is useful for the overall execution.

The third metric is total download time. This is the combined time of the threads downloading the repositories, and takes up the most amount of time while crawling the repositories. While the total execution without the download does not increase heavily, the download time does. Downloading a repository seems to take up a lot of the bandwidth so that downloading multiple repositories at the same time does not give much of an advantage. The best way to speed up the crawler is by using a better Internet connection. This is partially demonstrated in table 4.2. In this table, showing the data for downloading small repositories (up to 100kB each). The download time is significantly lower because of the small repository size, and therefore the wall-clock time is also significantly lower.

Ideally, we would have wanted to present a form of relative speed improve-ment, i.e., the speedup that occurred due to the automation of the search. However, the objective measurement of such a metric is impossible: the au-tomatic search system goes through the same cycle every time it runs, while handpicking code from a place like GitHub can be done very differently from person to person. Every user would also search at a different speed, and at a

(23)

different efficiency rate.

4.2 Efficiency

To estimate the efficiency of our system, we can consider the number of reposi-tories traversed by the search in the time unit as a metric of throughput, and the number of correct OpenCL repositories the search found as a metric of success. For the search with unlimited size it looks like 4.1

Figure 4.1: Efficiency of the system

This figure describes the ratio of successfully found OpenCL repositories, grouped in stacks of 100. In this experiment the maximum amount of reposi-tories was set to 1000, and the amount of reposireposi-tories that were used from the original GitHub search was set to 500. This means that the first 500 repositories are specifically from the search to OpenCL, and afterwards the only repositories that were used were ones found via the contributors of the first 500.

As is very clear from the result the ratio after the initial search drops off significantly. Searching through repositories of contributors of other OpenCL code is not a great method for searching. Still, some OpenCl code that was not encountered before gets found, so it does contribute to the overall search system. Such quickly diminishing returns could mean that it would be better if

(24)

the crawler stops after the initial search, but this is a consideration that a user should make for him- or herself.

4.3 Limitations

The biggest limitation of the system is its accuracy in finding OpenCL code. The system uses a Python extension called ’pycparser’ to analyze the OpenCL code. For this analysis to be feasible, an abstract syntax tree (AST) has to be built. There are a lot of problems that are encountered when building an AST from a piece of code that comes from a random online repository. The problems we encountered were mostly related to types and function definitions being included from multiple files, which cannot be easily found (not downloaded, available in a different folder, or assume available on the system). In all these cases, the parsing fails, and the file cannot be properly analyzed. It is not clear whether that is a bad thing or not, because if the parser cannot properly parse a file, it will not be a self-contained piece of code. However, there still could be valuable OpenCL code that one wants to find.

Furthermore, the system directories also need to be available to the parser. Projects can include directories that have been appended to the standard list of system directories via compiler flags. This means that external libraries may need to be downloaded first before you are able to run the project.

It is a big problem when a big part of the OpenCL code that has been found is not properly analyzed, because the crawler cannot extract data from those files to use during the filtering. It is a bad solution to leave them entirely outside of the database, because they can still contain valuable code. Therefore code that cannot be properly analyzed gets a warning message, so that it can be manually reviewed by the user. This is not the ideal situation, but is still a lot faster than handpicking the code, since the system does give the user hints about the important files in the repository.

(25)

Chapter 5

Conclusion & Future work

5.1 Conclusion

This thesis presents the creation and evaluation of a tool in the form of a search system that automatically finds OpenCL code in online repositories on GitHub. The search system (Chapter 3) consists of two parts: the crawler, which goes through repositories to find OpenCL code to add it to a database, and the filter, which takes entries out of the database depending on the user query. The evaluation of the system (Chapter 4) demonstrates the functionality and performance of our search system.

Therefore, our system is, in itself, a proof that it is possible to automatically find OpenCL code in online repositories, thus providing a positive answer to our research question. Moreover, by providing the added proof-of-concept tool, we also demonstrate one way to solve this search problem.

Using an automated solution as presented in this thesis provides an advan-tage in the form of speed and ease of use, but also has the disadvanadvan-tage of potentially missing the interpretation of a human who can quickly determine what piece if code is relevant. The system tries to solve this potential problem by using queries to filter out code that might be irrelevant to the user, but the user could be restricted in the search by the boundaries that the filter has. To analyze more complex code, a more sophisticated OpenCL parser is needed, but this is beyond the scope of this thesis.

5.2 Future work

We envision two directions of research to be followed to improve this work: better filtering and proof of functionality.

(26)

Better filtering

The current prototype of the tool only uses the host code to extract data for the filter. The filtering can be further extended to do a more sophisticated analysis of the OpenCL kernel code, by looking at kernel features like (k1) using local memory in the kernel, or (k2) using a kernel that is at least longer than N lines. A more advanced analysis of the host code could also extract features that would be more interesting, like (h1) iterative invocation of the kernel, (h2) event usage, and (h3) work dimensions (1D, 2D, 3D) .

Functionality check

Besides offering a wider range of features that the user can filter on, the func-tionality of a piece of code could also be verified before putting it in the database as an entry. This can be done by searching whether or not there are any Make files or Bash files present in the repository, and eventually attempting to build the project. This kind of automatic functional testing can be extremely com-plex, but with the amount of small OpenCL projects there are right now, it could be a great addition.

(27)

Bibliography

[1] Db-engines ranking of search engines. https://db-engines.com/en/ ranking/search+engine. Accessed: 8 June 2018.

[2] Github facts. https://github.com/about/facts. Accessed: 7 June 2018. [3] Github rate limit. https://developer.github.com/v3/rate_limit/.

Accessed: 8 June 2018.

[4] Github search rate limit. https://developer.github.com/v3/search/ #rate-limit. Accessed: 8 June 2018.

[5] Kisub Kim, Dongsun Kim, Tegawend´e F Bissyand´e, Eunjong Choi, Li Li, Jacques Klein, and Yves Le Traon. Facoy–a code-to-code search engine. 2018.

[6] Piero Lanucara. Introduction to opencl with examples. https:// hpc-forge.cineca.it/files/CoursesDev/public/2015/Programming_ paradigms_for_new%20hybrid_architectures/Hybrid%20Intro%20to% 20OpenCL%202015.pdf, 1 July 2015. Accessed: May 2018.

[7] Ibrahim Jameel Mujhid, Joanna C. S. Santos, Raghuram Gopalakrishnan, and Mehdi Mirakhorli. A search engine for finding and reusing architec-turally significant code. Journal of Systems and Software, 130:81 – 93, 2017.

[8] A. Munshi. The opencl specification. In 2009 IEEE Hot Chips 21 Sympo-sium (HCS), pages 1–314, Aug 2009.

[9] S.J. Pennycook, J.D. Sewall, and V.W. Lee. Implications of a metric for performance portability. Future Generation Computer Systems, 2017. [10] D. Poshyvanyk, M. Grechanik, C. McMillan, C. Fu, and Q. Xie. Exemplar:

A source code search engine for finding highly relevant applications. IEEE Transactions on Software Engineering, 38:1069–1087, 09 2012.

[11] Caitlin Sadowski, Kathryn T. Stolee, and Sebastian Elbaum. How devel-opers search for code: A case study. In Proceedings of the 2015 10th Joint Meeting on Foundations of Software Engineering, ESEC/FSE 2015, pages 191–201, New York, NY, USA, 2015. ACM.

Selective OpenCL Code Collection from Online Repositories: an Automated Approach

Bachelor Informatica