a b 1/29/07 Glenn, The past week has not been extensively research active as I have only had my project approved as of last Thursday. I have been reading through the documentation for SESC and ODE in order to familiarize myself with their inner workings. I expect things to pickup up after our meeting Tuesday morning and to soon become more acquainted with Tom Yeh's lab. Also, I think it would be a good idea to use our time after your CS 133 lecture for small discussions about the project as we are usually both free after that class. Paul Salzman 2/5/07 Glenn, Update: This weeks work was a little disappointing. I was on my own little wild goose chase looking for the sesc code to work in the sescutilities file from the source forge site until I finally discovered that the required files are actually in a separate cvs module, not in the sesc utilities. I was a little over my head in getting sesc to work as I was a little confused with the documentation. Over the last couple of days I talked with Tom a little through emails and was able to get sesc working. I was not able to make as much progress on the heterogeneous cores as I had hoped. There appears to be a possibility in the libnet library in sesc's src directory. It implements an interconnection network using router objects to define "the communication channel between processors in a large multiprocessor system." A larger description starts on the bottom of page 15 in http://sesc.sourceforge.net/sescdoc.pdf. The documentation does not mention any limitations on what can be connected with this network, so I'm not sure if heterogeneous cores will be a problem. Also, as I am not confident in how this library interacts with the simulator I cannot really say how difficult it will be to implement. In the next week I plan to work a little more closely with Tom in order to keep my head firmly above water and in general produce more results. Idea: In an attempt to plot out the future workloads to place on the ParallAX architecture we could consult with on campus AI professors or researchers about any possible AI algorithms they are working on or any open source code that they recommend. This would allow us to parallelize the algorithm and to analyze how the fine and coarse grain core architecture could be of use. Paul 2/12/07 Professor Reinman, This week's progress: I investigated sesc's ability to create heterogeneous configurations with relatively successful results. The configuration files allow for cores to be grouped to different parameter settings resulting in varying performance across different splash benchmarks. I have begun my research on how the cores communicate. Each group of cores can be designated a network configuration with parameters for wire latency, etc. I need to further investigate how different sets of networked cores communicate. Weekly idea: Perhaps when portions of the various resources of the ParallAX board are to be unused for a period time they can be shut off to lower power consumption. This raises an interesting question of how to arbitrate when a resource won't be needed and how to turn it on and off. 02/19/07 Professor Reinman, What I did this week: I Investigated the configuration of the routing policies. So far delving into some of the sesc code has proved a little fruitless, although I have been admittedly distracted by midterms. I emailed the sesc mailing list in hopes of any information about the heterogeneous core configurations. Unfortunately I am still waiting for a response. I also investigated further the heterogeneous capabilities of core configuration parameters. An idea: Maybe we can investigate a nonuniform cache architecture (NUCA) for use between various levels of core granularity. Paul Salzman 02/26/07 Professor Reinman What I did this week: This week I hardcoded in a rough version of the ParallAX topology into sesc's libnet and begun testing its functionality. This code was adapted from the existing mesh topology code and responds to the added keyword "parallax" in the network portion of the configuration file. A new idea: What if we could reduce communication latency by combining the "3D layout" architectural research with the distribution of fine and coarse grain cores. Perhaps a coarse grain cores can have its associated fine grain cores above its location to increase speed, or perhaps the set of coarse grain cores can be grouped together using the extra dimension. Paul Salzman 3/2/07 Professor Reinman >What I did this week: This week I looked through the cache coherency policy of sesc. Initial results were few and far between as the sesc documentation is proving to be scant and very out of date. On further examination with the aid of Tom, it looks like sesc uses a snooping policy in order to enforce cache coherency. Caches can be instantiated as inclusive or as non-inclusive, but we are still in the process of determining how that is specified by a client. Also, we have made progress with the libnet benchmark. While libnet still appears to be completely separate from the simulator, we have compiled it and run a bench march program on the preexisting routing policies. My added version of parallax routing makes it through half of the bench marks before seg-faulting, so this is a work in progress. >A new idea: Once we get parallax topology working with the libnet bench mark we should use some of the benchmark code to help model the network timing where cache coherency is enforced. Paul Salzman 3/12/07 Professor Reinman, >What I did this week: The cache coherency policy in sesc looks like snooping. Each layer of cache has one parameter (that I have seen) to a lower level memory system. This may make things hard to connect correctly. We have continued work with the libnet benchmark. ParallAX is up and running as a libnet topology and we have run tests between different nodes to analyze the communication performance. I'm not as familiar as how correct performance results should look, but Tom says that the different node to node latencies looked correct. Now it's just a manner of hacking the libnet latencies into sesc. Also, I have attached progress checkpoint slides. I will be presenting these to Professor Sahai at the beginning of next quarter and I would not mind some feedback. >A new idea: Perhaps an extra core would be useful if added to the topology for communication/fine grain core arbitration a la IBM's cell. Paul Salzman 4/9/07 Professor Reinman, >What I did this week: I've been searching through sesc trying to isolate when a message is received, and it appears that libnet is using some of sesc's event scheduler code. When a request is made it is put into the scheduler structure, which is later completed after the "globalClock" is incremented enough. When the request is put in that structure it appears to take a callback function as an argument. >A new idea: Maybe we could modify the callback argument with our own function that calculates latency and/or notifies the requesting core that their request is complete and can proceed. Paul Salzman 4/16/07 >What I've done this week This week consisted of securing a backup plan for the research project after the sesc simulation construction overhead was not looking to pan out. It looks as though I will be examining possible new methods for branch prediction when considering objects in the real-time physics o.d.e. >My Idea Well, the general idea is to try and find an object characteristic that can be seen by hardware to use in branch prediction (objects in motion tend to stay in motion, etc).