Initial commit

Makefile

@@ -0,0 +1,28 @@
+#CC=clang-3.5
+CFLAGS=-fcilkplus -lcilkrts -DCILK -pthread  -O2 -std=gnu99 -fms-extensions -ggdb3 
+#CFLAGS=-O2 -fopenmp -pthread -std=gnu99 -fms-extensions -ggdb3
+CC=g++
+LDFLAGS= -lm  -llapack -lblas -lnuma
+
+OBJ= random.o utils.o buffer.o  init_all.o
+ALGOS=sssp_pushpull spmv bfsgrid_cilk wcc prgrid_cilk pagerank_simple bfs_simple bfs_numa pr_numa 
+DIRS= $(patsubst %, .%, $(ALGOS))
+MK= $(patsubst %, .%/Makefile, $(ALGOS))
+
+DIRS= $(patsubst %, .%, $(ALGOS))
+MK= $(patsubst %, .%/Makefile, $(ALGOS))
+export
+
+.PHONY:clean all $(ALGOS)
+
+all: $(ALGOS) 
+
+$(MK):Makefile.tmpl
+	@(echo "#Updating makefile $@"; mkdir -p $(dir $@); cp Makefile.tmpl $@;)
+
+$(ALGOS): %: .%/Makefile
+	@(make -C .$@)
+
+clean:
+	rm -rf *.o $(DIRS) $(ALGOS)
+

Makefile.tmpl

@@ -0,0 +1,24 @@
+mkfile_path := $(abspath $(lastword $(MAKEFILE_LIST)))
+current_dir := $(notdir $(patsubst %/,%,$(dir $(mkfile_path))))
+current_algo := $(strip $(patsubst .%, %, $(current_dir)))
+header := $(strip $(patsubst %, "\"%.h\"", $(current_algo)))
+DEPS= $(patsubst %.o, ../%.c, $(OBJ)) ../$(current_algo).c
+CURR_OBJS= $(OBJ) $(current_algo).o
+
+.PHONY: all cp
+
+all: makefile.dep $(current_algo) cp 
+
+makefile.dep:
+	@(for i in $(DEPS); do ${CC} -MM "$${i}" -D ALGO_H=$(header) | sed '$$s/$$/ Makefile ..\/Makefile/'; /bin/echo -e "\t\$$(CC) \$$(CFLAGS) -c \$$< -D ALGO_H=\$$(header) -o \$$@"; done > makefile.dep)
+
+-include makefile.dep
+
+cp: $(current_algo)
+	@cp $(current_algo) ../
+
+$(current_algo): $(CURR_OBJS)
+	$(CC) $(CFLAGS) $(CURR_OBJS) -o $(current_algo) $(LDFLAGS)
+
+
+

README.md

@@ -1,2 +1,56 @@
-# EverythingGraph
-A platform to evaluate techniques used in multicore graph processing.
+# EverythingGraph_tmp
+
+
+README
+
+Provided is the code for BFS, PR, SSSP, SpMV and WCC using different data layouts and compute variations.
+
+This code was designed to evaluate existing techniques. Therefore, some files are reused from existing systems. More specifically: transpose_ligra, parallel_ligra, radixSort_ligra, utils_ligra from <a href="https://github.com/jshun/ligra/tree/master/ligra">Ligra</a>.
+Bitmap from <a href="https://github.com/thu-pacman/GeminiGraph/tree/master/core"> Gemini </a>.
+
+<h1>Organization</h1>
+
+The driver of the program is <b>random.c</b>. Pre-processing code is located in <b>init_all.c</b>.  Files starting with algorithm names implement different variations of the same algorithm, used to evaluate programming techniques. 
+
+<h1>Compilation</h1>
+
+To compile the code you need compiler support for Cilk Plus. The code is then compiled simply by running <strong> make </strong>. 
+
+<h1>Input</h1>
+
+The input file is a binary edge array of the for <strong>[src][dst].</strong>
+If the edges have weights, the <b>–w</b> flag needs to be added on running the program and the WEIGHTED constant changed to 1 in <b>random.h .</b>
+If the algorithm requires weights and the input file does not have them, random weights are generated by setting <b>CREATE_FLAG to 1 in random.h</b>.
+
+<h1>Running the code</h1>
+
+To run the code you need to call the corresponding algorithm binary with a number of required options:
+
+<b>./algorithm_binary –n #_of_vertices –m load_mode –f path_to_graph [optional parameters].</b>
+
+When not running the NUMA-aware version, it is recommended to use <b>numactl --interlave=all</b> before the command line to improve performance. <br/>
+To change the number of threads running, it is necessary to edit the constants ALGO_NB_THREADS and CONCURRENCY_THREADS in random.h.
+
+
+<h1>Pre-processing</h1>
+
+The graph can be represented as:
+
+1.	An edge array
+2.	Adjacency lists
+3.	2D grid
+
+The way these data layouts are created can be varied: Using a radix sort, a dynamic allocation and reallocation on load or count sort. 
+The implementation of all of these options is in <b>init_all.c</b>. The data layout can be selected by setting the <b>load_mode</b> flag. 
+
+If the algorithm needs to be run an undirected graph, pass the <b>–u</b> flag when running the algorithm. If the graph is already undirected and the algorithm requires creating incoming adjacency lists, passing <b>–s 1</b> will disable this. 
+
+
+<h1>NUMA-Aware data placement</h1>
+
+The additional pre-processing step needed to place data in a NUMA-Aware manner is implemented in the actual files that run the algorithms with NUMA-Awareness: <b>pr_numa</b> and <b>bfs_numa</b>. The expected data layout is an adjacency list. 
+
+Most files contain the currently pushed data layouts for the algorithm except BFS and PR over a grid which are stored in separate files (bfsgrid, prgrid).
+
+
+

barrier.h

@@ -0,0 +1,30 @@
+#ifndef _BARRIER_
+#define _BARRIER_
+struct  x_barrier {
+  volatile unsigned int count[2];
+  volatile unsigned int sense;
+  unsigned long expected;
+// public:
+};
+
+  void init_barrier(struct x_barrier* sync, unsigned long expected_in)
+  {
+   sync->sense = 0;
+  sync->expected = expected_in;
+    sync->count[0] = 0;
+    sync->count[1] = 0;
+  }
+  void wait_b(struct x_barrier* sync)
+  {
+    unsigned long sense_used = sync->sense;
+    unsigned long arrived =
+      __sync_fetch_and_add(&sync->count[sense_used], 1);
+    if(arrived == (sync->expected - 1)) {
+      sync->sense = 1 - sense_used; // Reverse sense
+      sync->count[sense_used] = 0;
+    }
+    while(sync->count[sense_used] != 0) { NOP10();}
+    __sync_synchronize(); // Also clobber memory
+  }
+
+#endif