Estrat´ egias EM e EM+I

Vemos que para a estrat´egia EM, o re´uso m´aximo para o benchmark 3-DES decresce de 72, 35%, utilizando uma cache global, para 65, 50%, utilizando caches locais por n´o. O mesmo decr´escimo ´e visto para os demais benchmarks: o LCS decai de 98, 83% para 15, 56%. O MapReduce decai de 54, 73% para 0, 03% e o GoL decai de 99, 74% para 7, 31%. Esse decr´escimo ´e esperado por conta da falta de visibilidade sobre os operandos das aplica¸c˜oes que ´e imposta aos n´os do grafo por conta de haver subdivis˜ao da cache global. Entretanto, vemos que para o benchmark 3-DES, a partir de 1200 caches, o re´uso m´aximo se torna constante. Isso ocorre, pois o grafo de aplica¸c˜ao 3-DES, possui uma quantidade de n´os menor que 1200, portanto, a partir deste cen´ario, o comportamento ´e de uma cache local. Ainda sobre a aplica¸c˜ao 3-DES, note que ao avan¸carmos os cen´arios ”G”para ”S, 2” e ”S, 100” para ”S, 400” n˜ao h´a diminui¸c˜ao no re´uso m´aximo. Isso pode ser explicado pelo fato de que esta aplica¸c˜ao possui muitos tipos de n´os distintos, e o reagrupamento deste n´os em alguns casos espec´ıficos n˜ao interfere na visibilidade de operandos, pois eles n˜ao precisam consultar a mesma cache j´a que implementam fun¸c˜oes distintas. Vemos que para todas as aplica¸c˜oes avaliadas, com exce¸c˜ao do algoritmo da mochila, temos uma quantidade expressiva de redundˆancia. O benchmark MapReduce tem uma taxa alta de redundˆancia, por´em menor que os demais benchmarks. Isso pode

ser explicado pelo fato dos n´os redutores estarem sempre agrupando conjunto de tuplas, portanto, o tamanho dos operandos torna-se vari´avel, n˜ao s˜ao fixos como no LCS, GoL ou DES. Isso tem uma influˆencia prejudicial na taxa de re´uso, porque operandos maiores s˜ao dif´ıceis de aparecer novamente durante a execu¸c˜ao.

(a) Estrat´egia EM.

(b) Estrat´egia EM+I.

Figura 7.8: Resultados de re´uso para as estrat´egias EM e EM+I.

Apesar da quantidade expressiva de redundˆancia nas aplica¸c˜oes, ainda sim, pou- cos subgrafos redundantes s˜ao utilizados. Somente ´e visualizado um re´uso de 3, 33% por parte da SRT no benchmark LCS com uma cache global. O re´uso baixo pela SRT pode ser explicado por conta deste mecanismo utilizar os Ids dos n´os para o re´uso do subgrafo, o que limita grandemente o escopo do re´uso. Uma alternativa para esta limita¸c˜ao, seria o uso de isomorfismo de subgrafos para detec¸c˜ao de sub- grafos redundantes, por´em isso geraria um custo de implementa¸c˜ao muito grande no hardware dataflow. Para os demais, esse tipo de redundˆancia foi desprez´ıvel nesta estrat´egia. Vemos tamb´em um decr´escimo na utiliza¸c˜ao de subgrafos redundantes conforme a cache vai sendo subdividida em grupos de n´os. Isso pode ser explicado pelo fato da falta de visibilidade entre operandos de diferentes n´os prejudicarem a reutiliza¸c˜ao de subgrafos.

As detec¸c˜oes de redundˆancia foram realizadas, na maioria das vezes, pela NRT, ou seja, reutiliza¸c˜ao n´o a n´o. Vemos que a NRT, no benchmark LCS, contribuiu com 78, 44%, atingindo um total de 81, 77% (78, 44%+3, 33%) de redundˆancia detectada. Para os demais benchmarks a contribui¸c˜ao da NRT foi de 65, 76%, 79, 32%, 0% para os benchmarks DES, GoL e MapReduce respectivamente. Na aplica¸c˜ao MapReduce, nenhuma tarefa redundante foi detectada pela NRT ou SRT em todos os tipos de cache. Isso pode ser explicado pelo fato de que esse tipo de grafo, um fork-join hier´arquico, possui um n´umero grande de tarefas que s˜ao assinaladas como prontas ao mesmo tempo. Por exemplo, o n´o mapeador, quando executado, liberar´a para execu¸c˜ao todos os redutores de primeiro n´ıvel (red1,1, red1,2, red1,3, ..., red1,n). Ainda que red1,1 e red1,2 sejam redundantes, red1,2 n˜ao estar´a h´abil a utilizar os resultados de red1,1, pois ele j´a estar´a na fila de prontos. O re´uso de computa¸c˜ao de red1,1 por red1,2 somente ser´a poss´ıvel com o mecanismo de inspe¸c˜ao.

Analisando o cen´ario de cache local, vemos que n˜ao houve redundˆancia detec- tada para os benchmarks LCS e GoL apesar de haver re´uso a ser explorado. Isso pode ser explicado porque as tarefas instanciadas por cada n´o foram executadas praticamente de forma consecutiva, sem um per´ıodo consider´avel de tempo entre elas. Portanto, quando as caches eram consultadas, os workers n˜ao haviam enviado ainda os resultados necess´arios para que as tarefas fossem reutilizadas. Para outros tipos de caches, isso n˜ao foi um problema, pois os n´os possu´ıam visibilidade sobre os resultados dos outros n´os do grafo. Esse comportamento n˜ao ocorre para aplica¸c˜ao 3-DES, pois o mesmo possui mais itera¸c˜oes, isto ´e, o n´o Source produz mais ope- randos. Portanto, quando um operando se repete, j´a ocorreram diversas itera¸c˜oes, permitindo que as caches estejam aquecidas o suficiente para que a redundˆancia possa ser detectada.

Na figura 7.8b, analisamos os resultados para a estrat´egia EM+I. Vemos que o mecanismo de inspe¸c˜ao foi muito efetivo, substancialmente incrementando a taxa real de re´uso. Para o benchmark LCS, o re´uso alcan¸cado foi de 97, 1%, quase o re´uso m´aximo de 98, 83% apresentado pela aplica¸c˜ao. Para aplica¸c˜ao MapReduce, vemos que o mecanismo de inspe¸c˜ao contribuiu com aproximadamente 50% do re´uso detec- tado no melhor cen´ario (G) e com quase toda redundˆancia dispon´ıvel no cen´ario local (L). Para o benchmark 3-DES, vemos que a inspe¸c˜ao, nos melhores cen´arios ”G”e ”S, 2”, n˜ao contribuiu expressivamente com o reaproveitamento de tarefas, por´em em cen´arios onde a visibilidade de resultados era baixa, ela proveu grande contri- bui¸c˜ao, em torno de 18, 82% e 38, 14% para os cen´arios ”S, 25” e ”L”respectivamente. Isso pode ser explicado pelo fato de que com baixa visibilidade, menos tarefas s˜ao ignoradas, e, portanto, mais tarefas s˜ao colocadas na fila de prontos, aumentando assim, a oportunidade de re´uso por inspe¸c˜ao. A aplica¸c˜ao GoL tamb´em apresentou benef´ıcios com a implementa¸c˜ao da inspe¸c˜ao. Seu re´uso aproveitado de 99, 67% foi

pr´oximo ao m´aximo dispon´ıvel pela aplica¸c˜ao de 99, 74%. A inspe¸c˜ao contribuiu com 22, 16% no cen´ario ”G”para o GoL. No cen´ario ”L”, ela foi a ´unica respons´avel por detec¸c˜ao de re´uso com 7, 16% de contribui¸c˜ao.

Note que os benchmarks apresentados tiveram sua contribui¸c˜ao da NRT decres- cida ap´os a habilita¸c˜ao da inspe¸c˜ao. Esse comportamento ocorre, porque a inspe¸c˜ao permite que tarefas sejam removidas da fila de prontas com mais antecedˆencia, antes da cache estar bem aquecida. Por consequˆencia, os n´os n˜ao s˜ao reutilizados na NRT e instanciam tarefas. Essas tarefas acabam sendo reutilizadas na inspe¸c˜ao, gerando, desta forma, uma regulariza¸c˜ao do re´uso por parte da pr´opria inspe¸c˜ao.