# HG changeset patch # User Sean Halle # Date 1375583062 25200 # Node ID eb146c5c05a82c481b3d87e83b0e47579a0e8333 # Parent 9b9a2497757da396287c8d71e9190bf4274c5dcd maintenance -- DSLDI slides, VMS__Full_conf_paper_2.tex update, etc.. diff -r 9b9a2497757d -r eb146c5c05a8 0__Papers/Holistic_Model/Perf_Tune/europar2013_submission_22.pdf Binary file 0__Papers/Holistic_Model/Perf_Tune/europar2013_submission_22.pdf has changed diff -r 9b9a2497757d -r eb146c5c05a8 0__Papers/Holistic_Model/Perf_Tune__long_version_for_TACO/latex/Holistic_Perf_Tuning.pdf Binary file 0__Papers/Holistic_Model/Perf_Tune__long_version_for_TACO/latex/Holistic_Perf_Tuning.pdf has changed diff -r 9b9a2497757d -r eb146c5c05a8 0__Papers/Holistic_Model/Perf_Tune__long_version_for_TACO/latex/Holistic_Perf_Tuning__single_column_format.pdf Binary file 0__Papers/Holistic_Model/Perf_Tune__long_version_for_TACO/latex/Holistic_Perf_Tuning__single_column_format.pdf has changed diff -r 9b9a2497757d -r eb146c5c05a8 0__Papers/Ideas/VoteBucks/latex/continuous_voting.pdf Binary file 0__Papers/Ideas/VoteBucks/latex/continuous_voting.pdf has changed diff -r 9b9a2497757d -r eb146c5c05a8 0__Papers/Ideas/VoteBucks/latex/continuous_voting.tex --- /dev/null Thu Jan 01 00:00:00 1970 +0000 +++ b/0__Papers/Ideas/VoteBucks/latex/continuous_voting.tex Sat Aug 03 19:24:22 2013 -0700 @@ -0,0 +1,392 @@ +%&latex +\documentclass{article} + +\begin{document} + +%+Title +\title{Toward a True Democracy: Continuous Voting} +\author{Sean Halle} +\date{} +\maketitle +%-Title + +%+Abstract +\begin{abstract} + + Democracy rests on the principle that representatives carry out the will of the people governed, yet the centuries old system of periodic voting provides only weak feedback from the people to the representative, allowing governments to move in directions at odds with the majority of the people for sustained periods of time. We propose a continuous feedback system that puts the onus on the representative to actively solicit input from the populace and continuously engage with them in order to remain in office. This encourages stronger feedback from the people governed, applying force to the representative to carry out their wishes. The system includes a mechanism for establishing timely topics and effectively weighting their relative importance to each voter. It then records whether a voter approves or disapproves of the representative's statements and voting on those topics. The system tracks the weighted average approval of the representative and places limits on the duration the average can remain negative before the representative is removed from office. This places the onus on the representative to reach out to the populace, to interact with them in a meaningful way, and convince them to actively update their ratings, all of which strengthen feedback from the people to drive the actions of the representative. + +\end{abstract} +%-Abstract + +%+Contents +%\tableofcontents +%-Contents + + + + +%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% +% +%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% + +\section{Motivation and Overview} +Democracy rests on the principle that government should carry out the will of the people +governed. However, in many democracies, few believe +this principle is carried out in practice. Indeed, many voters feel that their voice goes unheard. The +behaviors of representatives often disproportionately reflect the desires of a few who have disproportionate influence, due to a variety of factors. Thus, modern democracies fall short of their ideal, of +governance according to the will of the majority of the people. + +To mitigate this, we propose tightening feedback from the governed, with a continuous voting system that will clearly communicate the will of the people and at the same time force the representative to comply with it. The system we propose has three aspects: first, it makes the actions of a representative readily available to the people; second, it clearly and quantitatively communicates the reactions of the people back to the +representative, letting them know definitively what the people want the representative to do; third it removes from office any representative +who fails to effectively accomplish the wishes of the constituency. + +Altogether, the aspects will give voters an easy way to learn what their representative is doing, then respond to that. The implementation should organize the wealth of possible topics, in such a way that the most relevant rise to the top. It should also inform about in-progress work and up-coming activities such as legislation being drafted that the representative is involved with, and up-coming votes on bills. + + Based on this information, the voter needs a simple mechanism to rate the representative on each topic, which communicates their relative strength of feeling. One means provides a fixed total of `emotion' tokens, which the voter divides among the topics they care about, in proportion to their level of feeling. For example, with 100 tokens, they may assign 50 to their strongest topic, 25 to the next, and 5 each to five more topics. They also state wether that is a positive feeling, meaning approval, or a negative one, meaning disapproval. For up-coming votes, they can even pre-assign a change in tokens, based on the way the representative votes. For example `+5 to topic X if they vote yes, -5 if no'. + +The system then adds up the tokens across all voters, creating a sum for each topic, and an overall sum. The representatives and the people can query the system about the sums, in order to learn the net desires of the constituents. For example, they can discover which topics have the most emotion assigned to them, and the net sum on those. A positive sum says the representative is perceived to be succeeding in doing what the constituents want on that topic. Queries can also be made to discover the highest net sum topics, both positive and negative, which gives clear indication of what the representative is doing well versus what they need to improve on. + +With a clear directive, the representative knows what the people want. If their net sum is comfortably positive, they continue their current path. However, if the net sum is close to going negative or is already negative, they must engage the constituents, in order to improve the net sum. They may choose to try to convince the constituents to change their minds on the topics, or else try to convince them that the representative has, indeed modified their behaviors, and to please update the ratings. + + The representative is allowed to have a negative sum for a maximum period of time, after which they lose the office. This gives them a chance to modify their behaviors, then show the people that their wishes have been heard and followed. The period of time that the sum can remain negative depends upon the office. For example, Governor or President may have a longer span than a member of the legislature, due to the intention that the office be a leader, which often involves making unpopular decisions that end up being in the best interest over the long term. + + + + +%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% +% +%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% + +\section{Visions of Results from Use of the System} + +It is anticipated that non-profits and partisan sites will spring up that have dedicated people who watch +the system, read the pending bills, and write up summaries and recommendations for voters. The recommendations may include links that connect directly to the text of pending bills. For example, a recommendation written on a particular bill may +include links to the token-assigning page for a particular representative, which lets voters easily tell their representative how they want the representative to vote on the bill. + +One anticipated effect will be to diffuse the power of narrow-interest groups and to reduce the influence of campaign +contributions. Political ads may still run when important legislation is being debated. However, accurate and easy searching of the actual comments of a constituent's own representative, along with the efficiency of the internet at disseminating analyses, that are then tied by the system directly to +the token-assigning pages, will diminish the influence such ads have on the representatives. In addition, such ads aren't tied to a representative, but rather to an issue, so the representative gains nothing from the financer of the ad. Rather, the ad has to influence the people, who then direct the representative, which comes closer to the democratic ideal. Although narrow interests may help a particular candidate get elected, their influence will quickly diminish as the representative is forced to +listen to the will of the people or be removed. + +The mechanism we propose is web-centric, which may raise concerns about voter access, especially for poorer or less educated voters. However, the web +has reached most homes in the country, and essentially every library. We see establishing a voter center in +every library, which is government funded and has trained personnel who help anyone who is a registered +voter to participate in the system. Only modest funds would be required to ensure that every community, regardless of +economic status, has a library, with such a center. + +As an example, if adopted at the federal level, the proposed system will require changes in the process that congress follows. In particular, bills will +have to be written in electronic form with tags on each paragraph indicating which issues are touched +upon in that paragraph. The bills will have to be submitted electronically at the time they are introduced. + +In addition, the congressional record or an equivalent would be put into electronic form, with +each of its paragraphs tagged with which issues it touches upon. The record would be linked +to the web site, allowing quick and easy searches for statements made by each representative, grouped by particular issue. +The proposed system would also change the rules for when elections are held and for terms in +office. Hence, federal adoption would require a constitutional amendment. + + + + +%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% +% +%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% + +\section{Usage of the Web Site} +We anticipate that the voter will interact with the system via a web site, where they will research their representative'’s +behavior and then assign their emotion tokens in order to influence that behavior. The site will provide a number of views into the actions and +statements of a representative. It enables the voter to focus on only the issues they care about and only +on the related statements and actions made by their own representative about those issues. + +The research views are linked to +token assigning views. That way, the voter may easily navigate back and forth between research and token assignment. + +We propose that a voter be given a number of screens organized into sets. With one set of screens they can research legislation that is pending, focusing on the parts that pertains to +issues the voter cares about. With another set they can view how their representative voted on past bills, as well as +see the text or video of the remarks the representative made during debate on the bill, but filtered so that only remarks relevant to issues of interest are shown. Another set of screens pertains to suggesting new issues not currently listed that are of interest to the voter. Finally, a set +of screens is provided for assigning approval versus disapproval to their representative, on each +issue, and allotting emotion tokens among the issues, to show how strongly the voter feels about each. + + + + +\subsection{Researching Bills} +To research legislation of interest, voters have a number of screens available: + +\begin{itemize} +\item List of completed bills related to a particular issue: for each issue, the voter can get a screen that +shows all bills related to that issue and how each of their representatives voted on that bill. It also +shows what percentage of the paragraphs in the bill are tagged with that issue. A link next to +each bill goes to a screen that lists all sections of the bill that were tagged as discussing that issue. +The voter can then read what that bill said regarding that issue. Each representative is listed next +to the name of the bill. The representative’s name is a link to the transcript of what the representative said on the floor during debate of the bill, and to a digitized video of that representative +making those remarks on the floor. + +\item List of the sections of a given bill, either pending or already voted on, that relates to a given issue: +A voter can filter the text of a bill to only show the paragraphs tagged with an issue they are interested in. The voter can then read what that bill said regarding that issue. + +\item List of all bills that have been introduced but not yet voted on: This screen can be filtered to only +show bills related to a set of issues the voter cares about. The list will arrange itself according to +issue, then according to status – whether still being authored, or in committee, or on the floor. A +voter can click on any bill in the list to see the sections relating to each issue. A voter can also +filter pending bills according to what percentage of their text relates to a given list of issues important to that voter. + +\item Creating an e-mail notification filter: The voter can create a filter by choosing issues of importance +to them. When a bill is introduced that has more than a certain percentage of its paragraphs +tagged with one of the issues, then an e-mail notification is sent to the voter with a link to the bill. + +\item When viewing a bill, a link to that bill’'s entry on the token allocation page: When a voter views a +pending bill and decides they want to tell their representative how to vote on it, they click on the +link, which takes them directly to that bill’'s entry on the token allocation page. +\end{itemize} + +\subsection{Researching Representatives} +To discover where their representative stands on an issue, the voter has a number of screens available: + +\begin{itemize} +\item List of the voter'’s representatives: with the voter’s own total sum for each and a graph of the representative’s' overall total moving-average + +\item list of their representatives, with the voter’s own total for each representative and a filtered list of +bills, with links for each bill to how that rep voted on that bill, transcripts of remarks the rep made +on the floor, and video of the rep delivering those remarks. +\item for each issue, for each rep, a voter can get a screen that shows all bills that have at least some +portion of their text related to that issue (and shows the percentage of the text related to that +issue), and how that rep voted on each of those bills. A link next to each bill goes to a screen that +lists all sections of the bill that were tagged as discussing that issue. The voter can then read what +that bill said regarding that issue. The screen also has a link to a transcript of what the represen- +tative said on the floor during debate of the bill, and a link to a digitized video of that representa- +tive making their remarks on the floor. +\item A list of bills the representative has authored, co-authored, or endorsed. +\item A list of bills currently before the representative in committee. +\item A list of ammendments the representative has authored. + + +\item a list of all representatives in congress and the executive branch, with current total net votes for +each, and the current moving average net total for each. A voter can check-mark representatives +that they want included in a summary screen + +\item a summary screen that shows all check-marked reps, with graph of each’ moving average and links +to summary screens for each representative. +\item a screen for each state, with that state’s representatives, a graph of the net total emotion tokens for +each representative, and a line to where on the state map is their constituency +\item a summary screen for a given representative that shows a state map, where on the map their con- +stituency is, a statement from the rep of their position overall, and a list of the issues. The voter +can click on each issue to get a statement from the rep of where they stand on it. +\end{itemize} + + +\subsection{Suggesting New Issues} +The screens used to suggest new issues to add to the list: + +\begin{itemize} +\item List of suggestions that are pending inclusion in the official list: the first screen has suggestions +that are pending. The voter votes on which of these they want to see make the final list. +\item the second screen of the new issues process has a text box where the voter can type in, free-flow, +one issue. The voter is allowed to suggest three issues per week. New issues are posted once per +month to the first screen, and once per month to the official list that appears on the vote screens. +(The GAO is responsible for reading the suggestions and choosing what goes into the pending list) +\end{itemize} + +\subsection{Assigning Emotion Tokens} +These screens are used by voters to make their will known to their representatives: + +\begin{itemize} +\item List of issues, for a given representative: The screen shows all of the current issues with thumbs up, +don’t care, and thumbs down radio button next to each. There is also a box showing the emotion tokens assigned to that issue. At the top of the page is the weighted average of tokens assigned, and +how many emotion tokens remain available. +\item List of pending bills: Shows all pending bills with a place to enter how the voter wishes their representatives to vote on the bill and how strongly they feel, from 1 to 5. This screen allows clicking +on each bill, which takes the viewer to the research screens described above. +\end{itemize} + + +\subsection{Viewing Vote Status, for Use by Representatives and Voters Alike} +Both the representative and the voter can check to see how the representative is doing. These screens are +the representative'’s lifeline, telling them the will of the voters and whether they are in danger of losing +office: +\begin{itemize} +\item Will of the voters on pending bills: shows each pending bill and both the simple percentage of how +many voters chose yes vs no, plus the weighted percentage that shows how strongly each voter felt. +\item Moving average of a Representative: shows the weighted average for a given representative, +starting when they took office. It allows zooming, shows the grace period, and highlights how +much of the grace period is below 50\%. An alert may be set on this screen that will send an e- +mail message when the average drops below 50\%, and when more than a certain number of days in +the grace period have been below 50\%. +\end{itemize} + + + +%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% +% +%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% +\section{The Processes within the System} + +The system has five processes, one has already been described in detail: the process for researching a representative's behaviors and assigning tokens to affect those behaviors. + +The four remaining are: a process for having new issues adopted and outdated issues removed; +a process for electing and removing representatives; a process for bills that governs how they are authored, debated, and tagged for search; and a process for running the web site at the center of the system, such that it is available, verifiable, and secure. + +\subsection{Adopting New Issues and Removing Outdated Issues} + +The GAO, or a specially created non-partisan, politically insulated body, is in charge of the maintenance and logistics of the web-sites. This managing-body also sets the list of issues, updating it once per month. The web-sites provide a mechanism for voters to suggest new issues they would like to see added to the list. The managing-body receives new-issue suggestions, sorts them, and picks the most popular ones. They replace the issue that got the fewest emotion tokens assigned to it with the top suggestion. + +In rare cases, more than one issue is removed, or more than one is added. The rules to determine when will be codified after experience with using such a system in smaller test settings. + +Only suggestions from voters can cause an issues to be listed. The wording of one of the suggestions +must be adopted verbatim. The rules to determine which one is adopted will be decided after more experience using such a system in test settings. + +Representatives have no input into adoption of issues. The +rules will be chosen in such a way that the potential for partisan influence is minimized. +Suggestions go through a two-stage system. First suggestions are sorted, and the text of one of a +group is chosen to represent that group. That is then posted on the first of the two pages that voters use +to suggest new categories. On the first page, voters pick which of the pending suggestions they like. +Then if they still want, on the second page they can write and send their own suggestion. + + + +\subsection{Removing a Representative from Office and Electing a Replacement} +Each office has a maximum time-span that a representative can hold that office. The exact time-span will +be decided after more scrutiny. To illustrate possible time-spans, President may be 8 years, senate 20 +years, house representative 10 years. + +A representative is removed from office if their net average vote stays negative for too long. A +moving average window is used to determine their net average vote on each day. The number of consecutive days that average has remained negative is counted. When the count reaches the limit for +that office, then the representative becomes lame duck and a vote is called to elect a replacement. + +The width of moving average window is chosen to be responsive to changes in the representative’s +actions and resulting voter satisfaction, but to eliminate the “peak-detect” effect. If the average votes on +a single day goes positive, that should not reset the counter. At the same time, the representative needs +to be encouraged to respond to the average, knowing that a change in their actions can indeed pull up the +average in time to keep them in office. + +That suggests that the window should be shorter than the limit. As a suggestion, one-fifth of the limit might be a suitable window size. With this setting, one will know +after four-fifths of the limit whether it looks like the representative has a chance to remain in office. + +Replacement voting is done electronically, via the web pages, and by mail (postage is guaranteed when +mailed to a vote-place POBox, but must be sent in person, with a signature, at the post office). Votes to +replace a candidate begin the day the candidate becomes lame duck and continue for a fixed number of +days. + +This allows time for campaigning, but eliminates manipulation of polling places, as the voting is +spread out. A public library shall be available in every community, with web access and assistance to any +person wishing to vote. This shall receive guaranteed funding, as stated in the constitutional amendment that establishes this system of voting. + +The number of days of voting will be decided after experience using the system in tests. As an +example, two months may be a reasonable time span. Ample time has already been given to prepare +campaigns, during the last fifth of the grace period. + +\subsection{How Bills Are Authored, Introduced, Linked, and Tagged} +Each representative has a listing of bills: +\begin{itemize} +\item that have been introduced +\item that are in a committee that representative sits on +\item that are currently on the floor for debate +\item that have been called for a vote +\end{itemize} +A representative can enter a statement on any bill, if they want, at any point after it is introduced. +The statement will then be visible to the other representatives and to the voters, via the web-pages. + +Each bill is tagged with statements each representative made on it during debate about the bill. +All remarks on a bill that a representative makes during debate are recorded verbatim. No alteration +of these remarks is allowed, for any reason (currently, the congressional record can be modified after the +fact). + +Remarks are recorded in two ways. While they are being spoken on the floor, a stenographer +enters them, in real-time, into the web-site, and they are linked to the bill and made available in all the +various web-pages. In addition, audio and video of the representative delivering the remarks are recorded +into the web-sites and linked, in real-time, to the various web-pages. + +Three stenographers enter transcripts, and the system automatically matches the streams from the three, choosing two that match. At +places in the text where all three differ, all three versions are included on the web-site (thus obviating the +need for revisions after-the-fact). + +All bills are introduced electronically. They are submitted to the system and thus made available in +tagged format for browsing before going into committee. This allows voter feedback to reach representatives who sit on the committee that is considering a given bill. + +Each paragraph of the text of a bill is tagged as addressing one or more of the issues current on the +day the bill is submitted. +An open-source tool is provided to all representatives with which they author, tag, view, and submit +legislation. + +The distributed web-sites are the official record of the legislation, and the process of introducing an amendment is made via electronic submission to site. The site has a "holding pen" for submissions, which are verified by voice communication with the representative who submitted. + +The GAO verifies each tagging of each paragraph. This may take some time, so the tagging that the +author chooses is used until it is either verified or altered by the GAO. All tags must be verified before a +bill can be voted on. This may have the side effect of tending to reduce somewhat the size of the text of +bills. + +When a bill is altered during committee, the alterations are also tagged by the authors. When an +amendment is proposed during committee or during debate on the floor, each paragraph of the amendment is tagged by the author of the amendment. Each such amendment must be submitted electronically +before it is introduced in committee or on the floor. + +When debate is done and a vote called for, it is done electronically, by voting on the text that is in the +web-site. + + + + +%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% +% +%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% +\subsection{Operation of the Site} + +We propose to implement such a voting system via the web. It must be secure, have a human-verifiable backup to recover if compromised, and be accessible to all segments of the population, specifically those without ready computer access, or training. + +\subsubsection{Security of the Site} + +An important issue is security, both for protecting privacy and preventing vote tampering. We propose a system of distributed copies of the site that uses a quorum to detect faulty copies. The system relies on humans and a paper trail to decide which copies are faulty and repair them from good copies. + +site that also has information on the actions of each representative, and a mechanism to suggest new issues to include in the list. It is a one-stop shop for political activity. The voter has a link to each of their representative’s remarks on the floor in both text form and in digital recordings of the remarks being delivered. The voter also has a link to each bill the has authored or sponsored, indexed by issue. The voter can follow the activity of their representative in one window-pane, while updating their emotion token allocation in another. This strong feedback will increase the responsiveness of representatives to what their electorate wants. Campaign contributions will have much less influence because they can only help get the representative into office. After that there will be no mistaking what the people want, the representative must follow the will of the people or be removed. + + +\subsubsection{Ensuring Correctness and Security} +Voter identification can be done in several ways: finger-print reader, social-security “smart” card, password, or all three together. The site is a distributed set of redundant, secure, copies. The program code is the same for all of the copies and is open-source. A distributed quorum system is used to detect and eliminate corruptions of individual copies. Each copy is administered separately, with separate local passwords and people in charge. + +When a discrepancy between copies is detected, the people in charge are alerted and talk via phone to decide which of the copies is non-corrupted. They use the non-corrupted copies to correct the corrupted ones. The copies continually send check-messages to each other, in order to detect discrepancies. + +As soon as a discrepancy is detected on any of the copies, all are alerted and go off-line. Only after voice communication and human decision of which copies are non-corrupt, and correction of the corrupt ones are the copies manually put back on-line. + +The people in charge can collectively decide how to view the corruption and decide whether there is a security breach and how to deal with that. The copies are run by people that both parties nominate via senate and house committees. These committees have equal numbers of both democrat and republican members. + +Each copy keeps a paper-trail of each bit of information on bills and/or representatives that is added to the site. Each copy keeps a paper trail of total emotion tokens positive and negative for each representative for each day, but not how each individual allotted their emotion tokens (that would be too much paper). Individuals may print out their emotion token allocation. + +The information-to-print is passed among the copies, each copy generating a code from the previous copy'’s code plus its own private key, then re-encoding the information with the new code. This way, only the original copy knows the contents of the information. The other copies don'’t know the original copy'’s key, so they don’'t know the voter’s' allocation, so they are unable to decide whether to “accidentally” give a wrong encoding so-as to disqualify the information. + +The information is passed in a fixed ring pattern. The originating copy encodes an identifier with its private key. Assuming no copies know the private key of any of the other copies, only the original copy knows where the information originated. If, say, one copy shares its private keys illegally, the most that can be discovered is that none of the copies sharing keys originated the information. + +During later verification, if the rogue copies attempt to tamper, or “accidentally” mis-encode, then the quorum system will still retrieve the correct original information. + +When all the copies have finished, the final code is printed at the top of the page. When the page is fed back into a copy after a crash or disaster or discovery of hacking, the copy passes the information around again, to generate a new code from the information on the page. The new code must match the code printed on the page. + +This prevents people from altering the information after the fact. Each day, each copy prints the previous day'’s private key into a locked, secure box. The box requires multiple keys; one person from each copy has a physical key. In the case of disaster or hacking, the secure box of each copy is opened, requiring the presence of one person from each of the copies, and the private keys are retrieved. + +For paper verification, an open-source program chooses the voters to be sampled, according to established statistical techniques. People from each copy verify that the choices satisfy randomness properties. Two thirds of the copies must agree that the statistics are random. + +To verify identity electronically, each registered voter is given a smart social-security card that contains a secure micro-controller that contains their private key. The memory of this controller is designed such that it cannot be read externally. + +Established public-private key encryption schemes are used to ensure that votes can only be cast electronically while in physical possession of the card. The micro-controller inside the card performs the encryption process so that the key is never exposed. Once it is written into the micro-controller, the private key is deleted from the main memory of the computer that generated it, and is never saved on hard-disk. Only the paired public key is saved, linked to the social security number and last name of the voter. + +When a voter prints out their emotion token allocation, the code also includes encryption with their private key, performed by the micro-controller in their social-security smart-card. The code must first be decrypted with the voter’s public key, which is only known to the site-copies in the system. The resulting code is then compared to the code generated during the passing of the information among the copies. This is an additional safeguard against 3rd parties attempting to forge vote print outs, and against changing the information after the fact. + + + + + +%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% +% +%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% + +\section{Conclusion} +We have proposed a system of continuous voting that links the actions of representatives to voters’ feelings about those actions. It makes the will of the voters clear and forces the representatives to act according to that will. The system provides quick and easy access to a representative’'s record, as well as access to pending legislation, allowing voters to pro-actively discover up-coming bills of interest and let their representative know how to vote on them. + +If the representative ignores the will of the voters for too long they are removed from office. However a grace period provides balance. It gives the representatives room to cut deals and the opportunity to defy the voters on issues they feel morally or intellectually compelled on. + +The net effect is to diffuse the power of narrow-interest groups and reduce the influence of campaign contributions. Political ads will still run when important legislation is on the floor, but transparency provided by the proposed site and the speed of the internet at disseminating analyses and linking directly to the voting site will diminish the influence of such ads. More importantly, such ads don’t benefit any candidate, so the representative is not beholden to the financer of the ad. + +%+Bibliography +%\begin{thebibliography}{99} +%\bibitem{Label1} ... +%\end{thebibliography} +%-Bibliography + +\end{document} + + diff -r 9b9a2497757d -r eb146c5c05a8 0__Papers/PRT/PRT__formal_def/figures/PR__system_level_activity.svg --- /dev/null Thu Jan 01 00:00:00 1970 +0000 +++ b/0__Papers/PRT/PRT__formal_def/figures/PR__system_level_activity.svg Sat Aug 03 19:24:22 2013 -0700 @@ -0,0 +1,2923 @@ + + + + + + + + + + + + + + + + + image/svg+xml + + + + + + + Master(runtime system)on core 1 + + + Seed VP(created atapp startup,on core 1) + + Application Code + Seed_Fn + Work_Fn + Language Wrapper-LibCode + Proto-RuntimePrimitiveCode + Lang Handlerfor create VP + Assigner Fn + Instances of runtime system(data structson heap) + Instances ofVirtual Processors(data structson heap) + + create VPwrapper Fn + Call to dyn lib + + Top Level Fn + Top Level Fn + Top Level Fn + + + + + + + end VPwrapper Fn + + + + + + + + + + + suspendand switchto runtime + + returnfromsuspend + PR primitive Fnto send request + normal call + + suspendand switchto runtime + Mutex Acquirewrapper Fn + + + end VPwrapper Fn + + + + + + + + + suspendand switchto runtime + returnfromsuspend + normal call + + suspendand switchto runtime + + + normal call + normal call + + + + + + + + + + Timeline of SeedVP + suspend + resume + end + Proto-RuntimePrimitiveCode + PR primitive Fnto create VP + + + + VP 1(created byapplication,on core 2) + + + Master Fn + + + + + + suspendand switchto app VP + + + + start + + + + Timeline of VP 1 + suspend + resume + + start + + + + Timeline of Master on core 1 + suspend + resume + + start + + + Call to dyn lib + Call to dyn lib + Call to dyn lib + call to dyn lib + + + Master(runtime system)on core 2 + + + + + Master Fn + + + + Timeline of Master on core 2 + + + + + return fromsuspend + + PR primitive Fnto send request + PR primitive Fnto send request + PR primitive Fnto send request + + + end + + + + resume + resume + suspend + start + resume + Language PluginCode + Proto-RuntimeMasterCode + + + + + + + + call via Ptr to Dyn Lib Fn + + call via Ptr to Dyn Lib Fn + Lang Handlerfor acq Mutex + + + + + + + Assigner Fn + + + + + suspendand switchto app VP + + + return fromsuspend + + + + + + call via Ptr to Dyn Lib Fn + + call via Ptr to Dyn Lib Fn + core 1 + core 2 + + + + return fromsuspend + + + + return fromsuspend + + + PR OS thread(core1) + + + Main OS thread + + main + Lang Handlerfor create VP + Assigner Fn + + PR_start() + Call to dyn lib + + Top Level Fn + birth Fn + + + + + + end VPwrapper Fn + + + + + + + + + suspendand switchto runtime + + returnfromsuspend + PR__start() + normal call + + suspendand switchto runtime + normal call + + + + + + + + + + Timeline of SeedVP + suspend + resume + end + PR primitive Fnto create VP + Master Fn + + + + + + suspendand switchto app VP + + + + start + + + + Timeline of Master on core 1 + suspend + resume + + start + + + Call to dyn lib + call to dyn lib + + + + return fromsuspend + + PR primitive Fnto send request + resume + + + + + + + + call via Ptr to Dyn Lib Fn + + call via Ptr to Dyn Lib Fn + + + core 1 + + + + return fromsuspend + + PR OS thread(core 2) + + + + + diff -r 9b9a2497757d -r eb146c5c05a8 0__Papers/PRT/PRT__formal_def/figures/PR__timeline_dual.pdf Binary file 0__Papers/PRT/PRT__formal_def/figures/PR__timeline_dual.pdf has changed diff -r 9b9a2497757d -r eb146c5c05a8 0__Papers/PRT/PRT__formal_def/figures/PR__timeline_dual.svg --- /dev/null Thu Jan 01 00:00:00 1970 +0000 +++ b/0__Papers/PRT/PRT__formal_def/figures/PR__timeline_dual.svg Sat Aug 03 19:24:22 2013 -0700 @@ -0,0 +1,446 @@ + + + + + + + + + + + + + + + + image/svg+xml + + + + + + + + + + Suspend(Point 2.S) + + + + Resume (Point 2.R) + + Timeline B + + + Physical time + + + + Suspend(Point 1.S) + + + + Resume (Point 1.R) + + Timeline A + + + + + + + Suspend(Point 2.S) + + + + Resume (Point 2.R) + + Timeline B + + + Physical time + + + + Suspend(Point 1.S) + + + + Resume (Point 1.R) + + Timeline A + + + + diff -r 9b9a2497757d -r eb146c5c05a8 0__Papers/PRT/PRT__formal_def/figures/PR__timeline_dual_2nd.pdf Binary file 0__Papers/PRT/PRT__formal_def/figures/PR__timeline_dual_2nd.pdf has changed diff -r 9b9a2497757d -r eb146c5c05a8 0__Papers/PRT/PRT__formal_def/figures/PR__timeline_dual_2nd.svg --- /dev/null Thu Jan 01 00:00:00 1970 +0000 +++ b/0__Papers/PRT/PRT__formal_def/figures/PR__timeline_dual_2nd.svg Sat Aug 03 19:24:22 2013 -0700 @@ -0,0 +1,545 @@ + + + + + + + + + + + + + + + + image/svg+xml + + + + + + + + + + Suspend(Point 2.S) + + + + Resume (Point 2.R) + + Timeline B + + + Physical time + + + + Suspend(Point 1.S) + + + + Resume (Point 1.R) + + Timeline A + + + + + + Tied Point + + Timeline B + + + + + Tied Point + + Timeline A + + + + + + + + + + Timeline B + + + + + Suspend(Point 1.S) + + + + Resume (Point 1.R) + + Timeline A + + + + visible + NOT visible + + + visible + NOT visible + + diff -r 9b9a2497757d -r eb146c5c05a8 0__Papers/PRT/PRT__formal_def/figures/PR__timeline_single.pdf Binary file 0__Papers/PRT/PRT__formal_def/figures/PR__timeline_single.pdf has changed diff -r 9b9a2497757d -r eb146c5c05a8 0__Papers/PRT/PRT__formal_def/figures/PR__timeline_single.svg --- /dev/null Thu Jan 01 00:00:00 1970 +0000 +++ b/0__Papers/PRT/PRT__formal_def/figures/PR__timeline_single.svg Sat Aug 03 19:24:22 2013 -0700 @@ -0,0 +1,306 @@ + + + + + + + + + + + + + + + + image/svg+xml + + + + + + + + Physical time + + + + Suspend(Point 1.S) + + + + Resume (Point 1.R) + + Timeline A + + + Physical time + + + + Suspend(Point 1.S) + + + + Resume (Point 1.R) + + Timeline A + + + + + Hiddenmeta-comm + + diff -r 9b9a2497757d -r eb146c5c05a8 0__Papers/PRT/PRT__formal_def/figures/PR__timeline_sync_def.pdf Binary file 0__Papers/PRT/PRT__formal_def/figures/PR__timeline_sync_def.pdf has changed diff -r 9b9a2497757d -r eb146c5c05a8 0__Papers/PRT/PRT__formal_def/figures/PR__timeline_sync_def.svg --- /dev/null Thu Jan 01 00:00:00 1970 +0000 +++ b/0__Papers/PRT/PRT__formal_def/figures/PR__timeline_sync_def.svg Sat Aug 03 19:24:22 2013 -0700 @@ -0,0 +1,498 @@ + + + + + + + + + + + + + + + + + + + image/svg+xml + + + + + + + + + + Timeline B + + + + + SyncPoint + + Timeline A + + + + write + read + + + + Timeline B + + + + + SyncPoint + + Timeline A + + + + write + read + + + SyncPoint + + write + + X + + + + + + + Timeline B + + Timeline A + + write + read + read + write + + shift relative to each other + + diff -r 9b9a2497757d -r eb146c5c05a8 0__Papers/PRT/PRT__formal_def/figures/PR__timeline_tie_point_ordering.pdf Binary file 0__Papers/PRT/PRT__formal_def/figures/PR__timeline_tie_point_ordering.pdf has changed diff -r 9b9a2497757d -r eb146c5c05a8 0__Papers/PRT/PRT__formal_def/figures/PR__timeline_tie_point_ordering.svg --- /dev/null Thu Jan 01 00:00:00 1970 +0000 +++ b/0__Papers/PRT/PRT__formal_def/figures/PR__timeline_tie_point_ordering.svg Sat Aug 03 19:24:22 2013 -0700 @@ -0,0 +1,369 @@ + + + + + + + + + + + + + + + + image/svg+xml + + + + + + + + + + Tied Point + + Timeline B + + + + + Tied Point + + Timeline A + + + + + + + + + + Timeline B + + + + + Suspend(Point 1.S) + + + + Resume (Point 1.R) + + Timeline A + + + + visible + NOT visible + + + visible + NOT visible + + diff -r 9b9a2497757d -r eb146c5c05a8 0__Papers/PRT/PRT__formal_def/figures/PR__timeline_tie_point_ordering_2.svg --- /dev/null Thu Jan 01 00:00:00 1970 +0000 +++ b/0__Papers/PRT/PRT__formal_def/figures/PR__timeline_tie_point_ordering_2.svg Sat Aug 03 19:24:22 2013 -0700 @@ -0,0 +1,324 @@ + + + + + + + + + + + + + + + + image/svg+xml + + + + + + + + + + + + + + Timeline B + + + + + Suspend(Point A1.S) + + + + Resume (Point A1.R) + + Timeline A + + + + visible + NOT visible + + + visible + NOT visible + + Suspend(Point B1.S) + + + Resume (Point B1.R) + + + diff -r 9b9a2497757d -r eb146c5c05a8 0__Papers/PRT/PRT__formal_def/figures/PR__what_runtime_does.svg --- /dev/null Thu Jan 01 00:00:00 1970 +0000 +++ b/0__Papers/PRT/PRT__formal_def/figures/PR__what_runtime_does.svg Sat Aug 03 19:24:22 2013 -0700 @@ -0,0 +1,2211 @@ + + + + + + + + + + + + + + + + + + + + image/svg+xml + + + + + + + Master(runtime system)on core 1 + + + Seed VP(created atapp startup,on core 1) + + Application Code + Seed_Fn + Work_Fn + Language Wrapper-LibCode + Proto-RuntimePrimitiveCode + Lang Handlerfor create VP + Assigner Fn + Instances of runtime system(data structson heap) + Instances ofVirtual Processors(data structson heap) + + create VPwrapper Fn + Call to dyn lib + + Top Level Fn + Top Level Fn + Top Level Fn + + + + + + + end VPwrapper Fn + + + + + + + + + + + suspendand switchto runtime + + returnfromsuspend + PR primitive Fnto send request + normal call + + suspendand switchto runtime + Mutex Acquirewrapper Fn + + + end VPwrapper Fn + + + + + + + + + suspendand switchto runtime + returnfromsuspend + normal call + + suspendand switchto runtime + + + normal call + normal call + + + + + + + + + + Timeline of SeedVP + suspend + resume + end + Proto-RuntimePrimitiveCode + PR primitive Fnto create VP + + + + VP 1(created byapplication,on core 2) + + + Master Fn + + + + + + suspendand switchto app VP + + + + start + + + + Timeline of VP 1 + suspend + resume + + start + + + + Timeline of Master on core 1 + suspend + resume + + start + + + Call to dyn lib + Call to dyn lib + Call to dyn lib + call to dyn lib + + + Master(runtime system)on core 2 + + + + + Master Fn + + + + Timeline of Master on core 2 + + + + + return fromsuspend + + PR primitive Fnto send request + PR primitive Fnto send request + PR primitive Fnto send request + + + end + + + + resume + resume + suspend + start + resume + Language PluginCode + Proto-RuntimeMasterCode + + + + + + + + call via Ptr to Dyn Lib Fn + + call via Ptr to Dyn Lib Fn + Lang Handlerfor acq Mutex + + + + + + + Assigner Fn + + + + + suspendand switchto app VP + + + return fromsuspend + + + + + + call via Ptr to Dyn Lib Fn + + call via Ptr to Dyn Lib Fn + core 1 + core 2 + + + + return fromsuspend + + + + return fromsuspend + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + diff -r 9b9a2497757d -r eb146c5c05a8 0__Papers/PRT/PRT__formal_def/figures/Portability_stack_combined.pdf Binary file 0__Papers/PRT/PRT__formal_def/figures/Portability_stack_combined.pdf has changed diff -r 9b9a2497757d -r eb146c5c05a8 0__Papers/PRT/PRT__formal_def/figures/Portability_stack_combined.svg --- /dev/null Thu Jan 01 00:00:00 1970 +0000 +++ b/0__Papers/PRT/PRT__formal_def/figures/Portability_stack_combined.svg Sat Aug 03 19:24:22 2013 -0700 @@ -0,0 +1,2691 @@ + + + + + + + + + + + + + + + + + image/svg+xml + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + Lang Syntax + + + + Request Intf + + + + VMS Intf + + + + ISA + + + + + + + + + Interface + Layer + + + + + + + Toolchain + + + + Specializer + + + + + Specializer + + + + + + + + + Toolchain + + + + Specializer + + + + + Specializer + + + + + + + + + Toolchain + + + + Specializer + + + + + Specializer + + + + + + diff -r 9b9a2497757d -r eb146c5c05a8 0__Papers/PRT/PRT__formal_def/figures/Proto-Runtime__modules.pdf Binary file 0__Papers/PRT/PRT__formal_def/figures/Proto-Runtime__modules.pdf has changed diff -r 9b9a2497757d -r eb146c5c05a8 0__Papers/PRT/PRT__formal_def/figures/Proto-Runtime__modules.svg --- /dev/null Thu Jan 01 00:00:00 1970 +0000 +++ b/0__Papers/PRT/PRT__formal_def/figures/Proto-Runtime__modules.svg Sat Aug 03 19:24:22 2013 -0700 @@ -0,0 +1,219 @@ + + + + + + + + + + + + + + + + + image/svg+xml + + + + + + + ParallelismConstructModule + + Hardware Specific Module(Proto-Runtime) + Assignmentof Workonto CoresModule + Hardware Abstraction Interface + + + + Code Stack for Runtime System + + diff -r 9b9a2497757d -r eb146c5c05a8 0__Papers/PRT/PRT__formal_def/figures/Proto-Runtime__modules_lang_breakdown.pdf Binary file 0__Papers/PRT/PRT__formal_def/figures/Proto-Runtime__modules_lang_breakdown.pdf has changed diff -r 9b9a2497757d -r eb146c5c05a8 0__Papers/PRT/PRT__formal_def/figures/Proto-Runtime__modules_lang_breakdown.svg --- /dev/null Thu Jan 01 00:00:00 1970 +0000 +++ b/0__Papers/PRT/PRT__formal_def/figures/Proto-Runtime__modules_lang_breakdown.svg Sat Aug 03 19:24:22 2013 -0700 @@ -0,0 +1,243 @@ + + + + + + + + + + + + + + + + + image/svg+xml + + + + + + + Code ofparallelismconstructmodule + Code ofassignmentonto coresmodule + + + Code Breakdown of a Language Implementation + Code ofwrapperlibrary + + Compiled intoapplicationexecutable + Compiled separatelyas a dynamic library + + diff -r 9b9a2497757d -r eb146c5c05a8 0__Papers/PRT/PRT__formal_def/figures/Proto-Runtime__modules_plus_plugin.svg --- /dev/null Thu Jan 01 00:00:00 1970 +0000 +++ b/0__Papers/PRT/PRT__formal_def/figures/Proto-Runtime__modules_plus_plugin.svg Sat Aug 03 19:24:22 2013 -0700 @@ -0,0 +1,618 @@ + + + + + + + + + + + + + + + + + image/svg+xml + + + + + + + + Master(runtime system) + ConstructSemanticsModule + + Hardware Specific Module(Proto-Runtime) + Assignmentof Workonto CoresModule + Language Plug-in + Hardware Abstraction Interface + + + + + + + Seed VP + + + + VP createdby Application + + + + VP createdby Application + + Application Code + Seed_Fn + Work_Fn + prallelism_construct2_Fn + Language Wrapper LibCode + Proto-Runtime PrimitiveCode + Language PluginCode + Proto-RuntimeCode + Handlerfor LanguageConstruct1 + Handlerfor LanguageConstruct2 + Master Fn + Assigner Fn + Instance of runtime system + Instances ofVirtual Processors + + + + + + + + prallelism_construct1_Fn + + + + + diff -r 9b9a2497757d -r eb146c5c05a8 0__Papers/PRT/PRT__formal_def/figures/Proto-Runtime__modules_plus_plugin_plus_code.pdf Binary file 0__Papers/PRT/PRT__formal_def/figures/Proto-Runtime__modules_plus_plugin_plus_code.pdf has changed diff -r 9b9a2497757d -r eb146c5c05a8 0__Papers/PRT/PRT__formal_def/figures/Proto-Runtime__modules_plus_plugin_plus_code.svg --- /dev/null Thu Jan 01 00:00:00 1970 +0000 +++ b/0__Papers/PRT/PRT__formal_def/figures/Proto-Runtime__modules_plus_plugin_plus_code.svg Sat Aug 03 19:24:22 2013 -0700 @@ -0,0 +1,2026 @@ + + + + + + + + + + + + + + + + + image/svg+xml + + + + + + + Master(runtime system)on core 1 + + + Seed VP(created atapp startup,on core 1) + + Application Code + Seed_Fn + Work_Fn + Language Wrapper-LibCode + Proto-RuntimePrimitiveCode + Lang Handlerfor create VP + Assigner Fn + Instances of runtime system(data structson heap) + Instances ofVirtual Processors(data structson heap) + + create VPwrapper Fn + Call to dyn lib + + Top Level Fn + Top Level Fn + Top Level Fn + + + + + + + end VPwrapper Fn + + + + + + + + + + + suspendand switchto runtime + + returnfromsuspend + PR primitive Fnto send request + normal call + + suspendand switchto runtime + Mutex Acquirewrapper Fn + + + end VPwrapper Fn + + + + + + + + + suspendand switchto runtime + returnfromsuspend + normal call + + suspendand switchto runtime + + + normal call + normal call + + + + + + + + + + Timeline of SeedVP + suspend + resume + end + Proto-RuntimePrimitiveCode + PR primitive Fnto create VP + + + + VP 1(created byapplication,on core 2) + + + Master Fn + + + + + + suspendand switchto app VP + + + + start + + + + Timeline of VP 1 + suspend + resume + + start + + + + Timeline of Master on core 1 + suspend + resume + + start + + + Call to dyn lib + Call to dyn lib + Call to dyn lib + call to dyn lib + + + Master(runtime system)on core 2 + + + + + Master Fn + + + + Timeline of Master on core 2 + + + + + return fromsuspend + + PR primitive Fnto send request + PR primitive Fnto send request + PR primitive Fnto send request + + + end + + + + resume + resume + suspend + start + resume + Language PluginCode + Proto-RuntimeMasterCode + + + + + + + + call via Ptr to Dyn Lib Fn + + call via Ptr to Dyn Lib Fn + Lang Handlerfor acq Mutex + + + + + + + Assigner Fn + + + + + suspendand switchto app VP + + + return fromsuspend + + + + + + call via Ptr to Dyn Lib Fn + + call via Ptr to Dyn Lib Fn + core 1 + core 2 + + + + return fromsuspend + + + + return fromsuspend + + + + diff -r 9b9a2497757d -r eb146c5c05a8 0__Papers/PRT/PRT__formal_def/figures/Proto-Runtime__modules_plus_plugin_plus_code_back.svg --- /dev/null Thu Jan 01 00:00:00 1970 +0000 +++ b/0__Papers/PRT/PRT__formal_def/figures/Proto-Runtime__modules_plus_plugin_plus_code_back.svg Sat Aug 03 19:24:22 2013 -0700 @@ -0,0 +1,1678 @@ + + + + + + + + + + + + + + + + + image/svg+xml + + + + + + + + Master(runtime system)on core 1 + ConstructSemanticsModule + + Hardware Specific Module(Proto-Runtime) + Assignmentof Workonto CoresModule + Language Plug-in + Hardware Abstraction Interface + + + + + + Seed VP + + + + VP createdby Application1 + + + + VP createdby Application2 + + Application Code + Seed_Fn + Work_Fn + Language Wrapper-LibCode + Proto-RuntimePrimitiveCode + Language PluginCode + Proto-RuntimeCode + Handlerfor create VP + Handlerfor LanguageConstruct2 + Master Fn + Assigner Fn + Instances of runtime system + Instances ofVirtual Processors + + create VPwrapper Fn + + + + + Handlerfor LanguageConstruct1 + + + + + + + + + + + + + Call via Ptr + + Top Level Fn + Top Level Fn + Top Level Fn + + + + + + Top Level Fn + Work_Fn + + + end VPwrapper Fn + + End VPPrimitive Fn + + + + + + + + + normal call + + + suspendand switchto runtime + + returnfromsuspend + create VPprimitive Fn + normal call + + + suspendand switchto runtime + Mutex Acquirewrapper Fn + + + + end VPwrapper Fn + + end VPPrimitive Fn + + + + + + + normal call + + + suspendand switchto runtime + + returnfromsuspend + send requestprimitive Fn + normal call + + + suspendand switchto runtime + + + normal call + normal call + normal call + normal call + Call via Ptr + Call via Ptr + Call via Ptr + + + + Master(runtime system)on core 2 + + + + Handlerfor LanguageConstruct1 + Handlerfor LanguageConstruct2 + Master Fn + Assigner Fn + + + + + Handlerfor LanguageConstruct1 + + + + + + + + + + + + + Call via Ptr + + Top Level Fn + Call via Ptr + Call via Ptr + Call via Ptr + + diff -r 9b9a2497757d -r eb146c5c05a8 0__Papers/PRT/PRT__formal_def/figures/Proto-Runtime__modules_plus_plugin_plus_code_back_2.svg --- /dev/null Thu Jan 01 00:00:00 1970 +0000 +++ b/0__Papers/PRT/PRT__formal_def/figures/Proto-Runtime__modules_plus_plugin_plus_code_back_2.svg Sat Aug 03 19:24:22 2013 -0700 @@ -0,0 +1,2231 @@ + + + + + + + + + + + + + + + + + image/svg+xml + + + + + + + Master(runtime system)on core 1 + + + Seed VP(created atapp startup,on core 1) + + Application Code + Seed_Fn + Work_Fn + Language Wrapper-LibCode + Proto-RuntimePrimitiveCode + Lang Handlerfor create VP + Assigner Fn + Instances of runtime system(data structson heap) + Instances ofVirtual Processors(data structson heap) + + create VPwrapper Fn + Call to dyn lib + + Top Level Fn + Top Level Fn + Top Level Fn + + + + + + Top Level Fn + Work_Fn + + + end VPwrapper Fn + + + + + + + + + + + + suspendand switchto runtime + + returnfromsuspend + PR primitive Fnto send request + normal call + + + suspendand switchto runtime + Mutex Acquirewrapper Fn + + + end VPwrapper Fn + + + + + + + + + + suspendand switchto runtime + + returnfromsuspend + normal call + + + suspendand switchto runtime + + + normal call + normal call + + + + Master(runtime system)on core 2 + + + + Handlerfor LanguageConstruct1 + Handlerfor LanguageConstruct2 + Assigner Fn + Handlerfor LanguageConstruct1 + + Top Level Fn + + + + + + + Timeline of SeedVP + suspend + resume + end + Proto-RuntimePrimitiveCode + PR primitive Fnto create VP + + + + VP 1(created byapplication,on core 2) + + + + VP 2(created byapplication,on core 3) + + Master Fn + + + + + + end VPwrapper Fn + + send requestprimitive Fn + + + + + + + + + suspendand switchto app VP + + returnfromsuspend + + + suspendand switchto runtime + normal call + normal call + + + + + start + + + + Timeline of VP 1 + suspend + resume + + start + + + + Timeline of Master on core 1 + suspend + resume + + start + + + Call via Ptr + Call to dyn lib + Call to dyn lib + Call to dyn lib + Call to dyn lib + + + Master(runtime system)on core 2 + Lang Handlerfor Acq Mutex + + + + + PR primitive Fnto create VP + Master Fn + + + + + + + suspendand switchto app VP + + + + + + Timeline of Master on core 2 + + Call via Ptr + Call to dyn lib + + + + + + return fromsuspend + + PR primitive Fnto send request + PR primitive Fnto send request + PR primitive Fnto send request + + + end + + + + resume + resume + suspend + start + resume + + return fromsuspend + Language PluginCode + Proto-RuntimeMasterCode + + + diff -r 9b9a2497757d -r eb146c5c05a8 0__Papers/PRT/PRT__formal_def/figures/Scheduling_states_2.eps --- /dev/null Thu Jan 01 00:00:00 1970 +0000 +++ b/0__Papers/PRT/PRT__formal_def/figures/Scheduling_states_2.eps Sat Aug 03 19:24:22 2013 -0700 @@ -0,0 +1,460 @@ +%!PS-Adobe-3.0 EPSF-3.0 +%%Creator: cairo 1.8.6 (http://cairographics.org) +%%CreationDate: Sat Nov 13 08:19:40 2010 +%%Pages: 1 +%%BoundingBox: 0 0 196 77 +%%DocumentData: Clean7Bit +%%LanguageLevel: 2 +%%EndComments +%%BeginProlog +/cairo_eps_state save def +/dict_count countdictstack def +/op_count count 1 sub def +userdict begin +/q { gsave } bind def +/Q { grestore } bind def +/cm { 6 array astore concat } bind def +/w { setlinewidth } bind def +/J { setlinecap } bind def +/j { setlinejoin } bind def +/M { setmiterlimit } bind def +/d { setdash } bind def +/m { moveto } bind def +/l { lineto } bind def +/c { curveto } bind def +/h { closepath } bind def +/re { exch dup neg 3 1 roll 5 3 roll moveto 0 rlineto + 0 exch rlineto 0 rlineto closepath } bind def +/S { stroke } bind def +/f { fill } bind def +/f* { eofill } bind def +/B { fill stroke } bind def +/B* { eofill stroke } bind def +/n { newpath } bind def +/W { clip } bind def +/W* { eoclip } bind def +/BT { } bind def +/ET { } bind def +/pdfmark where { pop globaldict /?pdfmark /exec load put } + { globaldict begin /?pdfmark /pop load def /pdfmark + /cleartomark load def end } ifelse +/BDC { mark 3 1 roll /BDC pdfmark } bind def +/EMC { mark /EMC pdfmark } bind def +/cairo_store_point { /cairo_point_y exch def /cairo_point_x exch def } def +/Tj { show currentpoint cairo_store_point } bind def +/TJ { + { + dup + type /stringtype eq + { show } { -0.001 mul 0 cairo_font_matrix dtransform rmoveto } ifelse + } forall + currentpoint cairo_store_point +} bind def +/cairo_selectfont { cairo_font_matrix aload pop pop pop 0 0 6 array astore + cairo_font exch selectfont cairo_point_x cairo_point_y moveto } bind def +/Tf { pop /cairo_font exch def /cairo_font_matrix where + { pop cairo_selectfont } if } bind def +/Td { matrix translate cairo_font_matrix matrix concatmatrix dup + /cairo_font_matrix exch def dup 4 get exch 5 get cairo_store_point + /cairo_font where { pop cairo_selectfont } if } bind def +/Tm { 2 copy 8 2 roll 6 array astore /cairo_font_matrix exch def + cairo_store_point /cairo_font where { pop cairo_selectfont } if } bind def +/g { setgray } bind def +/rg { setrgbcolor } bind def +/d1 { setcachedevice } bind def +%%EndProlog +%%Page: 1 1 +%%BeginPageSetup +%%PageBoundingBox: 0 0 196 77 +%%EndPageSetup +q +Q q +q 0 0 197 77 rectclip +% Fallback Image: x=0, y=0, w=196, h=76 res=300dpi size=776967 +[ 0.24 0 0 0.24 0 0.916468 ] concat +/DeviceRGB setcolorspace +8 dict dup begin + /ImageType 1 def + /Width 817 def + /Height 317 def + /BitsPerComponent 8 def + /Decode [ 0 1 0 1 0 1 ] def + /DataSource currentfile /ASCII85Decode filter /LZWDecode filter def + /ImageMatrix [ 1 0 0 -1 0 317 ] def +end +image +J3I@:GU(oO"FIqV0;rCK*=mro@So+\<\5,H7Uo<*jE<[.O@Wn[3@'nb-^757;Rp>H>q_R=Al + C^cenm@9:1mM9jS"!dTMT<$3[GQ$8#0$s<4ZX!SPQ1`A'g"%ioWjnAY&^gM+`4=1jRLW!YA=M/6)*KS9PE`kN%="Tc + _Aoh+fk'&t\ctI:h]"?)EVlIDd]!t-Xh$Ve"[JLu9_eZN2gNOTbQKrP([VkioDBB7=[,UR, + Hi@$GNQ^C&p\W4]93o[!Fh+rPIlj(Jn9-kkY-14!k3ht)5*"HoRH + ;haXA))8C?"dI7ot,?P2T;S5?2%pJG?hVRcZ<)f7H[>"\)m@0?8V'$JR>njlZch42=GEj[T + 4&n?hf?XIq!P\.u@^0VDF-?GfCPQA,''qCLT7E23?\J*`H"p).jbLiOLj8QXgt7CRShB%EX + iFq6k?EkOj:*SRe,%AVXodSr'0))J4\okLfL'T'%#7D6$`!`A)dSfo@#OBmIG1V.mMqX0?E + InfEH^'PuKNd`;(C\aGrimCVg+cLnm>S*p6in/MrB_=3sJ%E%]U:DLk=S8TFgnf3]:amtt* + /^*`*cS`u=SF8VeoGnH2dI`t_:"/bU:K>sq+ssgKcl$loZ@-jp`9s"i + V8utNT9gU:R1&;So:1_qAt]ol2%!TXm>j*caE0;T'sA]r#ZHgnbf"4c1ClU:Y#.:T5WQ[rZ + @3_q>R"imJHo*ch78:TC;^Xhuj(2:F3QNPpBD[Js(>X@KF9s*])p%>.#(RD)FIVD%H55cLJ[C[6eHetiWMQ';%=d + <=H*&a;#Q*#g(u1n*:KUa;2S4G.RdIA(#m/7Mc"@E7G,9iirieH&L<&FZF9n0Hjks2Xu8c% + h&GC-EK3oA3_*<>*TP(`Kb5XX`7SK>U]c71;@Z#a=UcP87#@%(/k/Ca#i)(-?%E3_1_7*i, + G`8GP>Z9n5GAiRV$*J3dYr(d=\L[65g5KkXC+ZJG:Vd.YSC']>"`"1.ODluQW!6X9;*jh`' + hG/;\!2k3K,!@7*1iq+?3'AbqnL8d@&s:C'@bB2000r7jpRT!C,"4V.\*0fki + b*c3_l3+=,<=W20!C\WZNCfL(#,Y(^RN*^]>cL_9,h6&9%B@A6"EeMm7;8l(Y-qBbh-93!ENWt#)=5*U[lihV72@ctm.h,Qr5U$At/p.8#*B + 8Y!Odbn>/'njfA`cO0ZW&>F=kRsGXTZ!HQB#&URnPW?7&CrIY#))IDen`oZ%;POHon**5pQ + ?6[oVqR7`OU>7kMQAd]?p5=^Wa45btqglpb7-$$56"CV!G0/6uD]&h_,[#5<"X!dhUi!4Cd + e5T92q)pNZs7HqKeY4c2Vh0\UEn\/)MqHm&!"7O#=^K)Hkhq?O?_=ZUlQk&D8M4bf,7*1h5 + %Uf[&*%,]Y[&@HV=A#j'L$@7N*Z/eOiS6R?Xe_.Y1r;mTX?VR37O`bkKQ,quWJebc0pY_]: + ub]&;X/)>%2eFcA(e!snc1qr=*F$5r/Fg/5"WKA0.(5`rI+`p@]WTX.Th3oQ045b]3sKBKL + tc"B"ZV$ZjLLOr67O+0S7PK.lM"ph*Rt5Q(cmW3bM^b/ugcAU/`-okM5HooEKjWq@>Dr=d* + F7NarR7MagLt"r/oW1t#=<'5:^P@K=-1b$&]!J=N1.o`e*kJ2e!Q>q-/Y:d`c66mm]%>T*3 + fagpCB88D'_XlZ4df2iYqN?*ErV$UMJ>7Y1/X@#Xc*)=GZb@9hoSKj+Rn\[=kC^e"Z/-TqE + `hJ45M*VZ]k"'7B=bnJD>uVBuf&jOYE:'ShX,hCDD,*3^5aY) + *Jq>qX(10qgo1RS8h/c0,Y?$ZfQ%F4nOI!Q=9EC3$?!L.qZ\bm")"nLT$=LM#ANR$04VrC?a?KBC[PKR'.K'sh8\W'Q$CMQ$*O1 + MHiSH]=R7kP>_!FWha7L[/-pLWQ/h2O!V06K;Ltk[%(sA:o2C.="Yd@Ik(\\[2)%;>+XQC7 + hKbDrcdk`!;(D*\ePW#U_b%jg0XY@k_(5uEi90al$hgc;"c=H'Fh_[Ij> + +5&4+Tr,$$GOK8!hX93IGZ4/2eWU%T8XQb>QLl,s66N^PLG@9ED6G:G8OV + *\+7UcdhY2]IX"TW2B;62Ob;UB,h\bUsk(FL@jT!0DU6kW0mO66":-)GlA + 0d#d?tFI%k.'<73.0!q$"#c^/#!_L,IJ56#M3:WXb"&&"'%8QL[F:$=8d=B1)5k5N6e>U3# + %BZ]L@Dr^#[g3Q/LX+V4lq%12lORcUg*o_j+_qW=N"PRc&!7800bEr[Wr/Mnnu_'_bNdQW_ + ?.lg"DQB^TUQTJU=K=iek;VAmuE]j@-g\Q`M(/50_lG<<5ZUGU`m,\kuJV*A/6n5W6h+I&T + IQldL5Qc$.)'FWtkl#ZiP0'&dndYJ/8:R[L$rA(N'QiDj:MM55kSD)QrWMK2WM)[!tj)O31 + rOEPRSC2BDn.*3R6TNOK?_*"R&B'97AG5^sh0K&'fi!3to.bKf@&0cse#+/!ZslDb.DU>/# + `ZU"-pEY.]U1mW]4+g$"@_4q9e]Ta]o*&9)inh>HC']WWKg6&BPnCeZ']G/TLeo@;H^rIJ[ + kQi;>-(mOMmZARulI2Ct-D5W2lR;SF'dmE[-a@1uTrf^ta!3?qH',]*lZ4J[P_92k*:fX+_ + 5,[KEi?en.^>Sh:C[QV[2si)/$`]hE4I:Q5jA>Z-#qfN^u[.!(86:+\Nrd]NHkG[6On.'0! + ajsk\=$>f.UR90B$Se8* + O5VQ%2`[mN1WsV8$r&mKRSlt()t2i)JQ"cf#SHTuk=s8>0dcHV"#fGn47oO0!`,?;Tci=Q>k + d437^P.9&rtX#P=G$ImbuhK&HW`PRhl)*RK/aHo++8h#qMYT*g7*W1U-0FkpiAG1=Ds9oW\ + (QkspuK9=2B",/3f8V*m)l7"G.9&d&`.-Lq^-!O78Ji0cmHfenV"pbFj&kbUd*i7X@aVSX' + 3ZgU+%;a58o4L'AKYIX`HnK,IQo!6?/0m8s>eLeU_;Qp`!_:(D$qbqVt;me`6_A*d6V++88 + *J!lG$iqnYR,.-jk])srC7a1dM&Pq8;s6LHJb&iX\IULVID+m@NHL(`#(AQgMG@N:s@_cC'9Y?aj&u*2. + 'B74"=*%;cUROM',_&b5]uc?KeCe&*ZV9igD;FkRm%L'U^Zu2ToL'@B:"LXhGA3N@4CN;76 + @3p+^&81q%#WrmU=>NXucL38a9&"V!N7OcZ,0U=O+A'p'",(,gP>oiICRAgfoB:L_1]fbs6 + >Z+t)U[XdTo7p4B9"SGJ@O_>LRQ"b1(%p!O]p7Z4ZUk=gipaKod1/T)8Iii&P^9j:1m9(RR + E"rmmm1uRE(1utLHYhm;/+';1Pc55pdl&m5=\V+G:FdOFF$-,cDm3RQP;?\!fl2-AE46726 + W6VYSeZGeCC[I^V=2eW!@HbM*DbU^0hi>*CaVeF@TMG./,RG6aC"d$3jI/C> + 2=h_c7bTEfg!`G8DW64p%AktQ!GSU>Y'I(.=XJe\3M>1RI<=kA2;0>e3!*r,:L%S-5]]j(NG(UlN95A4IYjj3 + `j92QpB>HqB62,)6/Z"==hP:jPJ:6%+ZYCJQF]0TgKZ:Mn$HYpqW)f&F<5#KqQT:5\XN)!> + u?loSH`g'Xom+nfP:5N7U'M8k9unIkm52A@JiECYn:$X#JC3jUk@K3>%B6'p39>;GP1;n"U + MrbitHo+OYaoD4?A@OVLiD#*qU'lO^c%g<3mGPdC(L&tBs;)3oJMQ+:/;os,T6M+lD7#h7S + 3o=lD&eH$(UP?-97,/3h*gBs$+]oJL3Nc^Xi0*bMEQ2-u=q4X6.4AsP`*DKZ"b5YmH+;FX^ + O"4S(enWmam;-^3Dc7Fb&%2P'@rJ%1:ednKq5'ZCjdpb]fS8Pi%D&j2J-)bH;2N$AZn/$IP + d]Q>Ik,kh0Uil(,eX^=2tWOe + Y"m@Pb)'m5Q#m>j0Fk=Z3b>/r/&<<\JL)`l`Xq[p(p'\K0Z1=?8\$KG:9T."Bd%e'F0LuFXY + V'UI2Y0hj#n):M*(USN\[(B#N'enCH`N2\n)$uuTkd.=G\ON:Hf&8VI3i]A%ro[33PrhdNq + gl7=KZ!>`%2`!G1mn]3k_a^tMF,'G0es'EY-/S2"^#uJH\]3p[C^dqVM-=cJPNufk?1[=pZ + RI,F$Y)=P_d_jSW>;$cR")U@$KEX^:WdHqs^JDl#'ZaXn2cZ\cRZ!dB?)_DK"KYHW[Gh.$b`0`E[i3r.2p;fVC4GDT^i_%AJO0nR%b>KL-chg5)n2%u'kfaBYji + r3=En`=;6cXqJ^5kXWa>mE):bDKrEsWoaJ4e\h0Cb?WlJr8GpLMJdF1-7[VM:J$tQ1WG4tp + [N^8G's(Tp!-hLd(Kn8k]&r<@]gF(S)!auB_s4q6@p$JDHr.&cA,uE#LOPPe%IonkWEa$gL + TU&?$hlhg]u&Z"E&R'YNk)&:QM(f6.UHuf"GmO[hPn$6ER9+jTm6c\L^^e>]TChdN1Q>X?3Zh8.l0`S>+];_ZS#\Gl9e*SSQm'\gR + .lOaG/akhI1hS&9'1>0,dd90^=eU8R:Y2)TR-@RfUJ4eLUo3I9Fn)8^5iP$:WGd36#c]@`% + J,I7r(=ep&e0,H$Xq?9\4s/iL7HAng+7s-UC=(gbA:K$[HunTE!+`4="ba\H+Wa;=rc.*ak + A5S=XR)XV-h$/p^Bn&IXc;]n5'?*RQ0E^c_8.h-[F_Mclf^jJ7NQlX.DJXWRHo=4lb,G=b1 + eg;2LV-I]j,l0jYHYgAF`0Rf"7j2uoY4,4:fsj'g3p[ + gZMlV*[!h'DgOL:bo`&e%s)G;1*uHKX$_F/B)_G-@?@!hhoEs7fqaL6DQ2,otWR\'dg_-^W + S:+a*GN'@iWn?,+(&>VTqnKh=Dka@.41E8TnRgqH9%qI<\,63YrP.0RZ6cdc&bDRm[]=8t5 + 0eC0+K_mdb.ldU&,6hK#mGrIi=MAU/f>+R6fJ[pPYNYBMacYOE:HQ-SW:]3XkAS(6s&ID9.WD;5[9$!j4%E>4:117Ip + W<,&a1h-(HBb6%8P?iV]:bg0ZR)BBTS8YsmMobsB%Y?A!ZC\A\fQHs9QJWr)2Tt]t0ri9#' + cYS;1X%S(/GlnOWC:4.AF8"E2QVXU2lZN(FT%@nkh=#Rc*Zl(ZC$!T9YYEds-[eYK5'T1.Q + :iY13dpqu'9DV&rVo+O"9SZiE$Pen5k%/T"[R!OX:<#4d2NBTCg$W/^+=?fii;2SLCZDHct + *ePn750*7.EZD'h*+Q>8K`uKOYlD6VM7>#Vj7Gp7JJi*iHnLR[2&!Z6M3O!Cj_c)9Ho0RjU + euKVKtgEho`d7*d;qblG'.i@cH0@t)G'fF/8+`:@lE'0-1* + -qTTfJ"MkGF8qVl?*HXOe75I\8@*)2$Kd0/eFJUK\;Y7pa9dClF3mA3n"U,pnPUYmEeEi:c + AY/fDuF1B:W9/(o'qRqGmtKqi?cG,;6D& + 9brK:5&E;W3>`Gp9; + p1j-k[a\+C]Vd:'ErM!bI:L_`k4f$S@pA4u;V + ^^XZHHc^:"/Z=uF'":[GlC3sj`u;fS*,(rLSO*[I]'74HN(skmrq_"WNP+8c + e(OB)`TGVKD1e/*KV=n0pe-RS + .k]AFR#%j%B&U^h*,=Hd=&n4g5I*d$I`)rEA@['fKOW"qNZ%j''e6@inFpc,S817s\7PfsF + h%,'p)H0JeNKFfi.FUF"A!D%pOk)TaGjuhbe9d7=p-2(C!?bneK92636V)J7,%OZ2OchUm8 + GO1bP>k:\YEChrGp+MFe=2YbG#(^*5q$:YUQLD5/%(`1IR>*UP`iIV9)2mHAX'NeP/L\MFO + _3;(k.g+BGJ_cb^7;[_d&+aWCGnV(8b$*R=r\HN@?4LUoY[e;^a4ke`?lAe>I'pV";]"Ye( + S(\U[//AVG1^'W4oB.RG>')5&iL:T;a)djAYO)=U71I*mSq:+/h>mljf`g+^uqX3KZ^3%,E + iS7gti)B_C89[JWjPH^p?.PPIboc'K7g3T%;X[;7a,+iN1Ke4c=5UO/h>r3+qct9CH$oKE/ + M`uleH6-G6&'=ATi + LCYXQp1IXC_*HcC*6SlX<[)(030jWoe-`odd:*FG*_qB4!)Ue>ZIIcRWc6!%]?nYf-gb>'2 + ]3b3b0A,JMn4RrDu7&>;Te#[(C(eCkCtS$j+IJQ`DmBU4Xr\BCBs+R_\J?7J/IRtmeW%n(P+i^iCYsN(V:R+SA@`L`;1M?e + =hodaX"f1l^efn%\9=%8?E<`tDf)Yl.m!Ia'f17]0idTj?/Uma(r[qZT'.0DuMJt<<3 + Ue[JW&TQ=Z0Y=16J"ZJ. + \oD)Ei_R[R-d7ip&%qH']5*5Jrlo0e")2M$nad&uhg0B(Ard(ARU3_n67fF#8<_VHKPbQHj + )g(RMDX@*;Y>5UUBi2fHB+_tkB8AspeI.G3q2i'Sh:9/C+C)nSq?X%ucBd)@QeL!TTVE9Jk + mB_1X&e@M&/kaE$Vle\Vkai?q_@d,q*Q0!b][lGp8l8:I4I/lqMJt"=/X]j#KM<8S*m%iaE + .?:^@3n%agI;W<.k1`U/S=!q8qO'rj]F2ld!2op9Cc5&?C:c6ND!_\D'"65hHW&ql@qm5If + )#ccp#GMfS%e:bZFEH=2/S;/6aV\e)>l?:R@l:Q7o'fQqJSBa1;Z$CWLW$](gC'L4FJsq-Uak?\>YIp + @$-N31;GI?kr#1;msI^"_*RT8LHUH4#k^m]o-@j]a4"7b^p@\DJ3_)s0m8Kl + sXl6 + gi^h^)48t7kCS0iQAJFPJtoFjF`S\GIQ]1TVtgDL&92&e4O(;N5#G_2W^T`D_G-ZDHYN#rE + hqMeF)MA)A8_gk"qI_Z'r$d8X;Hm">@$O@FCWUcXW\;!>+f0[Bq6lEgP"2$.#C4,C1"q,3J;H]Oi[#XHKgn227K!.dC:6l:KBk[tQ*#fKC>" + 5uWQ=Iqj(e3Z-f^sjSfnA@Yf'VH^?NO1O#4=7;>!fN"4L_Il736aRY1d\i-%\ut=bZ0S.#a + tl&ZlBFlG_j=Q4h)J#P>cnK.#jlEkJWIb`C&h-n;`^eX9C^c76AX]9+_G'?&UT<#eUQS1ej + "322Q'+#1t4kl/RD$E&'\-$To.e4?X86L8ujnJ;N`+C!=IK(i^0FjZ.#LOibso4" + _AVT&nY6A3JHBQM\--N%S15S-K8_L;THMKK8;p+_Y/W0\7`^cGpcZaqg]0o'$6TPTfXAgL1 + IKfN8&RCh=lhVgk!>-dK.(V0W0g*-dCsl`5*:rJ\@p&SSOd6W2-X_7I"a`e9>X5Rb5fo4A; + X#>\OahS]blsSgbK;bMS&)i.I`0`8a]+tKhKhZ`5%/Ona?`oR",0q7TdPh39a#mO2&9""6u + kEcl1-@D2X(C6"HetWNh.Z'$UaOU&o*WGa1n:d2l/I95qMf@%0e$)&T'8K!=El1\lkIe-dO + &bV63A['e)-M8_$^%+BXJi/gCMhp*(V7I/&\<8\$=RLD%1#b9rZP\?+?jp!f+7RO7NA7Y0,\gb^bS0OBg0-.a\PT!%HsN#X_HNg'?!8]/ + (4a`2(F=N!te@d?kNnWUGj\-W/+r#mB%AoMWsZI14XHQsA5NXWiUtfFhH*+!<=:BOK89\d5 + tjM@tM<25MJ'#:[8Lo8:E.YlR"cDX'LnpO^KTcUjMU8'Z9MC+8*%re + c0Gd]+Jl&.,*6FO,NR)EA*q_4CEnNDSbD;E:67@Oad"tR!Th,fKbY79E7#qUOfgS/_;eViQ + 1nDGQYsAAEO(+M"%=GkSWK.he<oD\Xd#(`:O$^d7`_F)e=G5,A[n_'=LgqsLMkLDfZ&/u_Nl,)X8a<40%8$= + XLAgrX-*#!FPM^BR4S6jRNQ[6^R7V8QM@E$^'I6`tlYp&Zm + MXNn:dgkd2Ri#`8=Lp]G0OeIH-W@*$1<(J>bA8W]5eTk`1S[i#&WUrZ.VEL.D1q*h + FWb7667K/7.`J=d@NEAg"4E!8l2aZDgtN`U2$7)CoAD3Rgu\\Lb\(4SJ_f*2L$O?O\6d>6o>s:melX9G*`*+ + X;c#k4ANL + gT2&gp"6,gLaA^+aG8NH7gL]7?EfPSI@suhKis]]#`^N>`LVM_SqsgaM2isLFqY%YmK$(2@ + iNE\^.nr&LtT:%#c[Q2NGTa9$>/-JMX;s7o + FS>_k>`Dj7,3-P#7T>T&j7?W&0CQ200Ja)$@gHbAn6*2 + '`r9>te>Gd75AoNQ\GM'ogjfI`WI7.NeM;g3l@k=).=Gc4.QFB6.Jtc0cQnrMAZtiFECL4G + bDRXD1\8.,8CS&+QY.JJ`\B9Br!fk!,SqRG=[Gj^W@"'ra@)HB#oJiE"?Mu"*2E'_L%VH`/ + #fZ-9lc7le@;%"&Md$W6VS$aEcts9?D'%,B0%4Y=a.IlPm9Y9U@#%ENS*HRd#u2=u4+JdR` + *J%M8?=Z/J0p(1g;50]NqEkm%K!mWO:&:fJRRbSE!n?B/AlA\M&)NfIXpHAa](q + "7#l&miM^@?Rj$4CBZlhi+Em#:lF\=NblGLMXI;HCMZZ*L8o4LN9D<6B<8-RmBE;7o!`tSLY!JipWnn + joh7k8ZEJ+UKLnqS(7?8ot?@<U8pec.Y;1OW203`=8._Tu$Bb:sc2X63++7) + 2sLgOQ3cCXXJ;Y31M>R&IA-S+Q?0j^R=od;D9;>5$q_/nLFMgT&da);Vj5f%qiG9:jL06;> + %FE^N'G@,N;Dg-DTG^"#dT6@pMNk]bp.pkM>D_E0F>WV7u3ma56RSQ?oai + MdNOtSjVHKHf6,!iBVnkOI8YC@cdnWpb1a_#'G`?9nb`jq/tHl(Ja_EE+Mi7IjSD,=&F=2# + ^G[qHihiG&U!Ztk$jpC@^uu_9F;%-rWNCU6"&&a6m`WVL-oCr0Eaik&r4>&;0\U"HQ.a4,L + Mn^L.*8DVP,T07#k7tOiH"WQV>D%1R^a@ET?,?EAjCaB@H\[n_litSg`),74+9mMSH.:g4S + C\p8U8jeL/9&[8;>$/(OLk5/eWr=_nk#6H[h8[S!Yp-qoY`EedpE[qXs`D0giVA-gB^rqUP + r;C<(`Ml+l.-KAVH*/2]HMonb_=a:oi23lI"F4KlBL=cOT%eRl671J2aYlj?YD#Snh2TRjt + UtGpd#pGNk@Je^^hc13*aS2p0XGrpsT;hY5c(#jd);;tfZ7]?K4k\q<-f#f'E*M@a%m8\j8 + #Oo'KoCH2^d#c8o2pEJ?[,3SopO)%5Ko9WV7,TOKV>+*HJ4Xmm`HAV_9beFMnogj'\^?AJg + 1Z=.T@Bt]<9W_&@.9nMPJ*e4#j,[b2TY+7E;F4XWM<=;&Z-&CL/S^c&=Lg5qT]lO?aEklO" + g(!Z*+*;H/nE8CC2'T"2g$5q0GsnhVdE12M-*1?Oeq91uT2aFU@HYTl!#@3!oa9uc8PT>q5 + [b8j9ZqF';9CeM)`Ui7hbKK!]?0nZD#:?JF8UIB"cc + WiN.%&u!)m)<)m5EC_suM-MN*(5Zs3c/?EQ]YoW[-#9C2<.9^_h-J + 3WDib9rcIAWkk7p2M$GrDYLU:pd3;ANTqR72O[>V5M[?e7BTCntV52KtVjcX=P=_1i(KJV) + 1*4*#U:p&[Ms,i&b.g4EqU^6+`]"j^D)+/NC%U?#cage8\_7?'>I#U2eS&SPlS[Jm(ZglP( + KH#taW)T*t46/8O5,YljC15%?WLgs81Na.5ipjEV(,KV2a/e^YdR.]=ZBRYke;n@R4G"F/% + -g5^FY*/j@91%DXmf>h0eKl(G/2JHroDh:2)JYi-3[;gZqih90l!k9`?"FWq0:2Z+i!`MFb + eaTQp`UgAA;r`JJKRMD3!SZ?Ss6?.P002!6_=BqKqpb85,[biLh$6>&!d,]QPC0j"Ak%>E1Xa'8TTX9"iE>XMZd:GBU + /!$*OAnOm7)*Y$b25\mYT?WND2X/1DDC=iWVCI!jhI158FV6^U"mUrE5mrl/&:6_m4$D[&q + 1T4u;:O=-eDI,:L:1.t\k=4nEZil9!)Dh*;ocg"E5 + cEb:9)EAXMFjNaBbL=Q*S+WiTe2`]83JnG2$7 + pV0(XdYp)*Ol671BG&HEZ[r;]BaD69JmLA-fenX4uHKAidh"G,u=P#m-Vg7a-oj8M;!*tNL + BC=UQ^Xa1hhtSLBn'0t0=<=X%RdGGONISLiVYJ]"kCPCb'fJ#1rF'0QC7K.B_cVA^?lVGfn + 0T$kGb/n_X4C5)*IYW/:A+Oa-cj&@P!&HE@s>oGodH)WoH3SSF + dlS\pS!=,AQ_>8BTS;*E4SnO)^[ibB\OEj=J*M1+lbSH(F).X-&;_rD9)q_^NdRI@;sgeB9 + l%L?C\hT%HeIc\U1.kPYP-F&dS3P%t9UC`bY.eq;B$59'GS + /Wa&AY05M;03m'[G)PpFcd^WD%cpug[cXa2dT[Z.DA!Vg[hV,1<\&4YOrq&GmL7Tkq^H=je + \'sThU24QH>Y=V^.[!hY>@>-0cIUU3X3PgDJCmG!?+iq*'FWnLqh*T,$A`B8uH<5KJ*l-04uu)!kQ: + ZM@ibk5=D5oA4uDH65T:XVSM:K6D`r$,pKmmXH + ln(3r[52I]1]hBY>`)^?`j.FgXkWX^\#CHeb\01m!YM6pAX72qqlnmINQQ(s!Qq+hk0OiT@ + Nf5<$C&AnoQ`mDY)`NN,H:AkFeaTF63%?THW&E=6l5moA1j=.1l0]qB!h%*?Z&((=f#(G9:> + h?2e#LL!m0*`#M'+p?G&^_X_0^@L,%gFa2jq/CBd5)G52\Uc^&lB)EYgt6H`tXQs'[]\k&Q + 9EA + &p&JGIBkm:D-.6,Y;$LCs*>`Z;b(@AR+sS@B#,MAf2X47c; + /A<=DLH5TR^,^3&^)L6QRS)dgQH+OdVB%"DCa.U!"sI@LmD"bp_/eT6V.N14EH;> + dq'2jT6J=A0JT.`Nt09ZDm'/MF;bo1TT&onX+nU3+.74oo60d`,nZSmDe73D*>+>["U'4Wp + n__\$d)RA$7n_l<66SteULeB^+1M2Nn=X%n\,tie8PD)"qQT9s?0N!*P1)DlY5rYe^8^jc= + _V[+fM*"9"18:$ho:%j@a#o3j3V%"@13#?a1HMIXL<:DfMC]2@nfm(;s5LDClX+t-`GT^_N@%D-6jaQ,dXp&1aY1,)a`cZL53X*V)Dl6)A + Yq'$)1%dP!Cc9r1`E';H*i\@re?n&gS,p37>h0Zcbja=2'NE-U_?`"%OH6X6F,rk-X;J7c@2!A,#n.r'_]>Lq + bT.s=4Mb;Zd1+Bdjh]U+gVbUob`'BdV29S;.%f04k7 + n)APZT@">s3:7RH'<_0]Df:L$o@3PnrEL-[e^;+C.a=;F,3(.)@CKi$`p'jRD + KHq;d+dGJj+q&%L1*X/U+t7s`PJ/J%_dlfkCt?l`(.g=t%l@c& + (NAYa5eTd-q_!D:>J%#^oIA_eMLcBXG]4pDbO%rW!_ME$U3X(?QkY?;`TLEgLcdLu:2c$ms + SZ0t2rf2^"ePqe>_pUBJ&Hei,$5a`FqlHIo;K2Us%W6n&h,FXUB]U,")14"/]23sIWhGBJ* + Qs&umn+ZArm(:.g9dsc3p+Yt99jJlH$A0JGP@WrW:(XHhSS>DqpIC?\)28=N2"+FiSfOBpP0SWKD6C2[f:R7Af;F4@\R@dJi/)r?\.r+Jh2n5\>+p^d=V"C2`BDf2jo2k_h + :"WL)5Ds+qKH>0n*2A.9O/4p)5/r]k/I:NBqoNP45.^"b).gN+=)\="Ym[1Q$GSO40RpEbQ + [5[inhb=OKWjfS22Lcl_NJ?:&u^R*&Z9'PV=IF4\`=FYk:CE(=N6DZY?NajYc"7uY<8@X+% + f\Li*ZRu_fd=.'#R).Q1(WgXWTU"Kr(=VH`=4cu!uKu+RBq*^UF+\QkEI#85pLVI<_ckPT0 + B`c&;oL"E/7@JEJQY5iUQ"a7j:*TE;M3Ein<,ieDAXo13:YBELq.q2*]hqdnRe[bKJd6POM + (ujdG(M#X62uVTE&Y9-R2N"Jg$U%E]Kc30Mq2I1q+I@U'Hl*&,MDsDRMT$#_,iY9-$db1)D + dHd3q&D*=EdD?\2d[egS!3^R3HuGe$`,Zm?0dAL#Z[=U&RdD!F]"./]W/\K2bf:>bZjN:3^ + @mqK,XsH%291,8Ib_(q--,:R^"%+^/2j(Ss";Q(qN`Wm`[\Y!3r5Tl$!iUfe;*RH'*,&gu. + (Ap)N0IT!n;mrbTe6-!rmpNY)-7 + 5Fk>/b0t6V4j9-\Q`j;5u)k2)nMaL0fuXURs6=8ICM + B9^X3"jBeQuj$(["bP+$q,4:aD3^LN\LA)%%#*$Z60!kGR%OHZH$g:rt7g;*SDq;UeV:hc3 + M-,c5j&K9[Jl5Zpjh1hA`jsI/Xhg@%7m-Ck*?tj&pV + f6JX1U78$X6#i#+u;LIs5#urAW+bi3V6*[+scZ\gtVq-.SPj"T6?']Za=PO'*K./0%!]*:$ + [SD:b>*"$L%hI/VM6>M%Q%W`D3]SVu0,QK>bVX*7,Aie,JrRC9m3a.%Frh5T.7[c'=t1]8o + EGd5nl\Y;D8gACX!4iuMcf%L"POSrbEIG(hFcbs+3JmIKq*V.VVglU@Nesp%'=]`mo>Me#+ + i'%\1%):\UV;L&b,%*k!*[BZN-fU^Jinc?K*])h_2rgJkj5*#]*^f!p8*$77jPE\o*`M0,= + 66#Xin\Q/h:(=HBBGd#F6oA7SL]=/\_:8K)ub?N*eWZ_LZSXg^Rf6**g4-!(5b9pkanF3*i + &!tMr("GeUEeL*jWU'R"X:+0d)>>*lI>Na6]D@m,$(U*n0L_fBo0amG?ag*olZpkO+r-mb[ + F$*mOj/p&TX>mlpd@*s;"=fFgCVdFlS+?PDs'"m^t)ek:$$+!^.2l10cs*a^N#?SWfkS+DS + 7kl2Ik+%#EMbfujN\Q&rtIWpmT-l/FZAUPE3!AX:ICZ'"@oD_8R+*+?q)M7u1[i\chT3b>F + /-Fde,QJ5J"D#FMDtdV.q9!:CLaVr?DtkE-_P+gC"%WD97M^Kcq0loNs24bA7UM2Lh>Akt> + VYoD>qs*K^u5V!!a'akXo&)*Q2eo)+7cV'2$&(_)OP"Y=+VBPtQB + =uH?83:A7cJF?oR9(LO\"D>Bf'F!(^*Ieo%>;&@540Di6<^XVD+=,9dc.Xo_sD-Thss;=u@ + @`8Yo>LPhL7DTi%dglBPP\?EmY8;_E0qmBO5[G#"Pi@-?`mFPN`[.&`3HqWl0 + em8XaA@a,n$3e"KHB4E:q*u.9d?I:QYSh6cr'oS3N,m1N^`DVr(/5%bJ[k:=ZoY3"K%7@ZI/M@1[+?"6 + S0eapE1/T;kW);/-!7SBA`9j/Alb:t@mh@71_Xp_N + 2kr0g%S>-U`:,Q^1qEuX,;]Qo<)keU=&r>/F^E>5%rq0H/Fi)Pp/6^c/Qa.&au#,ViN7l2a + e4?K#TiXZ8t.187qC2;eL:!6u='\f9\sMjQ\VI+4DuZ> + H+l/5_ + 3j%[:/-XpG'jFf!k2eo%/mF?ghu;L'>0AFhY;brSe49J#lZapM"+T>-0BKeGG")F0,?W)C7 + Mrbo$h1T[t\0WT>)sQLKYeVpYk*RZ^o?X%ASFl:Smi85F:R0I]CGf7pjfeYr1$VOPN*N"n& + !*/HK3^LjZ"l^-6\8qd4^DJe1BX5r^:s87VElm"'&[2R(;,dY\:6L&me5i<`L(#pV,UBu&m + J"eg#kL(M?B2"e)T(=Lu9:iX^qk;K&fe3AUu&X3^f:>VXB^k&X7.`0hN'4Q&ZM@i9W6&5*_ + TAp#R7IZRmLk8(sA7&>5TSu49P4E'dbDK/o2+G+/)c<$t0.4^LU(g(R4SW["LU?&umV->?auGsrocKju8mBP/ + T/ER<-`%NSPqeWpXf'so3jLe;.e1hZA>fSa?uhf6`E,AS<@+4e2MY2AM,A"F7o^5elc1s\[ + "5&L0QSp.XU9JJ(%!?I'kXRJ]"",>ni9ROAs^T]@koL%]apC(_2QOi<@JXhWli2[s#$.DRJ*.(M<&?1M(atp#!CuL@JS3a`lFk.>rD9oj58`HZ$oQ^')Hd + gcObKDmf0(h8Pfb6RLB0o($%[%R#Jh6)"^nt\K5buE_AGcFL7B]?XW-]8\)Rp+] + K(_Md^?C/ZDNf_"?:@d-cHq#'k4gYMfEnn`XAgS#+R8`0ZCcD\E=lB]1m9Zjo2@6!0?,BC'K.1kq@ + G)J2?M@I#DG2BoIEP=Capn0.GP7+,53M/%HAX*&M]c564Cj;f%uobf4.]"JtrSLL"Mf"]iV + "o + \p1+>!q@:h8_Tp&M<-dGH&^=`05.X:&2PJo(Bom\u"["Of5NCNmu*.G@4.D/;X#DhBkmBOT + $SI\?=F:=eB$c^&Q,tpE*Q8RcEgf@Ch:b\N*"NPo)\a03$dS0I%Z`1dTPX[YRX(-;TP]c?= + 1&l(d,]O+$R/M:$W)J`L&LP&On9apq2T,ojjtF7Qll#Y.qZ"m^GRSGTeerYaquLTu"ZB@:S + h`[#r!N:c.med7CT.ilEWG9]?.%,X>r>n=5b^A6Y_7\%r]+R*RAe#iF0m-!2o&g$`']XO7!#@"Nd;&J\U$oE8c;i+*>#9mA-+,R.<8pqOiomKAkq!SnibNB?"" + QO-A05O+s5JQmj]@$NG:1$,?Qh"[>b5%Zto6t\fo6JO)OrlkVr<^+2KVsWicVQt%B'[+QPF + gq)s(j^f1Sr'GuYcj(;@-lN`-S-^qr+E+GfpTLbmSkH?4p1m>+FZ\ + ]BTB0T!+F?K^kB[Ri]YD*\`?4LFDD.U#/s-#2nWu5bUUP9+ulq][8H$T"EVUOFGNl2/)sF + A;hDhr:,cER&.Bci`,J$WC^BB/`$.<5XDnMu\M7cM6pL_Y,\OWOE]Diq7oY5aFC6rd'YNJ5 + 4S3,Q5laEZN&Gb`6gPc0`!o5\J4SaHk_Mc;fF/Sq1b1+3<'ZgX)4%\A + D7=;R<*5bKuZV=sY^G)0PBSSU@_8j?_7A,mignb:p%>dI_\eG\!m,QAYJ',"Y9#SHg.-Ea? + LmXF&,3#\$X@IKJ-(p"OL(Sc<05SCl6F.!R3=Q8BO%gTSLeV@`o%/7= + ,;9!.n%G_?a]a]#mQEr<^gWOEdGt-M*@/]<@q\$]k<1eAJ + =Gb@k7tFgp+Z\ + <\_N8qjNS/\BcRVUg_G3`R.+Gh/Mc^t][@ga0hm28e3<`8"A3gh"L\FiW9kaP<'&gni0K[E + I@EbhUanguZh`["Y8<]\O=MRYo4OCOn'SC"T!)%/$,rA_5ahr$ + @@auIFaM+csdN4n"Q-0*iJ/_Gd,^[p^H:#"F1kMDKghGrF$SS;DIC0mRJhDO]Wp$\s+hO+! + &7*GVf!6AL6oAEhkg10A\H::d4L(L$FT]ejo=6=cel]th,WFl#cZ_T + "5m2`N0X,H%JX==U0p_%i2-j=ecuWg#[jm/i1:D9p(*$t)W/dYhqenO/e6hu']Dl]?_%,N^CQ:L"j8E?(.jJAY/[RF`H+66hSA9LT+p.sc + S:urHij@2i)2BZFD_+#>RAL:I>G$!d[=P>Z+jZZl,8K8L;h&XmRQ'pS9i6p`l@-/55jsFR" + 2Ikl=AEHp(T1F.fG%]rlB]bUpk,)nU[VP$FD!';ck2pRDp2B*uE9A!Vk9b642KS%NFQZ\Ik + @So#G&EU@A`oA)kGERg[X72WI-9(/kN76Vp4)91JERc"kU(oF2M:3_K]lHjk[oS5G),:9M! + 1.]kba7$[Ys@hN9JiPkiRogkdG'mA;?b=LR++(&[;Sl?YNBr$YG]_%[H:5Q"bE-l&M4op6k + 0RRq\IUC!N,\fRE)QR-DV`l!C"I#,2@bUM<8jBr7`kAtS?pV.t1Ll#s&kVOd"4W+qotl?9. + A-Eh10VX!TOCAtMS%\@GWXD15/CL4%+hQpqa[VIM#CHf4CSuuk3U[([fCQ>o?^6e/7[;5cQ + CMq"**jfYl\SP$QCX0k6m_N\aX)(h*m%0a5k/6Nib\PeNljh5'f"Z$-_efn0Co5QqI`H9U` + pD!rCYm'J51aTla_`r0D4])@(>%rfg2)M\m7,LjL>-PlbAI76D=5j>hUq2_iU,4SmKV5/k2 + g<3b3j/lmXEsZNnWnZipITBm[if`T%S#Dm-]VuDPkqOY4$9Un8;j4m`+AVG4TX,ennIYl%% + ?@#Q~>Q +Q +showpage +%%Trailer +count op_count sub {pop} repeat +countdictstack dict_count sub {end} repeat +cairo_eps_state restore +%%EOF diff -r 9b9a2497757d -r eb146c5c05a8 0__Papers/PRT/PRT__formal_def/figures/Scheduling_states_2.svg --- /dev/null Thu Jan 01 00:00:00 1970 +0000 +++ b/0__Papers/PRT/PRT__formal_def/figures/Scheduling_states_2.svg Sat Aug 03 19:24:22 2013 -0700 @@ -0,0 +1,210 @@ + + + + + + + + + + + + + + + image/svg+xml + + + + + + + + + + Blocked + + + + Ready + + + + + + Progressing + + Stalled + + + + Animated + + + + diff -r 9b9a2497757d -r eb146c5c05a8 0__Papers/PRT/PRT__formal_def/figures/Time_in_VMS_1.eps --- /dev/null Thu Jan 01 00:00:00 1970 +0000 +++ b/0__Papers/PRT/PRT__formal_def/figures/Time_in_VMS_1.eps Sat Aug 03 19:24:22 2013 -0700 @@ -0,0 +1,943 @@ +%!PS-Adobe-3.0 EPSF-3.0 +%%Creator: cairo 1.8.6 (http://cairographics.org) +%%CreationDate: Sun Nov 21 13:32:58 2010 +%%Pages: 1 +%%BoundingBox: 0 0 330 127 +%%DocumentData: Clean7Bit +%%LanguageLevel: 2 +%%EndComments +%%BeginProlog +/cairo_eps_state save def +/dict_count countdictstack def +/op_count count 1 sub def +userdict begin +/q { gsave } bind def +/Q { grestore } bind def +/cm { 6 array astore concat } bind def +/w { setlinewidth } bind def +/J { setlinecap } bind def +/j { setlinejoin } bind def +/M { setmiterlimit } bind def +/d { setdash } bind def +/m { moveto } bind def +/l { lineto } bind def +/c { curveto } bind def +/h { closepath } bind def +/re { exch dup neg 3 1 roll 5 3 roll moveto 0 rlineto + 0 exch rlineto 0 rlineto closepath } bind def +/S { stroke } bind def +/f { fill } bind def +/f* { eofill } bind def +/B { fill stroke } bind def +/B* { eofill stroke } bind def +/n { newpath } bind def +/W { clip } bind def +/W* { eoclip } bind def +/BT { } bind def +/ET { } bind def +/pdfmark where { pop globaldict /?pdfmark /exec load put } + { globaldict begin /?pdfmark /pop load def /pdfmark + /cleartomark load def end } ifelse +/BDC { mark 3 1 roll /BDC pdfmark } bind def +/EMC { mark /EMC pdfmark } bind def +/cairo_store_point { /cairo_point_y exch def /cairo_point_x exch def } def +/Tj { show currentpoint cairo_store_point } bind def +/TJ { + { + dup + type /stringtype eq + { show } { -0.001 mul 0 cairo_font_matrix dtransform rmoveto } ifelse + } forall + currentpoint cairo_store_point +} bind def +/cairo_selectfont { cairo_font_matrix aload pop pop pop 0 0 6 array astore + cairo_font exch selectfont cairo_point_x cairo_point_y moveto } bind def +/Tf { pop /cairo_font exch def /cairo_font_matrix where + { pop cairo_selectfont } if } bind def +/Td { matrix translate cairo_font_matrix matrix concatmatrix dup + /cairo_font_matrix exch def dup 4 get exch 5 get cairo_store_point + /cairo_font where { pop cairo_selectfont } if } bind def +/Tm { 2 copy 8 2 roll 6 array astore /cairo_font_matrix exch def + cairo_store_point /cairo_font where { pop cairo_selectfont } if } bind def +/g { setgray } bind def +/rg { setrgbcolor } bind def +/d1 { setcachedevice } bind def +%%EndProlog +%%Page: 1 1 +%%BeginPageSetup +%%PageBoundingBox: 0 0 330 127 +%%EndPageSetup +q +Q q +q 0 0 331 127 rectclip +% Fallback Image: x=0, y=0, w=329, h=125 res=300dpi size=2165625 +[ 0.24 0 0 0.24 0 0.991089 ] concat +/DeviceRGB setcolorspace +8 dict dup begin + /ImageType 1 def + /Width 1375 def + /Height 525 def + /BitsPerComponent 8 def + /Decode [ 0 1 0 1 0 1 ] def + /DataSource currentfile /ASCII85Decode filter /LZWDecode filter def + /ImageMatrix [ 1 0 0 -1 0 525 ] def +end +image +J3I@:BHu(:pOk^R:T.dk*=mro@So+\<\5,H7Uo<*jE<[.O@Wn[3@'nb-^757;Rp>H>q_R=Al + C^cenm@9:1mM9jS"!dTMT<$3[GQ$8#0$s<4ZX!SPQ1`C/mioWjnAY&^gM+`4=1jRLW!YA=M/6)*KS9PE`kN%="Tc + _Aoh+fk'&t\ctIN)4XQLiVpoI(>.nOW?*DmsG$@,,f58"PDKfeAJlo*B]ZT!'31_l[h@F?.u;GBO/Fms$q.0(\8JhnaScr]a26g[)`OH[c!ea5-IbHN.>J^ + &uma4O=2qs$*R]rqo%N,N/ekE&6SU_%/pY#XOP%r<0s`>VcdTn?Vp$6h#Hs$,(:o3t4UJ1d + _,U&KE;87<)6$&4UXR>8tG!P4okbE:do]7$5Dp*BCCsHPf9CjGP9SnfmZ1_NaKPr2cC;DiIe + =]UeUj&Ji3AS5+DoHeiff@<$:=41&B!EIOt*KsUYFo?So=&oL$B%e#sM.tF26Ti%akKdi"uq-J`)nJ%>3UV:)/KAQu + 3q"iY[\%M;jo*/W8X+c8CUAR-m+uj;AFrOfAd`n:WD!U$%]D85^LXAf6I&RHBp?D4'K(L2E + LD\^#SOB:9<[SS1%?LS/=k^5o"&3Mqk7kIM_.VeLHHVl/fmm]ihX]$@^_CHC=GWp8=[_6.G + Ip;s^Yq_lp-laqo/ZtJ-*Qb..IQLh\)\o,L%Dn8]q]k9FI$c6e.G5&spqr\X.EVpUTU@"*&ft'F*r`Zd<%L:n'Gma-U5juI-3<;Bq:#`eTLhgA(u0T2b2\G]Va`?F5=$Fa + S4O8:_*l/+/6J1*a["QO0C67#A/A.DtpsrS[;CL9X2j^,VAoU1@>\O]jA*LoV*Hll_7l3\Wu. + gD$Cs0o&V8,=2&86dB[m3_Z@5(7&DoU]c71;@Z#a=UcP87#@%(/k/Cb*@'WuOciU;8kE/;- + 03"4P>Z9n8_H6SjTM9A;N=XI=\U@,7&cGLY#\0J>q>#iZ'J;5>"`"8/`jp]QW!6X9A+_Hjo + iMf;\!81=cG/u7*1iq/nRf1SMTD]d@+!/C/%j52>"qTQ74G'4Y*Mu>>ta@_(SC?:RT!C,:$KVWVc<)U + ;qcXq.?sn2oa[]q>)b^V#nJY"XQ^N]^s)#qefFn8WWn?_:hT!NX&Vu!<@X&2lNHIQ!!9CU> + 0U497.@3VEiTD%a&[k)>cZDP\l7n7?#.E)Y>t#)=5*U[lihs1AJXkWg1lP=kXU#XS&9oSCt.A%#>0[b2c/k!c>9P%:Sc29EC10'6EnSTF&'^:4sdZ.r!GF03^=]2rn.IY7?\Q>6u?ebNCn"ApZf*_E_HiJ";jp/_) + 0*Yh>*J:"UUdF'/u,,^LU,UTdM1:S+rF + &a`=N!.M\a&neM@SD'.mTqlm]"8]`]>&!!l3j_R?R2r;9E$:ULYi-N9tdG3nW=,A? + ;b9Ectg6=cW_tC&aJ'L0>W9Eua5Qa]Yq[DpD>F'G.:4C2\Y"[?O"_NZA"fm$;Y<)@j+:h#F + '&mE!Zn01KX2*MW0[iR.>i6"rJ6Vjnj+ep"BqTFWRC*F?akt$TUM_D_N:.#Gp6La#Y^mD8+P@HL2\:7IeDpUA,N+pNcX + lB:e_`f#t7A>!L\e4h0lag6p5mfm#1mDk-dHaC5)44Zg-*!$13Edk:HF4@6Ca-,nun5[n?E?T[0mODj:G@bOBW(]?H+Y8^rab(OC\L=M#_Fp + S<.jo&?GjC'aMPLT?r0+Y_L1pTWSjUWt:L90UN^HS=MA.":X)nN-,8b[h3TsSM7Y>OM7B,_ + XXVO"onZ'OO4K_K*LhtbqC(;d,=dMr=3d.%^:Jl&0CMl&0!>2&Wljf0`M\=#+Z?1$>INfYs + f'u)YHk@[1,[Q0#jU-V!YDT&l57j:[fImSA6jr#n`>kN$R!%<1M8i\.CFjd#+IB#cqtNSM1 + cQ;)Js35n'aM)DRj#ER:5#f,kTI*ASWYnfZ4tf,#P1*NAWNl2)4ci?%OP&Fq\'.H;S.rrNMI++Th&d-.?) + !iRjYSFR#Zn7j'9&LJsO,Z6QF12un!-JDE+V + K*kDRUQ_W1FE_"7]Y$dbQ.,"QKik.uZUB;[V\#Ik1#p/II*>'%\aS)(+r&,RMQIo-H+i!hE + 6V#H>m".JkEjfe9I;#kK](EBc-u&.K9^2+d`Bdb?Af))cPM2QRoRc)!0KSt7\l/'nA?1Nt4 + q2]P+YVGciP;a:A4 + ''gNOs#B!;3AZtl;jumUT.Vp1S[(ZS;suFsYr*3'dF,nFo#T>/bbL=4XE3&Hnf$^JlOqJ)T + 5GH*0_h0D&OF^m2lY6+P+`Q?))e1@.)0V + \0r4B+C3oPmAORmZIn6o"!pPXuLEbs]AC6Bm$WoMmonbsg*85."dhP\-Q[CFI[G7oZS;P^, + 7;4Z5-t5no"]@5Oi\)b'Bh8HH^^e<`mXH(J`>b:XU[g'.Z1_)!t<4 + ,1RQ/ePe-:j$nam!i)oYpP=H8b-W1Q&#aRI7r+-=Z$^eaidQsRi+)rS5lH@[? + 4Z%`D73=rY,R4nuYBEpK@1J<=`]UQ.9.4a&hro>a:!knVdG^M@e6p7'nKgPUVR@jI<,H0Rb5et0p0\B407YB9mm*p4$h!WD_<&:"G9@PQ*1U + pna'27h%-l,`r)SefXWg!#&c!F5qDMLCBIt:3RA)!?RR,K20+53%KJMnV"DJEO\pS1JF5<*pnNQ\N1 + CfdCDa4GGdE2Zo7`Km]&2pb@VmQ[VNd+V&skbC* + )%m>=eo:,$0S3;%IipsJk0J#UnZ(?^a'07B6FSG=/[Y\(;r,h6#I@ehT!3AH9!2jS`':>%^ + \$."hR1OE6IE1$BamX^WHTp9Q`P*Fn)Ohl/8CRJs*QMCu;\0ZOr\!NG$P\Jm>)'P8Gc'!?V + -M_"QQa;<)R(HFTO@gXq:$1X,Nj*#qH$R4=fcH^3/LKuE=P*A8)6BAh,ESnX$5pZC)3%7gV + &Pf6RX)lBCc.amLRh24SUoajeU<@#kb#EFS[mokq.@nS&q&0:9;^FIEFaG[ + 6ZI&Z'eV-UY#,/SCV_ri0-FQ8n&$.PINqfqS4*UGs?k(j)?14a_R,>$=@\)G,k_8LF:0-(5 + 4.fh80QUnsLo&"4?kWQ1m&mot)_Sf(D'H7*1uI@g:nWHo)B9r4JnO.Z&ATJ\=#Znmh*VS)` + J(_>W"fj=/h@%>kubo6Bg>*#'0ANijIg_lSOd%udYnB]C0D7LONGVaV[ + \Zp+1'\GpYCWWb4rNC0.a%`B1RlaWlb=X8CYc`+C>">h0@l6=eZ;lYi4!Md\d+>l[E-_%rf + )_peKT + 7YogW5o>Gh.3nYo/fLRtRYCM%CVc$5ohRS+*1WSGKasSGN*'P4u@A,t;%"Fh>&nPJt0R+1t + fcTDKX=:><6,e%K1N]t0oOqn5ms1od$*]!g_8.iDZPV0+ + I#Hu80WjQ%-qDjd#9>>C<`!eH@lbg[ZV3Kb9]KBCrgjlh<@sQjB^`$+AS8D.dEMtfN@N9Xa + >^adX[*"o&`XR^B11eP-WQ=`]bGqhhGP0(NRu!N>V>HABr25JhAV3+Jn9h^jmgm@\-cfBj3 + 0+i!!;9?oTCO^'QbS-rk4n@:YL4"OMcW[d2si9dPu`uNa&DQu7OFj + <9Z)-hJ2!M>8PeXjISM:^E#;iC[ipg-GeM3&Y4@[*Bg + Cu3jmUNkc6\\*K&O=Fk(=,e[G_5$TH.TQK,++:[oPJ(cLJ&Y5hi+9C9cb2.PUT5B/6^]E$/[FZ@UdJY)pl,h`Ze(?Ge + WEn?>pib5:2\%u3`Z775rBiGj8)/sQhjmX%h,WAS"_QTtgHB)=ILfBU^YBuZgjCog4E@!!- + 0(Qdh0q&b>3gFEm`GAkkPgFCSr;h3Q0EabV`p=/^7gsDTB\:RkVgH'?Dm([[&3i/l[HP5rk + Y(q/aP[CM8$UgZaVJ7^$=sZm/GE"lPk_1iU20Zm_/_ihXQQ]h=!*BO4aQPN1o]hq=&W9m!f + ?2rt4N\"n=ep/,pFUYdf5YS0L?Us_f;>!. + VosVX.IpMb#&b[;Wi?(^;heVsNFn^B2pV2.Ns+0quQ.!&4m@T+-s,m+AQ2,otq7iKrrd^(; + Pg7[)n/nA#s0;Gc[JPHaqnKiAl0J'BL8A,AbjC/E>es4JKj\\U*8eQ?hojAp_:9]ir@1;`s + 4FUg(&gC#X1bk_&,6hK#mGrIi=MAU/f>+R6fJ[pPYNYBMacY;oE5BO$IqjiDb+\'%'aTf5':Nd`Ufd[b^BgS(6rrrkCYd%u_1V#kc)CT,7gfpDJ= + fj73jp5#32=XOA1K7?O?*BZq-3'^OnB8YsmMoajfWY.p0!j_O[QtQ%Pb_&9.WS_Xh + *$,n,M8eLpq&GqXl^.\(Cb+6kc-pI"VJ$:I/luu%h=#Rc*%l-pT6eQM[[Gftj0RdLD]0Z=Q + d=on^H\u!T@O\Np;A[Z@J]1Nb_gMT/P2t&XM!i9i9WKXX8K`uKOYlhEMB9;[?/Pc%E#3Y5-$uob&83>E[6Pf8Ef\`e]01.G.' + c^Zut_c`5&Tn.h9B\$u=*9U().V-;_+5=Y;V8AU.unD@N%ef + dY'V8m9SIO(qnn"iG=bG9a_;+L]/'D,PR=;.m5$NQZTRGGJMfTQa"FA^iX2N7d!s"aOGsF! + ZGpfQ0cE]\`;7JVG941L4ZA%BEbe,$0`f'ZF`!iCC0='l&KF8]"HIeu\ME3065jaj[;BYRT;]&?RW#3jqRl^,k]kmpSsgPn^S&;&`lDuY4(ep>?u/6U1EQI* + M#gu<7PU[308>;-DTue4&N.e&DXsK**lsSCc*"7*nD-ONe"Bc\/!=r:G&i6dguga,oC04UX + %SnVe^X?m#D:u[DI4dDprG[*-$C.In'EF&WDChqSY(&PVS+U#ebGa!]9[elCO+)USAas5b+ + .XlfD<,mX57HJ\%VT!Hp\(V=A2I'a5MJ6':4o8YX9/92`hJ%JL,uHJl6qtE.eqUW:M]/M]n + .!YFUi@olBpLMt;RYS[Uid5ld$%?@]-a/#$\iLEKg_K'thC5m!GWM=_KomV32seacF?`#XV + pp)cZsGmE7Q+X(e5RmL0W$-(1<?linBnp9k\a':b8Pr:!\["8FV(906m5DE + R`'de!XYP[M6UM*`<*dgU81h*:\:_UPFV:j"FDeurEkV=b5NB$CHFpI^6<6=6;l2hJgnY)@d*tLn//Ns=.p\2PZ]K>DE^Y`kelIA23B..7t:ma6Y/BBM:*.K'8\8,:tt2tEP/E>Bh + nnD"M:"`p0T6t7+[^@M'8%R<6ScltD^U]K'1Y&=4:$? + &/AS"W52L(ihm4J6g7+Oj-\93NB;A&6]j + FOlp[H>mgOm2r,L-4/%^,tZ*>.>ZJ.$[qIo4'?eUU6>ON*,(ZA-bnmYGV[a\H").'>K>I&o?f@q4'B'r5*Za?s7g@B)rD=++#kO,l^8cW/ + ar1tQ7T$uKV%.YJDi3Ua9h-E+hfkbfdO]0j"hKN*lD]QF%UnUfEbL:oYebb]bDK&4KgdTh3 + c+XtM_U?((gM[8n_3d.\.1+(BBo*G;GKU0JMfEu\8OC/crs%:Mr4s-Kp.X(HrQl2;.II5*R + .^mo^s"S\0,>A.R(_;6Z=A<%r]@*ASpKD%l&05`0t(2qg0Yh>N3B*8;%j9[K\;]Q16tk]NM + snWU2!f8AE1ZH+"lSi0pf1H7)7K.%;&9KP&d^@W]=E.jcXnTigpk+R>3S14N3I>7WulKT0/ + @;7KTKT0Q>4FMpH3&)-_L%A*fSWqP\H+ + SWc_4he8n[FBtYsL[,qM;Giqe9]l>GXDIq;M(Er&q*N_-n0[uoPYNq_gLg3UI`6o<#OpesR + T`@fn3qI"Mr9p5c*KAYI,5uA`%CA[5,`J&?j^[,mSMFNA,k@LSmHrlFGEOi=";c&_c)7sn7 + ekeceT54[IjI3g=rN[Q#5="g%OSqKMBd5B!N4tpYqqSG'qcKQU'XV5?76fZ2,k.EpZo8^+G]8p9brVfJI6u,%?`bl)2DpT3(=k+,H#,W=AYA$fcHf9qSrX2o@jBD#=gap&@q&q`%79OO(Q9r1 + ?O;T9_?uIt*5$YLEGho@FN5B"6TM#he;Ud$_YiJeA.l$*n_:UXD#PS0r9H,tT^P!1#ajrh/ + ;^^aPY.e-$$s"V5p\56J4%//#NtG,jm2"69e$+bd#_O9ka1$F(]F6Qjg^FGc2ieq<]!Odj)rA??-+K%t5 + iU\;4?g]282?Do`!GMD*$IPAb/?8'%V.^b`'-SJ:_@M8]^[:9ZqNk17aL9"]JXD;()4IB(5nU"VENu!9ZuF8LLd!K1:IAr#U%DS,BQtGYMFIRRu,Q + 2W@GmiqR-N8a)JUZ1jOnaD_&JIQQ0/AK<`L&Le*J]8=YQ.XG]W^N(D0P+.S(m98uKtO@]kC + 8KGg"U + _Ko%`N)I#9W(L1W(N#J8t;nRXK+t'LWWgi6X6]bm&s%ZYY,D09,t61/$D<$\I\>09/O(MCq + !&b\4_dk9:WR7%'<*S]$&=29AI6Sm(Z3k^e>$kbIcEN'Z3U,`(WkD9O,S2Cq`RgLWjk^9Us + 7!XNO;MbY66-a_A^cI)=+WcqOqr9cVSU/CRo?MQ*)Xs$;;E9cI1RRd/cr-u;B6p9>pE54#))q$!M(Q8BI2)T,Z9 + T#K\\+U,p6I#57Zf(Fe.\pC(*Ls`%6:5U/r.aZh]K[XL6e5VSPgdXNiPYc4C$+5+ + _N7uq*Rb6?B=`bY&m#+s`mo_F*=?W-#h/nLUFkLPJ`usIPe5KO%PZaBBfr_2INLTtPSLkdO + 7/7YQF=We[TH"%`;D@Tq$R3\F!]Gk:In/:#4i+nOA&m>CU + 0E-J83@G$nO1*Qc4kW64K5BEiCCmC2Q>_NP^RUW0rEZd!*Z5B9gu,:b0aF'=JG2lgYKBDJ; + @F(iN.9q>I]Ppc,!A!YRcGZ]0n?igP9&SF:#Xt)r8QLh8GOP`NoH^O]C8YJ@PuWaHR.`^.l + aS."g7\mTUUD??OMfjg85kOWN3UZ?p?9qn`N#p^1TK%UeX((kk84)kPI6PDU+3WO6!Mc!U+k>jY;>gIGT)gg9>8)`??*36Y_Hh-V]^Ln4/L^%FX5 + p;)1POM1J#jnde<'b;/J?e,C@D:Ssj;c$b!;_9fV7I"7n04)>X>?aTFEo]/J\r2RE7jrUQ8 + IO=PJR@(<[l,4`rZ0uMq*+[s6TMVFF7R6#R^)Wu@NkhqI=L/>q;rKhP+%AYXjrYaC?BV`mi=4UIQ91L + 8.+QmMbml5Tjuuo?j('BhjLtqV*aK$m6Oa5f8--Eb>.*F/7uX$1MIoHA7O=YF@:eYRAbj$Q + `_PYC*b>D!iAfB.<%;H82i57W`h%#.@ROdHJ_kt;?BWFj[TTV/j!SESAJ2)`-:#%0I:j[]?.n;pS9T\G_chBM$*C,'FuEuYH=`+q9a4eRk'?.BJS + 2-4`&$K,$GU6A*FSI=BFV0/*WCk1`oLY]Z@7uCL5#sj7R_,R^h'^*2MlqgMWJH.L_b+S*d2 + "9NLh29fPW$C2OWgkBaC.i=TX<=A7SsJ0.H2Ah$_],'J4&k?0KkD9YQPH]l31YgKJiTlCEa + rY"'fZdqX7l6^0Xs#+gZu@7I\rl^9u)ETC7:[94[ql96q<*i2t=Q/gF6/9VE>b&_5mMBP`j + #V5?-QG(4Y+PjJpLqtVOFu!gpYK";sCrX@-k-8bSam1O\/Oman/s#@LMp8p\7d9:eq$8=ASef + 1UG4V:8k%n:KLs#S`C#h^/Bn\`^LJ@[,VX?lrLI?%M5pl@l*s7bAo5OWGDbA#>-O3+>nLAG + _-[uHlY%M[oMK)mTEJFL4hZ9;Z!q?ljn4i9'k1=QYgW*M_k%Pe!f+dYMPD9WpMEQ#;No7u# + +E>dhnII'B%h_&J+)*)&DQaPb%jDS",B='Jl2F&--RQMbd-SM"].Q(j[8cQWK6"-4fi;YCT + -!Mm22Ks#kPlgENef,BEt9<2`BK!]Eo;#anaPEgF-0DlVaa>J/$!S%6g$VsGL'jkY@'rL52QS%a*;"a + Q[o%-m,f11!8]_%&uMt$]WO'(t/J+]D"]2r3UO%]/mcunLFoM3g)'?bEGE-3[B0c\`e`oCR + +jD[%g)IHOEYq?'tGRG('pR(GnIl)sC;Wp`K.k%UY2OqXGD![c(4-cYG-K00^VKZ/1p-47( + QXpdH13eU2GaMn6W;Do?/B(BZUIl-,T$<')mYSE&E6Jh)2h?'PNH"Ulp(qWBDF + [pNG=,*/VG,`8Dq:M/:+.iU1TEQ^:G&!%^cMr^k'VdpH$RB3fH\3pE'Hp#2jA0>')GFWqIFG2;K/iGPV95>$(n4)B<, + *gh7_tsFVPG_KXC/!@rm?fqY-Lr7lp!7W/#lE!+3kWGR+/V0RV3(L(B3%:O@?Cg1A.5i9ND + >+fgMYe0tM@B&l-=9&KS[.!S7kHsmM8S$7p7&Es7Q:kf;q1Qb!1R_$Mds8lZdlWGMkL5k'#),F=;/"I*74+9mVGh3YqLq + D8,!R][2`].@o`:`-H&oi/SrbV7;ahfUY@+JRt3KZ@(JY,7,*?k7]3t+Dq@A=#!6^ + gf3%eEX9g`e=^`L6knZTQP(gZVcb.0U2"o3XF4mJ2@J9ZJ>.!".]1Z.3E9hWbrJ&@(ZeB8> + gO7!t&%d^S\(dJZ"]<1U?cP9Na!KK`e7C$Jl%U&ne$*rAQt^.%:2'&]mes$/L*LuZT-C>n7 + R"RBf!o^#%kh_Q&bI`'L5=Zhf-TWgs)&5G!5MDN#m.oh3W>S/.I)Bc6-t!&#f9E..13r=&u + n&DlHClK1l(9>&@eb@/J='u3M@.tYPO(SV9Y:'YI`#ro@/:TKN"#tW`a/_JQ6h'HXKf)>`=P$5&4OH"1;d@tR2e5!rhp&K + r6?5iK*:O'V9-C6::WLud3`&BSiBj9B]a$sQ<*^A2dF:i)"poC".8&%<]eN408Sg0lKs]P\ + ,h,c27]ZchD,>9'<A28Woa^8.Z + %9\QP>del,87Qf_GBBpu.n;'J.>6\(r&kIK`'T]d:8J"l.12Mn3n>#(K]C"cmcVWo(kV5if + A^7Zg,_$VY2KHS:6XD6K"ag(3e(=BGT4$M3'm@/RV\F&%:iOSC2Y49)A>JBjEn!j=T_!eoX + !Q&e\0+l+l>W3P=n[r3LaRU=BXt0dN1+EieJ9N<[oA&d/-O&HE9p1$7&-=#1@DPUfb;lpYR + .^hlB[!e\gpVS(BffGa/l8A4_W_/gj()TbQL65A8JNE0>`"T+5"A0^)^OKtP`epF9M'Le(P7/_!_2edJ9`psV'Mgt@8IU<3)_(NUiA/cMD-peX:J^B$G + V/2J2%&S'u7nc.Tomk7m$J1S/V^M9P^eX;<&LAe!%bjZ7%Ml^lER!eB*/-96< + K%r/XMp[qc,%D$k+VC"rdAeojkp7RMe;BJg>#S#W + <@t&3^6R.c>th5O1T&[QS5W%&:$LGHPHoRkJa#NsC#qdD+\#7'`_$8H?r*c=[\t)O-;Z*>% + mKV0Kb2rT?V:8-Waqu69E_`*%1L0VA4UHp&_\RbJCCWc]!g2dj]lStE3@a:]@U6V?L--iY; + Qt>8(4.pidIlJ4'Y4F^hGKLU+?@bZT9MAZY!]ZaObt=rTb@m/_4D96 + V!W]5t@&\Yr*.qXd/hZ*r+-h5KSm/6JMj<55f:MU`@CRnC0[UR90)&]\hgB@=o=ii!r*N\" + IIG_b^R+rui#DWFYQb3FfG=Zu9GN)pYX/R?<$$Y\;h=FE$,W':$XoPUL@E2&_cV*o@JiQLY + pLX4\;q;4S5G164tX`U],"lRAW1W+0ZMbk)rk1CNq([`a#O)?A.3mJE[F/pfI/HWY_#;0-l + `=L(Em?0To6dL56gk@\cTZ8#=M+4%qDq"?BU"eZGC^s\VQF"'l@(8'kK4ET/74'`gK=,ER* + 7p4>UO)S3Zdn2BuEkAVNSQJd-oBqApH64T&%+ERq*Z>--r$-)C11Pr?cQLQggIV6oBUe(T6 + &.FK9:RA`9ufjN\&UcAtUJS2&OK\+JEpt$CAZn>U>W?QYSCjetecqQ1U9Dp*Rc2`CE)@ + ']lUB318IJX;#L`$+0CIbU1KB`b=Fl?r)qtg=q*rDB1m;#Y(9<>G$"TS^^O0&I?mF][-Y]#e"*+Id&(,]QVfFtRMO$"Y^SbhoV5i="9`CP$N^-,fNVaWVS#MA%\)`m + ,tFj2&'`6V]GYq'RKLg/E#'IEfn0B.`6!K6E?)hQ2q1YW03&,'/lhi/cA*#sf",]^q?#L'OD + MpR(D?0Fd)0/E"6qB&,Lq\T>"^5pciT2]V'=9.`gA79g(U]=7?((K-VQAj-AjlKVco3Q5[q + ;$pj#SD98jiGDg,R_GZ_4Gj3uX8:^Yds-rTiql:!qo>%(%sHok0-,O'4l"VD#8p)e1\f0_P/Y` + ;D=P0UDBf'RMmnP]3\!9iqV(\+ + *[nREI>AJhRt4p(j>0rl44[e*FB)j.lT%7:(hh$jo[)c&sDiggTt'*tcB!jS-^ELe((k1t$ + R*eLd?+t4,"V#$(`pjk:4j2sQh1. + u]:'%0&956[4=,;Jm:d\7>:VI\,T26sAQEj?t=[jm!k'>mNY!Y5er7S:u$q5ibh'@"9#7:2\U)K`/0/)=S/^l"&%:(OV6St!!.rs;P1.!88.kWV1WDbPqP;^X + k3\"!E+S*B-cm!ZET.r&"'la=$d31BarA;T@1,Fe7PK^>a[Bh'd'4n(C#PW]1:4tICAX$^)^YhU + JP[033c7?g_>_AbrUn0!=\8oqs1147>eJN'jk2tBU.[!+n0H;kS99TrOA1.=nm`COH0'6Kj + @U+\0O%51%@$SllZ6D$e*cVKTmr_:QE<;J1G`CtCWlnj1o<;%F*k=oK>;7$[,eC.0#!D]@\ + :?!?CJtGq`.jqY1QgE;TESCPXLE7')3&0Sn<=DWebuI`";=^D\nsrN3/IRg!9eos"ohn#>@ + o]p_G'%_*_f&UVK&h%d"#UfjPm]tpPpDW4eg'`3Q%gOu80IR\q/Jt?d?@O+rCbWh,5%d7KY + ^ZR_BMs)3L+k\2;MQtPn*El5a3 + EH'I=W=^E,7.*&GYk7$]p/+$0NN0[fG5j/au"Yu8KV0iY%n7"?QJ&2@'\%un20d@XZdo20Y + j27;($da`GeV/$%]5iSPB@eU_(5#!K![,qkDh + RY"AI),A3%gOa,52F?(CtQgAS^c%Cc,j;2doju*DMgLD"hI*'e^7Ze3Xr0>BD5-OtgkF*]e + L=+]9^1n/+45k<$Wj8WjTuZh@5"mP.`N+\E=^pJ`>W*%pjR*WdPo1@R?U<&]f%&GK7GGA1) + ZD-;(&AbXt'Eq+Io&RQ>UI`$)Ep[9Pt-S>(K&XSFupQ-PBPWF#V;?>a%nm3qMU*&K&H@c3)!q1n23A2)+&_@\&f@,E)+,#s#=qtafJh]/M%m + e,UI^hIu"&XP-_C4"m//XZtdMO6S'8RhY0,TQk(lfbAOtKk`,5@X!=NDbT55lBdM`,4*GXm + iSDhM%GX+CqAUN:::@r9.3GLD+CD:^Le>8C:p,.Q>S&[PCMnfh.X@lQFp25tZ,ng%@$Bj!_ + <32'Z'V3&/rQ+6p\pePO*2+4uG5e+Ri=`Pu/a-T,FN7`]DU5>2%Z4DO?Pe[Q#bU8],MAK8(.LA>DBG$Bj5f8o^3MW,qL@NV#4[m?)%6b+:3[7Q+=l")TaP/8<$_JVCP( + R^\-4#mh@o[0.I]9QCXQ'o74q.#]D!Hrap;L(Gb"LD + o1qG\a2)0HR`,':"S6=3?(6Pm<1>abVg)@*9&@AmA/Wd'1ZcS(;[pRca^X4YBemT!(E^G:) + E8pg6VfNaPcU%g@cf'>m+>0Wo@#Feo;I/SQn4LZ1*HgRigADmK>5dNu1;l*Z,.U75=4g + +Tbk8$p91YM-%Q;qJ?[?m0j_q\o"33`i\59<\,i\7-8_Udoq:AM?1.9/Sj[oHOXm(T6ffW& + nXKR"n*T%:b$a\.b"2Q&2j%K71@iLE!M.gWUj^BtI@7AE*E[e&SkCH+nl_[JT584(YbX7kX + r4]:+qjQef<$n0]0&qYS%;>Lg6QEO5dG]pc7b2RF1qi[*(co(rqj:AYQgJ%D*iW#On<\.ba + N"/o&a-EuriP*`gD$,rE=(VB.Te^q>./\baZ`*#+(S4fb!a-/*Ge\`pto2oU0"b1s0.ggSADZ,'X_]c,^A3SDDT>KQ_N-(Lg>4LQM?L!eRK@RK + +93%:iD+*>b/42#hPOdnWW^p(P_O]>NC*a]\A?i^)"^0+RoW,SKX01=OU`5LuB?m6)35qt8 + 8:8_#O[caIuH][A(]?n\'fY.:FsRB+ubq8fjqP#g`o[d+iYYL4UB`o-ZA@e61C.q>!6Mj+I + #=.10;&3RJM"VTq>!Z!r-0?4ZSepWnA*TH2:ERS38,sAHd,2q9c+5=/b5XA1pF:9'.bM49Z + gu9E$I*G4@_qg`=b1t\,9l&Fm,2HBLg/4QtSTZ9*$8E_/+JKrVSeo8^8'k]uE#[Mb4Y7;;h + r6h(jj!VXSJU/"=6"nr0i^/C=r'!07QA+Tgfjh7*`]V>+m&)QYo=F_SOq+r+3rWidJ\G0o' + ej6@q!rDdC96.\r&-#X?O3N+uZPG*-[dA\31nH&cPqs^=2IDNTNA9k$nd5*`)hXVBAVYlJ8 + H`KO>CD_?N+RRFTD$)4*P7nt.T,%2\EH1\6E + FnUEUF4t#naT:LD*S\II3+"d.-=7qDao7(!<"Z>oO@]TMtGTN4FQRh`9F8);Q;ZC+uhh"[3 + BD>&4e39)e>tat#kP'Imq;7c;5CrYQVF&%SqM/M/1O5n4PtW:'=J))[ho#@ZKDJrqr58^6h + p,5oD8X,.rD`Uj+5d')kEgM3m$buoTCP;*e,MierIP%LJO&.T=>V'2$&(_)OP"Y=+VBQ!i@ + QI^!\kRO\7:XloR9(LO\"Pr=Yu^I.@!NeP1ark@540Dk)sgKhDH,\:?Jn9o_sD-Thss;=u@ + @`8Yo>LPhL7DTi%dglBDrV??-#lf'9ZsomX_cYup@Y>;`#".Qgo#,277;iGlD5m[%$[qXFB + q4tht4p&=a]]ft>`>IGS;(26fZESO#J+d'lWnsNW;h%*YZLU,Ugp4#B%d:i0@>rJOD + 26pPd@BnL%p7#?q`n#CCg\1O#pA\uSIph.r>Q+^"K>PBJ(/.aa0cY0(HC\BO?a1ZrAuD2kp + OC$nf`+N%YOSj$Y*uOcZXt(Ip4/Y5+ + tGF6ajf1(t`-YACdMLE7F6ic;iO<#$g8d`e= + 8gLb@ohH_84[2WCd#CAa9W61];H5SS=&r>/Ego%`1S%kC;fqC!:R(OHdo"_8"U^48p%=):d + >SKt,bF^/"Qi^kZ?&]ALg`/U.l5-1K0o1;W(e3hoq\hD[f\7Q6dG)>FBph*f60\bMD88iXo + 5eG9(p+0D+_7u]PQFsV8[pB[K80l?oTu?@n>diP9mGtSQBI!gXAm%YrQUe^' + 7d3>P,JA?<2qXZ^qc;i7j)2DJ$)GhuKK?sj0HRV+9c&pupnK*=hL[:UW&\p-DNQs4a0n>q\ + >F`WHak!#]@%uSSB>gN8H1CBh5ap_VC0p\<,CT'_>?L)=NX*^W<;)P4fH@8#VTle"S\&ON$ + g4\&KekM2*'h3>_E4e+?`$Q?jj2A:86=74i.+YGtA]XSBA*lhb65u$^Z + QT-81lUgbW_(:T*Bu'L+hPL)]Xe]Xq7CRncPjCWfuJ['2nA(!,uQ^GKnprB5:qA$C!:O_`k + Cs]DB\skY)HQ_IsR)@^>1g<:ApLWN1rMF\;bh`EjK$&5@=NaT`:UuP41RUMuJ4@oD`?=/X8 + R'*qY9;e0WGCqnD&4ptiXEFAISp^uVlu>`uRFUe1eT3#MiibOJO"c4#eimc`RPAU$]8'>h( + DUCJ^J39BsjUt)",P)I[n:W_(Kf/0'<6jOoNnaWAP'):E&s+a&u5EPO0g'BJ3K&l#U3J%[1 + U5/enKH;22G^b8(HJXHk9s5k>\Iut6QtE?gtS2K9;Ma>>0Xd$`@-KhW*Z1us&7S>7KJ*=9)>k2@2Go6gqe=i-NHPm&;O7W^[W + HTK^,e1m0JYY.#W91nid@;PmS9A"(Jfc#@'PP&2%+r*MeeKZ5Qnq;h9#=Bo=$E-jgKgn+$6 + sP!B6L.pPGTV_?JA + &6KAJ>P6U[OYZjc$/JO`h6aV7f)$oNG")c1e%b;di*K(pK5buE+BKWj'^O^^T`+I)QjWr(q + k\m_jh/M+)ZO#GAT+frVSdWl%cU+dLTP_H_IU[V@iT/LY;PKtCctckhuMS<1MERb.ho%2.< + ii2hSn+]!"g`jOOMaEUcBe6jLhBPf.(Blpt%*/]X]#dQAo,bcZS!rM\\foZ!aUcVk$>=#ae7*UgC<7c`1l=%N9#B:0rWbcW8o;FBWE/CF2jN + l=9B4ICKI9GeoK(4B*Djh:R6)$Vpu]_!0r4=!;02Zd3qX[l,#_mfBmu*2.^7;:,B + ?S?=YBFHBL0Oq7(O\9$*I4PuUS096k^fgYEsBOFA(sm(X'c*(J97V,NF0o8(sHie-R"K->7 + Z&"n9%4R=-@\qh.!Z*jaToaO.-HB+_=SBIsW^A6Y^DY3D9Vm*"Ha0nR@'[FCiF7Od>hDm:s + mM]$7Eo#!F]=+F#ScjZ + T:i]NnkJ_0c8>%kB8g::$6saa8#q;^jMbFe%IRtob4:fHK#+r8WU)'.*L<7Nhtb3:C6m9X/ + Gc6#l+B0Sb&I#H27HK`;8p;BWQ1\igc]Q;Z'Tc^RTkG-SX(a,N""RI#0B-^E^oY]!dgF^VA + -H5N/V&)biG92n[>-SN97NOjocY]g#I*^uQ!+9:Q`\SNg'KYhT#149R,R"c*![SBM5Qqpl% + s!A;jW[Nkpfj2O]M;Gj\m'h"!#5_MM;G_j=48t'j&Rg[2(RfgL#$DP)2`,U&iN(h + 5ZAB%H?6bE"[&IHE"#K8Kb#b5.[KN8YS="*ZF6ZKk,80j29oT.'uKh29_8CWc_N/:+\P,Wum8&MJE,HjKc=-9R7La'qgm$*C+B + ?ALoalK%I/>(&&TZRs0aV:G+>a`LfKh8KK3u"G%-tLJRT#p1rb+tpT/$'nMHUFL00E?57-jbb,it[*-\'F3N+&7X.Bl)7bG`?VGjpbp:`Md*,2%b6*. + BbqPj8m*C=CXN+;kc(pTJN-pn(FU'mQ#M=GhFP;Q?^PCn/c33.P1uk)cGR!qZLVS->AE6L= + kg#9G7,%9$m)]ue+b>/EJe/`PAF>.Z8-C>RcBs=gK_(#@#>\/E:Ls%BFSF+42i#1nLM0]iO + ;;*WXF`kMd' + XA1oad-TIZ)_T;'c)EJ56;B&.F\j!L4GJ<>WDP]TP"@V9H',FU6:jmf\_>3c,%PI34?f/CG + 7M;C*O80^DRerQii&"J@s,3T,g(+!FW3d\6\;CuoW-B$IA)%idBQ`(+;iDc/Pbdr"#s^f + rC>@k8CW`tLJV^i>rYX,E!>H,e=B@ao0:[6?%P<\"a(de&1Ie5:XrHFeR_d;QtuqN:Xm/n# + CpateQ5bi>cnN4Q(TW/0Nul>,Cudp#LIkH`EcM5ACaa)L$1RL]d/;6-im.oMoB8Y[;2Uu?5 + 7]E!t\j;`:*sj@0\r3=!_n=1ujA6Wq=B;pP,#-@n.&LJW$E%@>b!%ORpNNTRn_aX+AHhj/!cSk(Qs'S'+]/f!>Q)RsE:R4@j4Kc$"9:H:4` + >n*N6_Z+L!Y,NS]4o_d+oGaQ6:7'E+.(s(L%mX#7+]@Q-rrlfT!SC'mNmcBQ$b`,QYDVfYB + M"-t(.hBh0D4k!\%.:#pOhOr$ITiVIiF5!Ik:B33QaBhua6A*? + j9V%IKk$l"?lNX88SNd:uJQ8i?]RtGY6p[DIHQRiF&Na[ + (?/@@Q#M&)=E=Z@4Tb$^?= + a!=0LQ"kkhio/!<+Um/gb'.Ol!WP#=*>8W$0YZ*!Q+BLDY&e&:+E),_`Xb"0G%JW-V_PdM] + 9JLNYlA%R9"T2$WPU"^"h-YSgoH,lo]+".1QniL\u3?t>B*Kr.K'%SMY=0pV5fK,A"D^bu8 + X?O.Kk#=*Vij?GLR<,f!+:HS1#u%SKs3@b + 4Q_E:(5HL5KSF*_\-hAKI:edNk+Ip[=rC]#FQ6JCfYD0T@!.8BGDC-b"'@/Zoo&r[*"Git1`LX:>PLhHqT6s2BMg`R;2Qs9_q-&9!SB*MW'>j(:AKS]TJa^ojcPi7De/- + 8!qg9s`\#_NB'HjARuKD9%\`9d_98d%t($fHJI&I=bR\q!rsEWO=#ND=b?\qgDuO`OAQ./U24_pk,u4[OBD``D + V2t%hl)7an9kF.0&*$NJll7/%<:b^h!NWV#Inu5?%ms)=G#`WA4TpW5U6MH/*'/LjA8nZ\/ + GSh@Kjd-m\X7JI-]%nFkQ0]hu/Lc=<*$L*/C2BL(IYr+=Mg9=kfeqL,J=QY3PJ1ps42/#2! + Yp84NcjZ.EmUBD=B:G(9X*p]^.KK$\h!:3Q)m"QEb:(DpijBQ`PC*!;ii"r6]bE-DOpHis. + (>e[,ga@=+od/L7igIQ9=Y<'_,/0#M=BYW,ICJ;``RBg\7Z"O-A?+_JW<.O8 + /)7F6%_F7KWm`+I[KZf70V$t!fm*]V_3&0qf4]=A%6r=cm<_'X)'1uL44d]Ss"d%9*VM,C3 + IGGcTd,n?%nqji*fIGQr4'C=9@+pA5.9"?ugug@d;%n!T1bF8&L''`;9I=H4bF/%Gt^j%g4";##@j + J/Sa`&EW\!Gmd7Su86CPL7>?gXmsK`9^Vf7(jWRfD9+j"COKLDp)b#T + *?]NLG1Q:csHQ^<`D%Zp/kj@mmBQ?TDkbae:;iM3,o/\>6Q]i";itLBRgg%$Beec#mQ!tiD + >mkW1#,@SP'EgP(i>kF["[NKU]/^TLE/>j"G]P@F=Y&,$q>C8[9P.3`Ut0BAS5*]q\`E + I45G1hd<&u<@NCTdBBiMZT2P!X2O=EL&V,TrdHIcgG]&e+K?a*XK<]_Unc"FCeD-"8[[bYl + 3>\fMcoBtu?]N/rH>JoIeqgRI@=?IoG@-VhsMWA?J#[XUQA239mX!.35Ib37(2`]7/_T:q\ + qCIf6bZ8%$Ptfl:eb=gNCj'#GVUo[oghq=?^#o';^Yj'U>WsMONQ:*Y?VaamQ'B!pV@ZC!. + 2GG*L.PdQ_N;0[JMXc:$CAB`%7&HJ$n`23Vlt]*+Q%QTp@@lYg?Ef + o2_;7QjL00BQ(!S"Oa,,Ap?q:j+EO]hV&KI&^ac^J2-d!'\V('QMXK="r&u#)J*lg:2@@AJ + C(mBiR:nAB8;bODu$Xpl77h3QWMHloHZ=8/$Vb+$kP=<:<--]5R=t57REAU!'LH3=)d?JJf + j;^"9+%anFXY!2p'[-Lb0'gG6euLLqm1<2oC!^oBUA1ln"E2J6,"_1G + D^_MWUm58tDj,UmFIsqj)Mt"n>u.%tap''O;3jFuY@T&Q4T0[a#VAiL"L'LZ0/2-&J_1iV% + ZZ'`C6n0FS^FruL9:n2#t+j]X?q-.0eQSng[^IMX;m_,luRr)h$s+gG??O![_mA0!&fqNp7 + =.^iu($E,&CN>cN]Vs)ipV5`aKY-"bj$PG(7*(Cf`B9QjY"tTZJ0 + jI0s6Q1A%EA/NZnMBQTUK>$63Qq@n0EO]b!4AQ^2nXOMj\n`7=\P?ZIUT%o^#^cHSq%b1DG%6Y%Q4/&/`r^.+Sk"(??5:Ht"hjB=oB?&g6hn + `A(ZgeS5"E60J5?^W5ZeHri'[cYaCu,6'(C\/oEd,0jEqKVE&,sW6O!Ur9ShZ'oGSlhF+`[ + YMNPIg!m&&u$FDYoZ$\&*+PRohWW9j]T_&KI3JUB1WWni=%AEtkLf"X+6rX.L7p+mn@h;lS + !BMDnn957,Zml.Om%@9b3'RGND2V7`4@]t;-V>Y(%?Y$G`V=]dLXe4EptU89aDD7$A64WKn + 2b#8H&khj5"F9(+3gkp;p[A85kRVMA-$0t6ZaQ*<-lg5H_2-/c5N#m]JbOqQ4[Up.YL*%$I + N6L"sUE7L/EOSKlGoj6cE5"Pc?McJ7b*75$CSCD(Xkf\X-&\4-!a60?15q'#P8I#,,QDJ`K + mljG[:IE/ZQ*Lj:5>Y^$^E]M=7HQQ8FeA;qa!,?+/`R<+=M$]s!S7]<6uZW:kb\_T@1K^kX + 4c,[mKn6Y$mIZWmHH5+c22$\3/(7f-I,ab3+l&H3NcLg:6a.C5S/\-lAK:([SiA.-6C49oR`*^bm(O + [2;fKEu1IKFW#N&TShBI-I2C>*@E>X]=Z*=fY%*HV]4X4mN4^T9X5c%ftNN"0cGUDSS>gTn + YTu3sdf;aF&nC=uV(qA/HI";9Au5&V6=PXWn9`NTNPk.j@n*egqnFd1'UIT[0l$:TqB%6+Bs;$7-%l?dWH?O0"OKq#68R7(UMO*@7H-/$atkDTi-::@`%ZnHcjq>A0E^W36W5t + [%q0p^%oLd>XM)`d="`W?gFYRQqAk[AG-Ti^C=%b*V%[?E*RR5Fkf&pi)l1!ua[&rU`mAE- + :o]F8#t-:ZaMAVnTPb75cCM,D!t#k4*WQ1YJ+(Y`^fV*K+9pgf7nD&G0pkcGOWGP'Le_3JW + o)9'81]Af4ZhVnG6pR\1BnEd*b3-]9p,(W#"7;[Xc7hh;.(/j\Af+(^i55EB8Ef>"ij+R"U + hU.O7D'maB8sHP2nDAeHCSu=&U:V3A*E;7I6bGQ'r.ZUJO\>.ir/Y9au'c("kJ3bXRk\$c, + (S`i.Q/UUp#,dqE)RAoYS[$T_ndm@EjgGp^kAGE/Aq1IuuF<%WSOW!!e$=PtR!^f#$0Pj&\JWj=hOhHT=cr:>AZ[.>l)Tm3t`J[es1PS`E* + =u%rCZHA!Gd?hK>2Y#X.cg]C8ZB]3Q343)#,_F;r)UCu@RJ7YI$8+U9^E(^qX8E`1[D\OHHHTb!G*://q-L:hPCB40 + OS1TsY(nn*ouS;QhtY)R;(2u>oY%C"\+7Kr7a`f\i1!;[YS0Wu2NESS1?@T4iXpZCR"CA#t + Cf>fOQlMZdLG#Y8#7o8;?_[\^6k1Ca,@'9qi/_@-##]8m!.2P,BZ.)`\N%D;fm + /Q:DN]FD29S7ETdR._P1TO,kFH(!;YKc.(m$_oN*\RA=\EsH':T2!i0];&:Q1dJ + 5lkacrsLl0Bs#9miB=)R#V1G*/6[Pl#^#ZKX#I)`ZVu8Wu5Go1>X)OL&D6`:Zm.5XnBkHpM + e#JPtVcCK7gc<$>KtdpKe*("jh2q046hU_(e^hk@hC0.i``I]\Z"GG6YgL'2oHa(nhEKX;F + )DW7DKa!91R0E"iFO(_Y19!>$CU.HL-%UrdM_jIt]W61bfK)B(-;Fo\fS!GmF_](Y0Ggl9/ + k%DLT#L<SE&[(d[@++ikt.67F5K`!$d!\`I%H=rP:uMn'k + _O1+T.7eMY,W#JiY]qM0oi%KNQB27rlmaabCQi$6%K3u>6Ucm=+Oln5jT?q&0'X@iUH+["@ + */'3:idE.^0m*d5)JV8AHV*Vua1B+i5&sAAbV',iGcCi,9%J/0o-$#0p#l9A^E_1@[[JEE8mNlA1=i+s_VJER@*F<%!9(TfD+Z*bNj\JqLDX/YUS0_5%UTG_1 + fgC!kBTkNYmJjHT-(kI,UXhG0nQko33U;4bUJTd5CU)@Bu*ig;@CYR\N;-;Rb\Od!^qLWHEmO:U*O;1`JPRn6qEY)i*`DM\1A*;2Rj, + $`(rc%]"l'`nh^'MG#d$rLD?c)OBFJ:%d)4KHmb8YrHAhm7ZRS'iB;%*'<#S%j&]`rA!GDm + ,K/#VbmQbI4bZ%>'Ek'HY09]g&1M&IV)(H.m#a,$*!8It`J?R,j'sbnnkjUpBDAj[c*FUo? + 6)G)>;`F771pIl,@(7#o3Z:;E(dZICP@u9Cf/p&0"V\^6F2^7O?t_k$r^jO9;Ze^hFOVGGn + P^)KO_A#fW!Is+&&?+$Te6m-(mi3NR`nGVUWOTo.N"8G'0H/Gd<=QC2^q^9XEYRIp)[Rob@DnF'll3bL%mcHaPuC+`:_uj + ?(L^ts/uqi8WFW/2.Y34`2>:ZsYtf3Em<%\0N&onTpo+8;S1jP@'ZuF&;-N?T[o3Mc27i02 + bUq"J1;V$K_0#Xoh@@lN63(S064Ypf-4>I#&4R)e@@lPG=[U'u$Wb'o^]kR_a_S?0Cu]SDZ + DB"RDARk=*&5iN@9C5$ndT#`(]e^uE<]%/c5_E!(BItb'QP(!ZjBUsDF\(A5_'VXp^Q2>'T + 9F?U"".DKeJ!;EpNQ%QSfs&d;u6!?A>m/_7CPkr#;>M'g\c4Td7*GmL2f.$!*a7"g(U?%CM6$n$3`9Yt4W%=jf_i>)o6p(L1f(^Q3Cf0*5 + fkQ\N/^S[:tiO+&W[sY[//U#X9F2\^,,S8q+$0?L;VabLOG@u/*s-+BUTS41@U^gh+'>YB]ergh8gD).*GJ`>cdOcla3YcC4!!(^h5hl\_@s + 3*'4"nZkDqOs,hXIlSK@\B`34-Gn08lNbMtjQ935d99^b9]HI8i:X2Xh]0l55PHDFt6O2[9 + L47T%-@*oVPa!QIZ]SOK5pNV4$I-!Pg!A.LrX(mYIQ-@n6Yo`q4lF$L$-!;DFt-oS4K?;18 + 7C/c-<@MCb\Bq^+hTZ!?TAU0:oVVu7u^l)s.<2Gap168m#_p4>eqB(:P*iEg)1h)%7@E+\0[,O\,)8d7ZF0<&GaGI,3, + :ig[MH[*#n'7[fn:W8rWW-<#nHV*!N$Q>+XNgU3Pg(`iOg)pBH>!8`s8CYcf((=6K@cV)3a + *;qIDc`-FFYOV3';aTqZG9"fJ)2;spuig4cH6d`IeW)[t:2#X&;?#Cp5b#s`GF&GR*qjrqt7ZpS-)BjGsqQ_/e)_$!N)aG@F/,C,El)8egc]]qD/gMBE + Ae])Ghk:"9eHE8jaeE_K4lC$soA';%FH"%#'k(Z%eI>8`IVu_b)Z!O!Y!*\R"q<+-E'"Ii1 + `58VnBd>7*9!>'B@%VU^TQ4WDZ + ]k?"15Oq@#^h0_ToM4PHi(^47QZ-*D'4@&O7=$/[.*'S(TUmegKHTg9jUTHUY'Gr=HNJ(UW + m$Ad-.].]a,Ik&.S4n&_:HU..>?M.FPm]`LL:53O>-3a;[FH*T9J]a3s2P--!Ej2m3[$p(K"aL94H + uq+Jt\WR1bSM`5!XY9,'3#4V*?,6=>E[^\XU0n_i`,BMKM!:nZFi>LIRh=d]R+DoJ][\m=( + 'RE"c!Q#dDle(%lhu3Yq]4k/hm,%j1]HOis(@9]t?TJ"T(4+9h-67,jNRd@BI[1`c4`/6$> + 3W2M(]c)u6(nq)4<=7B'WVu_^r,8]Zitfj'4SJ,!C>jVXlccli&cnSlT(eMA/&9:&QidQ5d + Q2KA'LC36&Tsmh$LmC_9agh0KW)JBA=F1\'JTT-.&q;OKUqCBbrNng8le?rTFg.g)8j/&F, + 8#iSY[6Za-0BmG`jQSmE.\l0]V[M]N+Q>M$CDL30@H$/g,2g728(!#u\`@Q,adU"8G9/f@t + Oj*J^%OVqZ&"qKUU\5KuNM]l0L.0e%JC?84 + ;A)^uLN/9DRWq`V"#@mR.$9Z&I0e>m37O:d$(FP'511a+fBo\#oO"7?iNN)cHhsJ:!l(r[T + =+M[\Rh24%iE^^"\1OH^E$-TNZg:n+f69VDJIILnNg?5+V##kQ".?*ngZ5QM+SUK65gcB+: + XX;\aoNE5N*0@<%]$tLI:&5(mIcE'oPN@&X_'c3?=/Nj%7?(!_F[>8`%m`"KklZQV6HS)3i + E\24I>'&LZo/o($f[SBSt\D.o_Y-W(:?.BRW--S%fa'hL)R;l\@teXFHpY?e83X-NPsEEH* + SXNVpniQSC@6(/[*1ZM2#O_q2LDDj!+f%"A.S+!hueoQP_8$Gcj>?RKN>,cBe`S&2+AJWqb + )4\]aW2_3PU]pVXi#LYH\?)kGRKH+i*Rp`(=k%uJ8n/3+>L< + 04r@j)b&;*g][%ea%AT*M1l$\_Z^rhqf1,NUc+Vq>ChR=,lqPpNQTY+.(8hrdMVN/B:p.o# + `54`H[%PQ&l[d!PkofNZ+2$=TE%R7eu-A6>1r:HCnf;S9:*n+gscLL02GF(Lf(1=$[B[;Zf + I.6s16iU*sPQMunQN5n:n#9MV&]3J;IE7lfrD89,r\502Y%P*1Q?A;_g,nqF8*u.+U:sLji%,3[7lM4g>#3EqY-CA] + ELWlRkm9sWgLbW"#'l#?Q%[hN71MbrdNl089\3'7b5#?p#)2:+/"'q0p1tJ^l-?:F9F'Vjija,pD2?HJ^=CnUm?Wd"jP@[m?AXd=8p4IVZT?h#iHmLJQcYG\)EVjG(pB + >kh*bWl.<1AM*ZR.,eGE4UhXoR<9A\_^SW7fb53RNnKL@1#=%B6M8HAf$ + /XiULG]6)9U"k!da5-3H46N2-?tABE;O`Kq@"jpX3J!TdA9k%ehk*E-BU\dR%u^q>Rc9n==Jsrr8CIdo6FXnL:T@3@1XY"9,nC"RRq4`c'qpZ + >V;F;4rSZ9o-l:rk-)OZ.35`VuZ6+bg/.Zm:sTd+De@,]TVb(+0;GG93ZZ6f@o[l1=WM++o + jZ&tc)TqcN:nk]E>M3LjN;Tk#QMfRG`/H+g\QSH;L#XpX+6>mBem0gm^4)?P.P3&+,,7MtY + 86Z@K+GOB>RW9G;!Zrsm>"tmfT<#&h,'gRMBdXc[Z$E[u+%Dcp2c%+/F9;,3.K:.BE(LKtd/'KI3+!p&D + @M`d/qo\O'+]aWL2hk\_@m98;>'1opTF3rfQ[jDIIN/'?H1XaBoR*QR1.-s8S!4.P(jg'&& + J&H#2%oP6I`RQ&W@o$J@Q-*4L0S&@+6*.WX7g<1'BN3(^=*,B0M4qjA`NqWEAFt+<;J. + ;riJSSU`OUm<\dkQ1$#2`V=H*nV,,$h5)i*'ubR(O4B%5S)PBLk=q8#%'';C?$mIq-YUD/b + =gkrFuG:UMf43,.-&n=`aK99R6K!7ZZUBk098`!0sE9nYK0Op-*;CESbbRC[<&u'XKoVdp& + HU?@HL7sAC7[/]Jj'6;Yfbm%X)jD=o16VlF:^O+#k9bh-QOV)G8=\sE*GRiK2\D2tKRHe80o)Fc*-2IT&dbZn#/I>S@g##N0j5:mKgAG[0H + &F!`\doRP8p>??B7t53GQ6KY*ISM=*jCCCXmd8Nj`u1B25n5>H47%p;7o;Hp,E(Kc0MGkm* + m80h44b0U<]E\tQbpa,%MI6]=ft@B(G;TZBTSk/U=<;'42!=:"P&N%cEM7g?3GU]\tl=_Bo + :mEm3^(A'T@qf&;LA@rkukZ/,^2BbNiHOJiK/VAr&!fH!3#(l>*"`mE[A[%UCK,e1*@L>Hee(Uj$7)`P6#_ + LD`L/EOI`$!>?@Z5.4Tnk`RaRhX5q[fg4A!12\A'(,YkX3l)1+LqG(r@CSe521'07-MoK%) + Q/,AUOqb\]mK#U7JP"sJLA":38G,@k9m#dQDpS=%CQN0fS8O=e%?Hg-04V\;Nl4NCN%^l=k + 36aDLs')6\f!N7=+WE%SEaK#XjZCV4,EZLX/2Q!#^J&B[R0a5U%(*R^0FsA\PN?DM"JlZ>e + *o5b%(P/8Ug$Z:_IuauK7HgtH\AP73m]^;#`Y%"ekK._)JmH)3#(r'<[lnp=EaTQ$6r5AM%$00^/+ + Y+S[]`Upa9] + Ca:@uCBo*&#.V:!)+t'nZiU?u$L7>X.]%f&\:qct-j0Gg89LTB!kSNu$L4jHJdDNmDM?/34 + )?(XHoNs=oL"Qu6``@!]EL!)#HTIL4Ek@<'H/LeH[%e"s@9.-r_TnSH + `ad!ru^s,T/b^5FokJJm_gcb!N4\=bU7%2!B'1)rs87%E2KG5)LkL8Os%94ba5+K+OsgPPC + eE1QrA%L3QGr3,jTP=U1H=L\hWJ17AVj;S1^>+@;fS1NTRQ=tRBT`iNrF]PL']D+<1QV^cb + c8:*_Z#KGd,&?pS8pc/O=Kq6:dKfEs?+P\k/I"nS5LM?:6"(4VaA$KEI2:P=?q#Q(\*JK;+ + K$[hW3'E!m;?YWf\O^a-!S'8PP!2uE!o/\<'T=4K%u7B1L1k#4bBcC"E45R9Jl5a(k\l15= + $JZn^8)#C8Y60EpC-m82Yu_@\86kD:DJ\)7tdL+r1HXjTh6`*cooEWe8"lNR>#YtSr + C,LTtL"hTlN8u5][]sYXbDa!QJG-]LP6>9VJ/%<6p`>4?m14g>_JG`qo.\CY>dk@/S!d90k + psCLCb($V]B_*O+p9QU;M)dX"UjWjbkt8YAV<2F2IHTL=XMJF!Djd<%c#UIXJE5B!j07TL; + 8"bUpLtB63\ToY8%5$/.!kpHCcO,"`RBEil-XtJqageJiHrW;qoT">r@;5#.S,rpi?["E]? + ^I!W)`ji]*FU?IHj@=emF/n3e'[[6jZcL69Zi/D!ao6?oXG+4*eu;JLSUrS.!4'39@m9ef4a"GfR! + k"-&jlI;A/2i3`r5_9S[:tL5UN'=gnT<9*:+?]+Ug;5W"6=A-M&eb,^K$J$]rYD^X]jP==OYG\jfTs&G + lo`Nem[j[:h&,6Y`b)mLOac,BOh?=`OOY@lc3Lh(<'53GI;,eQlGY7e- + 4C"c_>IDVJiPc7+I#J3o!5fbNi%3B1B"^i>%[8;h=OVZ!/%uY/a*THmJ($_q-T[TM_TB#g-70_#[9$X'%%WEr1]2:L33nV[U)hZjF-#7,UQ#^?RSD'\uRJm+h28 + cmG#,Z%_uL1j55$5jatm/i-:"b+T,iMlVg!%?fl*F[_6g@YT]^)eP8bs]A_,R + @_1Y]4+YDq9V2(GK_0=?hOJ1BOde6&#R\?mlkO$*ca1L.&2Y3[0?`G)&d?g6JEtGY\Cn++k + CPJUi"pXXj^eG)&n+KYTlW.Km43=Q3@F:X%2gj2;6`ETA0)j=WeZ[NAFK6_^nr>N$@Pi]!_ + 57@=^Y#OU`1F[LoMZ!LgEa7_$N?#GA+63G#6gR)id-0^qAQkIbRKCCTbD1ao"ouTa+#KV1G + NA1b'GG]mZ,rmidM4t)e?=]X:9_5.dp]KYL.HX`=Ao6&[/nejT5uoP4A6*Cg7<,QR'a!#6K + t)D4G&*UVeJI.fKof:=mCL@!W8#]$Yh3&?id(g)Xp7+N9iRFtLh$X%3mSKqTp.CR#[&%b$] + XXgkUC=54j>KR8[GoE'3haC@8m?a@S-!,kcCL>7S.:%NG.&Jk+M=p7Vc\s+jL@.(g&kP87B + <"OW968L3R87;q6W<5(eAq=`/C!EHjA&g]h_'KqNCj)(A?mn:crW!Ta$>8m(2J`/Z+_("_^egfP^u@GZQlo8SE.!:gXmO1Za2kR]/l3hD#7+lNLV;;W%OeBO3e=_ + Zijl'70H%+?AYW[r!'Y=%IFdIaeD4eH,BpD'mkOHNWRk"`8ha8!\#r]XB]#9C8G#3[*-Pn8 + 8@?3eg,;l*sbRkZP=cG)#.pllFL`f#Xnec&dOH6$#E`4/V9WfTu0UOfD,aX2\6I40N=]:\7;QITL`YaW)V^-#(H\oHN^], + ru[=fnZNdL^DnMqf-a#bgAGs\aj%n/CYc\ZncBoco,n9':P>Z]duD!b%(4"kKS0=d"uodP2 + %9hmBq#0%!dXtQQn\XBeHE<@6q+0#KP-KTlQJ.5ni&K\kU,n\7tf2LBZE('^H4MW;QOZq2??l4E,Wu]O#"WlN+>nc/?XQ\ZJY5Vg0HgLj<.\IU+@o0-80A%k15'%?" + b:IIl6HDfN3*WFfOpL!]#<*.gm(T2LkX1X&:g#[=#-TP+R<:+*0L>;o"_0.2D)2 + [1[7Kn+*tU!4j-K>3>(mI!^&;BDjoR]:NP"=Wo6&N + &3ARMRgmDtLF+Z#Q]B%)%Dk&ibW:M8/Q"U9ZJSN0g\eT"]%W?qqNPj3#)]KC9lfX+8iB!kj + G=)6@`"bt!+Z<;"pHUXg^CURGaf)(-Vl#Tm29UB_sjkY9nhf%-E"pYrb%YtOI7C,7=]qdEdTI3fGd_U,p=k#8kB2f5^##kK) + F7P+(fU4Zg3k5X^dpd5(0A]Q6PO7r4aj + $?tkjYM=Pq`/.o[8Sg>72CQ/D;HLEaJ&jeG`Aareu)bH!CTq&H7aZ.3e6/H"1_\AWkNpj=DjCQZbLdI) + 6OiVIM7sWg9g]0=WLm8,g`[Zk!@h71C]'/Y+(HbT$_mp"ZE^;/7T*7)T/)lAaT'jcDVVuDkQ/]Sn>UedmjssasS/-Ak#K^d`)rmU8@9L/T?mURSJJ(/7Ar2mtj" + ZB:hLJo0+9VC/#DiSQ`R.gOKiPsX9Ft)Nq9""iT;h+M(^Y\m63ap0l[.Lg_=7A0+0!$tEBa + b*T,^Qt6]bU6mQCciV+NXY=FB(Z25\g_#0Ijqq/;7j*B*k7;5)5g%: + ns\)%oH.O#0:9]K'h22oqX*D@)<`>jDgsU4H#:EQ5P9N5:_:e'S15`(o$.C8=:2:c-SJ5^] + m=2fd%skUl:Jb?;*qY2%S\%SV[lVp.;e_OO&eB7g?an#8)qDj^F5l,D^3J!36)c0Y@mH>^) + 1TXJlEFeK)M#6k&R\&4N+/2Bbm?Ma97#O.Tm_B:e?d\]-^( + u:lBhOHO`*DY=m#cGquSCAI2;!K>qMX30JcY;f1U/ZN=eNCr1iV!ocd2b=.KM0M"TiT6]A0 + #.W4U((`0LPVF*lG4(1,a)8'1ggbiB1Ah@RA,SC<.HkdASHZiEj]4d:OQ(>RN7(&-nlk2RR + SD=HuQ9/7[C"iu6!@X!MR=q9@R'r(4GnP + _=]@"Ua0q#Je0"0([R5_m"Lq;)gH8cq,#%)M*\UkV=IL!CQt+&2diCLrT-7/+5;\?%C'08% + @q,=9f[Q'$E7):nPbE[i?/]pP6#>4ic4T+?/UAqJ>3X@X/2('2[sqBaKcd"$)9)K\YS*omMfY4=_EWo(]jK=)0%KM + NH*eu_q<+EpB@5q&B$7l:rTOb/9'p:Vlnkf#9+TZXptJ]/>ff,*Wq(4C!Dp%7,H1'g'i)j* + LF/,VUaDB[e\UglTY$UmPEnm-Nh1oC_^Rd,=cfp)a9b3/2WT&__ + ?"aS^e^lG8^$,HiM4-(X18E69mZ6Lq!fspq.?K + ,^^,Bq#eXp + VYVuWf3s3hnfl+Ucan5cCqA=d2MBcT?#>B$^8k*aS*bfEtj_u"9ed5dO*MLoo%u;;n4;*4D + G"SjG6!+RA^ssVC5cbe_6h6s:BH;Z@)iq350W%8->meP#1S?$%7][$F]*e&B$kU:g&4FUA, + n*AVmihH3i+ggE4r;%QYjfq*623kWWljfM#"+or.LI65#S-s!Ju$>X@58G2V%"Ym1L@I&6;+D=WjO)!RdLaY;WAN1"a?/>t&2. + f6A.K0$m&U2uW*Nf0O5dUh`DAiPAi$28A6"CZuE;>%ZlQOIQEMdKdCDt% + ^)\H^%6o$SR[i<`0*!iSRNlN+g()2@M>bl2)q + C_bpC$1Ipg8EUP8V"B_d0riM>"J@t*e-Joq(SUi[iNNN,.KP\b)fd_TZ8X"k4!W0;^bNk,1 + -gi6>dYrWiop(-H]X(`10$MdMbE7-B[.&;TC+^at/,$/IZ>Edap(6g3V + 18aO!L1a1T&mYqEk^0*2t[TUH+&`]NGaVS[?jo*,I6$4ep'/n,SPXa17O)B%!F.j;D\8'I^(/p(qPNG1@"ppL]'_Cn+P*dT4dMcPY&E&!?+Jo:C7K + FV;'4@74U#6mKZK8p`*[1,'L4g.HrY^?_+-&5t"<[fr3Y/S^0O^!i!cA>Z8jX"=ct"7/oN! + ;o//KG_$,JS,^d\c`@KQUH"+VQqe94-arS[8JI@[70tRY + -:bi$$#$_-:!oP7'^dnU8\u3=U"!eulFN6H#q+T;T61-9,eCFp?g'Y4D$8g`HDDD6c%KM6b + #iJ#N+jq8PNpVI2*)M5\5g0SoGU>!N#5"le5XSD0YQ^:5c2]"^#IFRJ.L4KVcV\[9$>8>?03[W8pQi.l?=kb2i5'D\V1<2()Iid7%I33oP3`P$ils'.RrmCC(T>4&s\AZnt + dF<1?q]e7>7m?5:"T9,JP1Y&J&p!4CoiJ>3p%;aYZj8Q + 20N:PJcm]=1-XtX[@fm5Uk6D_ZgLDQE7DM?&_%mq7 + _unpM$$K<]:buDYE%g/bBE2CQH:omZQjs2&l!FSiB[R_)k.PLGJ#mRMMiIu?=pN+qNF;I:)2Y1Xl6sc + -IApTnf7lU$RdsNR^+u>gpQdV + EOa5QNH3+sF@IgC4R3[!N + GNLUr[-Dk>ZjXkbGP?%:+:_KQIi&9<Z!2&H%[^Sno@."Z%n]m(%i-IJ=Jq%?TnTcaMPUZNPeU=f,?tkbD7+\[i6* + +GPTCqo!PhoAQkgj4O][qKig@%BE%ViF`Yhn?Nu7I?esBFgooDN_$[DhVR-e07.L(#C8jEW + :E]+A7a:Yh:6f@eaJUN]HM0NFAO81Sq=Z;P$h2dj`O4cQj+bu;I-3P2^D)H<_i8mjE`_k/H + 77$>B!"K&f-]!d*+_4@mi#)VL/=f)-PZ`X+=biB#Bo;_D:d@,FTM#A5`"$r;()`l>L8`%e> + 9n`p$,Fpj1qEh,BF/(,#d?&i@!i2i2gMrrSJfnI=k5=@^g[K*>XJd7#9&2/d5RnJ7B"q + $W>[^GZ`AEKP!c&a$m[!aer)I4+:MGW3.YA96m53r8gd%?"U#q_3lXN$6Q0>JC>+7E(o=4N + 0o!M%Xr?&t>3>4?h6)Db)&i'4)Y6*-5H@(UFlBs:;i!7Q2mC*lYl]%]G!lI2S3o;-(gnGk= + ssRl6*B;qOK"?S,JO;A + ,Zl,o-QOHHj:\[i9t09`)2$L-WT.\JF>ue"aD3HI<8K'JsR\*[^eh`Va-(K*0 + Ce+AuJ9dBfCiSO+p`s3NXRct"BJZ_>b,,LIh&(>WF%4_EVhPLQ.@;B`Bu>q<'%Z-h^9f2N_ + I4[;mCM:WBpe:!?/4\]\H$J.BNPaiAiHl$X2ms*Gj64;,JrKZ,k"4O%fZGM%?]]_5$N)8?T + gTjD7qn\L[dOeal%iq/[4eVb$3SJjDg84.O)76Zb+lD,2-jY&1bFf8j*T.$@abHq(U47XIO + i]t-h$",E4qAl_q1/Gm/H+Pa?0U'/iS&ir?L,T;IRcquXqH1;-_'ZB35PY:7L=F8jTAH#,o + >HJJ_tiIg-TFSJpZ;)mH3LHd_[#@U2T%#Fm,Q46X:egk,rJ?+3EMrkl,'2I?Wq_\`6pLg&* + _]4mh:cn`0lF.fL7LU25SXh?(^!FoKAH@o($TX`6[MeNE7H^31lp61)&,aatVu@VtBoM9;Q + 0dhk#P]NrJ4H11aa*58EB!f?4?H0[S@l[49?r.X#m(2Xq=F\XJ%T/Z>Y;on&:59WcL?UMra + #Og2gnAhrJ@2W1>$g:Wro]E5'I\ZRZbM8\KnGbT8D`^"MZUs%r.pj7>59J+!,L!nMbl93g# + "lmd4o+!%gnbh\ibdphJa^?\9Ki.&+s6(/EVf^KpEG+P4X`Vo>spim+eHSu?C1%cq>2ZsGI)NCMrjf^s + VY+d#=VP$'W5;(7c&jc\;=^0raa9]hIJeD('bSMV^URH$VV3h*"@Zl1bnNBno>hA"Vu-?W+ + _!$`4>UcO8GT@-N#fR6q=@Bir$QCC![*`N.RU%hD;5r)\opX][^L=C+2KkA.o + HLkoV!T*X>+Hk85EAnk>Y)=B:WS7\[Tq[55G?KhFS_(lMu*M]#PrTa1USmO=l'J + 7=7]`-f39.JoDk'd8:[*(\-dJa*;ht-jJ5VNlW!^N^\Q6rR^q?HkrcpFbiU+3McNk(/?Ta4 + !kUNf_TXidaW-S#$="%9CN:D?5P;@;a%/$$8L]Bbs('umMcDO.sh=RdA$Z+K#kQuVbQpHbg + 36s<-E<0nq'Z?2]e8h2&r.Od-HA:_no[&FJ5/d+"l_T8OkLeNU\GVi,L%+d0VP;K*q:,A-t + -H3$]?Pji^]_:hK';YXn51.f;`lF;Q%bO;ZRkZ'`'QXX,.5F=68lE%(02,;$dT1J=W_=Ib5 + mg=IFN^[H,n`1[8hW,s[;*0/<]+%q^>4c`\(+@T]Zg#,'>O23tRG8q + e-p=t(11UJc9#YA@E$e[KEO0`$b=PjP^MWD0=6CGFCZ]Y.?O8/7[kWFbJZps%E2%s2$beb= + MaQ0!D]=:=2&5@:oY%Y@gieWkerW3tQY=r;DpC+)!JQ?csb2E"e"\=PpHA2tBlA)t%`8n6Y + cABT>LapqEM\G*RhUlh(Qf9kFH2Fj?O\as6ZY0Pbi))'VpJ#$"&;KIS,3?B<9i`^K$MPjRi + FC/f,#.C')Rdo4<,6uN7WG6cPA*4,^&7hI + ->l&K7[3Q%i6PV?j<+??Wr&(ZLTilmJq"paZ7Wrf\"E*]&O;j7s)DQ:5msTVcVAjY)2u,&c + Iiig-#2*VQ@YFDY)]H8qVAI9d;ugH'bIp^UG=imIB&+C:AcGH9R[lTUu_LA&N'9=/YIO*-W + Rof\Dp:b5=&n1!Nc0\bM8%sST`6Oo]'3:Q>LV3>]#2W/8Zi9JBk+4L-$0'p1e:,UH>YoKsXj8H + 49>&k*J484&muClK&s8L\>#YKlam7ZpM@)H_ljUtUW]0eQ7r\=A^b!:#gMr`)2P&ljVWYEW + mom=r_s(r-_E%J&X`bHbM$-1\>C;Zno#0o[n^>$<:&>`cV.pdAO)KQom?5=h_l2H=N@O_#B + 'b_ZfqVKsAOPD4'%GH.65dX6$jNcc-54$(iLTg"[N'1u8H1+0<&7`:/kO>%8!FgT[ + M?p;;/I.kA,\>?,R6sK@&"tgJNXg@a2G+6$UB1d^6IRe7aik;A'/D]_Jq"5k6nt)t3;BWn: + /R"o-m6^opq(R>DH@8e+E&$]Q#\!CarH/1<4V + c)2"a+@Ob/u88W&UWRQ%lP'$8;d$ksbY1U`WXB5?h?oA$-Qd\Kb:8p*rIuY&#tsMs080C\< + 1]('_TW3sf>322AFOp^^K4Oq]HiM6[mda]U\SASec@ZPI/t=h?\,D"XF-(%s)AC,@'8%B$T + LVU\k^=_hksYHu)tfbJ'+Cb<'([h\g4>Heo^CH?8A[g(XC4,Irp2936D-KSLER<*7gcajo^ + l!6BM?pVc`\*9sr?*J["CAY4WQ0.UC432]JX?`=8Q%"A/flh:Vn%KUXq-Q5JI;cOf^DH&2? + b?,`DtX.G(^C(L4:-RX2@%&8-O!nj)1umO&&K/R$"5qFKlFI:_\d"q@D"Q(Yk>gBUIu2*X@ + \7g0r8i+NPc9=MdA,!g:`%.%V%V8NH)Bc`u*t[A%[)JEV;W<)$_f)2BqY4NX"42J:8PV_r)!fpd&+DpB6@3G1GCf"h? + EcNBLsA_d*RF7D$/=LFpeqo:d?+mu@6*7iYOZJdFG35+m@7;4n5J:]\G^7\\)#9>gh`dX3& + )M_0%4Td#f*i#_R)cRgu'<9:=N*Be]=Z,+tDtK?uf,E`#Se*!ID>^IBqZL*h42J).2TO6eP + rttLn!>q$'%L2Kf';(e@C:^C)-^VTD7V9;[]\NC"r_gsM%s2Z%;Q3f%_(jHft2/XuCSY&)n<3;V-=m`+&0.il3'fnWL + f)([`E.>R-91GcSpF4VSn0oECGO,Kj?i`>IBsPB/p%,e0Gkk-4H9F->:tq;EpcbOY-*Y)'0 + 7#=mt?4RIb"R@XO`oBI>Bl%T\H'=tT"NeW`%PN$h=&4YOA?&,[%N)JV>2Y-3Qn"'08aj7S- + ,j6crc[npURd%k22)N[N!C$;V7fR^Of7K)&cF-%b1`Ilm"3#Mj_qB$:B^q+l[J:GDgUs4!m + OTJtH+eM+b-9mt*aHu[W7Xsu2lH:OYJQBN%itRDWV.CONq7VHm$n$=p;ETHH]f];=E>Juq) + e\NW+k]/1"R/T-LQN7F=;T^`nf*#L6MVL;Yp^Gq]B@"qb!(GR\.+e`-^>>&ej`$s%`?A_t" + Z7RJU5:le2;2pjYNl6+;Pkk9&69ILl'>IiJC%0p%"R!K#3_LQaoTg]XU/rkMpe5ElAfKBth + 4]XD>J^km\.j9qq`b7n-)^sISH$'5YL)o3ac'Ou1b6kl:269Dgj_/Q\FHl'V_`P1@K6()UU + bSu?os1d%pR1OAT"%fG)-6j-XJcm=!BMZ3iH,7uWM+ebXEEJD!SLEKcM7_>h!8OA`K->f8( + PjDq*#=@/c]YjY$.9[+>UMm:*fH.BT!D!OKJf(6*5c#&5HGqoOQqup=X@H-_sgo!"(K0l6& + ;$Z*`OR'69lEo8#FB2%u`:ZN%KjCDCDipMt7WHk + 0F2>ji)+BFMW>n9f!H>MMJ%hSPP?Hn7W6`CiW#a#N(RV6>$u#tYcc52PMO\P'S9U3M)Ruko + 'RX@VCh#\_*sKG^LB(J2?uJR=JOg3#a>ALi7"Rs/K?.;NaCL(IFGS"SM9(@-8LPf[I#8T^6>I$Vm-RE:\M!iROM;Z%aV!J-m]!WYdpJ5 + ;3\HU$k3LanMoKO"j],g&r:`uDquC\!@!0?(/MWS!aj9VP/,Im[pVRM)A`m&cLoHpQ815?o + 93BH;e_+TZgg94YM)Cq%TP\BC\X9=27Q]Xl;)^!"p>bKR`EjM4F\^s"(?bV[.07)I/A_ou* + "b[ec<>fb-2a\7B0bd>O:`6(d'bKSbcbiI*ooY1DT%0H\4]]mas%+MhPYs$=+,M[(RP&?:b + fGq\[`1WX=OGTc(TT.1H:%9:FUgVIC3_L_;b;8]^7(#_lcH]t^c?.FYD!4WAkg$!gcEuh2` + 9PXlld"#JcK+H>gq&%r%KeKg2_Z7J5[@/biOuVM6B'S=AG@,!fM?e'#U1,3Z'PfVp.sW\^m + ]>QCYI,!3R0/nc9(O3n19/V>69$jKp;khI0WT&$.+qEd#AF[V$p2.%++)Fd.IiF"V/oh&() + +)d3TIR*>HmY'i@C7d<-5PKbdON(X\cjdA7f0[2dSr*RVhI;:Q`9"Wu+d'`e:f0CT@"YRZ< + Q-(jC=$(:qB)e2ZcCer:.c]R'^]_KpVfWYf5dd[?5%53p1!l:-(^@Yr7&B#lf2D;,VK-`J$ + 879\ER]GXDe$V2lCHVnNM$JGmdn5GESLu%i=&5YB<#H:D3rl.;5La*8;[l3ZI54*:1Hs>G< + .Me-?l?*DiC6pJ<:llB@!5N`i;ocQKmcn9Y_!88#$#/e!?,3qHd.;nn3-gmeZ`o@`Cm+/5f + uMIRsdYs]gU@%>ui*Ke9teh,tUCF8j:Km<^="s?"gqb71W(*23;kfK6.Gk%+aN!K-V_,@bC + nbWrei4f&-sndPq;VB;ZJN9nV\3JU=)tF]W.#O;qUG*3e&"("Q=pemn&IFa]/]oFV?;=>N\ + SN)ko(r%HPb"iZ$=*HtE*qUPg:=Ic.Q]NbcbE7fl)O7d#8nJ#'k%9NGj=:L@KE4pf3Q&3pi + -kIpf(g=iheCD?OYJN/JB5\Mp6[U=J;(;>hd1n7NgoJO,PiR]s$1P_:ho"O7fBcNM + jJOW8"P=,)C7M3C9p2#[AW$gZfs:%CAR#TN`GV=oGT2/4_Dc&ru]08MYp7FE@@`6[8YgkDEU2+(VFLYGd#^9s_AfW%kYFZL![N@dG== + 2NsH-M78:(8Wno2Uh-ms%FkO]-a&:I>b)gjPJDCR$Rh4q`hJM_<4hBMNl.uOIh@nRK-1R*l + D_:p1?WHjXKn3SGpl94^^h*,NNV),%!o9kC"o\JYh>lIK1tTZ@7KrmRIJZ7rr&oc4?pOaPg + Qa$_V?),Ni3j$j"qZHke3lObeEL$N(,A5L+U&u0&pp(=S3,DN'B\B.s\U6hd;fHj/4m1scV45\B2FEb + D7qM"XU,Ya&htmq3$@B-)GZ..F@k8L!B4[b(a8q"05?L""V'BQf0G[R!9.Y\*$R&^Ec_Ajo + -@I_1&Ykchm5l5g!JOfsu-!^;gWn5<]_O6L7\kJigE#(=5:N]Ubn#"V7:\75Y,2egj7C#5H + H#+t/rT5#^Gl7Sdq2PfV-VTZg1Z#lXmWl?F]3DRS + ft^?Y.+mI&Qnm`t:hk4!9^nF%^om6E(N+:0_G`IRV-KC)fXY5$uTQg^#pm(;V#bH^EjcL3C + UDta2"#4ld5!H8PMn2CF<7fmX2"7TY#n7N!qG6m\V$1N]WE0gq$`s_<[-uV`[!RD:0Y7QJ- + &aun9iElA#0T,>2k\nYLBssOJ#/9Vo)"FK=nXgb?Y8d#`*:`23EVCLDruU_9+n?Enndcu9- + R<^k,k>RolW1jg.fB@W#QSO!"%Y1OD\Vcn'(JIDLlW:b2\s"8O)jh\,6/ghPKof.39^r/o6 + (/se_]nI'kkG(kgWCL'<-%#3O6K<-m/X@[8&b0Pj)O=F>aYMmmDn$0KnS]\kbK];\R(&6<: + )6k\j#a`YS2B9Sac[4jQVYs%%7ko#=e4=$;3@O&Yco7tgY8E_>T54F_nU07geQK"3gmpg8sSa,H)ZH?@2a4MQb6+,bBqOngAfNh;>RO,lE$O> + uEcGrM)cLR=&kCZY#)q,>B1@uU5-R(&^&U\62kZC8C9g*lBao#V%L0PT]2p-N:^&0h7 + r:eO-(Tuu"^AS;brAW4(8(QN#r>%_C-f4h=i + Vk4ar\pKuqXf4Ij8N]RrcdQ)J?NKVKjF_@>;/$k7i6b0?r-PC((CM%6=E^#A2YG=LdY]L32B + S,(Q:gn;7P\14WfbVA5YE5Q;&`k8nCo2A@>bsQqV*j3Mb5C2k3WU;n:u_I6XB$BN.#=(6(h + [;J>OaA+#l^W'..V>,=OT:49lm<3#&']jJ!0=r&l1PQ>F(>&@N6P + M2u.X&^`Hh*0G-T60L@>I?ZhDnhUuGPd_%mhNN7n2XCl(G<>>k]C^(fFmo*e`V+&?,#KG^# + /=(HsT#bQd+^cH@9,0Ni,rTfB_;n4dBs=p\[ID?b9V+mXuVm$L[kV7a);=]P_M%!^E_9re& + !6KEhCj`lo"b_,._$%)Yp.4V,IC$q1cHOXs3?`=YdD'uc!`go%jsMdWJIXe]/?\*N"j*QJ[ + )37CApjEh$5EZ/^8aO3bI--;'r]Nl#>To!OOC%.bVclWj(e/9#(m2\D-t0Y>_oBU]'!;_pj89 + X6-"+3oR&m'T]SJWDfEFR;9!c#as!N_d"XeNf1\1^2j+n*.ee + .u7@!4tdOp^5!a\MmOQ9bA4-5>#(^gi8h!7,OP20e.'mEe>K)IL^G`D$9U=[[!!+1[oeUP' + <2?o(I\D$+dU3LDh@j60K%?BNfNb+X@RBCCrk8DQfSZ@pqo:NFmD8NC0H01'@i"f/bF]2<^ + RY4O>o6c1nlcr"X/ot)L_.d0mh7`$%e9['?;Cl34n<."94BTNaGb[*UUFh6sQbHZQ^B)k&"`!# + ridKC=&jeYDW&HNi)?]^!he(VJ0&c4?H8);'0T%u'!;ShH)`q&W2"T4f,Lm@h`F$(&R.HOD%L,c26'47]Jdb1FHIhTWm + '?ijMo\4\G[9Y2FP:,u"F*AD&HhBSsZAk@7k$mh)V\@Y-W]WlSk[M);T^Hgd-F+/1`l + ,IFm)G=#[U%EYadZVdAbA@tT<+^5Lg1s18/M!^"hK;M\92$"11--*RU/YVMH5\ + GPNBa=>%^@!f#jc8:Dm*)g^rGXnat$DMKQZqCfD;CTm"LS-<_ge?>:a&minoOA9$=[W^qA>HN&9`S%k)D"b!L[4(##s+hJ2.n&-i?nOap+B#M#&=]%jBTWO

\k?tLrI\D3(i5^CZeH2-5j^'D[ + p424br"0Rc<>H*Ch/^Z7H27L9ZaXsB2rd;X`_3KZ7E0rbdJ_.30I6V"1X"aJtcDD'aW_<5!nD'I + j,P%4ZP"^NiM4H^"52Ah[Pf:h*iR)H1N<61a;h&rIVl*hcqQMFJ1SO!S>g8LMRt^6hVk]+8 + ZtdkhI4J2K$X^A2e2=!^i(:VUpFsB2\/pFdDJc7,GM->B!mX_>$M,iERpjlQsB:?B5LS)L@ + :nk4O\tE(tb@nALF%4JN[,SUOet:)90a3b0Z'R@.4]&@t_V6tTLCl02&M/XN@0%CFo%SmoR + GG(H2RU,76pPAt%H,r_/0kRb-*EV/).:^g:V=m^X0^4!T;cR\-G-^V9Kh:BY#1eo%FGLsMQ + cG0ZJFDeF]]A6#c\-H!]4a(+P*a?k9h_e4m9>5W,rSRMXJY,%cc/(YfBks]pK>f7'E[9R'LWHL'Whj0g7pWGp[O'tOk,O1TDOH<9+1iL/AO89:rY4E+\/8V= + d.+nF<7f[+>r+/@N!n@//lMVpRu#8;#2kc#;C9*E-V\`o'hRUc-Ui`%c[h(>mRZo#r%VNE1%$:SI+DM#RtJT#@RoMW + $G3A$LkG2E4H@\]aO>F1bb`b$qh!Z&FJu2Bo[0B0\Ho>h$rl4%PZriXO>@4V[d:A$S_(ZYk + J[4r=AE!&2==t0ZK@&,7nD)%oEoN;%XDF*>.fb&htZ;OUCps-;"jf&5b4rnMq8f4VR?O'IS + MGY721C9bd+p'er]'EEO$];#-mGq=.)md:jB$D&2Y](GU%KDAa3"*tZfB(QjCgEJYO;N>V2 + J)(@9SOG+Q?1kC7D)@]S*Y(Dt#em?\V0Ti0'&ZRHp?rSE1)^9a2X9TWjboH9$*ANTmOUiI" + cK4&H*Xp'VL%P6Dh]>AYZ%)i>@Y5>'/i\]FkgA3/EXFoEg\A^S;'no(c%[=V"F?.DC)Th!s9,(&sOY^ZD\ + u^T10`VDdY[?]..jK/Mbj.A]ZDW)(gIp09U-!Eo^QTcFWT7^7sdCC%>]7oZm\8.nKsF`L.r + eo"VCY:k`fb72l7;Ea[>S1,C43F!tWtI.4D118?><^sH5io!Cg:1XOLmBsAdIO#)tg%;9e> + &-DNZ/f%*;Zu/??k!\9o*agc]2`#S8F*L:*/fq9/1Ga>3dX=%?+=@h[mS\YeNhnYNOZ>3]K + Su]fi_B1,JFFniY-PV_l9j6=t!]A0i + Y-[bl06+RJ,S$imtMeC[\14O?YHJdd`?0f`,\68W7CFD44>$J%\#+`qQboAh3>1oY2n/JIJ + *e:)"M5jk?db-ZmHafprX;Z*7AaAdLVFK%m>X\.SM-.HuQ'&Q=`\Oa*!i"3/f1jaF9@W&uFQlQ$\hupfZVZ8p[-]^BVCkjI]4n,q0uP\$^h,"ETT8=):i=]ZY + 4m#A7PnOB;e&E6qbm)A;`-BT'HpCaM,`faqCKW^+,>sSD;H740F`CQlSQYP72tMYtQ(TJSK2n2$bRM + u#'E0bPY$3Uq8Q-'iKn.\gO&F:g=V#"Jj6X]T9>nuO2Fr=_nf"9"K(\'(ce)OMb&hbW["Di'^/3O!-;^,6u;5/&;No=?^ + &man[KHlB7/ONE7=].adlkV$^G%kQn5@.B,,n!stb`PVc9X49"Akh\HFC$9e86W8Von?f>E + ]V>W6VK3/m*::9`F+9cojCgACGrS9E8=/RV'Ztfdo>=Xnr7I.m)7@XZ%=CHZ^)n67Cp$tOf2Yh:"r<[XeDtZ+qJh3q1;OZ0cWCH\*68*<&SgO0f>&s'c1;Pc-]$A + ME0biKTWJais"&1]XF>lX1DAR7N8KXlpi/p4YQVVb5?$5mL]2q^M,&WGUQP+LZ>^'n+GBnD + AI%F?65*9K%iadk2YnP`J@i'uIGF<`cS;%],C_r^RilH+\SJ!\(7$jfuGI`(0]NUY7Hf@.J + ((CrOaS_CDI5f])GM+q++M8I9G^%nkGNjRcm=+g!+]c8#Pdu9&rI=SCJ2d^UQhPf.#CuR]J + N+BqF`Ddg)1hQ+JiG'.F,,>!.>%=LK/b`@ERf@lF`oM??Ijuh\3^s57`].,]6J7,@TK170Y3pi[qXMN\m4K:Ge#+WEGP>6BnGc(rip"b?G/B+un$ + Q+W69*>=DZQ0LfIEfXm6U%?U,kJ@NKt;9;(EdM"s^^;W:Ij*.;`nTH)g_GX"TC/eE!Z/ + "Q!%=TA!HlZ@OqQWH1+dP8_,TXu!.:Qm0,bO#kUd>-4i/mB6I%P)XSH[KXRk`q^[udT";O"41 + bJ:4%HQEDe7FrMRtgUHYKpi6[e(/PaDngCu^`&m%Thb[<_/>].U'EH\K&MRplo<(Nm5lP:p + ,*[bIXiH`3p4pK&:CV\Bf@R;Z_a30X!g\[GkW]48JMX1\>W]dRs5oVgT0]l;sCAhNKpl7!] + RjgH#4^0.,-]A0Lbi#u=s,!5+r@MccUaf0Xi]j);gHl/M;7>A3*l+n5%!T?&LQ]:glRY:iY + `-7pp>3b.)N^ac!S$jPh56Q/5T;auj>UdPE=i3.u`>gsb>Yem&jrHQP!#l;WR+6+[Q6?%#49PQUiNS+2lffbVRI@8d%S_&IL4rH%H.3tiBA"8IMq+Y*T?u@i]\[JIOX9j/`Qaaj$#?Q_Q[\3nfT%~>Q +Q +showpage +%%Trailer +count op_count sub {pop} repeat +countdictstack dict_count sub {end} repeat +cairo_eps_state restore +%%EOF diff -r 9b9a2497757d -r eb146c5c05a8 0__Papers/PRT/PRT__formal_def/figures/Time_in_VMS_1.svg --- /dev/null Thu Jan 01 00:00:00 1970 +0000 +++ b/0__Papers/PRT/PRT__formal_def/figures/Time_in_VMS_1.svg Sat Aug 03 19:24:22 2013 -0700 @@ -0,0 +1,407 @@ + + + + + + + + + + + + + + + + image/svg+xml + + + + + + + + + + + Suspend Point 1 + + + + Suspend Point 2 + + Program Time 1 + TraceSegment + + + + Suspend Point 1 + + + + Suspend Point 2 + + Program Time 2 + TraceSegment + + + + Tie Point + + VirtualTime + + + + + + + Suspend 1,1start + + + + Suspend2, 1 start + + + + + + + diff -r 9b9a2497757d -r eb146c5c05a8 0__Papers/PRT/PRT__formal_def/figures/Time_layers.eps --- /dev/null Thu Jan 01 00:00:00 1970 +0000 +++ b/0__Papers/PRT/PRT__formal_def/figures/Time_layers.eps Sat Aug 03 19:24:22 2013 -0700 @@ -0,0 +1,869 @@ +%!PS-Adobe-3.0 EPSF-3.0 +%%Creator: cairo 1.8.6 (http://cairographics.org) +%%CreationDate: Sat Nov 20 00:16:39 2010 +%%Pages: 1 +%%BoundingBox: 0 0 206 75 +%%DocumentData: Clean7Bit +%%LanguageLevel: 2 +%%EndComments +%%BeginProlog +/cairo_eps_state save def +/dict_count countdictstack def +/op_count count 1 sub def +userdict begin +/q { gsave } bind def +/Q { grestore } bind def +/cm { 6 array astore concat } bind def +/w { setlinewidth } bind def +/J { setlinecap } bind def +/j { setlinejoin } bind def +/M { setmiterlimit } bind def +/d { setdash } bind def +/m { moveto } bind def +/l { lineto } bind def +/c { curveto } bind def +/h { closepath } bind def +/re { exch dup neg 3 1 roll 5 3 roll moveto 0 rlineto + 0 exch rlineto 0 rlineto closepath } bind def +/S { stroke } bind def +/f { fill } bind def +/f* { eofill } bind def +/B { fill stroke } bind def +/B* { eofill stroke } bind def +/n { newpath } bind def +/W { clip } bind def +/W* { eoclip } bind def +/BT { } bind def +/ET { } bind def +/pdfmark where { pop globaldict /?pdfmark /exec load put } + { globaldict begin /?pdfmark /pop load def /pdfmark + /cleartomark load def end } ifelse +/BDC { mark 3 1 roll /BDC pdfmark } bind def +/EMC { mark /EMC pdfmark } bind def +/cairo_store_point { /cairo_point_y exch def /cairo_point_x exch def } def +/Tj { show currentpoint cairo_store_point } bind def +/TJ { + { + dup + type /stringtype eq + { show } { -0.001 mul 0 cairo_font_matrix dtransform rmoveto } ifelse + } forall + currentpoint cairo_store_point +} bind def +/cairo_selectfont { cairo_font_matrix aload pop pop pop 0 0 6 array astore + cairo_font exch selectfont cairo_point_x cairo_point_y moveto } bind def +/Tf { pop /cairo_font exch def /cairo_font_matrix where + { pop cairo_selectfont } if } bind def +/Td { matrix translate cairo_font_matrix matrix concatmatrix dup + /cairo_font_matrix exch def dup 4 get exch 5 get cairo_store_point + /cairo_font where { pop cairo_selectfont } if } bind def +/Tm { 2 copy 8 2 roll 6 array astore /cairo_font_matrix exch def + cairo_store_point /cairo_font where { pop cairo_selectfont } if } bind def +/g { setgray } bind def +/rg { setrgbcolor } bind def +/d1 { setcachedevice } bind def +%%EndProlog +11 dict begin +/FontType 42 def +/FontName /f-0-0 def +/PaintType 0 def +/FontMatrix [ 1 0 0 1 0 0 ] def +/FontBBox [ 0 0 0 0 ] def +/Encoding 256 array def +0 1 255 { Encoding exch /.notdef put } for +Encoding 1 /uni0050 put +Encoding 2 /uni0072 put +Encoding 3 /uni006F put +Encoding 4 /uni0067 put +Encoding 5 /uni0061 put +Encoding 6 /uni006D put +Encoding 7 /uni0020 put +Encoding 8 /uni0054 put +Encoding 9 /uni0069 put +Encoding 10 /uni0065 put +Encoding 11 /uni0068 put +Encoding 12 /uni0079 put +Encoding 13 /uni0073 put +Encoding 14 /uni0063 put +Encoding 15 /uni006C put +Encoding 16 /uni0053 put +Encoding 17 /uni0064 put +Encoding 18 /uni0075 put +/CharStrings 19 dict dup begin +/.notdef 0 def +/uni0050 1 def +/uni0072 2 def +/uni006F 3 def +/uni0067 4 def +/uni0061 5 def +/uni006D 6 def +/uni0020 7 def +/uni0054 8 def +/uni0069 9 def +/uni0065 10 def +/uni0068 11 def +/uni0079 12 def +/uni0073 13 def +/uni0063 14 def +/uni006C 15 def +/uni0053 16 def +/uni0064 17 def +/uni0075 18 def +end readonly def +/sfnts [ +<00010000000a008000030020636d61700076f10b00001a9000000064637674207d0742a80000 +1af4000002706670676d49d7df9200001d640000060a676c7966e942e463000000ac000019e4 +68656164d5ceeae00000237000000036686865610f7e06ae000023a800000024686d74784af9 +067a000023cc0000004c6c6f63613a8c41da00002418000000286d617870037802c900002440 +0000002070726570292ded1600002460000004ad00020080015e0380045e0003000700264016 +059c039d049c070017003700030000079c019d049c00002ffdfded012f5f5dfdfded31301311 +211125211121800300fd800200fe00015e0300fd00800200000200960000042605c3000a0013 +0108b9000cffea40170c0c024b0b180c0c024b670701021045070b4401440207b8ffd8b41010 +024b07b8ffdab40b0b024b07b8ffdab40d0d024b07b8fff0b40d0d064b07b8fff4400e0e0e06 +4b07471507022702020002b8ffeab41313024b02b8fff4b41010024b02b8fffa400b0f0f024b +02040b0b024b02b8fffeb40d0d024b02b8fff0b40e0e064b02b8fffeb40c0c064b02b8ffe840 +2d1010064b0247143a124a125a1203350e450e550e0303050b120c000e180c0c024b0e160d0d +024b0e4909090212b8ffe8400b0c0c024b12490502080502003f3f10ed2b11392fed2b2b3332 +113311335d5d0110e62b2b2b2b2b2b2b2b5f5d10e62b2b2b2b2b10eded10ed5f5d3130002b2b +0111231136332011102122031116332011102122015ec8e32f027efdcc22727f070174fe7328 +0234fdcc05b90afe55fe1202dbfde30a0125010c0000000100960000031c0443000e00af401e +0a400b0d024b081018102810c81004c70ed70e020e06094d064d68070107b8ffecb41313024b +07b8ffeeb41010024b07b8fff240110f0f024b07040b0b024b07040c0c024b07b8ffeeb40f0f +064b07b8fffcb40c0c064b07b8fff2b41010064b07b8fffc40250e0e064b070f170a270a370a +470a570a670a0600050a400e0e064b0a02520c0806070a0c07003f3f3f10edcd2b325f5d0110 +d62b2b2b2b2b2b2b2b2b5deded10c65d5d3130002b01262322061511231133153633321702cd +3e3f6597bebe68cd336003782bba83fd9a042fabbf1200020041ffec040a0443000b0015013c +402517401010024b17400b0c024bb7050101381701114e17063706470667060406041010024b +06b8ffdeb40f0f024b06b8fffcb40b0b024b06b8ffe4b40c0c024b06b8ffd4b40d0d024b06b8 +ffeab40e0e064b06b8ffe0b40c0c064b06b8ffe440760d0d064b060c4e87009700a700b700c7 +00e700063800480058006800040000101010024b000e0f0f024b00200b0b024b00200c0c024b +00160d0d024b000c0e0e064b00100c0c064b000c0d0d064b00166a030165090103670e016813 +0102450e550e650e034a135a136a13030e100f0f024b0e520913b8fff040160f0f024b135203 +09180f0f024b09180f0f064b090b03b8ffe8b40f0f024b03b8ffe8b50f0f064b0307003f2b2b +3f2b2b10ed2b10ed2b5d5d5f5d5d5f5d5d0110d62b2b2b2b2b2b2b2b5f5d5dfdd42b2b2b2b2b +2b2b2b5ded5d5f5d31302b2b1334003332121110002322001310213236351021220641010bda +e6fefefce0e5ff00c8011d8597fee4829b021af80131fedbfefcfefdfed5012e0100fe6dd8bb +018ed40000020050fe5c03c804740030003c0160402c48195819681978190400272b372b0202 +65017501020320101c12064e282b382b482b582b682b782b882b072bb8ffeab40e0e064b2bb8 +fff0400f0d0d064b2b193a4e1c0e1010024b1cb8fff440860c0c024b1c120d0d024b1c3e0023 +4e0d344e12060e0e064b120c0f0f024b12120b0c024b12120d0d024b123d17010188199819a8 +19b8190488189818a818b81804280c380c02006701770102026a317a31026537753702031020 +37281a171f181537180f0f024b37521f40090a064b1f9708a708b70803970ba70bb70b030028 +530825530b01b8ffc0b41114024b01b8ffc0b40b0c024b01b8ffc0b41114064b01b8ffc04009 +0c0c064b0103522e31b8ffe8400d0f0f024b3152152e0e0b061507003f3f3f10ed2b10fdc62b +2b2b2b10edd4fd5f5d5dd42bed2b10c6123939111239395f5d5d5f5d5f5d5d5d5d0110d62b2b +2b2bedd4edc610d62b2b2bedc6d42b2b5ded111239395f5d5f5d5f5d31301337163332363534 +2322062322353436372611343633321737170716151406070706061514333236333216151404 +2322260122061514163332363534266067a68c8195bc20a82fe46b4fe2eaac9e595f7c7249ca +a49d1c5e622bb62c9eb1fef7cb68e6014d637d796765727bfedb986f59428220ac3556136a01 +06a8e0417275565f99a2dc101003251e291f978694b64a05048c6470938f74648c0000020050 +ffec03e40443001b002501d3b627401010024b25b8ffecb40b0c024b25b8ffee40490d0d064b +071317130201672077200202280f480f0200b70fc70fd70fe70f04010025150f053718471857 +1867187718871897180718254d0a4d881501150c1313024b150c1010024b15b8fff8b40f0f02 +4b15b8fff040110c0c024b151e0d0d024b150c0e0e064b15b8fff040440f0f064b150c0d0d06 +4b1527214e38050100050c0f0f024b05160b0b024b05100c0c024b05120d0d024b050c0e0e06 +4b050c0c0c064b050c0d0d064b05263a0301032500b8ffc0b40d10024b00b8ffc040320d0f06 +4b480058006800780004000218191c520a080e52080f180f280f380f480f580f980fa80fb80f +c80fd80fe80f0c000fb8ffc0b41317024b0fb8ffc040240d0d024b0f124a1e5a1e02031e52a8 +08b80802580801006a087a08020347085708020008b8ffc0b41414024b08b8ffc0b41313024b +08b8ffe8b41010024b08b8ffe8b40f0f024b08b8ffc040131313064b08080c2352020c521219 +0b020b1207003f3f3f10ed10ed11392f2b2b2b2b2b5f5d5f5d5f5d5ded5f5d10dd2b2b5f5ded +10d5ed10cd10dd5d2b2bcd5f5d0110d62b2b2b2b2b2b2b5f5ded10d62b2b2b2b2b2b2b2b71ed +edc65d10c41112395f5d5f5d5f5d3130005f5d2b2b012b250623222635342433321710232207 +273636333216151114171522260326232206151433323702e472eb7eb9011ddd3c4ce8b26050 +36bf57e9d35474732b5a2490b6c5906f7b8fb788a3e11a0104609f2c3fd4e7fe808d2f5f4201 +df149465a789000100870000061d0443001f01b8403821400f10024b21400c0c024b071c0101 +08216821022721372157219721c72105004d371f011f101313024b1f081010024b1f1c0f0f02 +4b1fb8ffec40170b0b024b1f180c0c024b1f040d0d024b1f0e0f0f064b1fb8ffed400b0c0c06 +4b1f101010064b1fb8fffe401d0e0e064b1f084d37070107101313024b07021010024b071a0f +0f024b07b8ffec40170b0b024b07180c0c024b07040d0d024b07080f0f064b07b8ffedb40c0c +064b07b8fffe40180d0d064b07061010064b07104d071117112711e711040011b8fff8b41010 +064b11b8fffa400b0e0e064b11100909024b11b8fff4400b1313024b11040d0d024b11b8fff4 +b41010024b11b8fff440110f0f024b110a0b0b024b11080c0c024b11b8fff440530f0f064b11 +100c0c064b1120171c271c371c030118400d0d024b18401010064b182c0d0d064b4718571867 +187718040018400e0e064b18400e10024b18160f141603521b0c52161f0a080a110a1b071607 +1206003f3f3f3f3f3f10ed10ed10ddcd10cd2b2b5f5d2b2b2b5f5d0110d62b2b2b2b2b2b2b2b +2b2b2b5f5dfdd42b2b2b2b2b2b2b2b2b2b5dedd42b2b2b2b2b2b2b2b2b2b5ded5d5d3130005f +5d012b2b2111342322060711231134262322060711231133173633321736363332161511055f +db457816be776239811bbe7c3f6ea5e65c20ae5ca6b602a6fd5536fce802f94f5b5835fcea04 +2f7c908f3d52c5b2fd34000100120000049305b900070080401e270701280401079301042c13 +13024b049301442702010002081010064b02b8ffe440111313024b02180f0f024b02100b0b02 +4b02b8fff6b40d0d024b02b8ffe640200e0e064b02120f0f064b02010c0c064b02220d0d064b +02074804480502080502003f3f10eded012f2b2b2b2b2b2b2b2b2b5f5dede62b10e65d5d3130 +011123112135211502acc8fe2e04810505fafb0505b4b400000000020050000001c105c4000b +001100d9b613400f0f024b13b8ffc0b60d0d024b097b03b8fff4b40e0e064b03b8fff8b40f0f +024b03b8fffab40c0c024b03b8fff940200c0c064b03110e0c4d7711010011041313024b1102 +1010024b110e0f0f024b11b8ffeeb40b0b024b11b8ffecb40c0c024b11b8ffe6400b0d0d024b +110e0f0f064b11b8fff8400b0c0c064b11120d0d064b11b8ffd640100e0e064b11081111064b +11130d511000b8ffc040120f0f024b007c06400f0f024b06100c0a1006003f3f10d62bed2b10 +ed0110d62b2b2b2b2b2b2b2b2b2b2b5f5dfdc610d42b2b2b2bed3130012b2b01321615140623 +2226353436031123352111014b314545313045443793015105c44530314545313144fa3c038f +a0fbd100000000020041ffec041c04430019002201ff408724400b0b024b58170103b807018a +079a07aa07ba07ca07da0706025705016808780888089808a808052808380848085808680878 +0888089808a808b808c808d8080c00571877180208221010024b08180f0f024b08180c0c024b +082c0d0d024b08100c0c064b08100d0d064b081f4e471e0102171837184718671887189718a7 +18b718c7180918b8ffe0b40e0e064b18b8ffdeb41010024b18b8ffdcb40f0f024b18b8ffe2b4 +0c0c024b18b8ffd4b40d0d024b18b8ffe4b40c0c064b18b8ffe4406b0d0d064b18011e4e014e +87100138104810581068100410100e0e064b10101010024b10100f0f024b101c0b0c024b1016 +0d0d024b100c0c0c064b100c0d0d064b102387079707a7070300270537054705570504020752 +2a083a084a08030357086708770803070817080208b8ffc0b40b0c024b08b8ffd4b40d0d064b +08b8ffc040350d0d024b080c1e50470157016701a701b701050001400f0f024b01400d0d024b +01400f0f064b010105581a011a5214100f0f024b14b8ffe8b40d0d024b14b8ffe840200e0e06 +4b140c0f0f064b14671401024a145a140205100c0c024b05520c0b1407003f3fed2b5d5f5d10 +2b2b2b2bed5d11392f2b2b2b5f5ded10d52b2b2b5d715f5ded5f5d5f710110d62b2b2b2b2b2b +2b5d5deded10dd2b2b2b2b2b2b2b5d5f5dedc42b2b2b2b2b2b5d5f5d715d5f5d5d5f5d313001 +2b0121141716333237170607062322272635103736333217161514012207060721342726040d +fcfc675b8fa36d502c5b728cca8d9da190c5e5827efe247f56520b0251484f0205bc65585f89 +2c202a8997ff0109a08f817ccd3f0169524e74734d5400010087000003d905e60013010d400d +15400b0b024b07101710020100b8fff8b60c0c064b004d13b8ffecb41010064b13b8fff8b413 +13024b13b8fff640171010024b130a0f0f024b131a0b0b024b13080c0c024b13b8ffd6b40e0e +064b13b8fff6400b0d0d024b130e0f0f064b13b8fff840130d0d064b13080b4d084d07091709 +2709030009b8fff2b41010064b09b8fff4b41313024b09b8fff4400b1010024b09040d0d024b +09b8fff440110f0f024b090a0b0b024b09080c0c024b09b8fff4b40e0e064b09b8fffa400c0f +0f064b09146a047a040204b8ffe8400f0f0f024b04520f130a090a0f070a00003f3f3f3f10ed +2b5d0110d62b2b2b2b2b2b2b2b2b5f5deded10d42b2b2b2b2b2b2b2b2b2bed2b3130005f5d01 +2b2111342623220607112311331136363332161511031b766b458b25bebe26a95aaac102a178 +8a5136fce405e6fdd33b4fe0c2fd5f000001000cfe5c03e6042f000f0105b9000dffe0b31010 +024bb1020243545840120d0b0452030e0e060b06030d0f0e0d0b0c0db8fff4b70b0b024b0d0d +11101112392f2bddcd10ddcd10c4003f3f3fed123931301bb1060243545840150d0b0452030e +0e060b06030d0f0e0d0b0c0d0d11101112392fddcd10ddcd10c4003f3f3fed123931301b4058 +4c0801380f0127000103270401004701010237010103081128110200380d480d02020d0d0c45 +07010707040e4f0f110c4f450b0103040b10980da80d020167060102270d470d570d670d770d +05000d0f0452030e0f060b06003f3f3fed11395f5d5f5d5f5d0110d6c65f5ded10d6ed11392f +5d11393d2f5f5d5f5d5f5d5f5d5f5d5f5d5d5d31305959002b05060623353236353426270133 +010133022025ed9277aa3e31fedec2013b011bc2b66688aa6f5058ab7e02e9fcc4033c000001 +0041ffec02fc0443002100e7402b23400b0b024b081f181f02070e170e022823482388230300 +3a0c01351d0103c8110111054e671d771d021db8ffeeb40e0e064b1db8ffe0405a0d0d024b1d +1700174e480c01970ca70cb70ce70c04000c040e0e064b0c22e81901271b0101280701270f01 +28200102651a751a020307191a0314034812581268127812c81205120f370147015701670177 +01b701c70107000103b8ffe040141113064b03522014181113064b14520f200b0f07003f3f10 +ed2b10ed2bc55f5d10c55d111217395f5d5f5d5d5d5f5d5d0110d62b5f5d5dedc610d42b2b5d +edc45d5f5d5d5f5d3130005d5d012b37371633323534272e0335343633321707262322061514 +17171616151406232241439f61b0aa835b4321c09b75b2367172445d75887d72cab3a940b468 +946a4c3c3e4f593384944ab05a403167353e39926e90a300000000010041ffec03b504430017 +0119401e450501a1010103281938190200870d970da70d030200070d870d970d030db8fff4b4 +1010024b0db8ffeab40f0f024b0db8ffeab40b0c024b0db8ffe840610d0d024b0d074e381248 +12028712a712b712c712e712050012101010024b12180f0f024b12200b0c024b12180d0d024b +12060e0e064b120c0e0e064b12120c0c064b12100d0d064b1218250a350a450a032a043a044a +0403030c52070d170d020db8ffc040160b0b024b0d0f015208001800020000400b0b024b0004 +b8ffe8b40c0c024b04b8ffe840190d0d024b0452150a180c0c024b0a180d0d024b0a520f0b15 +07003f3fed2b2b10ed2b2bdd2b5f5ded10dd2b5ded5f5d5d0110d62b2b2b2b2b2b2b2b5f5d5d +fdd42b2b2b2b5d3c5f5d5f5d5f5d5d3130010726262322061514163332371706232200351000 +21321603af5e1d93479bb6baa580824b99e2dbfee20129010253c203d8861d34d9bdbcc563a0 +630126fb01000136460000010096ffec020705e6000800c7b9000affc0b41313024b0ab8ffc0 +b41010024b0ab8ffc0402a0c0c024b070a170a270a370a470a570a670a770a08070617062706 +0306024d070117012701d701040001b8ffecb41313024b01b8ffeeb41010024b01b8fff24011 +0f0f024b01040b0b024b01040c0c024b01b8ffcc40170e0e064b01180f0f064b01130c0c064b +01160d0d064b01b8ffec401b0b0b064b0109b705c70502010a081a082a083a08040652070b01 +00003f3fed5d5f5d0110d62b2b2b2b2b2b2b2b2b2b5f5dfdc65d5d3130012b2b2b1311331114 +1633152096be6350fe8f012f04b7fb695663aa00000000010050ffe7038805d2002601ccb102 +02435458401907221a0e180b0b024b0e120c0c024b0e22070e1a0425131714b8ffc040120c0c +024b1411000401251749110304492509003fed3fed10cd123910cd2b1239121739012f2b2bcd +2fcd31301bb106024354584086082401071001002520452065207520042a0b01034828a82802 +68130113074507223722672203221a001a45380e01870e01000e2777040102351e651e751e03 +351f451f651f751f040a0c3a0c4a0c6a0c7a0c0533220103380e010a0b1f1e04254814581468 +14781404141137014701570167017701a701b70107000125174911044925091103003f3fed10 +ed10cd5f5d10cd5d1217395d5f5d5d5d5d5f5d0110d65f5d5dedc410d45dedc45d5d3130005f +5d5d5f5d5d1b4086082401071001002520452065207520042a0b01034828a828026813011307 +4507223722672203221a001a45380e01870e01000e2777040102351e651e751e03351f451f65 +1f751f040a0c3a0c4a0c6a0c7a0c0533220103380e010a0b1f1e042548145814681478140414 +1137014701570167017701a701b70107000125174911044925091103003f3fed10ed10cd5f5d +10cd5d1217395d5f5d5d5d5d5f5d0110d65f5d5dedc410d45dedc45d5d3130005f5d5d5f5d5d +5959373716163332363534262727262635343633321707262623220615141616171716161514 +042322544938a742758e4f9f769677e8b6f35f3b28a44666752a4b74789679fef7dec343b829 +3780634a7f4b3746c087a4d84fae1d36745b385c3e383947c598a5e60002004bffed03ec05e6 +000e0019011e40161b400b0b024b004d0d190c4d470d010d201313024b0db8ffeab41010024b +0db8fff6400b0f0f024b0d080b0b024b0db8fff6b40c0c024b0db8ffe4400b0d0d024b0d0c0f +0f064b0db8ffe2b40c0c064b0db8fff240660d0d064b0d140c0c0c064b144e87060138064806 +020006080f0f024b061a0b0b024b061a0c0c024b06120d0d024b060c0e0e064b06100c0c064b +060c0d0d064b061a251635164516032a113a114a110303580368030216180b0c024b16100f0f +024b16520311b8ffe8400e0b0c024b115209480901020e0a03b8fff0b60f0f024b030b09b8ff +eeb70d0d024b09070d00003f3f2b3f2b3f5f5d10ed2b10ed2b2b5d5f5d5d0110d62b2b2b2b2b +2b2b5f5d5dfd2bd42b2b2b2b2b2b2b2b2b5dfd3c10ed3130012b253506232202353400333217 +1133110326232206151021323637032e63bdc9fa0120c7a656bebe487d99bd01602d7e10014f +630120f0f101554e01f1fa1b03366ce4b0fe7d39200000000001007dffec03e3042f001200fb +402714400b0b024b7714010a4d074d070801170847087708a708048708b708e70803080c1010 +064b08b8fffab40e0e064b08b8ffecb41313024b08b8ffec400b1010024b08160b0b024b08b8 +ffeeb40d0d024b08b8ffccb40e0e064b08b8fff0b40c0c064b08b8fff440150d0d064b08004d +e812f81202071217122712030012b8fff8b41313024b12b8fffab41010024b12b8fff640230f +0f024b120c0b0b024b120c0c0c024b12080d0d024b12040c0c064b12040d0d064b12b8fffa40 +110e0e064b121303520e090a0e0b08061206003f3f3f3f10ed0110d62b2b2b2b2b2b2b2b2b5f +5d5dfdd42b2b2b2b2b2b2b2b2b5d7172eded5d3130012b011114333236371133112335060623 +22263511013bd75e9c19bebe20c15cb0bb042ffd55f86c4702f0fbd1943f69caba02bf000000 +0002000300000000001400010000000000340004002000000004000400010000f012ffff0000 +f000ffff10000001000000000006003000000000001300000001000200030004000500060007 +00080009000a000b000c000d000e000f00100011001205e6000005b9001905b90014042f0014 +0000ffe70000ffec0000ffecfe5c000005c30000fe5400000338000005d300000253000005c8 +000a000000000000000000000000000000000000000000000000000000000000000000000000 +0000000000000000000000000000000000000000000000000000000000000000000000000000 +00000000000000c800cd00cd009600b400b400000000000000be00c800c8008c00a0009b0096 +0000000000be00c800c8000000aa00aa000000000064007d0082008c009600a00064007d0082 +008c009b00d20064007d0082008c009600a002300136011801a401d600460218012c01c20000 +01d600eb00eb01d1017f0154011301450168012c008d02350159033f0505012c00b4006e0136 +015e01cc01cc04d8006e006e01d600d2005f01f4012c007802d00190037f00800280006e00b4 +000000a5fea2003200b9008c0000000000000000000000000000000000000000000000000000 +0000000000000000000000000000000000000000000000000000000000000000000000000000 +0000080005e6000005b9001905b90014042f00140000ffe70000ffec0000ffecfe5c00000000 +0000000000000338000000000000025300000000000000000000000000000000000000000000 +0000000000000000000000000000000000000000000000000000000000000000000000000000 +000000000000000000000000000000000000000000000000000000c800cd00cd009600b400b4 +00000000000000be00c800c8008c00a0009b00960000000000be00c800c8000000aa00aa0000 +00000064007d0082008c009600a00064007d0082008c009b00d20064007d0082008c009600a0 +4036544b214a494847464544434241403f3e3d3c3b3a39383736352f2e2d2c2826252423221f +181411100f0d0b0a090807060504030201002c4523466020b02660b004262348482d2c452346 +236120b02661b004262348482d2c45234660b0206120b04660b004262348482d2c4523462361 +b0206020b02661b02061b004262348482d2c45234660b0406120b06660b004262348482d2c45 +23462361b0406020b02661b04061b004262348482d2c0110203c003c2d2c20452320b0cd4423 +20b8015a51582320b08d44235920b0ed51582320b04d44235920b0042651582320b00d442359 +21212d2c20204518684420b001602045b04676688a4560442d2c01b10b0a432343650a2d2c00 +b10a0b4323430b2d2c00b0282370b101283e01b0282370b10228453ab10200080d2d2c2045b0 +0325456164b050515845441b2121592d2c2045b0004360442d2c01b00643b00743650a2d2c20 +69b04061b0008b20b12cc08a8cb8100062602b0c642364615c58b00361592d2c8a03458a8a87 +b0112bb0292344b0297ae4182d2c4565b02c234445b02b23442d2c4b525845441b2121592d2c +01b005251023208af500b0016023edec2d2c01b005251023208af500b0016123edec2d2c01b0 +062510f500edec2d2c20b001600110203c003c2d2c20b001610110203c003c2d2c00b00743b0 +06430b2d2c21210c6423648bb84000622d2c21b08051580c6423648bb82000621bb200402f2b +59b002602d2c21b0c051580c6423648bb81555621bb200802f2b59b002602d2c0c6423648bb8 +4000626023212d2c4523456023456023456023766818b08062202d2cb00426b00426b00425b0 +042545234520b003266062636820b0032661658a2344442d2c2045b0005458b040442045b040 +61441b2121592d2c45b1302f4523456160b0016069442d2c4b5158b02f2370b01423421b2121 +592d2c4b515820b0032545695358441b2121591b2121592d2c45b01443b0006063b001606944 +2d2cb02f45442d2c452320458a60442d2c45234560442d2c4b235158b90033ffe0b134201bb3 +330034005944442d2cb0164358b00326458a586466b01f601b64b020606620581b21b04059b0 +01615923586559b02923442310b029e01b2121212121592d2cb0164358b004254564b0206066 +20581b21b04059b0016123586559b0292344b00425b00725082058021b0359b0052510b00425 +2046b0042523423cb0072510b006252046b00425b0016023423c2058011b0059b0052510b004 +25b029e0b0072510b00625b029e0b00425b00725082058021b0359b00425b003254348b00625 +b00325b0016043481b2159212121212121212d2cb0164358b004254564b020606620581b21b0 +4059b0016123581b6559b0292344b00525b00825082058021b0359b0042510b005252046b004 +2523423cb00425b0072508b0072510b006252046b00425b0016023423c2058011b0059b00425 +10b00525b029e0b02920456544b0072510b00625b029e0b00525b00825082058021b0359b005 +25b003254348b00425b0072508b00625b00325b0016043481b2159212121212121212d2c02b0 +0425202046b004252342b0052508b003254548212121212d2c02b0032520b0042508b0022543 +482121212d2c452320451820b00050205823652359236820b040505821b04059235865598a60 +442d2c4b53234b515a5820458a60441b2121592d2c208a08234b538a4b515a5823381b212159 +2d2c00208a49b0005158b04023208a3812341b2121592d2c462346608a8a462320468a608a61 +b8ff8062232010238ab14b4b8a70456020b0005058b00161b8ffba8b1bb0468c59b010606801 +3a2d2c208a2349648a2353583c1b21592d2c4b505845441b2121592d2cb0024354584b53234b +515a58381b2121591b21212121592d2cb1020042b123018851b1400188535a58b91000002088 +5458b202010243604259b12401885158b920000040885458b2020202436042b12401885458b2 +022002436042004b014b5258b2020802436042591bb940000080885458b202040243604259b9 +4000008063b80100885458b202080243604259b94000010063b80200885458b2021002436042 +59b94000020063b80400885458b202400243604259595959592d00000001000000050000093f +e5da5f0f3cf5001b080000000000ad61b71900000000c142e956ff50fde708a8078b0000000a +0001000000000000000100000783fe39000008e9ff50ff7808a8000100000000000000000000 +0000000000130400008004760096031c0096044b0041040400500434005006a4008702690000 +04a5001202480050045d0041045f008703f2000c033d004103f60041025c009603d900500475 +004b045f007d0000002800d20144020c031204340540054005940622075a080208a4094a0a00 +0a780b980c540cf2000100000013004d0007004b000500020010002f0055000002f001ff0003 +0001400a54bfa50140a5111546a4b8010cb2321fa1b8011540b21f1f6fc731216ec731216dc7 +31216cc731216bc731216ac7312169c7312168c7312167c7312166c7312165c7312164c73121 +63c7312162c7312161c7312160c731215fc731215ec731215dc731215cc731215bc731215ac7 +312159c7312158c7312157c7312156c7312155c7312154c7312153c7312152c7312151c73121 +50c731214fc731214ec731214dc731214cc731214bc731214ac7312149c7312148c7312147c7 +312146c7312145c7312144c73121b80137b26f0821b80136b26e0821b80135b26d0821b80134 +b26c0821b80133b26b0821b80132b26a0821b80131b2690821b80130b2680821b8012fb26708 +21b8012eb2660821b8012db2650821b8012cb2640821b8012bb2630821b8012ab2620821b801 +29b2610821b80128b2600821b80127b25f0821b80126b25e0821b80125b25d0821b80124b25c +0821b80123b25b0821b80122b25a0821b80121b2590821b80120b2580821b8011fb2570821b8 +011eb2560821b8011db2550821b8011cb2540821b8011bb2530821b8011ab2520821b80119b2 +510821b80118b2500821b80117b24f0821b80116b24e0821b80115b24d0821b80114b24c0821 +b80113b24b0821b80112b24a0821b80111b2490821b80110b2480821b8010fb2470821b8010e +b2460821b8010db2450821b8010c40ff4408216957311f5857311f5657311f5152311f464431 +1f4544311f4f4e311f4d4e311f2097309740975097043088010f8c018f849f84af84bf84cf84 +058f689f68af680360697069028f5b018f5a017057018f509f50af50bf50cf50058f519f51af +51038f529f52af52033f7c4f7c02507b607b707b03704e01708f01308f608f708f03008e0100 +8e01408e708e02008e308e408e508e608e708e06107040700260740160730170440100282800 +000012110840370f3fce16010fa21fa20218c7312114c731210ec731210dc731210cc731210b +c731210ac7312109c7312108c7312107c7312106c7312105c7312104c7312103c7312102c731 +2101c73121407c00c73121e0180821dc140821d60e0821d50d0821d40c0821d30b0821d20a08 +21d1090821d0080821cf070821ce060821cd050821cc040821cb030821ca020821c9010821c8 +000821230e45220c45210a452008451f06451e04451d02451c00451a08180816081408120810 +080e080c080a08080806080408020800084bb807ff524bb008505b58b101018e59b0124b004b +5442b9000101ff858d2b2b2b2b2b2b2b2b2b2b2b2b2b2b2b2b2b2b2b2b2b2b2b2b2b2b2b2b2b +2b2b2b2b2b2b2b2b2b2b2b2b2b2b2b2b2b2b2b2b2b2b2b2b2b2b2b7342011d4bb01b5358b096 +1d594bb0325358b0001db1160042594b20b0325323b096515a58b0301d592b0145695342014b +5058b108004259435c58b1080042591610703eb13737456920b0005458b040605944b1300070 +b33200300019701870737373737373747473737373737373737373737373737373732b2b2b2b +2b2b2b2b2b2b2b2b2b2b2b2b2b2b2b2b2b2b2b2b2b2b2b2b2b2b2b2b2b2b2b2b2b2b2b2b2b2b +2b2b2b2b2b2b2b2b2b2b2b2b2b2b2b2b2b2b2b2b2b2b2b2b2b2b2b2b2b2b2b2b2b2b2b2b2b2b +2b2b2b2b2b2b2b2b2b2b2b2b2b2b2b2b2b2b2b742b00000000> +] def +FontName currentdict end definefont pop +%%Page: 1 1 +%%BeginPageSetup +%%PageBoundingBox: 0 0 206 75 +%%EndPageSetup +q +0 g +0.864145 w +0 J +0 j +[] 0.0 d +4 M q 1 0 0 -1 0 74.329308 cm +67.75 3.387 m 124.164 3.387 l 124.164 18.609 l 67.75 18.609 l 67.75 +3.387 l h +67.75 3.387 m S Q +BT +8 0 0 8 70.70321 60.248497 Tm +/f-0-0 1 Tf +[<01>-1<0203040205060708>1<09060a>]TJ +ET +q 1 0 0 -1 0 74.329308 cm +147.75 3.387 m 204.164 3.387 l 204.164 18.609 l 147.75 18.609 l 147.75 +3.387 l h +147.75 3.387 m S Q +BT +8 0 0 8 150.70321 60.248497 Tm +/f-0-0 1 Tf +[<01>-1<0203040205060708>1<09060a>]TJ +ET +q 1 0 0 -1 0 74.329308 cm +106.148 56.188 m 162.566 56.188 l 162.566 71.41 l 106.148 71.41 l +106.148 56.188 l h +106.148 56.188 m S Q +BT +8 0 0 8 109.10321 7.448497 Tm +/f-0-0 1 Tf +[<01>-1<0b0c>-1<0d090e>-1<050f07>1<0809060a>]TJ +ET +q 1 0 0 -1 0 74.329308 cm +3.75 30.586 m 60.164 30.586 l 60.164 45.809 l 3.75 45.809 l 3.75 30.586 +l h +3.75 30.586 m S Q +BT +8 0 0 8 3.603992 33.048497 Tm +/f-0-0 1 Tf +<100e0b0a11120f0a02070809060a>Tj +ET +0.8 w +q 1 0 0 -1 0 74.329308 cm +95.039 19.262 m 94.672 27 101.449 32.363 114.461 35.277 c 133.074 +39.445 131.441 55.703 131.441 55.703 c S Q +133.785 22.595 m 131.344 17.571 l 129.949 22.982 l 130.996 22.032 +132.547 21.884 133.785 22.595 c h +133.785 22.595 m f* +q 1 0 0 -1 0 74.329308 cm +173.063 19.262 m 173.43 27 166.652 32.363 153.641 35.277 c 135.027 +39.445 136.66 55.703 136.66 55.703 c S Q +138.168 22.982 m 136.773 17.571 l 134.332 22.599 l 135.547 21.876 +137.098 22.036 138.168 22.982 c h +138.168 22.982 m f* +1.12 w +[ 3.36 1.12] 0.224 d +q 1 0 0 -1 0 74.329308 cm +111.125 32.664 m 111.125 34.766 109.418 36.473 107.313 36.473 c 105.211 +36.473 103.504 34.766 103.504 32.664 c 103.504 30.559 105.211 28.852 +107.313 28.852 c 109.418 28.852 111.125 30.559 111.125 32.664 c h +111.125 32.664 m S Q +[ 3.36 1.12] 0.224 d +q 1 0 0 -1 0 74.329308 cm +163.922 32.664 m 163.922 34.766 162.219 36.473 160.113 36.473 c 158.012 +36.473 156.305 34.766 156.305 32.664 c 156.305 30.559 158.012 28.852 +160.113 28.852 c 162.219 28.852 163.922 30.559 163.922 32.664 c h +163.922 32.664 m S Q +0.8 w +[ 3.2 0.8] 0 d +q 1 0 0 -1 0 74.329308 cm +104.352 35.625 m 60.328 37.32 l S Q +[ 3.2 0.8] 0 d +q 1 0 0 -1 0 74.329308 cm +157.684 36.473 m 145.832 47.477 60.328 40.703 60.328 40.703 c S Q +Q q +q 0 0 207 75 rectclip +% Fallback Image: x=0, y=0, w=206, h=74 res=300dpi size=796293 +[ 0.24 0 0 0.24 0 0.169308 ] concat +/DeviceRGB setcolorspace +8 dict dup begin + /ImageType 1 def + /Width 859 def + /Height 309 def + /BitsPerComponent 8 def + /Decode [ 0 1 0 1 0 1 ] def + /DataSource currentfile /ASCII85Decode filter /LZWDecode filter def + /ImageMatrix [ 1 0 0 -1 0 309 ] def +end +image +J3KW%GU+$o#COBr:T)u+*=mro@So+\<\5,H7Uo<*jE<[.O@Wn[3@'nb-^757;Rp>H>q_R=Al + C^cenm@9:1mM9jS"!dTMT<$3[GQ$8#0$s<4ZX!SPQ1`B[F7^jpq0?^FN,^V01s.HIuWPG[6 + W[B=(iZioWjnAY&^gM+`4=1jRLW!YA=M/6)*KS9PE`kN%="Tc + _Aoh+fk'&t\ctIN)4XQLiVp8<#YAIm[Y7B-r[TbficW^RQh!2M]87rW`7R`ng.Y + r2oA,QcS@]\G\$U6`4nep,_pH-TAH`l>Cq)%f_I)hX5T5S6nLebM0LLI6LH!bN&*#rP(P"+ + 0X8e4n!IWoKM[fr;O?J":"rmYZ)P=/W\C+#VBr\)#_11HnPfAcpQOe^lZJT&O\>6,mqMI<) + 45nOSh6A`,RV,'LOT#CDfKZUgkE6.nj"d8#o$0"3&T&G8<[td=>o,*#G[4CIPBG^U($C!N\$_3;hY6\sHs_)@$XM]bjl;&$\7 + PhXh`*LjAmmZb(Q2_3`ZK_p.TkF2OIA9u6p5b>IpL\&@@QHqnTP$6]S#BkDG%7Req3JLkBtB=iV!+7RbHbk + a-HE+Q3$uPElru[,[I%1alaH7$VVSE@=Pga+Dd1NS^$GKL!O-L47coJ*a2J%0EJR=cHRe=' + ["!-:cS`u=SF8VeoGnH2dI`t_:"/bU:K>sj*caE0;SonVc[qKnq5bPJ>&r1NUs4-f@T5WQ[rZ + @3_q>R"imJHo*ch78:TC;^Xhuj(2:_!Ol=:G;h6j\E@/d=Sn*mM??%O#@C>k=_h`2.$;-l"I=Nq`D6tqWXXu8c% + h&GC-EK3oA3_*<>*TP(RM^.XAO1;bbUASC@0;6T[R11>#7#@%(/k/Cb*@'WuOciU;8kE/;- + /dj2O0S[L_hc>[,m9p+;N=XI=\U@,7&cGLY#\0J>q=fKRW9![>/Oii(h(XBQ4iUl9A+_Hjo + iMf;\!81=cG/u6n+Ei10P4AD#'kH@[C"?C/%j5*_"<+$F=Vf:"d3=k60b6;iYln=j8ti7-U + 7@Y'*Rnh)jeQnX`\)H;@]24m0cZT2Y0,:YG\,#&OC0nY1N[=q*d]71#Ye/r!3V*CK%E&Y`5 + =51*N"%4/)^L@X>"coO<[klb'#e;OB*>"qTQ74G'4Y*Mu>>taF90r@pqRT!C,:$KVWVc<)U + ;qcXql30JP<=Ya&>)cDE74o@@/s+%uP>gb#;6!VkW`<6)7G$*[9j0(L-JP'!> + jhhe$$2Tb#qh>>:Fe/ZW:th=kc)Pm002j>8i!7B*[qY1?e2?#/h]Z*m]Yg07cuD=, + 71%%/@8*W2YQ-8>E*Xj7EN)A0'6EnSTF4QdC0gq`E:5BA16Q&\2SqGNf_io8IoZ*QKN96m9bCGk[u=:YGh$<;>*Q3>$+ + /eq]M=*h)]0>4j0#iT#?#VVi&^=@i58'CRJkhZ96\6fkX=cn97:'eejY80CI*D3Pj/VKKb1 + ug-(NSkiq_fd[Cah&Q@DU&:')%Ro`4Ae^*<^k,5/b\3#;iGa-)9/(7.V-bG8h[ekL0/pIh2 + FdGZE@W[;9L34I$9rh7O6+*UF9`A+dDSAEPgC8PNA.GIV*0gXEI)WB.X"RieD$?fq1NC>KN + >u5&JZn+#mrI*HuS$-I0SG/a&WiJ#b2_dopW0kUK6!2!1L-)BtAYX[N2rDPu#aHUuRj-9j> + h(r)A$&F#`eXnBUKe%c&^CRol-2'jQugAUm5SVaW5p8n<5^KB&;q_U1=aP'ims(f;p[5Pt" + fH:9)m?cM2[eA[EHRi]@NFe^P%cZ;KYA7H-f=U+HgY9>uE,Q3Q,PNN)b?LHKCJ?N?ZgRSG> + 2seaSd3*m:@bn7$[V<&*?DW74PtC194cpp^c6f]dsMskES0BiX60TD]R,f2Sg/Bf[f=,_Q^ + 27O3Ql]$A`OgQOn0W2'KJ??bF6a"Ac;eVq?Ak>rlK-Ec10Qcd;m!/mH%uYJ:[=K;]qRu`+Qn%?OUcK?ZDhkKCKj%0Al]SS+=RQ+ + 8'uaf"^Zu+$KA6pg4]pI!?$(?`29HhZ)e:s't7Q:US,jHhL$lFTC\4B`;?QD#W&`p`G:9V* + ?p'<4gT;DWL-/Q@VikrboCIa7TB:jSqhKs,C.Km-=$m)!nC$kH:cb&298ChLJ4Yr3.s/YEJ + o=IfF>8s.O-+mR$6><9Zpk"0\$nn3F,=klHZ;!QkWEn0n!L/G*mi#H8LABEG#ckSu:4'_%' + XiSb(sI/++KJM4t>E'0e3VVP%Jrp!PjE/P"e>mV\5$"sbR8/DU$SI-gL#7gItmF)Hie;l;6 + J.TMG!RhN4BVa"6'_']Q&?a%bVV[C<"gIS.&EO%0;%Bi!"-EN'E6RK_q#^'o&ZFFnVuI4ho + _Jnmr]njCd3B4hAIiXq$E*\48+R@N;%h81eIaXXnIjiaUuLi['X:o&&Kqk8RhIMgP&H'j:r + pb@5fKufgX/-5EH_F<:6G'b(G(mi/7fPKbk@(E'sV*`l9qG+_VNQF(h`FX%DNV9HQ-rUV'. + ]8kO]V]`:tJmV3/k=@=!INL`A,7)mC7X5oBG17&9?jIPH$e&_s2P^(X$)q@WH3C.f2epDcJ + [$Hc-bB@e/Drt%dtqXMr.:R<&_8-uQq+UD3i&VR"o18N>L+7^-cnc/Y&*?0#A)A4>:ngPOK + 3e.dP(@SFHc\!?r2]&U&(\0J\&D\8Fh]Dm\M[#,N + 1L*10D',uWNKP$7X$?DVY`-:g!3:b(aLGo@>5MG[k+b#3_n\KY\N%J'e#ZClYCiZ0 + eQVN72FL\i04$4RVKIBtL!Wa.D.h$co!q6N"4C/HCQHD_:C*HNj1Z6([hFXHBX2j7f2O+0( + ::o;]^IrTBaYK6t3.41%Z-IK"UBBM$j;)T#%2X4@$8)Z7F3i6s_!9`f-8q@W(9,f[f3,2SX + #MCtlFZ%P+2p[*s'7^CqK_l*p336aR&V2Q)m%lLeVXnR/PH:X&m!k4[4`ce_-n-k^FYQaa0 + shpWdiU1sC4B1@2D9\ + 9-/Y*<=BnEQs7N5a-@_=.Hod/&<8A:??bV")PpZn39);*D9J#rFiD<,R,+7]3VU8CUD3'N0 + A/=#g8M7]PWD-oFP:T-I;.Y;F'c&@AB8G(F`LoJ)g5F<=7-f,@#b=DjNP*8:GZ74h=>^X.'bpXHM,n@m=^fc`&E + ?Z'JSW_#ME=HcRj9(**&^TojelH9.8.rV3Ot['il4eStu&(=CL/k192f/799%,1,R + .M[LZJ@'4GWM@C?2=Q.Vp5Ndd9:Up]!+eX]^'[&%pEJMc*Z1u?Fjj^r1_68S2/bs?AIFa4NG.N+0 + P@rGo>4sHo'ZY!QQ"Y,mV3\uHQH'-8RN<(h9]tFtF3oIqVV60n8ubU!>um_>^mf9*bnCFpAC_ph^hhDC_n0jQ:##D\qG5UB( + dfaW_mk]F`"T^5mQ^n2cbB+V$=8Y0B`"H%u,Z/?PRHY:)7Pgk^@'nFJlP:CNj91kP&:_G7M + [h=Z8sVTe&d!'dqo?[I!=4kep1c7,_(m>/@Mp:f(Rf + uqdSiIH+3TppM>>gV.@r3J%)Oh=0[/cmoTIop]FE<%"=H! + \"UMV+`$(GpY%M[7sqV>/kJ(n$$O*K+$LO&mul\7h\Jnta=jM\j^!W!e;5d-nJKOgn[lN)N + Km&>bT"F74ArG@cd/r>&N:O1>RSoWN^Ac@6RmK_[Khpk\^U.]6@=PBcPN),Ydl4"L,>LcH' + 3q#uCr@uZAGJbZb-pq;rm9pK`fP4?;N3JEeRK9)CHMKDpQBAo)an!=kKPp*K$MK+pVWJS0m + K@hc6q0/9q#FS]aO6W]h:a"1_,kLMH:!XuFg#.S:?^l=GJ_@eh3H(CbeT9+C#hFtkG"M`PT + n5:lIX1^e=d,;bbELW$Fd`].)B5Ch'p]a_T3;N#FVaQ?HH$YJo/)(<\ar?q++%0YU/gqn\c + $N5,7Za:TR#sR\dkZ"/YP2FU1ccfq8JFVD5MU'T"!.J3\l8S'cEFsSiVga3Tm72kH`>(2V]+A=>,%p@Vlb7 + pJ!RjLn[GPXdAr_FUj;@2g.eZ:Ffr=YV_5rZ/R=ocAY%2sW;@R?q&mcs,mg$.:AY&a;p;&G + N.1WlP/-jAq?!NnO.r(dJ!7]@_&96Kl*S&1X;W+[qan3LS$8?[IImWJBN_GHJ#uo`K">s1q + G_q`3i'@LIJZ@.4%H`+=FXOMUt_*A>0F%;>IHV#ZE\,Tg+U&V8\8,NXCp4r(#F_WLBho?Z2 + ;atg68a3-`7lXTP*;b0aN6Wk,%YF'3UI0]$7gS3P3u7]:+5a4+"QNq7?J/N-kN<]F2;4$,. + 5`LV%Z[gNgV>Q`p9oITtQUBCWg)W.%t5V;(=Mqu=63TtafI`-\DZq_,@'_j9'gHo(<18:A- + m)0jo^`i(K&4AURA;BP[,GF(+E\93d'=+A9JT^T&_R)R#!Q+^EK[9=HbBK<-*n\e[8_*"d6 + *1P#.\UZb_UMQQtY?@Xt/],$(b_P/t[oJG9f/%/EaH_0h)a2:[d175A^tc'-4RpCbiIW@c,>CY-5YLIOOe?kL"Q8QiKNR4))eXa1i4IO-CkLTO#pcWYGSTi\q;6^RsYtrb + lO4@iJ)r>AFZ7O8+I663=l-m]5>;fPOO+4VYrhQh]$^-4nh*\m2?-]A(bmKGEReb7ArQK]c + d!M&/S]#tZlDI^e>$ZU)4bF*4LU*KDOT$_XrVWSBft9>Ei38F'rNEQa("GGAI_Hf#\m;MR- + .op&k.WRr4i?:BoAaS,j/<^?2iHNul02jtdJb`O*dOSjdpnn2i&cRk'[ipCe^-HiIhsQtZ+ + o(`$0"*2idH[BStG4/p!nM=I9sjhh333"4TtD*"Y^#^DSP2&8qn2YS?AZl[0 + <3VsE[6E?BYedN4+sq"O.r_;KdSm@=:48+l97C[Od`3?UOp:N-Ls/pilmItOEpUJWFs'aI8L%-84e]9K?S + n\-fkP[UsrmRSa%gR^/#^h7)+V:#7)#1"a1a3J*PYNYBMacYJ]L4m!Cobg'2eRms:hRFLYM4eGO6'H.\rM++1:knKRd/t#G3;sG)9Ptn;YX$r3%R.M + i(?)uTD()itTiEJ-AlrKTUY1[[$>OE0DV9ZOV\ZIJCS(6ruFbCZP(X*X)SRf'10USA20,]b + i:1Jn0gjjZ$P!:6jku=ro0pt`]dqAA=8YsmMobsB%Y?@ud<`7Q-"a-ZEgK\o+IFdk4]s->d + =+0fRM*K[$%6Rrs6Z^H6F8?mCN_VqdP0)f@Cuh?S0U]XeZ[RsralW,>r>qCc_e$4JD;iW\5 + L+uSA(Jc:T7?>*rMhgbo7[-/Ca4tU^l:_@q`_3QnGPWaKHgdN:7=;f1=!H(br\K13psWK$V + (NAE?n0j7.;/J^HKt3"E;?H37*I"$R./=S1fe2pr0N!HKRO$X9B\:C.&KkaGY^i(rgQq.iZ + MZoQMQQEhc\CThrA&bW?'Y2\*H]q`oS:;QS%t9_1[#Sjc;R=Z%_n@q@YqBM7nCc1AmE[7CY + [Kfr-c2#aN#1SkGicI7f7FQA?4&7^i@^e9pl:T,e<:i$U + ;j!5[8QSpUV"g!HeV$dbeuCT%<)k`F='!og"[,>Mm]@W@_fVVW0Jh)[1D*_IKqi?cB[oG1< + -G!fZ64jdMUb,[Xq`,otZ>f=(U\RfO+k)8B[1hPtP8D'Zk]0GU + in=2u]U[@i; + 'Z"[7G9b3WgW$dQC]!fi&Ft534$di?=$=rQHt)WnXh9EbeT'BHNP/I3m_aS9?!hC%6@ArOg + \6(39AV3?:Oh>=*H$)RB@O[TiV@q4U"oIXL7R4J/n4b>HCi-;io>CKA)u>"cbo90hLET;A: + C/rU\I&TgO"9qIXA;GqA7ubId:%]7t5+-qu8nU!e5!?bneK92636V)J7)4Q;,,-iOc8 + GODSA<`:@P#b4C[WM6gWloHZJjr?-5Y`QrQ^!Z!;bD=4.V2S>O`H1Vb5#HsAX'NeP1;oi2_ + NuujEGPQdSS-_68p5&WgJtc@n_0111jM/R?KOA9_kA=AsCc5P?)HnH*K8>eD$IVG&L+N_)Q + 'Aj.)=!F&%"L3N#il,86eq:ANj2B9`"ZPLb(VH1=(2eGGfRqL:GkkiO2G5`ZSaK2?k*?GsM + b#a@6&66P5RBU'6"U@sLAl7kY>U&CVsjmPSD4\"ZN,G^#-j;gL28SM0T4JJ:2*84M?.-l5D + CjKDU)IlNVeK^mNGTbK3G>N#dXD/4LTpsbJn_]l[I^L5p<;?,^85MaTPsVNOEqHgMOl*2Dl + D20Cm6N&bH)n?=ZTKr!>%pE\3b>4T + *&m?Of^Q'=:5EjcFZe[7)3RU'*O`@n@T_mkUm?asA]$UHC>V"ERDj!70J1CF2]3ZnhSbnIk/-hHF21TW( + =1u$(S'i8]JoFU""unHAfDtGnn<;lPQrM`I9JM4CNWlLC#-q[=6&89TA]0:?WWZQqMI$ju` + J&+0@e&cCED]BHPRe:74E6BUYb/siC^+D@093=OP7G,;Xb0l@ONL$M\.f`*AGi*/#2W9:6U + *)4*3e6P0KHf_X"9JTR:L/8?d+q&YC\m`[4lLMA+FdB,[MVrSlHsQg\fVmDje:6bB%pnr&_p,Zd30g^2Z:S*8fnq%@m..Re + [ZL4:RepJrS.W)Nek\bIaAhR*\%#?khZGs)Xl;UhZSoNVgfq62kV.!oD;O^;M"FO4F(@)9f + '7;*daR>1Zb:T!'AMND&isn8_GD+"KclV^KFT06pKgVR>ZUrhTL$Rih@0ZM98df]S0pjd3&EEqrY*&Teh"mgqZ,BeM$eT_U4m?U]tpA3lU`Xd.X^!sP + )i+_%?fEUes?b^cU;-5Q^/+270_IYI1!dn"9ZU;pVG]+^+_uGoY60l^5T%1'XO.38g8'`,) + Sec_:UFDrGdqbEU7l4WKo,\+KEisuX4dB;05muEd+Xui-T=ZK2TAON_1Z&#kbk'_;n + nHAa*.V8VHlriLr`@PmB7(eLF(?Npf.?^k_s2[H=%.i2EWBZe$N>MepcXb6$\,P:"^g6554 + 5HL?e1AGYOH@Z-i4okp\R(*#Rum:\kmXdPLh@<4[/K;^flUFOKF(e#Sm7A3YKVh=P58;%L3 + s_3b/!$S.@%cbCXgJ%?MOF/-8*6Q9E;]1sc6(;T4BL(coSF_*f1iRi$p\T7R@%/^PFmJ9Jc + 0HG7`r_-jCKYQ[0D@68!;_?;264.?JE/\hpX4n*NQF92\h/3R5bR4H;_PUm&YR#aU;":3[4 + O9:3d1cr&j_V@$qr%>L0+:XMk!?8cX\Dk9U&dm7s6ei<*\2H_Op]@L2#IHCU+NcU#BfjBS$ + TKt/&19ehgC1_a%?hla@K/HC28h%?,\03QGU8?2#fR/2L#BrSXA_K>#me0L!J2RMn2A73FU + '`tP>GW*X4m[eDoKefJim?`6qW(W?l,Ka6Kf]7/5SbCkranu`LLNb&=5id1(BGQ!%Z@uMrY + 6?AB)hQ$J8%lka]RP-H)iI7iY&hBbUcAF@IZ(MVDcs(n?2JGTq4J!(].@W-?:l`5AMga4T& + Fr-pd>C-@ema#&Al,Q%[D+q*lg86gLsGd*/=5Y-dCJ.UBh5T5L':ElGD8D1o%./egPO?GkD + 8+7&!n1VmE.QP9RL.%=8cqm;]9#96;6DNC.*03\%r"e2sak59+a:Lg3W56,3U-NQf.#c109 + ZL+$79V',X+JI/oFCXNb*jR[/?9'!\-4ChJi&Ade?:'8"A9"qb8@VlUpC.+ZkK7B!sCp(S= + <-(\0#E([tJHW+]XA,V8O9"-"r8JpfC,`'2/gkU-l%UM!#2X-TM`5$4rI1\/3A:OVQoCK^c + %YJ7uMB'L\]G84m-c9? + B$Un@#f+'e3!tY/>e5;%M>0KbBiNELsXj%[0ogE$rG1X:tddu]_r,Rk!n#aXO%N4[1`kg)9dpu77 + aYdbH?J?%uql0#5!2+89E7h[`'q([3-n*N8jui+;:PIJ;gDCAI41;$IIl\;I(VID'r5(%oJ + .A%2>U*fE`.`.oOSrLA6Z-r@\h[4>'HR;NXD"I5;P4$p`0ZN[U4sXZ',q3WcuT7>s.Q3/ga + 0-e$=';r'W9l:4a31'tnZ4UF/G**7c.XVFNiN(_^D7!Jd(5`A[c9eb6)"\T:YbGfGZ;<5@q + OHpE94AI,[dF;dWY`$uJ;7.SfeQl3UD-'_c=B1>`-NB%Dln'%8UMVSpL[9biS?a4sUeg,jt0T/prNt$eSRBXRMYliSpT# + ;Vs"2(jg67'Z#`k\QQf0I""XYU$,?iU1Lf@\-e(f$g#/WlR5f'nRK!/4JhH5U:7Mlf6H8=p + L(0j'E__/KXpXP8\5-^1?h=E(uO\9*ChO@O!5%f.OR5E\7?/63Ko4]@fm'. + oXd`-E8dk6)!-EO>TQ+-0`50PV#6gi)Tdg@jc35-d'h`(foTt78:=/s)#b@7e7@.14MV3fH + =e2W*?t7n&6UmFq>8uQ0e#/D+;Hi;u_X&FLC*WlR\16TOg6d_#VuU#7[2<2O#Z\$3aJ'dIL + E]'?9DDQpE4$=03<[=?>O_tdX/FCO-VnDDfM/p^rOZ:Q`Y]`0LeYV=aG\;^6A.eT-s0-Gb= + dY\i`d6P:0BqJE!oh8kDHKT?(!`0=@:m5W!$tn"?#%-!(\Y+:!c_F_L!=,r,r11=;g'X3XUl:?-l'-_)b)WeLq2?#dm;0!BOKj!M2*`12GO!r + WQ^ZG$oJ!?\S*&ffDU4M[^F?^M#4HW[#)?$r=Aj@-.t+a?a:G3X&hA@K<43#UU4\hhi`M/G + h$Pa[4rG);uE(aCq*s!(dj"al1B:?@tea:n1tn/f,QP?Ih5or+Hb>J-nQI@obE1?799K.L@ + 5U!tId6UiZg45)M5(PFNm)jY]@?1:5IT;RG7gOJ,Ns3_HVcj,tJ!7QTCl4,W7T>fK=##!J, + 5)nWJnCf?cWRe.P58RU;H_*b?PH">Ok4rdTH":@/sB\SW7KT$W_6hmW)qq-J`c53n\ + EbPApIA$0XtdE?,Ufa5*K9MIPN#u#TbD'?./H'qPl7+t%Y0U4Z_lg& + (S_mVjNbJ+il<.5(DLPs^>STr7MhK8Z@6$]p/HoBK@$2p/R)mP&>D6X:LKmQ1SUk^caZ"q;8"`-.1C$Z1r:@l[QN]^69AkMFXO?F + rF$L;2qpB'b%VQ4@eQ@ci'665IXVI4^8Z]>mg)@n*CnA)L6*M3KpOMiQa*PrAiEUC\ + @u+t1O%N^jpNA[AgD(#mRtrM"Za!Zqb:*ZF0sN/mksZ_KSic+@9>6X7q($Jh$\ReH#C>k7aEYsc#mGD`4b6-4khp,\!%cW(< + LI>2>aOl4Q[dbR0)N)>4,5pF+c!GE-@gXb7nHUV%`D$V2=+If\Cteg,Ki"LsP#6R!k6#p+h + ;:SQqP%lfnpT8('uLABnSjF1$-XYk<[7sh6,9Y9$-K@UpI"3u!\!X62@i=?2NI/A954MSnu + imgnLF'k\TI@,,P[4]Ym1rW*Gmr\AV-h:B-5g8o0oYY-7l7@7jHh+,_NR3?c[#*k_g5;M`B + f&8Q?r"BjNI^N69j+=GS[;[Ke"MF>(q@0n#/j^sN-hC^Sr;p!>cRc-gS6@ni>ml@>H0T6"b + ?YgZMJp17STD=6<-0K!F&/H'BT$QjsjHu+N6o:W*aY$).gS<0t:G3+2_Kun@2E1Nb,DU=C@fd#=]A!R_qr:h,MS(lMa/@H + :fMhp$<3B#mHCUf>p\TCs2^Q^8)A\g$3.NH#oo/P#NM"eo;u!Br#e'O`c=g&`q]X2r6V/-[i9p;*0f>$P>5k + KR*f?+\V:FjC^BgY6u)(Ck'#kaqU@e"@#EO;#'a5[dN6].Ch\^MHhq:rH?q2A.#K?$/r7\m + 8Q>s`>`1"P:IGW!hp61dp!IOM8S$7p7&Es7Q:kf;q1Qb!(k0_:PBYgDofJ\Xk-*Iml0h!65bBjbU\[a6VF2T/HA' + S?.>UsgeTk.qYqW:\ldbk)G/7[o=_*R$6pT4:ZUp`HpLV=UF)0T7QZ`i"GC*@t<;6%1"u`6 + n)=YWs6!"ap`XsrCI"9Ng,0C.2_&U682$tpJ@s%)BL)R#=7MT*T(8jMkN+YdeXb8JI9oX_t + g7U(]0G+b4Ee5Hi"DPco&Jr*)`A+02jrV(SNe0KlJP<%hg3$Si45gm_k9O1>`R0'A(rfFCBW\3$_KqlQWVV4@.&[c?MPSNr<>q + ^7'TEr$&Y,15aiQ*'-d#(sd!.-8@P5?\C["s9PjY=M8NHu>q(e!%3t*p`9MhbB\?aO:=jBa + rC]hX.&q8ENNLK!D\8p,PiPKK]WBS?L&]^?M96!\_>=3ia5R%G-5Yt>l=;Au"RhoO$:LT:-.?]&;j@NUNg8JJ3UN@;RUOO5WhfgAUS)b! + 2ij!Ion.Dd]FNIgno+9H0"fJB&,iI6&C\=u`L2A\Cm0_%h\&KL'iKc@:jQR2?umi$MA`,t: + pDE"Z_:U6.&CX1mf=):XJDmI"%+m#i+G'V7chE`qs")^Iql*bG5^@7PgpT[$rn'+ZD^l06O + nmL)bM3l/94Bk,pn]+uZOrSkA$i&JnoA'@3d&`T8q&J=,nnT<)pe#VFUiI\YD + ]CDmW`aM`B5iZN"Ce$6Ul+VVgJ"C%)nHJ!Z"05H-'sDCG9-.:ZqK77Mn2R6mP9l5aT&a:XQ + rB=k+Vb2TT_ri+/jo-?X+E9HWY;XLA".kAbD6]RN(58B\B*YpLH,6^Lu\%*a@VIc]G)gB9>'UbQkH5+=3\S(iZ]ML+IiZDV%/j&Fb),KSW$c!q[d;+db:,Po:\W(la6o.)I!UOUT= + cZ5jM4#!JlBLIBlPJ^B-ej?/1?,-I(48_d`Ve1mO2X1- + Q,2Wj)VS&iD6"c:27N=6AUU'5ZM3PRW&ES;4%@+<.!BI:kGq,O-:Hm3MHBL*pB(j#\":`9L + &h#(np;6b^Bie8?Z4E=kMd>"+s/leON(]Y'65>bp$@gO>cUI6G2OpX?BaAe4b&"8]e$<'Gf + r?S0o7Ie!R;]u]OOJ=.ZhpP+]!6G*`UK"mcb;'qe8@hfj<"c!+R[$e']<[+]OO+kQ3gV=-< + @,r3.+OM\cN/C6LJ(2'!8>A)>EB&]!RQ/DR]TcZASjlc(k&0Z&l9g!5';MGYEB1V6V_TH1b + TbJ8OmUgKOO0c,[i1&3?(a&q4MqT(lUn`.RW)B*0eB%02k1gQ"0oS+qA^R=CNECWW + W7b#\FW=VdmQ?H\Gb1=`HlBX=Bjc^'J-;k>k.,5,&5g60!^D:oJHp?L*kfc!6n)kF5]*/Hg + g4`!Z#ZQ1sRG[#N84=UYO+nZJW?5pk.mihuUGFU8APUL3W-0H4kQF@P?'7AujTl&qR<)e"8 + 4\3/)(1]^O!#4+5YD*4rfGp1.$KUJ&V$jHR`k4es8RBJK'GA^6e.Ddq?tGV[+kUaq4M"3RV + "#\8A1ifQWe:?u6Jj'@A;&r?1NLQ/?6o).f@$^Q7^:5h`NIN'[mD$mLrL>fQ@U=AS45k[aU + Y\RES3kX&kFXP/>JT5%hPgk8b%<2aH[Pme24F^1F?\Wfpn%]*7^#SF@Ql[]VB(q\q=ICTpF + V_H'?dSL.%ne"hFOkBG*!sF8.=19Y_k-%-=5UAamN2SV#e\Im\17&&NEVL>cSrC%;k/NoYd + n&=cX#DBU$Y9Lhp0$p[C$&Id.L>!>)Gd3s"j0\3cn-5#$SWc_GieYFj"jAI(`dWS6H3p'<) + ?#?l$l;k=(nDk4QIR:IQ@+im_1$IH$[eAfT<+)J?)AOM@@X5P + V2c\9cbeOKFAZ[V!,(<8Wl!Y#7d##moYiXFa`cA$N.;)n;\")tJB%CO'Rnjo"-iD0]j(GS` + g4h&XfU@1CZ?#RVa\Zq,<\("*hT;]9]S(E+;*2S.mHSKbPI-Ha7/:O1M*]i2:]RCU-YD@L" + 6hRiG942V>*%O>1YO_$^VcjLpP+KS&'8g4Y4&jJE!rVMuKXE3<6a#iG:-c9_[q3(ZJ,kAPp + NVLCYGBt$6J_dBRH65PV>4CH9iB+.t#4:X%WC_f\2*d8m2seLZ[7S8og^/IPciR"J4ok'02 + pLIM4t"E0AldY%/f1!'p,K4n\=8cs23+rO91"8+C3nPF"dMXj>%k9N\hlb!Q!Xp"CA + i/rn^'V6f:_ai;hm,&He+U>QS_L.cSk`'^b>J_FIr.c5QN\9#o/Ymr-qKYL`sHhZdt'/RqV[ANc,_on9&@.5t+qUui + mSKu2B_XOG+B`,I%)`]LV_Sd%ecrA4#8#`:@!N5Rpn+S344(eS&Fr:dOPn:Hq.^oFTqm9Z< + p)(nPs>>SK!>/'>7g*W.r@`h(Ab+R&Z]UOE0NpjSE1 + ]n7e`$cY2Q6QD:)9= + Z0!-V%EXW!==)UY]Od.l$C9#;.R,Au]g0'mrR3tt!gVns.f_S6_E]c?BR0B0dcn^/B:W;H] + XJPQP+pC^97eFJW`!j:*0Tb+L>,0[XMU,rqWR/DOP")U_HbbZd5[g*$H/? + imPceSfRRisLN+`a0rdZ>sl,3Y2.0%018Db;3=A0M>)!sM@9nieJ>>j:9*'Cu\ZkcRlq_K* + J!,7dD@_g2DQfFkM?olBRY'/G@T5]j"9mB;a_&\A2*72u:-#I@0N&L&?u%-O?"2*rrRU(Vq + '^=EPc[15[6d5^YLWmr:-Z/aC[a(0QCas8OM*^NR[JdRR&@kB0W+07Z[+u8-g2_.;=J--ZL + +uM<]7!BLe'T78f()]S+LAMNo=Hs`4$3b94AkUl+r3*[$3Tns0 + 49c)$,d2`M@['$7U,kQ49%cK6=/Hlc7Vc'fG;j]F7-QuF=4ES"Ve)3C^B + Hu\Nc';p6EA]4Ui&5GM/[f&1!JHRpnkQk2B$C0HVFlQ:icWh+n'D2d&@d\8Fa&LUd7c_T8BJN^'@e=,])tj + b@BC$*$(FA&\?AYgYC.R]!F^g!m,7F;c]/MH%9G.SEG&%$mV*uMu>u[]i8#kEm=_"f.qtF)Q^$S]W + C`Lif+>>$4V2Oo]7;b[K8W"\8;9S3sO\^:9ZV-)Sai5)tCU^pN(OF2.Na7A+Fl='jT3B$$U + TO-IV,Li_G7s8fZ%D_Uh8Yp#6BfV0[n:#ULQkFrDO.-ZL93nV$fH@Q(s(!hNjU,3*ib^d?D + W%72>E+$LL + ;E07E\gE#E5AqAN=>D*%X+Qb?AUqmBUTd`2:Oi.4KYg0%Z+4B[=Yu4i+['s7'^<$F(rVs"l*!fpAf2!T5mEF)Dh] + J,=97(^UmC9jD!n%J.!KR2NVOZZ!`aq2Gg`i!&7I/R3AU[QBT0fe9q>f!rdU+ + S'lXu_6UG^&+m7+jq.-jNHSI3WonfiTJ5KEuK6;?4U&-.Mjnr$*"#nV$0PGJR"H+ajRm2tH + [0.>0[g3_bu+7%lTe@OOoY0r^*_DhG8U!F_urZqF:L45-hip[f[3N)c]YKUO#.ie_-]/lcD + p6tE]q\tBd*W&g;$&Q,&0Kq!%u+ThD:$;('sPpeS:Z9A9gYJN#hDp+Rn0_OI*MphM,Rh@]W + /dpis_U&c=2b"u#$]Va6ZIpIr&H@p#I4+euZMQi?=sZKEoHQ`:Q3=n'\2'T9RX!I+9op/i- + 0Ulb,:kLTeSHf,L`dpVM"--d]+<)N!\k`@5`"HD2fr"#j*irLhbt^X%:Jlh[GD7DfM-n,]# + [[Z)md.Zq(]<1-tSiMWQn1aa1Rnb]\CP8@PA\Sf=_"8^"_9i!\KgE_7kVmN*E^%84j9EW%g + d;[XlnFV`u'guLc@P7h2@NCQ'*:]BRR;&%_b0)P4\\Y!mbsA,(JMAm + YrYTr?Do0P8)Ypo_e$L*!P?TheoQtgC0?)^]d@3SE_E93B>8PHk44GgM+`KLXm?pA_9`XS& + )7gra=36m$?CV?XO:!pdO>JdU%P[&70iULnb/>`a=-SJOilU-b + `_:C&'N3!0?`X'Q(5knTE'QY"hVV>Z'XFQ_#@:Jm4kKS0GeT!AV)p;RN\i'SK)_!(hL]%]MZaq1*4Yj_kERRAI8u5a8_o4o.1Etk`IbRa47)pUC=DipjHb3T,r'DV4fJi`(1Dh`U*9J + I#lD0rO,?aW_pQ?Ye_9PXRcCEG/#%u2oK=Ct'^a)< + /O(oCWO\\=4)M,#6aE(l?bag`&gVq76SNG\0NRDc?KpG/]dDNCofK[-?W:tq&j5*#]"XE$d/t%::^gLft*"D"9= + 65&_hqDiG5$R-C'VA]B15`RdGX(9g:N5/Vj;>YHQc^N>jVYVp=gc_k]%u@31217&^W(W+]sI'hX[=# + NZo:9pOA575@q0KB@?gBq8K-'5G.dMn&YRr+orqc$3F4=Q6EcD".lXkJ&:h"Q$39c1qqH:? + d_;kU]"QS'r$Q@_AHErBUbAQ+r_^(ht$/Aak^hNh]`%#90hD(=>V'2$&(_)OP"Y=+VBQ!if + R?M?83=W7cTW`oR9(LO\"Pr=Yu^.nW*Z9M3:K&([5JGdu)7XnsNak?SRtn7OlBWV+:a7d:VE?Qgj`HcWEYO9Q8?t!qq);*Co\Q[Oqss^#Vt5fH^f%PC/5%bJ[k:=ZoY3(R1DIkb9X?S%1efc + *f/?@0FPf&Q1?;R_cEjnH4ARERlTPCAnu*[-/u_i;3[G4G4]+%9(Igja96U06dW=q,3(M_Z + s1$OC2bm;Yofl8P2&/VZ<4+SZ<(o*E)cftHF^H>Tool+X.1iBCg/gJ[r,EYotPHN2\jAR>dlT:FBph*f61H/Fl.FM2j + NQP>==J>@Ga#opO4lq[JgWn0*B/RQP_NQ;rK\'(PZA.E]7I"D<("TY#MItAkI;s2i_CXp-4 + XL3>7g-Ot*2d!1LGsC*R;iTN.@2q&X1;B!O$6M:,Eo/S.i0`bhA^3YmLFBY$)b4s$AoQDtA + )F(EZ9cA=EYB_o0@X>9Uj,5^P`%P^W0]$A@%CqDUOZu%?:q6hc':>U24/UE^<.[jHgJ"GCq + pV(RF5.;kJRG7:Zfm=2d^MuA;(WLI-G)gWa+?(XI&q%#BH1N.k2QB6ZIm;;"]EO?DkIUqJd + .KP'=4VN-F5"p>JU_:V'7I0b!r"'4GLuT&p1r(F>qWl@GQ'O^jEWpjQC\oLF/!8m/@]]b.Y + ="jk'K;B@Gp?JifoI(qVdd'UV2euB3eF!tr*/r=B?I35re(ONa^$,^m-_uG5u"p$ + tI(*R'?O+kM<=?-UooH/_ko]dTH/t&/h4k#a?q.\a`rbV1<-iW)e3sC)0*UY_D;H1A$JuA1$1F8\CVVPo + AF`ZMEXQk#pEh8@kHo?$'de2,>/mKOp?63$>Cq4jKpt/ct5PZ\M#=@oUh?UoIJ'>W"e>J@s + PrePE^(9.qK-mK!Ju,7]BfJA[Jq5#gK@UU8S3ko"HX5k$\umGRPnBa*uIYdmI9#1M1aTRKe + jlbrCUnb4mi`"].8)\YD)i7*:KA*cFe6aZ3ug=TjqaW^'u"=%@)q1^-]\cT0<7>m0)I'/Fo + 1\bSI&nJDXU"KDUi#ZkZ+\N1tLKhqO^g1S?!PB8^>;*$-hKO#BDJ:oQ,@ou:"JKT98#TDr=;C-7IQH@Q@M-EBu-#nh)Kp)!eo50G@[]VbIBnXM^TmW.aNc0U)i\VC:sVUod-7IHV`J@^'@Qr + 7P!MIDmf=8!uh+c.#]oPI=)?8]^UT$nUXE2o;("X"^nt[Gfsb0_?mK5KOQ6:L,s7T=>p[,C + _8$KhB0ZQK\52cfklPFdS5?E'k/^rYmW;X@SLkO9082mEOIgH"q3t2[*fJinJG<%!Ao?9M/ + G&n7k(rl,\4QUP=auaapFr2$aMZ$19tMbJNG5jZ@.nAk$Q=MKnpLI'U\8J*alkD1GW4SRn8 + oPc.U,tB/0iDJsp0bRH0ISJ81Iu#'A2pG;s7V$))@[PgKehdK:HP7VaJ]!np.6k\V_7ZlYL + ])J9-]D)dmdAtL?'RboFE7MYRHVi99A-"@_mpS1.PZT=jaCHIU^Fg>1P+L2:d<eYCnMqg/IGdN9ZqiS"USoeNNJ8@p*S>E)eP?Ac+'%T0&OagaAM@^YHGQ#[F1b=\QZ#$e@""tjQj3O)O>]ZZje^3S + %MpHRj^#GH/gqnu1#&*Vgs8o2=9Wd8kbl5`BoFZueTHFHuA*AaN/SrqV#p2fJhA$L2@ak;# + "BC-_;[3b7Kf?>mRmG5f:Fro8kHae4f*Tt+[^A(>_DfURnWCUdUpPh#%JFOL=\ej[b1^=PP + /%'nR;YeLT:60np-%EFMT/hnD?,/roFnBrh*TfKsAFN50iG/34>Wk*52r?cjDH/jG_oocl<]X#Z8T=FFqB#[i)"31N?:Vs`59K2)T6^/0olKm2]B + ]@hHhIbigAHWQmf&j3;h#**r-u-)raK+.5ER;kJ)C3&TAE4*MuB1CqE+:\^]S45;4P9KA[R + Hu^g`nMkQ!jF#+Sp!!!E*`P&_;o,smc!66n"L + 4F>H:+320A06]n%ZCc[AG3((VIT + nGHoiL.Tr5DT/"6kht\X?T*-O2MGk`$@ahEWAKq8!r(#_rO;*PY7W*8;RAU"5tgj^a?>=7K + o#RLb@O&QAF%]#],[H+qR@+TZTjd8`Vg%oUng-^If&rb#j>>1ma/3;2(608X*XUd" + tBQUr_2JaOmL\i.nPD:rZF]-/=93;(W(GXMl0e%!5=MY`)"K?-)408X`r.]V3GlYY(jJbCG + HWUje+VI`p2f9/3k)+C<$Uf?9t394=ho5`X$PXda.B0I(ddWHqf]Zbs7jqBS9&1 + jpFdYb]tm1r-loL0$JR!:(]2*+D;+(cpL4K9dK;!,h!%3e5!+0Z.te3A9c+I`X57radB)!# + _Y_D0ho$ac2`d!fegYRL.n!k:P^k)UeUhWB%!8\/V%X/X!/On1$$;SkXZV+;#m`+39l29a + AO6a#-O?6dLm8e_]cr;LhbZ/!$Pc-,j\AR4^Jn0]4FGaU.#:e=Q;B.hN,:^U(lD+fUsnh)d + qg_eI5ocnRa[eE'6P9ofW#4r(KCHi:k4k^n;#PMQO&!*M.Kc."\/i(6rX`%asBgi[;/NkBM + 'jn:NZDgV+=YVKiCK4#fL1GBKcb$>/Kr:e]i9*%:.Kj1J+-M95RVP4c@nILkoVt;cn\%7>2"a1lLqFf;0kJQ&JcMRmn]7P;SS.%0Tgf3a)EK + fZalZ9l/Nd;:eKV]u4^)XDGRT+$Oh1g>TbK4eGnpCYF24gB`R6^m7ufK[rjtLks&O.*#;pG + hPF:W/3AjttHWHuJgW5]7&PYb&Ma#sLEkc + .iXNDfD^gL[ZqNJgtBOPI@d7/Y*Ym0-XHO,9FX>V4=V"i44#f3>*(>t*ET=dQ4: + mdXhR;a^066+#^o\%9iKek!)kS6fQD^MIGbBbLKum#;ui68S\a-Y.GbW-h-b`\V-pGhG*/>(&2-Ymp=f4?lf2NrTB#K + Qf&>"?eBkcl%KPjo0S`7?WIMu?1qQpkZ\f+i'iZ^^#[c`U;pi%asGHc'pf3&rs1L_?u?/U9 + q2R@mb[pQ?*4t$2=-,NIgSnIN'7P7BDD-kg)-\-NhZ\kd7I)\b3(u + ucb102n(*>k$+CZ*POu=Lllt9cr"P@ijRp_1]0ec]UcXFfVj(U;Zn:K:)3+RhujF/?\4um& + K3au,8im< + ia%\efJE/N_E)@B_Li! + VL9HfLW=H`phRmakA/B!(Y\R([CCofgCmjJ]E62Fm_*56l?Fu0![d1`5CSVR.[_;#-_s>mh + MWVXgrkIeH`/>DIlqjd"1_4Cl`pAehlt4B"ri$i9iMbM#QE%@$ + >Ir#&[K)m\#M(GXu_gkjI$hmcNs*p@%GSnF%._mj@Vo2Y6B,o^>iRmq2:^G5(H[q!XOEn## + sM[eoO5r9r58mtU03L/p];l0b_ULn"^^mfW&L"RoIrn7Msj``C#2!H9CmLj&r?G73o\%.Mj + XnDQAn1skVf-JI>aE?MK)[gqpu'_,6>nRi8Lr:0:bk32gXnY!!%:hkYR*:_W$n`Lt`pE/r2 + +S$XP2^@l`,k>"_nn0a#cpHRTAj#,^ZF=0ECT[O9q_3rC"nI + \D'aLCes8G&6?oVY=R[nHA69_?q2o]K!ApJ:Ge;"YW%od<:skQ]Sp#fZSpL!V!@.kCFp*X>C2e2POAG0)9p1J"2GA$W)B_Id&_:^-)2b#r + >8-d1(NR)M9pM]d2E;(/gpEt"U2fn^`FSAjZpLe[DGB`e:Gk[PMpSW?3[sRkiI.u6@pZI#" + pODrCJG9q3pa:[g2hUlqK_SW&ph,?VGDGsKM"mQ +Q +showpage +%%Trailer +count op_count sub {pop} repeat +countdictstack dict_count sub {end} repeat +cairo_eps_state restore +%%EOF diff -r 9b9a2497757d -r eb146c5c05a8 0__Papers/PRT/PRT__formal_def/figures/Time_layers.svg --- /dev/null Thu Jan 01 00:00:00 1970 +0000 +++ b/0__Papers/PRT/PRT__formal_def/figures/Time_layers.svg Sat Aug 03 19:24:22 2013 -0700 @@ -0,0 +1,198 @@ + + + + + + + + + + + + + + + image/svg+xml + + + + + + + + Program Time + + Program Time + + Physical Time + + Scheduler Time + + + + + + + + + diff -r 9b9a2497757d -r eb146c5c05a8 0__Papers/PRT/PRT__formal_def/figures/VMS-core__internal_workings.eps --- /dev/null Thu Jan 01 00:00:00 1970 +0000 +++ b/0__Papers/PRT/PRT__formal_def/figures/VMS-core__internal_workings.eps Sat Aug 03 19:24:22 2013 -0700 @@ -0,0 +1,1926 @@ +%!PS-Adobe-3.0 EPSF-3.0 +%%Creator: cairo 1.8.6 (http://cairographics.org) +%%CreationDate: Sun Feb 06 23:03:28 2011 +%%Pages: 1 +%%BoundingBox: 0 0 366 156 +%%DocumentData: Clean7Bit +%%LanguageLevel: 2 +%%EndComments +%%BeginProlog +/cairo_eps_state save def +/dict_count countdictstack def +/op_count count 1 sub def +userdict begin +/q { gsave } bind def +/Q { grestore } bind def +/cm { 6 array astore concat } bind def +/w { setlinewidth } bind def +/J { setlinecap } bind def +/j { setlinejoin } bind def +/M { setmiterlimit } bind def +/d { setdash } bind def +/m { moveto } bind def +/l { lineto } bind def +/c { curveto } bind def +/h { closepath } bind def +/re { exch dup neg 3 1 roll 5 3 roll moveto 0 rlineto + 0 exch rlineto 0 rlineto closepath } bind def +/S { stroke } bind def +/f { fill } bind def +/f* { eofill } bind def +/B { fill stroke } bind def +/B* { eofill stroke } bind def +/n { newpath } bind def +/W { clip } bind def +/W* { eoclip } bind def +/BT { } bind def +/ET { } bind def +/pdfmark where { pop globaldict /?pdfmark /exec load put } + { globaldict begin /?pdfmark /pop load def /pdfmark + /cleartomark load def end } ifelse +/BDC { mark 3 1 roll /BDC pdfmark } bind def +/EMC { mark /EMC pdfmark } bind def +/cairo_store_point { /cairo_point_y exch def /cairo_point_x exch def } def +/Tj { show currentpoint cairo_store_point } bind def +/TJ { + { + dup + type /stringtype eq + { show } { -0.001 mul 0 cairo_font_matrix dtransform rmoveto } ifelse + } forall + currentpoint cairo_store_point +} bind def +/cairo_selectfont { cairo_font_matrix aload pop pop pop 0 0 6 array astore + cairo_font exch selectfont cairo_point_x cairo_point_y moveto } bind def +/Tf { pop /cairo_font exch def /cairo_font_matrix where + { pop cairo_selectfont } if } bind def +/Td { matrix translate cairo_font_matrix matrix concatmatrix dup + /cairo_font_matrix exch def dup 4 get exch 5 get cairo_store_point + /cairo_font where { pop cairo_selectfont } if } bind def +/Tm { 2 copy 8 2 roll 6 array astore /cairo_font_matrix exch def + cairo_store_point /cairo_font where { pop cairo_selectfont } if } bind def +/g { setgray } bind def +/rg { setrgbcolor } bind def +/d1 { setcachedevice } bind def +%%EndProlog +11 dict begin +/FontType 42 def +/FontName /f-0-0 def +/PaintType 0 def +/FontMatrix [ 1 0 0 1 0 0 ] def +/FontBBox [ 0 0 0 0 ] def +/Encoding 256 array def +0 1 255 { Encoding exch /.notdef put } for +Encoding 1 /uni0047 put +Encoding 2 /uni0072 put +Encoding 3 /uni0065 put +Encoding 4 /uni006E put +Encoding 5 /uni0020 put +Encoding 6 /uni003D put +Encoding 7 /uni0056 put +Encoding 8 /uni004D put +Encoding 9 /uni0053 put +Encoding 10 /uni002D put +Encoding 11 /uni0063 put +Encoding 12 /uni006F put +Encoding 13 /uni0042 put +Encoding 14 /uni006C put +Encoding 15 /uni0075 put +Encoding 16 /uni0061 put +Encoding 17 /uni0070 put +Encoding 18 /uni0069 put +Encoding 19 /uni0074 put +Encoding 20 /uni0052 put +Encoding 21 /uni0064 put +Encoding 22 /uni0067 put +/CharStrings 23 dict dup begin +/.notdef 0 def +/uni0047 1 def +/uni0072 2 def +/uni0065 3 def +/uni006E 4 def +/uni0020 5 def +/uni003D 6 def +/uni0056 7 def +/uni004D 8 def +/uni0053 9 def +/uni002D 10 def +/uni0063 11 def +/uni006F 12 def +/uni0042 13 def +/uni006C 14 def +/uni0075 15 def +/uni0061 16 def +/uni0070 17 def +/uni0069 18 def +/uni0074 19 def +/uni0052 20 def +/uni0064 21 def +/uni0067 22 def +end readonly def +/sfnts [ +<00010000000a008000030020636d617000a2f14100001fdc0000006c637674207d0742a80000 +2048000002706670676d49d7df92000022b80000060a676c7966489d9ecf000000ac00001f30 +68656164d5ceeae0000028c400000036686865610f7e06b2000028fc00000024686d74785bc6 +0894000029200000005c6c6f636153405a880000297c000000306d617870037c02c9000029ac +0000002070726570292ded16000029cc000004ad00020080015e0380045e0003000700264016 +059c039d049c070017003700030000079c019d049c00002ffdfded012f5f5dfdfded31301311 +211125211121800300fd800200fe00015e0300fd0080020000010050ffe704d305d2001a0137 +403a1c400b0b024b55060103370e470e570e670e04006a167a16025516010506150645060303 +680078000200160c0c024b000f0e0c44170f370f020fb8fff0400b1010024b0f0c0f0f024b0f +b8ffe8400b0c0c024b0f040d0d024b0fb8ffeab40c0c064b0fb8fffab40d0d064b0fb8ffe840 +571010064b0f0645181638160200160c1010024b16060f0f024b16200b0b024b16100c0c024b +16120d0d024b16120c0c064b16120d0d064b160c0e0e064b161b080168017801030223100103 +2813011803380302020c510eb8ffc0401a0c0c024b0e090118000100001909100b0b024b0949 +1303491913b8fff0b70b0b024b13091903003f3f2b10ed10ed2b10cd5f5d3210d62bed5f5d5d +5f5d5f5d0110d62b2b2b2b2b2b2b2b5f5dfdd42b2b2b2b2b2b2b5dfdcd10c62b5d5f5d5d5d5f +5d5f5d3130012b010726232200111400333237112335211106042320001110002132048d5397 +91e6fef60105e1a063cb019350fee287fed1fea101810147e50553a570febcfef5fefeca6001 +57aafd824453019b0155015401a7000100960000031c0443000e00af401e0a400b0d024b0810 +18102810c81004c70ed70e020e06094d064d68070107b8ffecb41313024b07b8ffeeb4101002 +4b07b8fff240110f0f024b07040b0b024b07040c0c024b07b8ffeeb40f0f064b07b8fffcb40c +0c064b07b8fff2b41010064b07b8fffc40250e0e064b070f170a270a370a470a570a670a0600 +050a400e0e064b0a02520c0806070a0c07003f3f3f10edcd2b325f5d0110d62b2b2b2b2b2b2b +2b2b5deded10c65d5d3130002b01262322061511231133153633321702cd3e3f6597bebe68cd +336003782bba83fd9a042fabbf1200020041ffec041c04430019002201ff408724400b0b024b +58170103b807018a079a07aa07ba07ca07da0706025705016808780888089808a80805280838 +08480858086808780888089808a808b808c808d8080c00571877180208221010024b08180f0f +024b08180c0c024b082c0d0d024b08100c0c064b08100d0d064b081f4e471e01021718371847 +18671887189718a718b718c7180918b8ffe0b40e0e064b18b8ffdeb41010024b18b8ffdcb40f +0f024b18b8ffe2b40c0c024b18b8ffd4b40d0d024b18b8ffe4b40c0c064b18b8ffe4406b0d0d +064b18011e4e014e87100138104810581068100410100e0e064b10101010024b10100f0f024b +101c0b0c024b10160d0d024b100c0c0c064b100c0d0d064b102387079707a707030027053705 +47055705040207522a083a084a08030357086708770803070817080208b8ffc0b40b0c024b08 +b8ffd4b40d0d064b08b8ffc040350d0d024b080c1e50470157016701a701b701050001400f0f +024b01400d0d024b01400f0f064b010105581a011a5214100f0f024b14b8ffe8b40d0d024b14 +b8ffe840200e0e064b140c0f0f064b14671401024a145a140205100c0c024b05520c0b140700 +3f3fed2b5d5f5d102b2b2b2bed5d11392f2b2b2b5f5ded10d52b2b2b5d715f5ded5f5d5f7101 +10d62b2b2b2b2b2b2b5d5deded10dd2b2b2b2b2b2b2b5d5f5dedc42b2b2b2b2b2b5d5f5d715d +5f5d5d5f5d3130012b0121141716333237170607062322272635103736333217161514012207 +060721342726040dfcfc675b8fa36d502c5b728cca8d9da190c5e5827efe247f56520b025148 +4f0205bc65585f892c202a8997ff0109a08f817ccd3f0169524e74734d5400010087000003d8 +044300110103401813400b0b024b070f170f0201771301004d11101010064b11b8ffd4b40e0e +064b11b8fff8b41313024b11b8fff440111010024b110a0f0f024b11080c0c024b11b8fff440 +110d0d024b111c0b0b024b110e0f0f064b11b8fff8b40c0c064b11b8fff8b40d0d064b11b8ff +f440100b0b064b11084d070917092709030009b8fff4400b1313024b09040d0d024b09b8fff6 +b41010024b09b8fff4400b0f0f024b090a0b0b024b09b8fff8b41010064b09b8fff4400b0e0e +064b09080c0c024b09b8fffa40110f0f064b091204520e110a090a0a060e07003f3f3f3f10ed +0110d62b2b2b2b2b2b2b2b2b5f5dfdd42b2b2b2b2b2b2b2b2b2b2b2bed5d3130005f5d012b21 +1134262322060711231133173633201111031a6779418e26be823c5ed50160026fab894e39fc +e4042f8a9efe54fd690000000002007a018b03c0036c00030007002d401b0105870207061706 +37065706770605060803840207840706010006002f5f5dfddeed0110d65d3cfd3c3130011521 +350115213503c0fcba0346fcba036c8d8dfeac8d8d0000000001000dffec04a605b900060133 +b10202435458b90004ffe8400d0c0c024b040402010502020201002f3f3f111239012f313000 +2b1bb10602435458403804601010064b04400c0f064b04100a0a064b47080100370401010808 +18082808580804054606034602067600027601040400754701010104b8ffc0b42227064b04b8 +ffb0b41a1d064b04b8ffc040261416064b04240b0b064b480401370401170427043704570467 +0477040600048e010906020202003f3f3fed5f5d72712b2b2b2b012f5ded39192f1810ed10ed +10ed10ed5d5f725f5d3130002b2b2b1b40414708010037040101080818082808580804054606 +0346020676000276010404007547010101480401370401170427043704570467047704060004 +8e010906020202003f3f3fed5f5d7271012f5ded39192f1810ed10ed10ed10ed5d5f725f5d31 +30595905230133010133029465fddede0179016bd71405cdfbc90437000000010014ffec05a3 +05b9000c01f0401401400e0e064b04400e0e064b0e401010024b0002435558401d0c0e180e28 +0e380e03080e180e380e480e580ea80eb80e070606080702003f3f012f5d7110d631301b40ff +4a030145020143087308024c0a7c0a0203280301280a0127080102970101980401870701880b +0101180e280e380e03080e180e380e480e580ea80eb80e070000460c0546380c480c02370647 +0602022806480602270c470c020672070c720b01010a0b04040875070a75680b016707010b73 +0207730309090275c70301270377038703a703d703e703060003770901016709010809180902 +680988099809a809b809c809d809e809f80909580101580401004a0201034701014704010107 +011701020701270187019701a701b701c701d701e701f7010a07041704020704270487049704 +a704b704c704d704e704f7040a070117010217014701570167017740490187019701a701b701 +c701d701e701f7010d0704170402070417042704470457046704770487049704a704b704c704 +d704e704f7040f00097102017104710702090c0806080b020702003f3f3f3f3f10ede410ed5f +5d715d715d715d715f5d5d5f5d5f5d5d5d715d5f5d012f5f5d71ed39192f1810ed10fd5d5ded +10ed39192f1112392f1810ed10fd5d5d5f5d5ded10ed5f5d715f5d5d5d5d5f5d5d5d5f5d5d5d +5d3130592b002b2b2103012301032301330101330104e5aefec032feb7aabe01125b015d0142 +5a012903adfc3f03c1fc5305b9fbd3042dfa470000010050ffe7038805d2002601ccb1020243 +5458401907221a0e180b0b024b0e120c0c024b0e22070e1a0425131714b8ffc040120c0c024b +1411000401251749110304492509003fed3fed10cd123910cd2b1239121739012f2b2bcd2fcd +31301bb106024354584086082401071001002520452065207520042a0b01034828a828026813 +0113074507223722672203221a001a45380e01870e01000e2777040102351e651e751e03351f +451f651f751f040a0c3a0c4a0c6a0c7a0c0533220103380e010a0b1f1e042548145814681478 +1404141137014701570167017701a701b70107000125174911044925091103003f3fed10ed10 +cd5f5d10cd5d1217395d5f5d5d5d5d5f5d0110d65f5d5dedc410d45dedc45d5d3130005f5d5d +5f5d5d1b4086082401071001002520452065207520042a0b01034828a8280268130113074507 +223722672203221a001a45380e01870e01000e2777040102351e651e751e03351f451f651f75 +1f040a0c3a0c4a0c6a0c7a0c0533220103380e010a0b1f1e0425481458146814781404141137 +014701570167017701a701b70107000125174911044925091103003f3fed10ed10cd5f5d10cd +5d1217395d5f5d5d5d5d5f5d0110d65f5d5dedc410d45dedc45d5d3130005f5d5d5f5d5d5959 +3737161633323635342627272626353436333217072626232206151416161717161615140423 +22544938a742758e4f9f769677e8b6f35f3b28a44666752a4b74789679fef7dec343b8293780 +634a7f4b3746c087a4d84fae1d36745b385c3e383947c598a5e60001009f01fa024b02a90003 +00254017280368037803a803040307002700370003000004014800002fed0110d65f5dcd5d31 +30133521159f01ac01faafaf000000010041ffec03b5044300170119401e450501a101010328 +1938190200870d970da70d030200070d870d970d030db8fff4b41010024b0db8ffeab40f0f02 +4b0db8ffeab40b0c024b0db8ffe840610d0d024b0d074e38124812028712a712b712c712e712 +050012101010024b12180f0f024b12200b0c024b12180d0d024b12060e0e064b120c0e0e064b +12120c0c064b12100d0d064b1218250a350a450a032a043a044a0403030c52070d170d020db8 +ffc040160b0b024b0d0f015208001800020000400b0b024b0004b8ffe8b40c0c024b04b8ffe8 +40190d0d024b0452150a180c0c024b0a180d0d024b0a520f0b1507003f3fed2b2b10ed2b2bdd +2b5f5ded10dd2b5ded5f5d5d0110d62b2b2b2b2b2b2b2b5f5d5dfdd42b2b2b2b5d3c5f5d5f5d +5f5d5d313001072626232206151416333237170623220035100021321603af5e1d93479bb6ba +a580824b99e2dbfee20129010253c203d8861d34d9bdbcc563a0630126fb0100013646000002 +0041ffec040a0443000b0015013c402517401010024b17400b0c024bb7050101381701114e17 +063706470667060406041010024b06b8ffdeb40f0f024b06b8fffcb40b0b024b06b8ffe4b40c +0c024b06b8ffd4b40d0d024b06b8ffeab40e0e064b06b8ffe0b40c0c064b06b8ffe440760d0d +064b060c4e87009700a700b700c700e700063800480058006800040000101010024b000e0f0f +024b00200b0b024b00200c0c024b00160d0d024b000c0e0e064b00100c0c064b000c0d0d064b +00166a030165090103670e0168130102450e550e650e034a135a136a13030e100f0f024b0e52 +0913b8fff040160f0f024b13520309180f0f024b09180f0f064b090b03b8ffe8b40f0f024b03 +b8ffe8b50f0f064b0307003f2b2b3f2b2b10ed2b10ed2b5d5d5f5d5d5f5d5d0110d62b2b2b2b +2b2b2b2b5f5d5dfdd42b2b2b2b2b2b2b2b5ded5d5f5d31302b2b133400333212111000232200 +1310213236351021220641010bdae6fefefce0e5ff00c8011d8597fee4829b021af80131fedb +fefcfefdfed5012e0100fe6dd8bb018ed400000300960000043705c6000f0018002201ac406f +24400b0b024b05060103580a680a02a805b805c805030178150102480a780a880a980aa80ab8 +0ac80ad80ae80af80a0a0a1545380748070207200b0b024b071e0c0c024b07160d0d024b0710 +0c0c064b07100d0d064b07220e0e064b070d10441a44011f45070d170d270d370d040db8fffa +400b1010024b0d100b0b024b0db8fff4b40c0c024b0db8ffd8b40d0d024b0db8fff4b40e0e06 +4b0db8fff4b40c0c064b0db8fff4400f0d0d064b0d24070117012701030001b8ffecb4131302 +4b01b8fff4b41010024b01b8fffa400b0f0f024b01040b0b024b01b8fffeb40d0d024b01b8ff +eab41010064b01b8fff0b40e0e064b01b8ffff40330c0c064b0123671c0101371c471c571c03 +020a0a111348190722014722572267227722041722372247229722c722f722060022b8ffc0b4 +0f0f024b22b8ffc0401f0f0f064b22100d0d064b22221a17021048041a1c200f0f024b1c4801 +080402003f3fed2b3210ed333211392f2b2b2b5f5d717233ed3239192f5f5d5f5d011810c62b +2b2b2b2b2b2b2b5f5d10d62b2b2b2b2b2b2b5ded10eded10d42b2b2b2b2b2b5dedc45d5f5d5f +5d31305d5f5d012b212111243332161514060716161514040111163320353421220311163332 +36353426230238fe5e010b76d9ee985cae9ffee5fe423f5d011cfefb644f6737bcada5c105b9 +0dbbae66a8152ac2a7c1e60519fe5b06e7cbfdb9fdd10a8d9a8f8800000000010096ffec0207 +05e6000800c7b9000affc0b41313024b0ab8ffc0b41010024b0ab8ffc0402a0c0c024b070a17 +0a270a370a470a570a670a770a080706170627060306024d070117012701d701040001b8ffec +b41313024b01b8ffeeb41010024b01b8fff240110f0f024b01040b0b024b01040c0c024b01b8 +ffcc40170e0e064b01180f0f064b01130c0c064b01160d0d064b01b8ffec401b0b0b064b0109 +b705c70502010a081a082a083a08040652070b0100003f3fed5d5f5d0110d62b2b2b2b2b2b2b +2b2b2b5f5dfdc65d5d3130012b2b2b13113311141633152096be6350fe8f012f04b7fb695663 +aa0000000001007dffec03e3042f001200fb402714400b0b024b7714010a4d074d0708011708 +47087708a708048708b708e70803080c1010064b08b8fffab40e0e064b08b8ffecb41313024b +08b8ffec400b1010024b08160b0b024b08b8ffeeb40d0d024b08b8ffccb40e0e064b08b8fff0 +b40c0c064b08b8fff440150d0d064b08004de812f81202071217122712030012b8fff8b41313 +024b12b8fffab41010024b12b8fff640230f0f024b120c0b0b024b120c0c0c024b12080d0d02 +4b12040c0c064b12040d0d064b12b8fffa40110e0e064b121303520e090a0e0b08061206003f +3f3f3f10ed0110d62b2b2b2b2b2b2b2b2b5f5d5dfdd42b2b2b2b2b2b2b2b2b5d7172eded5d31 +30012b01111433323637113311233506062322263511013bd75e9c19bebe20c15cb0bb042ffd +55f86c4702f0fbd1943f69caba02bf0000020050ffec03e40443001b002501d3b62740101002 +4b25b8ffecb40b0c024b25b8ffee40490d0d064b071317130201672077200202280f480f0200 +b70fc70fd70fe70f04010025150f0537184718571867187718871897180718254d0a4d881501 +150c1313024b150c1010024b15b8fff8b40f0f024b15b8fff040110c0c024b151e0d0d024b15 +0c0e0e064b15b8fff040440f0f064b150c0d0d064b1527214e38050100050c0f0f024b05160b +0b024b05100c0c024b05120d0d024b050c0e0e064b050c0c0c064b050c0d0d064b05263a0301 +032500b8ffc0b40d10024b00b8ffc040320d0f064b480058006800780004000218191c520a08 +0e52080f180f280f380f480f580f980fa80fb80fc80fd80fe80f0c000fb8ffc0b41317024b0f +b8ffc040240d0d024b0f124a1e5a1e02031e52a808b80802580801006a087a08020347085708 +020008b8ffc0b41414024b08b8ffc0b41313024b08b8ffe8b41010024b08b8ffe8b40f0f024b +08b8ffc040131313064b08080c2352020c5212190b020b1207003f3f3f10ed10ed11392f2b2b +2b2b2b5f5d5f5d5f5d5ded5f5d10dd2b2b5f5ded10d5ed10cd10dd5d2b2bcd5f5d0110d62b2b +2b2b2b2b2b5f5ded10d62b2b2b2b2b2b2b2b71ededc65d10c41112395f5d5f5d5f5d3130005f +5d2b2b012b250623222635342433321710232207273636333216151114171522260326232206 +151433323702e472eb7eb9011ddd3c4ce8b2605036bf57e9d35474732b5a2490b6c5906f7b8f +b788a3e11a0104609f2c3fd4e7fe808d2f5f4201df149465a78900020087fe5c042c0443000f +001b014d40161d400b0b024be71d01164e470af70a02470a970a020ab8ffe4b40f0f024b0ab8 +ffeab40c0c024b0ab8ffd4b40d0d024b0ab8fff4b40e0e064b0ab8ffe6b40c0c064b0ab8ffea +401e0d0d064b0a111101044d014d1702010702170227028702e702f702060002b8fff4b41313 +024b02b8fff6400b1010024b02040d0d024b02b8fffa40110f0f024b020a0b0b024b02080c0c +024b02b8fff4b40e0e064b02b8fffe40330f0f064b02020c0c064b02020d0d064b021c580d68 +0d025707670702024514014a190114100e0e064b14100f0f024b14520d19b8fff0b40e0e064b +19b8fff0400c0f0f024b195207010e03060db8fff0b40e0e064b0db8fff040140f0f024b0d0b +07100e0e064b07100f0f024b0707003f2b2b3f2b2b3f3f10ed2b2b10ed2b2b5d5d5f5d5d0110 +d62b2b2b2b2b2b2b2b2b2b5f5d71eded103c10d42b2b2b2b2b2b5d71ed5d31302b2511231133 +15363332121114002322260311161633201134262322060145bebe6c99e4feff00f2449b1612 +74370162a8b928743bfe2105d3586cfee4feeef4fecb30032cfd901b310190cbbc3800000002 +0050000001c105c4000b001100d9b613400f0f024b13b8ffc0b60d0d024b097b03b8fff4b40e +0e064b03b8fff8b40f0f024b03b8fffab40c0c024b03b8fff940200c0c064b03110e0c4d7711 +010011041313024b11021010024b110e0f0f024b11b8ffeeb40b0b024b11b8ffecb40c0c024b +11b8ffe6400b0d0d024b110e0f0f064b11b8fff8400b0c0c064b11120d0d064b11b8ffd64010 +0e0e064b11081111064b11130d511000b8ffc040120f0f024b007c06400f0f024b06100c0a10 +06003f3f10d62bed2b10ed0110d62b2b2b2b2b2b2b2b2b2b2b5f5dfdc610d42b2b2b2bed3130 +012b2b013216151406232226353436031123352111014b314545313045443793015105c44530 +314545313144fa3c038fa0fbd10000000001004fffec02fc0558001500cab90017ffc0403f0c +0d024b0813181302281701871001109708010809010006090309010c0c064b094d4800580068 +00f8000400000c1313024b000a1010024b00120f0f024b00b8fff2b40b0b024b00b8fff0b40c +0c024b00b8ffe8401d0d0d024b00160e0e064b00100f0f064b00260c0c064b00280d0d064b00 +b8fffc401b0e0e064b002c133c13020f0d0205070d52120152085207120b0706003f3f10eded +10ed10c63c10c65d012f2b2b2b2b2b2b2b2b2b2b2b5f5ded2b3c103c10cd10dd5dc65d5d3130 +005d012b13233533353711211521111416333237170623222635cb7c7cbe0126feda5b65494e +1c768d7faf039996e049fed796fdec877225a71ebd90000200a0000004a805c8000f001a0106 +4017670e770e02010e040b00460f0f1c16060d0d064b16450bb8ffe8b40b0b024b0bb8ffea40 +120d0d024b0b471c1044044407052705020005b8ffe4b41313024b05b8fff2b40f0f064b05b8 +fff0b41010024b05b8fff4b40f0f024b05b8fffcb40c0c024b05b8fffab40d0d024b05b8fffe +b40c0c064b05b8fff4b40d0d064b05b8ffeab41010064b05b8fff040290e0e064b051b481701 +0245150103570e01025513015a196a197a1903101906090e1103134901010519b8ffe8400d0f +0f024b194909000805080902003f3f3f10ed2b11392fed333233113311335d5d5f5d5f5d5f5d +0110d62b2b2b2b2b2b2b2b2b2b5f5deded10f62b2bed2b103c10ed111239395d313021012227 +112311322433201114060701011116333236353426232203c3fe794391c80b0121420210aa75 +01a9fcc04844b4a4b0be1e02750afd8105b90ffe5c8add1bfd5e0505fe240a74957b6c000002 +004bffed03ec05e6000e0019011e40161b400b0b024b004d0d190c4d470d010d201313024b0d +b8ffeab41010024b0db8fff6400b0f0f024b0d080b0b024b0db8fff6b40c0c024b0db8ffe440 +0b0d0d024b0d0c0f0f064b0db8ffe2b40c0c064b0db8fff240660d0d064b0d140c0c0c064b14 +4e87060138064806020006080f0f024b061a0b0b024b061a0c0c024b06120d0d024b060c0e0e +064b06100c0c064b060c0d0d064b061a251635164516032a113a114a11030358036803021618 +0b0c024b16100f0f024b16520311b8ffe8400e0b0c024b115209480901020e0a03b8fff0b60f +0f024b030b09b8ffeeb70d0d024b09070d00003f3f2b3f2b3f5f5d10ed2b10ed2b2b5d5f5d5d +0110d62b2b2b2b2b2b2b5f5d5dfd2bd42b2b2b2b2b2b2b2b2b5dfd3c10ed3130012b25350623 +22023534003332171133110326232206151021323637032e63bdc9fa0120c7a656bebe487d99 +bd01602d7e10014f630120f0f101554e01f1fa1b03366ce4b0fe7d392000000000020050fe5c +03c804740030003c0160402c48195819681978190400272b372b020265017501020320101c12 +064e282b382b482b582b682b782b882b072bb8ffeab40e0e064b2bb8fff0400f0d0d064b2b19 +3a4e1c0e1010024b1cb8fff440860c0c024b1c120d0d024b1c3e00234e0d344e12060e0e064b +120c0f0f024b12120b0c024b12120d0d024b123d17010188199819a819b8190488189818a818 +b81804280c380c02006701770102026a317a3102653775370203102037281a171f181537180f +0f024b37521f40090a064b1f9708a708b70803970ba70bb70b030028530825530b01b8ffc0b4 +1114024b01b8ffc0b40b0c024b01b8ffc0b41114064b01b8ffc040090c0c064b0103522e31b8 +ffe8400d0f0f024b3152152e0e0b061507003f3f3f10ed2b10fdc62b2b2b2b10edd4fd5f5d5d +d42bed2b10c6123939111239395f5d5d5f5d5f5d5d5d5d0110d62b2b2b2bedd4edc610d62b2b +2bedc6d42b2b5ded111239395f5d5f5d5f5d3130133716333236353423220623223534363726 +1134363332173717071615140607070606151433323633321615140423222601220615141633 +32363534266067a68c8195bc20a82fe46b4fe2eaac9e595f7c7249caa49d1c5e622bb62c9eb1 +fef7cb68e6014d637d796765727bfedb986f59428220ac3556136a0106a8e0417275565f99a2 +dc101003251e291f978694b64a05048c6470938f74648c000000000200030000000000140001 +0000000000340004002000000004000400010000f016ffff0000f000ffff1000000100000000 +000600380000000000170000000100020003000400050006000700080009000a000b000c000d +000e000f001000110012001300140015001605e6000005b9001905b90014042f00140000ffe7 +0000ffec0000ffecfe5c000005c30000fe5400000338000005d300000253000005c8000a0000 +0000000000000000000000000000000000000000000000000000000000000000000000000000 +0000000000000000000000000000000000000000000000000000000000000000000000000000 +000000c800cd00cd009600b400b400000000000000be00c800c8008c00a0009b009600000000 +00be00c800c8000000aa00aa000000000064007d0082008c009600a00064007d0082008c009b +00d20064007d0082008c009600a002300136011801a401d600460218012c01c2000001d600eb +00eb01d1017f0154011301450168012c008d02350159033f0505012c00b4006e0136015e01cc +01cc04d8006e006e01d600d2005f01f4012c007802d00190037f00800280006e00b4000000a5 +fea2003200b9008c000000000000000000000000000000000000000000000000000000000000 +0000000000000000000000000000000000000000000000000000000000000000000000000800 +05e6000005b9001905b90014042f00140000ffe70000ffec0000ffecfe5c0000000000000000 +0000033800000000000002530000000000000000000000000000000000000000000000000000 +0000000000000000000000000000000000000000000000000000000000000000000000000000 +0000000000000000000000000000000000000000000000c800cd00cd009600b400b400000000 +000000be00c800c8008c00a0009b00960000000000be00c800c8000000aa00aa000000000064 +007d0082008c009600a00064007d0082008c009b00d20064007d0082008c009600a04036544b +214a494847464544434241403f3e3d3c3b3a39383736352f2e2d2c2826252423221f18141110 +0f0d0b0a090807060504030201002c4523466020b02660b004262348482d2c452346236120b0 +2661b004262348482d2c45234660b0206120b04660b004262348482d2c4523462361b0206020 +b02661b02061b004262348482d2c45234660b0406120b06660b004262348482d2c4523462361 +b0406020b02661b04061b004262348482d2c0110203c003c2d2c20452320b0cd442320b8015a +51582320b08d44235920b0ed51582320b04d44235920b0042651582320b00d44235921212d2c +20204518684420b001602045b04676688a4560442d2c01b10b0a432343650a2d2c00b10a0b43 +23430b2d2c00b0282370b101283e01b0282370b10228453ab10200080d2d2c2045b003254561 +64b050515845441b2121592d2c2045b0004360442d2c01b00643b00743650a2d2c2069b04061 +b0008b20b12cc08a8cb8100062602b0c642364615c58b00361592d2c8a03458a8a87b0112bb0 +292344b0297ae4182d2c4565b02c234445b02b23442d2c4b525845441b2121592d2c01b00525 +1023208af500b0016023edec2d2c01b005251023208af500b0016123edec2d2c01b0062510f5 +00edec2d2c20b001600110203c003c2d2c20b001610110203c003c2d2c00b00743b006430b2d +2c21210c6423648bb84000622d2c21b08051580c6423648bb82000621bb200402f2b59b00260 +2d2c21b0c051580c6423648bb81555621bb200802f2b59b002602d2c0c6423648bb840006260 +23212d2c4523456023456023456023766818b08062202d2cb00426b00426b00425b004254523 +4520b003266062636820b0032661658a2344442d2c2045b0005458b040442045b04061441b21 +21592d2c45b1302f4523456160b0016069442d2c4b5158b02f2370b01423421b2121592d2c4b +515820b0032545695358441b2121591b2121592d2c45b01443b0006063b0016069442d2cb02f +45442d2c452320458a60442d2c45234560442d2c4b235158b90033ffe0b134201bb333003400 +5944442d2cb0164358b00326458a586466b01f601b64b020606620581b21b04059b001615923 +586559b02923442310b029e01b2121212121592d2cb0164358b004254564b020606620581b21 +b04059b0016123586559b0292344b00425b00725082058021b0359b0052510b004252046b004 +2523423cb0072510b006252046b00425b0016023423c2058011b0059b0052510b00425b029e0 +b0072510b00625b029e0b00425b00725082058021b0359b00425b003254348b00625b00325b0 +016043481b2159212121212121212d2cb0164358b004254564b020606620581b21b04059b001 +6123581b6559b0292344b00525b00825082058021b0359b0042510b005252046b0042523423c +b00425b0072508b0072510b006252046b00425b0016023423c2058011b0059b0042510b00525 +b029e0b02920456544b0072510b00625b029e0b00525b00825082058021b0359b00525b00325 +4348b00425b0072508b00625b00325b0016043481b2159212121212121212d2c02b004252020 +46b004252342b0052508b003254548212121212d2c02b0032520b0042508b002254348212121 +2d2c452320451820b00050205823652359236820b040505821b04059235865598a60442d2c4b +53234b515a5820458a60441b2121592d2c208a08234b538a4b515a5823381b2121592d2c0020 +8a49b0005158b04023208a3812341b2121592d2c462346608a8a462320468a608a61b8ff8062 +232010238ab14b4b8a70456020b0005058b00161b8ffba8b1bb0468c59b0106068013a2d2c20 +8a2349648a2353583c1b21592d2c4b505845441b2121592d2cb0024354584b53234b515a5838 +1b2121591b21212121592d2cb1020042b123018851b1400188535a58b910000020885458b202 +010243604259b12401885158b920000040885458b2020202436042b12401885458b202200243 +6042004b014b5258b2020802436042591bb940000080885458b202040243604259b940000080 +63b80100885458b202080243604259b94000010063b80200885458b202100243604259b94000 +020063b80400885458b202400243604259595959592d00000001000000050000f72805665f0f +3cf5001b080000000000ad61b71900000000c142e956ff50fde708a8078b0000000a00010000 +00000000000100000783fe39000008e9ff50ff7808a800010000000000000000000000000000 +00170400008005690050031c0096045d0041045f0087026900000432007a04b3000d05ad0014 +03d9005002f0009f03f60041044b004104870096025c0096045f007d04340050047500870248 +0050032c004f04a800a00475004b040400500000002800f40166029e03400340036c041a0532 +06520672072807f0090009780a160b380c0e0c9c0d240dd60e920f98000100000017004d0007 +004b000500020010002f0055000002f001ff00030001400a54bfa50140a5111546a4b8010cb2 +321fa1b8011540b21f1f6fc731216ec731216dc731216cc731216bc731216ac7312169c73121 +68c7312167c7312166c7312165c7312164c7312163c7312162c7312161c7312160c731215fc7 +31215ec731215dc731215cc731215bc731215ac7312159c7312158c7312157c7312156c73121 +55c7312154c7312153c7312152c7312151c7312150c731214fc731214ec731214dc731214cc7 +31214bc731214ac7312149c7312148c7312147c7312146c7312145c7312144c73121b80137b2 +6f0821b80136b26e0821b80135b26d0821b80134b26c0821b80133b26b0821b80132b26a0821 +b80131b2690821b80130b2680821b8012fb2670821b8012eb2660821b8012db2650821b8012c +b2640821b8012bb2630821b8012ab2620821b80129b2610821b80128b2600821b80127b25f08 +21b80126b25e0821b80125b25d0821b80124b25c0821b80123b25b0821b80122b25a0821b801 +21b2590821b80120b2580821b8011fb2570821b8011eb2560821b8011db2550821b8011cb254 +0821b8011bb2530821b8011ab2520821b80119b2510821b80118b2500821b80117b24f0821b8 +0116b24e0821b80115b24d0821b80114b24c0821b80113b24b0821b80112b24a0821b80111b2 +490821b80110b2480821b8010fb2470821b8010eb2460821b8010db2450821b8010c40ff4408 +216957311f5857311f5657311f5152311f4644311f4544311f4f4e311f4d4e311f2097309740 +975097043088010f8c018f849f84af84bf84cf84058f689f68af680360697069028f5b018f5a +017057018f509f50af50bf50cf50058f519f51af51038f529f52af52033f7c4f7c02507b607b +707b03704e01708f01308f608f708f03008e01008e01408e708e02008e308e408e508e608e70 +8e06107040700260740160730170440100282800000012110840370f3fce16010fa21fa20218 +c7312114c731210ec731210dc731210cc731210bc731210ac7312109c7312108c7312107c731 +2106c7312105c7312104c7312103c7312102c7312101c73121407c00c73121e0180821dc1408 +21d60e0821d50d0821d40c0821d30b0821d20a0821d1090821d0080821cf070821ce060821cd +050821cc040821cb030821ca020821c9010821c8000821230e45220c45210a452008451f0645 +1e04451d02451c00451a08180816081408120810080e080c080a08080806080408020800084b +b807ff524bb008505b58b101018e59b0124b004b5442b9000101ff858d2b2b2b2b2b2b2b2b2b +2b2b2b2b2b2b2b2b2b2b2b2b2b2b2b2b2b2b2b2b2b2b2b2b2b2b2b2b2b2b2b2b2b2b2b2b2b2b +2b2b2b2b2b2b2b2b2b7342011d4bb01b5358b0961d594bb0325358b0001db1160042594b20b0 +325323b096515a58b0301d592b0145695342014b5058b108004259435c58b108004259161070 +3eb13737456920b0005458b040605944b1300070b33200300019701870737373737373747473 +737373737373737373737373737373732b2b2b2b2b2b2b2b2b2b2b2b2b2b2b2b2b2b2b2b2b2b +2b2b2b2b2b2b2b2b2b2b2b2b2b2b2b2b2b2b2b2b2b2b2b2b2b2b2b2b2b2b2b2b2b2b2b2b2b2b +2b2b2b2b2b2b2b2b2b2b2b2b2b2b2b2b2b2b2b2b2b2b2b2b2b2b2b2b2b2b2b2b2b2b2b2b2b2b +2b742b00000000> +] def +FontName currentdict end definefont pop +%%Page: 1 1 +%%BeginPageSetup +%%PageBoundingBox: 0 0 366 156 +%%EndPageSetup +q +0.0823529 0.580392 0.0823529 rg +BT +8 0 0 8 222.394666 145.083551 Tm +/f-0-0 1 Tf +[<010203>1<0304>]TJ +ET +0 g +BT +8 0 0 8 244.004041 145.083551 Tm +/f-0-0 1 Tf +<0506050708090a0b0c0203>Tj +ET +0.0117647 0.0117647 0.721569 rg +BT +8 0 0 8 298.536267 145.005426 Tm +/f-0-0 1 Tf +<0d0e0f03>Tj +ET +0 g +BT +8 0 0 8 314.161267 145.005426 Tm +/f-0-0 1 Tf +<0506051011110e120b1013120c04>Tj +ET +0.588235 0.0392157 0.0392157 rg +BT +8 0 0 8 162.495227 145.005426 Tm +/f-0-0 1 Tf +<140315>Tj +ET +0 g +BT +8 0 0 8 175.963977 145.005426 Tm +/f-0-0 1 Tf +<050605110e0f160a1204>Tj +ET +0.8 w +0 J +0 j +[ 0.4 0.4] 0 d +4 M q 1 0 0 -1 0 155.935211 cm +106.051 133.129 m 85.43 122.164 70.191 113.375 70.191 113.375 c S Q +72.852 38.791 m 69.273 43.08 l 74.777 42.131 l 73.484 41.564 72.711 +40.213 72.852 38.791 c h +72.852 38.791 m f* +Q q +q 0 0 367 156 rectclip +% Fallback Image: x=0, y=0, w=365, h=155 res=300dpi size=2955450 +[ 0.24 0 0 0.24 0 0.895211 ] concat +/DeviceRGB setcolorspace +8 dict dup begin + /ImageType 1 def + /Width 1525 def + /Height 646 def + /BitsPerComponent 8 def + /Decode [ 0 1 0 1 0 1 ] def + /DataSource currentfile /ASCII85Decode filter /LZWDecode filter def + /ImageMatrix [ 1 0 0 -1 0 646 ] def +end +image +J3P/PW$E,P#D#)]Yda6_*=IZk@Smti:+[9:6_dMgggVWNO%&)l3,F"ku50(ntAUMcm)Oo767PIW6f'4L\5 + \kA?XR`oI6ngb@$B1Xu2,k(=?iT>clVY*TH%*\_C`i]H,l'I_aEM\,-pfWJ.h;Yh9F33aZ( + 0aK`4DVIpEFWTEaCRq?tVS%dgY=GpbJ,H]O/Zl3]AP@]X%lggJ"c+[?Ad(f6041Y3,bl8*7kdSpsb88$VLUH@&DRa+9rLG^FoND + ^X2u4q@0,r4R%'`mh`+CX3-Y/Xua.5d1A%#rg$9-NZ;D;c(\#%]h;k6Ed`o#K06XUA708PM + G:_:Ffu[_f+m=#JX*b1AAfWRnX)R%nq*]_D+/;'#*l]AK8dRj:r0DD'</)Cuj8$UR*aGhHQ:WH5:"[l7o(VX,8eMp?*>#:mN.qtEUlFd_WYn4=0H,Zf/(A1]qs%_DgQtSd + rO.QKg9Z!7glQlR\+k)oNfIXcLtO.;;1iK[iMO@*Ij(9pn#6MAp?Km\^u.5-`PRA*VL)_o3 + DmSNrCnS"dFBUs0L'u*S7sa?&NlR:(;K_=8q==S#Loj[HfrQmdhD3[sZIF#JesToA!9NI]q + `/_$9E*hFn`'mVW'A`_uo19C-Om*W8s* + aU;=j`em/1[C2Ih5"I0%7EPKS.<,mE\^69.6`&'H8Lf5AjeHY)^(tFX-(iOk=HO`WMP0`Pp^rV`q0sgSS;B53(.-27%ZViTk`HM??6_I!2!"#'R7S`58U4(BAq[=S;d+*6fi^&lN7= + .L12T[pf/=sB,b/Qa782qCPG[..T/$mpapIG\,h1tD1M0_7oO0m0]Z6RB*`u)rP-.CB8jEskH]BYl5;j`XV.=KqMEWM0g)ERs.r[-Qr4hg6k4V*85mA[ + OHKs:)e+([eIJ + *Va]2/00mY-qBbh-93!E@3Wd\lW)&?0fITY>qa4=1\?;lihsE\9M0#f"_f4 + /WNOg8"_b#[g;ASf>"NW]Zra.aJ:m002jMFREmKLG:8s,WDEZm + i(QS&lHae9=7Hq@LT(QD_`HuIHn%KU`qHH&7I;d+#[9)5`>q>#dDJc#](_6Z)bR&jhD?don + )ZSa-M1DgR&\T#3$"7&9KeTpG_73\YiLE&UDQY)"=%<[.4)'IhQ70](Y1qr?f+;[4&B1$_) + Im#hNUb"Ka&qdOA))KnnchD$=Uu]e>`Fm:7S1^)0.(5bSWiW!;9E$;.V2keQ1Dptb?8a9AZ + -o68+p64=cY=M>g8].7VU+MY;U"Jh4+"jER%_53bM^bSb'jHcWT^#BAEHXoEGULOjUS5Pi% + A*%Z/S:01KX2*M`7]Oj[E/8nhQ_V=_cqdopZbC#(qMo`h,6`61J\>^gIA^fIF_ + i44Y=n=R/+eX`_Xjf37';lOg9J`?!>IUS)^Ec&JlL5/#WQb]=1iMfa,U`S!=KA8PV=XEGHE + \g'mAM1)A2pBJ_TTh$V<@>GpkY2A&>>@)2dlZKZR;Vc\TG&*XuY\o3KhL"^;K>"%e2Ko#TS + .BH']t;(i7^:f3RriV@#J51LnD'NqJT#sjYrJWZffT2sD&tLNp!3fQ)foq;Y"c_,?.7WbIs + LJM-+pcQ+6)&I@n45^+I\+s*qZj@6Q(8Vs4.eYP*G&h>@5-nbunAqL;d$eVE1#O# + _gCI4r\Amdg6nJFmd\p@#l/O2guL$LJ@i\aQ!gE"i=KTXmqt!\\HfbF\SB/H?=b\aP.P%p& + bsQN8b:ordHMmhl6=W<-k1!jG;c&2:YV2$NFV"07gln2CS)p@#1_n1[iD0H.K`*sYTV"cK& + Xd!l6/aL]`2#r$,d0F%EYM$G_&\I_=6!J1d=hYtm4$a@;PnA,Me`=-_-%'[tbn'_4F$IH\F + s/jB2%TqVkB"@=$kE,&^:3*n*G2s50fe,\'mR[m@;$h,>iNVb.:0dWJ-P5]a%VqIBYko#lr + 7T?qg/0-R;#\"f!tt#t"tQ#$EB)lr'*=:4&i!)mbEihR"P`G:\T%9XD>OtsQP4@4i))VI&O + @28D\R.p'X;'!;,Fe8<>7/j&ro$2/l!+R=p;)!$S]%!&YU*tV&F?Q)R6C_nZa#f[2Wn6%8b + XA932E2,k=gC*3ma.n^/@-QldL2*\j,l;:Q^BjW8F+*jP)RnaR\UocJ!@ctbW\n+dqWhX(l + 6+-I'Une!#tN?+/:n?JN-;B[5>,pI@Y,-idEnhD@?QQ+1D+=gG3;@=^I73lnF,cm%MOl%&I + 9dOg_-*gf&nmNk#AL;B2,E"W.b>TYuaX30r-aJ.Jl]3>)*?GiE.'eg\nrY@VPppaA.BF%,d + +CXgg^6g.,Vko?o!']#%NhDN)hD0-ZFqe%^)]M2)=k0do$K$EeLbgp/[F1R66+L\DU@`\[1 + [TPEo/N*oe1@]0=(O0o)UO$"Yb!(0WTaW1&iK(kg^;1+E#XXdg\&g,r0Nj1:&Pfo.`$W2)B + ;5dSg_W1''+MV^eur1UBe4o2.A$8:o-,51fGT7e)1a7Ti@54dBFB>?&qDJoTIW)h\N8\"3e<\S + JGD>aL`J;(\F\>n1Pn7;ppM>'5-p?\!MM_6H5e[8\+B//%c.e]PQ1]Q5dUS.<"RSgiAqYj6 + *0rAOhicYEA@',]egHi!FuWR2*c6o5qQ-FPQs/]Pe&[45]bsK1]eNd'+'(;QjUNuL + ^,WCh`U(85LeN1TJI5=S?b5P,=Wi0ut$bS@t$("9uno=[m4^J6WM:34<7@Ak2TWA'Q9)"WS + O$]dXgM,10^8!A9o979!t2+WsN[kp`GeKHl8j[nd6&YU*^odh'?"or(O;ft0#Ps&)(5uX%( + (1Ceq6,FTbm^DdW;rM^oMk`t(CJ<7*9f)@f/B&C+5u-PGf$cG_OHZWB"/5]h9>'Lr%$A + @V;j=gNDgoq9V'QF1k4^6P_,26P5IM-8;[=Rid^oJ'RnJQjZU>BRJ8[D]J<_+/T(__p%;!7 + =g[,6j1W9;-+BPf2&$aNq6>30_`.!S/=.f0!$o@'o6-eEo@3aYGaP5c]rQZ\:j>K2G9k30X + KQocIH1Pu&4V\WpB/og`$56"Ete;X8%-Fum1!p9f&e2q@oT2Hr,K?WWBg1_UT5ZYq[`n@Wi + "@oN\:!Dci3O$m$'\e]]s[3j1BA>8]C2?UZ[]ML> + YdN&h^37\21!a0def/$s'hjfu/N[e8lXhquAoXYT2?uS"XJ)f + &qp(J;3h.^TuU5aED5;u^P^JTeKgc4t[ab>]H)F;I6C';7L4TfO,Y;AC_*EH?b+pDUCQ'gM + @+EqY2HQAKr(NEIc-H?8[C1^@g?heQ;*](a@p=.NpP$[NurHblD%Zhk\CcH#\.AlmSblUQB + Ti#=PYH]08"G@MQ"i3b3L*`ZJ + p6W$%'auVKo"8rM%&Qkp2ImU#BFsTLlS<`25uJV=_JLF5&B2*R'aT;Yg:t"`0`nPY]hL$N;9=#.4O><)@$[^?Q)=AH + 96qi2&(Lb!9Z!K\>p=q*aH)Rt?@2*$heLM43>NNGBhd+:1cUOW)5\("i,FVSJpcV[fC[b!r + 2<0]uG4[F6;P`%muq&_QK)RYp25.>;kQ)d]Hi;#mZ)+YH+ + Cm_>l'U+nd7^[NHRp!:gMe.hbI()+n'3UAZ3KoET]q'Ep=fYIeH,3"WK + 0ECKkbbm=Y)nO`_O2FDEis2RV5-7*B:\(W/eT.AcmF]GW;a\Ns6]=0;> + RQaaAe\ocFX5F"&L_HL`R=^>NZ&Sg$%Zk^hq==K*[l]dhM3;X%)qTEX,L:,bTVj1bllVUoV + %p\uFHMV!SZ\*[q2d;b5Xa0r;4#"'H,A?s$[/&6M.nr2$CJm%=ZT?&k)aQmH'=N$,Chp5Xq + 7=.A=(g8k[+,,b)Eh6XGGu>'\(QU&4*ar?9pt>B<\(VRTi]SJ + l^KgR]<&UV']iZe!"%RtkKXMls0HWN0UEb^7)6/"s$j6Q7*m[.5-"j:6`k%ZBLY$Vc][#S* + *['LA`595-FQiYMX0(DnfX2@hmuafC>N_H\P,fJ.;cZ,;K6:0[k-4?^Qo09@NiN-pr`NScZrAE3EF!V\Y+#mMR6)T>]-oM3B0)#+8=5L4EYsE=3c#+$ + ,#T#\k0PM6&'/T@l2MQgOjOqq6@S\d(>L_Y2@PKs)S"3ZMO."=fZsP1pq`"dPp0m<#*`Dcd + ')/cp@]YMbVZo):DeXX?AGelTqrTfX?2;5eRcBb<^1I)%%rjY)BU\riW*GPnoDRA5BdJT?_SW?1pPL?"sF$6)HSY-:u)1nnfeQl> + (I9hZohFVPJQTY?,Q@JmBl1A>Y_`ag$KjF:>Xr*94L_%05hc:mFDq4hVuc6)saP'Ed5 + 4=D-(d:Y?F":lWp90X&\,)1<"RQB`1Z61YJY;PsE#/^!lG_1O6';e3/F\EfW=;uER;`QNPm,P&CeQ]C<;-o$be*lJq[J9`\Y5ac_T:,<" + Qg33(aDTo2H2EE(o9MP_`d`n1^SAEQ\%A2X]?>9;5HglRPGJ/RK"eST*T`_.-GS,Hs$@$qX + t"Qt.s$(P>3<&B@J)4XG\),n + Rq0Y"%Z>7?:u.^*N3.d9lF/m"V,JTuQ3%#`M + Ll>,bLPZ>.'fa&&!F,uVi26=P>1^nMTJe:*0m]#geNS(.k$1mb^k'mnDA?H9rSD"g%k(7Qg + $aDo`]>^F_1-J!$t.0]PY=3aBV%NH5O9nm0;,o"M_r>qS4YM&O0W!U(b_^eD!P,$#jZqh[=0"Ns<[7>hOa%,b@JttoAZP&2+XF3AO7ZO3u + 9#^5H4[dfIm5[qmFeVJ/J7Z]<>h9;i7XUXOM<%-gVYtXC$0$6!T\.f6FN)pufl5p((36'NQ + =j3sB%qKgTk#%L!TdM?Cf4sgDLI6f\q2*!C:Y].]eoq&GC?qt;QlM!>:pk`Uq+5-p#X^V@$TkFP-qWkGhRA:,C2Za\uON8 + 7Yu,&*khVj/]2h3E`upFaC^sJ/]49P:0<*dPh,hhDKr>)+EC_`fsg/r%a`2dl6M%3T4cis? + PhPMH/5%Y-Um!=IOC'6GlC$&%5DIG,"TMRJUjjAAPlG:HLS:!#!pB:WU"mq":t"tISYZOa1 + %B%cLiU?LW-lt5@5OAguFI0iI+5>rB)l#LHUDYJ/njPmi-pFAe'BZ9?%P'(eL8VV6mg"e+i + H.M;^TFfHs+]>RaK54Y@Qn[@-)jm![*%]$ra.cVG"&b+hflSUj/c!V7'f[ + :6nsBP@EZ$dq31Y,j+Hh,3]%>b!Rrn"fEtpu7e424U.6*oR/p,@KW9me7niP;IJkHEr4Qj! + ,C(n0m2.r+:&JY)5ZW///Z2[9!KbC)Co_,3aieE0nD[l::P>Z^(8nh0gI"[`2%\_DG`X$Gk + a<:^%VkSp;oe.=R6BF@;0SZP-*^8cKnC')Hp;ln^VNeNSTu9-N*%@SU6nup.RQX)Q'`OKiR + "iV8''RFXEKD@04P-V]Y(mRt$PCJ5_D+nid((B=7BH7aNFP58em_ + N\5rNL]ba65=sG#$U<-,e9YMMZRKMF$UNdWOWuSm/["ZPofT9:*Z%seKBHl$s=\/1%ISLp0Z]0t>&Bg3!O&W6gL/ + 0%)L&6YhZ/EdqO`Y.cLOt>j9Zah_NFf-!=GKVg`.I]cA5%WAo*02&B7B^#.*a9`IUp[$hG% + T5l(>9l#frmH/4uqkTem7#`&SJXAJ^K"b.^-g3=+U*da5Vr?>1gunnY&t5tIt%44K^c;egO + Mp)b'NeQ!Z46 + &CjQgc%L\"er6O^,;-XmqK.#CLr](NF-EmV:d;g>5sZ!.1*;e/F(Acs$)9@Vd<^a@_/\CFo + 3Pn+'fGW.)j^)_?ni.mZQ]234uU@[Y-=C=^Wlp

\k?tLrI\D3(i5^CZeH2-5j^'D[ + p424br"0Rc<>H*Ch/^Z7H27L9ZaXsB2rd;X`_3KZ7E0rbdJ_.30I6V"1X"aJtcDD'aW_<5!nD'I + j,P%4ZP"^NiM4H^"52Ah[Pf:h*iR)H1N<61a;h&rIVl*hcqQMFJ1SO!S>g8LMRt^6hVk]+8 + ZtdkhI4J2K$X^A2e2=!^i(:VUpFsB2\/pFdDJc7,GM->B!mX_>$M,iERpjlQsB:?B5LS)L@ + :nk4O\tE(tb@nALF%4JN[,SUOet:)90a3b0Z'R@.4]&@t_V6tTLCl02&M/XN@0%CFo%SmoR + GG(H2RU,76pPAt%H,r_/0kRb-*EV/).:^g:V=m^X0^4!T;cR\-G-^V9Kh:BY#1eo%FGLsMQ + cG0ZJFDeF]]A6#c\-H!]4a(+P*a?k9h_e4m9>5W,rSRMXJY,%cc/(YfBks]pK>f7'E[9R'LWHL'Whj0g7pWGp[O'tOk,O1TDOH<9+1iL/AO89:rY4E+\/8V= + d.+nF<7f[+>r+/@N!n@//lMVpRu#8;#2kc#;C9*E-V\`o'hRUc-Ui`%c[h(>mRZo#r%VNE1%$:SI+DM#RtJT#@RoMW + $G3A$LkG2E4H@\]aO>F1bb`b$qh!Z&FJu2Bo[0B0\Ho>h$rl4%PZriXO>@4V[d:A$S_(ZYk + J[4r=AE!&2==t0ZK@&,7nD)%oEoN;%XDF*>.fb&htZ;OUCps-;"jf&5b4rnMq8f4VR?O'IS + MGY721C9bd+p'er]'EEO$];#-mGq=.)md:jB$D&2Y](GU%KDAa3"*tZfB(QjCgEJYO;N>V2 + J)(@9SOG+Q?1kC7D)@]S*Y(Dt#em?\V0Ti0'&ZRHp?rSE1)^9a2X9TWjboH9$*ANTmOUiI" + cK4&H*Xp'VL%P6Dh]>AYZ%)i>@Y5>'/i\]FkgA3/EXFoEg\A^S;'no(c%[=V"F?.DC)Th!s9,(&sOY^ZD\ + u^T10`VDdY[?]..jK/Mbj.A]ZDW)(gIp09U-!Eo^QTcFWT7^7sdCC%>]7oZm\8.nKsF`L.r + eo"VCY:k`fb72l7;Ea[>S1,C43F!tWtI.4D118?><^sH5io!Cg:1XOLmBsAdIO#)tg%;9e> + &-DNZ/f%*;Zu/??k!\9o*agc]2`#S8F*L:*/fq9/1Ga>3dX=%?+=@h[mS\YeNhnYNOZ>3]K + Su]fi_B1,JFFniY-PV_l9j6=t!]A0i + Y-[bl06+RJ,S$imtMeC[\14O?YHJdd`?0f`,\68W7CFD44>$J%\#+`qQboAh3>1oY2n/JIJ + *e:)"M5jk?db-ZmHafprX;Z*7AaAdLVFK%m>X\.SM-.HuQ'&Q=`\Oa*!i"3/f1jaF9@W&uFQlQ$\hupfZVZ8p[-]^BVCkjI]4n,q0uP\$^h,"ETT8=):i=]ZY + 4m#A7PnOB;e&E6qbm)A;`-BT'HpCaM,`faqCKW^+,>sSD;H740F`CQlSQYP72tMYtQ(TJSK2n2$bRM + u#'E0bPY$3Uq8Q-'iKn.\gO&F:g=V#"Jj6X]T9>nuO2Fr=_nf"9"K(\'(ce)OMb&hbW["Di'^/3O!-;^,6u;5/&;No=?^ + &man[KHlB7/ONE7=].adlkV$^G%kQn5@.B,,n!stb`PVc9X49"Akh\HFC$9e86W8Von?f>E + ]V>W6VK3/m*::9`F+9cojCgACGrS9E8=/RV'Ztfdo>=Xnr7I.m)7@XZ%=CHZ^)n67Cp$tOf2Yh:"r<[XeDtZ+qJh3q1;OZ0cWCH\*68*<&SgO0f>&s'c1;Pc-]$A + ME0biKTWJais"&1]XF>lX1DAR7N8KXlpi/p4YQVVb5?$5mL]2q^M,&WGUQP+LZ>^'n+GBnD + AI%F?65*9K%iadk2YnP`J@i'uIGF<`cS;%],C_r^RilH+\SJ!\(7$jfuGI`(0]NUY7Hf@.J + ((CrOaS_CDI5f])GM+q++M8I9G^%nkGNjRcm=+g!+]c8#Pdu9&rI=SCJ2d^UQhPf.#CuR]J + N+BqF`Ddg)1hQ+JiG'.F,,>!.>%=LK/b`@ERf@lF`oM??Ijuh\3^s57`].,]6J7,@TK170Y3pi[qXMN\m4K:Ge#+WEGP>6BnGc(rip"b?G/B+un$ + Q+W69*>=DZQ0LfIEfXm6U%?U,kJ@NKt;9;(EdM"s^^;W:Ij*.;`nTH)g_GX"TC/eE!Z/ + "Q!%=TA!HlZ@OqQWH1+dP8_,TXu!.:Qm0,bO#kUd>-4i/mB6I%P)XSH[KXRk`q^[udT";O"41 + bJ:4%HQEDe7FrMRtgUHYKpi6[e(/PaDngCu^`&m%Thb[<_/>].U'EH\K&MRplo<(Nm5lP:p + ,*[bIXiH`3p4pK&:CV\Bf@R;Z_a30X!g\[GkW]48JMX1\>W]dRs5oVgT0]l;sCAhNKpl7!] + RjgH#4^0.,-]A0Lbi#u=s,!5+r@MccUaf0Xi]j);gHl/M;7>A3*l+n5%!T?&LQ]:glRY:iY + `-7pp>3b.)N^ac!S$jPh56Q/5T;auj>UdPE=i3.u`>gsb>Yem&jrHQP!#l;WR+6+[Q6?%#49PQUiNS+2lffbVRI@8d%S_&IL4rH%H.3tiBA"8IMq+Y*T?u@i]\[JIOX9j/`Qaaj$#?Q_Q[\3nfT%~>Q +Q +showpage +%%Trailer +count op_count sub {pop} repeat +countdictstack dict_count sub {end} repeat +cairo_eps_state restore +%%EOF diff -r 9b9a2497757d -r eb146c5c05a8 0__Papers/VMS/VMS__Foundation_Paper/VMS__Full_conference_version/figures/Time_in_VMS_1.svg --- /dev/null Thu Jan 01 00:00:00 1970 +0000 +++ b/0__Papers/VMS/VMS__Foundation_Paper/VMS__Full_conference_version/figures/Time_in_VMS_1.svg Sat Aug 03 19:24:22 2013 -0700 @@ -0,0 +1,407 @@ + + + + + + + + + + + + + + + + image/svg+xml + + + + + + + + + + + Suspend Point 1 + + + + Suspend Point 2 + + Program Time 1 + TraceSegment + + + + Suspend Point 1 + + + + Suspend Point 2 + + Program Time 2 + TraceSegment + + + + Tie Point + + VirtualTime + + + + + + + Suspend 1,1start + + + + Suspend2, 1 start + + + + + + + diff -r 9b9a2497757d -r eb146c5c05a8 0__Papers/VMS/VMS__Foundation_Paper/VMS__Full_conference_version/figures/Time_layers.eps --- /dev/null Thu Jan 01 00:00:00 1970 +0000 +++ b/0__Papers/VMS/VMS__Foundation_Paper/VMS__Full_conference_version/figures/Time_layers.eps Sat Aug 03 19:24:22 2013 -0700 @@ -0,0 +1,869 @@ +%!PS-Adobe-3.0 EPSF-3.0 +%%Creator: cairo 1.8.6 (http://cairographics.org) +%%CreationDate: Sat Nov 20 00:16:39 2010 +%%Pages: 1 +%%BoundingBox: 0 0 206 75 +%%DocumentData: Clean7Bit +%%LanguageLevel: 2 +%%EndComments +%%BeginProlog +/cairo_eps_state save def +/dict_count countdictstack def +/op_count count 1 sub def +userdict begin +/q { gsave } bind def +/Q { grestore } bind def +/cm { 6 array astore concat } bind def +/w { setlinewidth } bind def +/J { setlinecap } bind def +/j { setlinejoin } bind def +/M { setmiterlimit } bind def +/d { setdash } bind def +/m { moveto } bind def +/l { lineto } bind def +/c { curveto } bind def +/h { closepath } bind def +/re { exch dup neg 3 1 roll 5 3 roll moveto 0 rlineto + 0 exch rlineto 0 rlineto closepath } bind def +/S { stroke } bind def +/f { fill } bind def +/f* { eofill } bind def +/B { fill stroke } bind def +/B* { eofill stroke } bind def +/n { newpath } bind def +/W { clip } bind def +/W* { eoclip } bind def +/BT { } bind def +/ET { } bind def +/pdfmark where { pop globaldict /?pdfmark /exec load put } + { globaldict begin /?pdfmark /pop load def /pdfmark + /cleartomark load def end } ifelse +/BDC { mark 3 1 roll /BDC pdfmark } bind def +/EMC { mark /EMC pdfmark } bind def +/cairo_store_point { /cairo_point_y exch def /cairo_point_x exch def } def +/Tj { show currentpoint cairo_store_point } bind def +/TJ { + { + dup + type /stringtype eq + { show } { -0.001 mul 0 cairo_font_matrix dtransform rmoveto } ifelse + } forall + currentpoint cairo_store_point +} bind def +/cairo_selectfont { cairo_font_matrix aload pop pop pop 0 0 6 array astore + cairo_font exch selectfont cairo_point_x cairo_point_y moveto } bind def +/Tf { pop /cairo_font exch def /cairo_font_matrix where + { pop cairo_selectfont } if } bind def +/Td { matrix translate cairo_font_matrix matrix concatmatrix dup + /cairo_font_matrix exch def dup 4 get exch 5 get cairo_store_point + /cairo_font where { pop cairo_selectfont } if } bind def +/Tm { 2 copy 8 2 roll 6 array astore /cairo_font_matrix exch def + cairo_store_point /cairo_font where { pop cairo_selectfont } if } bind def +/g { setgray } bind def +/rg { setrgbcolor } bind def +/d1 { setcachedevice } bind def +%%EndProlog +11 dict begin +/FontType 42 def +/FontName /f-0-0 def +/PaintType 0 def +/FontMatrix [ 1 0 0 1 0 0 ] def +/FontBBox [ 0 0 0 0 ] def +/Encoding 256 array def +0 1 255 { Encoding exch /.notdef put } for +Encoding 1 /uni0050 put +Encoding 2 /uni0072 put +Encoding 3 /uni006F put +Encoding 4 /uni0067 put +Encoding 5 /uni0061 put +Encoding 6 /uni006D put +Encoding 7 /uni0020 put +Encoding 8 /uni0054 put +Encoding 9 /uni0069 put +Encoding 10 /uni0065 put +Encoding 11 /uni0068 put +Encoding 12 /uni0079 put +Encoding 13 /uni0073 put +Encoding 14 /uni0063 put +Encoding 15 /uni006C put +Encoding 16 /uni0053 put +Encoding 17 /uni0064 put +Encoding 18 /uni0075 put +/CharStrings 19 dict dup begin +/.notdef 0 def +/uni0050 1 def +/uni0072 2 def +/uni006F 3 def +/uni0067 4 def +/uni0061 5 def +/uni006D 6 def +/uni0020 7 def +/uni0054 8 def +/uni0069 9 def +/uni0065 10 def +/uni0068 11 def +/uni0079 12 def +/uni0073 13 def +/uni0063 14 def +/uni006C 15 def +/uni0053 16 def +/uni0064 17 def +/uni0075 18 def +end readonly def +/sfnts [ +<00010000000a008000030020636d61700076f10b00001a9000000064637674207d0742a80000 +1af4000002706670676d49d7df9200001d640000060a676c7966e942e463000000ac000019e4 +68656164d5ceeae00000237000000036686865610f7e06ae000023a800000024686d74784af9 +067a000023cc0000004c6c6f63613a8c41da00002418000000286d617870037802c900002440 +0000002070726570292ded1600002460000004ad00020080015e0380045e0003000700264016 +059c039d049c070017003700030000079c019d049c00002ffdfded012f5f5dfdfded31301311 +211125211121800300fd800200fe00015e0300fd00800200000200960000042605c3000a0013 +0108b9000cffea40170c0c024b0b180c0c024b670701021045070b4401440207b8ffd8b41010 +024b07b8ffdab40b0b024b07b8ffdab40d0d024b07b8fff0b40d0d064b07b8fff4400e0e0e06 +4b07471507022702020002b8ffeab41313024b02b8fff4b41010024b02b8fffa400b0f0f024b +02040b0b024b02b8fffeb40d0d024b02b8fff0b40e0e064b02b8fffeb40c0c064b02b8ffe840 +2d1010064b0247143a124a125a1203350e450e550e0303050b120c000e180c0c024b0e160d0d +024b0e4909090212b8ffe8400b0c0c024b12490502080502003f3f10ed2b11392fed2b2b3332 +113311335d5d0110e62b2b2b2b2b2b2b2b5f5d10e62b2b2b2b2b10eded10ed5f5d3130002b2b +0111231136332011102122031116332011102122015ec8e32f027efdcc22727f070174fe7328 +0234fdcc05b90afe55fe1202dbfde30a0125010c0000000100960000031c0443000e00af401e +0a400b0d024b081018102810c81004c70ed70e020e06094d064d68070107b8ffecb41313024b +07b8ffeeb41010024b07b8fff240110f0f024b07040b0b024b07040c0c024b07b8ffeeb40f0f +064b07b8fffcb40c0c064b07b8fff2b41010064b07b8fffc40250e0e064b070f170a270a370a +470a570a670a0600050a400e0e064b0a02520c0806070a0c07003f3f3f10edcd2b325f5d0110 +d62b2b2b2b2b2b2b2b2b5deded10c65d5d3130002b01262322061511231133153633321702cd +3e3f6597bebe68cd336003782bba83fd9a042fabbf1200020041ffec040a0443000b0015013c +402517401010024b17400b0c024bb7050101381701114e17063706470667060406041010024b +06b8ffdeb40f0f024b06b8fffcb40b0b024b06b8ffe4b40c0c024b06b8ffd4b40d0d024b06b8 +ffeab40e0e064b06b8ffe0b40c0c064b06b8ffe440760d0d064b060c4e87009700a700b700c7 +00e700063800480058006800040000101010024b000e0f0f024b00200b0b024b00200c0c024b +00160d0d024b000c0e0e064b00100c0c064b000c0d0d064b00166a030165090103670e016813 +0102450e550e650e034a135a136a13030e100f0f024b0e520913b8fff040160f0f024b135203 +09180f0f024b09180f0f064b090b03b8ffe8b40f0f024b03b8ffe8b50f0f064b0307003f2b2b +3f2b2b10ed2b10ed2b5d5d5f5d5d5f5d5d0110d62b2b2b2b2b2b2b2b5f5d5dfdd42b2b2b2b2b +2b2b2b5ded5d5f5d31302b2b1334003332121110002322001310213236351021220641010bda +e6fefefce0e5ff00c8011d8597fee4829b021af80131fedbfefcfefdfed5012e0100fe6dd8bb +018ed40000020050fe5c03c804740030003c0160402c48195819681978190400272b372b0202 +65017501020320101c12064e282b382b482b582b682b782b882b072bb8ffeab40e0e064b2bb8 +fff0400f0d0d064b2b193a4e1c0e1010024b1cb8fff440860c0c024b1c120d0d024b1c3e0023 +4e0d344e12060e0e064b120c0f0f024b12120b0c024b12120d0d024b123d17010188199819a8 +19b8190488189818a818b81804280c380c02006701770102026a317a31026537753702031020 +37281a171f181537180f0f024b37521f40090a064b1f9708a708b70803970ba70bb70b030028 +530825530b01b8ffc0b41114024b01b8ffc0b40b0c024b01b8ffc0b41114064b01b8ffc04009 +0c0c064b0103522e31b8ffe8400d0f0f024b3152152e0e0b061507003f3f3f10ed2b10fdc62b +2b2b2b10edd4fd5f5d5dd42bed2b10c6123939111239395f5d5d5f5d5f5d5d5d5d0110d62b2b +2b2bedd4edc610d62b2b2bedc6d42b2b5ded111239395f5d5f5d5f5d31301337163332363534 +2322062322353436372611343633321737170716151406070706061514333236333216151404 +2322260122061514163332363534266067a68c8195bc20a82fe46b4fe2eaac9e595f7c7249ca +a49d1c5e622bb62c9eb1fef7cb68e6014d637d796765727bfedb986f59428220ac3556136a01 +06a8e0417275565f99a2dc101003251e291f978694b64a05048c6470938f74648c0000020050 +ffec03e40443001b002501d3b627401010024b25b8ffecb40b0c024b25b8ffee40490d0d064b +071317130201672077200202280f480f0200b70fc70fd70fe70f04010025150f053718471857 +1867187718871897180718254d0a4d881501150c1313024b150c1010024b15b8fff8b40f0f02 +4b15b8fff040110c0c024b151e0d0d024b150c0e0e064b15b8fff040440f0f064b150c0d0d06 +4b1527214e38050100050c0f0f024b05160b0b024b05100c0c024b05120d0d024b050c0e0e06 +4b050c0c0c064b050c0d0d064b05263a0301032500b8ffc0b40d10024b00b8ffc040320d0f06 +4b480058006800780004000218191c520a080e52080f180f280f380f480f580f980fa80fb80f +c80fd80fe80f0c000fb8ffc0b41317024b0fb8ffc040240d0d024b0f124a1e5a1e02031e52a8 +08b80802580801006a087a08020347085708020008b8ffc0b41414024b08b8ffc0b41313024b +08b8ffe8b41010024b08b8ffe8b40f0f024b08b8ffc040131313064b08080c2352020c521219 +0b020b1207003f3f3f10ed10ed11392f2b2b2b2b2b5f5d5f5d5f5d5ded5f5d10dd2b2b5f5ded +10d5ed10cd10dd5d2b2bcd5f5d0110d62b2b2b2b2b2b2b5f5ded10d62b2b2b2b2b2b2b2b71ed +edc65d10c41112395f5d5f5d5f5d3130005f5d2b2b012b250623222635342433321710232207 +273636333216151114171522260326232206151433323702e472eb7eb9011ddd3c4ce8b26050 +36bf57e9d35474732b5a2490b6c5906f7b8fb788a3e11a0104609f2c3fd4e7fe808d2f5f4201 +df149465a789000100870000061d0443001f01b8403821400f10024b21400c0c024b071c0101 +08216821022721372157219721c72105004d371f011f101313024b1f081010024b1f1c0f0f02 +4b1fb8ffec40170b0b024b1f180c0c024b1f040d0d024b1f0e0f0f064b1fb8ffed400b0c0c06 +4b1f101010064b1fb8fffe401d0e0e064b1f084d37070107101313024b07021010024b071a0f +0f024b07b8ffec40170b0b024b07180c0c024b07040d0d024b07080f0f064b07b8ffedb40c0c +064b07b8fffe40180d0d064b07061010064b07104d071117112711e711040011b8fff8b41010 +064b11b8fffa400b0e0e064b11100909024b11b8fff4400b1313024b11040d0d024b11b8fff4 +b41010024b11b8fff440110f0f024b110a0b0b024b11080c0c024b11b8fff440530f0f064b11 +100c0c064b1120171c271c371c030118400d0d024b18401010064b182c0d0d064b4718571867 +187718040018400e0e064b18400e10024b18160f141603521b0c52161f0a080a110a1b071607 +1206003f3f3f3f3f3f10ed10ed10ddcd10cd2b2b5f5d2b2b2b5f5d0110d62b2b2b2b2b2b2b2b +2b2b2b5f5dfdd42b2b2b2b2b2b2b2b2b2b5dedd42b2b2b2b2b2b2b2b2b2b5ded5d5d3130005f +5d012b2b2111342322060711231134262322060711231133173633321736363332161511055f +db457816be776239811bbe7c3f6ea5e65c20ae5ca6b602a6fd5536fce802f94f5b5835fcea04 +2f7c908f3d52c5b2fd34000100120000049305b900070080401e270701280401079301042c13 +13024b049301442702010002081010064b02b8ffe440111313024b02180f0f024b02100b0b02 +4b02b8fff6b40d0d024b02b8ffe640200e0e064b02120f0f064b02010c0c064b02220d0d064b +02074804480502080502003f3f10eded012f2b2b2b2b2b2b2b2b2b5f5dede62b10e65d5d3130 +011123112135211502acc8fe2e04810505fafb0505b4b400000000020050000001c105c4000b +001100d9b613400f0f024b13b8ffc0b60d0d024b097b03b8fff4b40e0e064b03b8fff8b40f0f +024b03b8fffab40c0c024b03b8fff940200c0c064b03110e0c4d7711010011041313024b1102 +1010024b110e0f0f024b11b8ffeeb40b0b024b11b8ffecb40c0c024b11b8ffe6400b0d0d024b +110e0f0f064b11b8fff8400b0c0c064b11120d0d064b11b8ffd640100e0e064b11081111064b +11130d511000b8ffc040120f0f024b007c06400f0f024b06100c0a1006003f3f10d62bed2b10 +ed0110d62b2b2b2b2b2b2b2b2b2b2b5f5dfdc610d42b2b2b2bed3130012b2b01321615140623 +2226353436031123352111014b314545313045443793015105c44530314545313144fa3c038f +a0fbd100000000020041ffec041c04430019002201ff408724400b0b024b58170103b807018a +079a07aa07ba07ca07da0706025705016808780888089808a808052808380848085808680878 +0888089808a808b808c808d8080c00571877180208221010024b08180f0f024b08180c0c024b +082c0d0d024b08100c0c064b08100d0d064b081f4e471e0102171837184718671887189718a7 +18b718c7180918b8ffe0b40e0e064b18b8ffdeb41010024b18b8ffdcb40f0f024b18b8ffe2b4 +0c0c024b18b8ffd4b40d0d024b18b8ffe4b40c0c064b18b8ffe4406b0d0d064b18011e4e014e +87100138104810581068100410100e0e064b10101010024b10100f0f024b101c0b0c024b1016 +0d0d024b100c0c0c064b100c0d0d064b102387079707a7070300270537054705570504020752 +2a083a084a08030357086708770803070817080208b8ffc0b40b0c024b08b8ffd4b40d0d064b +08b8ffc040350d0d024b080c1e50470157016701a701b701050001400f0f024b01400d0d024b +01400f0f064b010105581a011a5214100f0f024b14b8ffe8b40d0d024b14b8ffe840200e0e06 +4b140c0f0f064b14671401024a145a140205100c0c024b05520c0b1407003f3fed2b5d5f5d10 +2b2b2b2bed5d11392f2b2b2b5f5ded10d52b2b2b5d715f5ded5f5d5f710110d62b2b2b2b2b2b +2b5d5deded10dd2b2b2b2b2b2b2b5d5f5dedc42b2b2b2b2b2b5d5f5d715d5f5d5d5f5d313001 +2b0121141716333237170607062322272635103736333217161514012207060721342726040d +fcfc675b8fa36d502c5b728cca8d9da190c5e5827efe247f56520b0251484f0205bc65585f89 +2c202a8997ff0109a08f817ccd3f0169524e74734d5400010087000003d905e60013010d400d +15400b0b024b07101710020100b8fff8b60c0c064b004d13b8ffecb41010064b13b8fff8b413 +13024b13b8fff640171010024b130a0f0f024b131a0b0b024b13080c0c024b13b8ffd6b40e0e +064b13b8fff6400b0d0d024b130e0f0f064b13b8fff840130d0d064b13080b4d084d07091709 +2709030009b8fff2b41010064b09b8fff4b41313024b09b8fff4400b1010024b09040d0d024b +09b8fff440110f0f024b090a0b0b024b09080c0c024b09b8fff4b40e0e064b09b8fffa400c0f +0f064b09146a047a040204b8ffe8400f0f0f024b04520f130a090a0f070a00003f3f3f3f10ed +2b5d0110d62b2b2b2b2b2b2b2b2b5f5deded10d42b2b2b2b2b2b2b2b2b2bed2b3130005f5d01 +2b2111342623220607112311331136363332161511031b766b458b25bebe26a95aaac102a178 +8a5136fce405e6fdd33b4fe0c2fd5f000001000cfe5c03e6042f000f0105b9000dffe0b31010 +024bb1020243545840120d0b0452030e0e060b06030d0f0e0d0b0c0db8fff4b70b0b024b0d0d +11101112392f2bddcd10ddcd10c4003f3f3fed123931301bb1060243545840150d0b0452030e +0e060b06030d0f0e0d0b0c0d0d11101112392fddcd10ddcd10c4003f3f3fed123931301b4058 +4c0801380f0127000103270401004701010237010103081128110200380d480d02020d0d0c45 +07010707040e4f0f110c4f450b0103040b10980da80d020167060102270d470d570d670d770d +05000d0f0452030e0f060b06003f3f3fed11395f5d5f5d5f5d0110d6c65f5ded10d6ed11392f +5d11393d2f5f5d5f5d5f5d5f5d5f5d5f5d5d5d31305959002b05060623353236353426270133 +010133022025ed9277aa3e31fedec2013b011bc2b66688aa6f5058ab7e02e9fcc4033c000001 +0041ffec02fc0443002100e7402b23400b0b024b081f181f02070e170e022823482388230300 +3a0c01351d0103c8110111054e671d771d021db8ffeeb40e0e064b1db8ffe0405a0d0d024b1d +1700174e480c01970ca70cb70ce70c04000c040e0e064b0c22e81901271b0101280701270f01 +28200102651a751a020307191a0314034812581268127812c81205120f370147015701670177 +01b701c70107000103b8ffe040141113064b03522014181113064b14520f200b0f07003f3f10 +ed2b10ed2bc55f5d10c55d111217395f5d5f5d5d5d5f5d5d0110d62b5f5d5dedc610d42b2b5d +edc45d5f5d5d5f5d3130005d5d012b37371633323534272e0335343633321707262322061514 +17171616151406232241439f61b0aa835b4321c09b75b2367172445d75887d72cab3a940b468 +946a4c3c3e4f593384944ab05a403167353e39926e90a300000000010041ffec03b504430017 +0119401e450501a1010103281938190200870d970da70d030200070d870d970d030db8fff4b4 +1010024b0db8ffeab40f0f024b0db8ffeab40b0c024b0db8ffe840610d0d024b0d074e381248 +12028712a712b712c712e712050012101010024b12180f0f024b12200b0c024b12180d0d024b +12060e0e064b120c0e0e064b12120c0c064b12100d0d064b1218250a350a450a032a043a044a +0403030c52070d170d020db8ffc040160b0b024b0d0f015208001800020000400b0b024b0004 +b8ffe8b40c0c024b04b8ffe840190d0d024b0452150a180c0c024b0a180d0d024b0a520f0b15 +07003f3fed2b2b10ed2b2bdd2b5f5ded10dd2b5ded5f5d5d0110d62b2b2b2b2b2b2b2b5f5d5d +fdd42b2b2b2b5d3c5f5d5f5d5f5d5d3130010726262322061514163332371706232200351000 +21321603af5e1d93479bb6baa580824b99e2dbfee20129010253c203d8861d34d9bdbcc563a0 +630126fb01000136460000010096ffec020705e6000800c7b9000affc0b41313024b0ab8ffc0 +b41010024b0ab8ffc0402a0c0c024b070a170a270a370a470a570a670a770a08070617062706 +0306024d070117012701d701040001b8ffecb41313024b01b8ffeeb41010024b01b8fff24011 +0f0f024b01040b0b024b01040c0c024b01b8ffcc40170e0e064b01180f0f064b01130c0c064b +01160d0d064b01b8ffec401b0b0b064b0109b705c70502010a081a082a083a08040652070b01 +00003f3fed5d5f5d0110d62b2b2b2b2b2b2b2b2b2b5f5dfdc65d5d3130012b2b2b1311331114 +1633152096be6350fe8f012f04b7fb695663aa00000000010050ffe7038805d2002601ccb102 +02435458401907221a0e180b0b024b0e120c0c024b0e22070e1a0425131714b8ffc040120c0c +024b1411000401251749110304492509003fed3fed10cd123910cd2b1239121739012f2b2bcd +2fcd31301bb106024354584086082401071001002520452065207520042a0b01034828a82802 +68130113074507223722672203221a001a45380e01870e01000e2777040102351e651e751e03 +351f451f651f751f040a0c3a0c4a0c6a0c7a0c0533220103380e010a0b1f1e04254814581468 +14781404141137014701570167017701a701b70107000125174911044925091103003f3fed10 +ed10cd5f5d10cd5d1217395d5f5d5d5d5d5f5d0110d65f5d5dedc410d45dedc45d5d3130005f +5d5d5f5d5d1b4086082401071001002520452065207520042a0b01034828a828026813011307 +4507223722672203221a001a45380e01870e01000e2777040102351e651e751e03351f451f65 +1f751f040a0c3a0c4a0c6a0c7a0c0533220103380e010a0b1f1e042548145814681478140414 +1137014701570167017701a701b70107000125174911044925091103003f3fed10ed10cd5f5d +10cd5d1217395d5f5d5d5d5d5f5d0110d65f5d5dedc410d45dedc45d5d3130005f5d5d5f5d5d +5959373716163332363534262727262635343633321707262623220615141616171716161514 +042322544938a742758e4f9f769677e8b6f35f3b28a44666752a4b74789679fef7dec343b829 +3780634a7f4b3746c087a4d84fae1d36745b385c3e383947c598a5e60002004bffed03ec05e6 +000e0019011e40161b400b0b024b004d0d190c4d470d010d201313024b0db8ffeab41010024b +0db8fff6400b0f0f024b0d080b0b024b0db8fff6b40c0c024b0db8ffe4400b0d0d024b0d0c0f +0f064b0db8ffe2b40c0c064b0db8fff240660d0d064b0d140c0c0c064b144e87060138064806 +020006080f0f024b061a0b0b024b061a0c0c024b06120d0d024b060c0e0e064b06100c0c064b +060c0d0d064b061a251635164516032a113a114a110303580368030216180b0c024b16100f0f +024b16520311b8ffe8400e0b0c024b115209480901020e0a03b8fff0b60f0f024b030b09b8ff +eeb70d0d024b09070d00003f3f2b3f2b3f5f5d10ed2b10ed2b2b5d5f5d5d0110d62b2b2b2b2b +2b2b5f5d5dfd2bd42b2b2b2b2b2b2b2b2b5dfd3c10ed3130012b253506232202353400333217 +1133110326232206151021323637032e63bdc9fa0120c7a656bebe487d99bd01602d7e10014f +630120f0f101554e01f1fa1b03366ce4b0fe7d39200000000001007dffec03e3042f001200fb +402714400b0b024b7714010a4d074d070801170847087708a708048708b708e70803080c1010 +064b08b8fffab40e0e064b08b8ffecb41313024b08b8ffec400b1010024b08160b0b024b08b8 +ffeeb40d0d024b08b8ffccb40e0e064b08b8fff0b40c0c064b08b8fff440150d0d064b08004d +e812f81202071217122712030012b8fff8b41313024b12b8fffab41010024b12b8fff640230f +0f024b120c0b0b024b120c0c0c024b12080d0d024b12040c0c064b12040d0d064b12b8fffa40 +110e0e064b121303520e090a0e0b08061206003f3f3f3f10ed0110d62b2b2b2b2b2b2b2b2b5f +5d5dfdd42b2b2b2b2b2b2b2b2b5d7172eded5d3130012b011114333236371133112335060623 +22263511013bd75e9c19bebe20c15cb0bb042ffd55f86c4702f0fbd1943f69caba02bf000000 +0002000300000000001400010000000000340004002000000004000400010000f012ffff0000 +f000ffff10000001000000000006003000000000001300000001000200030004000500060007 +00080009000a000b000c000d000e000f00100011001205e6000005b9001905b90014042f0014 +0000ffe70000ffec0000ffecfe5c000005c30000fe5400000338000005d300000253000005c8 +000a000000000000000000000000000000000000000000000000000000000000000000000000 +0000000000000000000000000000000000000000000000000000000000000000000000000000 +00000000000000c800cd00cd009600b400b400000000000000be00c800c8008c00a0009b0096 +0000000000be00c800c8000000aa00aa000000000064007d0082008c009600a00064007d0082 +008c009b00d20064007d0082008c009600a002300136011801a401d600460218012c01c20000 +01d600eb00eb01d1017f0154011301450168012c008d02350159033f0505012c00b4006e0136 +015e01cc01cc04d8006e006e01d600d2005f01f4012c007802d00190037f00800280006e00b4 +000000a5fea2003200b9008c0000000000000000000000000000000000000000000000000000 +0000000000000000000000000000000000000000000000000000000000000000000000000000 +0000080005e6000005b9001905b90014042f00140000ffe70000ffec0000ffecfe5c00000000 +0000000000000338000000000000025300000000000000000000000000000000000000000000 +0000000000000000000000000000000000000000000000000000000000000000000000000000 +000000000000000000000000000000000000000000000000000000c800cd00cd009600b400b4 +00000000000000be00c800c8008c00a0009b00960000000000be00c800c8000000aa00aa0000 +00000064007d0082008c009600a00064007d0082008c009b00d20064007d0082008c009600a0 +4036544b214a494847464544434241403f3e3d3c3b3a39383736352f2e2d2c2826252423221f +181411100f0d0b0a090807060504030201002c4523466020b02660b004262348482d2c452346 +236120b02661b004262348482d2c45234660b0206120b04660b004262348482d2c4523462361 +b0206020b02661b02061b004262348482d2c45234660b0406120b06660b004262348482d2c45 +23462361b0406020b02661b04061b004262348482d2c0110203c003c2d2c20452320b0cd4423 +20b8015a51582320b08d44235920b0ed51582320b04d44235920b0042651582320b00d442359 +21212d2c20204518684420b001602045b04676688a4560442d2c01b10b0a432343650a2d2c00 +b10a0b4323430b2d2c00b0282370b101283e01b0282370b10228453ab10200080d2d2c2045b0 +0325456164b050515845441b2121592d2c2045b0004360442d2c01b00643b00743650a2d2c20 +69b04061b0008b20b12cc08a8cb8100062602b0c642364615c58b00361592d2c8a03458a8a87 +b0112bb0292344b0297ae4182d2c4565b02c234445b02b23442d2c4b525845441b2121592d2c +01b005251023208af500b0016023edec2d2c01b005251023208af500b0016123edec2d2c01b0 +062510f500edec2d2c20b001600110203c003c2d2c20b001610110203c003c2d2c00b00743b0 +06430b2d2c21210c6423648bb84000622d2c21b08051580c6423648bb82000621bb200402f2b +59b002602d2c21b0c051580c6423648bb81555621bb200802f2b59b002602d2c0c6423648bb8 +4000626023212d2c4523456023456023456023766818b08062202d2cb00426b00426b00425b0 +042545234520b003266062636820b0032661658a2344442d2c2045b0005458b040442045b040 +61441b2121592d2c45b1302f4523456160b0016069442d2c4b5158b02f2370b01423421b2121 +592d2c4b515820b0032545695358441b2121591b2121592d2c45b01443b0006063b001606944 +2d2cb02f45442d2c452320458a60442d2c45234560442d2c4b235158b90033ffe0b134201bb3 +330034005944442d2cb0164358b00326458a586466b01f601b64b020606620581b21b04059b0 +01615923586559b02923442310b029e01b2121212121592d2cb0164358b004254564b0206066 +20581b21b04059b0016123586559b0292344b00425b00725082058021b0359b0052510b00425 +2046b0042523423cb0072510b006252046b00425b0016023423c2058011b0059b0052510b004 +25b029e0b0072510b00625b029e0b00425b00725082058021b0359b00425b003254348b00625 +b00325b0016043481b2159212121212121212d2cb0164358b004254564b020606620581b21b0 +4059b0016123581b6559b0292344b00525b00825082058021b0359b0042510b005252046b004 +2523423cb00425b0072508b0072510b006252046b00425b0016023423c2058011b0059b00425 +10b00525b029e0b02920456544b0072510b00625b029e0b00525b00825082058021b0359b005 +25b003254348b00425b0072508b00625b00325b0016043481b2159212121212121212d2c02b0 +0425202046b004252342b0052508b003254548212121212d2c02b0032520b0042508b0022543 +482121212d2c452320451820b00050205823652359236820b040505821b04059235865598a60 +442d2c4b53234b515a5820458a60441b2121592d2c208a08234b538a4b515a5823381b212159 +2d2c00208a49b0005158b04023208a3812341b2121592d2c462346608a8a462320468a608a61 +b8ff8062232010238ab14b4b8a70456020b0005058b00161b8ffba8b1bb0468c59b010606801 +3a2d2c208a2349648a2353583c1b21592d2c4b505845441b2121592d2cb0024354584b53234b +515a58381b2121591b21212121592d2cb1020042b123018851b1400188535a58b91000002088 +5458b202010243604259b12401885158b920000040885458b2020202436042b12401885458b2 +022002436042004b014b5258b2020802436042591bb940000080885458b202040243604259b9 +4000008063b80100885458b202080243604259b94000010063b80200885458b2021002436042 +59b94000020063b80400885458b202400243604259595959592d00000001000000050000093f +e5da5f0f3cf5001b080000000000ad61b71900000000c142e956ff50fde708a8078b0000000a +0001000000000000000100000783fe39000008e9ff50ff7808a8000100000000000000000000 +0000000000130400008004760096031c0096044b0041040400500434005006a4008702690000 +04a5001202480050045d0041045f008703f2000c033d004103f60041025c009603d900500475 +004b045f007d0000002800d20144020c031204340540054005940622075a080208a4094a0a00 +0a780b980c540cf2000100000013004d0007004b000500020010002f0055000002f001ff0003 +0001400a54bfa50140a5111546a4b8010cb2321fa1b8011540b21f1f6fc731216ec731216dc7 +31216cc731216bc731216ac7312169c7312168c7312167c7312166c7312165c7312164c73121 +63c7312162c7312161c7312160c731215fc731215ec731215dc731215cc731215bc731215ac7 +312159c7312158c7312157c7312156c7312155c7312154c7312153c7312152c7312151c73121 +50c731214fc731214ec731214dc731214cc731214bc731214ac7312149c7312148c7312147c7 +312146c7312145c7312144c73121b80137b26f0821b80136b26e0821b80135b26d0821b80134 +b26c0821b80133b26b0821b80132b26a0821b80131b2690821b80130b2680821b8012fb26708 +21b8012eb2660821b8012db2650821b8012cb2640821b8012bb2630821b8012ab2620821b801 +29b2610821b80128b2600821b80127b25f0821b80126b25e0821b80125b25d0821b80124b25c +0821b80123b25b0821b80122b25a0821b80121b2590821b80120b2580821b8011fb2570821b8 +011eb2560821b8011db2550821b8011cb2540821b8011bb2530821b8011ab2520821b80119b2 +510821b80118b2500821b80117b24f0821b80116b24e0821b80115b24d0821b80114b24c0821 +b80113b24b0821b80112b24a0821b80111b2490821b80110b2480821b8010fb2470821b8010e +b2460821b8010db2450821b8010c40ff4408216957311f5857311f5657311f5152311f464431 +1f4544311f4f4e311f4d4e311f2097309740975097043088010f8c018f849f84af84bf84cf84 +058f689f68af680360697069028f5b018f5a017057018f509f50af50bf50cf50058f519f51af +51038f529f52af52033f7c4f7c02507b607b707b03704e01708f01308f608f708f03008e0100 +8e01408e708e02008e308e408e508e608e708e06107040700260740160730170440100282800 +000012110840370f3fce16010fa21fa20218c7312114c731210ec731210dc731210cc731210b +c731210ac7312109c7312108c7312107c7312106c7312105c7312104c7312103c7312102c731 +2101c73121407c00c73121e0180821dc140821d60e0821d50d0821d40c0821d30b0821d20a08 +21d1090821d0080821cf070821ce060821cd050821cc040821cb030821ca020821c9010821c8 +000821230e45220c45210a452008451f06451e04451d02451c00451a08180816081408120810 +080e080c080a08080806080408020800084bb807ff524bb008505b58b101018e59b0124b004b +5442b9000101ff858d2b2b2b2b2b2b2b2b2b2b2b2b2b2b2b2b2b2b2b2b2b2b2b2b2b2b2b2b2b +2b2b2b2b2b2b2b2b2b2b2b2b2b2b2b2b2b2b2b2b2b2b2b2b2b2b2b7342011d4bb01b5358b096 +1d594bb0325358b0001db1160042594b20b0325323b096515a58b0301d592b0145695342014b +5058b108004259435c58b1080042591610703eb13737456920b0005458b040605944b1300070 +b33200300019701870737373737373747473737373737373737373737373737373732b2b2b2b +2b2b2b2b2b2b2b2b2b2b2b2b2b2b2b2b2b2b2b2b2b2b2b2b2b2b2b2b2b2b2b2b2b2b2b2b2b2b +2b2b2b2b2b2b2b2b2b2b2b2b2b2b2b2b2b2b2b2b2b2b2b2b2b2b2b2b2b2b2b2b2b2b2b2b2b2b +2b2b2b2b2b2b2b2b2b2b2b2b2b2b2b2b2b2b2b742b00000000> +] def +FontName currentdict end definefont pop +%%Page: 1 1 +%%BeginPageSetup +%%PageBoundingBox: 0 0 206 75 +%%EndPageSetup +q +0 g +0.864145 w +0 J +0 j +[] 0.0 d +4 M q 1 0 0 -1 0 74.329308 cm +67.75 3.387 m 124.164 3.387 l 124.164 18.609 l 67.75 18.609 l 67.75 +3.387 l h +67.75 3.387 m S Q +BT +8 0 0 8 70.70321 60.248497 Tm +/f-0-0 1 Tf +[<01>-1<0203040205060708>1<09060a>]TJ +ET +q 1 0 0 -1 0 74.329308 cm +147.75 3.387 m 204.164 3.387 l 204.164 18.609 l 147.75 18.609 l 147.75 +3.387 l h +147.75 3.387 m S Q +BT +8 0 0 8 150.70321 60.248497 Tm +/f-0-0 1 Tf +[<01>-1<0203040205060708>1<09060a>]TJ +ET +q 1 0 0 -1 0 74.329308 cm +106.148 56.188 m 162.566 56.188 l 162.566 71.41 l 106.148 71.41 l +106.148 56.188 l h +106.148 56.188 m S Q +BT +8 0 0 8 109.10321 7.448497 Tm +/f-0-0 1 Tf +[<01>-1<0b0c>-1<0d090e>-1<050f07>1<0809060a>]TJ +ET +q 1 0 0 -1 0 74.329308 cm +3.75 30.586 m 60.164 30.586 l 60.164 45.809 l 3.75 45.809 l 3.75 30.586 +l h +3.75 30.586 m S Q +BT +8 0 0 8 3.603992 33.048497 Tm +/f-0-0 1 Tf +<100e0b0a11120f0a02070809060a>Tj +ET +0.8 w +q 1 0 0 -1 0 74.329308 cm +95.039 19.262 m 94.672 27 101.449 32.363 114.461 35.277 c 133.074 +39.445 131.441 55.703 131.441 55.703 c S Q +133.785 22.595 m 131.344 17.571 l 129.949 22.982 l 130.996 22.032 +132.547 21.884 133.785 22.595 c h +133.785 22.595 m f* +q 1 0 0 -1 0 74.329308 cm +173.063 19.262 m 173.43 27 166.652 32.363 153.641 35.277 c 135.027 +39.445 136.66 55.703 136.66 55.703 c S Q +138.168 22.982 m 136.773 17.571 l 134.332 22.599 l 135.547 21.876 +137.098 22.036 138.168 22.982 c h +138.168 22.982 m f* +1.12 w +[ 3.36 1.12] 0.224 d +q 1 0 0 -1 0 74.329308 cm +111.125 32.664 m 111.125 34.766 109.418 36.473 107.313 36.473 c 105.211 +36.473 103.504 34.766 103.504 32.664 c 103.504 30.559 105.211 28.852 +107.313 28.852 c 109.418 28.852 111.125 30.559 111.125 32.664 c h +111.125 32.664 m S Q +[ 3.36 1.12] 0.224 d +q 1 0 0 -1 0 74.329308 cm +163.922 32.664 m 163.922 34.766 162.219 36.473 160.113 36.473 c 158.012 +36.473 156.305 34.766 156.305 32.664 c 156.305 30.559 158.012 28.852 +160.113 28.852 c 162.219 28.852 163.922 30.559 163.922 32.664 c h +163.922 32.664 m S Q +0.8 w +[ 3.2 0.8] 0 d +q 1 0 0 -1 0 74.329308 cm +104.352 35.625 m 60.328 37.32 l S Q +[ 3.2 0.8] 0 d +q 1 0 0 -1 0 74.329308 cm +157.684 36.473 m 145.832 47.477 60.328 40.703 60.328 40.703 c S Q +Q q +q 0 0 207 75 rectclip +% Fallback Image: x=0, y=0, w=206, h=74 res=300dpi size=796293 +[ 0.24 0 0 0.24 0 0.169308 ] concat +/DeviceRGB setcolorspace +8 dict dup begin + /ImageType 1 def + /Width 859 def + /Height 309 def + /BitsPerComponent 8 def + /Decode [ 0 1 0 1 0 1 ] def + /DataSource currentfile /ASCII85Decode filter /LZWDecode filter def + /ImageMatrix [ 1 0 0 -1 0 309 ] def +end +image +J3KW%GU+$o#COBr:T)u+*=mro@So+\<\5,H7Uo<*jE<[.O@Wn[3@'nb-^757;Rp>H>q_R=Al + C^cenm@9:1mM9jS"!dTMT<$3[GQ$8#0$s<4ZX!SPQ1`B[F7^jpq0?^FN,^V01s.HIuWPG[6 + W[B=(iZioWjnAY&^gM+`4=1jRLW!YA=M/6)*KS9PE`kN%="Tc + _Aoh+fk'&t\ctIN)4XQLiVp8<#YAIm[Y7B-r[TbficW^RQh!2M]87rW`7R`ng.Y + r2oA,QcS@]\G\$U6`4nep,_pH-TAH`l>Cq)%f_I)hX5T5S6nLebM0LLI6LH!bN&*#rP(P"+ + 0X8e4n!IWoKM[fr;O?J":"rmYZ)P=/W\C+#VBr\)#_11HnPfAcpQOe^lZJT&O\>6,mqMI<) + 45nOSh6A`,RV,'LOT#CDfKZUgkE6.nj"d8#o$0"3&T&G8<[td=>o,*#G[4CIPBG^U($C!N\$_3;hY6\sHs_)@$XM]bjl;&$\7 + PhXh`*LjAmmZb(Q2_3`ZK_p.TkF2OIA9u6p5b>IpL\&@@QHqnTP$6]S#BkDG%7Req3JLkBtB=iV!+7RbHbk + a-HE+Q3$uPElru[,[I%1alaH7$VVSE@=Pga+Dd1NS^$GKL!O-L47coJ*a2J%0EJR=cHRe=' + ["!-:cS`u=SF8VeoGnH2dI`t_:"/bU:K>sj*caE0;SonVc[qKnq5bPJ>&r1NUs4-f@T5WQ[rZ + @3_q>R"imJHo*ch78:TC;^Xhuj(2:_!Ol=:G;h6j\E@/d=Sn*mM??%O#@C>k=_h`2.$;-l"I=Nq`D6tqWXXu8c% + h&GC-EK3oA3_*<>*TP(RM^.XAO1;bbUASC@0;6T[R11>#7#@%(/k/Cb*@'WuOciU;8kE/;- + /dj2O0S[L_hc>[,m9p+;N=XI=\U@,7&cGLY#\0J>q=fKRW9![>/Oii(h(XBQ4iUl9A+_Hjo + iMf;\!81=cG/u6n+Ei10P4AD#'kH@[C"?C/%j5*_"<+$F=Vf:"d3=k60b6;iYln=j8ti7-U + 7@Y'*Rnh)jeQnX`\)H;@]24m0cZT2Y0,:YG\,#&OC0nY1N[=q*d]71#Ye/r!3V*CK%E&Y`5 + =51*N"%4/)^L@X>"coO<[klb'#e;OB*>"qTQ74G'4Y*Mu>>taF90r@pqRT!C,:$KVWVc<)U + ;qcXql30JP<=Ya&>)cDE74o@@/s+%uP>gb#;6!VkW`<6)7G$*[9j0(L-JP'!> + jhhe$$2Tb#qh>>:Fe/ZW:th=kc)Pm002j>8i!7B*[qY1?e2?#/h]Z*m]Yg07cuD=, + 71%%/@8*W2YQ-8>E*Xj7EN)A0'6EnSTF4QdC0gq`E:5BA16Q&\2SqGNf_io8IoZ*QKN96m9bCGk[u=:YGh$<;>*Q3>$+ + /eq]M=*h)]0>4j0#iT#?#VVi&^=@i58'CRJkhZ96\6fkX=cn97:'eejY80CI*D3Pj/VKKb1 + ug-(NSkiq_fd[Cah&Q@DU&:')%Ro`4Ae^*<^k,5/b\3#;iGa-)9/(7.V-bG8h[ekL0/pIh2 + FdGZE@W[;9L34I$9rh7O6+*UF9`A+dDSAEPgC8PNA.GIV*0gXEI)WB.X"RieD$?fq1NC>KN + >u5&JZn+#mrI*HuS$-I0SG/a&WiJ#b2_dopW0kUK6!2!1L-)BtAYX[N2rDPu#aHUuRj-9j> + h(r)A$&F#`eXnBUKe%c&^CRol-2'jQugAUm5SVaW5p8n<5^KB&;q_U1=aP'ims(f;p[5Pt" + fH:9)m?cM2[eA[EHRi]@NFe^P%cZ;KYA7H-f=U+HgY9>uE,Q3Q,PNN)b?LHKCJ?N?ZgRSG> + 2seaSd3*m:@bn7$[V<&*?DW74PtC194cpp^c6f]dsMskES0BiX60TD]R,f2Sg/Bf[f=,_Q^ + 27O3Ql]$A`OgQOn0W2'KJ??bF6a"Ac;eVq?Ak>rlK-Ec10Qcd;m!/mH%uYJ:[=K;]qRu`+Qn%?OUcK?ZDhkKCKj%0Al]SS+=RQ+ + 8'uaf"^Zu+$KA6pg4]pI!?$(?`29HhZ)e:s't7Q:US,jHhL$lFTC\4B`;?QD#W&`p`G:9V* + ?p'<4gT;DWL-/Q@VikrboCIa7TB:jSqhKs,C.Km-=$m)!nC$kH:cb&298ChLJ4Yr3.s/YEJ + o=IfF>8s.O-+mR$6><9Zpk"0\$nn3F,=klHZ;!QkWEn0n!L/G*mi#H8LABEG#ckSu:4'_%' + XiSb(sI/++KJM4t>E'0e3VVP%Jrp!PjE/P"e>mV\5$"sbR8/DU$SI-gL#7gItmF)Hie;l;6 + J.TMG!RhN4BVa"6'_']Q&?a%bVV[C<"gIS.&EO%0;%Bi!"-EN'E6RK_q#^'o&ZFFnVuI4ho + _Jnmr]njCd3B4hAIiXq$E*\48+R@N;%h81eIaXXnIjiaUuLi['X:o&&Kqk8RhIMgP&H'j:r + pb@5fKufgX/-5EH_F<:6G'b(G(mi/7fPKbk@(E'sV*`l9qG+_VNQF(h`FX%DNV9HQ-rUV'. + ]8kO]V]`:tJmV3/k=@=!INL`A,7)mC7X5oBG17&9?jIPH$e&_s2P^(X$)q@WH3C.f2epDcJ + [$Hc-bB@e/Drt%dtqXMr.:R<&_8-uQq+UD3i&VR"o18N>L+7^-cnc/Y&*?0#A)A4>:ngPOK + 3e.dP(@SFHc\!?r2]&U&(\0J\&D\8Fh]Dm\M[#,N + 1L*10D',uWNKP$7X$?DVY`-:g!3:b(aLGo@>5MG[k+b#3_n\KY\N%J'e#ZClYCiZ0 + eQVN72FL\i04$4RVKIBtL!Wa.D.h$co!q6N"4C/HCQHD_:C*HNj1Z6([hFXHBX2j7f2O+0( + ::o;]^IrTBaYK6t3.41%Z-IK"UBBM$j;)T#%2X4@$8)Z7F3i6s_!9`f-8q@W(9,f[f3,2SX + #MCtlFZ%P+2p[*s'7^CqK_l*p336aR&V2Q)m%lLeVXnR/PH:X&m!k4[4`ce_-n-k^FYQaa0 + shpWdiU1sC4B1@2D9\ + 9-/Y*<=BnEQs7N5a-@_=.Hod/&<8A:??bV")PpZn39);*D9J#rFiD<,R,+7]3VU8CUD3'N0 + A/=#g8M7]PWD-oFP:T-I;.Y;F'c&@AB8G(F`LoJ)g5F<=7-f,@#b=DjNP*8:GZ74h=>^X.'bpXHM,n@m=^fc`&E + ?Z'JSW_#ME=HcRj9(**&^TojelH9.8.rV3Ot['il4eStu&(=CL/k192f/799%,1,R + .M[LZJ@'4GWM@C?2=Q.Vp5Ndd9:Up]!+eX]^'[&%pEJMc*Z1u?Fjj^r1_68S2/bs?AIFa4NG.N+0 + P@rGo>4sHo'ZY!QQ"Y,mV3\uHQH'-8RN<(h9]tFtF3oIqVV60n8ubU!>um_>^mf9*bnCFpAC_ph^hhDC_n0jQ:##D\qG5UB( + dfaW_mk]F`"T^5mQ^n2cbB+V$=8Y0B`"H%u,Z/?PRHY:)7Pgk^@'nFJlP:CNj91kP&:_G7M + [h=Z8sVTe&d!'dqo?[I!=4kep1c7,_(m>/@Mp:f(Rf + uqdSiIH+3TppM>>gV.@r3J%)Oh=0[/cmoTIop]FE<%"=H! + \"UMV+`$(GpY%M[7sqV>/kJ(n$$O*K+$LO&mul\7h\Jnta=jM\j^!W!e;5d-nJKOgn[lN)N + Km&>bT"F74ArG@cd/r>&N:O1>RSoWN^Ac@6RmK_[Khpk\^U.]6@=PBcPN),Ydl4"L,>LcH' + 3q#uCr@uZAGJbZb-pq;rm9pK`fP4?;N3JEeRK9)CHMKDpQBAo)an!=kKPp*K$MK+pVWJS0m + K@hc6q0/9q#FS]aO6W]h:a"1_,kLMH:!XuFg#.S:?^l=GJ_@eh3H(CbeT9+C#hFtkG"M`PT + n5:lIX1^e=d,;bbELW$Fd`].)B5Ch'p]a_T3;N#FVaQ?HH$YJo/)(<\ar?q++%0YU/gqn\c + $N5,7Za:TR#sR\dkZ"/YP2FU1ccfq8JFVD5MU'T"!.J3\l8S'cEFsSiVga3Tm72kH`>(2V]+A=>,%p@Vlb7 + pJ!RjLn[GPXdAr_FUj;@2g.eZ:Ffr=YV_5rZ/R=ocAY%2sW;@R?q&mcs,mg$.:AY&a;p;&G + N.1WlP/-jAq?!NnO.r(dJ!7]@_&96Kl*S&1X;W+[qan3LS$8?[IImWJBN_GHJ#uo`K">s1q + G_q`3i'@LIJZ@.4%H`+=FXOMUt_*A>0F%;>IHV#ZE\,Tg+U&V8\8,NXCp4r(#F_WLBho?Z2 + ;atg68a3-`7lXTP*;b0aN6Wk,%YF'3UI0]$7gS3P3u7]:+5a4+"QNq7?J/N-kN<]F2;4$,. + 5`LV%Z[gNgV>Q`p9oITtQUBCWg)W.%t5V;(=Mqu=63TtafI`-\DZq_,@'_j9'gHo(<18:A- + m)0jo^`i(K&4AURA;BP[,GF(+E\93d'=+A9JT^T&_R)R#!Q+^EK[9=HbBK<-*n\e[8_*"d6 + *1P#.\UZb_UMQQtY?@Xt/],$(b_P/t[oJG9f/%/EaH_0h)a2:[d175A^tc'-4RpCbiIW@c,>CY-5YLIOOe?kL"Q8QiKNR4))eXa1i4IO-CkLTO#pcWYGSTi\q;6^RsYtrb + lO4@iJ)r>AFZ7O8+I663=l-m]5>;fPOO+4VYrhQh]$^-4nh*\m2?-]A(bmKGEReb7ArQK]c + d!M&/S]#tZlDI^e>$ZU)4bF*4LU*KDOT$_XrVWSBft9>Ei38F'rNEQa("GGAI_Hf#\m;MR- + .op&k.WRr4i?:BoAaS,j/<^?2iHNul02jtdJb`O*dOSjdpnn2i&cRk'[ipCe^-HiIhsQtZ+ + o(`$0"*2idH[BStG4/p!nM=I9sjhh333"4TtD*"Y^#^DSP2&8qn2YS?AZl[0 + <3VsE[6E?BYedN4+sq"O.r_;KdSm@=:48+l97C[Od`3?UOp:N-Ls/pilmItOEpUJWFs'aI8L%-84e]9K?S + n\-fkP[UsrmRSa%gR^/#^h7)+V:#7)#1"a1a3J*PYNYBMacYJ]L4m!Cobg'2eRms:hRFLYM4eGO6'H.\rM++1:knKRd/t#G3;sG)9Ptn;YX$r3%R.M + i(?)uTD()itTiEJ-AlrKTUY1[[$>OE0DV9ZOV\ZIJCS(6ruFbCZP(X*X)SRf'10USA20,]b + i:1Jn0gjjZ$P!:6jku=ro0pt`]dqAA=8YsmMobsB%Y?@ud<`7Q-"a-ZEgK\o+IFdk4]s->d + =+0fRM*K[$%6Rrs6Z^H6F8?mCN_VqdP0)f@Cuh?S0U]XeZ[RsralW,>r>qCc_e$4JD;iW\5 + L+uSA(Jc:T7?>*rMhgbo7[-/Ca4tU^l:_@q`_3QnGPWaKHgdN:7=;f1=!H(br\K13psWK$V + (NAE?n0j7.;/J^HKt3"E;?H37*I"$R./=S1fe2pr0N!HKRO$X9B\:C.&KkaGY^i(rgQq.iZ + MZoQMQQEhc\CThrA&bW?'Y2\*H]q`oS:;QS%t9_1[#Sjc;R=Z%_n@q@YqBM7nCc1AmE[7CY + [Kfr-c2#aN#1SkGicI7f7FQA?4&7^i@^e9pl:T,e<:i$U + ;j!5[8QSpUV"g!HeV$dbeuCT%<)k`F='!og"[,>Mm]@W@_fVVW0Jh)[1D*_IKqi?cB[oG1< + -G!fZ64jdMUb,[Xq`,otZ>f=(U\RfO+k)8B[1hPtP8D'Zk]0GU + in=2u]U[@i; + 'Z"[7G9b3WgW$dQC]!fi&Ft534$di?=$=rQHt)WnXh9EbeT'BHNP/I3m_aS9?!hC%6@ArOg + \6(39AV3?:Oh>=*H$)RB@O[TiV@q4U"oIXL7R4J/n4b>HCi-;io>CKA)u>"cbo90hLET;A: + C/rU\I&TgO"9qIXA;GqA7ubId:%]7t5+-qu8nU!e5!?bneK92636V)J7)4Q;,,-iOc8 + GODSA<`:@P#b4C[WM6gWloHZJjr?-5Y`QrQ^!Z!;bD=4.V2S>O`H1Vb5#HsAX'NeP1;oi2_ + NuujEGPQdSS-_68p5&WgJtc@n_0111jM/R?KOA9_kA=AsCc5P?)HnH*K8>eD$IVG&L+N_)Q + 'Aj.)=!F&%"L3N#il,86eq:ANj2B9`"ZPLb(VH1=(2eGGfRqL:GkkiO2G5`ZSaK2?k*?GsM + b#a@6&66P5RBU'6"U@sLAl7kY>U&CVsjmPSD4\"ZN,G^#-j;gL28SM0T4JJ:2*84M?.-l5D + CjKDU)IlNVeK^mNGTbK3G>N#dXD/4LTpsbJn_]l[I^L5p<;?,^85MaTPsVNOEqHgMOl*2Dl + D20Cm6N&bH)n?=ZTKr!>%pE\3b>4T + *&m?Of^Q'=:5EjcFZe[7)3RU'*O`@n@T_mkUm?asA]$UHC>V"ERDj!70J1CF2]3ZnhSbnIk/-hHF21TW( + =1u$(S'i8]JoFU""unHAfDtGnn<;lPQrM`I9JM4CNWlLC#-q[=6&89TA]0:?WWZQqMI$ju` + J&+0@e&cCED]BHPRe:74E6BUYb/siC^+D@093=OP7G,;Xb0l@ONL$M\.f`*AGi*/#2W9:6U + *)4*3e6P0KHf_X"9JTR:L/8?d+q&YC\m`[4lLMA+FdB,[MVrSlHsQg\fVmDje:6bB%pnr&_p,Zd30g^2Z:S*8fnq%@m..Re + [ZL4:RepJrS.W)Nek\bIaAhR*\%#?khZGs)Xl;UhZSoNVgfq62kV.!oD;O^;M"FO4F(@)9f + '7;*daR>1Zb:T!'AMND&isn8_GD+"KclV^KFT06pKgVR>ZUrhTL$Rih@0ZM98df]S0pjd3&EEqrY*&Teh"mgqZ,BeM$eT_U4m?U]tpA3lU`Xd.X^!sP + )i+_%?fEUes?b^cU;-5Q^/+270_IYI1!dn"9ZU;pVG]+^+_uGoY60l^5T%1'XO.38g8'`,) + Sec_:UFDrGdqbEU7l4WKo,\+KEisuX4dB;05muEd+Xui-T=ZK2TAON_1Z&#kbk'_;n + nHAa*.V8VHlriLr`@PmB7(eLF(?Npf.?^k_s2[H=%.i2EWBZe$N>MepcXb6$\,P:"^g6554 + 5HL?e1AGYOH@Z-i4okp\R(*#Rum:\kmXdPLh@<4[/K;^flUFOKF(e#Sm7A3YKVh=P58;%L3 + s_3b/!$S.@%cbCXgJ%?MOF/-8*6Q9E;]1sc6(;T4BL(coSF_*f1iRi$p\T7R@%/^PFmJ9Jc + 0HG7`r_-jCKYQ[0D@68!;_?;264.?JE/\hpX4n*NQF92\h/3R5bR4H;_PUm&YR#aU;":3[4 + O9:3d1cr&j_V@$qr%>L0+:XMk!?8cX\Dk9U&dm7s6ei<*\2H_Op]@L2#IHCU+NcU#BfjBS$ + TKt/&19ehgC1_a%?hla@K/HC28h%?,\03QGU8?2#fR/2L#BrSXA_K>#me0L!J2RMn2A73FU + '`tP>GW*X4m[eDoKefJim?`6qW(W?l,Ka6Kf]7/5SbCkranu`LLNb&=5id1(BGQ!%Z@uMrY + 6?AB)hQ$J8%lka]RP-H)iI7iY&hBbUcAF@IZ(MVDcs(n?2JGTq4J!(].@W-?:l`5AMga4T& + Fr-pd>C-@ema#&Al,Q%[D+q*lg86gLsGd*/=5Y-dCJ.UBh5T5L':ElGD8D1o%./egPO?GkD + 8+7&!n1VmE.QP9RL.%=8cqm;]9#96;6DNC.*03\%r"e2sak59+a:Lg3W56,3U-NQf.#c109 + ZL+$79V',X+JI/oFCXNb*jR[/?9'!\-4ChJi&Ade?:'8"A9"qb8@VlUpC.+ZkK7B!sCp(S= + <-(\0#E([tJHW+]XA,V8O9"-"r8JpfC,`'2/gkU-l%UM!#2X-TM`5$4rI1\/3A:OVQoCK^c + %YJ7uMB'L\]G84m-c9? + B$Un@#f+'e3!tY/>e5;%M>0KbBiNELsXj%[0ogE$rG1X:tddu]_r,Rk!n#aXO%N4[1`kg)9dpu77 + aYdbH?J?%uql0#5!2+89E7h[`'q([3-n*N8jui+;:PIJ;gDCAI41;$IIl\;I(VID'r5(%oJ + .A%2>U*fE`.`.oOSrLA6Z-r@\h[4>'HR;NXD"I5;P4$p`0ZN[U4sXZ',q3WcuT7>s.Q3/ga + 0-e$=';r'W9l:4a31'tnZ4UF/G**7c.XVFNiN(_^D7!Jd(5`A[c9eb6)"\T:YbGfGZ;<5@q + OHpE94AI,[dF;dWY`$uJ;7.SfeQl3UD-'_c=B1>`-NB%Dln'%8UMVSpL[9biS?a4sUeg,jt0T/prNt$eSRBXRMYliSpT# + ;Vs"2(jg67'Z#`k\QQf0I""XYU$,?iU1Lf@\-e(f$g#/WlR5f'nRK!/4JhH5U:7Mlf6H8=p + L(0j'E__/KXpXP8\5-^1?h=E(uO\9*ChO@O!5%f.OR5E\7?/63Ko4]@fm'. + oXd`-E8dk6)!-EO>TQ+-0`50PV#6gi)Tdg@jc35-d'h`(foTt78:=/s)#b@7e7@.14MV3fH + =e2W*?t7n&6UmFq>8uQ0e#/D+;Hi;u_X&FLC*WlR\16TOg6d_#VuU#7[2<2O#Z\$3aJ'dIL + E]'?9DDQpE4$=03<[=?>O_tdX/FCO-VnDDfM/p^rOZ:Q`Y]`0LeYV=aG\;^6A.eT-s0-Gb= + dY\i`d6P:0BqJE!oh8kDHKT?(!`0=@:m5W!$tn"?#%-!(\Y+:!c_F_L!=,r,r11=;g'X3XUl:?-l'-_)b)WeLq2?#dm;0!BOKj!M2*`12GO!r + WQ^ZG$oJ!?\S*&ffDU4M[^F?^M#4HW[#)?$r=Aj@-.t+a?a:G3X&hA@K<43#UU4\hhi`M/G + h$Pa[4rG);uE(aCq*s!(dj"al1B:?@tea:n1tn/f,QP?Ih5or+Hb>J-nQI@obE1?799K.L@ + 5U!tId6UiZg45)M5(PFNm)jY]@?1:5IT;RG7gOJ,Ns3_HVcj,tJ!7QTCl4,W7T>fK=##!J, + 5)nWJnCf?cWRe.P58RU;H_*b?PH">Ok4rdTH":@/sB\SW7KT$W_6hmW)qq-J`c53n\ + EbPApIA$0XtdE?,Ufa5*K9MIPN#u#TbD'?./H'qPl7+t%Y0U4Z_lg& + (S_mVjNbJ+il<.5(DLPs^>STr7MhK8Z@6$]p/HoBK@$2p/R)mP&>D6X:LKmQ1SUk^caZ"q;8"`-.1C$Z1r:@l[QN]^69AkMFXO?F + rF$L;2qpB'b%VQ4@eQ@ci'665IXVI4^8Z]>mg)@n*CnA)L6*M3KpOMiQa*PrAiEUC\ + @u+t1O%N^jpNA[AgD(#mRtrM"Za!Zqb:*ZF0sN/mksZ_KSic+@9>6X7q($Jh$\ReH#C>k7aEYsc#mGD`4b6-4khp,\!%cW(< + LI>2>aOl4Q[dbR0)N)>4,5pF+c!GE-@gXb7nHUV%`D$V2=+If\Cteg,Ki"LsP#6R!k6#p+h + ;:SQqP%lfnpT8('uLABnSjF1$-XYk<[7sh6,9Y9$-K@UpI"3u!\!X62@i=?2NI/A954MSnu + imgnLF'k\TI@,,P[4]Ym1rW*Gmr\AV-h:B-5g8o0oYY-7l7@7jHh+,_NR3?c[#*k_g5;M`B + f&8Q?r"BjNI^N69j+=GS[;[Ke"MF>(q@0n#/j^sN-hC^Sr;p!>cRc-gS6@ni>ml@>H0T6"b + ?YgZMJp17STD=6<-0K!F&/H'BT$QjsjHu+N6o:W*aY$).gS<0t:G3+2_Kun@2E1Nb,DU=C@fd#=]A!R_qr:h,MS(lMa/@H + :fMhp$<3B#mHCUf>p\TCs2^Q^8)A\g$3.NH#oo/P#NM"eo;u!Br#e'O`c=g&`q]X2r6V/-[i9p;*0f>$P>5k + KR*f?+\V:FjC^BgY6u)(Ck'#kaqU@e"@#EO;#'a5[dN6].Ch\^MHhq:rH?q2A.#K?$/r7\m + 8Q>s`>`1"P:IGW!hp61dp!IOM8S$7p7&Es7Q:kf;q1Qb!(k0_:PBYgDofJ\Xk-*Iml0h!65bBjbU\[a6VF2T/HA' + S?.>UsgeTk.qYqW:\ldbk)G/7[o=_*R$6pT4:ZUp`HpLV=UF)0T7QZ`i"GC*@t<;6%1"u`6 + n)=YWs6!"ap`XsrCI"9Ng,0C.2_&U682$tpJ@s%)BL)R#=7MT*T(8jMkN+YdeXb8JI9oX_t + g7U(]0G+b4Ee5Hi"DPco&Jr*)`A+02jrV(SNe0KlJP<%hg3$Si45gm_k9O1>`R0'A(rfFCBW\3$_KqlQWVV4@.&[c?MPSNr<>q + ^7'TEr$&Y,15aiQ*'-d#(sd!.-8@P5?\C["s9PjY=M8NHu>q(e!%3t*p`9MhbB\?aO:=jBa + rC]hX.&q8ENNLK!D\8p,PiPKK]WBS?L&]^?M96!\_>=3ia5R%G-5Yt>l=;Au"RhoO$:LT:-.?]&;j@NUNg8JJ3UN@;RUOO5WhfgAUS)b! + 2ij!Ion.Dd]FNIgno+9H0"fJB&,iI6&C\=u`L2A\Cm0_%h\&KL'iKc@:jQR2?umi$MA`,t: + pDE"Z_:U6.&CX1mf=):XJDmI"%+m#i+G'V7chE`qs")^Iql*bG5^@7PgpT[$rn'+ZD^l06O + nmL)bM3l/94Bk,pn]+uZOrSkA$i&JnoA'@3d&`T8q&J=,nnT<)pe#VFUiI\YD + ]CDmW`aM`B5iZN"Ce$6Ul+VVgJ"C%)nHJ!Z"05H-'sDCG9-.:ZqK77Mn2R6mP9l5aT&a:XQ + rB=k+Vb2TT_ri+/jo-?X+E9HWY;XLA".kAbD6]RN(58B\B*YpLH,6^Lu\%*a@VIc]G)gB9>'UbQkH5+=3\S(iZ]ML+IiZDV%/j&Fb),KSW$c!q[d;+db:,Po:\W(la6o.)I!UOUT= + cZ5jM4#!JlBLIBlPJ^B-ej?/1?,-I(48_d`Ve1mO2X1- + Q,2Wj)VS&iD6"c:27N=6AUU'5ZM3PRW&ES;4%@+<.!BI:kGq,O-:Hm3MHBL*pB(j#\":`9L + &h#(np;6b^Bie8?Z4E=kMd>"+s/leON(]Y'65>bp$@gO>cUI6G2OpX?BaAe4b&"8]e$<'Gf + r?S0o7Ie!R;]u]OOJ=.ZhpP+]!6G*`UK"mcb;'qe8@hfj<"c!+R[$e']<[+]OO+kQ3gV=-< + @,r3.+OM\cN/C6LJ(2'!8>A)>EB&]!RQ/DR]TcZASjlc(k&0Z&l9g!5';MGYEB1V6V_TH1b + TbJ8OmUgKOO0c,[i1&3?(a&q4MqT(lUn`.RW)B*0eB%02k1gQ"0oS+qA^R=CNECWW + W7b#\FW=VdmQ?H\Gb1=`HlBX=Bjc^'J-;k>k.,5,&5g60!^D:oJHp?L*kfc!6n)kF5]*/Hg + g4`!Z#ZQ1sRG[#N84=UYO+nZJW?5pk.mihuUGFU8APUL3W-0H4kQF@P?'7AujTl&qR<)e"8 + 4\3/)(1]^O!#4+5YD*4rfGp1.$KUJ&V$jHR`k4es8RBJK'GA^6e.Ddq?tGV[+kUaq4M"3RV + "#\8A1ifQWe:?u6Jj'@A;&r?1NLQ/?6o).f@$^Q7^:5h`NIN'[mD$mLrL>fQ@U=AS45k[aU + Y\RES3kX&kFXP/>JT5%hPgk8b%<2aH[Pme24F^1F?\Wfpn%]*7^#SF@Ql[]VB(q\q=ICTpF + V_H'?dSL.%ne"hFOkBG*!sF8.=19Y_k-%-=5UAamN2SV#e\Im\17&&NEVL>cSrC%;k/NoYd + n&=cX#DBU$Y9Lhp0$p[C$&Id.L>!>)Gd3s"j0\3cn-5#$SWc_GieYFj"jAI(`dWS6H3p'<) + ?#?l$l;k=(nDk4QIR:IQ@+im_1$IH$[eAfT<+)J?)AOM@@X5P + V2c\9cbeOKFAZ[V!,(<8Wl!Y#7d##moYiXFa`cA$N.;)n;\")tJB%CO'Rnjo"-iD0]j(GS` + g4h&XfU@1CZ?#RVa\Zq,<\("*hT;]9]S(E+;*2S.mHSKbPI-Ha7/:O1M*]i2:]RCU-YD@L" + 6hRiG942V>*%O>1YO_$^VcjLpP+KS&'8g4Y4&jJE!rVMuKXE3<6a#iG:-c9_[q3(ZJ,kAPp + NVLCYGBt$6J_dBRH65PV>4CH9iB+.t#4:X%WC_f\2*d8m2seLZ[7S8og^/IPciR"J4ok'02 + pLIM4t"E0AldY%/f1!'p,K4n\=8cs23+rO91"8+C3nPF"dMXj>%k9N\hlb!Q!Xp"CA + i/rn^'V6f:_ai;hm,&He+U>QS_L.cSk`'^b>J_FIr.c5QN\9#o/Ymr-qKYL`sHhZdt'/RqV[ANc,_on9&@.5t+qUui + mSKu2B_XOG+B`,I%)`]LV_Sd%ecrA4#8#`:@!N5Rpn+S344(eS&Fr:dOPn:Hq.^oFTqm9Z< + p)(nPs>>SK!>/'>7g*W.r@`h(Ab+R&Z]UOE0NpjSE1 + ]n7e`$cY2Q6QD:)9= + Z0!-V%EXW!==)UY]Od.l$C9#;.R,Au]g0'mrR3tt!gVns.f_S6_E]c?BR0B0dcn^/B:W;H] + XJPQP+pC^97eFJW`!j:*0Tb+L>,0[XMU,rqWR/DOP")U_HbbZd5[g*$H/? + imPceSfRRisLN+`a0rdZ>sl,3Y2.0%018Db;3=A0M>)!sM@9nieJ>>j:9*'Cu\ZkcRlq_K* + J!,7dD@_g2DQfFkM?olBRY'/G@T5]j"9mB;a_&\A2*72u:-#I@0N&L&?u%-O?"2*rrRU(Vq + '^=EPc[15[6d5^YLWmr:-Z/aC[a(0QCas8OM*^NR[JdRR&@kB0W+07Z[+u8-g2_.;=J--ZL + +uM<]7!BLe'T78f()]S+LAMNo=Hs`4$3b94AkUl+r3*[$3Tns0 + 49c)$,d2`M@['$7U,kQ49%cK6=/Hlc7Vc'fG;j]F7-QuF=4ES"Ve)3C^B + Hu\Nc';p6EA]4Ui&5GM/[f&1!JHRpnkQk2B$C0HVFlQ:icWh+n'D2d&@d\8Fa&LUd7c_T8BJN^'@e=,])tj + b@BC$*$(FA&\?AYgYC.R]!F^g!m,7F;c]/MH%9G.SEG&%$mV*uMu>u[]i8#kEm=_"f.qtF)Q^$S]W + C`Lif+>>$4V2Oo]7;b[K8W"\8;9S3sO\^:9ZV-)Sai5)tCU^pN(OF2.Na7A+Fl='jT3B$$U + TO-IV,Li_G7s8fZ%D_Uh8Yp#6BfV0[n:#ULQkFrDO.-ZL93nV$fH@Q(s(!hNjU,3*ib^d?D + W%72>E+$LL + ;E07E\gE#E5AqAN=>D*%X+Qb?AUqmBUTd`2:Oi.4KYg0%Z+4B[=Yu4i+['s7'^<$F(rVs"l*!fpAf2!T5mEF)Dh] + J,=97(^UmC9jD!n%J.!KR2NVOZZ!`aq2Gg`i!&7I/R3AU[QBT0fe9q>f!rdU+ + S'lXu_6UG^&+m7+jq.-jNHSI3WonfiTJ5KEuK6;?4U&-.Mjnr$*"#nV$0PGJR"H+ajRm2tH + [0.>0[g3_bu+7%lTe@OOoY0r^*_DhG8U!F_urZqF:L45-hip[f[3N)c]YKUO#.ie_-]/lcD + p6tE]q\tBd*W&g;$&Q,&0Kq!%u+ThD:$;('sPpeS:Z9A9gYJN#hDp+Rn0_OI*MphM,Rh@]W + /dpis_U&c=2b"u#$]Va6ZIpIr&H@p#I4+euZMQi?=sZKEoHQ`:Q3=n'\2'T9RX!I+9op/i- + 0Ulb,:kLTeSHf,L`dpVM"--d]+<)N!\k`@5`"HD2fr"#j*irLhbt^X%:Jlh[GD7DfM-n,]# + [[Z)md.Zq(]<1-tSiMWQn1aa1Rnb]\CP8@PA\Sf=_"8^"_9i!\KgE_7kVmN*E^%84j9EW%g + d;[XlnFV`u'guLc@P7h2@NCQ'*:]BRR;&%_b0)P4\\Y!mbsA,(JMAm + YrYTr?Do0P8)Ypo_e$L*!P?TheoQtgC0?)^]d@3SE_E93B>8PHk44GgM+`KLXm?pA_9`XS& + )7gra=36m$?CV?XO:!pdO>JdU%P[&70iULnb/>`a=-SJOilU-b + `_:C&'N3!0?`X'Q(5knTE'QY"hVV>Z'XFQ_#@:Jm4kKS0GeT!AV)p;RN\i'SK)_!(hL]%]MZaq1*4Yj_kERRAI8u5a8_o4o.1Etk`IbRa47)pUC=DipjHb3T,r'DV4fJi`(1Dh`U*9J + I#lD0rO,?aW_pQ?Ye_9PXRcCEG/#%u2oK=Ct'^a)< + /O(oCWO\\=4)M,#6aE(l?bag`&gVq76SNG\0NRDc?KpG/]dDNCofK[-?W:tq&j5*#]"XE$d/t%::^gLft*"D"9= + 65&_hqDiG5$R-C'VA]B15`RdGX(9g:N5/Vj;>YHQc^N>jVYVp=gc_k]%u@31217&^W(W+]sI'hX[=# + NZo:9pOA575@q0KB@?gBq8K-'5G.dMn&YRr+orqc$3F4=Q6EcD".lXkJ&:h"Q$39c1qqH:? + d_;kU]"QS'r$Q@_AHErBUbAQ+r_^(ht$/Aak^hNh]`%#90hD(=>V'2$&(_)OP"Y=+VBQ!if + R?M?83=W7cTW`oR9(LO\"Pr=Yu^.nW*Z9M3:K&([5JGdu)7XnsNak?SRtn7OlBWV+:a7d:VE?Qgj`HcWEYO9Q8?t!qq);*Co\Q[Oqss^#Vt5fH^f%PC/5%bJ[k:=ZoY3(R1DIkb9X?S%1efc + *f/?@0FPf&Q1?;R_cEjnH4ARERlTPCAnu*[-/u_i;3[G4G4]+%9(Igja96U06dW=q,3(M_Z + s1$OC2bm;Yofl8P2&/VZ<4+SZ<(o*E)cftHF^H>Tool+X.1iBCg/gJ[r,EYotPHN2\jAR>dlT:FBph*f61H/Fl.FM2j + NQP>==J>@Ga#opO4lq[JgWn0*B/RQP_NQ;rK\'(PZA.E]7I"D<("TY#MItAkI;s2i_CXp-4 + XL3>7g-Ot*2d!1LGsC*R;iTN.@2q&X1;B!O$6M:,Eo/S.i0`bhA^3YmLFBY$)b4s$AoQDtA + )F(EZ9cA=EYB_o0@X>9Uj,5^P`%P^W0]$A@%CqDUOZu%?:q6hc':>U24/UE^<.[jHgJ"GCq + pV(RF5.;kJRG7:Zfm=2d^MuA;(WLI-G)gWa+?(XI&q%#BH1N.k2QB6ZIm;;"]EO?DkIUqJd + .KP'=4VN-F5"p>JU_:V'7I0b!r"'4GLuT&p1r(F>qWl@GQ'O^jEWpjQC\oLF/!8m/@]]b.Y + ="jk'K;B@Gp?JifoI(qVdd'UV2euB3eF!tr*/r=B?I35re(ONa^$,^m-_uG5u"p$ + tI(*R'?O+kM<=?-UooH/_ko]dTH/t&/h4k#a?q.\a`rbV1<-iW)e3sC)0*UY_D;H1A$JuA1$1F8\CVVPo + AF`ZMEXQk#pEh8@kHo?$'de2,>/mKOp?63$>Cq4jKpt/ct5PZ\M#=@oUh?UoIJ'>W"e>J@s + PrePE^(9.qK-mK!Ju,7]BfJA[Jq5#gK@UU8S3ko"HX5k$\umGRPnBa*uIYdmI9#1M1aTRKe + jlbrCUnb4mi`"].8)\YD)i7*:KA*cFe6aZ3ug=TjqaW^'u"=%@)q1^-]\cT0<7>m0)I'/Fo + 1\bSI&nJDXU"KDUi#ZkZ+\N1tLKhqO^g1S?!PB8^>;*$-hKO#BDJ:oQ,@ou:"JKT98#TDr=;C-7IQH@Q@M-EBu-#nh)Kp)!eo50G@[]VbIBnXM^TmW.aNc0U)i\VC:sVUod-7IHV`J@^'@Qr + 7P!MIDmf=8!uh+c.#]oPI=)?8]^UT$nUXE2o;("X"^nt[Gfsb0_?mK5KOQ6:L,s7T=>p[,C + _8$KhB0ZQK\52cfklPFdS5?E'k/^rYmW;X@SLkO9082mEOIgH"q3t2[*fJinJG<%!Ao?9M/ + G&n7k(rl,\4QUP=auaapFr2$aMZ$19tMbJNG5jZ@.nAk$Q=MKnpLI'U\8J*alkD1GW4SRn8 + oPc.U,tB/0iDJsp0bRH0ISJ81Iu#'A2pG;s7V$))@[PgKehdK:HP7VaJ]!np.6k\V_7ZlYL + ])J9-]D)dmdAtL?'RboFE7MYRHVi99A-"@_mpS1.PZT=jaCHIU^Fg>1P+L2:d<eYCnMqg/IGdN9ZqiS"USoeNNJ8@p*S>E)eP?Ac+'%T0&OagaAM@^YHGQ#[F1b=\QZ#$e@""tjQj3O)O>]ZZje^3S + %MpHRj^#GH/gqnu1#&*Vgs8o2=9Wd8kbl5`BoFZueTHFHuA*AaN/SrqV#p2fJhA$L2@ak;# + "BC-_;[3b7Kf?>mRmG5f:Fro8kHae4f*Tt+[^A(>_DfURnWCUdUpPh#%JFOL=\ej[b1^=PP + /%'nR;YeLT:60np-%EFMT/hnD?,/roFnBrh*TfKsAFN50iG/34>Wk*52r?cjDH/jG_oocl<]X#Z8T=FFqB#[i)"31N?:Vs`59K2)T6^/0olKm2]B + ]@hHhIbigAHWQmf&j3;h#**r-u-)raK+.5ER;kJ)C3&TAE4*MuB1CqE+:\^]S45;4P9KA[R + Hu^g`nMkQ!jF#+Sp!!!E*`P&_;o,smc!66n"L + 4F>H:+320A06]n%ZCc[AG3((VIT + nGHoiL.Tr5DT/"6kht\X?T*-O2MGk`$@ahEWAKq8!r(#_rO;*PY7W*8;RAU"5tgj^a?>=7K + o#RLb@O&QAF%]#],[H+qR@+TZTjd8`Vg%oUng-^If&rb#j>>1ma/3;2(608X*XUd" + tBQUr_2JaOmL\i.nPD:rZF]-/=93;(W(GXMl0e%!5=MY`)"K?-)408X`r.]V3GlYY(jJbCG + HWUje+VI`p2f9/3k)+C<$Uf?9t394=ho5`X$PXda.B0I(ddWHqf]Zbs7jqBS9&1 + jpFdYb]tm1r-loL0$JR!:(]2*+D;+(cpL4K9dK;!,h!%3e5!+0Z.te3A9c+I`X57radB)!# + _Y_D0ho$ac2`d!fegYRL.n!k:P^k)UeUhWB%!8\/V%X/X!/On1$$;SkXZV+;#m`+39l29a + AO6a#-O?6dLm8e_]cr;LhbZ/!$Pc-,j\AR4^Jn0]4FGaU.#:e=Q;B.hN,:^U(lD+fUsnh)d + qg_eI5ocnRa[eE'6P9ofW#4r(KCHi:k4k^n;#PMQO&!*M.Kc."\/i(6rX`%asBgi[;/NkBM + 'jn:NZDgV+=YVKiCK4#fL1GBKcb$>/Kr:e]i9*%:.Kj1J+-M95RVP4c@nILkoVt;cn\%7>2"a1lLqFf;0kJQ&JcMRmn]7P;SS.%0Tgf3a)EK + fZalZ9l/Nd;:eKV]u4^)XDGRT+$Oh1g>TbK4eGnpCYF24gB`R6^m7ufK[rjtLks&O.*#;pG + hPF:W/3AjttHWHuJgW5]7&PYb&Ma#sLEkc + .iXNDfD^gL[ZqNJgtBOPI@d7/Y*Ym0-XHO,9FX>V4=V"i44#f3>*(>t*ET=dQ4: + mdXhR;a^066+#^o\%9iKek!)kS6fQD^MIGbBbLKum#;ui68S\a-Y.GbW-h-b`\V-pGhG*/>(&2-Ymp=f4?lf2NrTB#K + Qf&>"?eBkcl%KPjo0S`7?WIMu?1qQpkZ\f+i'iZ^^#[c`U;pi%asGHc'pf3&rs1L_?u?/U9 + q2R@mb[pQ?*4t$2=-,NIgSnIN'7P7BDD-kg)-\-NhZ\kd7I)\b3(u + ucb102n(*>k$+CZ*POu=Lllt9cr"P@ijRp_1]0ec]UcXFfVj(U;Zn:K:)3+RhujF/?\4um& + K3au,8im< + ia%\efJE/N_E)@B_Li! + VL9HfLW=H`phRmakA/B!(Y\R([CCofgCmjJ]E62Fm_*56l?Fu0![d1`5CSVR.[_;#-_s>mh + MWVXgrkIeH`/>DIlqjd"1_4Cl`pAehlt4B"ri$i9iMbM#QE%@$ + >Ir#&[K)m\#M(GXu_gkjI$hmcNs*p@%GSnF%._mj@Vo2Y6B,o^>iRmq2:^G5(H[q!XOEn## + sM[eoO5r9r58mtU03L/p];l0b_ULn"^^mfW&L"RoIrn7Msj``C#2!H9CmLj&r?G73o\%.Mj + XnDQAn1skVf-JI>aE?MK)[gqpu'_,6>nRi8Lr:0:bk32gXnY!!%:hkYR*:_W$n`Lt`pE/r2 + +S$XP2^@l`,k>"_nn0a#cpHRTAj#,^ZF=0ECT[O9q_3rC"nI + \D'aLCes8G&6?oVY=R[nHA69_?q2o]K!ApJ:Ge;"YW%od<:skQ]Sp#fZSpL!V!@.kCFp*X>C2e2POAG0)9p1J"2GA$W)B_Id&_:^-)2b#r + >8-d1(NR)M9pM]d2E;(/gpEt"U2fn^`FSAjZpLe[DGB`e:Gk[PMpSW?3[sRkiI.u6@pZI#" + pODrCJG9q3pa:[g2hUlqK_SW&ph,?VGDGsKM"mQ +Q +showpage +%%Trailer +count op_count sub {pop} repeat +countdictstack dict_count sub {end} repeat +cairo_eps_state restore +%%EOF diff -r 9b9a2497757d -r eb146c5c05a8 0__Papers/VMS/VMS__Foundation_Paper/VMS__Full_conference_version/figures/Time_layers.svg --- /dev/null Thu Jan 01 00:00:00 1970 +0000 +++ b/0__Papers/VMS/VMS__Foundation_Paper/VMS__Full_conference_version/figures/Time_layers.svg Sat Aug 03 19:24:22 2013 -0700 @@ -0,0 +1,198 @@ + + + + + + + + + + + + + + + image/svg+xml + + + + + + + + Program Time + + Program Time + + Physical Time + + Scheduler Time + + + + + + + + + diff -r 9b9a2497757d -r eb146c5c05a8 0__Papers/VMS/VMS__Foundation_Paper/VMS__Full_conference_version/figures/VMS-core__internal_workings.eps --- /dev/null Thu Jan 01 00:00:00 1970 +0000 +++ b/0__Papers/VMS/VMS__Foundation_Paper/VMS__Full_conference_version/figures/VMS-core__internal_workings.eps Sat Aug 03 19:24:22 2013 -0700 @@ -0,0 +1,1926 @@ +%!PS-Adobe-3.0 EPSF-3.0 +%%Creator: cairo 1.8.6 (http://cairographics.org) +%%CreationDate: Sun Feb 06 23:03:28 2011 +%%Pages: 1 +%%BoundingBox: 0 0 366 156 +%%DocumentData: Clean7Bit +%%LanguageLevel: 2 +%%EndComments +%%BeginProlog +/cairo_eps_state save def +/dict_count countdictstack def +/op_count count 1 sub def +userdict begin +/q { gsave } bind def +/Q { grestore } bind def +/cm { 6 array astore concat } bind def +/w { setlinewidth } bind def +/J { setlinecap } bind def +/j { setlinejoin } bind def +/M { setmiterlimit } bind def +/d { setdash } bind def +/m { moveto } bind def +/l { lineto } bind def +/c { curveto } bind def +/h { closepath } bind def +/re { exch dup neg 3 1 roll 5 3 roll moveto 0 rlineto + 0 exch rlineto 0 rlineto closepath } bind def +/S { stroke } bind def +/f { fill } bind def +/f* { eofill } bind def +/B { fill stroke } bind def +/B* { eofill stroke } bind def +/n { newpath } bind def +/W { clip } bind def +/W* { eoclip } bind def +/BT { } bind def +/ET { } bind def +/pdfmark where { pop globaldict /?pdfmark /exec load put } + { globaldict begin /?pdfmark /pop load def /pdfmark + /cleartomark load def end } ifelse +/BDC { mark 3 1 roll /BDC pdfmark } bind def +/EMC { mark /EMC pdfmark } bind def +/cairo_store_point { /cairo_point_y exch def /cairo_point_x exch def } def +/Tj { show currentpoint cairo_store_point } bind def +/TJ { + { + dup + type /stringtype eq + { show } { -0.001 mul 0 cairo_font_matrix dtransform rmoveto } ifelse + } forall + currentpoint cairo_store_point +} bind def +/cairo_selectfont { cairo_font_matrix aload pop pop pop 0 0 6 array astore + cairo_font exch selectfont cairo_point_x cairo_point_y moveto } bind def +/Tf { pop /cairo_font exch def /cairo_font_matrix where + { pop cairo_selectfont } if } bind def +/Td { matrix translate cairo_font_matrix matrix concatmatrix dup + /cairo_font_matrix exch def dup 4 get exch 5 get cairo_store_point + /cairo_font where { pop cairo_selectfont } if } bind def +/Tm { 2 copy 8 2 roll 6 array astore /cairo_font_matrix exch def + cairo_store_point /cairo_font where { pop cairo_selectfont } if } bind def +/g { setgray } bind def +/rg { setrgbcolor } bind def +/d1 { setcachedevice } bind def +%%EndProlog +11 dict begin +/FontType 42 def +/FontName /f-0-0 def +/PaintType 0 def +/FontMatrix [ 1 0 0 1 0 0 ] def +/FontBBox [ 0 0 0 0 ] def +/Encoding 256 array def +0 1 255 { Encoding exch /.notdef put } for +Encoding 1 /uni0047 put +Encoding 2 /uni0072 put +Encoding 3 /uni0065 put +Encoding 4 /uni006E put +Encoding 5 /uni0020 put +Encoding 6 /uni003D put +Encoding 7 /uni0056 put +Encoding 8 /uni004D put +Encoding 9 /uni0053 put +Encoding 10 /uni002D put +Encoding 11 /uni0063 put +Encoding 12 /uni006F put +Encoding 13 /uni0042 put +Encoding 14 /uni006C put +Encoding 15 /uni0075 put +Encoding 16 /uni0061 put +Encoding 17 /uni0070 put +Encoding 18 /uni0069 put +Encoding 19 /uni0074 put +Encoding 20 /uni0052 put +Encoding 21 /uni0064 put +Encoding 22 /uni0067 put +/CharStrings 23 dict dup begin +/.notdef 0 def +/uni0047 1 def +/uni0072 2 def +/uni0065 3 def +/uni006E 4 def +/uni0020 5 def +/uni003D 6 def +/uni0056 7 def +/uni004D 8 def +/uni0053 9 def +/uni002D 10 def +/uni0063 11 def +/uni006F 12 def +/uni0042 13 def +/uni006C 14 def +/uni0075 15 def +/uni0061 16 def +/uni0070 17 def +/uni0069 18 def +/uni0074 19 def +/uni0052 20 def +/uni0064 21 def +/uni0067 22 def +end readonly def +/sfnts [ +<00010000000a008000030020636d617000a2f14100001fdc0000006c637674207d0742a80000 +2048000002706670676d49d7df92000022b80000060a676c7966489d9ecf000000ac00001f30 +68656164d5ceeae0000028c400000036686865610f7e06b2000028fc00000024686d74785bc6 +0894000029200000005c6c6f636153405a880000297c000000306d617870037c02c9000029ac +0000002070726570292ded16000029cc000004ad00020080015e0380045e0003000700264016 +059c039d049c070017003700030000079c019d049c00002ffdfded012f5f5dfdfded31301311 +211125211121800300fd800200fe00015e0300fd0080020000010050ffe704d305d2001a0137 +403a1c400b0b024b55060103370e470e570e670e04006a167a16025516010506150645060303 +680078000200160c0c024b000f0e0c44170f370f020fb8fff0400b1010024b0f0c0f0f024b0f +b8ffe8400b0c0c024b0f040d0d024b0fb8ffeab40c0c064b0fb8fffab40d0d064b0fb8ffe840 +571010064b0f0645181638160200160c1010024b16060f0f024b16200b0b024b16100c0c024b +16120d0d024b16120c0c064b16120d0d064b160c0e0e064b161b080168017801030223100103 +2813011803380302020c510eb8ffc0401a0c0c024b0e090118000100001909100b0b024b0949 +1303491913b8fff0b70b0b024b13091903003f3f2b10ed10ed2b10cd5f5d3210d62bed5f5d5d +5f5d5f5d0110d62b2b2b2b2b2b2b2b5f5dfdd42b2b2b2b2b2b2b5dfdcd10c62b5d5f5d5d5d5f +5d5f5d3130012b010726232200111400333237112335211106042320001110002132048d5397 +91e6fef60105e1a063cb019350fee287fed1fea101810147e50553a570febcfef5fefeca6001 +57aafd824453019b0155015401a7000100960000031c0443000e00af401e0a400b0d024b0810 +18102810c81004c70ed70e020e06094d064d68070107b8ffecb41313024b07b8ffeeb4101002 +4b07b8fff240110f0f024b07040b0b024b07040c0c024b07b8ffeeb40f0f064b07b8fffcb40c +0c064b07b8fff2b41010064b07b8fffc40250e0e064b070f170a270a370a470a570a670a0600 +050a400e0e064b0a02520c0806070a0c07003f3f3f10edcd2b325f5d0110d62b2b2b2b2b2b2b +2b2b5deded10c65d5d3130002b01262322061511231133153633321702cd3e3f6597bebe68cd +336003782bba83fd9a042fabbf1200020041ffec041c04430019002201ff408724400b0b024b +58170103b807018a079a07aa07ba07ca07da0706025705016808780888089808a80805280838 +08480858086808780888089808a808b808c808d8080c00571877180208221010024b08180f0f +024b08180c0c024b082c0d0d024b08100c0c064b08100d0d064b081f4e471e01021718371847 +18671887189718a718b718c7180918b8ffe0b40e0e064b18b8ffdeb41010024b18b8ffdcb40f +0f024b18b8ffe2b40c0c024b18b8ffd4b40d0d024b18b8ffe4b40c0c064b18b8ffe4406b0d0d +064b18011e4e014e87100138104810581068100410100e0e064b10101010024b10100f0f024b +101c0b0c024b10160d0d024b100c0c0c064b100c0d0d064b102387079707a707030027053705 +47055705040207522a083a084a08030357086708770803070817080208b8ffc0b40b0c024b08 +b8ffd4b40d0d064b08b8ffc040350d0d024b080c1e50470157016701a701b701050001400f0f +024b01400d0d024b01400f0f064b010105581a011a5214100f0f024b14b8ffe8b40d0d024b14 +b8ffe840200e0e064b140c0f0f064b14671401024a145a140205100c0c024b05520c0b140700 +3f3fed2b5d5f5d102b2b2b2bed5d11392f2b2b2b5f5ded10d52b2b2b5d715f5ded5f5d5f7101 +10d62b2b2b2b2b2b2b5d5deded10dd2b2b2b2b2b2b2b5d5f5dedc42b2b2b2b2b2b5d5f5d715d +5f5d5d5f5d3130012b0121141716333237170607062322272635103736333217161514012207 +060721342726040dfcfc675b8fa36d502c5b728cca8d9da190c5e5827efe247f56520b025148 +4f0205bc65585f892c202a8997ff0109a08f817ccd3f0169524e74734d5400010087000003d8 +044300110103401813400b0b024b070f170f0201771301004d11101010064b11b8ffd4b40e0e +064b11b8fff8b41313024b11b8fff440111010024b110a0f0f024b11080c0c024b11b8fff440 +110d0d024b111c0b0b024b110e0f0f064b11b8fff8b40c0c064b11b8fff8b40d0d064b11b8ff +f440100b0b064b11084d070917092709030009b8fff4400b1313024b09040d0d024b09b8fff6 +b41010024b09b8fff4400b0f0f024b090a0b0b024b09b8fff8b41010064b09b8fff4400b0e0e +064b09080c0c024b09b8fffa40110f0f064b091204520e110a090a0a060e07003f3f3f3f10ed +0110d62b2b2b2b2b2b2b2b2b5f5dfdd42b2b2b2b2b2b2b2b2b2b2b2bed5d3130005f5d012b21 +1134262322060711231133173633201111031a6779418e26be823c5ed50160026fab894e39fc +e4042f8a9efe54fd690000000002007a018b03c0036c00030007002d401b0105870207061706 +37065706770605060803840207840706010006002f5f5dfddeed0110d65d3cfd3c3130011521 +350115213503c0fcba0346fcba036c8d8dfeac8d8d0000000001000dffec04a605b900060133 +b10202435458b90004ffe8400d0c0c024b040402010502020201002f3f3f111239012f313000 +2b1bb10602435458403804601010064b04400c0f064b04100a0a064b47080100370401010808 +18082808580804054606034602067600027601040400754701010104b8ffc0b42227064b04b8 +ffb0b41a1d064b04b8ffc040261416064b04240b0b064b480401370401170427043704570467 +0477040600048e010906020202003f3f3fed5f5d72712b2b2b2b012f5ded39192f1810ed10ed +10ed10ed5d5f725f5d3130002b2b2b1b40414708010037040101080818082808580804054606 +0346020676000276010404007547010101480401370401170427043704570467047704060004 +8e010906020202003f3f3fed5f5d7271012f5ded39192f1810ed10ed10ed10ed5d5f725f5d31 +30595905230133010133029465fddede0179016bd71405cdfbc90437000000010014ffec05a3 +05b9000c01f0401401400e0e064b04400e0e064b0e401010024b0002435558401d0c0e180e28 +0e380e03080e180e380e480e580ea80eb80e070606080702003f3f012f5d7110d631301b40ff +4a030145020143087308024c0a7c0a0203280301280a0127080102970101980401870701880b +0101180e280e380e03080e180e380e480e580ea80eb80e070000460c0546380c480c02370647 +0602022806480602270c470c020672070c720b01010a0b04040875070a75680b016707010b73 +0207730309090275c70301270377038703a703d703e703060003770901016709010809180902 +680988099809a809b809c809d809e809f80909580101580401004a0201034701014704010107 +011701020701270187019701a701b701c701d701e701f7010a07041704020704270487049704 +a704b704c704d704e704f7040a070117010217014701570167017740490187019701a701b701 +c701d701e701f7010d0704170402070417042704470457046704770487049704a704b704c704 +d704e704f7040f00097102017104710702090c0806080b020702003f3f3f3f3f10ede410ed5f +5d715d715d715d715f5d5d5f5d5f5d5d5d715d5f5d012f5f5d71ed39192f1810ed10fd5d5ded +10ed39192f1112392f1810ed10fd5d5d5f5d5ded10ed5f5d715f5d5d5d5d5f5d5d5d5f5d5d5d +5d3130592b002b2b2103012301032301330101330104e5aefec032feb7aabe01125b015d0142 +5a012903adfc3f03c1fc5305b9fbd3042dfa470000010050ffe7038805d2002601ccb1020243 +5458401907221a0e180b0b024b0e120c0c024b0e22070e1a0425131714b8ffc040120c0c024b +1411000401251749110304492509003fed3fed10cd123910cd2b1239121739012f2b2bcd2fcd +31301bb106024354584086082401071001002520452065207520042a0b01034828a828026813 +0113074507223722672203221a001a45380e01870e01000e2777040102351e651e751e03351f +451f651f751f040a0c3a0c4a0c6a0c7a0c0533220103380e010a0b1f1e042548145814681478 +1404141137014701570167017701a701b70107000125174911044925091103003f3fed10ed10 +cd5f5d10cd5d1217395d5f5d5d5d5d5f5d0110d65f5d5dedc410d45dedc45d5d3130005f5d5d +5f5d5d1b4086082401071001002520452065207520042a0b01034828a8280268130113074507 +223722672203221a001a45380e01870e01000e2777040102351e651e751e03351f451f651f75 +1f040a0c3a0c4a0c6a0c7a0c0533220103380e010a0b1f1e0425481458146814781404141137 +014701570167017701a701b70107000125174911044925091103003f3fed10ed10cd5f5d10cd +5d1217395d5f5d5d5d5d5f5d0110d65f5d5dedc410d45dedc45d5d3130005f5d5d5f5d5d5959 +3737161633323635342627272626353436333217072626232206151416161717161615140423 +22544938a742758e4f9f769677e8b6f35f3b28a44666752a4b74789679fef7dec343b8293780 +634a7f4b3746c087a4d84fae1d36745b385c3e383947c598a5e60001009f01fa024b02a90003 +00254017280368037803a803040307002700370003000004014800002fed0110d65f5dcd5d31 +30133521159f01ac01faafaf000000010041ffec03b5044300170119401e450501a101010328 +1938190200870d970da70d030200070d870d970d030db8fff4b41010024b0db8ffeab40f0f02 +4b0db8ffeab40b0c024b0db8ffe840610d0d024b0d074e38124812028712a712b712c712e712 +050012101010024b12180f0f024b12200b0c024b12180d0d024b12060e0e064b120c0e0e064b +12120c0c064b12100d0d064b1218250a350a450a032a043a044a0403030c52070d170d020db8 +ffc040160b0b024b0d0f015208001800020000400b0b024b0004b8ffe8b40c0c024b04b8ffe8 +40190d0d024b0452150a180c0c024b0a180d0d024b0a520f0b1507003f3fed2b2b10ed2b2bdd +2b5f5ded10dd2b5ded5f5d5d0110d62b2b2b2b2b2b2b2b5f5d5dfdd42b2b2b2b5d3c5f5d5f5d +5f5d5d313001072626232206151416333237170623220035100021321603af5e1d93479bb6ba +a580824b99e2dbfee20129010253c203d8861d34d9bdbcc563a0630126fb0100013646000002 +0041ffec040a0443000b0015013c402517401010024b17400b0c024bb7050101381701114e17 +063706470667060406041010024b06b8ffdeb40f0f024b06b8fffcb40b0b024b06b8ffe4b40c +0c024b06b8ffd4b40d0d024b06b8ffeab40e0e064b06b8ffe0b40c0c064b06b8ffe440760d0d +064b060c4e87009700a700b700c700e700063800480058006800040000101010024b000e0f0f +024b00200b0b024b00200c0c024b00160d0d024b000c0e0e064b00100c0c064b000c0d0d064b +00166a030165090103670e0168130102450e550e650e034a135a136a13030e100f0f024b0e52 +0913b8fff040160f0f024b13520309180f0f024b09180f0f064b090b03b8ffe8b40f0f024b03 +b8ffe8b50f0f064b0307003f2b2b3f2b2b10ed2b10ed2b5d5d5f5d5d5f5d5d0110d62b2b2b2b +2b2b2b2b5f5d5dfdd42b2b2b2b2b2b2b2b5ded5d5f5d31302b2b133400333212111000232200 +1310213236351021220641010bdae6fefefce0e5ff00c8011d8597fee4829b021af80131fedb +fefcfefdfed5012e0100fe6dd8bb018ed400000300960000043705c6000f0018002201ac406f +24400b0b024b05060103580a680a02a805b805c805030178150102480a780a880a980aa80ab8 +0ac80ad80ae80af80a0a0a1545380748070207200b0b024b071e0c0c024b07160d0d024b0710 +0c0c064b07100d0d064b07220e0e064b070d10441a44011f45070d170d270d370d040db8fffa +400b1010024b0d100b0b024b0db8fff4b40c0c024b0db8ffd8b40d0d024b0db8fff4b40e0e06 +4b0db8fff4b40c0c064b0db8fff4400f0d0d064b0d24070117012701030001b8ffecb4131302 +4b01b8fff4b41010024b01b8fffa400b0f0f024b01040b0b024b01b8fffeb40d0d024b01b8ff +eab41010064b01b8fff0b40e0e064b01b8ffff40330c0c064b0123671c0101371c471c571c03 +020a0a111348190722014722572267227722041722372247229722c722f722060022b8ffc0b4 +0f0f024b22b8ffc0401f0f0f064b22100d0d064b22221a17021048041a1c200f0f024b1c4801 +080402003f3fed2b3210ed333211392f2b2b2b5f5d717233ed3239192f5f5d5f5d011810c62b +2b2b2b2b2b2b2b5f5d10d62b2b2b2b2b2b2b5ded10eded10d42b2b2b2b2b2b5dedc45d5f5d5f +5d31305d5f5d012b212111243332161514060716161514040111163320353421220311163332 +36353426230238fe5e010b76d9ee985cae9ffee5fe423f5d011cfefb644f6737bcada5c105b9 +0dbbae66a8152ac2a7c1e60519fe5b06e7cbfdb9fdd10a8d9a8f8800000000010096ffec0207 +05e6000800c7b9000affc0b41313024b0ab8ffc0b41010024b0ab8ffc0402a0c0c024b070a17 +0a270a370a470a570a670a770a080706170627060306024d070117012701d701040001b8ffec +b41313024b01b8ffeeb41010024b01b8fff240110f0f024b01040b0b024b01040c0c024b01b8 +ffcc40170e0e064b01180f0f064b01130c0c064b01160d0d064b01b8ffec401b0b0b064b0109 +b705c70502010a081a082a083a08040652070b0100003f3fed5d5f5d0110d62b2b2b2b2b2b2b +2b2b2b5f5dfdc65d5d3130012b2b2b13113311141633152096be6350fe8f012f04b7fb695663 +aa0000000001007dffec03e3042f001200fb402714400b0b024b7714010a4d074d0708011708 +47087708a708048708b708e70803080c1010064b08b8fffab40e0e064b08b8ffecb41313024b +08b8ffec400b1010024b08160b0b024b08b8ffeeb40d0d024b08b8ffccb40e0e064b08b8fff0 +b40c0c064b08b8fff440150d0d064b08004de812f81202071217122712030012b8fff8b41313 +024b12b8fffab41010024b12b8fff640230f0f024b120c0b0b024b120c0c0c024b12080d0d02 +4b12040c0c064b12040d0d064b12b8fffa40110e0e064b121303520e090a0e0b08061206003f +3f3f3f10ed0110d62b2b2b2b2b2b2b2b2b5f5d5dfdd42b2b2b2b2b2b2b2b2b5d7172eded5d31 +30012b01111433323637113311233506062322263511013bd75e9c19bebe20c15cb0bb042ffd +55f86c4702f0fbd1943f69caba02bf0000020050ffec03e40443001b002501d3b62740101002 +4b25b8ffecb40b0c024b25b8ffee40490d0d064b071317130201672077200202280f480f0200 +b70fc70fd70fe70f04010025150f0537184718571867187718871897180718254d0a4d881501 +150c1313024b150c1010024b15b8fff8b40f0f024b15b8fff040110c0c024b151e0d0d024b15 +0c0e0e064b15b8fff040440f0f064b150c0d0d064b1527214e38050100050c0f0f024b05160b +0b024b05100c0c024b05120d0d024b050c0e0e064b050c0c0c064b050c0d0d064b05263a0301 +032500b8ffc0b40d10024b00b8ffc040320d0f064b480058006800780004000218191c520a08 +0e52080f180f280f380f480f580f980fa80fb80fc80fd80fe80f0c000fb8ffc0b41317024b0f +b8ffc040240d0d024b0f124a1e5a1e02031e52a808b80802580801006a087a08020347085708 +020008b8ffc0b41414024b08b8ffc0b41313024b08b8ffe8b41010024b08b8ffe8b40f0f024b +08b8ffc040131313064b08080c2352020c5212190b020b1207003f3f3f10ed10ed11392f2b2b +2b2b2b5f5d5f5d5f5d5ded5f5d10dd2b2b5f5ded10d5ed10cd10dd5d2b2bcd5f5d0110d62b2b +2b2b2b2b2b5f5ded10d62b2b2b2b2b2b2b2b71ededc65d10c41112395f5d5f5d5f5d3130005f +5d2b2b012b250623222635342433321710232207273636333216151114171522260326232206 +151433323702e472eb7eb9011ddd3c4ce8b2605036bf57e9d35474732b5a2490b6c5906f7b8f +b788a3e11a0104609f2c3fd4e7fe808d2f5f4201df149465a78900020087fe5c042c0443000f +001b014d40161d400b0b024be71d01164e470af70a02470a970a020ab8ffe4b40f0f024b0ab8 +ffeab40c0c024b0ab8ffd4b40d0d024b0ab8fff4b40e0e064b0ab8ffe6b40c0c064b0ab8ffea +401e0d0d064b0a111101044d014d1702010702170227028702e702f702060002b8fff4b41313 +024b02b8fff6400b1010024b02040d0d024b02b8fffa40110f0f024b020a0b0b024b02080c0c +024b02b8fff4b40e0e064b02b8fffe40330f0f064b02020c0c064b02020d0d064b021c580d68 +0d025707670702024514014a190114100e0e064b14100f0f024b14520d19b8fff0b40e0e064b +19b8fff0400c0f0f024b195207010e03060db8fff0b40e0e064b0db8fff040140f0f024b0d0b +07100e0e064b07100f0f024b0707003f2b2b3f2b2b3f3f10ed2b2b10ed2b2b5d5d5f5d5d0110 +d62b2b2b2b2b2b2b2b2b2b5f5d71eded103c10d42b2b2b2b2b2b5d71ed5d31302b2511231133 +15363332121114002322260311161633201134262322060145bebe6c99e4feff00f2449b1612 +74370162a8b928743bfe2105d3586cfee4feeef4fecb30032cfd901b310190cbbc3800000002 +0050000001c105c4000b001100d9b613400f0f024b13b8ffc0b60d0d024b097b03b8fff4b40e +0e064b03b8fff8b40f0f024b03b8fffab40c0c024b03b8fff940200c0c064b03110e0c4d7711 +010011041313024b11021010024b110e0f0f024b11b8ffeeb40b0b024b11b8ffecb40c0c024b +11b8ffe6400b0d0d024b110e0f0f064b11b8fff8400b0c0c064b11120d0d064b11b8ffd64010 +0e0e064b11081111064b11130d511000b8ffc040120f0f024b007c06400f0f024b06100c0a10 +06003f3f10d62bed2b10ed0110d62b2b2b2b2b2b2b2b2b2b2b5f5dfdc610d42b2b2b2bed3130 +012b2b013216151406232226353436031123352111014b314545313045443793015105c44530 +314545313144fa3c038fa0fbd10000000001004fffec02fc0558001500cab90017ffc0403f0c +0d024b0813181302281701871001109708010809010006090309010c0c064b094d4800580068 +00f8000400000c1313024b000a1010024b00120f0f024b00b8fff2b40b0b024b00b8fff0b40c +0c024b00b8ffe8401d0d0d024b00160e0e064b00100f0f064b00260c0c064b00280d0d064b00 +b8fffc401b0e0e064b002c133c13020f0d0205070d52120152085207120b0706003f3f10eded +10ed10c63c10c65d012f2b2b2b2b2b2b2b2b2b2b2b5f5ded2b3c103c10cd10dd5dc65d5d3130 +005d012b13233533353711211521111416333237170623222635cb7c7cbe0126feda5b65494e +1c768d7faf039996e049fed796fdec877225a71ebd90000200a0000004a805c8000f001a0106 +4017670e770e02010e040b00460f0f1c16060d0d064b16450bb8ffe8b40b0b024b0bb8ffea40 +120d0d024b0b471c1044044407052705020005b8ffe4b41313024b05b8fff2b40f0f064b05b8 +fff0b41010024b05b8fff4b40f0f024b05b8fffcb40c0c024b05b8fffab40d0d024b05b8fffe +b40c0c064b05b8fff4b40d0d064b05b8ffeab41010064b05b8fff040290e0e064b051b481701 +0245150103570e01025513015a196a197a1903101906090e1103134901010519b8ffe8400d0f +0f024b194909000805080902003f3f3f10ed2b11392fed333233113311335d5d5f5d5f5d5f5d +0110d62b2b2b2b2b2b2b2b2b2b5f5deded10f62b2bed2b103c10ed111239395d313021012227 +112311322433201114060701011116333236353426232203c3fe794391c80b0121420210aa75 +01a9fcc04844b4a4b0be1e02750afd8105b90ffe5c8add1bfd5e0505fe240a74957b6c000002 +004bffed03ec05e6000e0019011e40161b400b0b024b004d0d190c4d470d010d201313024b0d +b8ffeab41010024b0db8fff6400b0f0f024b0d080b0b024b0db8fff6b40c0c024b0db8ffe440 +0b0d0d024b0d0c0f0f064b0db8ffe2b40c0c064b0db8fff240660d0d064b0d140c0c0c064b14 +4e87060138064806020006080f0f024b061a0b0b024b061a0c0c024b06120d0d024b060c0e0e +064b06100c0c064b060c0d0d064b061a251635164516032a113a114a11030358036803021618 +0b0c024b16100f0f024b16520311b8ffe8400e0b0c024b115209480901020e0a03b8fff0b60f +0f024b030b09b8ffeeb70d0d024b09070d00003f3f2b3f2b3f5f5d10ed2b10ed2b2b5d5f5d5d +0110d62b2b2b2b2b2b2b5f5d5dfd2bd42b2b2b2b2b2b2b2b2b5dfd3c10ed3130012b25350623 +22023534003332171133110326232206151021323637032e63bdc9fa0120c7a656bebe487d99 +bd01602d7e10014f630120f0f101554e01f1fa1b03366ce4b0fe7d392000000000020050fe5c +03c804740030003c0160402c48195819681978190400272b372b020265017501020320101c12 +064e282b382b482b582b682b782b882b072bb8ffeab40e0e064b2bb8fff0400f0d0d064b2b19 +3a4e1c0e1010024b1cb8fff440860c0c024b1c120d0d024b1c3e00234e0d344e12060e0e064b +120c0f0f024b12120b0c024b12120d0d024b123d17010188199819a819b8190488189818a818 +b81804280c380c02006701770102026a317a3102653775370203102037281a171f181537180f +0f024b37521f40090a064b1f9708a708b70803970ba70bb70b030028530825530b01b8ffc0b4 +1114024b01b8ffc0b40b0c024b01b8ffc0b41114064b01b8ffc040090c0c064b0103522e31b8 +ffe8400d0f0f024b3152152e0e0b061507003f3f3f10ed2b10fdc62b2b2b2b10edd4fd5f5d5d +d42bed2b10c6123939111239395f5d5d5f5d5f5d5d5d5d0110d62b2b2b2bedd4edc610d62b2b +2bedc6d42b2b5ded111239395f5d5f5d5f5d3130133716333236353423220623223534363726 +1134363332173717071615140607070606151433323633321615140423222601220615141633 +32363534266067a68c8195bc20a82fe46b4fe2eaac9e595f7c7249caa49d1c5e622bb62c9eb1 +fef7cb68e6014d637d796765727bfedb986f59428220ac3556136a0106a8e0417275565f99a2 +dc101003251e291f978694b64a05048c6470938f74648c000000000200030000000000140001 +0000000000340004002000000004000400010000f016ffff0000f000ffff1000000100000000 +000600380000000000170000000100020003000400050006000700080009000a000b000c000d +000e000f001000110012001300140015001605e6000005b9001905b90014042f00140000ffe7 +0000ffec0000ffecfe5c000005c30000fe5400000338000005d300000253000005c8000a0000 +0000000000000000000000000000000000000000000000000000000000000000000000000000 +0000000000000000000000000000000000000000000000000000000000000000000000000000 +000000c800cd00cd009600b400b400000000000000be00c800c8008c00a0009b009600000000 +00be00c800c8000000aa00aa000000000064007d0082008c009600a00064007d0082008c009b +00d20064007d0082008c009600a002300136011801a401d600460218012c01c2000001d600eb +00eb01d1017f0154011301450168012c008d02350159033f0505012c00b4006e0136015e01cc +01cc04d8006e006e01d600d2005f01f4012c007802d00190037f00800280006e00b4000000a5 +fea2003200b9008c000000000000000000000000000000000000000000000000000000000000 +0000000000000000000000000000000000000000000000000000000000000000000000000800 +05e6000005b9001905b90014042f00140000ffe70000ffec0000ffecfe5c0000000000000000 +0000033800000000000002530000000000000000000000000000000000000000000000000000 +0000000000000000000000000000000000000000000000000000000000000000000000000000 +0000000000000000000000000000000000000000000000c800cd00cd009600b400b400000000 +000000be00c800c8008c00a0009b00960000000000be00c800c8000000aa00aa000000000064 +007d0082008c009600a00064007d0082008c009b00d20064007d0082008c009600a04036544b +214a494847464544434241403f3e3d3c3b3a39383736352f2e2d2c2826252423221f18141110 +0f0d0b0a090807060504030201002c4523466020b02660b004262348482d2c452346236120b0 +2661b004262348482d2c45234660b0206120b04660b004262348482d2c4523462361b0206020 +b02661b02061b004262348482d2c45234660b0406120b06660b004262348482d2c4523462361 +b0406020b02661b04061b004262348482d2c0110203c003c2d2c20452320b0cd442320b8015a +51582320b08d44235920b0ed51582320b04d44235920b0042651582320b00d44235921212d2c +20204518684420b001602045b04676688a4560442d2c01b10b0a432343650a2d2c00b10a0b43 +23430b2d2c00b0282370b101283e01b0282370b10228453ab10200080d2d2c2045b003254561 +64b050515845441b2121592d2c2045b0004360442d2c01b00643b00743650a2d2c2069b04061 +b0008b20b12cc08a8cb8100062602b0c642364615c58b00361592d2c8a03458a8a87b0112bb0 +292344b0297ae4182d2c4565b02c234445b02b23442d2c4b525845441b2121592d2c01b00525 +1023208af500b0016023edec2d2c01b005251023208af500b0016123edec2d2c01b0062510f5 +00edec2d2c20b001600110203c003c2d2c20b001610110203c003c2d2c00b00743b006430b2d +2c21210c6423648bb84000622d2c21b08051580c6423648bb82000621bb200402f2b59b00260 +2d2c21b0c051580c6423648bb81555621bb200802f2b59b002602d2c0c6423648bb840006260 +23212d2c4523456023456023456023766818b08062202d2cb00426b00426b00425b004254523 +4520b003266062636820b0032661658a2344442d2c2045b0005458b040442045b04061441b21 +21592d2c45b1302f4523456160b0016069442d2c4b5158b02f2370b01423421b2121592d2c4b +515820b0032545695358441b2121591b2121592d2c45b01443b0006063b0016069442d2cb02f +45442d2c452320458a60442d2c45234560442d2c4b235158b90033ffe0b134201bb333003400 +5944442d2cb0164358b00326458a586466b01f601b64b020606620581b21b04059b001615923 +586559b02923442310b029e01b2121212121592d2cb0164358b004254564b020606620581b21 +b04059b0016123586559b0292344b00425b00725082058021b0359b0052510b004252046b004 +2523423cb0072510b006252046b00425b0016023423c2058011b0059b0052510b00425b029e0 +b0072510b00625b029e0b00425b00725082058021b0359b00425b003254348b00625b00325b0 +016043481b2159212121212121212d2cb0164358b004254564b020606620581b21b04059b001 +6123581b6559b0292344b00525b00825082058021b0359b0042510b005252046b0042523423c +b00425b0072508b0072510b006252046b00425b0016023423c2058011b0059b0042510b00525 +b029e0b02920456544b0072510b00625b029e0b00525b00825082058021b0359b00525b00325 +4348b00425b0072508b00625b00325b0016043481b2159212121212121212d2c02b004252020 +46b004252342b0052508b003254548212121212d2c02b0032520b0042508b002254348212121 +2d2c452320451820b00050205823652359236820b040505821b04059235865598a60442d2c4b +53234b515a5820458a60441b2121592d2c208a08234b538a4b515a5823381b2121592d2c0020 +8a49b0005158b04023208a3812341b2121592d2c462346608a8a462320468a608a61b8ff8062 +232010238ab14b4b8a70456020b0005058b00161b8ffba8b1bb0468c59b0106068013a2d2c20 +8a2349648a2353583c1b21592d2c4b505845441b2121592d2cb0024354584b53234b515a5838 +1b2121591b21212121592d2cb1020042b123018851b1400188535a58b910000020885458b202 +010243604259b12401885158b920000040885458b2020202436042b12401885458b202200243 +6042004b014b5258b2020802436042591bb940000080885458b202040243604259b940000080 +63b80100885458b202080243604259b94000010063b80200885458b202100243604259b94000 +020063b80400885458b202400243604259595959592d00000001000000050000f72805665f0f +3cf5001b080000000000ad61b71900000000c142e956ff50fde708a8078b0000000a00010000 +00000000000100000783fe39000008e9ff50ff7808a800010000000000000000000000000000 +00170400008005690050031c0096045d0041045f0087026900000432007a04b3000d05ad0014 +03d9005002f0009f03f60041044b004104870096025c0096045f007d04340050047500870248 +0050032c004f04a800a00475004b040400500000002800f40166029e03400340036c041a0532 +06520672072807f0090009780a160b380c0e0c9c0d240dd60e920f98000100000017004d0007 +004b000500020010002f0055000002f001ff00030001400a54bfa50140a5111546a4b8010cb2 +321fa1b8011540b21f1f6fc731216ec731216dc731216cc731216bc731216ac7312169c73121 +68c7312167c7312166c7312165c7312164c7312163c7312162c7312161c7312160c731215fc7 +31215ec731215dc731215cc731215bc731215ac7312159c7312158c7312157c7312156c73121 +55c7312154c7312153c7312152c7312151c7312150c731214fc731214ec731214dc731214cc7 +31214bc731214ac7312149c7312148c7312147c7312146c7312145c7312144c73121b80137b2 +6f0821b80136b26e0821b80135b26d0821b80134b26c0821b80133b26b0821b80132b26a0821 +b80131b2690821b80130b2680821b8012fb2670821b8012eb2660821b8012db2650821b8012c +b2640821b8012bb2630821b8012ab2620821b80129b2610821b80128b2600821b80127b25f08 +21b80126b25e0821b80125b25d0821b80124b25c0821b80123b25b0821b80122b25a0821b801 +21b2590821b80120b2580821b8011fb2570821b8011eb2560821b8011db2550821b8011cb254 +0821b8011bb2530821b8011ab2520821b80119b2510821b80118b2500821b80117b24f0821b8 +0116b24e0821b80115b24d0821b80114b24c0821b80113b24b0821b80112b24a0821b80111b2 +490821b80110b2480821b8010fb2470821b8010eb2460821b8010db2450821b8010c40ff4408 +216957311f5857311f5657311f5152311f4644311f4544311f4f4e311f4d4e311f2097309740 +975097043088010f8c018f849f84af84bf84cf84058f689f68af680360697069028f5b018f5a +017057018f509f50af50bf50cf50058f519f51af51038f529f52af52033f7c4f7c02507b607b +707b03704e01708f01308f608f708f03008e01008e01408e708e02008e308e408e508e608e70 +8e06107040700260740160730170440100282800000012110840370f3fce16010fa21fa20218 +c7312114c731210ec731210dc731210cc731210bc731210ac7312109c7312108c7312107c731 +2106c7312105c7312104c7312103c7312102c7312101c73121407c00c73121e0180821dc1408 +21d60e0821d50d0821d40c0821d30b0821d20a0821d1090821d0080821cf070821ce060821cd +050821cc040821cb030821ca020821c9010821c8000821230e45220c45210a452008451f0645 +1e04451d02451c00451a08180816081408120810080e080c080a08080806080408020800084b +b807ff524bb008505b58b101018e59b0124b004b5442b9000101ff858d2b2b2b2b2b2b2b2b2b +2b2b2b2b2b2b2b2b2b2b2b2b2b2b2b2b2b2b2b2b2b2b2b2b2b2b2b2b2b2b2b2b2b2b2b2b2b2b +2b2b2b2b2b2b2b2b2b7342011d4bb01b5358b0961d594bb0325358b0001db1160042594b20b0 +325323b096515a58b0301d592b0145695342014b5058b108004259435c58b108004259161070 +3eb13737456920b0005458b040605944b1300070b33200300019701870737373737373747473 +737373737373737373737373737373732b2b2b2b2b2b2b2b2b2b2b2b2b2b2b2b2b2b2b2b2b2b +2b2b2b2b2b2b2b2b2b2b2b2b2b2b2b2b2b2b2b2b2b2b2b2b2b2b2b2b2b2b2b2b2b2b2b2b2b2b +2b2b2b2b2b2b2b2b2b2b2b2b2b2b2b2b2b2b2b2b2b2b2b2b2b2b2b2b2b2b2b2b2b2b2b2b2b2b +2b742b00000000> +] def +FontName currentdict end definefont pop +%%Page: 1 1 +%%BeginPageSetup +%%PageBoundingBox: 0 0 366 156 +%%EndPageSetup +q +0.0823529 0.580392 0.0823529 rg +BT +8 0 0 8 222.394666 145.083551 Tm +/f-0-0 1 Tf +[<010203>1<0304>]TJ +ET +0 g +BT +8 0 0 8 244.004041 145.083551 Tm +/f-0-0 1 Tf +<0506050708090a0b0c0203>Tj +ET +0.0117647 0.0117647 0.721569 rg +BT +8 0 0 8 298.536267 145.005426 Tm +/f-0-0 1 Tf +<0d0e0f03>Tj +ET +0 g +BT +8 0 0 8 314.161267 145.005426 Tm +/f-0-0 1 Tf +<0506051011110e120b1013120c04>Tj +ET +0.588235 0.0392157 0.0392157 rg +BT +8 0 0 8 162.495227 145.005426 Tm +/f-0-0 1 Tf +<140315>Tj +ET +0 g +BT +8 0 0 8 175.963977 145.005426 Tm +/f-0-0 1 Tf +<050605110e0f160a1204>Tj +ET +0.8 w +0 J +0 j +[ 0.4 0.4] 0 d +4 M q 1 0 0 -1 0 155.935211 cm +106.051 133.129 m 85.43 122.164 70.191 113.375 70.191 113.375 c S Q +72.852 38.791 m 69.273 43.08 l 74.777 42.131 l 73.484 41.564 72.711 +40.213 72.852 38.791 c h +72.852 38.791 m f* +Q q +q 0 0 367 156 rectclip +% Fallback Image: x=0, y=0, w=365, h=155 res=300dpi size=2955450 +[ 0.24 0 0 0.24 0 0.895211 ] concat +/DeviceRGB setcolorspace +8 dict dup begin + /ImageType 1 def + /Width 1525 def + /Height 646 def + /BitsPerComponent 8 def + /Decode [ 0 1 0 1 0 1 ] def + /DataSource currentfile /ASCII85Decode filter /LZWDecode filter def + /ImageMatrix [ 1 0 0 -1 0 646 ] def +end +image +J3P/PW$E,P#D#)]Yda6_*=IZk@Smti:+[9:6_dMgggVWNO%&)l3,F"ku50(ntAUMcm)Oo767PIW6f'4L\5 + \kA?XR`oI6ngb@$B1Xu2,k(=?iT>clVY*TH%*\_C`i]H,l'I_aEM\,-pfWJ.h;Yh9F33aZ( + 0aK`4DVIpEFWTEaCRq?tVS%dgY=GpbJ,H]O/Zl3]AP@]X%lggJ"c+[?Ad(f6041Y3,bl8*7kdSpsb88$VLUH@&DRa+9rLG^FoND + ^X2u4q@0,r4R%'`mh`+CX3-Y/Xua.5d1A%#rg$9-NZ;D;c(\#%]h;k6Ed`o#K06XUA708PM + G:_:Ffu[_f+m=#JX*b1AAfWRnX)R%nq*]_D+/;'#*l]AK8dRj:r0DD'</)Cuj8$UR*aGhHQ:WH5:"[l7o(VX,8eMp?*>#:mN.qtEUlFd_WYn4=0H,Zf/(A1]qs%_DgQtSd + rO.QKg9Z!7glQlR\+k)oNfIXcLtO.;;1iK[iMO@*Ij(9pn#6MAp?Km\^u.5-`PRA*VL)_o3 + DmSNrCnS"dFBUs0L'u*S7sa?&NlR:(;K_=8q==S#Loj[HfrQmdhD3[sZIF#JesToA!9NI]q + `/_$9E*hFn`'mVW'A`_uo19C-Om*W8s* + aU;=j`em/1[C2Ih5"I0%7EPKS.<,mE\^69.6`&'H8Lf5AjeHY)^(tFX-(iOk=HO`WMP0`Pp^rV`q0sgSS;B53(.-27%ZViTk`HM??6_I!2!"#'R7S`58U4(BAq[=S;d+*6fi^&lN7= + .L12T[pf/=sB,b/Qa782qCPG[..T/$mpapIG\,h1tD1M0_7oO0m0]Z6RB*`u)rP-.CB8jEskH]BYl5;j`XV.=KqMEWM0g)ERs.r[-Qr4hg6k4V*85mA[ + OHKs:)e+([eIJ + *Va]2/00mY-qBbh-93!E@3Wd\lW)&?0fITY>qa4=1\?;lihsE\9M0#f"_f4 + /WNOg8"_b#[g;ASf>"NW]Zra.aJ:m002jMFREmKLG:8s,WDEZm + i(QS&lHae9=7Hq@LT(QD_`HuIHn%KU`qHH&7I;d+#[9)5`>q>#dDJc#](_6Z)bR&jhD?don + )ZSa-M1DgR&\T#3$"7&9KeTpG_73\YiLE&UDQY)"=%<[.4)'IhQ70](Y1qr?f+;[4&B1$_) + Im#hNUb"Ka&qdOA))KnnchD$=Uu]e>`Fm:7S1^)0.(5bSWiW!;9E$;.V2keQ1Dptb?8a9AZ + -o68+p64=cY=M>g8].7VU+MY;U"Jh4+"jER%_53bM^bSb'jHcWT^#BAEHXoEGULOjUS5Pi% + A*%Z/S:01KX2*M`7]Oj[E/8nhQ_V=_cqdopZbC#(qMo`h,6`61J\>^gIA^fIF_ + i44Y=n=R/+eX`_Xjf37';lOg9J`?!>IUS)^Ec&JlL5/#WQb]=1iMfa,U`S!=KA8PV=XEGHE + \g'mAM1)A2pBJ_TTh$V<@>GpkY2A&>>@)2dlZKZR;Vc\TG&*XuY\o3KhL"^;K>"%e2Ko#TS + .BH']t;(i7^:f3RriV@#J51LnD'NqJT#sjYrJWZffT2sD&tLNp!3fQ)foq;Y"c_,?.7WbIs + LJM-+pcQ+6)&I@n45^+I\+s*qZj@6Q(8Vs4.eYP*G&h>@5-nbunAqL;d$eVE1#O# + _gCI4r\Amdg6nJFmd\p@#l/O2guL$LJ@i\aQ!gE"i=KTXmqt!\\HfbF\SB/H?=b\aP.P%p& + bsQN8b:ordHMmhl6=W<-k1!jG;c&2:YV2$NFV"07gln2CS)p@#1_n1[iD0H.K`*sYTV"cK& + Xd!l6/aL]`2#r$,d0F%EYM$G_&\I_=6!J1d=hYtm4$a@;PnA,Me`=-_-%'[tbn'_4F$IH\F + s/jB2%TqVkB"@=$kE,&^:3*n*G2s50fe,\'mR[m@;$h,>iNVb.:0dWJ-P5]a%VqIBYko#lr + 7T?qg/0-R;#\"f!tt#t"tQ#$EB)lr'*=:4&i!)mbEihR"P`G:\T%9XD>OtsQP4@4i))VI&O + @28D\R.p'X;'!;,Fe8<>7/j&ro$2/l!+R=p;)!$S]%!&YU*tV&F?Q)R6C_nZa#f[2Wn6%8b + XA932E2,k=gC*3ma.n^/@-QldL2*\j,l;:Q^BjW8F+*jP)RnaR\UocJ!@ctbW\n+dqWhX(l + 6+-I'Une!#tN?+/:n?JN-;B[5>,pI@Y,-idEnhD@?QQ+1D+=gG3;@=^I73lnF,cm%MOl%&I + 9dOg_-*gf&nmNk#AL;B2,E"W.b>TYuaX30r-aJ.Jl]3>)*?GiE.'eg\nrY@VPppaA.BF%,d + +CXgg^6g.,Vko?o!']#%NhDN)hD0-ZFqe%^)]M2)=k0do$K$EeLbgp/[F1R66+L\DU@`\[1 + [TPEo/N*oe1@]0=(O0o)UO$"Yb!(0WTaW1&iK(kg^;1+E#XXdg\&g,r0Nj1:&Pfo.`$W2)B + ;5dSg_W1''+MV^eur1UBe4o2.A$8:o-,51fGT7e)1a7Ti@54dBFB>?&qDJoTIW)h\N8\"3e<\S + JGD>aL`J;(\F\>n1Pn7;ppM>'5-p?\!MM_6H5e[8\+B//%c.e]PQ1]Q5dUS.<"RSgiAqYj6 + *0rAOhicYEA@',]egHi!FuWR2*c6o5qQ-FPQs/]Pe&[45]bsK1]eNd'+'(;QjUNuL + ^,WCh`U(85LeN1TJI5=S?b5P,=Wi0ut$bS@t$("9uno=[m4^J6WM:34<7@Ak2TWA'Q9)"WS + O$]dXgM,10^8!A9o979!t2+WsN[kp`GeKHl8j[nd6&YU*^odh'?"or(O;ft0#Ps&)(5uX%( + (1Ceq6,FTbm^DdW;rM^oMk`t(CJ<7*9f)@f/B&C+5u-PGf$cG_OHZWB"/5]h9>'Lr%$A + @V;j=gNDgoq9V'QF1k4^6P_,26P5IM-8;[=Rid^oJ'RnJQjZU>BRJ8[D]J<_+/T(__p%;!7 + =g[,6j1W9;-+BPf2&$aNq6>30_`.!S/=.f0!$o@'o6-eEo@3aYGaP5c]rQZ\:j>K2G9k30X + KQocIH1Pu&4V\WpB/og`$56"Ete;X8%-Fum1!p9f&e2q@oT2Hr,K?WWBg1_UT5ZYq[`n@Wi + "@oN\:!Dci3O$m$'\e]]s[3j1BA>8]C2?UZ[]ML> + YdN&h^37\21!a0def/$s'hjfu/N[e8lXhquAoXYT2?uS"XJ)f + &qp(J;3h.^TuU5aED5;u^P^JTeKgc4t[ab>]H)F;I6C';7L4TfO,Y;AC_*EH?b+pDUCQ'gM + @+EqY2HQAKr(NEIc-H?8[C1^@g?heQ;*](a@p=.NpP$[NurHblD%Zhk\CcH#\.AlmSblUQB + Ti#=PYH]08"G@MQ"i3b3L*`ZJ + p6W$%'auVKo"8rM%&Qkp2ImU#BFsTLlS<`25uJV=_JLF5&B2*R'aT;Yg:t"`0`nPY]hL$N;9=#.4O><)@$[^?Q)=AH + 96qi2&(Lb!9Z!K\>p=q*aH)Rt?@2*$heLM43>NNGBhd+:1cUOW)5\("i,FVSJpcV[fC[b!r + 2<0]uG4[F6;P`%muq&_QK)RYp25.>;kQ)d]Hi;#mZ)+YH+ + Cm_>l'U+nd7^[NHRp!:gMe.hbI()+n'3UAZ3KoET]q'Ep=fYIeH,3"WK + 0ECKkbbm=Y)nO`_O2FDEis2RV5-7*B:\(W/eT.AcmF]GW;a\Ns6]=0;> + RQaaAe\ocFX5F"&L_HL`R=^>NZ&Sg$%Zk^hq==K*[l]dhM3;X%)qTEX,L:,bTVj1bllVUoV + %p\uFHMV!SZ\*[q2d;b5Xa0r;4#"'H,A?s$[/&6M.nr2$CJm%=ZT?&k)aQmH'=N$,Chp5Xq + 7=.A=(g8k[+,,b)Eh6XGGu>'\(QU&4*ar?9pt>B<\(VRTi]SJ + l^KgR]<&UV']iZe!"%RtkKXMls0HWN0UEb^7)6/"s$j6Q7*m[.5-"j:6`k%ZBLY$Vc][#S* + *['LA`595-FQiYMX0(DnfX2@hmuafC>N_H\P,fJ.;cZ,;K6:0[k-4?^Qo09@NiN-pr`NScZrAE3EF!V\Y+#mMR6)T>]-oM3B0)#+8=5L4EYsE=3c#+$ + ,#T#\k0PM6&'/T@l2MQgOjOqq6@S\d(>L_Y2@PKs)S"3ZMO."=fZsP1pq`"dPp0m<#*`Dcd + ')/cp@]YMbVZo):DeXX?AGelTqrTfX?2;5eRcBb<^1I)%%rjY)BU\riW*GPnoDRA5BdJT?_SW?1pPL?"sF$6)HSY-:u)1nnfeQl> + (I9hZohFVPJQTY?,Q@JmBl1A>Y_`ag$KjF:>Xr*94L_%05hc:mFDq4hVuc6)saP'Ed5 + 4=D-(d:Y?F":lWp90X&\,)1<"RQB`1Z61YJY;PsE#/^!lG_1O6';e3/F\EfW=;uER;`QNPm,P&CeQ]C<;-o$be*lJq[J9`\Y5ac_T:,<" + Qg33(aDTo2H2EE(o9MP_`d`n1^SAEQ\%A2X]?>9;5HglRPGJ/RK"eST*T`_.-GS,Hs$@$qX + t"Qt.s$(P>3<&B@J)4XG\),n + Rq0Y"%Z>7?:u.^*N3.d9lF/m"V,JTuQ3%#`M + Ll>,bLPZ>.'fa&&!F,uVi26=P>1^nMTJe:*0m]#geNS(.k$1mb^k'mnDA?H9rSD"g%k(7Qg + $aDo`]>^F_1-J!$t.0]PY=3aBV%NH5O9nm0;,o"M_r>qS4YM&O0W!U(b_^eD!P,$#jZqh[=0"Ns<[7>hOa%,b@JttoAZP&2+XF3AO7ZO3u + 9#^5H4[dfIm5[qmFeVJ/J7Z]<>h9;i7XUXOM<%-gVYtXC$0$6!T\.f6FN)pufl5p((36'NQ + =j3sB%qKgTk#%L!TdM?Cf4sgDLI6f\q2*!C:Y].]eoq&GC?qt;QlM!>:pk`Uq+5-p#X^V@$TkFP-qWkGhRA:,C2Za\uON8 + 7Yu,&*khVj/]2h3E`upFaC^sJ/]49P:0<*dPh,hhDKr>)+EC_`fsg/r%a`2dl6M%3T4cis? + PhPMH/5%Y-Um!=IOC'6GlC$&%5DIG,"TMRJUjjAAPlG:HLS:!#!pB:WU"mq":t"tISYZOa1 + %B%cLiU?LW-lt5@5OAguFI0iI+5>rB)l#LHUDYJ/njPmi-pFAe'BZ9?%P'(eL8VV6mg"e+i + H.M;^TFfHs+]>RaK54Y@Qn[@-)jm![*%]$ra.cVG"&b+hflSUj/c!V7'f[ + :6nsBP@EZ$dq31Y,j+Hh,3]%>b!Rrn"fEtpu7e424U.6*oR/p,@KW9me7niP;IJkHEr4Qj! + ,C(n0m2.r+:&JY)5ZW///Z2[9!KbC)Co_,3aieE0nD[l::P>Z^(8nh0gI"[`2%\_DG`X$Gk + a<:^%VkSp;oe.=R6BF@;0SZP-*^8cKnC')Hp;ln^VNeNSTu9-N*%@SU6nup.RQX)Q'`OKiR + "iV8''RFXEKD@04P-V]Y(mRt$PCJ5_D+nid((B=7BH7aNFP58em_ + N\5rNL]ba65=sG#$U<-,e9YMMZRKMF$UNdWOWuSm/["ZPofT9:*Z%seKBHl$s=\/1%ISLp0Z]0t>&Bg3!O&W6gL/ + 0%)L&6YhZ/EdqO`Y.cLOt>j9Zah_NFf-!=GKVg`.I]cA5%WAo*02&B7B^#.*a9`IUp[$hG% + T5l(>9l#frmH/4uqkTem7#`&SJXAJ^K"b.^-g3=+U*da5Vr?>1gunnY&t5tIt%44K^c;egO + Mp)b'NeQ!Z46 + &CjQgc%L\"er6O^,;-XmqK.#CLr](NF-EmV:d;g>5sZ!.1*;e/F(Acs$)9@Vd<^a@_/\CFo + 3Pn+'fGW.)j^)_?ni.mZQ]234uU@[Y-=C=^Wlp

]JgoI^08j5l/F`JT + !TSSDbfRIuCXB3_`%aXQjOY<&q&^-tHXF#!-^2BV?Q\>ihb`!eZec735eXiQPPBJcXSR>iM + qT8l.N\mi@%OLc1[^nW1kqdj56LV.fA$1XK2m?l/Q+Ht[43*VkTLUp;,A_>5K"T0TN[Frp& + XFP2K.fAIP]Z*VmGn7;o^XU?hK4.C$BVDBD^o(\/!j?lJ-E7[W/SA5"s^?SpPQ6_XH9K2nlhP/:IH7pL4"$BZfPnW:$=G&VaAGl,"0TW0:.P-=\$7Hb!:mr/%`%)8PO&Lpljj@QO$JA[ + ^o3/^^o0g]M%!=AMQE)GLn__+;&kgd6aJ12!.mN/,7If2]IQ7`b_&-UCW:Hu7]Y=c>a1BS/ + EksW'CY(,;`]L/7(uELGAAN8[. + a+9SCK+oZUgPbf$-qe)`YYVb/X87^/6WMiNb;oJ% + Vbp:@KK[!4"c:Se+^&6's9ZXQX<(,539lR)?m,?2OJkgiSc,,^c1\a/PX\R+-:>'YXn:El% + n>YGTa,G\YL9;K?$n0#ROe;u3/f`+MbN + OPVPTC>B1Ig/5cg:DD/G`*ua$'%7a;kd&m&Z)lE0c+H8p]sC`?N1H?3n0//ut=:>ong3_6i + gm:\;%XN8i*WJ'DM;;Rs1>bpbi(d8,Gr1aOZt<8Gaeo>F7+-.6);@iW]T&Bmi!O]*T"bi)J + cafSd0NZ>J9,YClB5L*B5;lh*;r;*^'eVIKm;oKa*\JCG*_F`fb`e?m=gha1k'i]<*4sBkQ + D+H^Y)cWWi:6c`R]g=>fpr=[M<7IWlbs&Ne1JE=NeNFpO'gmp[4]IR^::'H8`@'47?rdQDc + Y.obW)!QfooJJ0cRia)4ElEspR_`[eg1>q/;-rm)q)Z7]/r-P=I-T>r)0(\;[gFj'k%R"ag + Z&4NuXB\V$7?6G)ne2O%jnVIqsSULE\M^5+PZ + lWc_F/.oso^LkR]@Z.p3K2bZ%u535GRMZORK^&O&Rua=#G"t$anF55ZZDi + 9p;V]Ccjh^SQTN$c]htp/W#X=U;<<+X`F]d.Vi6Fg!c4mgDuP_4dT5#[FDiKWBIW@A7sW?q + 9n'Lg@_p$rE^$lFBGBY>[>HLpca)h=9.ro.K$_!ZV)5HFgY)Cc)&jN_$QU2%D?f$A#&n3_QtHY3 + C(mR4$>?l-1+G##k)&c0i&.>fj+P\%92R4]?KLJY?4i2s'%Di>>HLra!4h&JT\^YuaA*]^" + s$VW=pbHVM;-b4eNg7r`Xn@m0*q1l@p"e%*>2j5BOfi+M@M8<28bKG`8: + J^A6c6AeF4#($jtJW&1m>^D9*6Gn\:?'-ImM"4p$N)Fogf0$7bX/emQ9I,mu%iuS + -9&Z:$N29e`BN?^`Af7IPfpNctBD1B@XWJ5kr0=0b2A4"A5s)cNGSP"Nfs]CPTt:m85>>N#aX + `^92/6736@$<(kc!'KB(uL/fp@8p6c=HdqW9UlBR\[@'c+`VWNS)idQ65Sr]$%OGJJ9>Ac= + `\7=CP^WCZ5 + laET\XqXtrSqH1H$jOL_>Y+0o^hKB;&dC^aN^W$le87kFgsolb3B3h>Yph7D4uQ]tMuP$GO:]K^''leaGKhhqmFM[MQFZa)2BQ#>!8,L9ZU_O5:>*s-)@-uJaMmIl+i[2.o5(Lf:NnAc(%ena"E:YOt + BE7Sa8#eBHes7#Gh$8.-5AN#r>2qf+0BYKFe[Z0M86.5QG$Z%%n"]mJL=:.uinTM2Iei9Is + q$6o<1AosJR-ScY;fYp;.&AH$3>(i/=ZZ^E@cfM\NoNhu-_HGJo00]geJ(tS:htgIl\P:U& + Jt!bV&R4,F($-Eh\AlNF`R!aEsFF>O!]^=1<%hlnCG>_!o]E!JM).+'o+nf]N+SpT1.X'$G + Sn6"T3?'HO2VfT0F`b7acffe*t+PF]suG@"[OM"_>]<.H0Y*B_B,cnAjX!mG229%?sgm.o3 + =NF*iehLF.,Q[jP0n$Y[B>q9a9_E"]p*+]+?r.N!@hTQ]gWGElOF#_mL>P?];3fMf99^l-`k;\9"e-$[83a(Go5/.,E8_5j[, + (k9M5_Mp>0h)3Rio?_6Pf^.OLpnqih-'&I5T1WO*\h=7&e0p4)N5G'k#AC5P:35Z-I&!E*G + je#ha'Vu:T3q9TFo3?AUgJ>dBkPG><<[kl(6N*<>5A@[n%b4Wf)Y*uk&FLonZ=]C/dLq'N+ + ge&'r]Rh3oQ3ejC<[/E7WE[9,*7].LM=kF>7fl&>aJrcjMh4BLbOr+GY:=&8W]cl/$k"GI! + XQ&:6ksHW(W(W5X,]^&pmAH1mC,caAW2WJNp"M@[d]B?@_l[gG@0BOA:UcajB0b5B!_Lc;L + -`(8Mc[W?VSO(Zo=[)mXpU[PD/I)o$0fXC_A?G+m'F)Qqm0>r2sU\dj-HnVc$#`AtdM2@9k + kEr2rC>+*Vc]"LIqo?[(O0Lh"K`4M+Ef],$+6nO2iK)ApBc8;,NR'Jb#'p!#'(r)4I + .n9Ur;$daj+_d9EVJAea6A12UO,=^ZC!"PV78JQhH,qh<&OF1*Tg9&Q^G.s\hbYF#.[#5a% + g@*n7n4O4C_\j8%6HsR1*KZRPb9iVnR+-Xu]Ee.K0Am^b2kqTbt7]'s/SCfGoAaM9^2PhKC + 27#^*@BurMGBSuO!i2aE=Z3o678mtRFRsXFSkXj+l'^;5r-jE5G9FqjFGRkaB.A`$Yq[k,Th\N^bT26/\'2$6#S"-n6._)S2s8Gb< + $uoRO*c8UOXkWU_fXlR$VQG+Qh^KP'!e0q;:@W3LG3(nECOW34/IS=5s!&aBZ?[V:,c-;2J + /_(I!&4RhOQW`4_Q/b=lqIo&Z&#st8K4V:(YZk<5'(8?ndQ%;@8:(tTG]eN40<8BQ0e("=^ + :t/Jc8Q+'g4],2/,@-cW_X;XOiUoI$(;btf + LXPdBA)u-4I@21;:TA)p=5pTgX_(0:V0[JS0lJEH[b%hDJdJ%:J2D[Y/TTEEBG*0/G;8%o` + Y>_?`C1-E8XA,\9FEoiFji"XSXAu$\f85@4'5T<*UC(`YXT;=E19^RYeI)N&0,8#EE<9L+' + @h3#tt$A]`5&=Y96?_(W.b&#JbugTPC:=nAt:>614q-?1rqY&!p#[S;ru*jHGmR[qKIU)W-cY[$FR + !9gE;)I%(U;Ll$MQ]l6]UD(p>p+AICk&1eecP;:L:G8 + lFEiC"i::^N&''?/KqapYGk#i:p:%AQi=2[;k1$?=0,_TU'ob>7,tV1[,7<.V=AM[cb/YqT + 0nVR@r^ZXmXr:=3KXVIWEVU.GC8+l))`J(7B4^1nJOUL_okE-T"3&o,S4*%ZX&V!4)0jBPs + f1F@q;))U>g$q_tO,Y6.QV50>Qfo(Yd8A643aEgdIWqJ%1fqO\/R[t2j#!8dBR(2^+D,)!m + L$Ip4`YR]nO'sq3m?j<7pr(b1&d3'ieIk?[["+6c?S$$P^_A]''o4C./1h&#_ka#.>l!'7/ + r5r\dt$[Sd;OmmOfFSsnD>J>09:e+73.S3!E8VP3R>D:"P@Q9$-ZD5VQ&&n7ohhZgoXFG&O + nhS,.HBmG*^S5>YCK-0'20-QdYk@9BV2=e[i;Y1EL(#P%sUsM'![/8SSoOMYl1g3Y8uT7`N_m7$\;_;0eT^@`oLHQja?NnotK&7r*Prd + IdcB#Y#I7:f7Iibf.Hs:fH16(S/$YFAT;^iB(Fm7c#9`g_&o!R=^MDHKWsSZ_q9GM@N7gmn + KmtI0HCso_f1Ro0`R_u9WjmJ98rD<29+;+*&W+>;X2Of]63uC==`%iXt>JT2D6._S<]9.Ak + gD#5:C(]pQ&nh>&o`%.:o$WQLa0D^Nf1Zj\3@)1'36J\IRV*l]#AWM;ESH3=][&)k=73ER* + 7`46Kl=T#T1J771XN!;mo@j$[T%%A^>_mMb+jn..7p3AdV(dWua + W%^FT0#?b3Yg)j,UN:o(rR$0sA^JsKH.A'$uJ'^7"=R)FlUCR9`dMh:KCQ0j@oZirY>9>rl + *Cb8G.+$Wd#?:!5>`*ZYd+[4^>&.sYYVprNf6TAGmG5=DoX:,KqJ/iD4g2(Jb<*aKjsPY_G-7%^3T!!g^!!*k6c%OT3o'.o5EU3IKAO2SI.1HI + "aBqpk5=>=bYoj_M_5D<.Hm\2rcckTUV#H37re$hS&9V<1#"ft8GZ[MMtm;=jF4jhjW3fkrK"mm^/;lFT-KisT* + s@;+4p@[)s_t1jn=g,_Z!mUn+g>.qA0+m2,DNpY(HK0]^5+^m;E^<%cIC@&H7`BqiC14:Pq + 7FNr`h%s3G6Y&2ODb2Zo.'"4078&43eNBYA>#]qS[N$<.\S3!56\47DP:_D;6\^B0K>r(o" + '&-3!S\H$-O!3ds=Dr0m-is%0Bl)u5p0Quc$Ain@T#d6"/0*#$lT)C:b!0LD1p.+!L4;60'(aKbb8W'p1 + -_,Z>@rR2V3E'_,'i0io7?[i)H_(.5nRZ)\hKR2;!6(_O:u;0<`'ORNjI*APqYOeEFWYoWA + T)UVCs9fF,u`>e>\ZOu.;dK6b;b1EnJ+*%Ar&_@mTQQZt\(%LB(;<]7OlPf4ZB-rdW-IQf[&p#EuG:/Q"/b2Zrl + N5%&5O^;QRS)e.FOh<&u-pSV^dk1.`r\Y%r3IhPq(e7%l1jH+b_IF].B,g/C + Mir'%8F1f.E0?/^Y:FdY.hME@p/W:nTm'!ce^Tp6Pf(0@KkRm6oWJlS+M10[gOe',**!(GV + *m0p:O]dcVp?%$MlS!Ac?/@H*PEGrfQ7W)t3R`gG';ITeV`L$B3n(8o + '=)nd/*q50bR[bC$OX>;3jP5 + JsdJ8!rBP#=+/G)&)I)'GEc3(I=9)6.?uC$X5]U;)OI\0VQZW"2k1LZ3Bk^68Unp'LP8f7m + rS77+=uBdu?+]$5$6@C2)IJ@*M/?B1??&Ho+\j'QZcDG=RmE8(<#J:+RJdLIdWB/`9c'#,V + keQ?cDl*g8T2'S/kUVb32S9%:%;'XK%,r3/#783Hh+a-g9sfa + M<9$_Qk>%9-:=S`.$meGD]H9cK5Ea\k@,c[O!$PccGUikM'b`9#o21bl;:Qad'dHUV-CH\j + .rsl*lN9i=02Q&[;oaKt6E)cK.9)R*<7OcE'iS+4<^ft7iq/3^'amiIEWHni*VF;od>f;)D + c`-D1Kf\'sh*:OK\>B&iH(,dk + `c;'3YHZ#Be=9dka-ef0+\+>?0Qe(#rV#k?aG>-<4<9FT3nhlk=Na.=_M.!P)T.G=g9j@+5 + Wlee;Im(L`UK@FcLB'eNcja9U9G.=`RO!1.1\qdY0jA&0U)!=r^+pLJf.ACHhF@[U_VqdL= + FA_(4#(1UrWB+Ro\8@2GLTtb5@!!".*B?"CX!XCN]Qq&>'*nH>bp6#W'Q39+8>QtFHiU'+# + Vaf6OC=]S((:.dW[qh29:j%pCPkZ>#@4K,T'hoIqJmCjsVacuH-)DG,DM[\XCK)LG<-Gll( + @uHFpMZApDo98#e;%k*K2$ID:"8-?pChOJ(NGc\ERnQ-<%TgjVfJ(45a7dhoat%W!n:9nF4 + WWu(IN:G7oD8j-$'i.e^lr_14])`.(8SdQXb2?B6KVWG171Iet5rbF]XcF=4_A8(P?s6LNo + /D0Xl+%'+6prcZc^4='(B-(Sc:XVg=]18%4U9Es`b.[qLR.>ut#h(#+&da*a5sI+Q\m%N`K + M;dseUW\O(k[WHLPV=QLK>jD\*OBe0R]9FIPhpt\>+p`Vi$kBI+XK72cG)(,B + ]AY4VXSGfWC*7a,HD/N7Sl('o@.$RM.W0N;2:j(upWYk?D';0_^onJMRqDH]FKjO4aJo)$> + Flm4d0B/K!8f2ns_V`K44AOkCh>)'_QE9/8@XHSYtVpZ!pSI\W7o3B36/Qgp5A8!KE7PhAh + n=Xc\H:GGrZLS>+h*hIgR=I5MrM@'3L?4<\!retS'P5V2TKGFMhdZ/L\\]U):P-Zf:@kKOHU&mJZ"_=7 + X:AlF*OCL\auFrpRdlM^:!K8fia4YnV^d!*-r-a_;U=jrLoZ!U"UT_$Y*D+o3:sQ=;]Y8\I + kPs2kug'UY7niqBqp^)1_n$#F\C:J3B_t+/F%Sgg+ + hW`iE&[Pb)]L+&]:XkL6p>.R0,:TOVcVBJQ3(g\RNbZ.iEXWWp0H@?5gRB=7HXoT'978]Dg + WNQ*hRc:=pEX:(99`Z@\"B79?sZ?8W[5VK]IK'Po??E`H=<[09R9_O7n[77k4fFhZs9YJQ3t`Drj@qGg_0QhomGnmA);kX6WBZ6`AaicW* + a;o3k8ZXm(P_Ps;!42BiuZ)(7"6?0p):W+Gu`+;fM>;`Y?/$:ufYueFc]O"Rm@K7B[<81E\ + Rk@]GF2ZjW)Fl_l[IOI^jRgaNY<_o25ut\WSKe=*CI + $AdD?gP_HO4p3jm"t&]`ViesaM-h)lZ>4f,a9Wh"L@*Ik2CFg/IgYs"$]K$h`[8][E\<4lr + n*,\aRRG+0+6.Fj%FaZTO[VI,l]g``.B>h8N%34lsq:l*\4l + [J^5-IInmmpf(PPd8)kSRsE7_V9QWOc24S@SeNP83`MX].@qX>*;.K;q5#(`"h`V"4Q%i_2 + pQg\cF^X4qn,p7(aiT0dJ-5"[(_g8:-94o&Q[T>`CLa#LR<%('U[T!D@5=qZ:8hBc+a@9r**O1ShsR!olO5+Cg*J%^C&D4\<(D-Q>An5Xq2RX( + s\i_/Y8C/j'?Kmpr,^>@DSj6O.N<*p4$i+IrU0E=8%,hKn"JLIt;?a<)n85pn_!cpfH]k:\NIsq5%*c]1>q.I;PUTV'2$&(_)OOsB`+D-Huib + c343\_M37cTW`oR9(LO\"Pr=Yu^I.@!NeP1ark@540Dk*&rThJkQH:?Rhoo_sD-Thss;=u@ + @`8Yo>LPhL7DTi%dglBPP\?EmY8;`7NNWNM8`roR+ujL+d'lWnsNak?SRtnB(MGGp4#B%d:i0@>rJj9F9Xo`2ktS$q2mM"=_16e[d9!Yh-/5%bJ[k:=ZoY0\4cN@_1[ZV=X0JcU + @cR$i6SDQ0K1R.&`::%=r4ARc_pHDBZo`%0B;\Ag\9X(dlT:F?5O))T!"$FjkSA2j + /#Wd$D?UCu/mF)0PuoH,@ZI#I=&\0/qGmKOHi@(PZA.F<,M][rCkmijcDX6-uOcYr#qS>4[ + =iC['Qp9m>e%'B@bH=-dEt[SE@+a%9'q$+[AKRgGnAG>[K2mX763)0DQD*]0ZT5j:,7*^A70l58VB2I&V=26[*oBbg"DqSD,@7IqRs@97Dm#ct)sG:[!0W>M1:(O[c + Ec!9i>2GCZmJ"[KR7m?ajl@u;P!Lo;^-TX5Mej2qf`ACgYk;so4@L(QB.&jP2F@;Ja4G!K_ + A9Ubf(J<1bp6bD<"^Md9p<6_b.ea%s"[,qEP)E6V4lC7M?kCE&1FF_ + RknSs`Y:U*\+^L@F@.`8mENLud2,c5,BY_LS"a#n+!WQA,H=p*Z?EnE+s@D@NaRo;Q?O*<, + ]/P%L"+!2$I2j#`.l3r4NNZuLuT.XN04='2cfSgd48`SEUZ[mis-\EUg>:.at:Y'],ch:,T + AM8Z:S`;(>I4RBFFes"P.P:Uc`9:0n=L>nBiLlr4&%'DHTK^ec6sO4-Tjp3MKS97i@JLNMI + %S1J(\W)Y?d_mjsMlOg?OuKPZq"IQ4%#QFeBBE/sMo(6dF^2l5m!&!FSb9efF$9H0Ia6ukm + YH0bMV_$cH)Du`Jg:GQC=#GDhWY=$9.mZ/>Q-1M:jcBZ>L*/X9,k"1t#Zdu;CQHbiL: + flu7-1pnp;t:Gn-7pRAm](Q")P%paaU)MHk+,KR>tV-0MlC^TIb#uW=U6lU0X[^9f#%ciR? + ]XG%Z6deOt_^WlccEj,-+@/F^Sub6RJ)p;:nod>DOkMW)_!;5V`LMd4LA$PtFKq8jd6-oq* + V94fD3JAg]/f*'HpLH7id=eW&SGZkg[7.O[p^;(Grt':#)sW[L*oj^#=u+d9IK0[-$:!hMe + ML8^-kg-ZU^bhrb + ;g:VFr3C'(C6tp-qUQ\@^r>Ij48/MIkDKYB6[s<@Pg`78,QmBe+F=2ZO$QrHY-nMqFScF"G + lQ]0uP=N%F+_HcNluJ_4tWMj%55`me-O`"N)HnbWn4/ps?pH3rI-ilk=3SqF%j)Pi(W8J-Z + nl+P7:1A8X6O0bc$lW./:ZpM4Z!8GF.> + G>C/6=`M4bYLZq?LflDC@9Uq]3]2fmA*3pLpA1d<06Qj1e.2Q^Y'kc@;59CYrG;af_ZA9CJ + )"034B^M)>4?M<^EG4)3Wh@2@40ZHr[lEt>"6'JPNS?tR.KkPctC!?,J4D_o0Nh%N%XAF/`@?2Jd5D%kr.c'm"Y,dgX?H + ^:8!"DKQ^"jbdRON+H/_*f:l=]H*c@GGe[PrY2j"QTa'[CA"'_oXaW2D7$0X=#'T!Yg*Vf+ + kbPi0?D9s?Z0O4kGuLjW?G4-816:q;r + S55P7dCe7c]fONkQ#tTi'uW0G4:U/OgGSDdOtRBQTl18;r-.orVr_[X7qG`mtL9nfcbL*o9 + T5+&bl3Yd-^k#KmeEo6)bocQ&Od_7A&X,Ihuf0T;Tbl5O\3#q<5DON^)j72/l#A)INhlp,E + HI3-^0AlfGjEg-Cl/S,#@Dl]%MZDa;b#![I)jZ,`fQq&Gn35pR)#,-rgDbeW_"VsE(VF8%q + Y(bh$uLbom`ETjej\1H(B/=Z8;e/L]bVRB\J5[3mf3YJA)n0C[-M'O31$m,a;*/0UtUX4ZK + dtU1O(pNWW#m:77.rgLrNuj3/5'"_&lc]Va]Y7@RtVN6!H;83AFoP`*K`Ku8".aNT1PjB9SL\3IV[73emflF]6+HH*%BM#<6aClZDkL + ;W@n7\lJDFC)rqS]UMbaK0a21o$bsZc?M\4]p/79W,gFW61@(b+u&[[&_?fXNK%pb2fXSKW + fo*Yfd`c9)&Zam'Fl'[*)FVb@J')FLTGH\BC,IbG;_m[(FN"]Z\gh@1\])@=3*_u1Cge>ERg:jjM/+S4N1\-1@nJ/.bbJLdjH@T[TKen]6<"iE0V(o$Q-?S + B8X$j*g9SgoU!7D96Nd2,eCbrI1HEpAc.#GnF"08ibQpnoM,`$?b9=W"cj4II#rLd9lW?X+ + M25-\b!bO?Z&64m+,r6$:?6H@o^C*/nBVg=cQr)-2"T$]oZpM0cXcaqFSF+7ps53#c_UE`[ + /7C"M9J)I);>&,CB[N"E^(e[`;@tIBRrDh!Jrpe^dQFA'K]"@N)3'2WU"jo1nIOVRQdPPLh + $ZNeCk4?$&N3t,D=ak*=B#mcV;@e:k].1bl^['%+,')UFiI8@b?cr]1&"0]buZDOBAmoZ=(OH_;A8!7jo&N8NiG5,o9)M);'ni;/J\G72`^(I_=+L2[\tW*F7>cAQY_NTB0J8FgmZn_ + @(I_N@e]R-l1RR*/9`lR6@^2]0eD:7,*F3N+8BEBm8$Z:VXT>_c.>^/WU/\J#*lZ7h[M20p + t3:_H_fPaID"rrt\9uB=X;ma(ISOtfK"GKg7T#OT + $?C@4q8TnEFOP^M6hci(K>`gOFY9a6r28u!;/Ip;gL7+n*N",3LgIp@,01/J!:^O?\ZZDPZ + oSG`t2b!\TII8%3ml5aRU>=e6!u>&$oiWu(?;$nt:"k=abM4EVi?:8-bq';E]*p:(!GNO/- + 5X$K1H>3hhoN[QSeC"tY[D$pQNRl\j(ETQ52J)Xn#RjKNC?2%eL0SmiZ0k->W:+i,M0?!QU2qW@+ZCb- + 7*9@r5P+6ZVOW[EGdpZ(i@:?sbEn"Q;5%\b?_-9EoH2XZSHsgo8e + Vtp3o*XV2Cg`t&,=Up!`fL\OMKSdMDTNV&Oc1n6CrXcO(;1=VLME(@lE1le\\H1DG + t4aXD.BeYXi'HT4m]&sO3ZF99.F0>g(WVnD2-k`nSho#dH+EWj^uu(Z'!(g9];T#mU5;GI^ + ;m`k)]5j$5M#t.)KTYknCM^$m*]3f'eke.TS)/>HZt%%c\/']nVZ5mntEn"@h*Lmq6n(m\] + IehWO9lkjPbRDlB7t`K9QA4H##5n0\;,0'2R5"I/kq$YJsEV(Lu@(6QH-5mUbi!6D+me0su + )Dj]KPPhubgc/_G;.djHBA[:J/87IllRd?P$?MlV1rpWbGnW9=+qD+oHC2ojdn`LsM0&W1a + o'hC_E02)tHe4$l[uRp9N8reh9U:Lh?.shJSGB[8JA9T8!!phTADA-pdZug*I*h`rP-42B6#o)Q4"@-K1ORiu=oO + gYcG=V:V!V8nUM.pT+/SGnbHAZo)F)`.-G]I5R:W/"+`0SBh-ADuIj97\Nh/J@RmKF!%5me + jqBZi'q[Yh@Broo`2ch(qQmmZl0@.kCFp*X=0-V`JA^*<*r[urr!23Ka?cbl5r+o6fE,ZK_>X\G@u*nGB`e3a*'_9p0H0[8>Ps/,*B=8^uh_g + EE[=aY]IOG#g.H@mWBp0%LD?CRG*+bDCAW4IktJ%BU,@W"q;8aEoQO"j5(@,Zc2^6FBqL.U + CNmOLdl<,k5rFP]s(jU3]mVuOY,5fdmTus?D0aj&#i8"TKj%ipb4tsp2_7YQ^kDVEDgP6RHs`HhLS4K.aS_CHr27\ + o3mf,E'NS#-o]``"8e5cGJ\<#!6(9[74(\2>\;Ue?h^/Z!1GJ_.l5=Kp,!,hPSIqSKTGPD,PL)7>CmM@#\DpFKBj@>O>%[B$:!.[+<:\Z1N%0n5s5S + 1G8_Arl6+!OP&@id35N'Yoi\BGj2n6&:lZ.83,.1;6=Ui8mf;HF^"b@I[,C^JQ2BMN/;Bft + LN09=7enHk_oKc-2o-1b`n2MWiZJ1:%GAQBZT-I&Q0=HW/Y5)<0IQ)`VKWf4.,B+q7-Su6& + '^Z0%-D9h0c]O#MX]B/bbJ&#H2=?HtH%:VG/E1":M2][t#A9(g8VH5@9b[tp!]]OE$T?q7n + >!44!9rHKUF]uIj[p?2iCj'#GVUo[oghq=?^#o';J:DNFS2]=ANPg30H!D0Zs!Bkl91?NXG + ?5!slr^k/0"$tbh['")?7'l_*H7pqR.Acl[c9f?qP"\TbdQ?(RnIP&s$^hNX.^pkY_FRi_q + J&)!br(;,YW"EPJ:j!U5uNSlJf]$.nY9'5**"LYc9B,pn'pl@QOOeX&>Pt+R&ZM'IbO7],A + VNW]LVD$rh'aa-#_:+35''Kd"O#/<(mr&knQ:ac^J2-d!'\V('QMXJk5&Y!\0.\8oKT.j48 + 1Gj.8Q"*St7"l.Wcc#Z26,::8QjZ1Uuo^)1L.\'n$6P-j>[_q=W2[qW!@PL57PQX[35j2V' + 8#*:,(B^^oRMQ77oKiho^IXS>4KfH6:;>0!'$.jd8>IYc,O&sI\?&\iA;3;>2/QQin\V$=N + toW^?e?,'KjiW"/WF8n(/:'*fp6KGBA+,\V&m11`3h1hDFD.qf+Sk>(>?.t$$:?u-FW+=U,7o/M!lM!#:Oo1#U'jgEb:W'`?PguCI\9bW(9AiujnP + 2!3-I0,`!T-RKHZ__#l#U.U]HTohZWG!&&W8`Xc@Buq\h[N(R#X0lSjkN,JK(%p#n\Xc$;PLLo2*Re[Z$^:^Q + uef/7FCau029pg*D]\copp#,fCfJ.M_)B(`fbeoqI?:u9YHMWngNnkl"]+mE- + kh+jtM\[>_KdlVE9 + H/ndqi$u>\^O3*;DU]Nk&ZO&@FOG5th_Y_qa3(2k2I5(cN:!JjtdMp[P?7TdnQj$[U@;6DfHf\ILjlksuK+YLU]] + 'dY7:P)0jD^S*S*tg:%O@c`E-KgR'8UCneAPM28;@:PN3WWa\mm.M0rHic6asYdP@^>EKQLiiE!2HWoYDRE+i+!!(JD[0BNDRQr=K(9Nd?0k![ + =Z7e(7a3&\5'o!W8;jkdfCX#83Cfp^r$ihu@1nfkHO,8-sW+O[^uJ-9(!Z]KmHVt2F4ba4- + K+H4KE9+d""H9m4_Q-0GDoB-e[SqZk89/6q18>M991W[R3ip'#MI.3P>:0pTY-Um7<)5C/K + N`"Ln8*L1#AS3b-**7%GAs@N`Om8&J'\k$LKe]GV>]uM!9)"3hWI-;k+2[(Q9&Gde0G8P5O + kJDPaNZX`,^"\o(Bd@nYr.>JN[+T0-W(t"6`B?6L_FHq5_'#"I0s,/PiD3]@OS.9ocV7NKa + C.\%4t^^Km7HY2At!hEC;Au/<+c8#46)?;SiO5iCID7)CndUo_[QI471(0]2 + 2rD6-3,Oo@k5^E8&NL&.S-r.T9A,e:@(#F*&\S@A5`oN,p)%5gn:a+cPVf(*J.NU!6!/4nJ + BdLFJ'(_^*u8:j?/EanjZ3m=YD+4gmreqSbC2nlMO?qoh($G/:n2>670e_O].3f:9!$jU@P + =a8tF*fZ?:DbHAZ#>D6])=7X?rji7[o3Q'LN[n:L#XH0clf@sMJDJe4BBPNHtY + .K1(DHkYrh6i!6).-t:S,3;+r827g(7I?4[dc:7q;4q&D\CbU^A%p6i*6e%DA"D5pa6C,;\ + e!<,E]9>qVQm#"+)oF]THrC-bqhtNc1Jpa*@n5jBR_,n7W?Bq'RWQ:fE+UDBB*75$$YsLQ: + a"TKAi;/*C+!O7U)6ch[l4J_qOHEf4i.bL?hMLmrrU#)]pjO@iNN//o0E + iQhk?']tF*EG$`GHqaYAf?*A\EM!<,EP#gju""d5]Z%5[\#=uJFQLpd%hrtAVn/`+WG[Cp= + r'uV&LBbS2NR`K(SlkEM^Ob&'+&(D'MXsag_0NdYkPYXZoNmU,1X6DYqd;NLYEJVK2m2K7^l\E5=U:/moRGI\r%J!K0Eh + Gq#lq1!peeF&2=9+3 + _0NA9EYl66.no,k*DDHJ*YXiX[ih4NQ&46\;k23;Z][1p00SKdOM$U>EJZbOHO4`9K,_@W6 + #7tuJDlj4r\Hq]+9Fs&gn?iXC\I5XT$fu@2B]f\?,6dPui,C)tmA14&fLW6Q%C"e$0]`d`k + mjIc!@ge5mUY`]jSFZHbV$4$KS]W/])M3d&EA*HnIZ@Q)%j+o&b-tcmi("7i:7HT%++p'/- + buZ,4@pV$=Xk@d3B?8;\;ku'_,$80i\s,cD6;f%l#RFA?,ba3qk9[pQ8Sp,`%D)XV/J$O[_%PmOB3Q]X[+n$Mt34W>! + W:W,"iDG_DDfc@?R*V&(k:Di3@MZHR_)m3k+.0L^[]^+Y*8C-l=/BJqg#U$CK+L2S&1)1sQ + (jFB8%$<1^a<$#;DW_S_+gNdn&e?3B3?tgm,P"*&dN8usnJN`"*"ZjU:i>9sUEhRf,B@':1 + 1_eQBdTX.,]U@4%@D`DT-]LN'B?C6&lU.)FX@`X..WKL16j:u7jen/YqdT`0[a4Q/LcfZ.+ + 54J1:8WQ\LXDt(lo[b18,d<+V5($&4D9bM$kEoN#r)W*T;SZ^t]\jQ3hTr0%0&0!E6*^'$ + 'a#X#iNsP(#uS)4;:PnKo`J&WZnaKI'bqlj2'l-X3DX-5)'K+oP6i+[DcQ4).Bro@IFY3031]-BS%ufk2VCWc!(HS%6HH + [@M.!i<^C8>8S#8'n.L6[PfXV&m$:RP>f*]n8#HL.I3e5WW + +2.-Lg7VZKN(S3MYH8<_(bk8!^D'U?KUe.8'$in++5r\rH0mP\W9K*'$GP-H0q1#`+FMj45 + %oX5Z-;&JiJWZ8m<8JVh.^YpjPIJ5T`/f;@*[\uiD$As;KSb-Oj#d"uI\Uh,==&WF8VFTI8 + bWf4<[hUY-"[141s%h#!rZ=S$G^m^C2APYl$15t@S%CsITPc_eTB^!H%u*RM"m*h,`@@39. + +`OOD_a="&/u:)djrXs$2Ck(mHf.-nmtOIRW6Da_n/r9%;c"MaVcEpcXEm6[nG8Mg43@39? + 01D.p.Gju<]?=:Tn*0%q).2#+\CK4Buf!1arN-1#Tf7"L=r_1VN:A6B)!3@0i6-o:YcATa2 + 2806ZJj/cpsr>XXAp>#0.S- + ,Gk\J[Ih*K@UT6T=V"\YYa?WLBRSP3u[oG$,Io>_+f+GZLV)!X)Gpp + b?rq?]l6jXDk<$W5HXdC:3mc36YEGU9ik>SToB'(&`=8?GbaPW9]g(l-Z,VCRK7IRBB]#6PnH&lX%I9ShP?S>``/7q.G*URshbZ+pgST+aTI7l&d7n,74 + :Zb07lAi2WNVR%an`_&0cDl&<_<,l"AglED<9+f8`K#'gnQRLB4#&2q$eU)K`*3i-q#R9ji + ?Jla-kQR3V\*(C<([=S[o@d'`-*HOX#+*'VIH'0`&4=_?$;QV&bQeGkXhRUE&TRm*QC%/$S + pmi;L+pX'tg4tU>NZsA!8(sir[&/2I8H$0,`*%& + hkk?n4*%)UEZ>0)I>)mK!RIgS9f^NNFKMtb_&57EU'bLh![d^7I + E#NB;WLH\8D + ln?0/H+U.L^#BCWg#+JULiQX+PIj",HWlY=F0Q\EOhKQf8/mVg9onjZbg[*A][T2L=i'+g\/EK-4FPL;I@ijY,)V)HC!=m36:(sB0ErJN7!9 + Wfe/^j7:>K4q_;lR:_3+X[d+r\h@HH*K7G#5$f>/3S4`b.^&Y"!QJU'4G[Z^prc'27K5f"s + Th',Aa.AM700?TQgHm0[/MAn+!e"SU]>u/;g?-#)7H`EChS>V>CZuqiUfR;^eeA7.Cj'7"j + KmC3VL9Ut$_FU1t/6`%K.M,0-INH]toiDLe;8jke + Bd_hAPg5 + djFE[e\2:fA/B5@W\3^@oG23&u19.ED[2N7<^9/p\n_7M[#(1?E[U8,;iUsrkp$kWA;=0Di + UQ9('ZO*u(KR)J7UYmUTnf-:>"-G9gCK1A-!5FV*5n3X<+n;-Kn\Qt)s%7,JLV[P4`Be$j) + >_=%;tRq.Z^ccd_8DjV*%Mj_GM^[>+4^=>f`42(U:p-XQkrK/Y+n1onglaYiNN9(dK+&X_'c3?=/Nj:We?#,kP!G(l'P, + I820@+(%!g@@q$&ZOj_:V%%Q-+Mccm)*'b/$XVb9Ufl2Ma(+ZX*0sALQ-3b1 + )4]8r3M"K/oGS_cO%H1sC%WC8:$.u;%XfB?= + Q"A&$uD!0$/G/4?u_2'*U[@A/bb>n:W"m6?&_N$UX@$1CZ]jj?!l>nH;2k43dqUhD\0`DVm + H*4:J;UmSfL)\\W)OfKb9:LE/]S&0i8enbL3K7a\QXJuX^G1uK3+@)42kP(V@8-/j6Oh`^1 + =ieTd=,eCr;b+g/]/Fo56r6*=.E.^F)7,'Xpo7Z-a:335s4&5Cco0#ljjSM/;oE>'?aCCKgGNZY`oijh#G8lY + QoV`:Q2*g;T".)Nmtb%3nHa[fZE`3;91jGi%ZnOX&Cic!&09kID7W#'_G2K-Z%,&rtRWN43 + /$&@/E;TW/A\X!l.:a8emnJidP:Q>SdHA9fLpP@XJY;jCp>Am:U5q1S]d>`hJ!hpH7#Dk.C + 6k'N]X&WJ(Sd[>tRm%!@ZFCE$UhO667qM(Ydl?Xro@,GNV4+B$Irk!A^nrO$[)>b`s/D$80 + /#p4"?9,F#f_Pi7mJEdH]5IMco=]'hk52o3r!*;?`7-\\'jURQM6ES7VY&i=g5dJURrF[XX + B9i_goj^]b!3#7/cd3E!?EN&Oph4T5[po#aLEjFU?>S[o.:RZUahnTBZofl(?aLtrWe)7G^ + _#uj*:PnPN@'"#&+d\]L.<(nRs!`jhVDVki9hb\c9q?#rb&m[tUHs#Q4NZ8-F-#n(T[CJ-U + MsIXe9]qgSRcoDO/gkPP8kG6gDI3f%bAhiip'a(+n(5!J2%fk[$#Ed7<"YU)M0F,ge + 3pdu@TSLHr>aQ8$O.6H7.R7qkR-c*X?BY@]:dKXI.uXSg`sn_?.VH)$@C4URdqWS:LWiXMU + DuIQg2Bf%bsSB39o#*E?Dsk=7B(Cc3!KHs4t:D;WcZa''/KtW#,'JG[=W5b- + 0=;cTU\fUGY*ISM=*jAoUcUE,BmM-,#b^#"qaj:k739E9Jrnt4))4H%`s+ + %:7E.3K!7k+-=`QbA/C=Y:(3IXK>.n)k'fr7I&t`,1dqW_=Be^>J,$Gpn6n3U^NjcsXe69" + ".a;2+f%R@Z1C7_HHtbkWbs_g(aB.5 + ,,VVaGfH5m1a;Bc(E']jl]JUI!!m6q^#gs+>C1]k.G40g[/U!\McaETFoSJMbeqs]LOsB^= + >6"TY$e=1DsJ](^m*soN:A#9/ij0.QV.itr'?-Y(*gbbQP0u.W1crGd"'6Lm)^%.E$!EH?J + (dnfY[\hST%gS=S2Wg66H>pGi^I`FFh])Zt/>ZmN"YSB4TeiPHopAb#qdoja=%n13!4NjqN + +kr3Mc2[URE_P]p#8&3InYg<>to1$8DV4Cp7'S:aCYFfsP)ef0nUi_odd[F614MtiNYuWB*\()%!qB97)m`KA'.>BQJEE\8?@&H`R@PeK-Ro(n.rV;7J"?Yk/L]Q]\5hOE,DDf\.K8)/s)Y>8e5%ABR=c8 + -Kpo&Yob&KO-U*iidIh?[F2_?ZCCg20&Y>i";O37f,0S9L$6r^!g@&\=*%-0OOR5H#ON%3C + jm;8F(r6E]UBK([uW$8-9d`V2I"TGeCD60lmC%E[Wn-qOj\PW9BhSM6h4+HDNn-0fsEe + 2C)61NLQ.*[kqHN4D6[D7[ppOuLe*YQd29gio&\#NY)E87*\c`:l+P]\GCK$rH3j0N^%]9c + mFWk7c\(_C978r%VdHq3g_]GGUhBT>q/?T$0Rk2nDD7_t$%7j?PgC6#7?'Hl,/-HRmdd]o%Q2H+bqrJg=#*\<)W+0ET*!T8k`L3=H2( + Ri[>a'gLIk6>S#9Hmh=?.4_INTHb445n?5+]KZsZ_+R]FF,IA'6(F?GJJ_"s3/`Hs2#sF1# + %TYR6le"P/1[d__ON\T]KAR*4[[p$+:V24!,4LpQbCg2%H.8sqojR-?: + :0=_Fo3jn8,1n@gN8j#UD&/nFAuqK0u_(74_A+4B+aC<>ff=S1DN!Lr9Eq=XdTZ7B@RFK>k + >.8%9KU_($Y1E'utt,)t!lW:2=W4,tRZKe.a/,iE?ldqKeX1.I`+L1lPWpe/WJKE03!72rd + $P7GQ:ECV!h7kA^O3Bk@PAO="@$lO0n0m4!//KeL-4(r.p\F)+kB.it?+J]<(WM9sECIf?X + XLL.o*.nO/abHbN3;eC71,As@4NO"0Kp6>d3,Z6A,UHP_Ju"G?J-H8r&BPnPUb#D67$L8:P + t>5H8SIP/X;_QnGDIepN;Rt4ask!pc&Uch`n9T;@#Z/57AA.f#@sS44JY>P$7BmY+0484#U + )!+D%5!n3UBF#5d;TV>/1t?X+Z\YFKeCHYtH(B9.7YKKKq4No/gV08d&Be'O<>1(sA:tW:X + [4BM^d:o`SAg9Bh!187>0t8k^2=!'J.)(aVjIrAiM;7#2ONGlPWS;*&Kbb0[4/&-5"+Y=A= + F`sf:Jr6S.Hd7kUdb=$M=Bb8CugEm$X"O'=FKT8a2.B/,&T:ep'\4fW7iJ9/n:@*KP;1L\(T$1T#c+$KW6 + c#:_m>*8o:,L63AC""eq+mOW:TXFU,j3.!m`ps-69=PMTQQ>)`.Ct]L`eM#3T\C;Fq?@a8/ + Q+jn-dU%>J4,X:orW+FUU@epHR/H4/Dc#r=Dg8&Q'KVcc[*MfqH.]\&4'i67D]3kYtA,JZB + FA*_bLEn:?4?*=0:J::&LpW(G8O1=@)Q:-B3(O>P@M,uS"q;JddZI4/!Q.8l]d;QVHI]e!( + +/Q1CW;XH,8r@h.Z0iK)J;^jJR>r5D$O$!k-;f+HlI5k/b3E)J0;lr,[]G6?h=n.8!:]V'=62OACin#dkpV`DBPD;,nW7< + @q-L4]GEU5:5J!iuf]e;fh2]ANds/e&2[o)n]jmS4!o^Bn + I\iKH4\H/+u`]bCN@.Z03pn\DogC,hCYt!Bk?Obp-(#:Y"iQ="SJp4`jb"F]Vjl=)E._79J + *-NRb.Tf<'C$]mNo+I2/kkMZmM;m/9\=5VY@(9$dRj4O"nnncd!e#e\fG&11M=76Yj?(c8# + k4`FBJ\Q%Zcf,0Z?3%Mp)O]`]f=Y5h?4d9)DQ!%CY=`'L.I@+/sR9?)L=fn/r]pr6MSQXd? + =m_harLd='TirJ2=tQLQ4eu7UV-7+k$H78AOGqhjJq6q%>%Oa<]rYD^X]jP`>4&LsrNKK8P + h?4&Mff\8R1.>;\iF<08%<(@8Dm&V&=k[L*YMERPFfeXM[DhA"V_e6A<7HU8;AM.=Nq=Lm1 + 39`O%4`.g4dR.D*s+2VqcNHg5pnG]uhs55p))H#rT'0Ct-GK'cUBXajF@T=X+bC:L.,Ia3` + [&C6'e$$I*r9!q"_U-mW*@jjsqQgg$:QD9UiEOPGYD>b/pjY^tTKi@DmlfBA?%r7!S%d56f + ](c*;]RD-:\+Fkt^"-AG;!*Fg&nM2(5[eV\l!k[:M&7+dW8Zh+3H[FTlJ_i9)?9j'J?+hDe?5&cD+T9 + oU1\r_biR&UiSEc4i4.q$7`3>(uhR"oMe$\6n(1MUWP0>sCBP@[jdMe0+t4:eMHQSX[^W!X + 9kMAgBFe,c)Up4#Bp`3&?H2CP*TQd-]cK@"I3Y).M?/@9BCXi+\_&sRPQj!I8Q^+Wt + "=lU.3jEcGg0XtQ(=4'243kQGlRt:lf(D)#,MS^&HZ1k8a5bs>eo3p2*51IZ&DZCdf^;1p?:LFU)75%WocB4 + e:sABk,`];S;[#@EkZ?ulbX4?^b7'>9gnn^a_p='\doKcT#%& + -ge;m_'$Qu]g8<@K3%%=[+$8Dj$ON.^8MWn5pML`!'X:1LDSMoo-#UZ/MStHD+j_;MgC17) + (i94hNdqB5B-k<4W"7/#mP.TfYm;?m*!HR@pd8gi&*;=RAgMrPuEmk23\AFVG.]KTmN(5V%^F>76s%ffu&-6ON_#K;^@gRVfM"_7Is#Z.r3Jela9" + 9q>[gADA4bu$\_!mG-#&TIR4H5+(M'=-_e`4,K;K3c!CgN97509kf!97Ze%9Ro=$.s;[Zh! + $5ob*_b!5^E306)b&MjkW@pJW<'1lN@YFc)VAOMZ$V2_fJ*S+UI4G%c_U&GpNRqK$@dC3I>l#6Ggq$m2ZAMiO532aEh8F,2JkPFllT + G=IW++nUKboT5F"+%ddh&rAe/1ukRi5n$sode4m4"X[IK0GX@QKm5h:GYa(h?\\Ya`!/e8p + kOcPIuJW5Mh+u6/C;<=c.dL#Oa,37JR=9;&B&iIQ$Fa9L=4BV,;f\WQ2&ssH)I,:;YI.8cM + =*(H)YNOMOOA0Rs?ZR"[Ks#O.gkqLA?n$"\5D8+.DspM>49QqQHiBO,egB`-Tb-qA5@k:TJ + g1LAE>%p=/p3k;W,T:3<^lCS+*&Ybha6N=(3/i&HY[/te*KXp?Z^&,<.8fRi@,SKR/G$Zo& + L&&8GnSo^j7$Ps)!#+r?l[trpcMg?u](WHkJ^C#2'SZo)NGInjhEJc^#L_5N#pof%-%=D!> + S]%628'C.qR\a]*Hha4k8(TZ?XVMVFI7TW\^p80&b"\53GE@c3-ek#]Q2=[.IB]N'.GOe+f + 81;gLa]e3n4e=eSpe\a*uF!eG_1?(C3QNkGHi.KYC*,nIGFG\0!#8%!4f`M^]0i697@n@5D + "$Ejo7n/H3[CT"9&H+JjEekGXNkn$\h#Wd.i8`,nl/)@aTG=Ai1Nf7q9sB"GQj6OoQcUGra + ka,*kl5deSR9AM]cLB#^7WU3,mr9rHJ8`9L27Th44-=Ye-b8>\ut'_kBcTgGS,U:"/<*jk1 + 7'5Q+O6))=gYYh+Ca+b:VQ\N5f7> + M6)BJ!@Y\=WVGaJ%e2SYkB#=57X>`@_SW[iHqcp>PL27a`DKfFS..-gHPSjUMU%eA96/+N[jp@bK,:fj@!FMBdjg5.WY3\6W(dm3W@cP + -+W;Kh6KXh/C>oZ$8EhpNKZQeAC2D*b1=721Z+@UGTlQefdo>il:J!W_QHdN7#+EhYX+5as.p@'Z9ksm8*h]ikR1`">&qZoTlLcWVd + O77*SPTNB%83r?b^WKf9I"/*d&QaL(ss\T(GIS/Z;FQGeV-2h7SnGh#Is1rQY>)RSZ%+NAL + jeHg:#hJDVNb@_!sOE6d50c:Li+,h,dh9q*'kFp2-'A19+1m+o4N$6t?X:P_ccI3o-a/)7DqmBW31mVBjm$ + )6X#YEXJ[Z-pE-DPkH8r>+,T!PR:eGlptfAFk[NgHmH2PKbbgs]>NS;hT_lSRWGbHhg@SEGAM#BWI,$RauAS=dJ5pC8*n\FjGO9sAqE/b;j_6O^S^]XfaE#i?m`pu_>ld@)^,b5p1(Cd)! + 4XRGgp3m-2[ThKpIelp*"_7p+@m^t!"[;81AM@eN`5\$jL + .R@f<@j#0b8u#kgL6$$pri-D,de0N_'jJ,fqm.ARq$r8V.C"V-FaeP(B$c.5jP)+97YE2G: + iR>:^oE6^*7I;A#d4e/S=+,&lJ)6`H&#j!6ll!E@..gc?qWCk`Q\QEfUAISNSuX6XRJ$!WlmFi73B1nTHk + FC96(5t.7kq^!q`3c.W@ip,s\DL^66?rfh*^h3j;"qahiB\:$JIeZGe]j&aLBKi)M.cG)a, + f>"rfZh6`6Ob/)Q=D#/"fU4lX2e!A0UDl*,)W5P.#=*p1=C100&f.@P;)khB#oi.O1^ktjc + \Q8"[orIE*PV6V<=X*fVSMsI=+n>E?LD[`Af=(G1iSZX!j3+Q`*k*a0Upi#10>FaDG)]A"H + nU$3(deTAb(l0\Y>,NnFl\cWBZknhrPcX^>q[''G$cB9,8[J[_YFQ`iG2e_Z4.j%\5GAhrigTV-abAh&`Aq#Mjdd9 + q5TUO.l_c]L(ub*Nhde@UUIsFeX%,\.b\J("fO,*r(et*^0nN7PjN\YK:`UN!7?SA.dPT9A + g^A:k9Y!2=<%%`6;COnqh%A0Qm[Xt2Bpg__9$''nR)/o!Y6buTY_oro>EU8fF'6oC;B3)B. + fHQTXG"$m1L'7*>H2\Oe8@?D?s0V6PB&i^DOZ0?@3S(EJSpJF@^\XA*3?1&PDc&H7a1peT&qNq=F^cBh3%qIu>d.!G?()C'//!"TYB_L24")#Q&>eUjZ + J:\9"3X=Au&9E.i5WC?:LojmSA$mk"ajRNX>1h+5Ql9;JHo`-^f2J#)'IA9e;HLtlp)mg=*k#[6Qr. + ^?4P+H;unNgf=PK#@q(l"*sj8IXKj#2(CU.utV;08a]PAq@tQ4:p?L"N!iA&5I3.KL-+X^m + `J$o%=Tm"-A8G7VrVeb43`S$fVg,`qp8*'b-2e+jiIsL2>dB,l]=H!H=SE65ot;,o'lp#_i + tH&I/4\BeoAh#8+heoSA2t6l$#uUWiG'.5?Q-c + l#7`6hB8dZ-edZVm)A0OiAcEMk,93aA!0&DTcYV^],3BH))Xs:)%t=p_JJ(`]nr0_.($U + ?)f%fY?u:kNPl!P!gF'859bA-*g@W0K/m3>0LI+,Xe1KYfcsmnG1DR+i*kf`(9drIih!%,S + G)5$54\J;LIql.<-FUJdWde!%ZKp+7`th5oD0c>Ur][gksJo1#jgI>$FnG+7]IhWuB5:!:K + =M/+NC__&+Z',aPOI+V?XKNmo5(Uc0X=0]P:]!Y#S.kTG_`kjmU$KP_dUAJ`3@(_BU(EJDc + a*>m'EcV>asOUa,S)DLZm0k&urb8N%?"V%Lh8&Tm5_UU'/"AHgO0^peEX"I)pg*1C#?1T/mUTkQ(E8d6JnrXtd1'3 + cYZ?On0SHaQKY:0>eqe!nBAPd-[$4$Na*",In*$^?)P;e'Lf@&QKlm.\G0.[dni)E!.2J6KE6c2JZ@UV + X22+-J&2l-X-8l[._m_lJ1ISZ:1F2fE26ngGh7hg43;#Fnad7>K&7<68T_i0@("[@!./BES + bo!C.#'1kM4-W@9=jc9KhQOtDd!qUb*K*+[h#qE9#+On^9;'Q_$j"]OL1+j3u:H#iV0_)fi/$kPQaBr7Q0p45\l9KoLLr_l9Q*P#q\3SFIsK#qO*GC7b(Wp:Y + /Q"dOS9G/[2W(oM&H(O$\HR2PeR)P$]h.q`H[E+EQHM'?_Y0TNKaS-3WKgF5nclNZjUA1kN + Y%d*XR75n'>a"8T`+q20nQTZ\%2IJKe9;l2oY43I + b/$P=41p8M^l/>HU>D!!XNQH[3/NW'2]bG[=_J%R=l]PKQ_idE63YXhg^;,G$l&.U`gcQF* + Q"YGF3iTMALs`Ko"BBLf]Lk%gdLnY'jE-FCIBd;0ZdjHm#k?';>nhQ"X(6`IO]CHu@@U2o/ + 4r1HWKjq_n0B=4YYUgJ1H,16*:EPjK>&n>\3UFb2I-=Ge8'WImfh`2qcp/[L + !:K!cDSg'QlBWn6S'+i'k[0]sGEqm>!l5PFRXtS%\KlpLp/\-dae5uFZagD1:3-0jc+,@@l + oU(8s!Z]dTWKqgJQOoXC6mu>LGF.!4Qf5E@=`RtRRi9BX6'_p+`a8QqY_A5Er%:aaXdLBAO + ,Gs>\2a'pGhCsLh"*AdiT\@b%eq;%k3fI=Roob6&+P&!)0@bCJdi"k/Idi!fpNOr,+6NmGZ + `]qRR&P7hC8]3]u>KTB=*D,>:A"`XZG;N'reZ'Rl+M&j%/T$f[:Un;sZ*2'OgZOn + befj\GS,/8TlGB\CAKKMpWm$="qes#Ib(mTWSuS'i(I6[njhL9sPZsuX4%HhB%B^9:\SOo@ + )%\nL[9##&]o1@Or+!a:CW=KfYp:NN+]ZRQHcMhVa;f*.K;aS]cZn%b^NS#Ck0[eiZbk3*$ + QDIU40="4otKgG7UkV2p7%eh%CK]pC7!h<0Nij,l$eMcn_u^V3O*9;FeG6TbFAl\LjC/\ef + H!I)r0o.4RaEng`=PraT)?%SCb:kho*A:R[VRARr,bVn\gX:`4Zi&*(E%VllACBcWp)`6,4 + HZ\"[m$a@`;KI7)MT9@V8g]]tQk4\i"]h0eD5a;2shR_,Ta/$Iopd3[>Tem/-H/H54C=T?2M\V49!bJpl2f5?55?,oA;8IC6O'O.Sa- + frH?^4Xn5`?ekSpdYR"MrO/gk8)B,uI4o"o$AapPoA8c)a$'EnI9hX,gRt%2*u=5V![.Qr$ + n'IN5l%852hBV5'&a+lFFB@C4;b3hTr::/s,hH$adX>i5YaZ5og?6*G + %mS2C)BhO.>=Z&BCp0C!c=XN$r0(h=ceukMMc.ic/&VhHHL\&)Y;i[tr#\UEQ$hR%@UcWAU + Z0Ff[>9D2E]J#10ojXh/9fBH]F\+k/o0I%+s3.hnRq-1q20rH$BcB6\kT+WFS;*63LP>SnO + ]&K_,E?N_Gm$?dGUXp2k/#/`Jc(*Sk6Bc_]W4WE,R*S.r+kru6>ijkn'H"e?8f=e6Q[mTQV + AQ\Xo=CELG3+9HhAs%Ou+ULs'QH'P`'S2tOuH1i$u+fsMpAmd-n`t4f4JO + .3>>,/TW*MUDc;G_#i;OB=$M&H@GNiK2]64s:Mp7,_XsZl03%NC>(Sf^s + VY+d#=VP#tY;;&Fp7jc5aN3Y:do9[Ao*F/C0KK + eoDD<>.)Z1K]Vm'\X/7SX2%;p1Zoe=ClJoni7PU(9R&Wm'XFE_flumhJZ1NMea(OaZIlGW + qR"W/oY]uEX6#:(URmtdr'np\(XX]f/5uAMqCHDJ06;/"?f$#]:1lb$7K=Ht:87^M3c48R/ + 0$^f0W`f`2KWcoP,(`Al%21LAR\S=.:I238/E8W<1hnZ);?#LM;8$%5/'uI:7Fj?'m,\[36/c&"[Io#W,P@E(eNHo+f/d"l;C,hY8c + $P4fliXYC/3***r/!cX;t'eKOR(S+KPIME][)X9*E(T/_7*_[N-&O25qdA_+Y2F-J$\2$om + jPO:;9;U[ATfXs['-m%c#1'EZ@OM7O(LWtoR*MDqf@E.LLke:er7&ep0H8B;^8rOoLARZ5< + 7@AmoR^ebc4Af5lms':t3b,I&h>8`7F#X[-n,8:OY,bt.''r.Dnp62@Q33Jkk'd9MkR-$Gk + C9(t-@\ghH8N*uHW-R'CStUI*c)2eR1];u'KBC4[[:qtZ[\0'->*iq^VK&:r)C9[)D(5m*H + I3$/ekL%\2AEIUM1"HNC(MChN)fe@Dos3T-SNaq[EWp@oK=![M)[F5h6Wfg:J#&88=gFF4WcSnmKe^N\RMlMjZqX8X3Mn,+[5ap[G50)FNO$D%2Y-U,Wj/-CG7,i:& + X`hSDWC*eiBK/[dFlpu/n=Xl.:Q?Eb4$i9cI"]<@&ec(50$g]'4+iP,Cf*.!4q,0X(_&2l< + ]\F`Z+OGN95IKoMQ5V$";$J0_2f(qoS%+8f^"4gV:*u].Q[#>Y"[%%%'k4OOMZf%&Woc'.S + t"8#_sT6(kH=Mb)ri'eQ'F,Fk0-u(:5^jH3CbhIr1?V8I^.Q + o]J*^`K-r.#2d+sRRH1Eu!*"sN=O,t_H2VLkDF]G&P+`KQAZqi8H8aE--EZR,pFe]q2$h<1;Ju^)F+oP^-?*9@[[mk*O6KD)@.m/6-l, + \^:<,Vj4pf-'#&9,3:+k]UJm\(V!lSH>ik#:LSV+Eqo + _A#_k$]7=bk_p6e;Lb,$Z(EdoGY4[&6_4So6H/m'aAMqL"6/eoO8o8!P(5nkN=^jk%ZXDB@ + ^HOa-!A,t8P*qg5DUlkT9SGX94A8]-W@'gFQi!`&lgXN'h>5<,d0n.q%lURbt#\:WDtsP). + $"f,:o^.`lRU/UO>ajF0\G>"1:-m[-4TVUodZG0ft4b(cPHp$^A/,>`Vj?,uh%Z=0r2ZJ-C + (Z'J,>"qBI:W2%1pU&;aKPJROC6E?\$a^Y&Z4W@Un\+VIV4dXhj=LiSt-[PWhC82<^Uc(;, + )V#o,_#u@Hl]3(<5d^PU1C6!F),8D-O>J#/8lcKsqXG^S)]eR;#4jTHKIF<*NN@@EAYo:c(_%> + (S`rCq1R`f7dn'b=Fp1o`_dc9aDQIkX4K,ik7<>j''5!CSr32Uj*<)h[Ah)N\.a`f'sNi42WMc?R:6Us"?ji3dYK._Q6\heOCj1=W#k;uedR0EcJ/EoJ)?j@)H\+bm=T"U$73Ki;@l87rf>aa*)o"GKTX;)Ea3j'Cl*]-*/!A_. + C)9Va9U8!55,6I>"#\ss;A4*D1aH8*.HQP$7j+(56:?/^Q7H@2WF[0ae*AW%%>QpN7[q[RC + 3pk/!BVkKa!;PpJnP%U[f$Mk*p(`8')D*.AELn2#`2NSW@,GE + ,OR0V?XY]/uoi%In0bGE223,"tS'/Nm:=[&`(QB2XgbS&0.dZBo3\[,tDSWnU"Niqu6?CP4 + R:XBB&b(!hhNDF^/+0+PpI-6uQ4!ksbO/Z#W@flDZj["&A1k+(V*'qM[n?BZ=4uL'6c2tAPh;Zt>-1OLl:"uHb.!*o1O-/EaB%RG-iUf>&G,G30e`5r5Z%PKGFj1*B + ?jmRi:'#l"_(r)skLCdY[qll+b-q`Y*&kW5gY\Sp:89\[Y%hi[G6Dj% + ]@(&*U*(r6'=NHq]FH[e9;\"7p&CN9`MI1t$F;uAlod5gHN#OrrqlURP7)HZ)g:9>?PsjZ^6NgW5")(%MX2%+[6VD@)C?7g(84.q4#H2_ + L5h?,!Bh"2+#"W:+6rKb,$pV<+7+>(rPRkJb5p+!pKUcc`XE-"qDo3P1^76"RZb)a.egK-K + />Ps-Zs^"/$o11N7d,TG;t:84MA7Bc^I1.S4B]EU;i'sA2L)@@C\J)38A@e2`(S%i6N5#e! + &'Rb7DS\m1M&'\*):oTZ]k@DF]&_c,4-;3XOac9\I"_o-C6ZlP@CEC9pAa\a\4e1 + AX\F$?B:6'@p'fDn&CT83>lb$qXrb_&=IK+R"5]1B@;>cA!5p^+8\$TmOg["$-gL)^Vl#]" + #gKW,Dg`3g/59&Mm*Ya7iU]WXC*/Ej>VlAlrj+33`GVrV*Gkop@S_9=1A#IMC6LpOs7,re: + sa[Em;K+^a`P=@&j7QX&VA(aG9dL<,c)e5rNC(LbCaZu]oV!^",&$0f!rYH-d>.YNMHI\hJ7M<'LPV2oPf2ZZ^lM:u6-oIf(_%EZLp,+BWR6VY'ZCss%-aC + SlHm?9dMjc9/?D`3=K^0CR=+PCFPEr$H7)CBbuA(H>pcK.:!r;N$TXk'1Ji_beASkZ%!iYF + XT-7Ta%spa:"X,Rkc#P07N?B;#jfur;16]rk"=:G+HVIZ41-A%^&pX20MOV7C6;C_0df[#& + X1=k[@eSYN%'@G-U.dV@2soq`u5J + .Q[Hg9MA2<&7pIIort4QKS\`Dbe,g\%91^p#YCdkYJ\)3m%hCTL"FD$b"[6;]s + osP*)iMc0D1qCj<)83'A0i"=73S/I7fe!3l0pZ_ReP9Ha + 5i#H5U93#(FnhPFfSJn:fO`de6.sdfRF*nSb8#q4fhC5h^>Ku.PpD2jV;EtC`OOt#g2Q63X + =.42MI(s$^.%i*"pi(($.iJL8gV[;h9-!OYTRYD7WFT\Zc!meJ\5GdASXp0uQHf0/3@R]ln=Et.5:4U + \#@cf=Qk[fE$6Xcpqik9_B._,``21o3giqQB%5SQgIo4'6qiAN`k%?Y,$aOq=k+BB=hnb;" + 65ia)'iP!oQb[XqU*ad"A&j9?XAc:H8k8R*#JnrOtjDJAdZ,/+@ff<[)hBihp1Z;A$f,dOq + 77^)EULc1WA%l"*L02gB5\6):j;qLd_)p^;M;P_Iaai4.H:64qo]29n?hE>XKf*2DWT-Yq? + qpc57VEQQpis%*jPFP.>mob+DB;PSk9b956igkrFIa1Ok@Sq!AmL4@ft + ^WqNNQ[4VI>NT@\"8D6>_2(hJhE&.63t/gSnf)r?0(FBFe]QAJTM"reG)tL/2E$\NgLTTF0 + o&NG-KIk;J-1#*?9rFgeH4kr+R+p313dQ&_/U#^1McHj1&PCPGARl*d)G\:!PgnR=*Lu&BX$`Ui-0q6;$NsrBg.OWW&b+_3bmSM + #,$*nTa$5_EJ>6glW\]Km]Yj,l%D$,"?s#E=F19TP&&-]lMeAJ3/E1E=p!isB[2V'(:%]CZ + g118kl.OIL<-Y1Oq'[WlJA]12R)KgZKu22CM(%k@63c#\neaeCY$48f"^OZ_/(IBlpf7d?F + 1BKQ#)c?NTQQ5DO=khHWsM*;'qnGY^[8KHj=n?mO$t3.s6WcCun]JLik@`d"g4BULs-BaL/ + fuW/0X8DUGRoj62\<#ifTam&'9"in!/X54]#BlL,d,=4XF4GZP*r=)E,un$]H:!=%p.NpGn + 6#5DG>8F(3Hk_[^C0tA0L0`MLDY:A(l)q:&FakhCMo*sG`Qi`kk&!<#E,a"rtYnV`9R + @mLQ!dD'WaSY,:pXI]#l"p^T3tCB%>*-X@3PJIXlLm + 5DZHk1&k6ZA>E1#QJ<"#8$P0HtF1,ppZ1S.;VQ`Q0fp1n%XAn+,:=ZOU`akDnfh=k.^-\L' + XE,G_V4QQXt15@<)m;H*T#B/^7VkOEQL8)#%c:O!ZnlYJ[8"G:8;I!PX1Sd;l'N;bnu3U\` + J2;k-_m=XSV'<7r*W44D9Ie(m4aJH>McE[Oq8/t]E>T(hj$c&P#O(oOhPpUC\$J$Tm,[^n]tVNa+&7?Y&R6k!3_UmO3I,He + VI9>Bg@IQ2b`ofM=e7[KW&O:Y0?li9(5X7IP8D@[0>Hq23T^YXCadf&&rLmW]RhTi@*:b)Ti^Yr#!A1?O6Gel_O,Wd + .[$].>\d@dR!)'"`-jA@oWH9Dd`XrH\[X$%sV$Hl>QV8OQ@0SQnTD+LZJ3B^e1fMZH1(6&b + U/IR[cUB'OKL/Uj0.S4ZS(m2b:n>XAI`q",JR]7dt8R0tN2]_;.h6r9=\,\-_4.?`IDS0:o + =1dSfrI;UjE*,4L(Cc/<@W>M_AiC`kaC/Bm4/Q!IQbU;A:Yb"%4T!K=F3i(jpGDljl>d!OA + lJa^fP7ZD`hQB^$3b;@4,0JD26u.ZG[*E[(QHJrEd:a*8CVFdh/c&u^8G&7fBd[-?+\:8]r + np-cQ'K[EmCi(1E?nFjQWX?RRF$<%s2mBbcFB#;9CH-r2cR6/+3GPDu_Am'M5qH"@.e(&B2 + %3s%n\H\jDlPqb"NrnCaSdsg]'uc;O>o1KmN+EmHOfWC=`t?K;#KMg + CQQNksF>!2>0H*FT4pbHSQ+i+0m.J+I,PqR2&(CaTb,L%8LYrBJX@Zr&nI9Zo?>ZcCT27C4Ws:I)0Z@!L9]!GlN)2 + U0.4hD`r<4\rLb[7*sBNHINc]2"VL"ZfXP?!#SlN*brm1a=^9:%0oKPV7k]d%dU5@[sAjDq + 0*,6]+$iX2rW8X!B*SF`rR,;duc"W+^!0WkGCd&ITk&3f@IA;_#7fUW>cNM^Z"@7r0Er^#6 + oKK1tYH<`dQ=IG^CYrI<`B%L%E^Z/?]G8/9"mQs+-^HAGYf2;AP=<[,nN=Qq]jA5,_9R]7f + ;Jk]r*fZ^(Pg?KA5[G-j-]YiM8e\n1eLc*Edj/Oue&D`3j-Ac&BA`]1PCQ(tM@%'iUVl;`q:t7[FEr#glk`;drAFUql]=u]%*Wnn + [bo_WA#lK]%Z_JfW'e!c&&lVV]n]qToJ)8b+W0R$ + 1*iaoRD^dg_RPU_'*S/4WVeJD@#cDi(9UH_2I,]IJ!,S;a9(EL.PEd[6fX!gd5(KL0hs2e= + KN=t`*#O3nB.O#I!-Y/6>tr)&J_fH6)%=,@cSFB&EY+YO*\s)OM2_MG>f'C`,gr8aMYp47h + ^[U5\LT=oL)6/P+8UF>)k/5a7@f$?\:j$nS1Zf=Y/q^af^,)nc"Tu7VGL.Sq(FH\%lJ;!ZM + OTDGX39aa%/Bh:**!0NqRO=_ruRg\QQ#E\N[K%%O#M/S3usWk&fX0jbe-N9RcYP$!J](mI] + <:20)cVkZ,.'J(BNc1OQ6N?[F6_2N@X(G->kJVg0p6thl7],>NKkCiAs;pK\>(q(g8)/%/P2`]>tl'qrI8 + =g(J4_[>6V+5,kR;$hNjQWKtFO!`$`jXWu0lrTcc*9mLaJW`X6"#?3HB1pD(BW\gWAPf8$B + \7<:3*CQPmXNF+f$DPX\,QZoJ2/#CG'/J01DpYnuhco;,CfX6Nek];0fht(+Nad<).5V(Y` + 4=]\%@li5:c2O@%bCrH-P0ZCdk<8=4CAO4/uE:jFQSG+XWjVZQ8QW]W + r7]eR+,"NIc>-09nXqQ,l;5CY`Yog[3p^9jnHPYp"eM'T@-G\*(9n&*`KLVhbc=WG-I5=ZoJ*)gJ8,b+5:WHNbkr%Cu4m4V7_T!l.XQ&#&]q*;NZ8mj7Ko6 + L6B1"]cuN^_j-8IL\Vq[;7O>Y/g7b$U^ + G9@W99BQr1l\A5`ScZ;Dhr=G4LqP:L\D?,q>8Z.>LHJ\Na-%_dYDPM0%OQeQT.WC=;j75R&mgff4KFJg$kqV$,2N]F*m#JV:;9bu + ]6M._/clpOS1H<;>6]9AAEAP6rPM[!*U!m+m:M$AG7sGY_ + meSMFWXrM\3#<5VR>*N<[_Oe(7qP&al'aletoek"/E!C7P+!$gJiEY&$V<.:hAri1f_ + D%>&C<(M*CEd<#:6@5`S\0DoIU(Z(Bb3;13D4'9)95#Kl,_E$AD")m<0X!d!/qojDU;Jq19 + RT-Yn;`V2gDZ6usatE;QS(g#))rJAVLNt-!pHS-F"b.iLKfJ-<%4-)J8G+0=*,fYf\:c,0$ + dOO3ZVBeNAn,3E7i^dTp-D7/fO);K'^/!_;\r/*hRuFYoj4bMntm%?HmKg^lSJqSYUJALpQ + m.I4GERkalGJm*%;q&K6tHSm^;E'0RY=/(]QQ1EUM-JVB=0M^8P;Fa/o/FCrl:`\m@<&M/) + ):Z.!mDG0PL%7Q6]P$IN)TIt-l-,BRgj+nRn;R.2-5Hi8H?pA_>ss6p0kcj9\+$NFQ41P6Y + h!Se^B%0>r'!Y>kD@HJP\a>+q&*5Tl$:cSS24T]'Y*C811+ljUD_#pnh"V;q$%Rr0]qB$n) + "7T:p:hUfap`AD^1!f:f0PVV:TGe7$]k;F,6$O3,i;O:D(P<(uYYPJ-B*Bso"b]c.U&$SWT + *k(&W.F4gd'X5mTaU?!!?q=@E#T23bl;,6*'qLu+mL'Kd1#N\"7Y"b&4m#O:_fXR#S$^Y,\ + GD=Us%eS=JB>NJc7k#M%G93@Vc,Y.%(ZcK%"UVas>sjc&BZZ32EFVj)I790i0G6<>*>5N39$kb"V*JD&i)m09U-; + mhfOoR5B"XS2?-XfCGi(c$NC'm5&-W3Mai2%VJo-[64i"'ce7Xh+FXp^9t.qaBlU5^[@&BV + 1@d4^<\O]re7R#H(.q2r*>P.]t;0cGZ;g/>"%YDgCp6H"si*A[:@EqqA`$Pro3.^IAMiKbH + ,QQ]9>0d/P3DL.EM<@d-n(Bg'Vd_ROAMUq@g!3j.*Q+TN&\K0#3[+EB+s!uWEVdlJ+]-Ltq8o>N\a(H + D$M]b6)KUEM(Mo-H/[.DRYc5ro*U2_%[X3eQjR&],0Zn1TP//u@!A:Q%)m*u`#)4RIqSY7` + !H-9Ul&EM?\bMB=EK:,%nW6IAFX@bjE2d4do2/J0Hd;-lZ]o/9Qf7l5?Adf;G9(5tZ6-<)$ + >FAdI;Y=Pjn7>F\k'K.C>3Zn!!(">QqoL:-K9(PnR0D(AYnK9L7UIG1L0f6G>.I, + 2MDSK9bJPQ + NseT0%UI$mfDPgjGhDb\Ku:(G + ?qZ0Jr`mU1V$)W@h:_&>kQWQ2;)7Mh-G0\>bUp7!Uqh[ar!Eu?5<-=[J*ubr#4N + \'I+e@5u8:2qd6%;&&A)J?r."-M@e_W@.hY]iG'.'+rVUO&p>R.ei-s0cl"!i0u=,8Fus&s + 9k0Jb!jF:3[DQ6m:LN-$&])g36'SCX0k46kB/WV"G!BL^)BU-`*`bpHG)'>kk5M+pB_I?s< + ek"(l7o^8?T+]RFfKqVY3[dZgonstFh7N-IrS + s5;ZI^?2`Med4`_E)7kaQT^t!P#f6$aR0i7ekf%"miQ3[.l/mouKG=i<1NHX??DU`TIf6MS + LI"F9RGNP%u(Pj\d$3;9SGr@,fUIT:naLP*1M13a\Ii*Q0"%i[*N,91t-9%>D\3(RgL#BBU=XeX"8M9C+GBk!gGr_(_NJeZ: + 7lE+8Goeiqp]+]ePp&qg@I9>Ss)AoDQ6sq;=0*Lr7nr;M4m.uVUP]N]FObRK*(S#=g=L-c&.oTSE+&qg" + DjK8mofQ%&&0'#UcLr?H:apD9r.V_V)hVQHT.%)63Gd)k+1+fZD]e1cWC12\K^4)^`XF4SWl + 25./O%Q)l^E\Xh+D7]0!F-?qn8C!"`68+^6V0gW@+5e$FWFZeMt&HeH*Eh7`^EYlHGkGUs= + YIMr8([QDaKA6$(4\$l%9XV\?[Rb*VtOpO2O!dk_Vg\CYu6]'e<(*"WAJ7FN]cajVfD'GYT + _9&&!4i@1``&pK,HqD8h9uQs,`B7/>Hs+G$?,c_M`]RhPHtgS[\$P!'`uo`LGA\87TtGala + ?5.Cqp6L:hoP_2aZPj1I$r*hS]Uf'aulNB5eY=P5QI=Y"['2h+>80&j,L6(C"2*Zd)l(\gL_AMEYkoTBf&LXWo>hpMd6/2iI#H + B^(WX,u[6Ocuh'`qb/WesdbP`I1@i_*B> + "@*dE7c-O(,1'"`6HNFDBI?]'>7[Yt&feqAENS*PQJSFY*]oXsdC_9kQ"F[,Yn*+Ng!Rk>D + gEQC@_N31arR>%oTK+tJh8uq4)@U0ngIH!R`*OBGh"S9Q%3=QcJUQ,I1=2TA0c>KCSbR&HF + p#Y$>X>MII1b@#%H-J&dCp/F>?G`dAcc+^a1BaRqRZP@c/F++gOcW1]5`i/8).6+F2?&,!0 + -'Q1#iH?h1SfHIT_onZfV*FW#]m>!rR'8TNKN3P]F$^a&KbT:B7@C#7E&+cl;s,po=(O4kE4Io7GuiXm8Pjs-qb^ + MESYHr_=&m3.nmH,'pMCD.qXl@4<2h_HJ4b8ri1gb.!=.Zb%++-b^:q`ZD'AcPTBHi*d&%0 + KiGT?6uhH8\/f,%)q!*c)N4\"(3Iqh.uDTB6'elpi.Mro9"6?hMKiRNN.9'Fk!EI_jp'Qdd + W*$%>1tYZLH,.2@b0it7[.DE/_u8)ki9&->EL(M2VlP5K^2Rr"T<$Fog&73I)?s2d'RoQWED7mh_JDmeKX8hs4&H(&&#g_dW'PS5q9\NQ5Q")'"r<.@#gDo+c:PD_7O+BCm&f/ + rm@X&3#*b_qt9=l5(6HbjkK.5O\aH^PscP#6; + R/6k]_iE+Bmm61BL@bQ7(Z3=*Lk`#d9C-0o + !hL&.b;2i`7+4"fF(/tm_P172HHp!$lT7kggtOtK&DT7 + Hg71)(0;J#tlQl]e\`#@i[Uj'f?,;9".?BUJk(`78h.IjuTY7$f-Dk[Cju_MiRGNL^3+V/thpsr7Bihg!.g4K + S`T<"fGih)KA,-00Ag^W#;/dn,(.4*clG^)pAbh'iMWF$Q;O59YAK;Rm#aAah,]ohrR7P?3 + MNo,!6@&XC^e:Uhi49u)2QKE;/ZU.iVR',D)O1J_>WAUmYqe;UYDm@F7anb^HXf:&Uq&!BG + j\t"laq&Q%eI-^=^nS$DgVcl2WfiKCmJ]C`)qHCk`1'&h.\d$_+^Yk.W+b?+"hEN#+m9h6! + C!nM%nbg3R\6s7mAcpq*r9PFm>"0Sa?<1CYO%2`n@hsRu_XJ-G/Pe^\@^TMXBni-Oc:1&RQ + 9m>s*ReG&gnEeKl$85kqI.-'u6t/\"@7nGqGhF7X^m6T]h!M20#0QCia6K"kYd5LsG[GO,2 + OrK;&P&aAFjVW%C.1cWX;!O1*r9Zm2P7_>HH\hlg,tU*O-=kUlMC;Y&\-T + *+,.sP4O:!U3,!Q6jd1'`+2DQ!J-S/-eZ^-aG`PLI5#ULo%4>o+Vp5E_?b + X7([oGl8FN?<=$b-AjF:b:!IfA(ron9+EM@AbemR/+IoC#%*D1m#qn;O<9p*7N_Z\Og=2r) + !0hQEHTC=cU.KI,H.',2'_N$)b\XeU;r!GF''p/X:^`tMi'Irh+[M[32'f*&?P-dX0;FXjH + K;Iq&l9`B727&A8Skpfan85.<9Kf/Wg?W[@&<%70k:sCHIGK*aCiXD;.K9i;t;"Ib+/Q8;c + L_48#]6S*=+7e_E&5%3CBfFCmWM;X&6g$9,caj("ICo4\S:_%W%tl^b7Q*R//5Okmn(U?MT5V@=aM0t1c8D)$"Q:9PE$C2Tplo + %)Tp8]O>O>(1f:GX_&08\KFE63HRrU+/EBol!0S'Y>Q>s*BhXhigKT#DC+Fnj[O!A'=e^#R + Nt"m8Q-F/MRujX#`;?I>rXC:Z@pu&/8Z*4c2Fc-h,6q3l!Yd%*%-t`M?qJucpMc:K>L?L?& + U(R(V.<:CRRp,*n@ha(g0VD]IW*VX[qd>e>4Q3KmKHZ>EX(Nl7Bp,Oh@!$//XtPIRYr56Ne + =f5>hr"YChVKJ\:s3-&L$b%6p;h0(mbFgOm.a8m+\f(W&ir9:0VXOaeMd.SWqoFHuZjn0GP + AWiuEW3EY0h:Wtub@EbB>.'JL`9_'YAYR/ZM36ct4G#86WHKPl3)BCVDSfScdL:Jj>26LQ] + 39[H@<0KI:WL@l/L(^b>G=jE0L2O;!fZ"+;E.9Z'P>Z+RMPj4bF$@6_i\j+jFr*=VmdX + ,;(G<@@)[eT,<+M>dXd=RcH&m<,^X&'9`En,fKamFV\c9*+rSm0_!o(BRqI[>CZ^p + V!Efs?28nAr(/)5XB^-RA@o+eCep>hKi^sTX + ohr"eH$jZc,cVb5%C:X(D@5]X[)I&P5sI4!IH`.eQI9)!<\fMq;#q3B'JZUQaCfBe&H$J^E + *;0j7uJS.A&gHg-qRTdKI,G/95_$ge9_nIo0$7pE8N,.I1uMDWX$`[D`&Go9=)ue*1b`rdY + BMNa7Oi1]CuV1agjn$\iG)Sd]Lpt2PH`3A.",'AS`H05U,6M4=NUbAAJ:O66^KK)jt$Sqt==@=Z$4gZK"r%/4c7@l=F_mDs&M*8_\PABF&V6u7F2e5V8"qmXJqPOt;09SWo71;2H[73aJ*QmYLnP/Ed&b"0 + lI#Z=5*X["!>%rc5K9U*JsQ,(>D^sn^Co@D(&[S(;a8[-1V=M7+:l\`<6#m@i53Y]^ufunI + ?bE.XuFGWF)1;T2bL1J4bE(hM'gkD9=9CU+CFKPr&),-uLbe,1D*+_c)KM:A'8(>US%+,K* + \3#'m.7BfPo-TMS0oo_,YT!QtP\;*PBh]Po9E9uE'Ac?6hoK5P"o;_[:pUNtgC.hXba9_P9 + BO&ibt%sM$?VT)bg9*9l;":j9dms)^q7Y)?\p>-Lr:2<,bn(tffNEl::%f4d#(QIVp$\ia4 + thjiMH_\qE@%6$qkpJFHJSV28te5c>0<%;lNS*oM1qRcohL=I-_8,LJ1,A:jO)d,h1+aQHo + q1Jnml4TiNSpJM94W`f0N99;PE\JiPV^c.r%cN.rF)>!+KiSD`K4>nII[L]Bj_2C"[oFWEq + '!#2g(M!Z:T]`V-&,#ThU:g$'2r,5$?JNs8;aB^#KjUqh2S3ncubTdJ.o'*pMIMbU7;Yut: + jQ4gGW.st$2BeqIkZ:6E*g@rnLtt"\XWc.>3`Du8;F*QHM".?imYN+RbIRr,Kf_/7.>Ra-/ + *)Q'N;(GVL'@s\!Q@S6D+R\DWl-;f.^62Y]UjjOIT()U$&(ChrD?F_4B35_e.kn2,=+nW`)X1?L"1,C/TD(G4'%H2;s42^eTD+>G"JN?f.`1b$UoncdeXB0h*#T\1m]o>F6HWSaF + f\5+^j>,?`%9O1;=.a@Z*I:m@X=ISP/)3t@bV[DCKA,_!63XAk]r + P@#[QA?.=.QKuC7JK+.lgV"&7oc<=@EEb70F038EIV@otXfQ_-AS-gc`MZ5\:6dAhTNtLJ> + Zk:!$Y"b$7BVLCe_9&?#f#FbZI0gmuVo%FA>sHjASW$@lH<#[ZM[$Le^<3t_1j(Q"sBiLJ:%TUia-K\>fFqpIEl*jiER,IL$N#K9nuqY + \R+T`gO4AS?p4JH7K24>rJ!RY#!f*j?u1O/"^nJ;?sX7KW-F*=G`%#;L+kpO[LD*.&HVB"Ja + fXj?rhkk&RfPi?e@1=eCP%epYUuIi>rtH:e6=S8;_q;LQHN7Fr]JSs'U!U$@W:hVBTB=%tk + tig!R$,iZhi.ceddRik''b!Sl\.cX.G=.$_@[2>&`d'[>roiN=>6:(,ta!=F8W?oB=j*][T + 1,@HNNkNZ!_/1h8d?@)a5GkbmD=+QRu>A#9Lk + [O#FL-K9:Kbs9/Ni-0q6;$Nsr?r/lg!'4[>;$N\9L7lYC&93F>qW3fI%/qjeYX=.16f7BUL + U(iTAm^=!s(0hMLr_1PTIsXg<97FbATh/ap+'VOC,EXV$:[m(-<"JF]B#r*VRg'"gB*=kfL&(7RL8X + GChQ>(McN0]uiesYd*Ru>kIMe8OEm[EDFRd(X-C*n\mY+o_sd7p&69rT?\^jCq5C2PBY"%M + ;<7cWo3k&+MgDF)I5Gc-9mAI!tQmV_-(cKoH*l_o>_$@qIJ7dKLam;F?67=]4@=@rf.o5AO + ;ms&RT&93Sp3.m$&mrn,;L?jnT@#B!ELXuBB%fL92*!_TmB>fVR7Aa$gH;EI0ZAdE^(W7d!CJukmEIVE^q$gL!nd:Vhg.XnqSc:89aT*((,O-E2 + Dc+.8YA[ZSi\;tKO[r\4MA)70%BU.^ss(HqAD,/W8`W]rkaD+ + WWj=ZR'(6&Zf7,s;Z@s3KAcA(R+VWg$2BQ+=Mn>?Ae?j!T%iPpc9-B%N1N8^(^hhP"defJK + W3+J%%"dglY&BpGT:CG3!hqhja:l=jUhXb^-o7d#%Y`JC[[WWdno>U\"d$8\7LZ%=M@).\B + %mfALa60E-E%'k&a)(J%!VY,_p?-@<%rc_7DMB9C#B6U^+EM`SEH_A+GAh_M@)6mIVf,(KG + JA@ra)KT@?j`:(#&ep7%t+-h>QWh95-V"3:gSA_Gk`Y0+^VcZ#fbuP`^ap/VI^R-G.Zl"**q7r7peW->_mI)!aVa*r7%-MRhiI"uZc2hVO!Kma3PpO@u0c\_TZbkGb/pt7t&6r;IJo + tsgZ_e5.eB9V6IPdEB7M5Rrrs5A(KC\HN0pNYH + \Fam,MCPok3^Na/KDQWdbKfG&XAUcgtZW'BlklHNo$"fV`EGZJ`L(qKGL'G?B!M$?`(f#Qt + &0"+igHd!.r*&f""B@?B\h.O>ac7:OYh`(hBnLrNrPki=uZ+-K(HNjba;E8OnhV/(nrSZ*N + ^aC9'(bJlkR=r/Hjq?.7#6NBtse7K^JK1i(?C!\c-:#lBWXt#]OX^8DWb`-5/= + .V1E)_/$4./2m@:_;P3s64ZS`c+E4th0N]hLA%mJ"1KJkh>XKAj[*t;\8;K4GW58FhO + >ZHhql^l,l?iOQ[YGn=f&N'aCI18k+Y!aa#@KP-BTh8u;"a%1"(jPRR]/"qej`2(@InLQ7) + hk_hl>U)t'nd./\*+\*F2EKiql7$,CLEO8ddLO$DZNAW%,-BM0E_7S]BL"="@:/8&I;1ZFR9E%d)7LFc + DW:2&3ga=%h_:T6r=[fO`X_CVm2cn)UgFREui<)%"BD@E[st[Pd3g[UmQ3L=]X)'I:67/1U9Tp/]FjYmdE`!F2 + K>LI%;pV$NMrLSa4'A<>SYAG$2VE:!=FhGB(?GL-#p6Vh$T]fgf$Z/\Pt,Vd-TK]*^EK1oV + HFSLLQQFOl]_FbQlB+fiE\FJ60I + -$Hp[IH,alQf[UjT\%bQHXG8j*J!B'(7*!KcOLP@7lY(t9k!nLN.U&8H68&%oefTHAU?Vg[ + -_(&Z!,7,\piPGXke8/[ak7d[NP8aMWJb\rrKq)>TX8T>#9@@_XUOC[C=nN^;#$41Q!p)Uf + jE<(Xc/q-)m\FU'VbcRbBEj,Z-m=KVi"CF+:*%m2UaXFGn&dY..eNL7oUX+0+Xf$7@jnYJL + st4?\Q0GPM\30o[ej?_Q][?D"4^WL5I2DH4^m?5El`_aKm:D7?A\E4DaC& + k*Vr0_o[L+UgE?H"/^QfiU#h@pAkuR?Jp.]1h%4ee"^UX4F@7;2-\mLE+'B,),RNQV;c;9] + 94iO4ILng_7$JX1mVW/m\LXBKh+-252N%UP\&2CSTc>qEd,#a0Pd'u0$]0X8r4tAF9]OFA3 + bX%D:I*>Z[tnheJd;)W+il(.889#aD01IsneDZ8W[N`n"t6Ej'[MUM<\mOR)%_R:q\5G8Ma + SHeZbd4lc?mf-/8cS#R.VN\jF'ZMD="Qqr?02QhDM:/n/]#tKHa#K,;Cr33Pl:08ISrKc`T + &mQ0(K0Ta-L_LS'=."#]1dmf$E)PA?MNMKlUO>u5m)B;j?&9.A0km9!(jLoN:PiKW + $8I@uRFDe=mh`$p3EM8kNQd\-39c9bbU>ZW&3BgB`rL&5&'uaF,(C"c1HM3=n0[ + rhZ[eJ^S@g5e&Ha-\PQl`X,-J'h87e+X*Fug%pe0-;,A(>^dq*$BWs7FJH,/NtYuY;&U`Ke + k=Y+mqR_QaUD&-60Of^as3UDFu(Qn-)@6=$3"EWV2gsWa>5Rd8 + #uaiR1MT90SLar#:jrT$%H!5fnT972-_kd#]bEcA]7mo'21aR^H2B4MWi'E0![aN3=Qr0Q9 + k0UVf^7>3fa:XiE8FO0S*m`V=MWQ.ig-;7\>pHod`sI/'N&5)%@)@\=C=JKfou5O;@M+I&j + Q:]qR4/=@3P;HTdEpubCEA6aO:/uVOtNrR5gLjsH5#86o#AuKFaU%S-3>8q-iaIO(l9VU6. + H8\X!m=IhaI.2p]H6:_oJKO@qK%SM"@S,sF6h[7)cME/fY++^6KSmuL9<2TZl&N*s-I>Z1+ + P8/dV5CMXkRsUmCs6E_.C"-'$'G^(.q"Ho`c%*#@q^p`'e)P'V(([I"!grA=cLM5s$.-"l?i#/+#irY + ],SriE$ec,RB%DpkoD(GoVRm0==Z^CA?05bE=-_IFjF&]/HT9b<6Ns9&':l]Ao-TRb_A1"5 + eBaWnN!%"cn3N!_LZJsD6MCAs'TXX>EFYY7+b53,Cg2dVXB15amM4MC&),7E7"X7D.]a&I8 + ,MTIO<7MF"gP[>A!P2B%AqLL[.*"C3@8S!ejIJ$rh)+D:/UAV('aaY + X4N5,3N!9jse_Y@aQiRPD2Ds[mro+fKci)K/MU(_R;[EdTUI#;D@=.BV9'm)Nu0XUXEapY3 + *`?[YXQX+i5p%K!Zgu"V>Tcu9\Lk6J\$_I\J:,U!T3FgekAYjE*,XA:;$Qq9"ocBnaHD(P& + HtMNnm]G&R2)E3Q/uV7;u<7=pd-%n-`>j%,iX@laVij68-CTT/GcP:D*)D9dt+![&:^@l($67L? + 0fsXZ$0Y`2"1Um[ML#4,F%4V$C7:?WK\q^N/Ys]V+jONQlk6`VA=4j=H=QbS(M]_\c1u;Vt + =a&``*LG>$jY0$$A-M%/9/QeVDcJ*q9RfBsWamsG&`;gZ>LhQANG(%(V`J"tTa?4`'?BNHq + `-"_*L(auR-rhX'1JQ`A363k>%#LE[$78X)I*_Gf_rr\u\0>;,^D!nC5,)?_lWBq`,-u+SY + `QlE4/D*^S85k)ZTWV2rNQCu@S:!]@gMGCDUJh"V0).i!a,hGLOF%5ZIQ283OX%%2Y@\tKm + e&7j,&fM(/$^::5U8mbj8p[pd$u5_R-X6E"n#.jY[GV-mfm^V$a/4^!_E9d;X[,OrZ\NEE. + JJ<9c,M"0ee#h&<"YLs + Me=1018+Ba\g_ioTnT62peBh'T>C'r%0D_HPKP\0DJiC$@ne&ST3W*=$UQ4Q/+8+Z'O7@L@ + .J.Pd\H;QD:gCDX9M]'e@'&1hHIV^6p,-aCVg&nNEs:a!&]C%?6ocjWpu/+3*IdBNkG?mPP+)H,8G_nFHW8,qpRM,-_.m + m3s:doeZ1q1dWK#1&a5qhREj66HT3OkT__^%5lKpln[WEKu!&n;!u1)@0OImkc.IR=M$>2- + j#kr15[IMh$#T[.rgk[%H@.EZe;(82GPnUbYcqN4AH54^sa@0%0W+QTd]?W^T5he!qfufe8?O1+i"ae%/ + X:1*%N66:2"bU5_Kj2+%MI0QRRSZOSjPTN;dBKi%(indR?!?SZ[Pi=PY?<#dr_2C)-$d^-B + ;oP$bC75Ug9s3tpt;/6s>GW7L[3qN):!_Z#4Mb+"H47mYN'TuZ7&63Q<6#QPFb_cpqXuQ%r + .?kr7oWA^V'2-;A9=1i6Pfaj8cU[$@4d7Bh6Am'sAOBB&0Z\/S_O3->p>Bj&7q5=M9Qr7FS + K\UK8]-la!Zsm14@q:m;)JS41ib`F\P`G1;G-9cFVnX'I6(@Z1t74@'f7'jO&ORq,P79aoH + 4ch:(('"*u.jV7A3=3U'7f,W^=u0.c+ghe@,EY + g9@]=H!eFE1i]Yf6&X;0I,?-9qH!NdA?WD\%LK;rZD0Ei?[InTNh."qC;.9KE"I!^JX)ik!?C*lqdP`= + /=*9+U?(s#Q(GB1JB5e&2cFuZ4_^[[(tYWp + "!@Y6:^7fCH0(0(NqZ.h^Ik5mH-#SYj'-Wb4a$mfES!TA_@e_Kl#Xe,?/rJ(QA,Dmp@sT^Z1QHts5Y[9j4qp!JNTFMoYgn*ifk_JDNQHU*6B?l<5COf;K=I\)U+q&(fh:A7 + OZ(U9o]9tUTl.r,1sZPZUMYMV4s*l.dC$ZK@Qf8U4']6hK)ubYfbPc4hdBF+,%F\u!\K'M> + F)^[OCAYc)-qraFs@k<6Bni%(hnkYs&aQ&8[hW=3Kt_3,8U*E,9e_.'f$oa>>(4ZPbi#NJs + m[i^(Iom=P%"1i&R=\[T3+MSH:*sDq8+e4(2/\.($[G+tmIm:S'fPAAM&Q!\\"_dpn#7F$Ic_`K.>%O7D1j,(H,Lm@N#ZT,K4j[U#Rb@4>X@VYM&Wg&%G91fY:`R,X`f!l9@emkIl6s-EC_f)'u?"f:2jPjnpB3?+_Sh3NAS25.,Wc$7OR;+GE[Z3L?pY#F63$=/%@6ifAkH"gK82Km@N@'nK'TWNK\pOl + D@lUTBoY)OgNN+PF=N+mlYU9F4p$.Y%c$jH9lI?aN5?SQfPGRG0sfRPf>(EB&Z;@M=/Mafr + AE.,kK@=3\4K&X%?JTOY<^]74ucJg.gtFdo$HpM5B8T68n%KGm0$_fcgm^'f;*GX)qMUYH" + lcauTKVC/#N!C.Wh0H>GuCB<-h;ues!We!MUbf_-7$bHuI%dq';A;&Y'rWi\SW#A35-%4@@6/!XH)a&3&R#b!:g+J-jBQm9 + m^qb?V$iS@cu"^W[\8bZr34SBK.3ccmHYc!8lFSD2i+eV'EO3MUg+4*DOYRVn7Nl)I7Lp*I7_aJ'/R_!e#jL]o1P!O4bP; + fj0rtSX\YE&Ffr"m'QBF2Hp= + (6E/\:Ytdf$a&S`cV.K0+MEWa6km(Et7@\)c99iVd-FFsDilj2it(,[3XL4J!YR\*!bgk?P + @s*^SuGJ*7r+k['&.Sr;ghO6I^K25(QFJdp$f[Eij*=a4Z/Jg\p>&"5f5R[u;0HLp!X`R#e + \QpV2H+siW4_f37^+J,q*F=XO8g#TlW.)*mj*p"0o]pfWj74)%s_;677hs\D<*eEr)SSfR= + 6UCeonN^USSsAj'+7^Kunm`'`:lT.5f3rEp"h + $(PUKHiH\`?L6*r^X:=4B3J->l-!.]^OaG/Uo\E6i8^S'LXmc"?1YJEH_<>>LEu^Hk$.4'g + /Jl@*09.bJ\lpdJc_R5I_k!%HIR<668A@!1VNr9AS/tkuWf)T=r7Ye`9%#j?L',hr4R,dDd + 5::?"Y'S$hCq!9/PR+G,t7!YG`m6K+$YF?Ui[M+$?c=L;Bh)3%,GOkB;T5p;@]i^e>Nr_Y+ + $b2MdqFJ`J$R7ub,=g[%*3Lrq.PM,U-JO,u+k`f5\eUVcLV#n$8D).)JWDB!@=CO%j;j]<* + OMsA3I(cdP.u\bT4_8?#\8@>IKt`1>Ct7i/WZ43BAZo2`[O(=(\M_&elfrg+NYc95_l,OsA + bteVa\RX@&WJiA>$7/sH//+C6(u\>o>(;]0UJc-]Ch#OE:708fh")k?+/X1\_V/tS)*^E[D + A7[G`_V@+%aT9EopG\"qDB%_r'uD)5fNFNeQOSPFHnck_tt]&XMa9pTZK?4?NO5It,'jo_L + ;+f2(6?B`1tkB""WB!LF?#"TZ7j1_02Pj2;_-+4,$)#XTp"-ON2%N#[=4nC!186`=Bs&4:F + O7hS4p1esT*Dj0IX77iU:(a4KIB!T*d=rQYF@VQu%%uK(I'ZH%?JJ:09'TF(bni?^o8+KlR + -bba;:3`BYM_M"W`#4M"aKkHQ0MEr7fPnZ'@X;W\,)k(Uc)oo03"49#k;lAE[-p+Q1Xu._: + UB]n5Ys9P#=;7o2%N)P1fY>X(A)WXQ&R5-?SPHc[4b.O$<4?,!johO9iNc#TZK@<>f`O2Ns + oo\53GQWYG$i4RcRS*rChoF$11]G]T3u8L0$t.G_K5I7:`&nLeWk)[#D%=::!XURqc-8Z^0 + &@m6ajES!NQsDunQ(GR`H8A^>I(2c\IQ?+4t6G[4kAk2EhKF,j\_pX5sD=77_9[T+hpHFft + tl=jfQ(1`=D+d''-"JKh`K%j^R7Lt,D0jLTS^T[P;!Pip85DZ#;=RcU3n:W3"IH(D"GT[+)=Xe( + dQ)r='Td.(a8N7_Og/3tbK5\+(N?);,?2M9>l=a$hCt.K7H0W"sk#Bm%+UB)(+=fU%hp`YW + hZp;n.7i-(\.LZ0Xu+\LcT*\I,kFM0^O3Nd68s$-,TB2'EJ0rI(J#7F"KK_4I>QQf0D'Alc'%KrXD + Cp"%9_C'3:M^rq$!LOL2@#'TC_(ob1Q!,SPmP2*qfDu@gEA;>6-2/3agC6Qh2[;%tNr_4br + ZQYRL^AdP&E]`!@Pbq:@oQ<[0lRuhA57ub$-f7^<<=AF6%k>YhS@W/XeM7X@o7Xu7OYS3h0 + RI)E?6u"[sUN%9=Q`%hDkqAkRsYp"cie4$q@c&+&*]pGq8#A,'V'Bd;36MY=5Lgp>Hemqup + .Q"J?>#9!ZUUBbj=O9Lr5]PbdP4*i%56%cQ2,V'Mq&Z4*JA_A79,E2!/;-THI.bQPMC(,M!)5e,22FZQBp1ZH + :#H%3&MtqR,r%!gaaZBT*&/TL\Blhd\0#@f,+f!G@SaPj5A0LJLh&Cfch[r6mE%);K#4T[\Zf`mPM>bp';&e>*u1Z7mRRFX![rp-:9TPt + XmdS>$Zmi;9:ae.E%.Aa2V.='[BOOJGhftc<,eXia#apJTQDW1FLR`!oCSS/` + (8MW\93GX2'=IKC[b.&Fk\89L!#>Kfg\N"2Cb.36`b%']]9m;,3=DY(*,/\4m<(\Ef-0(Xm + 9JDUn>Vfb?PdifdE?SdD;ATAcV0#I,emL'FQU6e/Xb+7d;Ub@i\&b6)-#9qb,U*bA^%RZ96 + gbC#YeL;(aZrIl\RT31YO!#p.Z28>m(FmAWma/7P#e93=_01_?;(i+*(8I-KSr*mZd9D-4j + Ah.n,@taY7.m&W6sdN?Lje)\S@Kktcjh`u%5^A$SsmD=ItRoN[*`r$G)PFQ=T*&Lo)?&G8C)A&p^]t^0N,Z4d + KIfpOMP9^;.Z3"Dl>n+X\$6fd+m*O]T;W*l2;4#!dS&WT'Rf%YBLTA^RnTao4(k3Me% + up^5/riYsa-`E!3jb*+\Bi\\cNmKShfMFX[pS<',&j.#@J/$F\_kNAq6P]hFC=`8p?,?O_4 + alsXh#Xg))N!nB50M:F/qe!:@jX38Rc,\QajOe$08V807%j*3(Ll1DbRqCnQ+!JdLA+msZ5 + Eb8l'#H8C8>XJ+=;J]UaRYl.ebZN1N5PaCcPB[G`iI9#FE402pQZ0V6egie;Q]) + ;>FC>r.M=hb==5fm:iNQ*Rs7!!A@1p$f^f!sD[a*k;lQi1A&G8rn1q.]^3.lYM(RD84j>_*f!-"18iLK,!Y15uO19/.KFS)Ok6u.jNb6ZlP5hb7#oJ( + k@q_q[o*?PE,]tZ-]Md:q+/l#f&h:$3=3_:olno1,4%k&hA#f81)+d#Js#J_H:Je.46#jo\KNb9i)9(ZDP8"u:"6N&U@Yulq4P5Q7fU4\fMF2.34V4;GOVioWbE4H]=_2_Zb<3rGf[7MVJtG6;Ehp*8r(K:#KT_rTM + W`EP"?L&LHoIm_EPs2Q-"",7MK<'I$oi$ZFkMD!c-*i'MLHDf=ai4Lg/Der0^(I"H"/BPmh + 2cm%"=HSe3L$"Come]@7!GfRlQEX[6%0oW$%6Kh;nTas3(8#dun4a[/ANMbL@J"EP?KRNak + :96@\&S9]VfHDfu9LQH,&BR%_IG_Y^+#I)RfUEd^1CC.AJ9!kZQY_50PT?B&I"686(d;(rd + V_*R+Pl-2"]P+qDL'fHB[\Qp>!LU=.&]K)!`Jh?%<7R_]ND/=q8F4nn4I46Vg56<+badE^e + D6^$fV;][:#Z+FK](,uR`hM=-ZB@lOBs"g>V-4pU(#pS/Er"EcQ15bV6&(:][EXpe$dcUcD + 9sU&s5qRn[M9H:Gh'*`2q9YpR-Jb;R`eP32X1= + YAN;ajL4'bF;l;8:pI9GGti\^F#t9aq78'h,&8gla6ZaK8U-4\= + /&:=QsNeeM`H;Ee(QA\[%teobZO%9Z_qNR^I4^-u&LeE,*>!)`C`f"fTNY]PN=4GM+$f0+1 + ,9j3D86<1u-e3*-J8C.Q8HB!&of>)dceL3tY=B5lMNpU:T[7j[+K%MfoQHh02lDGd&AV?D)f(kR)k89RunW#Dd=(&:"KldK`m$#@6s," + o2N%o\ZeHhmNC>`Vn](F,-E0N?E7sQu_)u!oMQ2?fhIJ89TcuG)Zh*L[G:QQ3CYk$K$qk#L + Ic+#^cm8HsiNR@&=IlP`LU@d"d^1LR&N\%Mdq&E"+,u#At8bDAcgT!"BtM?mZXtQ4Mr.nAJ + O!+)Cg`np]FQcsB#XiZ9Ar:$1G56/I:UgZ>Be*[[['lWUmB>0*5fgk]*U``\#9KQhn])(S,NP.Y'^dr?*]`;Q9B0VHiZ7";U-<$nAKFh"SgJ#H,N=#mh + NcW&C*;N@o\.:$@L^4Q5^uU"/mM\-ir.Y-rS:ci0pM)]j#GHH:,V,#B&p`7jNu:bk%EcF:? + ;K%j5+E\W!_Si5n+#bB&7Cc<^mN&7q@?kB1>7J-<''(FQSD+k+6PSG&,tF;.Z3EM.K._??T + tqIaY)oBCZjMH=,co.Hh*TjeuEj`'@cHQ.j<$:3#?48*O'6k?+PEIQM1ectAA\jM$a_G'dm_s5biVk?qs.:q,^2&e,+g + LT#=[(8>PUVY3MmfC6l)YfQW)&dK[L1L;pH5C7'li+,D\:(r%cj*s*#A1d<mI\-9^s[&ui9dE%mKV/FfPQDBdKZ(QbKf0d2WX9(#&G^6m1d6b^`3P@k2Nt + oilIX!h'LqL]]KqXAgQ@==DW[n8Hrj"Dg(noIe\T3BEZ-!"i,&1`q]#bq="%QE!H=2%fc!X + on?Mr"Xn-i0*-$)!cW>an:4l$&7:D,&o_apE5)hNI^=dEd,E"SE5r4R#5IOEFq"^k#>f,S* + t`L*&;6.nE0+Gs?Pd^S")pa6EM"6?Ii.0?Snu79C&Q4f@E&NhGm>25KSX5nNg\t"Mrn'!l, + P49i$N.,+*(s\`SQ`jrfZi6VeJ>5kt`r&QBl/9QZErqA>%<3?Rt/kNpO0KW@aq9qBKh*3:1 + nX=[,%&[lnfJ>Qq'0LJZ@hpiUZH6M'A-eSqs7\BbF'Dfdp$oS5qu*<$BmkOb*/FLYQfS(0^_#7P6mdo4`3VBjcbuZ!0_:io=b46EFnh25I + #:/kI1ZUJB%2Unq2J6a&cfr2$A2c&uSs"/,5NE<=A1qNXh_GW>F*=^/EdhVDL3I]^-#C>%S + YnNTLK&AV<;1o\p9_;0.oP]&"d/`g3dIanlGMQ>Bf[=m9:j<4toS6=e0[KK+8* + F6q`Bact>J#-Go%h"KG=RVee;O"ONLWLFgkT7,Dd`-+-$K8C@lB9i(R'_hArQIspA\h8QYL + ]k`cCk#k6IIgBoDhN?GG`;qop^_oL\BoHGVL#IOGNdF + us*FOSk4g#no`(lb7tkf1GR*,"pjQKCMZ8d@nlM-6=8/KeQat#cNr,NZGm,u.J%^Qn^8/V, + "]/$C'mkUP_MB=&FW`gL^Vu_"3Ldf6Ju?]kJNqAV^_$RN%"PPcJ8b[B0E_A0( + kN#1K]$HqjHAimd-@iLaY2;g+5'4EgARr(rLB"(3,=I,d=r3PL)8Wn\(ps)ir0KnL@AE,+B + \p,=ah1Mr[6oXXH[hbcf$89I`L[Of@kuKGR!l:l;-dG2spU1]^+4sE9Hb@=7Sp"dXD/Rs(C + m%QfJ'?.XF%cRs1[76Q-Bh1a'G:WSKL+QnBOiF/iGcKfnMm=F/Jj@8@Z^o.3^!k + 3_dj=fS'CaIPY,F[#(t&c09O>Q8d,<[K^2aYdOa*k_\E-Oi)--L;KjDoNN^1TBqcffIn!EK8Cg=-SJ:"Ba4%Um`)93?5E_4<6I!m*3:AINO]Q+.7 + ,KUQlPa&k`oA6W&bG*qk^8m.G'?C^Er4tsFm(G'r'+<699Tp180Yu1Z+Z%B,CH2bi$O#9E7 + _uJ!&^Lpm"$Mdqm,pU['Fb43^bLd[-+e25@jfWfCRZJerJP77EotWF[8b3oJ9dl`r1TY:GsU-A!C"gJS!N#D4N + <3M^,Dn4&f-K7ToH.#tR#$'d[^%(Ce=Fg<9H!XNE2Ypp`r>Rb')\oeOWg>^*=;ELsY])1@d + Zl*Z#NeY)klXCVkMMA(5/Is^.57;ltn3,U#H=07K!M880>2.FL3<]jRH(rf",jI%M9BWQBH + [i7h?Cj8P4fc@TTgY%U(S*('bb0j`KS^U@e96/ndh=W%QGq=0:F/A,a!E#c@?jamVl@?UM0 + 5C\kZs2jO(;2t?-`gblCl=EuZ`IYKe;>lIDK1Heg$[\,\JVA;MscU6mCfZVcMXr!>RiaNE$ + 1:&_s]]`'ueb76H,40S;UC8[!Ai$bOZD`G-^O.2L`5N.r@bf0)@X-;p1]Wl/%XePbea37,DqtM8^]u%WreoY^^[g9cp&2[2g;LPTnssk4L!d(,I*rE*WIL!^ + "rK,^'OZRU6pP>k"@t'`@)/:b6RE9fA6*N`/0PJLN/@ig9N]8E.5&KO()I5pUL&SCH;MQ&-h@@XX/*2F + kMWiJj^K@pHip=(>;XBoC.*1S9l#L'h%FI"68n1RFEAiR*"98Xk0.)=>*-4d_9j$nV>)7*d + :jF8n8\DNjTtCPk-j@abVDuEAknm@%BVL;ls4lu.F#$:k6^Zee8#(ML,Z$a%d`4;#Tl=$4C + _+ljkVFVPa.Yn7.o=]J&ZCB%#P7(N*+fl[k<[\@oGc#46%>*WQi##!"& + $,a'DglJRYcM0Ec&mnDXFjN$d+R-pWI4Q*!i4S;1k7Do0b=Xd)Ym=&pV9la)ME?ilA?Rf*+ + 5%$,o`q>lYr5X(V_.5CJ"Mc/SN1M2&bZ:g&:$CI5VM\$*!9RpZ&A=IVH*S5QifmX\Mc\?41QA@jRm.Y.kUNq;#e93H3k$0%MUH/jhRZ!@d1*i&7"Ee;YQ#V + $.73Epf/toJR$/.)/MS*Ba@>4?6qY-MpB1kCFe[00;?qd2quqQT]1rp:Q]DccE,!P% + Q)"XWnMM=JnNGq31h):FR"M^E<.qHm%`I:',Lrl<^h?Z5@\hnAda#N>SfO7Ia,c2%B0l2=t + mp3toT,JHKOWkZ=FIp_UAs2Xs8?gmuDhu*ND!<=eW!,r5EVE!X4i^jLO!72SaYT3c6+Ta>D + !cQ/g#g+_JK__Rpq;bTQ0I[+n5m/l1"E6p8YY>8i;$AXR"_XS2,eEto=U$Qk#&n8\Y\aU6E + $sh&9/ + !fYmh97&J6`4&TJ[#YoOGH+VHLU&of?5Yq6UY0bZ9!'6-#GYrrcj,3V;%NhBkpj+n+=Uq@g + G'k5/gnQ`^L4VfP?#I-Q1Z#(0bUtE%Yp1)naLiX,)e-gCTVMu._!/+G]HDbFWPo\$XW9.H*HBaQZ/$Gji>s`8*c^EcZ + 0`V&nK0K'AauKckVsG7ocQ!n+E@c2Z4.rI&Krmh)@[&8D%>[,N?>GOB'SM57aqm0>R9=;'_ + 447@,W?i.)4`L.G,(S9%U;nA:C]W!a7j9A1Y89"d@5]oQ2 + KNP?ZMbsT'fNC?A?RR3WlbXB.(*JE/7A95VV!J3;IC[I_9)\G_W`j!?>udZ2fkopWCZ[?RN + ddCnL[-I1V>8Y:*P6h4CP?SZ`?4[d60;94_25anFJ)Mffg^Re4IqTa=%-Bp>Jcl^E?"<79J + q&q@URmAn;ehZj`S#!'[aN6"DArM+er,jZ`$g,(aJB!ljKa.3dtR'pKS'Zog.f5nHp36hEr + =:J^6dObcLpp$1qnG+cAhMlDDO8@mKm0l/n_Q0]n3?Qc9XORLZsFa6VY"=GiZNj3kurL$WiOCg&L&Z"FSer.+%qkB;KDA&&F + i1F!E,1>9B,=$TtOCl7/#P#<+a$0_4oS&b#NH\W*o%EX0FfapP)"qDcU&^.QeP(?'.TM^ + H$1W-biT3oGgk6f-,*`+2Pr._\;,?jK)p5iG@OXRXlV<]0pF/!9'9ukS!FReh?uH1pb7=!L + $"5).14nkb6H0El+Mpf!"I:J^79D1ddNXY*C+X>t2+@\@Y@KO+7?nE:NcZggRNdP=#a'Z)/ + NY\n.:dU5Ap.m#XW]@?:K'/gB4MN8Trf02cL!De!S/Y%KBhJilrL7:'Buk5i[>DITIb2d&c + sIg@2VoXGr?9ctgJ62h<673K4OD + BI4)dm4.QlK1'Eq].p"JXjMTn"\0_h!biP_ms.67B\X]SItb*/R*$i0Y^Tm<3_CL3REe\85 + !.18MA80m>^#`,U48Dh$:LFc0!t,0+$l.!G\?pL/MOW;7G)U_n^M#8jEW%+@N#CPs?IMg0i + V_W[59-j=k6hdbrN,0*3*-q'`r'R8;h\DiJo15D:^_,=R7e:+SP1jbq:)r+DN*eN`M-. + :lHAk+i.WL/`.2U;fR`?]@/aH-J-E&bKHki + _!F^\<;-]AqrT6^7)\bsG4$XibqTDAg>,2m&*^dcicPZ6(6[#7Gn)'\([k,D/"* + M615I&DC0-ca#md0/rB[]qCeZ@;5H:TNg=ga>$N0?7@p5&KuTjacB?H$'i!oT>h"AU["]cI + D-IM)V<+$7Uhrfb`.VOR,(R/%VP?\]8T%rE?+Plm\ui"-m>!8(LO-5%$1R>(S0E%V/8cj[M + S`E#.L`+;(5C[\_@eokHoei5Pu8^q+r#XK'AE4*M8],UP?6J,$[G[R]+)"A&V*shN8 + j(c)\]&;_a3Gm"pr#`QBr;QSj``o,CrWMT_YX + teso-EVUn[f673Sf@[*/W,%=Xm$ICa*Xh;8g]mJGG[5FeM*PL-rP`pPI@P7$9',q!%qEmc.^?,J2d![kf>RD:$$W-0,Z^ + 0F7J]M1c*iO:pFPe7p9UIHIuNd29d!PE+]?qr$\2AMiX=:`W#hhtoR3'qZW;9B + ._-nREW#7d4K:),hoC4$g/'+U2&`hOBF.F3=j60$)0j(#[RS"W@',&Yu0"(pRkFLX;nG89s + )]X`?I]HZ*Ub7fl[*BhmM5pfS`+nOU1>sj?V6RQD6/%=jrHBa6LOD6bB=fY@g2%W7%pHI`V + SFt)drAW+%4-[b%/t46l(rQSe.Be:b/8gB!liV!4$od0eg0IM.]rg#W"jFYQ2a+Er6\!?dW + %2?9/NVg*cP#po?nRt_QltXCV&Z42=hi2K,'eVD;0C^4-?*&7]P"sTM#/8CQE&T + r=c*19,MN*X'S^)c2"T>`t(iYSfH+OS:3s4eh(Iat]pU?UJE'!*t8Y(]e";Qk_[l7?bE$W> + ]2>4T3K;SL%=2u+;TR9-OW+sMPekAM#"mpA&FKB.Y$]]/s+_DTNS8&?;rl"=+G%.3/=nSNY1(.Q + U3mSh`n60V,/mZY-BdCJfD^pU67=a@jt(fNlTZ5+M_!R\(gFhRYFBI)jMI,YjiS@ + dSg!P#la_,*KkqEss7AFpI]j]ON>9_T-EH^"$CJ&"L=RmZXGIoZ\_XQ#rUM%&=_U6%+,E1] + L]5nortXa1Yh1q.?,ds-`]Y:<"!cgOC[K(?+iE-/Ff\8j_LVeq^EiJYYs^/t$YY!6b<3`B8 + OJ1&OA,o7-:RG4k)VPCgc;4+Xn!%!S)2ND8=kQE22/#S[aT"_5C+n!RR5TsY#2BnoE!tL+m;,ot+@tbPL(_gEM7jLhidn(b'bpo@(`+ + 8mB4[ctE*n0EG3*@o8q@Y"%i0@5'*pmD'5;#EZ@j8E2SKr?8`>U>5ulqgfn`nHOQ1QpSFoiF*K?KcAZt,j=#3/U!%D#V@c\@sI,tO(7ti + 6]ko)-;0P+YAKg(g'\nCQs^"SA!pq/DGQa6q8RH:?].?l&811GJn8V:TE6KSkY^$0=OXOD; + ebGl_5SPm_03$iqS@6T,;L0eIG\2Y_M>s]T#u`o>=ZD]8:(Ga2h + oD<8oAA:\EokN.gS3Rm]tdaPSesg2-G*Z36a(8?ZG*U'>ubUZm)RVlT- + 0rl;A48fU1*Ps,Qd*3uF]M`&WRIn.u\/\Zh^YnMV;p%]b!#O6l(+2S`lP%Q`N@?s46!**,A + J:LN"%i>k\^aok=6pQB`F`aHZU6]:;RJ!PR`'#6kXT@p5,!kc6+e]JM(,1uW3RE@*+]8k2K + `,*eASc>0`#"/ief-u$E=QF,4,8h*mZ5l5b1pbaHu;3B\KZA2@T6!WNodJba&)j;kUDCCG[ + JF1#1S8+Q#Z*i_N1B>(h$72+\:ZD&2B(]@ebD3Mo9b"V/S]UZ6_p"'j-G$R["Kf%0SuB57j + Ki+Ao^-)s;Th6-p\PdXi\XjSh0%=):[nA9j?$<_H#00d^G\S!/OI+-m1ab8->5P`h>24SYL + hUN"MDKod6Gn..'PJDM)lL%M7;<-j[)C/mp+Pr, + @6Qb>TGjB\b8GbfNY8/9s=B-Jr=Z(#:[fJQo85Mp\Lu"r1_6fq(KIn=G%L:O + 9eP'HYP_2?O1lP<:TL3u3TYY36NS>"Sa$L[[&Ue!0`(&?Pd[731ilbJO0kP7PS$S4A:VH>2 + .&s,7[$I#Bc-^D`/Q#mZ[^=#(Uk*!Oqk4q/,\(&!"rAl=$5$>2JVq'jBo7aV[6kMW)Zg-j/ + l;t5J>NDL7oUlkNcmf3O]O4(/!3K`FY04k'sR\BO``+BbR;*;abF&LW2oIN%- + EK(dk!$m[=\[IME0pYiT(bD'0JX@"o6A,8i\b*OKjl#m-@6k563])E=OZGg[?B\0=P/h1J0 + rB'DS(!gM:DFhbR1([A`;4s^C3;A`;7n(abseUn+aL.l@`+;]!jbpAH4%(-?E``Y;eCr@=V + hp8csck\(buFZ\7kFA7ddL7B`f[iWTq + Soi]r(';.`r3Y4Ir%+$6A%:QYjgGEeqM`aa$(Muhb9pOYj<-<.9+X8@),\RG)]b2SW + ZY[&Bo?c(DQ"G=9GfSCkiO+L1kG@^?Upg3StL_YEfLonDM%#k6Nd\_GLY[dd%Iu9Si=]7ru + pHNP.p5Qmh9LJ-g#g(2K]Uls54*=gb(RP%"=N-XH,sja;QKY$1a'N+u6*RqaUtI61!TKRuK + gC]-0H2hf)*tG;!&>H(Js7I".:LITO]R(P5KRJ!oqXOXeu=$[m6Q29pa3Xmc7[@)hBf-MKZ + ;+D_\\m6js,50EX]m=fI2_`(1KY=tck6"qskn"11W*:e8O)@AY3"WXscX5mA2=+>N2Y,@H( + V`)8h+OfiAO,.M!\#[4pK5t-0'3i"kHe3-6Z>;iPcT*)16]O!cg=g1FXL`1$Ale_`m@mZku + M^+r?OWZ=8#Xm%N517CcZ>h]TK`ZpD6O3^g10MG0(PkUO`sZ=_]O&W0F#\PMMkjOs4E`R"> + ceCt7r3H5K6SpqZ5t->SM5_qE)J[k@??X6]G,$/#TLi8]bW-4Lf:b_gkH1<`^I=(RlRi3FE + ts/M`/,q6BmHdCbj)EO"sCQS7Df**082lWOtjT]:-\blZ@q^#ZDe#)jqY, + fbfi$M\BQg/?hf]J\mNuLK)@t]ZMt=Z:%e,apCn'jG4(@CJ4$@9aoED*7>J$]h'/@M-MgWg + l3=Bd`m*N$R4`/6a`8MHHFMYP*uW,`8410hZtc"J2C:E5eDrkO%P4Zb1M3=0cRb%^V;QdcOC%S>m=,B#7==?Y7(S'g*6^:,RjVVd)pTjn^^H + 3It[J+#TKUr<;dGsY>6$X2.OHaEaI)(3R!S-%_W"$9CR`S;:2nZ%Cd%B&?`tp>V`60\MXgo + *?nB5,>pL]:lOd7fTshHT?dB\;Mn*YPE:=\ql%B'Z4iRWP;*EU67@X[dg;ErM^AorJq:SuN + b[gI/H%#UHAkB<#Z*k:S?.:d):Fd4;p@I(h$$QsD,?ml,W$O%m$H2_6QtBn,\2?c&1SSKPn + oc178Zg5]"p!q:_&Hb#Sd@c#V/*d#s\Y]eI>AU*E#H[e'nP!eOn&bN1disWmSoB^)4.#F[F + VY>?/@AKp1.DH:=^(,]K_U<*ZcKo#RBX/T8 + .I;5bg+fq>hdY2Ad*HG45F&c4Q8[WWk=Y!OCh$?&5&l=Z:BS-RVCsTVCUmU?\Yu+$AG$"Wm + =:Kg@`H93JJ_2t1f5W:"+O^W(3/B%`=2JS[FbNpdMcdZO=N_3'oa019NEGu^=K*b$TRo,\N + N*/0f8te/d*ErIM@63Z%98Nn"e&SrRp!>";H5s6opf1Ko%BEZQ.\g'Y`7=\JXE]#V+?Ks+k + YAueCk(u>)fLbSZ3lFN^_Ki>-4n63lhIc\d0U$"uqNEJ:sSDDP3pt'bt]nrM'W5CP]rGgBF + ;WU-"pRLPR)sUgq/q[BGB,[>8X@a3#9UXbtmCL^@o+Uh.8r&E6pBEnH?JgkEY%=VTXn!$lu + pgs+)Kh9He+5;aH.>j]oFBj4fSBNOklg/Y^!NRLI]>Zib7fg(-jd#D4:JR*e^>AUNK^kb.8 + Js?n*?1tDO4c1-;b9Nj]8N:Di4,'K\OL0FCX#j&\S7;`SHJJH!8cM:c&ToB>+_^Z[]Lo + '4fpkE$%T-n4ROU02A-0kg3>7jTkfnbI=+FfD39O2pGLhi5^%ME2&'4Ele==ht\7M](=on\ + `7?\S.n^l+0Ek*W[>M>eHM:&0Sd&VuSTO[/"6I@$rW8Vk@N@&\)iXchWKLY\&Ci$l=q5`"< + 5U]f&2=KT*]IJ[>o.UG0!gO9pu*\q4X1CIe0@m2bXl18BJO5SrTinBUME/*9+_2+rc@#0P! + pn-PBMV8fP#_j`5(+BN+h.--fih_s+NSOj]6jYHWPmG(g'uC41=n_(+JS/"'Lb=bQn::nrb@HotB$QVJ2L/c/Wp"&bC<`43Pd$#\X + _G#@.ZGb!7^(c/FbhAu#[M015+^U`X9a6XfCl`7\;B=\$jj'Z`7?$p#-!J4X,%g&A?L:Fk- + sY/_cSp"R@_An-H"u2m]e$^#NgU(D6<-FJng*pet.q-G`5[p6%B/2A9`i?-ie)qQ>5P7CVG + ..W2J>R5\;(7?A=d3m`KCLgMOW/m!CMqmSRi?l^cR?g'*Aj?GL($eV8dOjrg12-7e2T_2<, + $OVj_VfS+,?ent-IDU.WL%F9g\B^X]8@(o6>NkgHgc%cR]gpRCm?H[52M/,6FO\h%oVKRfV + cfB6s);a'S*K'4_o&&[U(odmRhWsV8")pI-:hH2RI6ggLmFABCcNW8A`fJj@Gi'p)k]VU\D + A`^l[LNd%'t3610(k2.#L<$%>Cf@P?2*h0N2J86A"\le^AmZQ_MV1MS[T/pQ:Y7E(C5d,KB + %Ztr_2a_rU>jnE_duR46JT3Z6(88j)3Cf>jCN6Tke=thPU$OAgU.GgMk_8muWI\-MiPNcZ7 + OTkCAOu(F&7=)i@CK@0/Q#7K7DC)/E:unu"Wlh`aK;J>EJ,M,bpC-PZ1=kobFmka4hWTShE + B'3hu'nW*\:\BGu%V;^@ngA$Wh(JBT*\r@KbAMHjj:6Pss\FhK)l!UHM429QIbgt-)>?=/) + LsB=0+nJb[F+6Q"hd1Hl+7a7TDZ<"CNtcW,?ZnG(l$$Z]?Y4It]Ppu>9jH7+CtEiSCD/pDG + /%m;hekrLX6bm4p?uu=%rCt^F*Bij6+rgkm:Z/hG8T4XpO@I4T6`VdFkXlZpTJu\5Buq[Is + :pC2Xb=(%tYJpIeYRLGYa#KpOW*HLNn<)G`R\Z7u$f2Mg3!qGgD@BT8NF$O*L\dGn6$(095 + iMPBfBWGu'\dhide?kl^]i"8FU)_p\@YRJF%VH,#nq\"7lkT)%99H4QZp+.rB_TmAYlH9\6 + P:SrG.Vg;^JqJWnEHN1/F&%-b&[X3M3 + qiA45QahC7]6g`oH`+Q(^V0LMs-C%6$;eabXKgqn;W`HV%Ceb]N)`FH2VCtA_sgK + uW4;IpHEJGMVESGCDbpf2qXk"bX[#E7fP--P_QZ@r^/tH2WPK0s1q1>eXDsS'>Se3W/#l4e + ^;;o\(ldQW'g4CNZ*E?H6?WfPL99?,k?9\)$IrS,N'dHc+44S#^@\-?=oQ+ugQ;(I+bDl?# + )C5/11(g[0334oXVsKWK!j3F72*Vq(,,H[XcNLWANJqL*hMJ&gaFqu2(YC[q8802($f!&+r + U&HopH>T!a^d!QuB_GHaO$Gt0&0atrrgc5k^d/60@`).LG'#`0[;&$c="9ANgBA3.`0!SAi + )TL1;E?*"rgj's]dJSPhM$[dsU+6Y"+0/!)D"UmQ=9DPkdMhe,99Hb>8Q9(X'kc%m\NA>o?,Ze9 + rK2dSubd9%)5&0Xf8^K^hg`6cCiXe5[M\$W(X"\O4b%/Ql-)eU:k.elA8T>1V6;EB-T\S=O + !/"J'UAfN'#KVGM8L;,g"Y%?"iOepX6*g/acDC>.7PZ#&/qh77F@Ps(=Mflm&1Eno80d<+2 + G?.jDWf6uV&hH-0aE$(3i@04XGAa+[$fDYf$i)h$,K&G9F&VT+F>8)?:8(Jh`9Gh@jMW3:& + 0oY-phDpVVf`"0u_RHrsP+PCt`iIS\m.!g2=aje;AWsbOREiu&C]J'#DKD9/fuAN4kZT$aU + ?L;pOI>0t2GUogQ!15Rk1OpAWp81'HO+C9`AUk7_a_J4OddE)=_`fM\#Zc<9H1De]'d>;k1 + ^akZL$i,h6h0*hYFnSg\l&G:tO50MGXFEHiqTF\Okoh>>l!! + dRs/AmqGXXplLUGOj6()^e+MpGrh$%PPlAC/\bht2dIdBE?eP.M2E\HZfmX1^qYo"UcMVOt + fD1_T/tA@Z[ncr+d+NrqOd81DYgqXQpO@,S:;?NN!)oZqIukL`^kFiOT.BYgd!cNm(duGPJ + qR9"mLd='<1i)_p2/%7E5N&Y]1 + o,)I6anop8&&g#(P-QQTRGEaiE+-63o-<[lJO]"jQ82mRtS&C)&nNL>S)20d,,&2>#&AH#< + M_aF'@s0Vml+5;dVW=hm:Cp'1'6\ELB!QW2"TDFreF*DF*7^QR\m.4hRgkoNk>(E1?I%dlX + tcdrKG&npNK14QInhRX%3)B0&te5*'7VG0_Vq:2!>mRC$:Z;49@3d( + ID5cMbXXb!ekD/-KOFLmgAK;b@A=S!jhPgs!RE)Xn;$7e'[)KWWSNb<;;k]d.nD+3BX8`!i<\QB2bjJ<[Lg=2i#PV6AbA;Q*k?5 + fXMB!lNDs9oTIR))b"H-+cg>RRO-Zl1YuSai0%DG1O6%7W!,O]t7&5oU/qX.s + 1&FZ('uA'nXSl]k"RL#%8C=?D> + @BY_"XP`Zfl/fjslAEkskE6@!.+_fR5lffS0PI,nqBc";("lJ65=@u8aB\F5BKe&=CmmhPR + u(fEn5ANPa+N"*[^G83KgEI8)t,cK@'RGruWm0XU[F7h[X@f]AaRmaM.ptE%26@4`pP`I1. + @gQb;eXH)?_kYE;A@Pa0RrbAlXGPr:;HP)uEa_^tc+<^N!f5U713UT=G97K8!p2+`@4/Do4 + %mG9P-Q*^bkZNgkBTc<8iE-bg%KRQN=h."NQ/cQ(IC"GQSrleU*c<\bNR_oWQE/A!#eD!kt + FaHYV$j>])Q/S*JG'rILt.Y*W"dLZ`K#>%'Opm=(C&W5NTj!OT`tIjiQPio,M,\!!;e.h#p + I:Gt)rPThB4&SUUt>cGM`)=mP'W[q2QuhA + FD3f]V21u\MNG4Q\"jaL"%i";sJbZ[1nT"c$PGslh=buPFf[UqSr$m)fpE!0'h!!-\_'H*G + G)B;rToLHKU.FAoJ57i;5@9^jA;fp^Y"!4PuUjr6NJ!3j[^g]%HQ;hoPI'X5*0YQh>dfR + EWO?P"jE<"p4PL.7^VnTJ&g9>-LrIo"pmOJ*1r$INHe,kg/m^io^n0sIOjA8+mOQ-gb$78U + 7Y9n)q6=CC%1ac,s#S?tU01N1hgeQ6)$aElBd3qr3pD)(f@5+ijk6DAi)]"QZ>75UlM+!J" + DC4iS^0sdP/+=Sb:6MlBp2F4(%]\>[`>*t'LPocj,'OO4!,Sp#YYA"2:$T\jb10-<)Id1\k + pVInfW>Y;e*U9W&N]2Bppt-a#fTFQ`lAo!kgg;h(lQ[cZ&X?)-Q-ZA!0Cn#,&\ANT,M^LMU + ARS;6q3^#d>g<'i2:@WQuP.D$-\7*26j]huJqFe8gSE%Di&6ncl6*4rckMB;J@K^UuFmG+j^4D/\ZT@M!smD"d4]P/aEU<`>e5]cr,%5Be%k(Cpq1L + PNgEl#dij!:$m;&X,t+#RN.nE/o[mPJVX3o&BHM`@<'ZCoUg)ZIW!==DUII1*VE37Vm3'65 + Qsu&b>BK7ja2$4X:UGWIV3R_+g^sP%P)CSNs26,ChdI`M6E;\YA2cAifF*d + +-I_7HS5*P:re*\i?l<+^;$SWYe'E:<3"$ffj5a2XA`>LBa[m9R%6'N#uq1IG,#6^0Z"_P9GlYZKq48]>m@oM7mi;ajYe7?h!7e+R,XN,[_Ea:qoLe8IhkF%92R + 7u0YNe7.BgY\HX?2fsC;e;m08P=\`?8VRUB&TL%PVaPVt8X)q@['*+:ZV+9,99d"g9H7LuK + 1j_79U*^oeB^i'dT!8B_=Y]@<8UFbj%`S::6b$6F@/gQo1r?[:R(`PeG_U"lr>mu:_a@7eI + PLl'2_aF.*.R#7JAN:),aH^;O&b1eLsQ1*/*m$;\_AmeN["J6W@#,;anY"F[oFH;cQh!IZ`YD4&+Cu9 + _0O]B5^dVHBZWf;g(W+ZCnsXb[I,VH + \R)\J(,btne\PU8`Xu4o>kPr@edl&Oh-;hq"ngt`Q1c.4+tZ*I@[6Wio%<0[WuN:;e:+G@Y'gsekW'290W + Yc7LpH?Zinu2=GLMi%:8V>W(&O6SEGEc#M\W@b1cdokd_3#Srb-B/`j,K%2Pcm3Y0P"4q:! + J+\R(s?r!S9G%0'HTKHeP)g>A.;n%,TpORQYC`6B`/ + O>/=f8k2$drli6%6)E]TNcg\UNAiUG@7h&[sfo[/Ug01HXWat\%ZJ+O;+GCB/dsB2pZmu4* + j6HJ'[U5\)\1Rl$J$2I\q1;(\hUorEt/#AXCaIU>(4%?n3'*B/dI?@b$%,D1U^!B/eRsGUn + 1Z0mp?C/GJgi\%RG2[V%ON&E;Gj``[u3fl=N!K&YHSAm%[!]7n7AK>Q.\V!Wo(D0OWPG@K< + N!1%2_Sh7I$;n.E0Q],P.?&6]iAXJW4Qu5j4T8D0>MDo=.B+TiBM0/DrFX%-L#%riq`Hc'. + H(ri7pMY77fm8>AHIoA4pP+qWd>d9kIohk5Q^KP;m<7+cI:CfV\)2MkfnPk/I_sQdf>2r]j + cJV;JjS.Bf@=lnomPGmIKJ,RQaMBRd?=7qHm70l\':,h!`'X;/U0&Qij4m3B7@@")H\#/=< + Wlr?nHVH;n+E55gt8#R?o7'Lq"=W=@JSO87pLqR!$Z/R?*&Rc%otERA/)^->/7Rf8Kk&RY' + (WK^kG^I>nqt4i57/H'sBgdtlo_S0HLRAFH%_du!kB"5(phL8UT:`K4XmNZulBH0QtAmS;E + Q/Xc<2\>>a!rap-DNHJ0![3&>"$5ja?#b!iMg-)3>O=`c_UmaND_)\>.V@-R$#_;ZG_V,RT + A#4^JVLmNL>$7WLX=P8WV]%W*!lq*fl)122V#`TQ>$5`pfqoo%VKuu/RW#*t]rFEK)LAH_H + @@DKK;`3'X+K%6]"b3\'<,/HUtTJginA4[LT3YRWg^&f]!*`S\#Z7VX5M1&2S:W1\.UiXXT + lJ@>,El4f;N^l/GeE?2G9m8l7KU?YCbH03d[m#VCc!UVn33cg4uYS&Z".rY<'4mH@d_?0;s + 4BZ?i@GEBYpWc)$mb/XF#R3kd2WMmN7OZm`\rHE)&,5IBr+/DF1#gK6%R>Ru-`T-D[k>'mU + Xe#/X]UcWT;4*JXGf=0Hu\3er[>D\32fspluVckTM<q0H8c[ + gY]^aj1\a\^74H&g[Dlro=nN(^RP,8g],&/"2J.H^mkeJg^h4@'>[oi_42I\g`OBQ,Jm\5_ + ON-ngb6Pb1W*HV_jig+gcr^s6c<5"`10K=geYm/;oN!C`LL/OggA&@A&_bd`gghagi(4QF2 + qO0a..LsgjdBbK?.;QaIJ10glKM:!'gSe~>Q +Q +showpage +%%Trailer +count op_count sub {pop} repeat +countdictstack dict_count sub {end} repeat +cairo_eps_state restore +%%EOF diff -r 9b9a2497757d -r eb146c5c05a8 0__Papers/VMS/VMS__Foundation_Paper/VMS__Full_conference_version/figures/VMS-core__internal_workings.svg --- /dev/null Thu Jan 01 00:00:00 1970 +0000 +++ b/0__Papers/VMS/VMS__Foundation_Paper/VMS__Full_conference_version/figures/VMS-core__internal_workings.svg Sat Aug 03 19:24:22 2013 -0700 @@ -0,0 +1,1010 @@ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + image/svg+xml + + + + + + + + Green = VMS-core + Blue = application + Red = plug-in + + + + + + + Physical-Core Controller(pthread) + + + core_loop + + + + + + slaveVP + + + top_VP_fn + + + + Shared Parallelism-Semantic State + + + + + + + Switch VPs + Switch VPs + + + schedSlot + + schedSlot + slaveVP ptr + + + Repeated for each physical core + 1 + + + + + comm_handler_fn + + + + scheduler_fn + + + + localMasterVP + + + + + master_loop + + + + readyQ + + + + 2 + 3 + 4 + 5 + + 6 + 8 + 9 + 10 + + + Switch VPs + Switch VPs + 7 + 11 + + diff -r 9b9a2497757d -r eb146c5c05a8 0__Papers/VMS/VMS__Foundation_Paper/VMS__Full_conference_version/figures/VMS-core__plugins.eps --- /dev/null Thu Jan 01 00:00:00 1970 +0000 +++ b/0__Papers/VMS/VMS__Foundation_Paper/VMS__Full_conference_version/figures/VMS-core__plugins.eps Sat Aug 03 19:24:22 2013 -0700 @@ -0,0 +1,365 @@ +%!PS-Adobe-3.0 EPSF-3.0 +%%Creator: cairo 1.8.6 (http://cairographics.org) +%%CreationDate: Sun Oct 17 19:38:15 2010 +%%Pages: 1 +%%BoundingBox: 0 0 116 67 +%%DocumentData: Clean7Bit +%%LanguageLevel: 2 +%%EndComments +%%BeginProlog +/cairo_eps_state save def +/dict_count countdictstack def +/op_count count 1 sub def +userdict begin +/q { gsave } bind def +/Q { grestore } bind def +/cm { 6 array astore concat } bind def +/w { setlinewidth } bind def +/J { setlinecap } bind def +/j { setlinejoin } bind def +/M { setmiterlimit } bind def +/d { setdash } bind def +/m { moveto } bind def +/l { lineto } bind def +/c { curveto } bind def +/h { closepath } bind def +/re { exch dup neg 3 1 roll 5 3 roll moveto 0 rlineto + 0 exch rlineto 0 rlineto closepath } bind def +/S { stroke } bind def +/f { fill } bind def +/f* { eofill } bind def +/B { fill stroke } bind def +/B* { eofill stroke } bind def +/n { newpath } bind def +/W { clip } bind def +/W* { eoclip } bind def +/BT { } bind def +/ET { } bind def +/pdfmark where { pop globaldict /?pdfmark /exec load put } + { globaldict begin /?pdfmark /pop load def /pdfmark + /cleartomark load def end } ifelse +/BDC { mark 3 1 roll /BDC pdfmark } bind def +/EMC { mark /EMC pdfmark } bind def +/cairo_store_point { /cairo_point_y exch def /cairo_point_x exch def } def +/Tj { show currentpoint cairo_store_point } bind def +/TJ { + { + dup + type /stringtype eq + { show } { -0.001 mul 0 cairo_font_matrix dtransform rmoveto } ifelse + } forall + currentpoint cairo_store_point +} bind def +/cairo_selectfont { cairo_font_matrix aload pop pop pop 0 0 6 array astore + cairo_font exch selectfont cairo_point_x cairo_point_y moveto } bind def +/Tf { pop /cairo_font exch def /cairo_font_matrix where + { pop cairo_selectfont } if } bind def +/Td { matrix translate cairo_font_matrix matrix concatmatrix dup + /cairo_font_matrix exch def dup 4 get exch 5 get cairo_store_point + /cairo_font where { pop cairo_selectfont } if } bind def +/Tm { 2 copy 8 2 roll 6 array astore /cairo_font_matrix exch def + cairo_store_point /cairo_font where { pop cairo_selectfont } if } bind def +/g { setgray } bind def +/rg { setrgbcolor } bind def +/d1 { setcachedevice } bind def +%%EndProlog +%%Page: 1 1 +%%BeginPageSetup +%%PageBoundingBox: 0 0 116 67 +%%EndPageSetup +q +Q q +q 0 0 117 67 rectclip +% Fallback Image: x=0, y=0, w=116, h=65 res=300dpi size=399300 +[ 0.24 0 0 0.24 0 0.327072 ] concat +/DeviceRGB setcolorspace +8 dict dup begin + /ImageType 1 def + /Width 484 def + /Height 275 def + /BitsPerComponent 8 def + /Decode [ 0 1 0 1 0 1 ] def + /DataSource currentfile /ASCII85Decode filter /LZWDecode filter def + /ImageMatrix [ 1 0 0 -1 0 275 ] def +end +image +J3I@:BHu(:pOk^R:T.dk*=mro@So+\<\5,H7Uo<*jE<[.O@Wn[3@'nb-^757;Rp>H>q_R=Al + C^cenm@9:1mM9jS"!dTMT(d8$g?t7s\'HOJg#PSPQ1`C/mioWjnAY&^Hf#!Qo!:QLNm9ApfKo@"^St*EZ$@h7Iu_ + dAb*B(hHM_+c/A3_/KTg;O43>N3c+5)[@l+5FLs\BULUaal`3%:o*cVOQKd#X?9bX/(9N + ;hHOZZn_7?NO1(WM6kAK/XoKPq^J0sl-?a0F-D'h>PLB,o"@,_I111+\T;ajP!l-d!&iT.% + e/>a[.cdZeMs92bu*/kbcJV__#PoP$$N1M#)o:%M?)+j1Opk9%o(KO6Z6F4AYo:,E+N3D]7 + S$Tq2Sh"*j$'D3;6:imCW5#QKF,=>9a`@jVR['[;:;RD-F8Q#.+Ki:rn"\Vipojq&s7-Kf$ + _Sb_TSJ.XGc#m=DQ0j!,fG4pM@G$ktNFUWW9pK;CQ>N1*g(o[EC"elTX_ZZ,c*_ECQL2A(g + _UF=ESQm4c#_\W:"=CB22WBi.$5D:LW)d^m3UV:)/KAQu + 3q"iY[\%M;jo*/W8X+c8CUAR-m+uj;AFrOlVo_9p=ZV20BS3MB`J*?BIu]RHBp?D4B]+c?5 + ]@RI5KqkSaqbU$.ptNMGKY>YUNWW&A%=?FiV&WToqTXfLb+cF'e?RdRkmll-E@V&u.7m?bb + [L1RW,Rr7&kmMh2J\aGrimCVg)-HTDpW&bNXT=`DQ_=3sJ%E%]U:DLk=Rg/S?A_M=UIHiq5 + /^*`*cS`u=SF8VekhLIRaI]tm.CJdg:K>s,Zn9T?<'.)e.H*9*nCCaIe-\7FN!r32`ri`XH.(GsdgeY.$ + ZN6DTr0]jokRPTMT:+4j4ac9.h2]-09KUJ'UN)D+P3geEYTl[qT + a*H\dkFA*2PM(u=3MSd*S;2mH>(TA$QR\IdP$W"*KJ2U*0VZarX&X&?7G$-7>\9M/[3j*G@ + )1E"fa>`WOdDV%4i64X#;`Y=kc)Pm002j9KL3]X!#5pPA%8-\UE&mDd4k7Z*m]Yg07cu@.%UZ]2rnYN^f^!Nskos7i&o"P=A0b4!)) + @67XM=JK<'3OZB0d36OiP=-f=Q^l=7C'\;0)c5.RT/D1`1[''2[Unjk + Q]!o)j-W)(R%$#\0(b^1#8])BIq:*tH5$EH.CO5%e-PSaU7\cU2n?BAE>kZQ^a-A.o.0N== + VlZo_]a#].D_S"nb6NsWBJ6g7j8IIo.XdnPX.l.CELfLW7O?M$UK$O0]r6X + L50_:r.L(]WUGHFDe_9HtlFU,^2Ec'S2qA^/V3@S&IpX]"3ULu3U&,W3`n`me.$i,K>o&X:ouBr\Y9FLBZd;T- + `"bRq20;/*9Nh7W6[3^EL?(?r6<;m[/,h([!uF>j6e.YtlE%2]\(jdH7_gscEJaU#RIs + U'^p*9.lV)qB_nDDX+kG=RH!VNY^:W$<)ZT/ok==pRJ3W%RbMnWHAZu[-%QZOed@D5]FU`H + 1]0&4>h,/R=*[d`U,Z"kDjf#SAk:Vn1d$LShPV5%XCjQi>o\WqqicZ.Y]SA55X=ns)0eX;#g7f&Uejf>!MrW3 + nql&fWWRrk9En?qQ(dCG>,Zdq5cXQr@/k1s,6^+5?P5KU\6C5&AGmIfTN;i7)OKs^&NEbms + HeS`F],J.!!a3:1=aB@*^`cjs:#(o'nBf!N&?b93>OfNZHIq!i$5H0HBX:l2V?l?Orn*%7F + OkieHmXs.BAdL%(f*neg + $RfunjmrU_!<c*e2r, + nb2E*DnB7-Hc*6bkPuGLN(iWmB$BH!>#f)fdLtScNmls2ZooEoM;:.7M-6P&HpEF?dWCkcq + P6%6Pf2Wngqel/mAuA?MI=I]$WXY0m_OcDZn.$$ml&U-1Me6!q58')@sp;L(t0=D\fU%)Ng + 3]Oab8hK$\>ZfBgqnYgjU'^=CRp)6f^e9g"38lsK8kU626YEUO*O]c(R/n\tkUW-%sb)]s( + NplWG!/#;a:JCTd@LJ^8YX]#S*D\\!*i95M(7K4&s`<=HK'SYu7m&q+!OC+r\f!,/N0+'Eg + >_b&(?a*5P;>eT+#6#'$LTQCT`Uo=QjNbaQ+#4tsOq+l1JJ`Ac(p"Sln;/O[;%EqN->!DAn + lfF!QiI[&%Z,fe`UPEkfdd7!,"SaYL%cIA$O^qea0LsQbFGZ8 + QZpOH,(ck$TsH"-Htu'(V$`[16*Z/1g)N%N&TY[#))_?df:>Y!g>"]a$=Vo+HYaP1h'Od_? + ARQ1<K`1+@ZdbP7KT + [Rb3es?k),F;T&PEk319AkAgkc0!-npaXD3h#P1"t''1-4T^kuD4*/'JPGGq@L3Bj?..SB? + ;nkIOeNI[74=h(,Cn2Qi4Xh&t5-sW?lG5X-1HlEf5#N<2'Ce=E"[H]d5=PSBKDtGjb7h5.1 + _^6^oH?OK"[L'*!Y'Ze6%)*D,.(J9os%T^csN&l>;a)uotalj`E[PF=f48_jn9R7e=[-H%L/t7Fi + drIj^*)o?FB-T[=DU!]3b1+?a]i>p&S6;b]@k;bg=^D&;;`KV-XFL`g.WRp*!m'-";$H@^[ + jtp+^&82.LeiA%"O1p-E4I7:^R5A@>3Cp/,BZp4mfoB!uPgp2O_'F_>l + CB=<5$p46l'qC3+82lDG2g:Q[YK%;CNN0UQ-`l=fg41*=t"H0( + @o0tkAI`s@94)R[e>JWqJ0.2?ZfdAe'1,^Z#/]?EVC0089o32Ys+L:^%WabL]VBo.UQ0CX` + V6/2bA(7%#5W2FK=)7FgbY$)f<'#\X-'H(FI*6d][]C-s"YVQSCdm1hubE#FBbM[r@HE\TD + p4H0a.-k\k\mZ#sXLE&V3OVR(QWXLn5$?ak5uQc?QpYQ,KHCA55F$RJHQo5I`uHoGYlpM51 + -Z[B6Z"h.uk9='%jg8oLQZ1j/4"A^#'%rHOVG!J0FGOp=mQ%,-CHC'tM99k$/;RrJ2\a5Ls + %*LgmQ%>.*I0Pa[=>7:Q-sp'%Kf=E:f"$EF_0tG6He+O:[[Va>T6%MJJp0J8G=@#5_2#(RK + 1J@P=:2Ff%m"oqKNDN8p\np[;2C-kKlr$"bP@$_MhW#CL.8q4L$a#m7UF[OLH$?1=Pi'k2 + (5Vi^4UOERaf[iLWi4-:l,keN%=q*C5G]p*VU'3\>R5fnPq5KZ^\T1fc + RJ<87(R&#>cZ&[\Rk#AFfV=t[':IF2D"F]'(=ejUFc@`)-e[!]q9b"Dn""a5FVp0>o;JkgD + j\)uS>M@=g%K$Go:$X2Y8Pu63:3;?a**m[B\F&lVGX%3Z_JD-T=9B@\_E8=WKd\LRV%>LqD + `#s23%H2U"VYV3^KJXCI)+@P$/6=`i#XO>%Cf'6b*5Gu%JWCj + e$-SM2TNMbj;W@I8c':PuuYqegLWL71ob."AU/ZM*.XKa2e5s)2.rJ_^FBY(<)o5M`i%,?e + c?.&;"/k7n[AL6qm'3<7`Bdi2rL=/ePb4<5*V/YEi0;uD(IbH0!)V^jiSmm`ji@*F>dn(pj`6PM=&BLKE- + 2TRa$J)Z/Z!1gI)f"Fc+#O6-\4HY0P#3s^CUWUP\-A#$]2#MU;K8)CM>0Z5-E3s+K<=]"l: + E]B&Y=ciI#P:+?PAT`'.4_0h72S8,YfjIL'bQWk37mAl.WX^]S4e7&fV + f.Pd\u.+oes[*KU&9C0SbdcW8Ihgsi1j&:o0>d^^H[U(NOd_oR82!WOZI[c):(iq!rs/X\/ + rCgg0Y__0ZlY2@.P5n?E]`BXFmHZKmpe&CmIa,T`7W-u_s0dS"%\L;gU=ZaWM_iA@Znf?P.^^?A,mQ`4c + )>P8[nb@Tra5AS`>kY.k]M\C_9.)AV>&Z?2Z8I_Fbt1YS+l$94h3;'qoo>'b$>jbgo>+ZYGQK,]@b6S=Ja2g/^@r^s'\^<8;Y + &D9tl$U)Eir$I,Wb+jk7=XaA.`J*Eh(cD'4s0!Bmf&SScsC\^r1+f6P-,H&7Crp"2DfSsiI + 0jrFV(C6Dkf&P_f*nO;"Tq'pf,!I`oK*OX`uD!?;hfWS#qL&p1pH.g__C7W8t>>`f##KkjJ + ]Nlt&g-nb"e%>S1?2]K+rVkR?8sc+70YNn)`U>>&n\q#N,OLW6h=Mff>M;imjD_4Zr9j&\= + il&FjrF1tP8i)d&;NC`j1ZXZ4ihADc/Ug>5(8H*Hc4Y;6=@7b!)1#OIV%8?BAVFg^SrsF^& + crWFmMEolEL6PqkMZT\6p;4NP<6Y#.`^lNclJ,Bc`T%g#$r(kBm%Cl5i0_rha(mSLbgT`dO + WLIAc0IpW3^(n=?90rlOYMs/uA9?eg$cruJf%JqlFTE*hYoB3jr&O7)OlGoKo=*^/>kA)7. + *c2RkF*jt\<'AH)-faT4_S,`&>J&@!GI=B`-h\5.,!VX8dLYm#/^N*]Q(E8,;oD_'uT1!AM + 8OiV$b<=OqR]H-de+L&P&ERUq<(^"%gW^J#mGpP+V4?I/f>+R6fJ[pPYNYBKd#IfB[]R6(5KZ#&'5LE8G861AJ + .MNmTBFS70f"nci@9-O%ndNRE0]"1RO4N<#QJ5B*G!JO-H'',l$>r6sVYcKhWFbU;7sJ#c1 + c,7t9,7K\I3d]fB$El\jLs7]+Nh>O.MeKeeudV`8E+.]$=P=g6Q=<`lZN$!aL*)`X4]h[$N + b@'UXe?/E+/6clBNmGl\sf/9f@lBkN"]oZ*Sq\Fo_788]`[g$a)99A83.]jQ]K0(?Hq+5)F\T0+jnM + l4>BYnMN3ro_o/1\eWJ]@)BrDef'".?FVU0r?"ea225l&+WoG + gRX9T%PU]8H15pF>XD%`Y^!b[VM[EMR@NTPD)G)`3PKY1klA$:^2Skt4M*\?XgukdkL3P+= + n%Jg0n*nq%;_0sA_E/>t>X*j_+%X0BX=d57Nn^Mb;D.Ej1cY/8F3PeT+/1E%bp:1tm?[`QZ + 3,bi/3K/3mhZf6$`UJ,Gh4.t#j4L^:U/G?nJ81YCD_fDjE6IU&<4&7`=aqIQ+&aG8rW%H29 + PrIqnlJX%gI7D^XB[VB55SM&>`Mq@]Y,4k]&fC,cnKbM%-rT=T0A)K2`@o19CZeA6Pd2XJf + kZ0rVGX:/P)(a`lAK#Np'MUEgFDJ?Cf2$^RqK!,MPFm9(9/X]Z+$/0EKp*\DOaMESH+Gl8C + KSKEcp$mGDOJF:JnDpKl;_mni:t;JNAK)dM]H;Aaa]E_q'JatSG>R'h+1&T=X'\bK8k + sKoqDn"ApMC:cf:rU+.ZI.iX)5im]HPL?q>GHK4*B__apeDKZbl3kdHG&/(6foKd+hMd^;O + M@dbbFOR@t3D"u#%K4FdG;Re9Dn_sp + *P+CCnUM5@YN!6.i3WNWQ_@s$FJN*+M + 3Zld3&((:p4K+ZVu&`13OmY.[AIK7S!-'+id:!$=$F,-RgdO(DLqc6IL\n&>+>aDaJ4b.2i + &jF>(SnIK(!ep.NqjX:foo2HrIKEN0d]qs(A>:U1FcZM*,Z`_6fS(f'dQ*[Z8#mXRpXKb#"Pt*XJ8ek31Ni3:SuYeh+!Ja/NlnM@?SW;#9#Xt&dD4!sU;/k1J,O%u-:OQTM[8'HOG9Ys+]#]1btHp`p72161(J5b + U`&Y$($=pN0d?7-[lP`,ekYW.goU0DJZA.hoT=_=EM#rlqH[0Jk)K_MA=I$(^#)ik'21785 + >=#"BDQ'\/H80jq&;5SCN(oFU2m1LPe@@U$?@62J?/nM5h)'k"'2H"B9V3JET,A7tq+F+?H + ,goJtGBiXK[1QN:iXCoY_ZaMS$u/0F.F[ob0FM;f3sn//UmZ*d$p?s.-\dH)65:_@\`&$,[ + U+IiSp8G9O/R'VLK&j^Qfu[!/[Y'3a_#0V.=EIQca%=aLZqF1I=&/_o[M>.AjWJu'5b*1!) + `$<;]`hU-W2e5`6o#VaE<4f2&0jlE[kA[rAb1l4R0eQ4@CE^&Z.FeMUq)(/r5c!/6!ID]gB + \=#d%I$b_!B'l:C4kZ`]c1*Lfd'rGZWh_^P3[GI3dtip"'lT:c3Z&Cor?e9"P<'uGK"U)ud + %XcTPO<2!=XW48\(14lkmcqg,U!hdAE@J2I6dG%VsTWOn3[l3ESX)CXJbH,SkhVM/"I,;"0 + /r19_(Dof@QPMa&73tY)d&\(=DD[iS&pEA42Zme6"gA<2P`8'Z.^3*`GdEAtWS+Q`IHqLD, + *FkfTrEhJ/WgaZQ%6@']&$JF4H2/$O]c%[=^=/u(g$(ZmtKG,i#m&,"`\Z!*`> + >p>UP$`oKJY&58Tko6t8YBgm[l'2+pQY'Iip%nRf,_T)-M,1's$PJ]^0:\=NsdM;3m5]a3" + LrL>1aICMr*:^?B\o>h + nDsa%dg#W+Aq+.Q3J@J.64RG+kk!4J:%S4\7^\bidETUpBTP>73>.I8m#e;j4/bE(G;/XJ0/V`X68R?72peo-":/?kr8mOg8-[heJ`e8Fo + 9IX5NdL$F?i%DHp^2Fgb8IXPB4h<8;oe#/NDaS,WZddF.Aq`g80DhuF#Y.Elor`\YFgTe=? + %--er6,pU:LiP6W]*OE8Xp.514d0ALI)N>ZKKA7fIAB4bX[sHpjM?2K$1-OSIW#,bK62-Td + W@%l,(;$Mpr&S-I#c\H\%b!$m="'T+Q6UN(oinV/ZJ=RVsLt_3$+ds^+kK=6s.aKH+5#`r: + @Y5^@MR%H7U9HoI8rK58PeGKbSdOXcVrtnqjo]kJ/bO&JGta!]Rd.H*DgSP+'lT:l%<&M(4 + FN$EI:$fV^r14sjcgRp'GDoA^*,j9`^%Ru73Kqo$!c`O^]AYS5'eU[8l)&\DPq2r!pii?uI + QadeP@P^E-7YjXBbF,ud>%f>36C\T?Rq(*]A.#]/qo62YcbR!_J]eG:!Gm(I!3P1+bYULtc + Y^aMgQ'5VQ^[)uK^s>@k0YN*'-p^\/$,StfJjDqs^/Mq`A/BgWOI>uXZ;_qPK3>AL*lE(F5 + ,pM/.NbpQM)UqL`(F"*JNQ*3?$=L^>cG7k5$PXqSoAU^*49,LI#kU;?=I;C,kJVnjSUF4f%`b:&k^kK + &c0IO*2XYBR[&PBp]kI&\'.\$JDqPqEEFh\j/`6a"8*)<%;-Gs5]2&ogbg/LS+P_tA3LhO5 + Z',3^a7M1!uPjr]?qXBV^1.IDb&1C!V1k^TFI7-oZ,FT_kgg7E'&Y1I7*"65p(lLj6V7:$4 + `^@!pK-WXB^;q1r_##smqb9JRlaYH3`Oq$5HEY:qKs``i%8:aK]99,@"=5T1XpfJDF3hM?O + $YCn8m9t?an!7uU'Sj_4;4M8o7WnJ@m4^l5Fc:V4D$JJ=@Xn.6sNtbCdoBAC']3&%$[@,3_ + W1M'?Vk$8j&tDXLfK8?^jHDb+n%1+r@gg]=MC*5'2t1lc2R`N^=uo8Y_9g,asT9)p9n4_$qW:nb5D2I2"aStl;6]!`pkr^(tHfH&P^4Yc= + A$e5aO'kW3n4t$D"s%fR#oQ,9RO0E.VHudnkl + 54;OJBLZ(b+6e!3n_6gWAG'_=A^+?MG(c6/k"_A#g#S;Y$>5@Fdk\Cf57bX)1^UfAg;I4A1 + /4:R9#)>J!rkZ(R[5Z@nC,OEoB/AOPo*m4-te!qX(jKSuDS&YO57"jWWU[X.KmRg>(;hX#T + <@1Mt(8l3\3s@%]bu7V&S^90BVKupO!8p`5o@!Jt97X32Lp954&l4[eMfS=8Emu!R:/n=me + G>J0X;KJVA6)7Be(PelC2(i/OKIje\8HciN&b+>6Fk*/$$=kiRNMgnit9>On$d#D/[bGj1RqO:HTg-H!H>cq7AW)cW<+_@>R70l9R7*sbg + Tf%7%fZ@<=cW^"H:aN*74aL'rU=Pg5A]mJHj[TnAI78Yj4IE`3i`n^O?3pk$3?" + Z,sBWqZU>!:8qZ:RT%L5N*!h.Xl8%GG+".,??Q>OALr9cmZW:+%XG0+r@C,fSUBDHX!Tfu4 + fb7HZ2gh&icU;Wrl;[Hdi.ls@co!_j+iVCPK_$Fko>'ZiD`U[A`\DC5 + Tau/s$Wbtg:TGok/hq25lmJgP_H/K,Obt*4YH+I5P_91T7\W(!7$/l3<@#bh-.GE^Z>N!0.i6:[o*T"mXf2b'.gr:"9WS6;X)e$k&iB^UT< + :=7,Md9$He$MDLVB',+^>['W@Tf71iDJS,#0fQ:eUAYINV244NSt'g@bH6?<\@kWKAplH@Y + A2mX!-)rA)WDjiLSNSc7iaR:?(t,A!o[D&Ph@3O5i(diiL_].@K2H3b/O7A!TDk.2cX#:1M + -Vj45#QV@I*9L1=fPj>KUBSjHtj9FY#j'])7aV5fhmDi\],@tau%5q5JhHr?]r(,TV:fG0S2@NL7(bYu + f7YoPpZte`t\H\hpNaHR!^?:5#B9ogf(;";+\^`%0ZMPIUDGbb@:atS%d##p;QCD<:%RB>4$QO,"6>$[d%H,iI7HbdQS0$d'@%99sXQR6D)qXC + @)XNf'/caIbHT;3EY7fD7t!051:b=e/Lm&Lj42_CP"MWGj^T?>?Z%!)*1kOd1;Vag0Gn*S> + :#MB9Sckfj+FsVW3m&o:bm=Rm,rl:1iM*&*kD]<4KP6=RKCAgd&m=:Rp\n0>aDq4fdt5qB-202b'hfLgKJP$E%bmZkLD6(")9\8 + hd3RK!74;8&=riiZZk^Db\]-$Yan<0)c,t2G$ee5oTXA.1qBf/rMe-^FIk,YZX4m4Y8Dko/ + lF.X\VlR.e4_7nhOltG$5/Y$$!)u+YlOW!4'SjlgGc?^n`fFMIgYcQS@W[`Gk.j2`SFa>[A + Z@:+o3FUXTgU3F@f)#W:`$UJ:@_T'_?Dp.J=UpkJLDBg8e-m`.>J^LLK1.eZYEDS2\8rD'L + 3;%6l1#]BA!%jkp1f-*(i8-^Q!HT1N*LG^mCFB:=,03K\cMXR_W(6]U.EWbs\V\bjMX^]T* + OLqVbCC:"_1&$)bk>)@d'j[/T+C@>Vo,f]j?[-"*NoJP)l*Y['KpS0^<0'D&;PWi:hGt2BG + cPZU\:o1K7U//,Kg14q%u#;*70PrbYt=F[m?D2ThnH=?p!o<7GtT*)h(-E( + 8BsF:akBOqb$=k3h>mp0As?%fqG[9.WnlHS9:0"QXY6Suh*==f5iVG)T5rND)bT[hl+>kaB + K/n?o#47&OS`3A.Q!\W$,86q6VAEsVUbeG:kQl2N&kT8LE%Q0 + N2m.&k+]1oA*!Hp:7Tj4sT,R_K6SIFh7Er!pqn3;mc]NKhQ]'#/gEe9m@3 + GA_#?\V'h&*"0C_6Ss;2O4%0jK>G3X<2'nD"Xa1[KfNt + M02L.*>F+lq&')bO*TInO.3pVb&<1O@;X08J?Eq`BXq-dg=Y#"_1V7>'*7m.bipVGh3YpbQ + NX9r^]b[ZeAA6 + Fh%8-CV,D\.rqMOZ<],2nRd/m[,,j#S\JgDpg+JV[A/MV1[^lJ[11\W9ca)UWt2H(m&[oKr + Un'4d:E0cbeKT"jFm@^+"r!p\,6/NYN[hGTWk,*q#\/]U5K.=-rM2UTk]^qW2`DQdgDhnRn + Bfpj$VVs^($#bVSC:&g5Wp^)W^c\d9@7_s`0/#up+_lMQ,qS*U5oRo"gd]BNBOCYg7/s0+!.\nYLRXn'$<7%>WBgVn$Y`=VN1sS] + 5U689M1_A7qW&-8\6Y[hma,c&CY8#,lr5o"5l5ZuYQaAS9LX,L^.#5d`6t&]enX<;nUe,B? + QmPD!Cm_bNCRuSso52B[*5o8ss!jFn4:%?-"V9L!qu,1JT1%nj?5D$+ + l4dT!@mT+AKj9=4(d"W&SMrkaDj^/A2.eM_>/,h:fTXiV9N^tGOA".O7g?(,7Bp + VNZq`Jd?"bgYY:>oN=dYm`H6$\W\YWkG[.XhO"@+Ht8F#MaO^nD8'p#]=a<3aFl0T + 4Q[Pc_quug:'DCX^b!0+h[gaas%i*!43pj-LSU@gi+S_9MM0XUVFkBD,Z3P[Oa@.(u__,/+6Lr1/]TJN@]2sX + r7,Rpp7>*MfC:HNXZB9@BF,=5p#_nO\8M8VFr&@g[Y5/ndrsV)6\tN;sSRK?4 + `0,j(oY019sG:$KVPjnJhC1QClD2oQHU4(NaqFt8(KZT9J0oq'XfLs9Y<6)N!/S!2i^1'^N + =BHo@(Z^uc1f>o\Q]/o?29+::[pA?$87>X/_96-sS\.s_ce]P3Qu7E767Isd<^ + 1<.U.XJdP`0U!+3!qsQ_Y:g:E>0Nb'6Z=Q]-Z.Eun[IGo2.Zgln.rmSG03Pk!idfRGZY(Wu + Jj/?h7GC9m69U3Y",8loX51CTliq(b=HCP/*u-57X")DW04-!mqZI(5t)IHI&^LNKVK9\N= + ;B[mWeZp>(=g+H(a.;qC]5c<$Rnb_N%3^<5:ee\,;1M`P(Y(n@;M62BFfK!bXWM<$c-$8KS-[iE:M`ABZ + rFKm%G%\umZN`6VsMecYW*RR.]>Jbp."_kkY;@AD.Mb8G,uZ1Q:3S2ql)gbW0G5Rd1P2EW! + FsuO2Y%OjZLr#FPZNEXUg)@c9mHLd0S+S7.g"**_1I^H/YWRX7<;=AK6UA@iU,]CH_+MpW3 + J`jBk"<%/%EE2[%IXkC[[c[$C3+/EZ%KRmC\?7N/W-@r=qO)K$#*pD517_uH\KNi;NTIWDr + fG_L:=fsQX&>r"QmT+J!>Z?dI2kb&$QO`$@MkBRQi\as>'qaK36EIHYRUUbM`_`-M2_fOmu + q8qIYff:^EdJc/<(;D*Fo-]gG?=1/2o"i/SlYc1j"H(R4NIcI'[IDl;pugBt1V@(doAbVHi + 56YS4IHp>Dr6F8+!i%cUnQU,[j?=CPD;4Y^@Ar?d$:`fgrUYY1-[%er(i\Jrcc]`\c^NkT3 + o=ac3*cQ,Gf3PEV2KG#l;JF#Ul.TWdd)W25pB$:W1dr./_)Po5-*ll]/[IVTj&IGiGV$!X/ + O@/gA28JZ&)>:?^DmbieFqhQP@BO4H9Bpf&]nWCpjsV,FINW8Om",)ebe$iL$c`qSZg(T*- + s:9Ok@#6hssqG:5uU*BjRAHIH/R`%h]L.MW3G6:Rq#>g!r&3sli7+^p%XRG-lmgf(F')-.8 + pTU=fOMW2sVZLaPs00`PJg+&EKPD*Nj^,ENFCt#Vj4u,I&.&"QO&Uf\"r-5-DU3_M%\"Q' + ,':*nj/'L51&`@P)^*QM+7]uuiXI&E,:%g7j_'Bk0t;0oF!Hi#o?lE&n`$)oC8HlnWQkSUA + f1cS\GW+.IY9m3l*GX_/k5*piHT/Wu.hd\MYn??">]L@ + $79"`4c)"Y!/?-GgcQkUA#64!t3r-VfdFC)\52&0/"P)m]Jt!QQlilEi5bMiY17#44$P0TV + C:ogc$J$_I,Yq#>&C%1tHA%:'h7raN,riT!,PmPbG-0bap7'MOQ%O/h'C%M=l'0k)djY;-E + j+H>t<`%rho@K/+30Q49`1Ld='%D+MR$J#]2!Rg7=o'Z!Cgdc9rXY1$MEebD$VQKEu(R(g[ + $K!iIg_9:j#'7OA'>PQ.`sSk*`Y!7"d3?%3-Ta-*1Yk5eWB4h6n8k2pe"ZA2k!hZpHZ)(U=8'%ZlMJ)nNc?OYRtc#o?`qiV*]8bSs1B4ZopfKWC + !Sr5r:G`;q0.c7n&>15OH8QZs-!k]gSj!7.Pf$1\X@\G+(6R2,nil#N&"MVaft%6$!E)1m3 + a'I7[D,K(Oed:LuPii<:aD7oZ$P#>[pUZV-%Z8dV7`Z_3ad3D6a%=]Dk(eC%Nb^7#bR5;^D + Qo[Q]*@nd[#:;nYVM3gr\%nRK(:W1^W[/Wrj=\gK#6KZ6''QC;Je0&-f;:Qad'dHUV-W63[ + ;UmF!'f/cg2cGu';q4*3'gkr#7oYaH<7OcE'iS+4=&kMi;;_a]"9/i]O=PHZ1Kf\'sh+E[p,-0>LgJn'u + O9V`dUlp_fa(,("6Ggf3OZr?.Ih=(#rO+&C/_q"V^D0;6jsdj'Ga_?e,0a('@rF#@NhK>gK + f?'loWkEn92hJgGEWbAGnM8OLmTc],YVA8m,L'Pt\Gd7hSC` + 3"fLKLs@R!p%8An"lYM3sG^ps"T(S.bUiLq(ujR&Un]GE*Mr`rcj-+hs&IH]2(J>PRrJK6N + >Y!JX^N2gF#;Qs5S=%>82Y?^7m*8:_=p_A'O12IVB)'u]eInF-%O!VnoZjF()+a$19jI@rPp"L6FiBZ?/X?EmP?,m]q1k9rCR=_/ + Ddr;[),ZYe$^%0AOnGo@,+k-cZ'F"#R.*R"3BLET4otJ!P]a[(U@jcHI@=ogP'+U1UD8t1N + L!_/06rgf3R*mhfpu8m>5)@ABK&R5*+>Ii083S0o!g,=51QF[ + B-).k>oBj9:+PrYC'3ZS-EV4o41Ie*6.@Q#7\VlH2dWnOYW)RHGrN](H7X'39>)T#!3AiY1 + TXP2"#KQ2n.n#[M_X!-B'"*P`SkH3J(WhJOX"*P_HpTE6H?eW(;])/]th5k*$XLe_?g=.iD + Dm:5JY$1(p]$IP\jf_k`Z9$76j(kssg*Z[;-Ta8h)\b"g)71=+2eDrp]"bFWi\u33[5t_%3 + h:S[I=G?d[bG`0#q;=TF17Wc\&ITW':hEnJ%1u+\A_U\2RFQ1QaXMe\_Eaf"*dcIRR[L&Y] + kH)@J$e!S%G0%]A(*5)oK&+k)tUgKpV3 + 3p^YAe(*!Q +Q +showpage +%%Trailer +count op_count sub {pop} repeat +countdictstack dict_count sub {end} repeat +cairo_eps_state restore +%%EOF diff -r 9b9a2497757d -r eb146c5c05a8 0__Papers/VMS/VMS__Foundation_Paper/VMS__Full_conference_version/latex/.pdf --- /dev/null Thu Jan 01 00:00:00 1970 +0000 +++ b/0__Papers/VMS/VMS__Foundation_Paper/VMS__Full_conference_version/latex/.pdf Sat Aug 03 19:24:22 2013 -0700 @@ -0,0 +1,31 @@ +%!PS-Adobe-3.0 EPSF-3.0 +%%Creator: PDF2EPS - BaKoMa TeX Portable Document Format (PDF) Import Filter. +%%Title: ..\figures\Proto-Runtime__mdoules_plus_plugin_plus +%%CreationDate: Sat May 04 20:18:38 2013 +%%LanguageLevel: 3 +%%DocumentData: Clean7Bit +%%BoundingBox: 0 0 612 792 +%%Rotate: 0 +%%EndComments + +%%Error: Can't find image + +%%Page: 1 1 +newpath +0 0 moveto 0 792 lineto 612 792 lineto 612 0 lineto closepath +1 0 0 setrgbcolor stroke +0 0 0.5 setrgbcolor +/Times-Roman findfont 30 scalefont setfont +0 396 moveto 0 90 rmoveto +gsave (Filter:) gsave show grestore 120 0 rmoveto (PDF2EPS) show grestore +0 -30 rmoveto gsave (File:) gsave show grestore 120 0 rmoveto (../figures/Proto-Runtime__mdoules_plus_plugin_plus) show grestore +1 0 0 setrgbcolor +0 -30 rmoveto gsave (Error:) gsave show grestore + /Times-Roman findfont 24 scalefont setfont 120 0 rmoveto (Can't find image) show grestore +0 0.5 0 setrgbcolor +0 -60 rmoveto gsave (Hint:) show grestore +/Times-Roman findfont 24 scalefont setfont +0 -30 rmoveto gsave 20 0 rmoveto (Open the file by Acrobat and then save) show grestore +%%EndPage +(\nPDF2EPS Error: ../figures/Proto-Runtime__mdoules_plus_plugin_plus - Can't find image\n) print flush +%%EndDocument diff -r 9b9a2497757d -r eb146c5c05a8 0__Papers/VMS/VMS__Foundation_Paper/VMS__Full_conference_version/latex/VMS__Full_conf_paper_2.tex --- a/0__Papers/VMS/VMS__Foundation_Paper/VMS__Full_conference_version/latex/VMS__Full_conf_paper_2.tex Thu Feb 21 23:27:44 2013 -0800 +++ b/0__Papers/VMS/VMS__Foundation_Paper/VMS__Full_conference_version/latex/VMS__Full_conf_paper_2.tex Sat Aug 03 19:24:22 2013 -0700 @@ -52,12 +52,13 @@ \authorinfo{Sean Halle} - {Open Source Research Institute} - {Email1} + {Open Source Research Institute, INRIA, + and TU Berlin} + {seanhalle@yahoo.com} \authorinfo{Merten Sach} {TU Berlin} {msach@mailbox.tu-berlin.de} -\authorinfo{Ben Juurlink} +\authorinfo{Benjamin Juurlink} {TU Berlin} {b.juurlink@tu-berlin.de} \authorinfo{Albert Cohen} @@ -68,9 +69,9 @@ \begin{abstract} - Domain Specific Languages that are embedded into a base language have promise to provide productivity, performant-portability and wide adoption for parallel programming. However such languages have too few users to support the large effort required to create them, resulting in low uptake of the method. -To solve this, we introduce a proto-runtime approach, which reduces the effort to create and port domain specific languages. It modularizes the creation of runtime systems and the parallelism constructs they implement, separating the language-construct logic and scheduling logic away from the low-level runtime details of concurrency, memory consistency, and runtime-performance related code. -As a result, new parallel constructs are written using sequential reasoning, and are easily reused across languages, and scheduling of work onto hardware is under language and application control, without interference from an underlying thread package scheduler. This enables higher quality scheduling decisions for higher application performance. + Domain Specific Languages that are embedded into a base language have promise to provide productivity, performant-portability and wide adoption for parallel programming. However such languages have too few users to support the large effort required to create them and port them across hardware platforms, resulting in low adoption of the method. +To solve this, we introduce a proto-runtime approach, which reduces the effort to create and port domain specific languages. It modularizes the creation of runtime systems and the parallelism constructs they implement, by separating the language-construct and scheduling logic away from the low-level runtime details, including concurrency, memory consistency, and runtime-performance aspects. +As a result, new parallel constructs are written using sequential reasoning, and are easily reused across languages. In addition, scheduling of work onto hardware is under language and application control, without interference from an underlying thread package scheduler. This enables higher quality scheduling decisions for higher application performance. We present measurements of the time taken to develop runtimes for new languages, as well as time to re-implement existing ones, which average a few days each. In addition, we measure performance of proto-runtime based implementations going head-to-head with the standard distributions of Cilk, StarSs (OMPSs), and posix threads, showing that the proto-runtime matches or outperforms on large servers in all cases. \end{abstract} @@ -79,14 +80,14 @@ %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% -\section{Introduction} +\section{Background and Motivation} \label{sec:intro} [Note to reviewers: this paper's style and structure follow the official PPoPP guide to writing style, which is linked to the PPoPP website. We are taking on faith that the approach has been communicated effectively to reviewers and that we won't be penalized for following it's unorthodox structure.] -Programming in the past has been overwhelmingly sequential, with the applications being run on sequential hardware. But the laws of physics have forced the hardware to become parallel. This trend will force nearly all future programming to become parallel programming. However, the transition from sequential to parallel programming has been slow due to the difficulty of the traditional parallel programming methods. +Programming in the past has been overwhelmingly sequential, with the applications being run on sequential hardware. But the laws of physics have forced the hardware to become parallel, which will force nearly all future programming to become parallel programming. However, the transition from sequential to parallel programming has been slow due to the difficulty of the traditional parallel programming methods. -The difficulties with parallel programming fall into three main categories: 1) a difficult mental model, 2) having to rewrite the code for each hardware target to get acceptable performance and 3) disruption to existing practices, including steep learning curve, changes to the tools used, and changes in design practices. Many believe that these can be overcome with the use of Domain-Specific Languages []. But such languages have been slow to adopt, we believe due to the cost to create and to port across hardware targets. This cost makes them impractical given the small number of users of each language, which is specific to a narrow domain. +The difficulties with parallel programming fall into three main categories: 1) difficult mental model, 2) effort to rewrite the code for each hardware target to get acceptable performance and 3) disruption to existing practices, including steep learning curve, changes to the tools used, and changes in design practices. Many believe that these can be overcome with the use of Domain-Specific Languages []. But such languages have been slow to adopt, we believe due to the cost to create them and to port them across hardware targets. The small number of users of each language, which is specific to a narrow domain, makes this cost impractical. We propose that a method that makes Domain Specific Languages (DSLs) low cost to produce as well as to port across hardware targets will allow them to fulfill their promise, and we introduce what we call a proto-runtime to help towards this goal. @@ -104,7 +105,7 @@ %\item The modularization is consistent with patterns that appear to be fundamental to parallel computation and runtimes (\S\ ). -\item The modularization cleanly separates hardware oriented runtime internals from the logic of the language (\S ). +\item The modularization cleanly separates runtime internals from the language-specific logic (\S ). \item The modularization results in reduced time to implement a new language's behavior, and in reduced time to port a language to new hardware (\S\ ). @@ -116,7 +117,7 @@ \item Part of the time reduction is due to encapsulation of hardware aspects inside the hardware-oriented module (\S \ref{sec:intro}). -\item Part of the time reduction is due to languages reusing the effort to performance tune the runtime internals on each hardware target (\S\ ). +\item Part of the time reduction is due to reuse of performance-tuning effort spent on runtime internals (\S\ ). \item Part of the time reduction is due to using sequential thinking when implementing the language logic, enabled by the proto-runtime protecting shared internal runtime state, and exporting an interface that presents a sequential model (\S\ ). @@ -127,21 +128,21 @@ \item -The modularization also gives the language control over placement of work onto the hardware. This allows application information and language semantic information to be used in decisions of which core a given unit of work executes on. This can result in reduced communication between cores and increased performance (\S\ ). +The modularization also selectively exposes hardware aspects relevant to placement of work, giving the language control over placement of work onto the hardware. If the language takes advantage of this, it can result in reduced communication between cores and increased application performance (\S\ ). \begin{itemize} -\item Similar control over hardware is not possible when the language is built on top of a package like Posix threads or TBB, which has its own hardware assignment (\S\ ). +\item Similar control over hardware is not possible when the language is built on top of a package like Posix threads or TBB, which has its own work-to-hardware assignment (\S\ ). \end{itemize} -\item Modularization with similar benefits does not appear possible when using a package such as Posix threads or TBB, unless the package is modified, to conform to a proto-runtime interface, or else used according to the proto-runtime pattern (\S\ ). +\item Modularization with similar benefits does not appear possible when using a package such as Posix threads or TBB, unless the package itself is modified, and then used according to the proto-runtime pattern (\S\ ). \end{itemize} -The paper is organized as follows: We first expand on the value of embedded style DSLs (eDSL), and where the effort goes when creating one (\S \ref{sec:DSLHypothesis}). We focus on the role that runtime implementation effort plays in the adoption of eDSLs \S, which motivates the value of the savings provided by the proto-runtime approach. We then move on to the details of the proto-runtime approach (\S ), and tie them to how a runtime is modularized (\S ), and how this provides the claimed benefits. -We then provide overhead measurements (\S ) and implementation time measurements (\S ), which show that the proto-runtime approach is performance competitive while significantly reducing implementation and porting effort. -Next, with the full understanding of the proto-runtime approach in hand, we discuss how it compares to related work (\S ), and finally, we highlight the main conclusions drawn from the work (\S ). +The paper is organized as follows: We first expand on the value of embedded style DSLs (eDSL), and where the effort goes when creating one (\S \ref{sec:DSLHypothesis}). We focus on the role that runtime implementation effort plays in the adoption of eDSLs \S, which motivates the value of the savings provided by the proto-runtime approach. We then move on to the details of the proto-runtime approach (\S ), and tie them to how a runtime is modularized (\S ), covering how each claimed benefit is provided. +We then show overhead measurements (\S ) and implementation time measurements (\S ), which indicate that the proto-runtime approach is performance competitive while significantly reducing implementation and porting effort. +With the understanding of the proto-runtime approach in hand, we then discuss how it compares to related work (\S ), and finally, we highlight the main conclusions drawn from the work (\S ). @@ -151,13 +152,13 @@ %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% \section{Background: The eDSL Hypothesis} -[[Hypothesis: Embedded-style DSLs -\textgreater\ high productivity + low learning curve + low app-port + low disruption]] +%[[Hypothesis: Embedded-style DSLs -\textgreater\ high productivity + low learning curve + low app-port + low disruption]] -[[Bridge: Few users-\textgreater\ must be quick time to create + low effort to lang-port + high perf across targets]] +%[[Bridge: Few users-\textgreater\ must be quick time to create + low effort to lang-port + high perf across targets]] -[[Bridge: effort to create = runtime + effort port = runtime + perf on new target = runtime]] +%[[Bridge: effort to create = runtime + effort port = runtime + perf on new target = runtime]] -[[Bridge: big picture = langs * runtimes -\textgreater runtime effort critical]] +%[[Bridge: big picture = langs * runtimes -\textgreater runtime effort critical]] Domain Specific Languages have been around for a while [], and recently have been suggested as a good approach for parallel programming[][stanford PPL]. @@ -169,58 +170,303 @@ A style of domain language, which we feel has good applicability to parallel software development, is the so-called \textit{embedded} style of DSL (eDSL) [] [metaborg][stanford ppl]. In this variation, a program is written in a mix of a base language plus domain language constructs. The syntax of the two is intermixed. A preprocessing step then translates the domain syntax into the base syntax, and includes calls to the domain language's runtime. -For example, C (or Java) is used as the base language for an application, and custom syntax for constructs from a user-interface eDSL are mixed-in. To test the code, the developer modifies the build process to first perform the translation step, then pass the resulting source through the normal C (or Java) compiler. The resulting executable contains calls to a dynamic (or shared) library that becomes linked, at run time, to a runtime implementation that has been tuned to the hardware it is running on. +For example, use C (or Java) as the base language for an application, and mix-in custom syntax for constructs from a user-interface eDSL. To test the code, the developer modifies the build process to first perform the translation step, then pass the resulting source through the normal C (or Java) compiler. The resulting executable contains calls to a dynamic (or shared) library that becomes linked, at run time, to a runtime implementation that has been tuned to the hardware it is running on. - language, with domain language constructs are intermixed with constructs of a base language, such as C or Java. + \subsection{Low learning curve, high productivity, and portability} -Domain experts are familiar with the concepts expressed by the custom syntax, which makes DSLs quick to learn, especially for experts in the domain, who are \textit{not} expert programmers. Embedded style DSLs further reduce learning curve because they have relatively few constructs, and require no new development tools nor development procedures. Together, these should meet the goal of a low learning curve for switching to parallel software development. +DSLs are generally quick to learn because the domain experts are already familiar with the concepts expressed by the custom syntax, especially for those who are \textit{not} expert programmers. Embedded style DSLs further reduce learning curve because they have relatively few constructs, and require no new development tools nor development procedures. Together, these should meet the goal of a low learning curve for switching to parallel software development. -A well designed syntax also, simplifies the code, modularizes it, and encapsulates the major performance aspects. Simplifying reduces the amount of code and the amount of mental effort. Modularizing separates concerns within the code and isolates aspects, which improves productivity. Encapsulating performance inside the DSL constructs removes them from the application programmer's concerns, which also improves productivity. +Productivity can be enhanced by a well designed syntax, which can simplify the application code, modularize it, and encapsulate performance aspects inside the language. Simplifying reduces the amount of code and the amount of mental effort. Modularizing separates concerns within the code and isolates aspects, which improves productivity. Encapsulating performance inside the DSL constructs removes them from the application programmer's concerns, which also improves productivity. -Perhaps the most important productivity enhancement comes from hiding parallelism aspects inside the custom DSL constructs. The language takes advantage of the domain patterns to present a familar mental model, and then attaches synchronization, work-division, and communication implications to those constructs, without the programmer having to be aware of them. Combining the simplicity, modularization, performance encapsulation, and parallelism hiding, with congruence with the mental model of the domain, together they should meet the goal of high productivity. +Perhaps the most important productivity enhancement comes from hiding parallelism aspects inside the custom DSL constructs. The language takes advantage of the domain patterns to present a familar mental model, and then attaches synchronization, work-division, and communication implications to those constructs, without the programmer having to be aware of them. Combining the simplicity, modularization, performance encapsulation, and parallelism hiding, with congruence with the mental model of the domain, together work towards the goal of high productivity. Portability is aided by the encapsulation of performance aspects inside the DSL constructs. This means that the elements of the problem that require large amounts of computation are often pulled into the language, which isolates the application code from hardware performance concerns. Only the language implementation must adapt to new hardware in order to get high performance. Although such isolation cannot always be fully achieved, Domain Languages hold promise for making significant strides towards it. -\subsection{Embedded Style DSLs provide low disruption} +\subsection{Low disruption and easy adoption} + +Using an eDSL tends to have low disruption because the base language remains the same, along with most of the development tools and practices. + Constructs from the eDSL can be mixed into existing sequential code, incrementally replacing the high computation sections, while continuing with the same development practices.\subsection{ Few users means the effort of eDSLs must be low} + +What appears to be holding eDSLs back from addressing the challenges of parallel programming would be mainly the time, expertise, and cost needed to develop an eDSL. Because the number of users is small, the economic model of the past doesn't apply. For sequential languages, the potential user-base is in the millions, but for a parallel Domain Language, the user base may be only a few hundred developers who will use the language. + +As such, the effort to create a usable eDSL needs to be reduced to the point that it is viable for that size of user base. + +The effort to be reduced falls into three categories: + +\begin{enumerate} +\item effort to explore the design and create the eDSL syntax +\item effort to create the runtime that embodies the eDSL behavior +\item effort to performance tune the eDSL on particular hardware +\end{itemize} + + +\subsection{Critical areas of effort in the big picture} + +Across the industry as a whole, when eDSLs become successful, there will be hundreds of Domain Languages, and likewise hundreds of different hardware platforms that each language must run efficiently on. That multiplicative effect must be reduced in order to make the eDSL approach economically viable. + +The first category of eDSL effort is creating the front-end translation of custom syntax into the base language. This is a one-time effort that does not repeat when new hardware is added. + +The effort that has to be expended on each platform is the runtime implementation, which includes hardware-specific low-level tuning, and the tuning of the domain construct implementation. + +Luckily, hardware platforms cluster into groups with similar performance-related features. This opens the door to an approach that can present a common abstraction for all platforms in a cluster. Examples of clusters include: + +\begin{itemize} +\item shared coherent memory multi-core single-chip machine +\item shared coherent memory multi-chip machine +\item independent address space coprocessor (GPU) +\item a network of nodes of the other categories +\item a machine with a hierarchy of sub-networks +\end{itemize} + + +%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% +% +%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% +\section{Our Proposal} + +We propose addressing the runtime effort by defining a modularization of runtimes. The low-level hardware details are collected into one module, which presents a common interface for all platforms sharing similar performance related features. This module only has to be implement once for a given platform, then reused by the languages. + +Thus, a given language doesn't have to re-implement its runtime for every platform. Instead, it has a much lower effort requirement of implementing for each category. + +The language effort is further reduced because the language doesn't +consider the low-level details of making the runtime itself run fast. It +only has to consider the level of hardware feature that is exposed by the +interface. This is a higher level of abstraction, which simplifies the task +for the language implementer. + +In this paper, we present work that applies to coherent +shared memory machines, both single chip and multiple chip. Extensions beyond this are currently in progress, to address multiple-address-space machines and hierarchical networked collections of processors, which will appear in future papers. + +\subsection{Breakdown of the modules} + +The language is broken into two parts. One is a thin wrapper library that +invokes the runtime and the other is a set of modules that are part of the runtime. + +The runtime consists of three modules. One encapsulates the low-level hardware details, and presents an interface to the language modules. We call +this the \textit{proto-runtime}. +It's job is to enforce the interface that the language modules see. + +The language has two modules, both of which are collected in what we call the \textit{language plugin}. One module encodes the behavior of language +constructs, the other module provides logic for choosing which work to execute on +which hardware resource. + +The plugin collects the two language modules into a dynamic library that is implemented, compiled, and distributed separately from any application executables. This is how a non-changing application executable is able to invoke plugin code that can change between machines. The executable contains only symbols of plugin functions, and during the run those are linked to specific functions' implementations. + +In order to provide such modularization, we rely upon something we call a tie-point as the primitive upon which synchronization constructs are built. The low-level nature of a tie-point places them below the level of constructs like a mutex. Instead, a mutex is implemented on top of tie-points. This places all parallel constructs on the same level in the software stack, be they complex like the AND-OR parallelism of Prolog, or the wild-card matching +channels in coordination languages, or ultra-simple acquire and release mutex constructs. All are implemented in terms of the same tie-point primitives provided by the proto-runtime. + + + + + +\subsection{The origin of tie-points.} + +A tie-point relates timelines, so we talk a little about timelines. A timeline is the primitive in parallelism. If you look at any parallel language, it establishes a number of independent timelines. It then controls which timelines are actively progressing relative to the others. + +For example, take a thread library. It provides a command to create a thread, and that thread represents an independent timeline. The library also provides the mutex acquire and release commands, which control which of those timelines advance relative to each other. When an acquire executes, it causes the thread to block, which means the associated timeline suspends. The release in a different thread clears the block, which resumes the timeline. That linkage between suspend and resume of different timelines is the control the language exerts over which timelines are actively progressing. + +To build up to tie-points, we look at the nature of points on +a single timeline, by reviewing mutex behavior in detail. We see the timeline shown in Fig X. Thread 1, which is timeline 1, tries to acquire the mutex, M, +by executing the acquire command. Timeline 1 stops, at point 1.1, then something external to it happens, and the timeline starts again at point 1.2. The gap between is not seen by the code executed within the thread. Rather, from the code-execution viewpoint, the acquire command is a single command, and hence the gap between 1.1 and 1.2 collapses to a single point on the timeline. + +Now, a tie-point is seen as the linkage between such collapsed points on +two timelines. In Fig X, timeline 1 is still there, suspends still at 1.1 and resumes at 1.2. However, now there is a second timeline, timeline 2. It executes the release command at point 2.1, which suspends timeline 2, performs the behavior of the release command +inside the gap, then resumes timeline 2 at 2.1. The behavior of the release +command causes the end of suspend in the first timeline. That causality ties the two collapsed points in the two timelines together. + + +We call this connection between the collapsed suspensions a tie point. What it provides is a guarantee about visibility of events between the tied timelines. The +guarantee makes both agree on the order of events,\textit{ +relative to the tied points}. Any operation that executes before the point in the second timeline, 2.1, is visible immediately after the point in the first timeline, 1.2. In addition, nothing +in the first timeline happening after the tie-point is visible in the second +timeline before the tie-point. + +Just that guarantee defines it as a half tie-point. A full tie-point adds the dual guarantee between the second timeline +and the first. Namely, for a full tie--point, anything before the point in the first timeline is visible in the second timeline after the tie-point, +and nothing in the second timeline after the tie-point is visible in the +first before the tie-point. + +A tie-point is the primitive mechanism that the proto-runtime implements. It does not involve any notion of dependency nor constraint semantics. All it provides is the notion that the tied points are the same "instant" for both tied timelines. What that means is that both timelines see events ordered relative to that point in the same way. + +It is up to the language to supply the behavior that happens inside +the gaps. This behavior is what decides which timelines get tied together. It is that decision making, of which timelines to tie together, that implements the +semantics of a synchronization construct. + + + +\subsection{Tie-points within a proto-runtime} + + In Fig X we didn't say what entity executes the behavior that takes place in the gaps in the timelines. This is what the proto-runtime does. It provides +primitives that suspend a timeline and then cause behavior supplied by the language +plugin to execute in the gap. This plugin behavior chooses which timelines remain suspended versus which resume execution, or start execution. + +As such, the plugin behavior that runs in the proto-runtime when one timeline +suspends is what chooses another timeline to resume as a consequence of that +suspension. That +choice establishes causality between the suspensions of the two timelines, +and thus creates the tie between the two collapsed timeline points. The proto-runtime +module provides the suspend and resume primitives and the proto-runtime entity +executes the plugin behavior. + +The proto-runtime entity is also known as the Master, while the timelines +are known as Slaves. The behavior of the language constructs executes within the Master's timeline, while the behavior of application code executes within Slave timelines. + +\subsection{More about the proto-runtime} + +The proto-runtime provides the following primitives, for use by language +plugins: +\begin{itemize} +\item create a virtual processor (which has a suspendible timeline) +\item create a task (which has an atomic timeline that runs to completion) +\item automatically convert a task to a virtual processor, as needed +\item choose which virtual processor or task to begin execution on an offered +core +\item suspend a timeline, and cause a function to handle the suspension to execute in the Master, with supplied parameters +\item end a timeline + +\end{itemize} + +Virtual processors and tasks, both, have associated timelines. The reason for having both is a practical one, as tasks are simpler, with less overhead, +and many languages have the semantics of short, atomic, units of work that +are not intended to suspend. Thus, tasks are treated differently inside the +proto-runtime, and incur less overhead to create and run. + +A special feature of the proto-runtime is that if a task happens to execute +a language command that causes suspension, then the proto-runtime automatically +converts that task to a virtual processor. This helps support the mixing of different +languages within the same program. + +The proto-runtime involves the language into the process of choosing which core a given task +or virtual processor executes on. The proto-runtime maintains control, but offers free cores to the plugin, which responds by then assigning a task or virtual processor to the core. The proto-runtime just offers, it is up to the language to decide what work that core should receive at that point in time. + +The proto-runtime provides a mechanism for communicating information from the application code to the plugin function invoked. For example, the identity of a particular mutex a thread wishes to acquire +can be communicated from the wrapper library to the plugin. + + +Because the proto-runtime tracks all the timelines, the end of a timeline has to be explicitly stated in the application code, by calling a wrapper library function. That then invokes the proto-runtime primitive that informs the proto-runtime instance. The proto-runtime performs internal bookkeeping related to the ending of the timeline, and notes that the core is now free and offers it to the plugin's Assigner function. + + + + + + +\subsection{Expl with Sung} + +A plugin is a dynamic library that is implemented, compiled, and distributed separately from any application executables. This is how a non-changing executable is able to invoke plugin code that can change between machines. The executable contains only symbols of plugin functions, and during the run those are linked to specific functions' implementations. ? -Lastly, switching from sequential programming to using an eDSL tends to have low disruption because the base language remains the same, along with most of the development tools and practices. - The cus\subsection{ Few users-\textgreater\ must be quick time to create + low effort to lang-port + high perf across targets} -\subsection{ effort to create = syntax trans + runtime + construct impl \& effort to port = runtime + constr impl_} +The sequence goes: wrapper library + is compiled into the application +executable; during the run, a call to the library function passes information, +such as the ID of the mutex to acquire; the library function packages the +information into a request data structure, then invokes the proto-runtime +primitive that suspends the virtual processor (timeline) that is executing +that code; the invocation passes the request structure and also a pointer +to the plugin function that will receive the request and perform the behavior. it invokes the suspend to the plugin function, which implements the behavior of acquire mutex, and runs +inside the proto-runtime instance. -showing the role that runtime implementation plays in the success of eDSLs. +? -\subsection{big picture = langs * runtimes -\textgreater runtime effort critical} -====================================== +A task is an atomic unit of work. It runs to completion, without suspending. That characteristic allows the proto-runtime to internally treat a task differently than a virtual processor. The fact that it never suspends means it doesn't need a stack, and needs less bookkeeping, which makes a task faster to create and faster to assign, for lower overhead. -We expand on the hypothesis that an embedded style Domain Specfic Language (eDSL) provides high programmer productivity, with a low learning curve. We also show (\S ) that when an application is written in a well designed eDSL, porting it to new hardware becomes simpler, because often only the language needs to be ported. That is because the elements of the problem being solved that require large amounts of computation are often pulled into the language. Lastly (\S ), we hypothesize that switching from sequential programming to using an eDSL is low disruption because the base language remains the same, along with most of the development tools and practices. +However, a task may optionally choose at some point to execute a language command that causes it to suspend. At the point it does that, the proto-runtime internally converts the task to a virtual processor. That allows the task to suspend and later resume, at the cost of gaining the normal virtual processor overhead. However, the virtual processor the task is converted to comes from a recycle pool and returns when the task completes. -In \S \ref{sec:DSLHypothesis} we show that the small number of users of an eDSL means that the eDSL must be very low effort to create, and also low effort to port to new hardware. At the same time, the eDSL must remain very high performance across hardware targets. +As an application programmer, you can create processes directly with an OS-like language built on top of the proto-runtime. But you use a programming language to create tasks or virtual processors. For example, VSs has a way to create tasks. VSs internally then uses a proto-runtime command to have the proto-runtime create a task for it. Then VSs decorates the task with its own meta-data. It uses that meta-data to track when a task should be executed. -In \S we analyze where the effort of creating an eDSL is expended. It turns out that in the traditional approach, it is mainly expended in creating the runtime, and in performance tuning the major domain-specific constructs. We use this to support the case that speeding up runtime creation makes eDSLs more viable. +? -In \S we take a step back and examine what the industry-wide picture would be if the eDSL approach were adopted. A large number of eDSLs will come into existence, each with its own set of runtimes, one runtime for each hardware target. That causes a multiplicative effect: the number of runtimes will equal the number of eDSLs times the number of hardware targets. Unless the effort of implementing runtimes reduces, this multiplicative effect could dominate, which would retard the uptake of eDSLs. +The only thing you're allowed to do outside a language is create the environment in which you start a language. +? - ============== +The implementation of the language behavior is the plugin. The plugin has two parts: request handlers, which handle the messages that come when a VP suspends, and an assigner, which picks where particular VP resumes onto or a task runs. With VSs, the plugin provides the behavior of "submit task". +The request handler plus plugin together provide the two halves of what people normally call a scheduler. -Further, in \S we show that when an application is written in a well designed eDSL, porting it to new hardware becomes simpler because often only the language needs to be ported. That is because the elements of the problem being solved that require large amounts of computation are often pulled into the language. Lastly, in \S we hypothesize that switching from sequential programming to using an eDSL is low disruption because the base language remains the same, along with most of the development tools and practices. Hence, we cover how the three issues currently making parallel programming unattractive are addressed by embedded-style DSLs. +Here's VSs code. This is library code that the application programmers get to see. This is code that gets compiled into the application. Here is submit task. Over in the seed function, it called VSs\_\_submit\_task. So, here's the implementation of submit\_task. You can see all it does is create a request data structure, and fill it up with some data, then call this proto-runtime primitive, which is "send\_create\_task\_request" and there's a separate proto-runtime primitive for creating tasks, because tasks are special inside the proto-runtime, so you need a special call just for them. -We next show what the blocks to eDSLs are, and where the main effort in implementing an eDSL lies. Specifically, in \S \ref{sec:DSLHypothesis} we show that the small number of users of an eDSL means that the eDSL must be very low effort to create, and also low effort to port to new hardware. At the same time, the eDSL must remain very high performance across hardware targets. +This is not the plugin code, this is the library that the application executable includes. It's equivalent to the pthread library. When you look at the source of the pthread library, it's just a wrapper that invokes the OS. It doesn't do anything itself. The language libraries are the same thing, just wrappers that invoke the proto-runtime primitives. Those suspend the VP and send a message to the proto-runtime. When the message arrives, it invokes the plugin to handle the task. -In \S we analyze where the effort of creating an eDSL is expended. It turns out that in the traditional approach, it is expended in creating the translator for the custom DSL syntax, in creating the runtime, and in performance tuning the major domain-specific constructs. We propose that the MetaBorg[] or Rose[] translation approaches cover creating translators for custom syntax, and that tuning constructs is inescapable, leaving the question of runtime implementation time. +Here's how the wrapper library connects a request to the request handler: via this function pointer, right here Fig X, given to the proto-runtime "suspend and send" primitive. The pointed-to function is part of the plugin. That runs inside the proto-runtime, and is what handles the message created in the wrapper library. -In \S we explore the effects of runtime implementation time by taking a step back and examine what the industry-wide picture would be if the eDSL approach were adopted. A large number of eDSLs will come into existence, each with its own set of runtimes, one runtime for each hardware target. That causes a multiplicative effect: the number of runtimes will equal the number of eDSLs times the number of hardware targets. Unless the effort of implementing runtimes reduces, this multiplicative effect could dominate, which would retard the uptake of eDSLs. Thus, showing that an approach that mitigates this multiplicative effect is valuable, and is the role that the proto-runtime plays. + +If we go and look at that handler function, Fig X, we see that it has a standard prototype, so it takes a standard set of arguments. One of those, here in Fig X, is a language environment. This is the special sauce, it is the thing that is shared among all the cores. This language environment is where tasks are placed that are not yet ready to execute, and where suspended virtual processors are placed that are not yet ready to resume. + +Here, Fig X, you can see there's a hash table. The language environment contains that hash table. The tasks get parked in this hash table. Each time a task completes, it looks in the hash table, finds all tasks waiting for its completion, and updates the status of those waiting tasks. If this was the last task being waited for, the waiter is taken out of the hash table and put into the queue of ready to execute tasks. + +This is the semantics of the language. This is how the semantics of the language defines what dependencies are, and how it defines when a task's dependencies have been satisfied. The implementation is just a data structure in the shared language environment. It is the proto-runtime that takes care of creating the tasks, creating the virtual processors, execute those, suspend them and resume them. The proto-runtime handles the mechanics of all that stuff. The language just figures out what are the constraints on making it ready. + +? + +Separately, the proto-runtime calls the Assigner function, which is also part of the plugin dynamic library. Each time a task completes or a virtual processor suspends, the wrapper library invokes a proto-runtime primitive. Among other things, that primitive informs the proto-runtime about the completion of that work, which tells the proto-runtime that hardware resources have just been freed up. + +The proto-runtime then invokes the Assigner function, passing it information about the hardware that was just freed. The assigner is implemented by the language and uses some language-specific way to choose which of the ready work-units to execute on that hardware (a work-unit is either a ready-to-execute task or a ready-to-resume virtual processors). This is how the language is given control over placement of work onto cores. + +=================== + +Any event visible before in one is visible in both after. The guarantee is between before in one and after in both. + +From the program point of view, that acquire statement is one instant. That entire gap in physical time is seen as a single instant to the code. + +However, the tie point is just one instant in the timelines. After the point, one of the timelines could perform an event that interferes with an event from before the tie-point, and no guarantees are given about what the other timeline sees. However, if another tie-point is created between them, then they are both guaranteed to see that second, interfering event, after the second tie-point. + +Take the example of a mutex, M. The purpose of the only-one semantics of a mutex is to isolate read and write operations done by the owning thread from those done by other threadz, which own before or after it. + +The mutex behavior is illustrated in Fig X. Timeline 1 writes to variable A at point 1, then releases the M at point 2. Timeline 2 acquires M, at the tied point 2 and reads A at point 3. For M to provide isolation, it must guarantee that the A write operation at point 1 is seen by the other timeline's read operation, at point 3. Likewise, it has to guarantees that nothing that happens in timeline 2 after the acquire of M, at point 2, will be seen by timeline 1 before its release, also at point 2. + +That ordering guarantee is what we think of when we imagine the behavior of a mutex acquire-release pair. All writes done by the releasing thread are seen as completed, by reads performed in the acquiring thread, and no writes in the acquiring thread are seen before the release by the releasing thread. That is required in order to have value for the semantics of only one thread owns the mutex at any point. The purpose of only-one is to isolate read and write operations done by the owning thread from those done by the threads that own before or after it. + + +The behavior is implemented in terms of a data structure that lives inside the controlling entity's environment. The controlling entity looks up the data structure for the mutex being requested. This data structure has a field that contains the name of the thread that current owns the mutex, plus a queue of threads waiting to acquire it. So, the controlling entity first looks at the field that holds the current owner, sees that it is occupied, and then puts the thread's name into the queue of waiting threads. + +At some point later, the waiting thread reaches the top of the queue. At the point the owning thread executes the release operation, that owning thread also suspends, the controlling entity sees that suspend and that the thread wants to perform the release behavior. It looks up the release behavior and performs it. This behavior looks up the mutex data structure in the controlling entity's environment, removes the releasing thread from the owner field, takes the top thread off the waiters, writes its name into the current owner, then marks both those threads as ready to resume their timelines. + +The proto-runtime is the controlling entity, which looks up the behaviors and performs them. It also manages the environment that holds the data structures used by the behaviors. + +=========== + +The purpose of the M is to guarantee that what gets written to A here in this timeline is seen over here, in this other timeline. + +So, to turn this simple mechanism into a synchronization construct, you add semantics on top, which determine the end of suspend in the two timelines. The timelines voluntarily place themselves into suspend, and it is up to the controlling entity to decide at what point to end that suspension. It is this choice of ending suspension that ties events in one timeline to events in another. The semantics of deciding that end of suspension is the semantics of the synchronization construct. + +For example, take mutual exclusion within Threads. One thread executes a construct that asks to acquire the mutex. At the point of executing, that thread suspends, so that timeline ceases advancing. At some point later, the controlling entity sees that suspend, and sees that the timeline is attempting the acquire mutex activity. It looks up the behavior for acquire mutex, which is then performed inside that controlling entity. + +============ + + +%====================================== + +%We expand on the hypothesis that an embedded style Domain Specfic Language (eDSL) provides high programmer productivity, with a low learning curve. We also show (\S ) that when an application is written in a well designed eDSL, porting it to new hardware becomes simpler, because often only the language needs to be ported. That is because the elements of the problem being solved that require large amounts of computation are often pulled into the language. Lastly (\S ), we hypothesize that switching from sequential programming to using an eDSL is low disruption because the base language remains the same, along with most of the development tools and practices. + +%In \S \ref{sec:DSLHypothesis} we show that the small number of users of an eDSL means that the eDSL must be very low effort to create, and also low effort to port to new hardware. At the same time, the eDSL must remain very high performance across hardware targets. + +%In \S we analyze where the effort of creating an eDSL is expended. It turns out that in the traditional approach, it is mainly expended in creating the runtime, and in performance tuning the major domain-specific constructs. We use this to support the case that speeding up runtime creation makes eDSLs more viable. + +%In \S we take a step back and examine what the industry-wide picture would be if the eDSL approach were adopted. A large number of eDSLs will come into existence, each with its own set of runtimes, one runtime for each hardware target. That causes a multiplicative effect: the number of runtimes will equal the number of eDSLs times the number of hardware targets. Unless the effort of implementing runtimes reduces, this multiplicative effect could dominate, which would retard the uptake of eDSLs. + + +% ============== + +%Further, in \S we show that when an application is written in a well designed eDSL, porting it to new hardware becomes simpler because often only the language needs to be ported. That is because the elements of the problem being solved that require large amounts of computation are often pulled into the language. Lastly, in \S we hypothesize that switching from sequential programming to using an eDSL is low disruption because the base language remains the same, along with most of the development tools and practices. Hence, we cover how the three issues currently making parallel programming unattractive are addressed by embedded-style DSLs. + +%We next show what the blocks to eDSLs are, and where the main effort in implementing an eDSL lies. Specifically, in \S \ref{sec:DSLHypothesis} we show that the small number of users of an eDSL means that the eDSL must be very low effort to create, and also low effort to port to new hardware. At the same time, the eDSL must remain very high performance across hardware targets. + +%In \S we analyze where the effort of creating an eDSL is expended. It turns out that in the traditional approach, it is expended in creating the translator for the custom DSL syntax, in creating the runtime, and in performance tuning the major domain-specific constructs. We propose that the MetaBorg[] or Rose[] translation approaches cover creating translators for custom syntax, and that tuning constructs is inescapable, leaving the question of runtime implementation time. + +%In \S we explore the effects of runtime implementation time by taking a step back and examine what the industry-wide picture would be if the eDSL approach were adopted. A large number of eDSLs will come into existence, each with its own set of runtimes, one runtime for each hardware target. That causes a multiplicative effect: the number of runtimes will equal the number of eDSLs times the number of hardware targets. Unless the effort of implementing runtimes reduces, this multiplicative effect could dominate, which would retard the uptake of eDSLs. Thus, showing that an approach that mitigates this multiplicative effect is valuable, and is the role that the proto-runtime plays. %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% -\section{The DSL Hypothesis} -\label{sec:DSLHypothesis} +\subsection{Details} +\label{subsec:Details} -Following that background on DSLs, we move on to the details of the proto-runtime approach (\S ). We provide details of how a runtime is modularized (\S ), showing what responsibilities are encapsulated in which modules, and what the interfaces between them look like. We show how this makes the proto-runtime be reused by all languages on given hardware, and how the low-level tuning of the proto-runtime for specific hardware automatically benefits all the languages that run on that hardware. + We move on to the details of the proto-runtime approach (\S ), showing how a runtime is modularized (\S ), what responsibilities are encapsulated in which modules, and what the interfaces between them look like. + +This modularization and its interface is what makes the proto-runtime reusable by all languages on given hardware, and the low-level tuning of the proto-runtime for specific hardware automatically benefits all the languages on that hardware. + +? We follow this (\S ) with an in-depth look at implementing language logic, and show how the proto-runtime interface allows it to use sequential thinking. We then give similar detail (\S ) on the implementation of the assigner, which chooses what core executes each chunk of work. We discuss how that has the potential to improve application performance by reducing communication between cores and reducing idle time of cores. We support our belief (\S ) that the patterns we followed when modularizing are indeed fundamental and will remain valid for future languages and hardware. We then discuss (\S ) some of the centralized services provided by the current proto-runtime implementation, as well as planned future ones. Then we give an example of reusing language logic from one language implementation to another (\S ). diff -r 9b9a2497757d -r eb146c5c05a8 0__Papers/VMS/VMS__Foundation_Paper/VMS__Full_conference_version/latex/VMS__Full_conf_paper_3.tex --- /dev/null Thu Jan 01 00:00:00 1970 +0000 +++ b/0__Papers/VMS/VMS__Foundation_Paper/VMS__Full_conference_version/latex/VMS__Full_conf_paper_3.tex Sat Aug 03 19:24:22 2013 -0700 @@ -0,0 +1,2152 @@ +%----------------------------------------------------------------------------- +% +% Template for sigplanconf LaTeX Class +% +% Name: sigplanconf-template.tex +% +% Purpose: A template for sigplanconf.cls, which is a LaTeX 2e class +% file for SIGPLAN conference proceedings. +% +% Guide: Refer to "Author's Guide to the ACM SIGPLAN Class," +% sigplanconf-guide.pdf +% +% Author: Paul C. Anagnostopoulos +% Windfall Software +% 978 371-2316 +% paul@windfall.com +% +% Created: 15 February 2005 +% +%----------------------------------------------------------------------------- + + +\documentclass[preprint]{sigplanconf} + +% The following \documentclass options may be useful: +% +% 10pt To set in 10-point type instead of 9-point. +% 11pt To set in 11-point type instead of 9-point. +% authoryear To obtain author/year citation style instead of numeric. +\usepackage{amssymb,graphicx,calc,ifthen,subfig,dblfloatfix,fixltx2e} + + +% correct bad hyphenation here +\hyphenation{op-tical net-works semi-conduc-tor} + +\usepackage{wasysym} +\usepackage{amstext} + +\begin{document} + +\bibliographystyle{plain} +% + +\conferenceinfo{WXYZ '05}{date, City.} +\copyrightyear{2005} +\copyrightdata{[to be supplied]} + +\titlebanner{banner above paper title} % These are ignored unless +\preprintfooter{short description of paper} % 'preprint' option specified. + + +\title{A Proto-Runtime Approach to Domain Specific Languages} + + +\authorinfo{Sean Halle} + {Open Source Research Institute, INRIA, + and TU Berlin} + {seanhalle@opensourceresearchinstitute.org} +\authorinfo{Merten Sach} + {TU Berlin} + {msach@mailbox.tu-berlin.de} +\authorinfo{Albert Cohen} + {Ecole Normal Supereur, and INRIA} + {albert.cohen@inria.fr} + +\maketitle + + +\begin{abstract} + +? +replace lang-specific with interface, centralize services, minimize effort to create, give language control over hardware assignment.. side benefits: multi-lang, perf-tuning, debugging + +? + +Domain Specific Languages that are embedded into a base language have promise to provide productivity, performant-portability and wide adoption for parallel programming. However such languages have too few users to support the large effort required to create them and port them across hardware platforms, resulting in low adoption of the method. +To solve a portion of this, we introduce a proto-runtime approach, which reduces the effort to create and port +the runtime portion of a parallel domain specific language. It modularizes the creation of runtime systems and the parallelism constructs they implement, by separating the language-construct and scheduling logic away from the low-level runtime details, including concurrency, memory consistency, and runtime-performance aspects. +As a result, new parallel constructs are written using sequential reasoning, and multiple languages can be mixed within +the same program. In addition, scheduling of work onto hardware is under language and application control, without interference from an underlying thread package scheduler. This enables higher quality scheduling decisions for higher application performance. +We present measurements of the time taken to develop runtimes for new languages, as well as time to re-implement existing ones, which average a few days each. In addition, we measure performance of proto-runtime based implementations going head-to-head with the standard distributions of Cilk, StarSs (OMPSs), and posix threads, showing that the proto-runtime matches or outperforms on several multi-core machines in all cases. +\end{abstract} + + + + + +%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% +\section{Background and Motivation} +\label{sec:intro} + +[Note to reviewers: this paper's style and structure follow the official PPoPP guide to writing style, which is linked to the PPoPP website. We are taking on faith that the approach has been communicated effectively to reviewers and that we won't be penalized for following it's recommended structure and approach.] + +Programming in the past has been overwhelmingly sequential, with the applications being run on sequential hardware. But the laws of physics have forced the hardware to become parallel, which will force nearly all future programming to become parallel programming. However, the transition from sequential to parallel programming has been slow due to the difficulty of the traditional parallel programming methods. + +The difficulties with parallel programming fall into three main categories: 1) difficult mental model, 2) extra effort to rewrite the code for each hardware target to get acceptable performance and 3) disruption to existing practices, including steep learning curve, changes to the tools used, and changes in design practices. + +Many believe that these can be overcome with the use of Domain-Specific Languages []. But such languages have been slow to adopt, we believe due to the cost to create them and to port them across hardware targets. The small number of users of each language, which is specific to a narrow domain, makes this cost impractical. + +We propose that a method that makes Domain Specific Languages (DSLs) low cost to produce as well as to port across hardware targets will allow them to fulfill their promise, and we introduce what we call a proto-runtime to help towards this goal. + +A proto-runtime instance is a normal, full, runtime, but with two key pieces replaced by an interface. One piece replaced is the logic of language constructs, and the other is logic for choosing which core to assign work onto. The remaining proto-runtime piece handles the low-level hardware details of the runtime. + +The decomposition into a proto-runtime plus plugged-in language behaviors modularizes the construction of runtimes. The proto-runtime is one module, which embodies runtime internals, which are hardware oriented and independent of language. The plugged-in portions form the two other modules, which are language specific. The interface between them occurs at a natural boundary, which separates the hardware oriented portion of a runtime from the language oriented portion. + +We claim the following benefits of the proto-runtime approach, each of which is supported in the indicated section of the paper: + +\begin{itemize} + +\item The proto-runtime approach should reliably apply to future languages and hardware. because the patterns underlying it appear to be fundamental and so should hold for future languages and architectures (\S\ref{subsec:TiePoints}, +\S\ref{subsec:Example}). + +\item The proto-runtime approach modularizes the runtime (\S\ref{sec:Proposal}). + +%\item The modularization is consistent with patterns that appear to be fundamental to parallel computation and runtimes (\S\ ). + +\item The modularization cleanly separates runtime internals from the language-specific logic (\S\ref{sec:Proposal}, +\S\ref{subsec:Example}). + +\item The modularization gives the language control +over timing and placement of executing work (\S\ref{sec:Proposal}). + +\item The modularization results in reduced time to implement a new language's behavior, and in reduced time to port a language to new hardware (\S\ref{sec:Proposal}, +\S\ref{subsec:ImplTimeMeas}). + +\begin{itemize} + + +\item Part of the time reduction is due to the proto-runtime providing a centralized location for services for all languages to use, so the language doesn't have to provide them separately. Such services include debugging facilities, automated verification, concurrency handling, hardware performance information gathering, and so on (\S\ ). + +\item Part of the time reduction is due to encapsulation of hardware aspects inside the hardware-oriented module (\S \ref{sec:intro}). + +\item Part of the time reduction is due to reuse of the performance-tuning effort for runtime internals (\S ). + +\item Part of the time reduction is due to using sequential thinking when implementing the language logic, enabled by the proto-runtime protecting shared internal runtime state and exporting an interface that presents a sequential model (\S\ref{subsec:Example}). + + +\end{itemize} + +\item + +The modularization also selectively exposes hardware aspects relevant to placement of work, giving the language control over placement of work onto the hardware. If the language takes advantage of this, it can result in reduced communication between cores and increased application performance (\S\ ). + +\begin{itemize} + +\item Similar control over hardware is not possible when the language is built on top of a package like Posix threads or TBB, which has its own work-to-hardware assignment (\S\ref{sec:Related}). + +\end{itemize} + +\item Modularization with similar benefits does not appear possible when using a package such as Posix threads or TBB, unless the package itself is modified and then used according to the proto-runtime pattern (\S\ref{sec:Related}). + +\end{itemize} + +The paper is organized as follows: We first expand on the value of embedded style DSLs (eDSL), and where the effort goes when creating one (\S\ref{subsec:eDSLEffort}). We focus on the role that runtime implementation effort plays in the adoption of eDSLs, which motivates the value of the savings provided by the proto-runtime approach. We then move on to the details of the proto-runtime approach (\S\ref{sec:Proposal}), and tie them to how a runtime is modularized (\S\ref{subsec:Modules}), covering how each claimed benefit is provided. +We then show overhead measurements (\S\ref{subsec:OverheadMeas}) and implementation time measurements (\S\ref{subsec:ImplTimeMeas} ), which indicate that the proto-runtime approach is performance competitive while significantly reducing implementation and porting effort. +With that understanding in hand, we then discuss how the approach compares to related work (\S\ref{sec:Related}), and finally, we highlight the main conclusions drawn from the research (\S\ref{sec:Conclusion}). + + + + +%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% +% +%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% +\section{Background: The eDSL Hypothesis} + +%[[Hypothesis: Embedded-style DSLs -\textgreater\ high productivity + low learning curve + low app-port + low disruption]] + +%[[Bridge: Few users-\textgreater\ must be quick time to create + low effort to lang-port + high perf across targets]] + +%[[Bridge: effort to create = runtime + effort port = runtime + perf on new target = runtime]] + +%[[Bridge: big picture = langs * runtimes -\textgreater runtime effort critical]] + +Domain Specific Languages have been around for a while [], and recently have been suggested as a good approach for parallel programming[][stanford PPL]. + +In essence, a DSL, or just Domain Language, captures patterns that are common in a particular domain of expertise, such as user interfaces, simulations of physical phenomena, bio-informatics, cosmology, and so on. Each domain has a particular set of mental models, common types of computation, and common kinds of data structures. A DSL captures these common elements in custom syntax. + + +\subsection{Embedding a DSL into a base language} + +A style of domain language, which we feel has good applicability to parallel software development, is the so-called \textit{embedded} style of DSL (eDSL) [] [metaborg][stanford ppl]. In this variation, a program is written in a mix of a base language plus domain language constructs. The syntax of the two is intermixed. A preprocessing step then translates the domain syntax into the base syntax, and includes calls to the domain language's runtime. + + +For example, use C (or Java) as the base language for an application, and mix-in custom syntax for constructs from a user-interface eDSL. To test the code, the developer modifies the build process to first perform the translation step, then pass the resulting source through the normal C (or Java) compiler. The resulting executable contains calls to a dynamic (or shared) library that becomes linked, at run time, to a runtime implementation that has been tuned to the hardware it is running on. + + +\subsection{Low learning curve, high productivity, and portability} +DSLs are generally quick to learn because the domain experts are already familiar with the concepts expressed by the custom syntax, especially for those who are \textit{not} expert programmers. Embedded style DSLs further reduce learning curve because they have relatively few constructs, and require no new development tools nor development procedures. Together, these should meet the goal of a low learning curve for switching to parallel software development. + +Productivity can be enhanced by a well designed syntax, which can simplify the application code, modularize it, and encapsulate performance aspects inside the language. Simplifying reduces the amount of code and the amount of mental effort. Modularizing separates concerns within the code and isolates aspects, which improves productivity. Encapsulating performance inside the DSL constructs removes them from the application programmer's concerns, which also improves productivity. + +Perhaps the most important productivity enhancement comes from hiding parallelism aspects inside the custom DSL constructs. The language takes advantage of the domain patterns to present a familar mental model, and then attaches synchronization, work-division, and communication implications to those constructs, without the programmer having to be aware of them. Combining the simplicity, modularization, performance encapsulation, and parallelism hiding, with congruence with the mental model of the domain, together work towards the goal of high productivity. + +Portability is aided by the encapsulation of performance aspects inside the DSL constructs. This means that the elements of the problem that require large amounts of computation are often pulled into the language, which isolates the application code from hardware performance concerns. Only the language implementation must adapt to new hardware in order to get high performance. Although such isolation cannot always be fully achieved, Domain Languages hold promise for making significant strides towards it. + +\subsection{Low disruption and easy adoption} + +Using an eDSL tends to have low disruption because the base language remains the same, along with most of the development tools and practices. + Constructs from the eDSL can be mixed into existing sequential code, incrementally replacing the high computation sections, while continuing with the same development practices. + + \subsection{ Few users means the effort of eDSLs must be low} \label{subsec:eDSLEffort} + +What appears to be holding eDSLs back from addressing the challenges of parallel programming would be mainly the time, expertise, and cost needed to develop an eDSL. Because the number of users is small, the economic model of the past doesn't apply. For sequential languages, the potential user-base is in the millions, but for a parallel Domain Language, the user base may be only a few hundred developers who will use the language. + +As such, the effort to create a usable eDSL needs to be reduced to the point that it is viable for that size of user base. + +The effort to be reduced falls into three categories: + +\begin{enumerate} +\item effort to explore language design and create the eDSL syntax +\item effort to create the runtime that produces the eDSL behavior +\item effort to performance tune the eDSL on particular hardware +\end{itemize} + + +\subsection{Critical areas of effort in the big picture} + +Across the industry as a whole, when eDSLs become successful, there will be hundreds of Domain Languages, and likewise hundreds of different hardware platforms that each language must run efficiently on. That multiplicative effect must be reduced in order to make the eDSL approach economically viable. + +The first category of eDSL effort is creating the front-end translation of custom syntax into the base language. This is a one-time effort that does not repeat when new hardware is added. + +The effort that has to be expended on each platform is the runtime implementation, which includes hardware-specific low-level tuning, and the tuning of the domain construct implementation. + +Luckily, hardware platforms cluster into groups with similar performance-related features. This opens the door to an approach that can present a common abstraction for all platforms in a cluster. Examples of clusters include: + +\begin{itemize} +\item shared coherent memory multi-core single-chip machine +\item shared coherent memory multi-core multi-chip machine +\item independent address space coprocessor (GPU) +\item a network of nodes of the above categories +\item a machine with a hierarchy of sub-networks +\end{itemize} + + +%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% +% +%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% +\section{Our Proposal} \label{sec:Proposal} + +We propose addressing the runtime effort by defining a modularization of runtimes, as seen in Fig X. The low-level hardware details are collected into one module, which presents a common interface. The language supplies +the top two modules, which plug in via the interface. The hardware specific module presents the same interface +for all platforms sharing similar performance related features. This module only has to be implement once for a given platform, then reused by the languages. + +\begin{figure}[ht] + \centering + \includegraphics[width = 1.5in, height = 1.1in]{../figures/proto-runtime__modules.pdf} + \caption{Shows how the proto-runtime approach modularizes the implementation of a runtime. The three pieces are the proto-runtime implementation, an implementation of the language construct behaviors, and an implementation of the portion of scheduling that chooses which work is assigned to which processor. } + \label{fig:PR_three_pieces} +\end{figure} + + +Thus, a given language doesn't have to re-implement its runtime for every platform. Instead, it has a much lower effort requirement, of implementing for each category. + +The language effort is further reduced because the language doesn't consider the low-level details of making the runtime itself run fast. It only has to consider the level of hardware feature that is exposed by the interface. This is a higher level of abstraction, which simplifies the task for the language implementer. + +One additional benefit is giving control to the language, to choose when and where it wishes work to execute. +This feature simplifies implementation of languages +that have features related to scheduling behavior. +It also enables the language implementor to use sophisticated +methods for choosing placement of virtual processors +(threads) and tasks, which can significantly impact +application performance. + +In this paper, we present work that applies to coherent +shared memory machines, both single chip and multiple chip. Extensions beyond this are currently in progress, to address multiple-address-space machines and hierarchical +heterogeneous collections of processors, which will appear in future papers. + +\subsection{Breakdown of the modules} \label{subsec:Modules} + +The language is broken into two parts, as seen in Fig +X. One is a thin wrapper library that +invokes the runtime and the other is a set of modules that are part of the runtime. + + + +\begin{figure}[ht] + \centering + \includegraphics[width = 2.8in, height = 1.1in]{../figures/proto-runtime__modules_lang_breakdown.pdf} + \caption{Shows how the code of the language implementation + is broken into two pieces. The first is a thin wrapper + that invokes the runtime, the other is a dynamic + library that plugs into the runtime.} + \label{fig:langBreakdown} +\end{figure} + +The runtime itself consists of three modules connected via +an interface, as was seen back in Fig X. One encapsulates the low-level hardware details, and presents an interface to the language modules. We call +this the \textit{proto-runtime}. +It's job is to enforce the interface that the language modules see. + + +The language has two modules, both of which are collected in what we call the \textit{language plugin}. One module encodes the behavior of language +constructs, the other module provides logic for choosing which work to execute on +which hardware resource. + +The plugin collects the two language modules into a dynamic library that is implemented, compiled, and distributed separately from any application executables. This is how a non-changing application executable is able to invoke plugin code that can change between machines. The executable contains only symbols of plugin functions, and during the run those are linked to specific functions' implementations. + +In order to provide such modularization, we rely upon a model for specifying synchronization constructs that we call the tie-point model. The low-level nature of a tie-point places them below the level of constructs such as a mutex. Instead, a mutex is specified in terms +of the primitives in the tie-point model. The proto-runtime +then implements the primitives of the tie-point model. + + This places all parallel constructs on the same level in the software stack, be they complex like the AND-OR parallelism of Prolog, or the wild-card matching +channels in coordination languages, or ultra-simple acquire and release mutex constructs. All are implemented in terms of the same tie-point primitives provided by the proto-runtime. + +We have reached a point in the paper, now, where the order of explanation can take one of two paths: either +start with the abstract model of tie-points and explain how this affects the modularization of the runtime, or start with implementation details and work upwards towards the abstract model of tie-points. We have chosen to start with the abstract tie-point model, but the reader is invited to skip to the section after it, which starts with code examples and ties code details to the abstract tie-point model. + + + +\section{The tie-point model.}\label{subsec:TiePoints} + + +\subsection{timelines} +A tie-point relates timelines, so we talk a bit, first, about timelines. A timeline is the primitive in parallelism. If you look at any parallel language, it involves a number of independent timelines. It then controls which timelines are actively progressing relative to the others. + +For example, take a thread library, which we consider +a parallel language. It provides a command to create a thread, where that thread represents an independent timeline. The library also provides the mutex acquire and release commands, which control which of those timelines advance relative to each other. When an acquire executes, it can cause the thread to block, which means the associated timeline suspends; it stops +making forward progress. The release in a different thread clears the block, which resumes the timeline. That linkage between suspend and resume of different timelines is the control the language exerts over which timelines are actively progressing. + +To build up to tie-points, we look at the nature of points on +a single timeline, by reviewing mutex behavior in detail. We see the timeline shown in Fig \ref{fig:singleTimeline}. Thread A, which is timeline A, tries to acquire the mutex, M, +by executing the acquire command. Timeline A stops, at point 1.S, then something external to it happens, and the timeline starts again at point 1.R. The gap between is not seen by the code executed within the thread. Rather, from the code-execution viewpoint, the acquire command is a single command, and hence the gap between 1.S and 1.R collapses to a single point on the timeline. + + +\begin{figure}[ht] + \centering + \includegraphics[width = 2.8in, height = 0.8in] + {../figures/PR__timeline_single.pdf} + \caption{The timeline suspends at 1.S and resumes + at 1.R. From the viewpoint of the timeline, the gap collapses into a single point.} + \label{fig:singleTimeline} +\end{figure} + + +Now, a tie-point is seen as the linkage between such collapsed points on +two timelines. In Fig \ref{fig:dualTimeline}, timeline A is still there, suspends still at 1.S and resumes at 1.R. However, now there is a second timeline, timeline B. It executes the release command at point 2.S, which suspends timeline B, performs the behavior of the release command +inside the gap, then resumes timeline B at 2.R. The behavior of the release +command causes the end of suspend in the first timeline. That causality ties the two collapsed points in the two timelines together. + + +\begin{figure}[ht] + \centering + \includegraphics[width = 2.8in, height = 1.35in] + {../figures/PR__timeline_dual.pdf} + \caption{Two timelines with a causal relationship. +Activity that takes place during the gap in timeline +B causes resume of timeline A. This ties point 2 on +timeline B to point 1 on timeline A.} + \label{fig:dualTimeline} +\end{figure} + + + +We call this connection between the collapsed suspensions a tie-point. What it provides is a guarantee about visibility of events between the tied timelines. The +guarantee makes both agree on the order of events,\textit{ +relative to the mutual tied point}. +The guarantees are what defines a tie-point. + +Fig \ref{fig:tie-pointGuarantees} shows the ordering guarantees in terms of visibility of operations between +the timelines. If these visibility constraints are +satisfied, then the timelines share a tie-point. Note that the ordering + guarantees are equivalent to the constraints on visibility of operations. Operations that execute in +the first timeline before the tie-point must be visible +in the second after the tie point, and vice versa. Likewise, operations that execute in one timeline after the tie-point must not be visible in the other timeline before the tie-point. + + + +\begin{figure}[ht] + \centering + \includegraphics[width = 2.8in, height = 1.25in] + {../figures/PR__timeline_tie_point_ordering.pdf} + \caption{The +guarantees that a tie-point enforces. Shows which + operations performed on one timeline are visible to the other +timeline. These visibilities must be true for a tie-point. +Note that all events are divided into two groups, those +before the tied points versus those after the tied +points. Both timelines see the same before group and +the same after group. } + \label{fig:tie-pointGuarantees} +\end{figure} + + +\subsection{Formal definition of tie-point} +In a moment we will show how any and all synchronization constructs +can be defined in terms of tie-points. Before getting +there, we provide a formal definition of tie-point, +which we will then use in showing that all synchronization +constructs can be implemented in terms of tie-points. + +In our formalization, we treat a tie-point as something +that exists in the code, and causes what we call an \textit{ordering-point} to +arise in every run of the code. We define ordering-point +formally, and use that to state the constraints that +a tie-point code-instance must enforce. + + +\subsubsection{Lifeline, Timeline, and Projection} +We define a formal entity that we call a lifeline, +where a timeline is a type of lifeline. +We define event-types and specific occurrences of event-types, and show how multiple lifelines can observe the same occurrence. A projection between +lifelines is defined as an event initiated upon one lifeline being observed on a different lifeline. The projection is from initiator to observer. + +\begin{description} +\item[event:] +\(E \) represents an event, which is something that +can be initiated or observed. +\item[occurrence:] +\(O\in E \times\mathbb{N}\) is the set of occurrences, where each occurrence associates a specific event with a unique identifier. A particular occurrence is denoted by subscripting with the value of the associated +integer, for example: \(O_{7}\) + +\item[clock:] +\(t:I\rightarrow\mathbb{R}^{+}\) maps each integer +onto a real number, such that \(I_{1} \) + is a lifeline, where \(\alpha\) +is a sequence over \(Dom(t)\) and each element of \(\alpha\) is either an initiation of an occurrence, or an observation +of one. A \textit{beat} of the lifeline is one tuple, denoted \(l(i)\), while the occurrence associated +to the beat is denoted\(\) \(O(l(i)) \) or equivalently \(O(\alpha(i)). \) The real value +associated with the beat is denoted \(t(l(i))\). For a given lifeline, not every element of \(t\) must have an associated +\(\alpha\), but every \(\alpha\) must have a unique associated +\(I\) from the clock \(t\). Note that \(\forall i , t(l(i)) < t(l(i+1))\). At most one beat from one +lifeline can initiate an occurrence. However, multiple +beats +from a given lifeline can observe the same occurrence, +including one initiated earlier in the sequence of +the lifeline, +and multiple lifelines may observe the same occurrence, +each multiple times. + +\item[projection:] +Given \(l_{1} = <\alpha , t_{1}> \), \(l_{2} = <\beta , t_{2}> \) then a projection from \(l_{1}\) to \(l_{2}\) + is denoted \(l_{1}(i) \uparrow l_{2}(j) \), where \(l_{1}(i) \uparrow l_{2}(j) +\equiv O(l_{1}(i)) = O(l_{2}(j))\). + This says that the occurrence initiated by the ith beat of the first lifeline is observed by the jth beat +of the second lifeline. + +\item[ordering tuple:] \(OT_{}\) is a tuple consisting +of a set of two beats from two different lifelines, which do +not participate in projections, plus a set of projections +that cross the two beats in the forward direction. +Given \(OT =<[l_{1}(x) , l_{2}(y)], [projections]> \) then \(OT\) is an +ordering tuple iff \( [projections] \neq0 \forall p(i,j) \in projections \nexists p(i,j) +|iy\ \) +\item[program run:] \(\mathcal{R} \) is a particular set of lifelines. +The program run begins with the creation of any lifeline, and +ends with the end of all lifelines. + +\item[equivalent positions in different sequences:] a partial ordering is defined. +Given two positions within different sequences, if +one or both both can be +validly rearranged, by using the partial ordering to +define valid rearrangements, so they occupy + the same position in their rearranged sequences, then +they are equivalent positions. + +\item[equivalent occurrences:] two occurrences are +equivalent if their event instances cannot be distinguished, given the observation +measurements of interest. If the observation measurement +involves sequences, then the two events must lie at +equivalent positions within their respective sequences. + +\item[equivalent lifelines:] two lifelines whose beats +can be paired, such that every beat in one lifeline +has an equivalent beat in the other. The beats do +not have to occur in the same order in both lifelines. +Beats associated to occurrences that are not of interest can be dropped. + +\item[equivalent program runs:] two runs such that +their lifelines can be paired one-to-one, with every lifeline in one paired to an equivalent +lifeline in the other. The projections between lifelines +in one run can be different from the projections in +the other run. + +\item[tie-point:] a set of beats, one from each of two lifelines, such that this set of beats forms a separation set in all equivalent program runs. +\end{description} + + +Some things to note: A particular occurrence +can be associated to at most one beat from a given +lifeline, but that same occurrence can also be associated +to beats from multiple other lifelines. Also, an occurrence may +be initiated by a lifeline but never observed by any. +Every \(O\) has a set of projections associated with it. + +For example, the event could +be writing a value into a variable. Two separate +write events are considered equivalent occurrences if +they both write the same particular value into whatever memory location +is associated to the same particular +variable, and happen within valid partial orderings +relative to the other occurrences. This is normally +compared across re-creations of the "universe" that +provides the context for the orderings of events instances. + +========= + + Okay, talked it over with Sung -- what about making distinguished beats +-- as Sung poked around for, make the PR\ "suspend" be the +distinguished beat. Then, as we worked out talking it +through, make the code that happens on the hidden timeline be the linkage between the beats -- so a tie-point is any number of distinguished beats such that the hidden calculation on one of the beats executed the resume for all of the other beats in the tie point. That establishes how a tie point gets created.. separately, need a universal statement of what is guaranteed by a tie point. + +So, one thing, is that the hidden calc is normally chosen such that every equivalent program run reproduces equivalent tie points -- but defining equivalent relies upon defining the "meaning"\ of the constructs.. but maybe that thing above about equivalent in terms of partial order can be used, by saying all constructs +are associated with a partial ordering -- but, still can have truly non-deterministic behavior being the correct behavior.. hmmm, but that should still have a partial ordering! + + What I\ really want to do is define tie-point in terms of the write-to-read. A half tie point says what's before the pre is visible after in the post timeline. And a full tie-point says that goes both ways. So, acquire-release is only a half tie-point, because what's after the release in its timeline can be seen before the acquire in its timeline. That makes it a half tie-point. Also, whats before the acquire in its timeline does not necessarily have to be seen after the release in its timeline.. that also makes it a half tie-point. + +So, use the project definition, and the crossing definition, to say which crossing projects are allowed by a half tie point, and which of those must be eliminated to make it a full tie-point. Then THAT\ defines the behaviors of a tie-point, independently from how it is created. + +The full definition of tie-point, in terms of proto-runtime value, has both those -- the hidden timeline "math" thing along with the causality, gives the "creation" aspect of tie-point, and the allowed projections gives the "behavior" aspect of tie-point. + +From the projection "behavior" I can simply state "this +defines what all synchronization constructs do" -- +the projection behavior is the whole purpose of a sync construct -- to ensure particular communication pattern when comm is via side-effect + +======= + +From first model, have the real-value constraints for slide of suspend and resume relative to each other.. + +The behavior of full tie-point is no back-cross projections, and there is a set of forward-crossing projections, which may be empty, and any of the tied timelines may +be the initiating timeline. For a half tie-point, have the origin lifeline. There is a set of forward-crossing projections with initiation on the origin lifeline, +and backward crossing are allowed whose initiation +is on non-origin lifeline. + +But a tie-point is more than just the behavior it defines. + In order for a pair of special beats to form a tie-point, +they must be causally linked on their internal lifelines. This means that a sequence of changes of the internal +state links the internal activity of one of the special beats to the internal activity of another special beat +that executes the resume that ends the second special beat. All special beats that are resumed inside the +same internal activity will have the behavior of a +full tie-point. Half tie-points can have both halves +resumed in different internal activities. + +A special beat has a variable-length span, as measured in the real-number of the clock. A special beat is associated to an isolated atomic span on a hidden lifeline. The only way to end the span of a special beat is via a "resume" beat on the hidden lifeline, which names the special beat to be ended. + +The internal activity on the hidden lifeline enforces some description. + +For +example, send-receive descriptions are: send = if paired +receiver is in shared context then resume both else place self into shared context. receive: if paired send is in shared context then resume both else place self into shared context. + +For acquire-release.. acquire: if lock-owner inside shared +context is empty then place self-name into lock-owner +and resume self else place self onto end of sequence +of special beats. release: remove self from lock-owner +and place the next in sequence of special beats into +lock-owner. If non-empty then resume the new lock-owner. +in every case, resume self. Note, acquire-release can +form either a half tie-point or a full tie-point. +? + +==== + +Note to the reader. This is a first pass at a formal description of tie-point. It likely contains more constraints than necessary. It should not be taken as the final formalism, nor is it implied to be elegant in any way, but simply an existence proof for a formal description +of a useful subset of what the intuition of tie-point associates to. + + + + + +\subsection{How a synchronization construct relates +to tie-points} + +To prepare for stating how the tie-point model can be used to +specify a synchronization construct, we first state +clearly what we mean by a ``synchronization construct''. + +The top of Fig \ref{fig:PRSyncConstrDef} shows two +independent timelines, both performing reads and writes +within a machine that has coherent shared memory. The +timelines have no relative ordering defined, so any +write on Timeline A can be received by any read of +the same address on +Timeline B, and vice versa. This means that, in general, +the use of a variable that is read and written by both will result in non-deterministic behavior. + + +\begin{figure}[ht] + \centering + \includegraphics[width = 2.0in, height = 2.8in] + {../figures/PR__timeline_sync_def.pdf} + \caption{Depicts the meaning we adopt for `synchronization construct'. One of them controls communications between timelines +by controlling the slide of timelines relative to each +other. They imply certain visibility between writes and reads on different timelines.} + \label{fig:PRSyncConstrDef} +\end{figure} + + + +To control the behavior of writes and reads to the +same addresses, a common point must be established, which +limits the ``sliding'' of the timelines relative to +each other. A synchronization construct is used for +this. +The net effect of such a construct is to establish +a common point that both timelines agree on. This +point separates reads and writes before it from reads +and writes after it. + +For example, consider a simple lock used to protect a critical section. The lock is acquired by one timeline +before entering the critical section. Any writes performed +on other timelines before the lock was granted must be complete before the critical section starts, so that reads performed inside the critical section see them. This is illustrated in the middle of Fig \ref{fig:PRSyncConstrDef}. + +The critical section ends by releasing the lock, which allows a different timeline to acquire and enter the critical section. As seen in the bottom of Fig \ref{fig:PRSyncConstrDef}, +any writes performed by that new +timeline after it acquires the lock must not be visible +to reads performed by the old timeline before it released +the lock. + +With this intuition, we define a synchronization construct +as an operation preformed on a timeline, which has +the property that it creates +a tie-point together with an operation performed on a different +timeline. Such operations that establish a tie-point +fit our definition of synchronization constructs. + + +\subsection{More on tie-points} + +Fig \ref{fig:dualTimeline} showed how a tie-point can be generated. The establishment was accomplished by +a combination of primitive mechanisms. These include: 1) suspend; 2) an `invisible' timeline that executes +behavior in the gaps; 3) resume +called from that invisible timeline; and 4) enforcement +of instruction completion relative to resume. + +What an established tie-point provides is the notion that the tied points are the same ``instant" for both tied timelines. What that means is that both timelines see events ordered relative to that point in the same way. + + +Notice that the primitives that establish a tie-point +do not involve any notion of dependency or constraint +on order of execution. It is the behavior code that runs on the invisible + timeline that embodies notions such as dependency + between units of work, mutual exclusion, + partial ordering of work, and so on. However, the + primitives do provide the notion of causality, the ordering implied by causality, and enforcing completion +of reads/writes. + +It is up to the language to supply the behavior that happens inside +the gaps, which executes on the invisible timeline. This behavior is what decides which timelines end up +sharing a tie point. It is that decision making, of which timelines to tie together, that implements the +semantics of a synchronization construct. + +A workshop paper also discusses tie points +[]. A formal treatment of tie-points is beyond the scope of this paper. However, a formal framework has been substantially completed and +will be published in a future paper. + + + +\subsection{Tie-points within a proto-runtime} + + Fig \ref{fig:dualTimeline} didn't say what entity owns the hidden timeline that executes the behavior that takes place in the gaps. This is what the proto-runtime does. An instance of the +proto-runtime executes the language plugin behavior. +It acts as the hidden timeline. + + The proto-runtime code module also supplies implementations +of the primitives that are used to establish a tie-point, including these: + + %It provides the primitive that suspends a timeline and then causes language plugin behavior to execute in the gap. + +%The plugin behavior that runs in the proto-runtime when one timeline suspends is what chooses another timeline to resume as a consequence. That choice establishes causality between the suspensions of the two timelines, and in the process ensures that a valid tie will exist between the two collapsed timeline points. The code of the primitives is provided as part of the proto-runtime code module, while the plugin behavior is executed by an instance of a running proto-runtime. + +%The running proto-runtime instance is also known as the Master, while the application timelines are known as Slaves. The behavior of the language constructs executes within the Master's timeline, while the behavior of application code executes within Slave timelines. + +%\subsection{More about the proto-runtime} + +\begin{itemize} +\item create a virtual processor (which has a suspendible timeline) +\item create a task (which has an atomic timeline that runs to completion) + +\item suspend a timeline, then invoke a function to handle the suspension -- handler is supplied with +parameters from application +\item resume a timeline, which makes it ready for execution +\item end a timeline +\item trigger choosing which virtual processor or task to begin execution on an offered +core + +\end{itemize} + +Virtual processors and tasks, both, have associated timelines. The reason for having both is a practical one, as tasks are simpler, with less overhead, +and many languages have the semantics of short, atomic, units of work that +are not intended to suspend. Thus, tasks are treated differently inside the +proto-runtime, and incur less overhead to create and run. + +A special feature of the proto-runtime is that if a task happens to execute +a language command that causes suspension, then the proto-runtime automatically +converts that task to a suspendible virtual processor. This helps support the mixing of different +languages within the same program. + + +The proto-runtime provides a mechanism for communicating information from the application code to the plugin function that was invoked to handle suspension. For example, the identity of a particular mutex a thread wishes to acquire +can be communicated from the wrapper library to the plugin. + + +Because the proto-runtime tracks all the timelines, the end of a timeline has to be explicitly stated in the application code, by calling a wrapper library function. That then invokes the proto-runtime primitive, +which informs the proto-runtime instance. The proto-runtime performs internal bookkeeping related to the ending of the timeline, and notes that the core is now free and offers it to the plugin's Assigner function. + +The proto-runtime involves the language into the process of choosing which core a given task +or virtual processor executes on. The proto-runtime maintains control, but offers free cores to the Assigner +portion of the plugin. It responds by then assigning a task or virtual processor to the core. The proto-runtime just offers, it is up to the language to decide what work that core should receive at that point in time. + + + +\subsection{Concrete Example}\label{subsec:Example} + +To make this concrete, consider the example of implementing +acquire mutex and release mutex. The semantics are: + +\begin{itemize} +\item Acquire Mutex: A thread calls the construct, +and +provides the name of the mutex. If no thread owns the +mutex, the calling thread is given ownership and it +continues to make progress. However, if a different thread +already owns the mutex, the calling thread is put into a queue +of waiting threads, and stops making progress. +\item Release Mutex: A thread calls the construct and +provides the name of the mutex. If the mutex has waiting threads in its queue, then the next thread is taken out and given ownership of the mutex. That thread is resumed, to once again make progress, as it the thread +that called the release construct.. +\end{itemize} + +This calls for a data structure that has two fields: +one holds the thread that currently owns the mutex, +the other holds a queue of threads waiting to acquire +the mutex. The semantics of a construct involve multiple +reads +and writes of the data structure. Hence, the + structure must be protected +from races between different threads. + +The protection +is where the difficulty comes into the implementation, +and where performance issues come into the picture. +It could be accomplished with a single global lock + that uses hardware primitives, or accomplished +with wait-free data structures that only rely upon the coherence +mechanism of the memory system, or even by message passing plus +quorum techniques. + +However, the implementation of the semantics is independent +of the implementation of the protection. They are orthogonal, +and an interface can be placed between them. One side +of the interface implements checking and updating the fields of +the data structure, while the other side implements +protecting the first side from interference. + +The side that provides protection requires fields, +for its use, to be placed into the data structure used +to represent a thread. To hide those details, +the protection side should also provide +primitives to create and destroy threads, as well as suspend +and resume them. + +This interface that separates the semantic side from +the protection +side is the proto-runtime interface. It is what enables +the modularization of runtime system implementations. + +The tie-point concept provides a model for thinking +about how the semantic side controls ordering among multiple threads, without exposing any details of the protection side. The tie-point model involves thinking only about actions taken during suspension of timelines (threads). It assumes that those actions are protected from interference, and that suspend and resume of timelines are primitive operations made available. The model remains constant regardless of implementation details. + That provides a cross-hardware way of specifying synchronization +behavior using just sequential thinking. The proto-runtime primitives implement the elements of the tie-point model. + + %Currently, these constructs are either implemented directly in terms of hardware level synchronization constructs such as the atomic Compare And Swap (CAS) instruction, or else are a thin wrapper that invokes operating system behavior. However, the behavior of the OS\ kernel's threading primitives are themselves implemented in terms of hardware level synchronization +%constructs. Either way, developing the behavior proves +%time consuming due to the difficulty of debugging hardware level synchronization behavior, and due to the difficulty of performance tuning such low level code across the full spectrum of patterns caused by applications. + + + + + +\section{Concrete Details} +Now that we have seen the concepts of how to modularize +a runtime system, using the tie-point model, it is +time to make the concepts concrete by showing code +segments that implement each of the concepts, and code +segments that use the concepts. We will start with +the big picture and work down. + +The first stop will be the development process, showing +how it is fractured into three separate and independent +development activities. Next, we will show examples +of how application +code invokes constructs, and follow the path of calls +down to the point it switches over to the runtime system. Lastly, +we will look at the flow of control inside the runtime, +where we will focus on the interaction between plugin +code and proto-runtime code. + +In this last portion, we will show how the +interface supplies the plugin with a consistent ``inside +the runtime" environment. Along with that, we will +show how providing +a consistent environment + is an implementation of the "single hidden timeline" portion + of the tie-point model. We will also show how it is + the existence of a \textit{single} hidden timeline + that allows the semantic portion of the language constructs +to be written in a sequential style, without regard to concurrency issues. + + +\subsection{Three independent development efforts} + +To get a handle on the big picture, we describe the +three independent paths that development takes: +one for development of proto-runtime code, one for +development of language implementation, and one for +application development. Each of these produces a separate +installable artifact. +The proto-runtime development produces a dynamic library, for each machine. The language development produces a dynamic library to plug into whichever proto-runtime library is installed on a given machine. It may also produce development tools that are used during compilation, distribution, and even installation and during the run. The application development produces a single source, which the language tools may then turn into multiple executables. + +The proto-runtime code is developed separately from +both language and application code, and packaged as a dynamic library. This library has multiple implementations. Each kind of hardware platform has a proto-runtime implemented specifically for it, and is tuned for low overhead on that hardware. The administrator of a particular machine chooses the proto-runtime implementation best suited to that hardware, and installs that. + +The language code is likewise developed separately from both proto-runtime and application code. Although multiple versions of a language may be implemented, there are significantly fewer versions than the number of proto-runtime versions. That is because most of the hardware details are abstracted away by the proto-runtime interface. + +However, the interface does expose hardware features related to placement of work onto cores, so some variations may exist for the same interface. Again, the administrator chooses which language implementation best suits their machine and installs the corresponding dynamic library. + +The wrapper library, however, is not +installed on the machine where code runs. Rather, it +is only used during development of an application, +and remains independent of hardware. + +Ideally the application is developed only once. It makes calls to the wrapper library, which in turn invokes the dynamic libraries of the language and proto-runtime. +When an application is executed, the loader binds the +dynamic libraries, connecting them to the application. + In this way, a single, +unchanging, executable gains access to machine-specific implementations of language and proto-runtime. + +However, the success of the compile-once approach has +limits in practice. Each machine's characteristics determine the size of unit of work that gives the best performance. When too small, the overhead in the runtime system that is required to create the work, manage constraints, and perform assignment becomes larger than the work +itself. When work-unit size is too large, then not enough units exist to keep all the cores busy. Thankfully, the range between is wide enough, for most applications, that neither limit is hit, on most machines. As machines evolve, though, this happy circumstance is likely to change, necessitating recompiling and possibly hand modifying the application code or some meta-form. + +\subsection{Walk through of activity during execution} + +At this point, we present a picture of the flow of control on each +of two cores, as the core is switched between application +code and runtime code. It is too early to understand +the details, but this figure can be referred back to +as each portion is discussed in the coming sub-sections. +Each portion of the figure is labelled with the sub-section that describes that portion of activity. + +At the top is the main program, which starts the proto-runtime, +and creates a proto-runtime process. Below that is +depicted the creation of proto-runtime virtual processors, +along with the animation of application code by those virtual +processors. + +? + +The application passes information to a wrapper library +call, +such as the ID of the mutex to acquire. The library function packages the +information into a request data structure, then invokes a proto-runtime +primitive. That suspends the virtual processor (timeline) that is executing +that code. The call to the primitive passes as arguments the request structure and a pointer +to the plugin function that will handle the request. +The handler runs inside the Master and chooses which +other timelines to resume as a consequence of the wrapper-library +call. Those timelines will then resume, returning from +whatever wrapper-library call caused them to suspend. In this way, the request handle implements the behavior of a +synchronization construct. + +However, there is one last step between the request +handler marking a timeline as ready to resume +and it becoming re-animated. That step is where the +assignment half of the language plugin comes into play. +The request handlers stack up work that is free to +be executed, but it is the assigner that chooses which +of those to place onto an offered core. + + + + + +\begin{figure*}[ht] + \centering + \includegraphics[width = 7.0in, height = 4.5in] + {../figures/Proto-Runtime__modules_plus_plugin_plus_code.pdf} + \caption{Illustration of the physical time sequence of the timelines of multiple virtual processors executing on multiple +cores. The timelines run top to bottom, while calls +between modules and returns run horizontally. The colors of Fn names indicate whether the +code is part of the application (green), the proto-runtime module (blue), or the language (red). The top two timelines are animated +by core 1, while the bottom 2 are animated by core +2. The boxes +represent virtual processors, each with its associated +timeline next to it. The timelines have no relative +ordering, except at tie-points established by the Request +Handlers. Gaps in the timelines are caused by suspension, +which is effected by primitives within the proto-runtime +code module.} + \label{fig:langBreakdown} +\end{figure*} + + + +\subsection{Using language constructs} +In the simple form of an eDSL, the language constructs +take the form of function calls. The reader familiar +with posix threads will have used function calls to +perform mutex acquire commands and mutex release commands. +Here, we illustrate invoking language commands in the +same way. + +We use posix threads for our example because it is +a familiar language that the reader already knows well. +It allows us to illustrate the concepts new to proto-runtime without introducing potential confusion about what the language semantics are. + +\subsubsection{Main and startup} +Before using a proto-runtime based language, the proto-runtime +system must be started, and a proto-runtime process +must be created. Fig X shows this. Notice that the +create process was given a pointer +to a function. This function is the seed of the proto-runtime +based application code. This seed must start all proto-runtime +based languages that will be used in the application, +and must create the virtual processors and tasks that +perform the work and may in turn create more VPs and/or tasks that perform work. + +==main, with PR\_\_start and PR\_\_create\_process == + +\subsubsection{Seed birth function and thread birth +function} +Fig X shows our example seed function. It first starts +the language that will be used, which is Vthread. It +is an implementation of posix threads that is on top of proto-runtime. +Next, the seed uses Vthread commands to create two +threads, and then uses Vthread join to wait for both +threads to die. Lastly it "dissipates", which is the +command that kills the virtual processor that is animating +the function. + +==seed\_birth\_Fn, with Vthread\_\_start(), Vthread\_\_create\_thread, +Vthread\_\_join, Vthread\_\_stop, and dissipate== + +Notice the signature +of the seed birth function. It returns void, and takes a pointer +to void plus a pointer to a SlaveVP struct. This is +the standard signature that must be used for all birth functions for +proto-runtime created virtual processors or tasks. + + +Also, notice that the standard signature includes a +pointer to a SlaveVP struct. This is a proto-runtime +defined structure, which holds the meta-information +about a virtual processor. The birth function is handed +the structure of the virtual processor that is animating +it. + +An illuminating aside is that the birth function for +a posix thread doesn't need +to be handed the structure representing the animating thread. +That is because the operating system tracks which thread +is assigned to which core. Posix thread constructs work by executing +an instruction that suspends the code executing on +the core and switches +the core over to animating the OS kernel code. The OS kernel +then looks up the data structure that is assigned to +the core. + +That lookup is how the OS kernel gains the +pointer to the thread that was animating the application +code that called the posix construct. But the implementation +of proto-runtime illustrated in this paper doesn't +have such a hardware based suspend instruction available, +and so proto-runtime-based application code must explicitly pass around the pointer to the data +structure of the virtual processor performing the animation. + +Fig X shows the birth function of the threads created +by the seed birth function. It uses the Vthread equivalent +of mutex acquire and release to protect access to +a critical section. Notice that the signature +is the same as the signature of the seed birth function. +Also notice that the SlaveVP structure is handed to +each invocation of a Vthread construct. In the next +several sub sections we will track how this SlaveVP structure +is used. + +==thread birth function.. uses Vthread acquire and +release to protect a counter plus print of count value== + + +\subsection{Language Wrapper Library} + +Looking at the implementation of the Vthread calls +reveals code such as in Fig X. + +==wrapper lib code for mutex acquire== + +There's nothing much to it. It just creates a data +structure, fills it, then hands it to a proto-runtime +call. This is a starnd form for wrapper library +calls. The data structure is used to carry information +into the proto-runtime (the proto-runtime that was +started by the PR\_\_start command). The PR call is +the equivalent of the hardware instruction that suspends +application code and switches to the kernel. For the +implementation of PR illustrated in this paper, this +call is implemented with assembly instructions. + +This wrapper library code is placed on the machine +used during development of the application, and is +compiled into the application executable. However, +the proto-runtime call is a link to a dynamic library, +and is not part of the application executable. + +Notice that the PR\ primitive is given a pointer to +a function. This is called the handler function, and +is part of the language plugin. The proto-runtime +will actually perform the call to the handler function, but in a carefully controlled +way. It will provide the handler function with a carefully controlled environment +to use while it handles this wrapper-library call. +We will see in a moment how proto-runtime invokes the +handler function, and what such a handler function +looks like. + +First, here's the assembly that suspends the application code and +switches to the proto-runtime code, as seen in Fig X + +==assembly of suspend and switch== + +All it does is save the program counter and stack pointer +into the SlaveVP structure, then load in the program +counter and stack pointer of the proto-runtime code, +which was previously saved in different fields of that same SlaveVP structure. + +\subsubsection{proto-runtime code that is switched +to} + +The PR assembly code switches the core to executing +the (psuedo) code seen in Fig X. + +==animation master code, which calls plugin fns== + +All this does is invoke the handler function named +in the wrapper library, and hands it an environmen. +This is the hidden environment referred to in the tie-point +model. It must be accessed in an isolated, atomic, +fashion. The proto-runtime code seen here happens +to use a global lock for each language's environment. + However other implementations are possible. In order + to keep overhead low, it uses the Compare And Swap + instruction to acquire the lock, and an exponential random + backoff scheme when contention for the lock arises. + + The handler function is the hidden behavior that executes + on the hidden timeline that is mentioned in the tie-point + model. The suspend primitive is what begins a special + beat on the lifeline of the virtual processor that + executed the wrapper library call. It is this handler + code that then establishes the causal connections + between such special beats, and so ties them together. + The causal connection is via the changes make to the + language environment. + + So, in summary, the proto-runtime is the hidden timeline. + The suspend primitive is what starts a special beat + and starts the behavior on the hidden timeline. The + lock is what isolates and sequentializes + the behavior on the hidden timeline. The language + environment is the hidden state used to establish + causal connection between special beats. + + + +This is not the plugin code, this is the library that the application executable includes. It's equivalent to the pthread library. When you look at the source of the pthread library, it's just a wrapper that invokes the OS. It doesn't do anything itself. The language libraries are the same thing, just wrappers that invoke the proto-runtime primitives. Those suspend the VP and send a message to the proto-runtime. When the message arrives, it invokes the plugin to handle the task. + +Here's how the wrapper library connects a request to the request handler: via this function pointer, right here Fig X, given to the proto-runtime "suspend and send" primitive. The pointed-to function is part of the plugin. That runs inside the proto-runtime, and is what handles the message created in the wrapper library. + + +If we go and look at that handler function, Fig X, we see that it has a standard prototype, so it takes a standard set of arguments. One of those, here in Fig X, is a language environment. This is the special sauce, it is the thing that is shared among all the cores. This language environment is where tasks are placed that are not yet ready to execute, and where suspended virtual processors are placed that are not yet ready to resume. + +Here, Fig X, you can see there's a hash table. The language environment contains that hash table. The tasks get parked in this hash table. Each time a task completes, it looks in the hash table, finds all tasks waiting for its completion, and updates the status of those waiting tasks. If this was the last task being waited for, the waiter is taken out of the hash table and put into the queue of ready to execute tasks. + +This is the semantics of the language. This is how the semantics of the language defines what dependencies are, and how it defines when a task's dependencies have been satisfied. The implementation is just a data structure in the shared language environment. It is the proto-runtime that takes care of creating the tasks, creating the virtual processors, execute those, suspend them and resume them. The proto-runtime handles the mechanics of all that stuff. The language just figures out what are the constraints on making it ready. + +? + +Separately, the proto-runtime calls the Assigner function, which is also part of the plugin dynamic library. Each time a task completes or a virtual processor suspends, the wrapper library invokes a proto-runtime primitive. Among other things, that primitive informs the proto-runtime about the completion of that work, which tells the proto-runtime that hardware resources have just been freed up. + +The proto-runtime then invokes the Assigner function, passing it information about the hardware that was just freed. The assigner is implemented by the language and uses some language-specific way to choose which of the ready work-units to execute on that hardware (a work-unit is either a ready-to-execute task or a ready-to-resume virtual processors). This is how the language is given control over placement of work onto cores. + +=================== + + +\subsection{not sure} +A task is an atomic unit of work. It runs to completion, without suspending. That characteristic allows the proto-runtime to internally treat a task differently than a virtual processor. The fact that it never suspends means it doesn't need a stack, and needs less bookkeeping, which makes a task faster to create and faster to assign, for lower overhead. + +However, a task may optionally choose at some point to execute a language command that causes it to suspend. At the point it does that, the proto-runtime internally converts the task to a virtual processor. That allows the task to suspend and later resume, at the cost of gaining the normal virtual processor overhead. However, the virtual processor the task is converted to comes from a recycle pool and returns when the task completes. + +As an application programmer, you can create processes directly with an OS-like language built on top of the proto-runtime. But you use a programming language to create tasks or virtual processors. For example, VSs has a way to create tasks. VSs internally then uses a proto-runtime command to have the proto-runtime create a task for it. Then VSs decorates the task with its own meta-data. It uses that meta-data to track when a task should be executed. + +? + +The only thing you're allowed to do outside a language is create the environment in which you start a language. + +? + +The implementation of the language behavior is the plugin. The plugin has two parts: request handlers, which handle the messages that come when a VP suspends, and an assigner, which picks where particular VP resumes onto or a task runs. With VSs, the plugin provides the behavior of "submit task". +The request handler plus plugin together provide the two halves of what people normally call a scheduler. + +================= + +\subsection{more on tie-points} +Any event visible before in one is visible in both after. The guarantee is between before in one and after in both. + +From the program point of view, that acquire statement is one instant. That entire gap in physical time is seen as a single instant to the code. + +However, the tie point is just one instant in the timelines. After the point, one of the timelines could perform an event that interferes with an event from before the tie-point, and no guarantees are given about what the other timeline sees. However, if another tie-point is created between them, then they are both guaranteed to see that second, interfering event, after the second tie-point. + +Take the example of a mutex, M. The purpose of the only-one semantics of a mutex is to isolate read and write operations done by the owning thread from those done by other threads, which own before or after it. + +The mutex behavior is illustrated in Fig X. Timeline 1 writes to variable A at point 1, then releases the M at point 2. Timeline 2 acquires M, at the tied point 2 and reads A at point 3. For M to provide isolation, it must guarantee that the A write operation at point 1 is seen by the other timeline's read operation, at point 3. Likewise, it has to guarantees that nothing that happens in timeline 2 after the acquire of M, at point 2, will be seen by timeline 1 before its release, also at point 2. + +That ordering guarantee is what we think of when we imagine the behavior of a mutex acquire-release pair. All writes done by the releasing thread are seen as completed, by reads performed in the acquiring thread, and no writes in the acquiring thread are seen before the release by the releasing thread. That is required in order to have value for the semantics of only one thread owns the mutex at any point. The purpose of only-one is to isolate read and write operations done by the owning thread from those done by the threads that own before or after it. + + +The behavior is implemented in terms of a data structure that lives inside the controlling entity's environment. The controlling entity looks up the data structure for the mutex being requested. This data structure has a field that contains the name of the thread that current owns the mutex, plus a queue of threads waiting to acquire it. So, the controlling entity first looks at the field that holds the current owner, sees that it is occupied, and then puts the thread's name into the queue of waiting threads. + +At some point later, the waiting thread reaches the top of the queue. At the point the owning thread executes the release operation, that owning thread also suspends, the controlling entity sees that suspend and that the thread wants to perform the release behavior. It looks up the release behavior and performs it. This behavior looks up the mutex data structure in the controlling entity's environment, removes the releasing thread from the owner field, takes the top thread off the waiters, writes its name into the current owner, then marks both those threads as ready to resume their timelines. + +The proto-runtime is the controlling entity, which looks up the behaviors and performs them. It also manages the environment that holds the data structures used by the behaviors. + +=========== + +The purpose of the M is to guarantee that what gets written to A here in this timeline is seen over here, in this other timeline. + +So, to turn this simple mechanism into a synchronization construct, you add semantics on top, which determine the end of suspend in the two timelines. The timelines voluntarily place themselves into suspend, and it is up to the controlling entity to decide at what point to end that suspension. It is this choice of ending suspension that ties events in one timeline to events in another. The semantics of deciding that end of suspension is the semantics of the synchronization construct. + +For example, take mutual exclusion within Threads. One thread executes a construct that asks to acquire the mutex. At the point of executing, that thread suspends, so that timeline ceases advancing. At some point later, the controlling entity sees that suspend, and sees that the timeline is attempting the acquire mutex activity. It looks up the behavior for acquire mutex, which is then performed inside that controlling entity. + +============ + + +\subsection{More on eDSLs} +%====================================== + +%We expand on the hypothesis that an embedded style Domain Specfic Language (eDSL) provides high programmer productivity, with a low learning curve. We also show (\S ) that when an application is written in a well designed eDSL, porting it to new hardware becomes simpler, because often only the language needs to be ported. That is because the elements of the problem being solved that require large amounts of computation are often pulled into the language. Lastly (\S ), we hypothesize that switching from sequential programming to using an eDSL is low disruption because the base language remains the same, along with most of the development tools and practices. + +%In \S \ref{sec:DSLHypothesis} we show that the small number of users of an eDSL means that the eDSL must be very low effort to create, and also low effort to port to new hardware. At the same time, the eDSL must remain very high performance across hardware targets. + +%In \S we analyze where the effort of creating an eDSL is expended. It turns out that in the traditional approach, it is mainly expended in creating the runtime, and in performance tuning the major domain-specific constructs. We use this to support the case that speeding up runtime creation makes eDSLs more viable. + +%In \S we take a step back and examine what the industry-wide picture would be if the eDSL approach were adopted. A large number of eDSLs will come into existence, each with its own set of runtimes, one runtime for each hardware target. That causes a multiplicative effect: the number of runtimes will equal the number of eDSLs times the number of hardware targets. Unless the effort of implementing runtimes reduces, this multiplicative effect could dominate, which would retard the uptake of eDSLs. + + +% ============== + +%Further, in \S we show that when an application is written in a well designed eDSL, porting it to new hardware becomes simpler because often only the language needs to be ported. That is because the elements of the problem being solved that require large amounts of computation are often pulled into the language. Lastly, in \S we hypothesize that switching from sequential programming to using an eDSL is low disruption because the base language remains the same, along with most of the development tools and practices. Hence, we cover how the three issues currently making parallel programming unattractive are addressed by embedded-style DSLs. + +%We next show what the blocks to eDSLs are, and where the main effort in implementing an eDSL lies. Specifically, in \S \ref{sec:DSLHypothesis} we show that the small number of users of an eDSL means that the eDSL must be very low effort to create, and also low effort to port to new hardware. At the same time, the eDSL must remain very high performance across hardware targets. + +%In \S we analyze where the effort of creating an eDSL is expended. It turns out that in the traditional approach, it is expended in creating the translator for the custom DSL syntax, in creating the runtime, and in performance tuning the major domain-specific constructs. We propose that the MetaBorg[] or Rose[] translation approaches cover creating translators for custom syntax, and that tuning constructs is inescapable, leaving the question of runtime implementation time. + +%In \S we explore the effects of runtime implementation time by taking a step back and examine what the industry-wide picture would be if the eDSL approach were adopted. A large number of eDSLs will come into existence, each with its own set of runtimes, one runtime for each hardware target. That causes a multiplicative effect: the number of runtimes will equal the number of eDSLs times the number of hardware targets. Unless the effort of implementing runtimes reduces, this multiplicative effect could dominate, which would retard the uptake of eDSLs. Thus, showing that an approach that mitigates this multiplicative effect is valuable, and is the role that the proto-runtime plays. + + + +%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% +\subsection{Details} +\label{subsec:Details} + + what responsibilities are encapsulated in which modules, and what the interfaces between them look like. + +modularization and its interface is what makes the proto-runtime reusable by all languages on given hardware, and the low-level tuning of the proto-runtime for specific hardware automatically benefits all the languages on that hardware. + +? + + + + overhead measurements + +implementation time measurements + + discuss why equivalent user-level M to N thread packages haven't been pursued, leaving no viable user-level libraries to compare against. + + give numbers that indicate that the proto-runtime approach is also competitive with Cilk, and OMPSs, on large multi-core servers. + + summary of development time of the various embedded languages created so far. Unfortunately, no control is available to compare against, but we provide estimates based on anecdotal evidence of the time taken to develop the versions compared against for overhead. In the +least, the same effort would have to be expended on +each and every language that we expended on performance +tuning our proto-runtime. + + We continue with a bigger picture discussion of the difference in design methods between traditional approaches and the proto-runtime implementations (\S ). We discuss OpenMP versus the equivalent proto-runtime version called VOMP (\S ). Then (\S ) we discuss Cilk 5.4 vs the proto-runtime VCilk. Next we discuss pthread vs Vthread (\S ), and OMPSs vs VSs (\S ). These discussions attempt to give the two design philosophies and paint a picture of the development process in the two competing approaches. The goal is to + +illustrate how the proto-runtime approach maintains many of the features, through its centralized services, while significantly reducing implementation time, through reuse of the services, elimination of concurrency concerns in design and debugging, and in the simplifications in design and implementation caused by the clean modularization of the proto-runtime approach, and the regularization of implementation from one language to another. + +Then, with the full understanding of the proto-runtime approach in hand, we discuss how it compares to related work (\S ). + +Finally, we highlight the main conclusions drawn from the work (\S ). + + + +? + + + + + The behavior module creates work and determines when work is free the execute, it tracks constraints on work imposed by language semantics, and constraints +due to data dependencies. + + a copy of the proto-runtime with language modules runs separately on each core and they communicate via shared variables in a shared language environment. The proto-runtime protects access to the shared language environment so that language modules can be written in sequential style. + +? + +The proto-runtime also implements "centralized" services that it makes available to all languages. Hardware specific functions include communicating between processors and protecting the internal state used by the language modules. + + + + this makes the proto-runtime be reused by all languages on given hardware, and the low-level tuning of the proto-runtime for specific hardware automatically benefits all the languages that run on that hardware. + + implementing language logic, + +show how the proto-runtime interface allows it to use sequential thinking. + +give similar detail on the implementation of the assigner, +we discuss how that has the potential to improve application performance by reducing communication between cores and reducing idle time of cores. + +support belief that the patterns we followed when modularizing are indeed fundamental and will remain valid for future languages and hardware. + + discuss some of the centralized services provided by the current proto-runtime implementation, as well as planned future ones. + +reusing language logic from one language implementation to another. + + +%%%%%%%%%%%%%%%%%%%%%%%% +%% +%%%%%%%%%%%%%%%%%%%%%%%% +\section{Measurements} +With the background on eDSLs and description of the proto-runtime approach behind us, we then provide overhead measurements in \S\ref{subsec:OverheadMeas} and implementation time measurements in \S\ref{subsec:ImplTimeMeas} + +\subsection{Overhead Measurements} \label{subsec:OverheadMeas} +For the following, we use a 4-core single socket 2.4Ghz laptop, and a 4 socket by 10 core each server. + +For runtime performance: + +-- Vthread vs pthread: laptop and server on exe vs task (and fibonacci?) + +-- VCilk vs Cilk: laptop and server on fibonacci (from Albert) + +-- VOMP vs OpenMP: laptop and server on exe vs task and fibonacci + +-- VSs vs OMPSs: laptop and server on fibonacci and jpeg + +\begin{tabular}{|c|c|c|c|c|c|c|}\hline +a & 2 & a & a & a & a & a \\\hline +a & 2 & a & a & a & a & a \\\hline +a & a & a & a & a & a & a \\\hline +a & a & a & a & a & a & a \\\hline +\end{tabular} +\caption{} +\label{tab} + +As seen, we didn't include application performance because we have not yet taken advantage of the opportunity to use language information to predict locality. That research is in progress and will be reported in future papers. + + +\subsubsection{Vthread Versus Highly Tuned Posix Threads} + +Measurements indicate that the proto-runtime approach has far lower overhead than even the current highly tuned Linux thread implementation, and discusses why equivalent user-level M to N thread packages haven't been pursued, leaving no viable user-level libraries to compare against. +\subsubsection{VCilk Versus Cilk 5.4} +In \S we give numbers that indicate that the proto-runtime approach is also competitive with Cilk +\subsubsection{VSs Versus StarSs (OMPSs)} +OMPSs +\subsubsection{VOMP Versus OpenMP} +VOMP + + +%%%%%%%%%%%%%%%%%%%%%%%% +%% +%%%%%%%%%%%%%%%%%%%%%%%% +\subsection{Development Time Measurements}\label{subsec:ImplTimeMeas} +Here we summarize the time to develop each of the eDSLs and copy-cat languages created so far. As a control, we estimate how long the equivalent functionality required, using the traditional approach, based on anecdotal evidence. + +Summarized in Table \ref{tabPersonHoursLang}, we measured the time we spent to design, code, and get an initial version working for each of the languages we created. The results are shown in the same order we created them, with SSR the first. As we gained experience, design and coding became more efficient. Not shown is the 7 hours required to take the send-receive code from SSR and adapt it to work with tasks in VSs. In addition, 11 hours was spent importing the DKU constructs into VSs. These are hours spent at the keyboard or with pen and paper, and don't include think time during other activities in the day. + + +\begin{centering} +\begin{tabular}{|l|r|r|r|r|r|r|} + \cline{2-7} + \multicolumn{1}{r|}{} & SSR & Vthread & VCilk & HWSim & VOMP & VSs\\ + \cline{2-7} + \noalign{\vskip2pt} + \hline + Design & 19 & 6 & 3 & 52 & 18& 6\\ + Code & 13 & 3 & 3& 32 & 9& 12\\ + Test & 7 & 2 & 2& 12 & 8& 5\\ + L.O.C. & 470 & 290 & 310& 3000 & 690 & 780\\ + \hline +\end{tabular} +\caption +{Hours to design, code, and test each embedded language. L.O.C. is lines of (original) C code, excluding libraries and comments. +} +\end{centering} +\label{tabPersonHoursLang} + +\subsubsection{Comparison of Design Approaches} +We give the bigger picture of the difference in design methods between traditional approaches and the proto-runtime implementations, discussing OpenMP versus VOMP, Cilk 5.4 vs VCilk, pthread vs Vthread, and OMPSs vs VSs. These discussions attempt to give the two design philosophies and paint a picture of the development process in the two competing approaches. The goal is to illustrate how the proto-runtime approach maintains many of the language features, through its centralized services, while significantly reducing implementation time, through reuse of the services, elimination of concurrency concerns in design and debugging, and in the simplifications in design and implementation caused by the clean modularization of the proto-runtime approach, and the regularization of implementation from one language to another. + + +%%%%%%%%%%%%%%%%%%%%%%%% +%% +%%%%%%%%%%%%%%%%%%%%%%%% +\section{Related Work} \label{sec:Related} + +With the full understanding of the proto-runtime approach in hand, we discuss how it compares to other approaches for implementing the runtimes of domain specific languages. The criteria are: level of effort to implement the runtime, effort to port the runtime, runtime performance, and support for application performance. The main alternative implementation approaches are: posix threads, user-level threads, TBB, modifying libGomp, and using hardware primitives to make a custom runtime. + +We first talk about each of these approaches, then summarize the conclusions in Table \ref{tab:CriteriaVsApproach}. + +The first three methods involve building the DSL runtime on top of OS threads, user threads, or TBB, all of which are languages in their own right. So the DSL runtime runs on top of the runtime for that lower-level language. This places control of work placement inside the lower-level runtime, blocking the DSL runtime, which hurts application-code performance, due to inability to use data locality. In addition, OS threads have operating system overhead and OS-imposed fairness requirements, which keeps runtime performance poor. + +All three also force the DSL implementation to manage concurrency explicitly, using language primitives such as locks. TBB may have a slight advantage due to its task-scheduling commands, but only for task-based languages. Hence, implementation effort is poor for these approaches. + +For the same reason, for these three, the runtime code needs to be rewritten and tuned for each hardware platform for each language, or else some form of hardware-abstraction placed into the runtime. But putting in a hardware abstraction is essentially an alternative way of implementing half of the proto-runtime approach, but without the centralization, reuse, and modularization benefits. + +Many language researchers use libGomp (based on informal discussions) because of its very simple structure, which makes it relatively easy to modify, especially for simple languages. However, it provides no services such as debugging or performance tuning, and it has no modularization or reuse across languages benefits. As the price of the simplicity, performance suffers, as seen in the experiments []. Also, re-writes of the DSL runtime are required for each platform in order to tune it to hardware characteristics. However, because the runtime is directly modified, the language gains control over placement of work, enabling good application performance. + +Lastly, we consider the alternative of writing a custom runtime from scratch, using hardware primitives such as the Compare And Swap (CAS) instruction, or similar atomic read-modify-write instructions. This approach requires the highest degree of implementation effort, and the worst portability across hardware. However, if sufficient effort is expended on tuning, it can achieve the best runtime performance and equal the best performance of application code. So far, the gap has proven small between highly tuned language-specific custom runtime performance and that of our proto-runtime, but we only have the CILK implementation as a comparison point. + +Putting this all together, Table \ref{tab:CriteriaVsApproach} shows that the proto-runtime approach is the only one that scores high in all the mesures. It makes initial language implementation fast, as well as reduces porting effort, while keeping runtime performance high and enabling high application performance. + +\begin{center} +\begin{tabular}{|c|c|c|c|c|}\hline +Runtime Creation & \textbf{impl.}& \textbf{porting} & \textbf{runtime} & \textbf{application} \\ +\textbf{} & \textbf{ease} & \textbf{ease} & \textbf{perf.} & \textbf{perf.}\\\hline +\textbf{OS Threads} & ++ & ++ & + & + \\\hline +\textbf{User Threads} & ++& ++ & ++ & + \\\hline +\textbf{TBB} & ++ & ++ & ++ & + \\\hline +\textbf{libGomp} & +++ & ++ & +++ & ++++ \\\hline +\textbf{HW primitives} & + & + & +++++ & +++++ \\\hline +\textbf{Proto-runtime} & +++++ & +++++ & ++++ & +++++\\\hline +\end{tabular} +\end{center} +\caption{The table shows how well each approach scores in each measure important to the implementor of a runtime for a DSL. On the left are the approaches that can be used to write the runtime. At the top are the measures an implementor may care about. For all measures, one plus is the lowest score, indicating the implementation approach is undesirable, 5 indicates the highest desirability. The scores are based on reasons discussed in the text. } +\label{tab:CriteriaVsApproach} + + + + +%%%%%%%%%%%%%%%%%%%%%%%% +%% +%%%%%%%%%%%%%%%%%%%%%%%% +\section{Conclusions and Future Work} +The main takeaways from the paper are first, the potential for embedded style Domain Specific Languages (eDSLs) to address the issues that are holding-back parallel programming, and second the role that the proto-runtime approach can play in making eDSLs practical, by simplifying the runtime aspect of implementing a large number of eDSLs across the many hardware targets. +%The proto-runtime approach does this by modularizing the runtimes, providing reuse of centralized services, and reuse of the hardware-specific performance tuning, which is performed once per hardware, on the proto-runtime, then enjoyed by all the eDSLs. Hence, the proto-runtime approach provides a significant piece of the puzzle of providing eDSLs, to bring parallel programming into the mainstream. + + +%[[Hypothesis: Embedded-style DSLs -> high productivity + low learning curve + low disruption + low app-port AND quick time to create + low effort to lang-port + high perf across targets]] + + +Specifically, we have shown how the approach modularizes runtime code, in a way that appears applicable to any language or execution model. It isolates the hardware-specific portion from language behavior as well as from the language-driven placement of work onto resources, providing interfaces between them. + + The modularization reduces the effort of implementing a new language, especially for an embedded-style one where runtime creation is a significant portion of total effort. It causes the low level hardware portion to be reused by each language. And, the behavior implementation is simplified, by handling shared state inside the proto-runtime and exporting a sequential interface for the behavior module to use. The simplification reduces effort, as does reuse of the hardware-specific portion, reuse of behavior code from one language to another, reuse of assignment code, and familiarity with the modular structure by implementors. Overall effort reduction was supported by measurements of implementation effort. + +The proto-runtime approach makes it practical to maintain high overall runtime performance, with low effort for the language implementor. It is practical because high effort is put into performance-tuning the hardware-specific proto-runtime, which is then reused by each language. In this way the performance derived from the high tuning effort is inherited without extra effort by the language creators, thus amortizing the cost. + +Centralized services were implemented inside the proto-runtime portion, such as debugging facilities, automated verification, concurrency handling, hardware performance information gathering, and so on. We showed how they are reused by the languages. + +Although we didn't measure it, we indicated how application performance can be increased due to giving the language direct control over placement of work, to take advantage of data affinity or application-generated communication patterns. This ability is due to the assignment module, which provides the language implementor with control over which core work is assigned to, and the order of executing each work unit. + +Work on the proto-runtime approach is in its infancy, and much remains to be done, including: +\begin{itemize} +\item Creating related interfaces for use with distributed memory hardware, and interfaces for hierarchical runtimes, to improve performance on many-level hardware such as high-performance computers, and to tie together runtimes for different types of architecture, to cover heterogeneous architectures and machines. +\item Extending the proto-runtime interface to present hardware information that a work-assigner will need, but in a generic way that remains constant across many hardware configurations yet exposes all relevant information. +\item Exploring work assignment implementations that take advantage of language and application knowledge to improve placement of work to gain higher application performance. +\item Applying the proto-runtime approach to support a portability software stack, and supply OS services to applications via the proto-runtime, to further increase application-code portability. +\end{itemize} + + +============================================= +== +== +== +== +== +============================================= + +\section{The Problem} + +[[Hypothesis: Embedded-style DSLs -\textgreater\ high productivity + low learning curve + low app-port + low disruption]] + +[[Bridge: Few users-\textgreater\ must be quick time to create + low effort to lang-port + high perf across targets]] + +[[Bridge: effort to create = runtime + effort port = runtime + perf on new target = runtime]] + +[[Bridge: big picture = langs * runtimes -\textgreater runtime effort critical]] + + +[[Claims: given big picture, runtime effort minimized -\textgreater modularize runtime, mod works across langs bec. fund patterns, mod sep lang logic from RT internals, mod makes internal reusable + lang inherit internal perf tune +inherit centralized serv, mod makes lang logic sequential, mod makes constructs reusable one lang to next, mod causes lang assigner to own HW]] + +While talking about the problems encountered by Domain Specific Languages (DSLs), we focus on implications for the runtime system, due to its central role in the claims. At the same time we will support the hypothesis that embedded-style DSLs are high-productivity for application programmers, have a low learning curve, and cause low disruption to current programming practices. While doing this we set the ground work for the next section, where we show that the main effort of implementing embedded-style DSLs is creating the runtime, and that when using the proto-runtime approach, embedded-style DSLs are low-effort to create and port and move the effort of porting for high performance out of the application and into the language. + +To give the needed depth, we'll first talk about a way to classify parallel languages according to the structure of their runtime (subsection \ref{subsec:ClassifyingLangs}). Then we'll talk about the sub-class of domain specific parallel languages, what sets them apart, and the implications for their runtime implementations (subsection \ref{subsec:DomSpecLangs}). That segues into the embedded style of language, and how the work of implementing them is mainly the work of implementing their runtime (subsection \ref{subsec:EmbeddedDSLs}). + +Once that reduction from parallel languages in general to embedded style domain specific ones in particular is done, we'll give more on what embedded style DSLs look like from an application programmer's view (subsection \ref{subsec:AppProgViewOfDSL}). We will include depth on a particular embedded-style language, showing sample code that uses the constructs, then delving into needs within the implementation of that language, and behavior of the constructs during a run (subsection []). + +The main implications for runtime systems, which were uncovered within the section, are summarized at the end (subsection []). + +\subsection{Classifying parallel languages by virtual processor based vs task based} +\label{subsec:ClassifyingLangs} +[[Hypothesis: Embedded-style DSLs -\textgreater\ high productivity + low learning curve + low app-port + low disruption]] + +[[Bridge: Few users-\textgreater\ must be quick time to create + low effort to lang-port + high perf across targets]] + +[[Bridge: effort to create = runtime + effort port = runtime + perf on new target = runtime]] + +[[Bridge: big picture = langs * runtimes -\textgreater runtime effort critical]] + + +[[Claims: given big picture, runtime effort minimized -\textgreater modularize runtime, mod works across langs bec. fund patterns, mod sep lang logic from RT internals, mod makes internal reusable + lang inherit internal perf tune +inherit centralized serv, mod makes lang logic sequential, mod makes constructs reusable one lang to next, mod causes lang assigner to own HW]] + +One major axis for classifying parallel languages is whether they are virtual processor based or task based, which has implications for the structure of the runtime. + +A virtual processor is long-lived, and has a context that persists across suspend and resume, while a task has no preceding context to fit into and leaves no implied context when done. Posix threads is a standard example of a virtual processor based parallel language, as are UPC, Charm, TBB, and so forth. All of these create virtual processors (aka threads), which suspend when they invoke synchronizations and other parallel-language constructs then resume after the construct completes. Such virtual processors have their own private stack to save the information that is needed upon resume. + +In contrast, dataflow is a standard example of a task based language, as is CnC. For these languages, a task is passed all the information it needs at the point of creation, and is expected to run to completion. If a task needs to invoke a parallelism construct, that invocation normally ends the task, while information needed by following tasks is saved explicitly in shared variables, or passed to the runtime as a continuation that is then handed to the task created when the construct completes. + +Hybrids of the two also exist, such as OpenMP which implies thread creation, via the parallel-pragma, but also creates tasks via the for-pragma. As well, StarSs (OMPSs) mixes the two, with a main thread that creates meta-tasks that have to resolve their dependencies before being turned into executable tasks. Those tasks are also able to invoke barriers and other synchronization constructs, then resume. + +The runtime implementations of the two different types of execution model differ markedly. Virtual processor (VP) based runtimes have to create a stack for each VP created, and manage the interleaving of the CPU's hardware stack. They also require a mechanism to suspend and resume the VPs, and save them in internal structures while suspended. + +In contrast, task based runtimes need ultra-fast creation of tasks, and fast linkage from the end of one to the start of the next. They tend to keep the task-structures in a queue and discard them when complete. + +Hence, VP based runtimes revolve around storing suspended VPs inside structures that embody the constraints on when the VP can resume. But task based runtimes revolve around the conditions upon which to create new tasks, and the organization of the inputs to them. The runtimes for hybrid languages have characteristics of both. + + +\subsection{Domain specific parallel languages} +\label{subsec:DomSpecLangs} +[[Hypothesis: Embedded-style DSLs -\textgreater\ high productivity + low learning curve + low app-port + low disruption]] + +[[Bridge: Few users-\textgreater\ must be quick time to create + low effort to lang-port + high perf across targets]] + +[[Bridge: effort to create = runtime + effort port = runtime + perf on new target = runtime]] + +[[Bridge: big picture = langs * runtimes -\textgreater runtime effort critical]] + + +[[Claims: given big picture, runtime effort minimized -\textgreater modularize runtime, mod works across langs bec. fund patterns, mod sep lang logic from RT internals, mod makes internal reusable + lang inherit internal perf tune +inherit centralized serv, mod makes lang logic sequential, mod makes constructs reusable one lang to next, mod causes lang assigner to own HW]] + +Now we'll talk about the sub-class of Domain Specific Languages (DSLs): what sets them apart from other parallel languages, how they potentially solve the issues with parallel programming, and the implications for their runtime implementations. + +DSLs can be any of the three basic language types (VP based, task-based or hybrid), but they are distinguished by having constructs that correspond to features of one narrow domain of applications. For example, we have implemented a DSL that is just for use in building hardware simulators [cite the HWSim wiki]. Its constructs embody the structure of simulators, and make building one fast and even simpler than when using a sequential language, as will be shown in Subsection []. The programmer doesn't think about concurrency, nor even about control flow, they simply define behavior of individual hardware elements and connect them to each other. + +It is this fit between language constructs and the mental model of the application that makes DSLs highly productive and easy to learn, at the same time, it is also what makes applications written in them more portable. Application patterns that have strong impact on parallel performance are captured as language constructs. The rest of the source code has less impact on parallel performance, so just porting the language is enough to get high performance on each hardware target. + +In practice, designing such a language is an art, and for some hardware targets, the language can become intrusive. For example, for porting to GPGPUs, their performance is driven by decomposition into many small, simple, kernels, which access memory in contiguous chunks. Fitting into this pattern forces rearrangement of the base sequential code, and even constrains choice of algorithm. Hence, a DSL that is portable to standard architectures as well as GPUs would place the GPU restrictions onto the code for all machines. However, much excellent work [polyhedral, others] is being done on automated tools to transform standard code to GPU form, which would lift the restrictions. Also, constructs such as the DKU pattern [] map well onto GPUs as well as standard hardware. + +\subsection{The embedded style of DSL} +\label{subsec:EmbeddedDSLs} +[[Hypothesis: Embedded-style DSLs -\textgreater\ high productivity + low learning curve + low app-port + low disruption]] + +[[Bridge: Few users-\textgreater\ must be quick time to create + low effort to lang-port + high perf across targets]] + +[[Bridge: effort to create = runtime + effort port = runtime + perf on new target = runtime]] + +[[Bridge: big picture = langs * runtimes -\textgreater runtime effort critical]] + + +[[Claims: given big picture, runtime effort minimized -\textgreater modularize runtime, mod works across langs bec. fund patterns, mod sep lang logic from RT internals, mod makes internal reusable + lang inherit internal perf tune +inherit centralized serv, mod makes lang logic sequential, mod makes constructs reusable one lang to next, mod causes lang assigner to own HW]] + +We segue now into the embedded style of language, and show how the work of implementing them is mainly the work of implementing their runtime plus their complex domain constructs. We focus on embedded style domain specific languages because it is the least effort-to-create form of DSL, and making DSLs practical requires it to be low effort to create them and port them to various hardware targets. + + +An embedded-style language is one that uses the syntax of a base language, like C or Java, and adds constructs that are specific to the domain. An added construct may be expressed in custom syntax that is translated to into a library call, or else directly invoked by making a library call, as illustrated in Figure \ref{fig:EmbeddedEx}. Inside the library call, a primitive is used to escape the base language and enter the embedded language's runtime, which then performs the behavior of the construct. + + +\begin{figure}[h!tb] +{\noindent +{\footnotesize +{\normalsize Creating a new virtual processor (VP):} +\begin{verbatim} +newVP = SSR__create_VP( &top_VP_fn, paramsPtr, animatingVP ); +\end{verbatim} + +{\noindent {\normalsize sending a message between VPs:}} +\begin{verbatim} +SSR__send_from_to( messagePtr, sendingVP, receivingVP ); +\end{verbatim} + +{\noindent {\normalsize receiving the message (executed in a different VP):}} +\begin{verbatim} +messagePtr = SSR__receive_from_to( sendingVP, receivingVP ); +\end{verbatim} +} +} + +\caption +{Examples of invoking embedded-style constructs. +} +\label{fig:EmbeddedEx} +\end{figure} +An embedded-style language differs from a library in that it has a runtime system, and a way to switch from the behavior of the base language to the behavior inside the runtime. In contrast, libraries never leave the base language. Notice that this means, for example, that a posix threads library is not a library at all, but an embedded language. + +As a practical matter, embedded-style constructs normally have a thin wrapper that invokes the runtime. However, some DSLs perform significant effort inside the library before switching to the runtime, or else after returning from the runtime. These look more like traditional libraries, but still involve an escape from the base language and more importantly are designed to work in concert with the parallel aspects of the language. They concentrate key performance-critical aspects of the application inside the language, such as dividing work up, or, for example, implementing a solver for differential equations that accepts structures created by the divider. + +It is the appearance of constructs being library calls that brings the low-disruption benefit of embedded-style DSLs. The syntax is that of the base language, so the existing development tools and work flows remain intact when moving to an embedded style DSL. In addition, the fit between domain concepts and language constructs minimizes mental-model disruption when switching and makes the learning curve to adopt the DSL very low. + +\subsection{Application programmer's view of embedded-style DSLs} +\label{subsec:AppProgViewOfDSL} +[[Hypothesis: Embedded-style DSLs -\textgreater\ high productivity + low learning curve + low app-port + low disruption]] + +[[Bridge: Few users-\textgreater\ must be quick time to create + low effort to lang-port + high perf across targets]] + +[[Bridge: effort to create = runtime + effort port = runtime + perf on new target = runtime]] + +[[Bridge: big picture = langs * runtimes -\textgreater runtime effort critical]] + + +[[Claims: given big picture, runtime effort minimized -\textgreater modularize runtime, mod works across langs bec. fund patterns, mod sep lang logic from RT internals, mod makes internal reusable + lang inherit internal perf tune +inherit centralized serv, mod makes lang logic sequential, mod makes constructs reusable one lang to next, mod causes lang assigner to own HW]] + +Well designed DSLs have very few constructs, yet capture the most performance-critical domain patterns, in a way that feels natural to the application programmer. This often means that data structures and usage patterns are part of the language. + +For example, a linear-equation-solving language would define a standard data structure for the coefficients of the equations, and supply a construct by which the language is asked to perform the work of solving them. This feels very much like a library, but the runtime system dynamically performs division of work according to the hardware, and implements communication between cores and a scheduler that load balances and tries to take advantage of data affinity and even computational accelerators. All of which puts performance in the hands of the runtime and is simple to use. + +An example of a DSL that we created using the proto-runtime approach is HWSim [], which is designed to be used for writing architectural simulators. + +When using HWSim, a simulator application is composed of just three things: netlist, behavior functions and timing functions. These are all sequential code that call HWSim constructs at boundaries, such as the end of behavior, and use HWSim supplied data structures. To use HWSim, one creates a netlist composed of elements and communication paths that connect them. A communication path connects an outport of the sending element to an inport of the receiving element. An action is then attached to the inport. The action is triggered when a communication arrives. The action has a behavior function, which changes the state of the element, and a timing function which calculates how much simulated time the behavior takes. + +The language itself consists of only a few standard data structures, such as \texttt{Netlist}, \texttt{Inport}, \texttt{Outport}, and a small number of constructs, such as \texttt{send\_comm} and \texttt{end\_behavior}. The advancement of simulated time is performed by a triggered action, and so is implied. The parallelism is also implied, by the only constraints on order of execution of actions being consistency. + +The only parallelism-related restriction is that a behavior function may only use data local to the element it is attached to. Parallel work is created within the system by outports that connect to multiple destination inports which means one output triggers multiple actions, and by behavior functions that generate multiple output communications each. + +Overall, simulator writers have fewer issues to deal with because time-related code has been brought inside the language, where it is reused across simulators, and because parallelism issues reduce to simply being restricted to data local to the attached element. Both these increase productivity of simulator writers, despite using a parallel language. The language has so few commands that it takes only a matter of days to become proficient (as demonstrated informally by new users of HWSim). Also, parallelism related constructs in the language are generic across hardware, eliminating the need to modify application code when porting to new hardware (if the language is used according to the recommended coding style). + +\subsection{Implementation of Embedded-style DSLs} +[[Hypothesis: Embedded-style DSLs -\textgreater\ high productivity + low learning curve + low app-port + low disruption]] + +[[Bridge: Few users-\textgreater\ must be quick time to create + low effort to lang-port + high perf across targets]] + +[[Bridge: effort to create = runtime + effort port = runtime + perf on new target = runtime]] + +[[Bridge: big picture = langs * runtimes -\textgreater runtime effort critical]] + + +[[Claims: given big picture, runtime effort minimized -\textgreater modularize runtime, mod works across langs bec. fund patterns, mod sep lang logic from RT internals, mod makes internal reusable + lang inherit internal perf tune +inherit centralized serv, mod makes lang logic sequential, mod makes constructs reusable one lang to next, mod causes lang assigner to own HW]] + +When it comes to implementing an embedded-style of DSL, the bulk of the effort is in the runtime and the more complex domain specific constructs. + +Examples of constructs implemented for DSLs include Abstract Data Types (ADTs), like linked lists, hash tables, and priority queues. Also, full algorithms, like solvers for systems of equations, or even linear algebra operations on matrices. It will be seen in subsection[] that the proto-runtime approach causes the implementation for such constructs to be reused, with high performance, across all the hardware targets in a hardware class such as the class of shared-memory multi-core platforms. + +In addition, embedded style DSLs rely heavily on data types that are part of the language. These are often domain-specific such as \texttt{Netlist}, \texttt{Inport}, and \texttt{Outport} in HWSim, or \texttt{Protein} in a bio-informatics DSL, but can also be common such as \texttt{SparseMatrix} in domains like data mining and scientific applications. + + + During language design, common patterns that consume significant development time or computation are placed into the language. Also, any patterns that expose hardware configuration, such as the number and size of pieces of work should be pulled into the language to aid portability. + +If such design is successful then porting the application reduces to just porting the language. When the language has successfully captured the main computational patterns of the domain, then the application code encapsulates only a small portion of the performance, so it does not need to be tuned. Further, when patterns that expose hardware-motivated choices or hardware-specific commands are in the language, then the application code has nothing that needs to change when the hardware changes. + +For example, HWSim pulls hardware-specific patterns inside the language by handling all inter-core communications inside the language, and also by aggregating multiple elements together on the same core to tune work-unit size. + +The advantage of placing these into the language, instead of application code, is portability and productivity. + + +\subsection{Implementation Details of Embedded-style DSLs} +[[Hypothesis: Embedded-style DSLs -\textgreater\ high productivity + low learning curve + low app-port + low disruption]] + +[[Bridge: Few users-\textgreater\ must be quick time to create + low effort to lang-port + high perf across targets]] + +[[Bridge: effort to create = runtime + effort port = runtime + perf on new target = runtime]] + +[[Bridge: big picture = langs * runtimes -\textgreater runtime effort critical]] + + +[[Claims: given big picture, runtime effort minimized -\textgreater modularize runtime, mod works across langs bec. fund patterns, mod sep lang logic from RT internals, mod makes internal reusable + lang inherit internal perf tune +inherit centralized serv, mod makes lang logic sequential, mod makes constructs reusable one lang to next, mod causes lang assigner to own HW]] + +? + +Figure [] shows\ the implementation of the wrapper library for HWSim's send\_and\_idle construct, which sends a communication on the specified outport, and then causes the sending element to go idle. Of note is the packaging of information for the runtime. It is placing into the HWSimSemReq data structure, and then the application work is ended by switching to the runtime. The switch is via the send\_and\_suspend call, which is a primitive implemented in assembly that jumps out of the base C language and into the runtime. + +The switch to the runtime can be done in multiple ways. Our proto-runtime uses assembly to manipulate the stack and registers. For posix threads language, when implemented in Linux, the hardware trap instruction is used to switch from application to the OS. The OS serves as the runtime that implements the thread behavior. + +The core is used by the construct implementation differently for VP based languages vs for task based languages. + +For VP based languages, once inside the runtime, a synchronization construct performs the behavior shown abstractly in Figure []. In essence, a synchronization construct is a variable length delay, which waits for activities outside the calling code to cause specific conditions to become true. These activities could be actions taken by other pieces of application code, such as releasing a lock, or they could be hardware related, such as waiting for a DMA transfer to complete. + +While one piece of application code (in a VP) is suspended, waiting, other pieces can use the core to perform their work, as long as the conditions for those other pieces are satisfied. Hence, the runtime's construct implementation checks if conditions are met, and if not stores the suspended piece (VP). If the construct can change conditions for others, it updates them. For example, the lock-release construct updates state for VPs waiting for the lock. Separately, for VPs whose conditions have been met, when a core becomes available, the runtime chooses which VP to assign to which core. + +These are the two behaviors a construct performs inside the runtime: managing conditions on which work is free, and managing assignment of free work onto cores. + +For task based languages, a task runs to completion then always switches to the runtime at the end. Hence, no suspend and resume exists. Once inside, the runtime's job is to track conditions on which tasks are ready to run, or which to create. For example, in dataflow, a task is created only once all conditions for starting it are met. Hence, the only language constructs are "instantiate a task-creator", "connect a task creator to others", and "end a task". During a run, all of the runtime behavior takes place inside the "end a task" construct, where the runtime sends outputs from the ending task to the inputs of connected task-creators. The "send" action modifies internal runtime state, which represents the order of inputs to a creator on all of its input ports. When all inputs are ready, it creates a new task, then when hardware is ready, assigns the task to a core. + + +One survey[] discusses DSLs for a variety of domains, and this list of DSLs was copied from their paper: +\begin{itemize} +\item In Software Engineering: Financial products [12, 22, 24], behavior control and coordination [9, 10], software architectures [54], and databases [39]. +\item Systems Software: Description and analysis of abstract syntax trees [77, 19, 51], video device driver specifications [76], cache coherence protocols [15], data structures in C [72], and operating system specialization [63]. +\item Multi-Media: Web computing [14, 35, 4, 33], image manipulation [73], 3D animation [29], and drawing [44]. +\item Telecommunications: String and tree languages for model checking [48], communication protocols [6], telecommunication switches [50], and signature computing [11]. +\item Miscellaneous: Simulation [2, 13], mobile agents [36], robot control [61], solving partial differential equations [26], and digital hardware design [41]. +\end{itemize} + +\subsection{Summary of Section} + [[Hypothesis: Embedded-style DSLs -\textgreater\ high productivity + low learning curve + low app-port + low disruption]] + +[[Bridge: Few users-\textgreater\ must be quick time to create + low effort to lang-port + high perf across targets]] + +[[Bridge: effort to create = runtime + effort port = runtime + perf on new target = runtime]] + +[[Bridge: big picture = langs * runtimes -\textgreater runtime effort critical]] + + +[[Claims: given big picture, runtime effort minimized -\textgreater modularize runtime, mod works across langs bec. fund patterns, mod sep lang logic from RT internals, mod makes internal reusable + lang inherit internal perf tune +inherit centralized serv, mod makes lang logic sequential, mod makes constructs reusable one lang to next, mod causes lang assigner to own HW]] + +This section illustrated the promise of DSLs for solving the issues with parallel programming. The HWSim example showed that well designed parallel DSLs can actually improve productivity, and have a low learning curve, as well as reduce the need for touching application code when moving to new target hardware. The section showed that the effort of implementing an embedded style DSL is mainly that of implementing its runtime and complex domain constructs, and that a well-designed DSL captures most of the performance-critical aspects of an application inside the DSL constructs. Hence, porting effort reduces to just performance-tuning the language (with caveats for some hardware). This effort is, in turn, reused by all the applications that use the DSL. + +The stumbling point of DSLs is the small number of users, after all, how many people write hardware simulators? Perhaps a few thousand people a year write or modify applications suitable for HWSim. That means the effort to implement HWSim has to be so low as to make it no more effort than writing a library, effectively a small percentage of a simulator project. + +The runtime is a major piece of the DSL implementation, so reducing the effort of implementing the runtime goes a long way to reducing the effort of implementing a new DSL. + +%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% +\section{Description} +\label{sec:idea} +[[Hypothesis: Embedded-style DSLs -\textgreater\ high productivity + low learning curve + low app-port + low disruption]] + +[[Bridge: Few users-\textgreater\ must be quick time to create + low effort to lang-port + high perf across targets]] + +[[Bridge: effort to create = runtime + effort port = runtime + perf on new target = runtime]] + +[[Bridge: big picture = langs * runtimes -\textgreater runtime effort critical]] + + +[[Claims: given big picture, runtime effort minimized -\textgreater modularize runtime, mod works across langs bec. fund patterns, mod sep lang logic from RT internals, mod makes internal reusable + lang inherit internal perf tune +inherit centralized serv, mod makes lang logic sequential, mod makes constructs reusable one lang to next, mod causes lang assigner to own HW]] + +? + + +Now that we have made the case that embedded style DSLs have potential to solve many parallel programming issues, and that a major obstacle to uptake of them is their implementation effort, we describe the proto-runtime concept and show how it addresses this obstacle to DSLs. As shown, embedded style DSL implementation effort and porting effort is mainly that of creating the runtime and implementing the more complex language constructs. We show here that the proto-runtime approach dramatically reduces the effort of creating a DSL runtime, through a number of features. + + +\begin{figure}[ht] + \centering + \includegraphics[width = 2in, height = 1.8in]{../figures/PR_three_pieces.pdf} + \caption{Shows how the proto-runtime approach modularizes the implementation of a runtime. The three pieces are the proto-runtime implementation, an implementation of the language construct behaviors, and an implementation of the portion of a scheduler that chooses which work is assigned to which processor. } + \label{fig:PR_three_pieces} +\end{figure} + + +The main feature is the proto-runtime's approach to modularizing the runtime code. As shown in Fig \ref{fig:PR_three_pieces}, it breaks the runtime into three pieces: a cross-language piece, which is the proto-runtime implementation, a piece that implements the language's constructs and plugs into the proto-runtime, and a piece that assigns work onto hardware and also plugs into the proto-runtime. + +The modularization appears to remain valid across parallel languages and execution models, and we present underlying patterns that support this observation. We analyze the basic structure of a synchronization construct, and point out how the proto-runtime modularization is consistent with it. + +\subsection{Creating an eDSL} + + +\begin{figure}[ht] + \centering + \includegraphics[width = 2in, height = 1.8in]{../figures/eDSL_two_pieces.pdf} + \caption{An embedded style DSL consists of two parts: a runtime and a wrapper library that invokes the runtime} + \label{fig:eDSL_two_pieces} +\end{figure} + +As shown in Fix \ref{fig:eDSL_two_pieces}, to create an embedded style DSL (eDSL), do two things: create the runtime and create a wrapper-library that invokes the runtime and also implements the more complex language constructs. + +As seen in Fig X, a library call that invokes a language construct is normally a thin wrapper that only communicates to the runtime. It places information to be sent to the runtime into a carrier, then invokes the runtime via a primitive. The primitive suspends the base language execution and switches the processor over to the runtime code. + +\subsection{The Proto-Runtime Modularization} + +\subsubsection{Dispatch pattern} +-- standardizes runtime code +-- makes familiar going from one lang to another +-- makes reuse realistic, as demonstrated by VSs taking SSR constructs + +-- show the enums, and the switch table + +-- point out how the handler receives critical info -- the semEnv, req struct and calling slave + +\subsubsection{The Request Handler} +-- cover what a request handler does.. connect it to the wrapper lib, and the info loaded into a request struct. + +-- give code of a request handler.. within on-going example of implementing pthreads, or possibly HWSim, or pick a new DSL + +\subsection{Exporting a performance-oriented machine view } +The proto-runtime interface exports a view of the machine that shows performance-critical aspects. Machines that share the same architectural approach have the same performance-critical aspects, and differ only in the values. + +For example, the interface models cache-coherent shared-memory architectures as a collection of memory pools connected by networks. The essential variations among processor-chips are the sizes of the pools, the connections between them, such as which cores share the same L2 cache, and the latency and bandwidth between them. + +Hence, a single plugin can be written that gathers this information from the proto-runtime and uses it when deciding which work to assign to which core. Such a plugin will then be efficient across all machines that share the same basic architecture. + +This saves significant effort by allowing the same plugin to be reused for all the machines in the category. + +\subsection{Services Provided by the Proto-runtime} + +-- Put services into the low-level piece.. plugins have those available, and inherit lang independent such as debugging, perf counters.. provides effort reduction because lang doesn't have to implement these services. + +-- -- examples of iherited lang services inside current proto-runtime: debugging and perf-tuning.. verification, playback have been started (?) + +-- -- examples of plugin services: creation of base VP, the switch primitives, the dispatch pattern (which reduces effort by cleanly separating code for each construct), handling consistency model (?), handling concurrency + +\subsection{eDSLs talking to each other} +-- show how VSs is example of three different DSLs, and H264 code is three different languages interacting (pthreads, OpenMP, StarSs) + +-- make case that proto-runtime is what makes this practical ! Their point of interaction is the common proto-runtime innards, which provides the interaction services.. they all use the same proto-runtime, and all have common proto-runtime objects, which is how the interaction becomes possible. + +\subsection{The Proto-runtime Approach Within the Big Picture} + +-- Give background on industry-wide, how have langs times machines.. +-- say that proto-runtime has synergistic advantages within this context. -- repeat that eDSLs talk to each other. +-- give subsubsection on MetaBorg for rewriting eDSL syntax into base lang syntax. +-- bring up the tools issue with custom syntax -- compiling is covered by metaborg re-writing.. can address debugging with eclipse.. should be possible in straight forward way that covers ALL eDSLs.. their custom syntax being stepped through in one window, and stepping through what they generate in separate window (by integrating generation step into eclipse).. even adding eclipse understanding of proto-runtime.. so tracks the sequence of scheduling units.. and shows the request handling in action in third window.. + +Preview idea that many players will contribute, and will get people that specialize in creating new eDSLs (such as one of authors).. +-- For them, code-reuse is reality, as supported by VSs example, +-- and the uniformity of the pattern becomes familiar, also speeding up development, as also supported by VSs, HWSim, VOMP, and DKU examples. +-- for those who only create a single eDSL, the pattern becomes a lowering of the learning curve, aiding adoption + +-- Restate and summarize the points below (covered above), showing how they combine to shrink the wide-spot where all the runtimes are. + +-- The low-level part implemented on each machine, exports a view of the machine that shows performance-critical aspects + +-- Collect machines into groups, based on performance critical aspects of hardware.. provides reduction in effort because only one plugin for entire group. + +-- Put services into the low-level piece.. plugins have those available, and inherit lang independent such as debugging.. provides effort reduction because lang doesn't have to implement these services. + + +\section{(outline and notes)} + +-- What a plugin looks like: + +-- -- pattern of parallel constructs.. ideas of Timeline, tie-point, animation, suspension, VP states, constraints, causality, work-units, meta-units, updates in constraint states attached to the meta-units + +-- -- a sych construct is something that creates a tie between two work-units. So, the logic of the construct simply establishes causality -- the ending of one work-unit causes the freedom to start animation of another. + +-- -- -- Examples: mutex is end of work-unit that frees lock causes freedom to start work-unit that gets the lock. They are causally tied. The semantics of the construct is the particular conditions existing inside the runtime (in this case ownership condition of a mutex), and what changes those conditions (in this case releasing lock removes one from owner, plus acquire-lock sets one as wanting the lock), and how freedom to be animated is affected by the changes in conditions (in this case, removal of ownership must precede gaining ownership) on what makes a work-unit free (in this case, being given ownership of the mutex), + +-- Hence, precisely, the parallelism model of the language defines constraints, which are implemented as state inside the runtime. Constructs provided do a number of things: signal bringing a set of constraints into existence (create a mutex), signal update to the state of those constraints (release mutex, state desire to acquire), and trigger the runtime to propagate those changes, which results in additional changes to states, including marking meta-units as free to be animated. cause creation of meta-units (explicitly as in VSs, or via creating entities that trigger creation as in dataflow, or via creating entities that consist of consecutive work-units as in pthreads). + + +-- Recipe for how to make the language plugin: time reduction is part due to simplifying the parallelism construct logic.. + + + + +\subsection{The Cross-language Patterns Behind the Proto-runtime} + +[[Hypothesis: Embedded-style DSLs -\textgreater\ high productivity + low learning curve + low app-port + low disruption]] + +[[Bridge: Few users-\textgreater\ must be quick time to create + low effort to lang-port + high perf across targets]] + +[[Bridge: effort to create = runtime + effort port = runtime + perf on new target = runtime]] + +[[Bridge: big picture = langs * runtimes -\textgreater runtime effort critical]] + + +[[Claims: given big picture, runtime effort minimized -\textgreater modularize runtime, mod works across langs bec. fund patterns, mod sep lang logic from RT internals, mod makes internal reusable + lang inherit internal perf tune +inherit centralized serv, mod makes lang logic sequential, mod makes constructs reusable one lang to next, mod causes lang assigner to own HW]] + +An application switches to the runtime, which does scheduling work then switches back to application code. + + +\subsection{Some Definitions} + +[[Hypothesis: Embedded-style DSLs -\textgreater\ high productivity + low learning curve + low app-port + low disruption]] + +[[Bridge: Few users-\textgreater\ must be quick time to create + low effort to lang-port + high perf across targets]] + +[[Bridge: effort to create = runtime + effort port = runtime + perf on new target = runtime]] + +[[Bridge: big picture = langs * runtimes -\textgreater runtime effort critical]] + + +[[Claims: given big picture, runtime effort minimized -\textgreater modularize runtime, mod works across langs bec. fund patterns, mod sep lang logic from RT internals, mod makes internal reusable + lang inherit internal perf tune +inherit centralized serv, mod makes lang logic sequential, mod makes constructs reusable one lang to next, mod causes lang assigner to own HW]] + +We adopt the concepts of work-unit, virtual processor (VP), animation, and tie-point as discussed in a previous paper []. A work-unit is the trace of instructions executed between two successive switches to the runtime, along with the data consumed and produced during that trace. A Virtual Processor is defined as being able to animate either the code of a work-unit or else another VP, and has state that it uses during animation, organized as a stack. Animation is definedd as causing time of a virtual processor to advance, which is equivalent to causing state changes according to instructions, while suspension halts animation, and consequently causes the end of a work-unit (a more complete definition of animation can be found in the dissertation of Halle[]). A tie-point connects the end of one work-unit to the beginning of one in a different VP, so a tie-point represents a causal relationship between two work-units, and establishes an ordering between those work-units, effectively tying the time-line of the VP animating one to the time-line of the VP animating the other work-unit. + +In addition, we introduce a definition of the word task, which is a single work-unit coupled to a virtual-processor that comes into existence to animate the work-unit and dissipates at completion of the work-unit. By definition of work-unit, a task cannot suspend, but rather runs to completion. If the language defines an entity that has a timeline that can be suspended by switching to the runtime, then such an entity is not a task. Pure Dataflow[] specifies tasks that fit our definition. + +\subsection{Handling Memory Consistency Models} + +[[Hypothesis: Embedded-style DSLs -\textgreater\ high productivity + low learning curve + low app-port + low disruption]] + +[[Bridge: Few users-\textgreater\ must be quick time to create + low effort to lang-port + high perf across targets]] + +[[Bridge: effort to create = runtime + effort port = runtime + perf on new target = runtime]] + +[[Bridge: big picture = langs * runtimes -\textgreater runtime effort critical]] + + +[[Claims: given big picture, runtime effort minimized -\textgreater modularize runtime, mod works across langs bec. fund patterns, mod sep lang logic from RT internals, mod makes internal reusable + lang inherit internal perf tune +inherit centralized serv, mod makes lang logic sequential, mod makes constructs reusable one lang to next, mod causes lang assigner to own HW]] + +Weak memory models can cause undesired behavior when work-units on different cores communicate through shared variables. Specifically, the receiving work-unit can see memory operations complete in a different order than the code of the sending work-unit specifies. + +For example, consider a proto-runtime implemented on shared memory hardware that has a weak consistency model, along with a language that implements a traditional mutex lock. All memory operations performed in the VP that releases the lock should be seen as complete by the VP that next acquires the lock. + +It is up to the proto-runtime to enforce this, using hardware primitives. It has to ensure that all memory operations performed, by a task or VP, before switching to the runtime are completed before any dependent task or VP is switched into from the runtime. More precisely, the proto-runtime has to ensure that all memory operations performed by a work-unit are visible in program order to any tied work-units. In some cases the language plugin has to alert the proto-runtime of the causality between work-units. + + +The proto-runtime does not, however, protect application code that attempts to communicate between VPs or tasks directly, without using a parallelism construct to protect the communication. + + + +======= + + I plan to explain VMS as a universal pattern that exists in all runtimes: that is, that the application switches to runtime, which does a scheduling decision and then switches back. I'll explain it first with just master and slaves, leaving out the core\_loop. Explain it as a normal runtime that has had two key pieces removed and replaced with interfaces. The language supplies the missing pieces. Then, introduce the core\_loop stuff as a performance enhancement used when lock acquisition dominates (as it does on the 4 socket 40 core machine). + Next, give HWSim as an example of a real domain specific (it's working, ref manual attached), and focus on how the modularity allowed pulling constructs from other languages (singleton and atomic), and a breakdown of implementation time vs design time, and so on. Highlight how VMS's features for productivity and encapsulation solve the practical problems for domain-specific languages. + Finally, show that VMS performance is good enough, by going head-to-head with pthreads and OpenMP (doing a VMS OpenMP implementation now). And also StarSs if I have time. I'll run overhead-measuring on them, and also regular benchmarks. + +================= + +\subsection{The patterns} +[[Hypothesis: Embedded-style DSLs -\textgreater\ high productivity + low learning curve + low app-port + low disruption]] + +[[Bridge: Few users-\textgreater\ must be quick time to create + low effort to lang-port + high perf across targets]] + +[[Bridge: effort to create = runtime + effort port = runtime + perf on new target = runtime]] + +[[Bridge: big picture = langs * runtimes -\textgreater runtime effort critical]] + + +[[Claims: given big picture, runtime effort minimized -\textgreater modularize runtime, mod works across langs bec. fund patterns, mod sep lang logic from RT internals, mod makes internal reusable + lang inherit internal perf tune +inherit centralized serv, mod makes lang logic sequential, mod makes constructs reusable one lang to next, mod causes lang assigner to own HW]] + + +Soln: modularize runtime, to reduce part have to mess with, hide part that has low-level details, reuse low-level tuning effort, and reuse lang-spec parts. + +Benefits: lang impl doesn't have to touch low-level details, inherit centralized services, can reuse code from other languages to add features. + +Performance must be high, or the labor savings don't matter. By isolating the low-level details inside the proto-runtime, they can be intensively tuned, then all the languages inherit the effort. + +Part of what makes this so easy is the dispatch pattern.. adding a construct reduces to adding into switch and writing handler.. borrow constructs by taking the handler from the other lang. + +By isolating the low-level details inside the proto-runtime, they can be intensively tuned, then all the languages inherit the effort. Compare that to current practices, where the runtime code is monolithic.. each language has to separately modify the runtime, understanding and dealing with the concurrency, and then on a new machine, each language has to re-tune the low-level details, worrying about the consistency model on that machine, how its particular fence and atomic instructions work, and so on. +We spent 2 months performance tuning the current version, but only 18 hours implementing VSs on top of it, and VSs inherited the benefit from all that effort. So did VOMP, and SSR, and VCilk, and so on.. each time we improved the proto-runtime, all the languages improved, with no effort on the part of the language creator. + + +\subsubsection{Views of synchronization constructs} +[[Hypothesis: Embedded-style DSLs -\textgreater\ high productivity + low learning curve + low app-port + low disruption]] + +[[Bridge: Few users-\textgreater\ must be quick time to create + low effort to lang-port + high perf across targets]] + +[[Bridge: effort to create = runtime + effort port = runtime + perf on new target = runtime]] + +[[Bridge: big picture = langs * runtimes -\textgreater runtime effort critical]] + + +[[Claims: given big picture, runtime effort minimized -\textgreater modularize runtime, mod works across langs bec. fund patterns, mod sep lang logic from RT internals, mod makes internal reusable + lang inherit internal perf tune +inherit centralized serv, mod makes lang logic sequential, mod makes constructs reusable one lang to next, mod causes lang assigner to own HW]] + +One view of sync constructs is that they are variable-length calls. The +basic hardware does this by stalling the pipeline. + +Another view is that they mark the boundary of a communication made via shared read/write. A load or store of a single location has a precise boundary enforced by the hardware, but if a pipeline desires to load, modify, then write a single location it has to have additional hardware. It has to make the multiple primitive load/store operations appear as a single operation. + +Moving up to the application level, the same pattern exists: an operation the application wants to do may involve many loads and stores, but it wants the collection to appear as a single indivisible operation. So the application-level equivalent of a load or store involves multiple memory locations but is to be treated as a single indivisible operation. This requires the application-level equivalent of the hardware that made the read-modify-write into a single indivisible operation. That equivalent is what a synchronization construct is. The reason a sync construct takes a variable amount of time is that it waits until all other indivisible operations that might conflict have completed. + +Another way to think of the sync construct is that it enforces sharp communication boundaries. The multiple read and write operations are treated as a single communication with the shared-state. If any other part of the application sees only part of the communication, it sees something inconsistent and thus wrong. So the sync constructs ensure that communications are complete, so the parts of the application only see complete communications from other parts. + +\subsubsection{Universal Runtime Patterns} +[[Hypothesis: Embedded-style DSLs -\textgreater\ high productivity + low learning curve + low app-port + low disruption]] + +[[Bridge: Few users-\textgreater\ must be quick time to create + low effort to lang-port + high perf across targets]] + +[[Bridge: effort to create = runtime + effort port = runtime + perf on new target = runtime]] + +[[Bridge: big picture = langs * runtimes -\textgreater runtime effort critical]] + + +[[Claims: given big picture, runtime effort minimized -\textgreater modularize runtime, mod works across langs bec. fund patterns, mod sep lang logic from RT internals, mod makes internal reusable + lang inherit internal perf tune +inherit centralized serv, mod makes lang logic sequential, mod makes constructs reusable one lang to next, mod causes lang assigner to own HW]] + +Unified pattern within parallel languages: create multiple timelines, then control relative progress of them, and control location each chunk of progress takes place. + +Another universal pattern: code runs, switches to runtime, some point later switches back to code, making application run be a collection of trace segments bounded by runtime calls. +The runtime tracks constraints (dependencies) among units, creates and destroys units, and assigns ready units to hardware. + +Units have a life-line, which is fundamental to parallel computation, as demonstrated in a paper by some of the authors []. + +Every unit has a meta-unit that represents it in the runtime. A unit is defined as the trace of application code that exists between two scheduling decisions. Looking at this in more detail, every runtime has some form of internal bookkeeping state for a unit, used to track constraints on it and make decisions about when and where to execute. This exists even if that state is just a pointer to a function that sits in a queue. We call this bookkeeping state for a unit the meta-unit. + +Each unit also has a life-line, which progresses so: creation of the meta-unit \pointer , state updates that affect constraints on the unit \pointer, the decision is made to animate the unit \pointer, movement of the meta-unit plus data to physical resources that do the animation \pointer , animation of the unit, which does the work \pointer, communication of state-update, that unit has completed, and hardware is free \pointer , constraint updates within runtime, possibly causing new meta-unit creations or freeing other meta-units to be chosen for animation. This repeats for each unit. Each step is part of the model. + +Note a few implications: first, many activities internal to the runtime are part of a unit's life-line, and take place when only the meta-unit exists, before or after the work of the actual unit; second, communication that is internal to the runtime is part of the unit life-line, such as state updates; third, creation may be implied, such as in pthreads, or triggered such as in dataflow, or be by explicit command such as in StarSs, and once created, a meta-unit may languish before the unit it represents is free to be animated. + +\subsubsection{Putting synchronization constructs together with universal runtime patterns} +[[Hypothesis: Embedded-style DSLs -\textgreater\ high productivity + low learning curve + low app-port + low disruption]] + +[[Bridge: Few users-\textgreater\ must be quick time to create + low effort to lang-port + high perf across targets]] + +[[Bridge: effort to create = runtime + effort port = runtime + perf on new target = runtime]] + +[[Bridge: big picture = langs * runtimes -\textgreater runtime effort critical]] + + +[[Claims: given big picture, runtime effort minimized -\textgreater modularize runtime, mod works across langs bec. fund patterns, mod sep lang logic from RT internals, mod makes internal reusable + lang inherit internal perf tune +inherit centralized serv, mod makes lang logic sequential, mod makes constructs reusable one lang to next, mod causes lang assigner to own HW]] + +Putting these together, gives us that any parallelism construct that has a synchronization behavior causes the end of a work-unit, and a switch to the runtime. The code following the construct is a different work-unit that will begin after the constraint implied by the construct is satisfied. + +The runtime is made up of the infrastructure for the constraints and assignment, such as communicating bookkeeping state between cores, and protecting internal runtime updates of shared information. Plus, the logic of the constructs and logic of choosing an assignment of work to cores. + +For large machines, the infrastructure dominates the time to execute a parallelism construct, while for smaller machines, like single-socket, the logic of constructs and assignments has a chance to be significant. + +\begin{figure}[ht] + \centering + \includegraphics[width = 2in, height = 1.8in]{../figures/SCG_stylized_for_expl.pdf} + \caption{Something to help understanding} + \label{fig:SCG_expl} +\end{figure} + + + + +%%%%%%%%%%%%%%%%%%%%% +\section{The Details} +[[Hypothesis: Embedded-style DSLs -> high productivity + low learning curve + low disruption + low app-port AND quick time to create + low effort to lang-port + high perf across targets]] +[[Claims: modularize runtime, mod is fund patterns, mod sep lang logic from RT internals, mod makes internal reusable & lang inherit internal perf tune & inherit centralized serv, mod makes lang logic sequential, mod makes constructs reusable one lang to next, mod causes lang assigner to own HW]] + +The interfaces between lang logic and proto-runtime. + +Demonstrate: modular runtime, how reduces part have to mess with, hides part that has low-level details, reuses low-level tuning effort, and reuses lang-spec parts. + +Demonstrate Benefits: lang impl doesn't touch low-level details, inherits centralized services (debug support), reuses code from other languages to add features. + +\subsection{Reuse of Language Logic} +[[Hypothesis: Embedded-style DSLs -\textgreater\ high productivity + low learning curve + low app-port + low disruption]] + +[[Bridge: Few users-\textgreater\ must be quick time to create + low effort to lang-port + high perf across targets]] + +[[Bridge: effort to create = runtime + effort port = runtime + perf on new target = runtime]] + +[[Bridge: big picture = langs * runtimes -\textgreater runtime effort critical]] + + +[[Claims: given big picture, runtime effort minimized -\textgreater modularize runtime, mod works across langs bec. fund patterns, mod sep lang logic from RT internals, mod makes internal reusable + lang inherit internal perf tune +inherit centralized serv, mod makes lang logic sequential, mod makes constructs reusable one lang to next, mod causes lang assigner to own HW]] + +Demonstrate reuse of language logic: +All the languages have copied singleton, atomic, critical section and transaction. In VOMP, took the task code from VSS, in VSS, took the send and receive code from SSR.. for DKU, took the code almost verbatim from earlier incarnation of these ideas, and welded it into SSR, and took VSs tasks and put into SSR. Thus, circle completes.. VSs took from SSR, now SSR takes from VSs.. pieces and parts are being borrowed all over the place and welded in where they're needed. + +Part of what makes this so easy is the dispatch pattern.. adding a construct reduces to adding into switch and writing handler.. borrow constructs by taking the handler from the other lang. + +Another part is that code for the constructs is isolated from concurrency details, which are inside the proto-runtime. All the dynamic system issues, and best way to impl locks, and need for fences, and so on is isolated from the construct logic. This isolation is also how porting effort is lowered (or in many cases eliminated), and is how runtime performance is kept high. + +? + +Performance must be high, or the labor savings don't matter. By isolating the low-level details inside the proto-runtime, they can be intensively tuned, then all the languages inherit the effort. Compare that to current practices, where the runtime code is monolithic.. each language has to separately modify the runtime, understanding and dealing with the concurrency, and then on a new machine, each language has to re-tune the low-level details, worrying about the consistency model on that machine, how its particular fence and atomic instructions work, and so on. +We spent 2 months performance tuning the current version, but only 18 hours implementing VSs on top of it, and VSs inherited the benefit from all that effort. So did VOMP, and SSR, and VCilk, and so on.. each time we improved the proto-runtime, all the languages improved, with no effort on the part of the language creator. + +? + +In addition to runtime performance, application level performance must be high. The runtime's performance only affects overhead, and so is only a factor for small work-unit (task) sizes. But data affinity affects performance for all work. + +The proto-runtime approach partially addresses this by giving the language the opportunity to directly control placement of work. This isn't possible when building on top of threads, because the scheduling is in a separate, lower-level, layer where assignment of work to core is made in isolation, blind to language constructs and +other application features. + + + + +%%%%%%%%%%%%%%%%%%%%% +\section{Measurements} + +\subsection{Implementation time} + + +\subsection{Runtime and Application Performance} + + +%%%%%%%%%%%%%%%%%%%%% +\section{Related Work} + + +%%%%%%%%%%%%%%%%%%%%% +\section{Conclusion and Future Work} +\label{sec:conclusion} + + + +\end{document} +%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% +Here is an example of netlist creation: + +The circuit has two elements, each with one input port, one output port, and a single activity-type. The elements are cross-coupled, so output port of one connects to input port of the other. The input port has the activity-type attached as its trigger. The activity is empty, and just sends a NULL message on the output port. The activity's duration in simulated time and the resulting communication's flight duration in simulated time are both constants. + + Note that HWSimElem data type is generic. An elem is specialized by declaring inports and outports, and by connecting activity types to in-ports. Behavior is attached to an element by attaching activity types to in-ports of the element. + +First, here is the top-level function that creates and returns the netlist structure: + +To use HWSim, one creates a netlist composed of elements and communication paths connecting them. An element has a number of in-ports and outports, and a communication path connects an outport of the source element to an inport of the destination elements. The inport has an action attached, which in turn has a behavior function and a timing function, both of which are triggered by the arrival of a communication. The behavior function has local persistent state of the element available to use, and can generate out-going communications. The timing function calculates how much Guest (simulated) time the behavior spanned. In addition, communication paths have an attached function that calculates time from being sent until arrival of the communication. Both the behavior and timing function are application-programmer provided. The entire simulator application is composed of those three things: netlist, behavior functions and timing functions, and all are sequential code. + +The embedded DSL consists of standard data structures, such as netlist, inport, outport, that the application must use in the language-defined way, and a small number of language calls, such as send_comm and end_behavior. The advancement of simulated time is implied, and the parallelism is implied. The only parallelism-related restriction is that a behavior function may only use data local to the element it is attached to. If state in the hardware is shared, such as registers or memory, then other elements access that state by sending communications to the element that contains the state. Parallelism is created within the system by outports that connect to muliple destination inports, and by behavior functions that generate multiple output communications each. + + +\begin{small}\begin{verbatim} +HWSimNetlist * +createPingPongNetlist() + { HWSimNetlist *netlist; + HWSimElem **elems; + HWSimActivityType **activityTypes; + HWSimCommPath **commPaths; + int32 numElems, numActivityTypes, numCommPaths; +\end{verbatim}\end{small} + +The first thing to do is create the netlist structure, which holds three things: element structs, activity type structs, and communication path structs. It also has two collections of pointers to the traces collected during the run, but these are handled internally by HWSim. +\begin{small}\begin{verbatim} + netlist = malloc( sizeof(HWSimNetlist) ); + + numElems = 2; + elems = malloc( numElems * sizeof(HWSimElem *) ); + + numCommPaths = 2; + commPaths = malloc( numCommPaths * sizeof(HWSimCommPath *) ); + + numActivityTypes = 1; + activityTypes = malloc( numActivityTypes * sizeof(HWSimActivityType *) ); + + netlist->numElems = numElems; + netlist->elems = elems; + netlist->numCommPaths = numCommPaths; + netlist->commPaths = commPaths; + netlist->numActivityTypes = numActivityTypes; + netlist->activityTypes = activityTypes; +\end{verbatim}\end{small} + +Now, create the activity types. During the run, an activity instance is created each time a communication arrives on an in-port. The activity instance is a data structure that points to the activity type. The activity type holds the pointers to the behavior and timing functions. +\begin{small}\begin{verbatim} + //have to create activity types before create elements + //PING_PONG_ACTIVITY is just a #define for readability + netlist->activityTypes[PING_PONG_ACTIVITY] = createPingPongActivityType(); +\end{verbatim}\end{small} + +Next, create the elements, and pass the netlist structure to the creator. It will take pointers to activity types out of the netlist and place them into the in-ports of the elements. +\begin{small}\begin{verbatim} + elems[0] = createAPingPongElem( netlist ); //use activity types from netlist + elems[1] = createAPingPongElem( netlist ); +\end{verbatim}\end{small} + +Now, the reset in-port of one of the elements has to be set up to trigger an activity. Every element has a reset in-port, but normally they are set to NULL activity type. Here, we want only one of the two elements to have an activity triggered when the reset signal is sent to start the simulation. + +Note that during initialization, all the elements become active, each with its own timeline, but unless an activity is triggered in them they remain idle, with their timeline suspended and not making progress. Only ones that have an activity type attached to their reset in-port will begin to do something in simulated time when simulation starts. +\begin{small}\begin{verbatim} + //make reset trigger an action on one of the elements + elems[1]->inPorts[-1].triggeredActivityType = + netlist->activityTypes[PING_PONG_ACTIVITY]; +\end{verbatim}\end{small} + +Now, connect the elements together by creating commPath structures. A comm path connects the out-port of one element to the in-port of another. A given port may have many comm paths attached. However, an in-port has only one kind of activity type attached, and all incoming communications fire that same activity. There are multiple kinds of activity, including kinds that have no timing, and so can act as a dispatcher. These end themselves with a continuation activity, which is chosen according to the code in the behavior function. So, a commPath only connects an out port to an in port. + +This code sets fixed timing on the comm paths. It also uses a macro for setting the connections. The format is: sending elem-index, out-port, dest elem-index, in-port: +\begin{small}\begin{verbatim} + //elem 0, out-port 0 to elem 1, in-port 0 + commPaths[0]= malloc(sizeof(HWSimCommPath)); + setCommPathValuesTo(commPaths[0],0,0,1,0); + commPaths[0]->hasFixedTiming = TRUE; + commPaths[0]->fixedFlightTime = 10; //all time is stated in (integer) units + + //elem 1, out-port 0 to elem 0, in-port 0 + commPaths[1]= malloc(sizeof(HWSimCommPath)); + setCommPathValuesTo(commPaths[1], 1,0,0,0); + commPaths[1]->hasFixedTiming = TRUE; + commPaths[1]->fixedFlightTime = 10; //all time is stated in (integer) units +\end{verbatim}\end{small} + +done building netlist, return it +\begin{small}\begin{verbatim} + return netlist; + } +\end{verbatim}\end{small} + +The macro that sets the connections inside a comm path struct +\begin{small}\begin{verbatim} +#define setCommPathValuesTo( commPath, fromElIdx, outPort, toElIdx, inPort)\ +do{\ + commPath->idxOfFromElem = fromElIdx; \ + commPath->idxOfFromOutPort = outPort; \ + commPath->idxOfToElem = toElIdx; \ + commPath->idxOfToInPort = inPort; \ + }while(0); //macro magic for namespace +\end{verbatim}\end{small} + +Creating an element involves creating arrays for the in-ports and out-ports, then configuring the in-ports. The out-ports are automatically filled in during simulation start-up, by HWSim. The most interesting feature is that each in-port is assigned an activity type, which all arriving communications trigger. During the simulation, each incoming communication creates an activity instance, which points to this triggered activity type. The behavior and timing of the instance are calculated by the behavior and timing functions in the activity type. Notice that the activity type pointers are taken from the netlist, so they have to be created before creating the elements. +\begin{small}\begin{verbatim} +HWSimElem * +createAPingPongElem( HWSimNetlist *netlist ) + { HWSimElem *elem; + elem = malloc( sizeof(HWSimElem) ); + elem->numInPorts = 1; + elem->numOutPorts = 1; + elem->inPorts = HWSim_ext__make_inPortsArray( elem->numInPorts ); + elem->inPorts[-1].triggeredActivityType = IDLE_SPAN; //reset port + elem->inPorts[0].triggeredActivityType = netlist->activityTypes[PING_PONG_ACTIVITY]; + return elem; + } +\end{verbatim}\end{small} + +Creating an activity type involves setting the pointers to the behavior and timing functions, which are defined inside a separate directory where all the behavior and timing functions are defined. An activity may have behavior set to NULL, or timing set to NULL, and may have fixed timing. The structure has flags to state the combination. +\begin{small}\begin{verbatim} +HWSimActivityType * +createPingPongActivityType( ) + { HWSimActivityType *pingPongActivityType; + pingPongActivityType = malloc( sizeof(HWSimActivityType) ); + + pingPongActivityType->hasBehavior = TRUE; + pingPongActivityType->hasTiming = TRUE; + pingPongActivityType->timingIsFixed = TRUE; + pingPongActivityType->fixedTime = 10; + pingPongActivityType->behaviorFn = &pingPongElem_PingActivity_behavior; + return pingPongActivityType; + } +\end{verbatim} \end{small} + + +========= + +All behavior functions take a ptr to the activity instance they are executing the behavior of. The instance contains a pointer to the elem, and most behaviors will use the element's elemState field. It holds all the persistent state of the element, which remains between activities. + +Here is the behavior function from the ping-pong example: +\begin{small}\begin{verbatim} +void +pingPongElem_PingActivity_behavior( HWSimActivityInst *activityInst ) + { //NO_MSG is #define'd to NULL, and PORT0 to 0 + HWSim__send_comm_on_port_and_idle( NO_MSG, PORT0, activityInst ); + } +\end{verbatim}\end{small} + +There are four ways a behavior can end: +\begin{description} +\item end, no continuation: +\begin{small}\begin{verbatim} HWSim__end_activity_then_idle( HWSimActivityInst *endingActivityInstance )\end{verbatim}\end{small} +\item end, with continuation: +\begin{small}\begin{verbatim} HWSim__end_activity_then_cont( HWSimActivityInst *endingActivityInstance, + HWSimActivityType *continuationActivityType)\end{verbatim}\end{small} +\item end by sending a communication, with no continuation: +\begin{small}\begin{verbatim} HWSim__send_comm_on_port_then_idle( void *msg, int32 outPort, + HWSimActivityInst *endingActivityInstance)\end{verbatim}\end{small} +\item end by sending a communication, with continuation: +\begin{small}\begin{verbatim} HWSim__send_comm_on_port_then_cont( void *msg, int32 outPort, + HWSimActivityInst *endingActivityInstance + HWSimActivityType *continuationActivityType)\end{verbatim}\end{small} + + +============= + + +\subsection{Activity Timing Functions} +All activity timing functions take a ptr to the activity instance they are calculating the timing of. The instance contains a pointer to the element the activity is in. The behavior function is free to communicate to the timing function by leaving special data inside the element state. The timing function might also simply depend on the current state of the element. + +Here's an example: +\begin{small}\begin{verbatim} +HWSimTimeSpan +sampleElem_sampleActivity_timing( HWSimActivityInst *activityInst ) + { + return doSomethingWithStateOfElem( sendingActivity->elem->elemState ); + } +\end{verbatim}\end{small} + +\subsection{Calculating the time-in-flight of a communication path} + +The timing function for a communication path is similar to that of an activity. Except, the timing might also depend on configuration data or state stored inside the comm path struct, so that is passed to the timing function as well. + +\begin{small}\begin{verbatim} +HWSimTimeSpan +commPath_TimeSpanCalc( HWSimCommPath *commPath, HWSimActivityInst *sendingActivity ) + { return doSomethingWithStateOfPathAndElem( commPath, sendingActivity->elem->elemState ); + } +\end{verbatim}\end{small} + + + + diff -r 9b9a2497757d -r eb146c5c05a8 0__Papers/VMS/VMS__Foundation_Paper/VMS__Full_conference_version/latex/VMS__Full_conf_paper_3_short.pdf Binary file 0__Papers/VMS/VMS__Foundation_Paper/VMS__Full_conference_version/latex/VMS__Full_conf_paper_3_short.pdf has changed diff -r 9b9a2497757d -r eb146c5c05a8 0__Papers/VMS/VMS__Foundation_Paper/VMS__Full_conference_version/latex/VMS__Full_conf_paper_3_short.tex --- /dev/null Thu Jan 01 00:00:00 1970 +0000 +++ b/0__Papers/VMS/VMS__Foundation_Paper/VMS__Full_conference_version/latex/VMS__Full_conf_paper_3_short.tex Sat Aug 03 19:24:22 2013 -0700 @@ -0,0 +1,448 @@ +%----------------------------------------------------------------------------- +% +% Template for sigplanconf LaTeX Class +% +% Name: sigplanconf-template.tex +% +% Purpose: A template for sigplanconf.cls, which is a LaTeX 2e class +% file for SIGPLAN conference proceedings. +% +% Guide: Refer to "Author's Guide to the ACM SIGPLAN Class," +% sigplanconf-guide.pdf +% +% Author: Paul C. Anagnostopoulos +% Windfall Software +% 978 371-2316 +% paul@windfall.com +% +% Created: 15 February 2005 +% +%----------------------------------------------------------------------------- + + +\documentclass[preprint]{sigplanconf} + +% The following \documentclass options may be useful: +% +% 10pt To set in 10-point type instead of 9-point. +% 11pt To set in 11-point type instead of 9-point. +% authoryear To obtain author/year citation style instead of numeric. +\usepackage{amssymb,graphicx,calc,ifthen,subfig,dblfloatfix,fixltx2e} + + +% correct bad hyphenation here +\hyphenation{op-tical net-works semi-conduc-tor} + +\usepackage{wasysym} + +\begin{document} + +\bibliographystyle{plain} +% + +\conferenceinfo{WXYZ '05}{date, City.} +\copyrightyear{2005} +\copyrightdata{[to be supplied]} + +\titlebanner{banner above paper title} % These are ignored unless +\preprintfooter{short description of paper} % 'preprint' option specified. + + +\title{A Proto-Runtime Approach to Domain Specific Languages} + + +\authorinfo{Sean Halle} + {Open Source Research Institute, INRIA, + and TU Berlin} + {seanhalle@opensourceresearchinstitute.org} +\authorinfo{Merten Sach} + {TU Berlin} + {msach@mailbox.tu-berlin.de} +\authorinfo{Albert Cohen} + {Ecole Normal Supereur, and INRIA} + {albert.cohen@inria.fr} + +\maketitle + + +\begin{abstract} + +? +replace lang-specific with interface, centralize services, minimize effort to create, give language control over hardware assignment.. side benefits: multi-lang, perf-tuning, debugging + +? + +Domain Specific Languages that are embedded into a base language have promise to provide productivity, performant-portability and wide adoption for parallel programming. However such languages have too few users to support the large effort required to create them and port them across hardware platforms, resulting in low adoption of the method. +To solve this, we introduce a proto-runtime approach, which reduces the effort to create and port domain specific languages. It modularizes the creation of runtime systems and the parallelism constructs they implement, by separating the language-construct and scheduling logic away from the low-level runtime details, including concurrency, memory consistency, and runtime-performance aspects. +As a result, new parallel constructs are written using sequential reasoning, and languages can be mixed within +the same program. In addition, scheduling of work onto hardware is under language and application control, without interference from an underlying thread package scheduler. This enables higher quality scheduling decisions for higher application performance. +We present measurements of the time taken to develop runtimes for new languages, as well as time to re-implement existing ones, which average a few days each. In addition, we measure performance of proto-runtime based implementations going head-to-head with the standard distributions of Cilk, StarSs (OMPSs), and posix threads, showing that the proto-runtime matches or outperforms on large servers in all cases. +\end{abstract} + + + + + +%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% +\section{Background and Motivation} +\label{sec:intro} + +[Note to reviewers: this paper's style and structure follow the official PPoPP guide to writing style, which is linked to the PPoPP website. We are taking on faith that the approach has been communicated effectively to reviewers and that we won't be penalized for following it's recommended structure and approach.] + +Programming in the past has been overwhelmingly sequential, with the applications being run on sequential hardware. But the laws of physics have forced the hardware to become parallel, which will force nearly all future programming to become parallel programming. However, the transition from sequential to parallel programming has been slow due to the difficulty of the traditional parallel programming methods. + +The difficulties with parallel programming fall into three main categories: 1) difficult mental model, 2) extra effort to rewrite the code for each hardware target to get acceptable performance and 3) disruption to existing practices, including steep learning curve, changes to the tools used, and changes in design practices. + +Many believe that these can be overcome with the use of Domain-Specific Languages []. But such languages have been slow to adopt, we believe due to the cost to create them and to port them across hardware targets. The small number of users of each language, which is specific to a narrow domain, makes this cost impractical. + +We propose that a method that makes Domain Specific Languages (DSLs) low cost to produce as well as to port across hardware targets will allow them to fulfill their promise, and we introduce what we call a proto-runtime to help towards this goal. + +The proto-runtime approach is a normal, full, runtime, but with two key pieces replaced by an interface. One piece replaced is the logic of language constructs, and the other is logic for choosing which core to assign work onto. The remaining proto-runtime piece handles the low-level hardware details of the runtime. + +The decomposition into a proto-runtime plus plugged-in language behaviors modularizes the construction of runtimes. The proto-runtime is one module, which embodies runtime internals, which are hardware oriented and independent of language. The plugged-in portions form the two other modules, which are language specific. The interface between them occurs at a natural boundary, which separates the hardware oriented portion of a runtime from the language oriented portion. + +We claim the following benefits of the proto-runtime approach, each of which is supported in the indicated section of the paper: + +\begin{itemize} + +\item The proto-runtime approach should reliably apply to future languages and hardware. because the patterns underlying it appear to be fundamental and so should hold for future languages and architectures (\S\ref{subsec:TiePoints}). + +\item The proto-runtime approach modularizes the runtime (\S\ref{sec:Proposal}). + +%\item The modularization is consistent with patterns that appear to be fundamental to parallel computation and runtimes (\S\ ). + +\item The modularization cleanly separates runtime internals from the language-specific logic (\S\ref{sec:Proposal} ). + +\item The modularization gives the language control +over timing and placement of executing work (\S\ref{sec:Proposal}). + +\item The modularization results in reduced time to implement a new language's behavior, and in reduced time to port a language to new hardware (\S\ref{sec:Proposal}). + +\begin{itemize} + + +\item Part of the time reduction is due to the proto-runtime providing a centralized location for services for all languages to use, so the language doesn't have to provide them separately. Such services include debugging facilities, automated verification, concurrency handling, hardware performance information gathering, and so on (\S\ ). + +\item Part of the time reduction is due to encapsulation of hardware aspects inside the hardware-oriented module (\S \ref{sec:intro}). + +\item Part of the time reduction is due to reuse of the performance-tuning effort for runtime internals (\S\ ). + +\item Part of the time reduction is due to using sequential thinking when implementing the language logic, enabled by the proto-runtime protecting shared internal runtime state and exporting an interface that presents a sequential model (\S\ ). + + +\end{itemize} + +\item + +The modularization also selectively exposes hardware aspects relevant to placement of work, giving the language control over placement of work onto the hardware. If the language takes advantage of this, it can result in reduced communication between cores and increased application performance (\S\ ). + +\begin{itemize} + +\item Similar control over hardware is not possible when the language is built on top of a package like Posix threads or TBB, which has its own work-to-hardware assignment (\S\ ). + +\end{itemize} + +\item Modularization with similar benefits does not appear possible when using a package such as Posix threads or TBB, unless the package itself is modified and then used according to the proto-runtime pattern (\S\ ). + +\end{itemize} + +The paper is organized as follows: We first expand on the value of embedded style DSLs (eDSL), and where the effort goes when creating one (\S \ref{sec:DSLHypothesis}). We focus on the role that runtime implementation effort plays in the adoption of eDSLs \S, which motivates the value of the savings provided by the proto-runtime approach. We then move on to the details of the proto-runtime approach (\S ), and tie them to how a runtime is modularized (\S ), covering how each claimed benefit is provided. +We then show overhead measurements (\S ) and implementation time measurements (\S ), which indicate that the proto-runtime approach is performance competitive while significantly reducing implementation and porting effort. +With that understanding in hand, we then discuss how the approach compares to related work (\S ), and finally, we highlight the main conclusions drawn from the research (\S ). + + + + +%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% +% +%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% +\section{Background: The eDSL Hypothesis} + +%[[Hypothesis: Embedded-style DSLs -\textgreater\ high productivity + low learning curve + low app-port + low disruption]] + +%[[Bridge: Few users-\textgreater\ must be quick time to create + low effort to lang-port + high perf across targets]] + +%[[Bridge: effort to create = runtime + effort port = runtime + perf on new target = runtime]] + +%[[Bridge: big picture = langs * runtimes -\textgreater runtime effort critical]] + +Domain Specific Languages have been around for a while [], and recently have been suggested as a good approach for parallel programming[][stanford PPL]. + +In essence, a DSL, or just Domain Language, captures patterns that are common in a particular domain of expertise, such as user interfaces, simulations of physical phenomena, bio-informatics, cosmology, and so on. Each domain has a particular set of mental models, common types of computation, and common kinds of data structures. A DSL captures these common elements in custom syntax. + + +\subsection{Embedding a DSL into a base language} + +A style of domain language, which we feel has good applicability to parallel software development, is the so-called \textit{embedded} style of DSL (eDSL) [] [metaborg][stanford ppl]. In this variation, a program is written in a mix of a base language plus domain language constructs. The syntax of the two is intermixed. A preprocessing step then translates the domain syntax into the base syntax, and includes calls to the domain language's runtime. + + +For example, use C (or Java) as the base language for an application, and mix-in custom syntax for constructs from a user-interface eDSL. To test the code, the developer modifies the build process to first perform the translation step, then pass the resulting source through the normal C (or Java) compiler. The resulting executable contains calls to a dynamic (or shared) library that becomes linked, at run time, to a runtime implementation that has been tuned to the hardware it is running on. + + +\subsection{Low learning curve, high productivity, and portability} +DSLs are generally quick to learn because the domain experts are already familiar with the concepts expressed by the custom syntax, especially for those who are \textit{not} expert programmers. Embedded style DSLs further reduce learning curve because they have relatively few constructs, and require no new development tools nor development procedures. Together, these should meet the goal of a low learning curve for switching to parallel software development. + +Productivity can be enhanced by a well designed syntax, which can simplify the application code, modularize it, and encapsulate performance aspects inside the language. Simplifying reduces the amount of code and the amount of mental effort. Modularizing separates concerns within the code and isolates aspects, which improves productivity. Encapsulating performance inside the DSL constructs removes them from the application programmer's concerns, which also improves productivity. + +Perhaps the most important productivity enhancement comes from hiding parallelism aspects inside the custom DSL constructs. The language takes advantage of the domain patterns to present a familar mental model, and then attaches synchronization, work-division, and communication implications to those constructs, without the programmer having to be aware of them. Combining the simplicity, modularization, performance encapsulation, and parallelism hiding, with congruence with the mental model of the domain, together work towards the goal of high productivity. + +Portability is aided by the encapsulation of performance aspects inside the DSL constructs. This means that the elements of the problem that require large amounts of computation are often pulled into the language, which isolates the application code from hardware performance concerns. Only the language implementation must adapt to new hardware in order to get high performance. Although such isolation cannot always be fully achieved, Domain Languages hold promise for making significant strides towards it. + +\subsection{Low disruption and easy adoption} + +Using an eDSL tends to have low disruption because the base language remains the same, along with most of the development tools and practices. + Constructs from the eDSL can be mixed into existing sequential code, incrementally replacing the high computation sections, while continuing with the same development practices.\subsection{ Few users means the effort of eDSLs must be low} + +What appears to be holding eDSLs back from addressing the challenges of parallel programming would be mainly the time, expertise, and cost needed to develop an eDSL. Because the number of users is small, the economic model of the past doesn't apply. For sequential languages, the potential user-base is in the millions, but for a parallel Domain Language, the user base may be only a few hundred developers who will use the language. + +As such, the effort to create a usable eDSL needs to be reduced to the point that it is viable for that size of user base. + +The effort to be reduced falls into three categories: + +\begin{enumerate} +\item effort to explore the design and create the eDSL syntax +\item effort to create the runtime that embodies the eDSL behavior +\item effort to performance tune the eDSL on particular hardware +\end{itemize} + + +\subsection{Critical areas of effort in the big picture} + +Across the industry as a whole, when eDSLs become successful, there will be hundreds of Domain Languages, and likewise hundreds of different hardware platforms that each language must run efficiently on. That multiplicative effect must be reduced in order to make the eDSL approach economically viable. + +The first category of eDSL effort is creating the front-end translation of custom syntax into the base language. This is a one-time effort that does not repeat when new hardware is added. + +The effort that has to be expended on each platform is the runtime implementation, which includes hardware-specific low-level tuning, and the tuning of the domain construct implementation. + +Luckily, hardware platforms cluster into groups with similar performance-related features. This opens the door to an approach that can present a common abstraction for all platforms in a cluster. Examples of clusters include: + +\begin{itemize} +\item shared coherent memory multi-core single-chip machine +\item shared coherent memory multi-core multi-chip machine +\item independent address space coprocessor (GPU) +\item a network of nodes of the above categories +\item a machine with a hierarchy of sub-networks +\end{itemize} + + +%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% +% +%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% +\section{Our Proposal} \label{sec:Proposal} + +We propose addressing the runtime effort by defining a modularization of runtimes, as seen in Fig X. The low-level hardware details are collected into one module, which presents a common interface. The language supplies +the top two modules, which plug in via the interface. The hardware specific module presents the same interface +for all platforms sharing similar performance related features. This module only has to be implement once for a given platform, then reused by the languages. + +\begin{figure}[ht] + \centering + \includegraphics[width = 1.5in, height = 1.1in]{../figures/proto-runtime__modules.pdf} + \caption{Shows how the proto-runtime approach modularizes the implementation of a runtime. The three pieces are the proto-runtime implementation, an implementation of the language construct behaviors, and an implementation of the portion of scheduling that chooses which work is assigned to which processor. } + \label{fig:PR_three_pieces} +\end{figure} + + +Thus, a given language doesn't have to re-implement its runtime for every platform. Instead, it has a much lower effort requirement, of implementing for each category. + +The language effort is further reduced because the language doesn't consider the low-level details of making the runtime itself run fast. It only has to consider the level of hardware feature that is exposed by the interface. This is a higher level of abstraction, which simplifies the task for the language implementer. + +One additional benefit is giving control to the language, to choose when and where it wishes work to execute. +This feature simplifies implementation of languages +that have features related to scheduling behavior. +It also enables the language implementor to use sophisticated +methods for choosing placement of virtual processors +(threads) and tasks, which can significantly impact +application performance. + +In this paper, we present work that applies to coherent +shared memory machines, both single chip and multiple chip. Extensions beyond this are currently in progress, to address multiple-address-space machines and hierarchical +heterogeneous collections of processors, which will appear in future papers. + +\subsection{Breakdown of the modules} + +The language is broken into two parts, as seen in Fig +X. One is a thin wrapper library that +invokes the runtime and the other is a set of modules that are part of the runtime. + + + +\begin{figure}[ht] + \centering + \includegraphics[width = 2.8in, height = 1.1in]{../figures/proto-runtime__modules_lang_breakdown.pdf} + \caption{Shows how the code of the language implementation + is broken into two pieces. The first is a thin wrapper + that invokes the runtime, the other is a dynamic + library that plugs into the runtime.} + \label{fig:langBreakdown} +\end{figure} + +The runtime itself consists of three modules connected via +an interface, as was seen back in Fig X. One encapsulates the low-level hardware details, and presents an interface to the language modules. We call +this the \textit{proto-runtime}. +It's job is to enforce the interface that the language modules see. + + +The language has two modules, both of which are collected in what we call the \textit{language plugin}. One module encodes the behavior of language +constructs, the other module provides logic for choosing which work to execute on +which hardware resource. + +The plugin collects the two language modules into a dynamic library that is implemented, compiled, and distributed separately from any application executables. This is how a non-changing application executable is able to invoke plugin code that can change between machines. The executable contains only symbols of plugin functions, and during the run those are linked to specific functions' implementations. + +In order to provide such modularization, we rely upon something we call a tie-point as the primitive upon which synchronization constructs are built. The low-level nature of a tie-point places them below the level of constructs such as a mutex. Instead, a mutex is implemented on top of tie-points. This places all parallel constructs on the same level in the software stack, be they complex like the AND-OR parallelism of Prolog, or the wild-card matching +channels in coordination languages, or ultra-simple acquire and release mutex constructs. All are implemented in terms of the same tie-point primitives provided by the proto-runtime. + + + + + +\subsection{The origin of tie-points.}\label{subsec:TiePoints} + + +A tie-point relates timelines, so we talk a bit, first, about timelines. A timeline is the primitive in parallelism. If you look at any parallel language, it establishes a number of independent timelines. It then controls which timelines are actively progressing relative to the others. + +For example, take a thread library. It provides a command to create a thread, and that thread represents an independent timeline. The library also provides the mutex acquire and release commands, which control which of those timelines advance relative to each other. When an acquire executes, it causes the thread to block, which means the associated timeline suspends; it stops +making forward progress. The release in a different thread clears the block, which resumes the timeline. That linkage between suspend and resume of different timelines is the control the language exerts over which timelines are actively progressing. + +To build up to tie-points, we look at the nature of points on +a single timeline, by reviewing mutex behavior in detail. We see the timeline shown in Fig X. Thread 1, which is timeline 1, tries to acquire the mutex, M, +by executing the acquire command. Timeline 1 stops, at point 1.S, then something external to it happens, and the timeline starts again at point 1.R. The gap between is not seen by the code executed within the thread. Rather, from the code-execution viewpoint, the acquire command is a single command, and hence the gap between 1.S and 1.R collapses to a single point on the timeline. + + +\begin{figure}[ht] + \centering + \includegraphics[width = 2.8in, height = 0.8in] + {../figures/PR__timeline_single.pdf} + \caption{The timeline suspends at 1.S and resumes + at 1.R. From the viewpoint of the timeline, the gap collapses into a single point.} + \label{fig:langBreakdown} +\end{figure} + + +Now, a tie-point is seen as the linkage between such collapsed points on +two timelines. In Fig X, timeline A is still there, suspends still at 1.S and resumes at 1.R. However, now there is a second timeline, timeline 2B. It executes the release command at point 2.S, which suspends timeline B, performs the behavior of the release command +inside the gap, then resumes timeline B at 2.R. The behavior of the release +command causes the end of suspend in the first timeline. That causality ties the two collapsed points in the two timelines together. + + +\begin{figure}[ht] + \centering + \includegraphics[width = 2.8in, height = 1.35in] + {../figures/PR__timeline_dual.pdf} + \caption{Two timelines with a causal relationship. +Activity that takes place during the gap in timeline +B causes resume of timeline A. This ties point 2 on +timeline B to point 1 on timeline A.} + \label{fig:langBreakdown} +\end{figure} + + + +We call this connection between the collapsed suspensions a tie point. What it provides is a guarantee about visibility of events between the tied timelines. The +guarantee makes both agree on the order of events,\textit{ +relative to the mutual tied point}. Any operation that executes before the point in the second timeline, 2.S, is visible immediately after the point in the first timeline, 1.R. In addition, nothing +in the first timeline happening after the tie-point is visible in the second +timeline before the tie-point. + +Just that guarantee defines it as a half tie-point. A full tie-point adds the dual guarantee from timeline +B to A. Namely, for a full tie-point, anything before the tie-point in timeline A is visible in timeline B after the tie-point, +and nothing in timeline B after the tie-point is visible in A before the tie-point. + +A tie-point is the primitive mechanism that the proto-runtime implements. It does not involve any notion of dependency nor constraint semantics. All it provides is the notion that the tied points are the same "instant" for both tied timelines. What that means is that both timelines see events ordered relative to that point in the same way. + +It is up to the language to supply the behavior that happens inside +the gaps. This behavior is what decides which timelines get tied together. It is that decision making, of which timelines to tie together, that implements the +semantics of a synchronization construct. + +A formal treatment of tie-points is beyond the scope of this paper. However, a formal framework has been substantially completed and +will be published in a future paper. + + + +\subsection{Tie-points within a proto-runtime} + + In Fig X we didn't say what entity executes the behavior that takes place in the gaps in the timelines. This is what the proto-runtime does. It provides +primitives that suspend a timeline and then cause behavior supplied by the language +plugin to execute in the gap. This plugin behavior chooses which timelines remain suspended versus which resume execution, or start execution. + +As such, the plugin behavior that runs in the proto-runtime when one timeline +suspends is what chooses another timeline to resume as a consequence. That +choice establishes causality between the suspensions of the two timelines, +and thus creates the tie between the two collapsed timeline points. The proto-runtime +code module provides the suspend and resume primitives, while the running proto-runtime instance +executes the plugin behavior. + +The running proto-runtime instance is also known as the Master, while the application timelines +are known as Slaves. The behavior of the language constructs executes within the Master's timeline, while the behavior of application code executes within Slave timelines. + +\subsection{More about the proto-runtime} + +The proto-runtime provides the following primitives, for use by language +plugins: +\begin{itemize} +\item create a virtual processor (which has a suspendible timeline) +\item create a task (which has an atomic timeline that runs to completion) +\item automatically convert a task to a virtual processor, as needed +\item trigger choosing which virtual processor or task to begin execution on an offered +core +\item suspend a timeline, then invoke a function to handle the suspension -- handler executes in the Master, with supplied parameters +\item end a timeline + +\end{itemize} + +Virtual processors and tasks, both, have associated timelines. The reason for having both is a practical one, as tasks are simpler, with less overhead, +and many languages have the semantics of short, atomic, units of work that +are not intended to suspend. Thus, tasks are treated differently inside the +proto-runtime, and incur less overhead to create and run. + +A special feature of the proto-runtime is that if a task happens to execute +a language command that causes suspension, then the proto-runtime automatically +converts that task to a virtual processor. This helps support the mixing of different +languages within the same program. + +The proto-runtime involves the language into the process of choosing which core a given task +or virtual processor executes on. The proto-runtime maintains control, but offers free cores to the plugin, which responds by then assigning a task or virtual processor to the core. The proto-runtime just offers, it is up to the language to decide what work that core should receive at that point in time. + +The proto-runtime provides a mechanism for communicating information from the application code to the plugin function that was invoked to handle suspension. For example, the identity of a particular mutex a thread wishes to acquire +can be communicated from the wrapper library to the plugin. + + +Because the proto-runtime tracks all the timelines, the end of a timeline has to be explicitly stated in the application code, by calling a wrapper library function. That then invokes the proto-runtime primitive that informs the proto-runtime instance. The proto-runtime performs internal bookkeeping related to the ending of the timeline, and notes that the core is now free and offers it to the plugin's Assigner function. + + + + + + +\subsection{What happens at different times within the +big picture} + +To get a handle on the big picture, we describe three different paths through time: +one for development of proto-runtime code, one for +development of language implementation, and one for +application development. + +The proto-runtime code is developed separately from +both language and application code, and packaged as a dynamic library. This library has multiple implementations. Each kind of hardware platform has a proto-runtime implemented specifically for it, and is tuned for low overhead on that hardware. The administrator of a particular machine chooses the proto-runtime implementation best suited to that hardware, and installs that. + +The language code is likewise developed separately from both proto-runtime and application code. Although multiple versions of a language may be implemented, there are significantly fewer versions than the number of proto-runtime versions. That is because most of the hardware details are abstracted away by the proto-runtime interface. + +However, the interface does expose hardware features related to placement of work onto cores, so some variations may exist for the same interface. Again, the administrator chooses which language implementation best suits their machine and installs the corresponding dynamic library. + +The wrapper library, however, is not +installed on the machine where code runs. Rather, it +is only used during development of an application, +and remains independent of hardware. + +The application, ideally, is developed only once. It makes calls to the wrapper library, which in turn invokes the dynamic libraries of the language and proto-runtime. +When an application is executed, the loader binds the +dynamic libraries, connecting them to the application. + In this way, a single, +unchanging, executable gains access to machine-specific implementations of language and proto-runtime. + +However, the success of the compile-once approach has +limits in practice. Each machine's characteristics determine the size of unit of work that gives the best performance. When too small, overhead in the runtime system required to create the work, manage constraints, and perform assignment becomes larger than the work +itself. When units become too large, not enough units exist to keep all the cores busy. Thankfully, the range between is large enough, for most applications, that neither limit is hit, on most machines. As machines evolve, though, this happy circumstance is likely to change, necessitating recompiling and possibly hand modifying the code. + +\end{document} + + diff -r 9b9a2497757d -r eb146c5c05a8 0__Papers/Vote_Bucks/MSW_A4_format.doc Binary file 0__Papers/Vote_Bucks/MSW_A4_format.doc has changed diff -r 9b9a2497757d -r eb146c5c05a8 1__Presentations/11__3__LCPC_11/VMS_presentation_for_LCPC_11.odp Binary file 1__Presentations/11__3__LCPC_11/VMS_presentation_for_LCPC_11.odp has changed diff -r 9b9a2497757d -r eb146c5c05a8 1__Presentations/13__Jy_01__DSLDI/DSL_on_top_of_Thds.svg --- /dev/null Thu Jan 01 00:00:00 1970 +0000 +++ b/1__Presentations/13__Jy_01__DSLDI/DSL_on_top_of_Thds.svg Sat Aug 03 19:24:22 2013 -0700 @@ -0,0 +1,341 @@ + + + + + + + + + + + + + + + + + image/svg+xml + + + + + + + Thd ConstructBehavior + + Hardware Specific + Assignmentof Workonto Cores + DSL ConstructBehavior + DSL ConstructBehavior + + Hardware Specific(Proto-Runtime) + Assignmentof Workonto Cores + Hardware Abstraction Interface + + + + HardwareSpecific Choices + + Thd Interface + + + diff -r 9b9a2497757d -r eb146c5c05a8 1__Presentations/13__Jy_01__DSLDI/Level_of_lang_fig.svg --- /dev/null Thu Jan 01 00:00:00 1970 +0000 +++ b/1__Presentations/13__Jy_01__DSLDI/Level_of_lang_fig.svg Sat Aug 03 19:24:22 2013 -0700 @@ -0,0 +1,156 @@ + + + + + + + + + + + + + + + + image/svg+xml + + + + + + + HW + + + + + PRT + Threads + DSL + + diff -r 9b9a2497757d -r eb146c5c05a8 1__Presentations/13__Jy_01__DSLDI/PRT__modules.svg --- /dev/null Thu Jan 01 00:00:00 1970 +0000 +++ b/1__Presentations/13__Jy_01__DSLDI/PRT__modules.svg Sat Aug 03 19:24:22 2013 -0700 @@ -0,0 +1,228 @@ + + + + + + + + + + + + + + + + + image/svg+xml + + + + + + + + runtime system + ConstructBehavior + + Hardware Specific(Proto-Runtime) + Assignmentof Workonto Cores + Language Plug-in + Hardware Abstraction Interface + + + + + diff -r 9b9a2497757d -r eb146c5c05a8 1__Presentations/13__Jy_01__DSLDI/PR__timeline_dual.svg --- /dev/null Thu Jan 01 00:00:00 1970 +0000 +++ b/1__Presentations/13__Jy_01__DSLDI/PR__timeline_dual.svg Sat Aug 03 19:24:22 2013 -0700 @@ -0,0 +1,446 @@ + + + + + + + + + + + + + + + + image/svg+xml + + + + + + + + + + Suspend(Point 2.S) + + + + Resume (Point 2.R) + + Timeline B + + + Physical time + + + + Suspend(Point 1.S) + + + + Resume (Point 1.R) + + Timeline A + + + + + + + Suspend(Point 2.S) + + + + Resume (Point 2.R) + + Timeline B + + + Physical time + + + + Suspend(Point 1.S) + + + + Resume (Point 1.R) + + Timeline A + + + + diff -r 9b9a2497757d -r eb146c5c05a8 1__Presentations/13__Jy_01__DSLDI/PR__timeline_single.svg --- /dev/null Thu Jan 01 00:00:00 1970 +0000 +++ b/1__Presentations/13__Jy_01__DSLDI/PR__timeline_single.svg Sat Aug 03 19:24:22 2013 -0700 @@ -0,0 +1,306 @@ + + + + + + + + + + + + + + + + image/svg+xml + + + + + + + + Physical time + + + + Suspend(Point 1.S) + + + + Resume (Point 1.R) + + Timeline A + + + Physical time + + + + Suspend(Point 1.S) + + + + Resume (Point 1.R) + + Timeline A + + + + + Hiddenmeta-comm + + diff -r 9b9a2497757d -r eb146c5c05a8 1__Presentations/13__Jy_01__DSLDI/ProtoRuntime_expl.odp Binary file 1__Presentations/13__Jy_01__DSLDI/ProtoRuntime_expl.odp has changed diff -r 9b9a2497757d -r eb146c5c05a8 1__Presentations/13__Jy_01__DSLDI/ProtoRuntime_expl.pdf Binary file 1__Presentations/13__Jy_01__DSLDI/ProtoRuntime_expl.pdf has changed diff -r 9b9a2497757d -r eb146c5c05a8 1__Presentations/13__Jy_01__DSLDI/software_stack_PRT.svg --- /dev/null Thu Jan 01 00:00:00 1970 +0000 +++ b/1__Presentations/13__Jy_01__DSLDI/software_stack_PRT.svg Sat Aug 03 19:24:22 2013 -0700 @@ -0,0 +1,2209 @@ + + + + + + + + + + + + + + + + + image/svg+xml + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + Lang Syntax + + + Request Intf + + + + PRT Intf + + + + ISA + + + + + + + + + Interface + Layer + + + + + Specializer + + + + + Specializer + + + + + Specializer + + + + + Specializer + + + + Toolchain + + + Specializer + + + + + Specializer + + + Proto- + Runtime + Hardware + Language + Plugin + Language + Toolchain + Application + + Executable + Source Code + Runtime + Toolchain + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + Plugin + Proto-RT + Proto-RT + Proto-RT + Proto-RT + Proto-RT + Proto-RT + DSL2 + OpenMP + DSL1 + DSL2 + OpenMP + DSL1 + DSL2 + + Toolchain + + Toolchain + OpenMP + Applications that mix languages + DSL1 + + + + + Development tool that translates syntax and directs to toolchains + + diff -r 9b9a2497757d -r eb146c5c05a8 1__Presentations/13__My_07__ACG_on_protoruntime_for_CWI/ProtoRuntime_expl.odp Binary file 1__Presentations/13__My_07__ACG_on_protoruntime_for_CWI/ProtoRuntime_expl.odp has changed diff -r 9b9a2497757d -r eb146c5c05a8 9__Owned_by_Others/armin/kronawitter-m.pdf Binary file 9__Owned_by_Others/armin/kronawitter-m.pdf has changed diff -r 9b9a2497757d -r eb146c5c05a8 CVs/13_Jy__ERCIM_CV/ERCIM_CV.pdf Binary file CVs/13_Jy__ERCIM_CV/ERCIM_CV.pdf has changed diff -r 9b9a2497757d -r eb146c5c05a8 CVs/13_Jy__ERCIM_CV/ERCIM_CV.tex --- /dev/null Thu Jan 01 00:00:00 1970 +0000 +++ b/CVs/13_Jy__ERCIM_CV/ERCIM_CV.tex Sat Aug 03 19:24:22 2013 -0700 @@ -0,0 +1,205 @@ +%&latex +%% Derived from: `cvctan.tex' + +\documentclass[a4paper]{article} + +\usepackage{tabularx} + +%\usepackage{doublespace} +%\setstretch{1.1} + +%\usepackage{ae} +\usepackage[T1]{fontenc} +\usepackage{CV} + + +\oddsidemargin 0in +\evensidemargin 0in +\textwidth\paperwidth +\advance \textwidth by -2in +\topmargin 0in +\textheight\paperheight +\advance\textheight -2in +\headheight 0pt +\headsep 0pt +\footskip 0pt + + +%%%%%%%%%%%%%%%%%%%%%% +\begin{document} + +\pagestyle{empty} +\bibliographystyle{plain} +%Ueberschrift +\begin{center} +\huge{\textsc{Curriculum Vitae}} +\vspace{\baselineskip} + +\Large{\textsc{Sean Halle}} +\end{center} +%\vspace{1.5\baselineskip} + +\section{} +\noindent\hspace*{\tabcolsep} +\begin{minipage}{0.4\linewidth} + +{\large{\textsc{Address}}}\\ +Carolina Macgillavrylaan 1976 \\ +1098XE Amsterdam\\[3pt] +Tel~: +31 616 434 534~\\ +EMail~: \texttt{seanhalle@yahoo.com} +\end{minipage} +\begin{minipage}{0.4\linewidth} + +{\large{\textsc{Personal Details}}}\\ +Nationality: US\\ +Gender: Male\\ +\\ + +\end{minipage} + +\section{Overview/Summary} Sean is a researcher, and former entrepreneur. As an undergraduate and masters student, his research at UC Berkeley demonstrated the first evidence of secure communication using chaos, spread spectrum communication using a chaotic carrier signal, and gain from perturbation of chaotic circuits, with a total of 680+ citations to these papers. He left with his Masters in 1994, to pursue starting a company with technology developed during a graduate course, eventually founding a fabless chip company around a massively parallel MIMD-SIMD low-power processor for graphics (ProSide), in 1997. After the company's demise, he switched to software and worked his way up the chain, ending at Chief Software Architect at Nevik in 2000. The dot-com crash precipitated a return to academia to start his PhD in 2003, where he worked on parallelism, developing a theory of parallel computation, and a performance-portable software stack. As part of this, in 2008 he was invited by Albert Cohen to work in Paris at INRIA, the national computer science research institute for France, concentrating on new parallel languages for high productivity and high performance portability. This led to BLIS and proto-runtime, two technologies that became the basis of his dissertation, for which he received his PhD in 2011. He subsequently +advanced the proto-runtime work as a post-doc at TU +Berlin, and is currently advancing it further as an +ERCIM fellow at CWI in Amsterdam. + + + +\section{Education} + +\begin{CV} +\item[May 1992:] UC Berkeley, BSEE, Dept. of Electrical Engineering and Computer Science. +\item[May 1994:] UC Berkeley, MSEE, Dept. of Electrical Engineering and Computer Science. + +Thesis on \emph{Experimental Chaos}. Published the first papers in the field on "Gain from Chaos," "Spread Spectrum Communication Using Chaos," and "Secure Communication Using Chaos." The papers, combined, have garnered in excess of 450 citations. Advisor: Leon O Chua. + +\item[June 2011:] UC Santa Cruz, PhD, Dept. of Computer Engineering. + +Dissertation on \emph{theory of parallel computation and tools for delivering performance-portable parallel software}. Advisors: Albert Cohen (INRIA, Paris), and Jose Renau (UC Santa Cruz). + +\end{CV} + + +\section{Experience} + +\begin{CV} + + +\item[Apr '13 to Apr '14:] ERCIM Fellow at CWI in +Amsterdam. + + Implementing the Reo language on top of proto-runtime, + and extending proto-runtime to distributed machines, + developing on the Netherlands' national supercomputer. + +\item[Jun '11 to Jun '12:] Post-doctorate researcher at Technical University Berlin. + + Oversaw 6 students who worked on: verifying the Holistic Model of Parallel Computation (proposed in Dissertation), design of a low-power GPU that is free from programming and application restrictions, improvement of proto-runtime, and implementation of the HWSim language on top of proto-runtime. + +\item[Apr '08 to Apr '11:] INRIA, Paris and Ecole Normale Supereur: Performed research on Portable High Performance Parallelism. + +In 2008-2009 period demonstrated DKU and BLIS framework in Java and in C, running on multi-core shared memory machines, a heterogeneous collection of them and on the Cell processor. In 2010 and 2011 designed WorkTable language for high productivity parallel coding for Enterprise applications, and HWSim for high-performance simulation of hardware designs, using parallel host machines. In 2011 delivered Virtualized Master-Slave (VMS), a hardware abstraction to simplify creation and implementation of domain-specific parallel languages, and the basis of a software stack for performant-portable parallel software. The work there formed the main results in his dissertation. + +\item[Sept '03 to Apr '08:] UC Santa Cruz: Performed research on a theory of parallel computation, and developed a programming system for performance-portable software called CodeTime, in addition to an analytic performance model for out-of-order pipelines. + +\item[Apr '02 to Sept '03:] Freelance: In anticipation of starting a fabless chip company, architected an ultra low power multi-threaded high-throughput processor. Developed a detailed analytic model of the processor. Wrote behavioral code and a test suite to demonstrate its performance. Pursued series-A funding. + +\item[Dec '00 to Apr '02:] Nevik Networks: As Chief Software Architect, designed and was responsible for the team implementing a telecom abstraction layer that provides web-based end-customer provisioning of big-iron class 5 switches as well as soft-switches. Led development, drove requirements gathering and scoping of the product. + +\item[Dec '99 to Dec '00:] SRI International: A member of SRI's enterprise software consulting spin-off. Designed a high speed trading system for Deutsche Bank's fixed income securities market. Co-architected, for American Century, an integrated financial system. Contributed papers analyzing and detailing electronic exchanges. Technical lead on implementation of a financial planning services exchange. + +\item[Apr '99 to Dec '99:] Cisco Systems, contract: Member of web based ordering tool team (\$15 Billion in orders annually via this tool). Added functionality via modifying front-end servlet code, back-end business logic, and Oracle database tables. + +\item[Apr '98 to Mar '99:] Sun Microsystems, JavaSoft division, contract: Participated in debug of the AWT portion of the Java language for the 1.2 release. Contributed to specification of the automated GUI testing API that later appeared in release 1.5. Developed automated testing tools. + +\item[Mar '96 to Dec '97:] ProSide Inc. Acquired funding for a novel architecture fusing SIMD and SPMD of his design. Targeted at 3D graphics, was also a general "loop accelerator" that appeared as smart-memory. Developed base programming language and tools. + +\item[Jan '95 to Jan '96:] Digital Equipment Corporation: Held position created for him by Dan Dobberpuhl to evaluate advanced technologies for use in Alpha processors. Evaluated adiabatic logic, Time-Stationary Computation, and other low power, high speed technologies. Invented five new logic families and a novel division technique based on deduction. Designed high speed pseudo-self-timed array multiplier for low cost Alpha core and StrongArm VLIW co-processor using a combination of static, domino, and differential cascode (DCVSL) logic. + + +\end{CV} + +\pagebreak +\section{Personal References} + +\noindent These persons are familiar with my professional qualifications and my character: + +\begin{table}[ht] +\begin{tabular}{@{}lll@{}} +\textbf{Prof. Albert Cohen} \\ +Thesis supervisor & Phone: & +33-1-44-32-21-67\\ +Department d'Informatiqe & Email & albert.cohen@inria.fr\\ +Ecole Normale Superieure \\ +45 rue d'Ulm\\ +75005 Paris\\ +France +\end{tabular} + +\vspace{.15in} +\begin{tabular}{@{}lll@{}} +\textbf{Prof. Jose Renau} \\ +Thesis supervisor & Phone: & +1-831-459-1847\\ + 1156 High Street MS: SOE2 & Email & renau@soe.ucsc.edu\\ +Santa Cruz, CA 95064 \\ +USA +\end{tabular} + + +\vspace{.15in} +\begin{tabular}{@{}lll@{}} +\textbf{Prof. Farhad Arbab} \\ +Principle Investigator & Phone: & +31 30 314 73131\\ +CWI & Email & Farhad.Arbab@cwi.nl\\ +Science Park 123 \\ +1098XG Amsterdam\\ +Netherlands +\end{tabular} + +\end{table} + +\cite{BLISHome, +HotPar10_w_BLIS, +HotPar11_w_Stack, +PStackHome, +VMS_LCPC_11, +VMSHome, +WorkTableHome, +BaCTiLTechRep, +CIPTechRep, +CTOSTechRep, +CTPlatformTechRep, +CTRTTechRep, +DKUTechRep_09, +EQNLangTechRep, +GainFromChaos_Halle_92, +MentalFrameworkTechRep_06, +Halle_GainFromChaos_pub, +Halle_Secure_pub, +Halle_SpreadSpect_pub} + +\bibliography{bib_for_papers_apr_2012} + + + +\end{document} + + + + + +%Tabellen +\begin{table}[htbp] \centering% +\begin{tabular}{lll}\hline\hline +1 & 2 & 3 \\ \hline +1 & \multicolumn{2}{c}{2} \\ +\hline +\end{tabular} +\caption{Titel\label{Tabelle: Label}} +\end{table} + + + + + + + diff -r 9b9a2497757d -r eb146c5c05a8 CVs/13_Jy__ERCIM_CV/bib_for_papers_apr_2012.bib --- /dev/null Thu Jan 01 00:00:00 1970 +0000 +++ b/CVs/13_Jy__ERCIM_CV/bib_for_papers_apr_2012.bib Sat Aug 03 19:24:22 2013 -0700 @@ -0,0 +1,916 @@ +@techrep{SyncConstr_impl_w_distr_coherence_HW_Utah_96, + author = {Carter, J. B. and Kuo, C.-C. and Kuramkote, R.}, + title = { A comparison of software and hardware synchronization mechanisms for distributed shared memory multiprocessors}, + institution = {University of Utah, Salt Lake City, UT}, + year = 1996, + url = {http://www.cs.utah.edu/research/techreports/1996/pdf/UUCS-96-011.pdf}, + number = {UUCS-96-011} +} +@Article{SWCoherence_Hill_SW_for_shared_coherence_w_HW_support_93, + author = {Hill, Mark D. and Larus, James R. and Reinhardt, Steven K. and Wood, David A.}, + title = {Cooperative shared memory: software and hardware for scalable multiprocessors}, + journal = {ACM Trans. Comput. Syst.}, + volume = 11, + number = 4, + year = 1993, + pages = {300--318} +} +@InProceedings{SWCache_MIT_embedSW_manages_cache_w_HW_supp, + author = {Chiou, Derek and Jain, Prabhat and Rudolph, Larry and Devadas, Srinivas}, + title = {Application-specific memory management for embedded systems using software-controlled caches}, + booktitle = {DAC}, + year = 2000, + pages = {416--419} +} +@InProceedings{SWCache_instr_trig_HW_supp_04, + author = {Janapsatya, Andhi and Parameswaran, Sri and Ignjatovic, A.}, + title = {Hardware/software managed scratchpad memory for embedded system}, + booktitle = {Proceedings of the 2004 IEEE/ACM International conference on Computer-aided design}, + series = {ICCAD '04}, + year = 2004, + pages = {370--377} +} +@InProceedings{SWCache_arch_supp_OS_policy_06, + author = {Rafique, Nauman and Lim, Won-Taek and Thottethodi, Mithuna}, + title = {Architectural support for operating system-driven CMP cache management}, + booktitle = {Proceedings of the 15th international conference on Parallel architectures and compilation techniques}, + series = {PACT '06}, + year = 2006, + pages = {2--12} +} +@InProceedings{SWCoherence_on_Distr_Mem_90, + author = {Bennett, J.K. and Carter, J.B. and Zwaenepoel, W.}, + booktitle = {Computer Architecture, 1990. Proceedings., 17th Annual International Symposium on}, + title = {Adaptive software cache management for distributed shared memory architectures}, + year = 1990, + pages = {125 -134} +} +@InProceedings{Charm_runtime_opt_10, + author = {Mei, Chao and Zheng, Gengbin and Gioachin, Filippo and Kal{\'e}, Laxmikant V.}, + title = {Optimizing a parallel runtime system for multicore clusters: a case study}, + booktitle = {The 2010 TeraGrid Conference}, + year = 2010, + pages = {12:1--12:8} +} +@InProceedings{TCC_Hammond_ISCA_04, + author = {Hammond, Lance and al, et}, + title = {Transactional Memory Coherence and Consistency}, + series = {ISCA '04}, + pages = {102--}, + booktitle = {}, + year = {} +} +@Misc{WorkTableHome, + author = {Halle, Sean}, + note = {http://musictwodotoh.com/worktable/content/refman.pdf}, + title = {The WorkTable Language Reference Manual}, + year = 2012 +} +@Misc{HWSimHome, + author = {Halle, Sean and Hausers, Stefan}, + note = {http://musictwodotoh.com/hwsim/content/refman.pdf}, + title = {The HWSim Language Reference Manual}, + year = 2012 +} +@Article{Lamport78, + author = {Lamport, Leslie}, + title = {Time, clocks, and the ordering of events in a distributed system}, + journal = {Commun. ACM}, + volume = 21, + issue = 7, + year = 1978, + pages = {558--565} +} +@Article{Lamport87, + author = {Lamport, Leslie}, + title = {A fast mutual exclusion algorithm}, + journal = {ACM Trans. Comput. Syst.}, + volume = 5, + issue = 1, + year = 1987, + pages = {1--11} +} +@InProceedings{Dijkstra67, + author = {Dijkstra, Edsger W.}, + title = {The structure of the "{THE}"-multiprogramming system}, + booktitle = {Proceedings of the first ACM symposium on Operating System Principles}, + series = {SOSP '67}, + year = 1967, + pages = {10.1--10.6} +} +@Article{Conway63, + author = {Conway, Melvin E.}, + title = {Design of a separable transition-diagram compiler}, + journal = {Commun. ACM}, + volume = 6, + issue = 7, + year = 1963, + pages = {396--408} +} +@Book{ComponentModel00, + author = {G Leavens and M Sitaraman (eds)}, + title = {Foundations of Component-Based Systems}, + publisher = {Cambridge University Press}, + year = 2000 +} +@Misc{Hewitt10, + author = {Carl Hewitt}, + title = {Actor Model of Computation}, + year = 2010, + note = {http://arxiv.org/abs/1008.1459} +} +@Article{Actors97, + author = {Agha,G. and Mason,I. and Smith,S. and Talcott,C.}, + title = {A foundation for actor computation}, + journal = {Journal of Functional Programming}, + volume = 7, + number = 01, + pages = {1-72}, + year = 1997 +} +@Article{SchedActivations, + author = {Anderson, Thomas E. and Bershad, Brian N. and Lazowska, Edward D. and Levy, Henry M.}, + title = {Scheduler activations: effective kernel support for the user-level management of parallelism}, + journal = {ACM Trans. Comput. Syst.}, + volume = 10, + issue = 1, + month = {February}, + year = 1992, + pages = {53--79} +} +@InProceedings{BOMinManticore, + author = {Fluet, Matthew and Rainey, Mike and Reppy, John and Shaw, Adam and Xiao, Yingqi}, + title = {Manticore: a heterogeneous parallel language}, + booktitle = {Proceedings of the 2007 workshop on Declarative aspects of multicore programming}, + series = {DAMP '07}, + year = 2007, + pages = {37--44}, + numpages = 8 +} +@TechReport{Halle_GainFromChaos_TechRep, + author = {Halle, K.S. and Chua, Leon O. and Anishchenko, V.S. and Safonova, M.A.}, + title = {Signal Amplification via Chaos: Experimental Evidence}, + institution = {EECS Department, University of California, Berkeley}, + year = 1992, + url = {http://www.eecs.berkeley.edu/Pubs/TechRpts/1992/2223.html}, + number = {UCB/ERL M92/130} +} +@Article{Halle_GainFromChaos_pub, + author = {K.S. Halle and Leon O. Chua and V.S. Anishchenko and M.A. Safonova}, + title = {Signal Amplification via Chaos: Experimental Evidence}, + journal = {Int. J. of Bifurcation and Chaos }, + pages = {290-308}, + year = 1993 +} +@Article{Halle_SpreadSpect_pub, + author = {K.S. Halle and C.W. Wu and M. Itoh and L. O. Chua}, + title = {Spread Spectrum Communication Through Modulation of Chaos}, + journal = {Int. J. of Bifurcation and Chaos }, + pages = {469-477}, + year = 1993, + note = {cited by 232} +} +@Article{Halle_Secure_pub, + author = {V. Kocarev and K.S. Halle and K. Eckert and L. O. Chua and V. Parlitz}, + title = {Experimental Demonstration of Secure Communications Via Chaotic Synchronization}, + journal = {Int. J. of Bifurcation and Chaos }, + pages = {709-713}, + year = 1992, + note = {cited by 457} +} +@InProceedings{HotPar10_w_BLIS, + author = {Sean Halle and Albert Cohen}, + booktitle = {HOTPAR '10: USENIX Workshop on Hot Topics in Parallelism}, + month = {June}, + title = {Leveraging Semantics Attached to Function Calls to Isolate Applications from Hardware}, + year = 2010 +} +@InProceedings{HotPar11_w_Stack, + author = {Sean Halle and Albert Cohen}, + booktitle = {HOTPAR '11: USENIX Workshop on Hot Topics in Parallelism}, + month = {May}, + title = {Support of Collective Effort Towards Performance Portability}, + year = 2011 +} +@Article{VMS_LCPC_11, + author = {Sean Halle and Albert Cohen}, + title = {A Mutable Hardware Abstraction to Replace Threads}, + journal = {24th International Workshop on Languages and Compilers for Parallel Languages (LCPC11)}, + year = 2011 +} +@Misc{StackTechRep_10, + author = {Halle, Sean and Nadezhkin, Dmitry and Cohen, Albert}, + note = {http://www.soe.ucsc.edu/share/technical-reports/2010/ucsc-soe-10-02.pdf}, + title = {A Framework to Support Research on Portable High Performance Parallelism}, + year = 2010 +} +@Misc{CTBigStepSemTechRep_06, + author = {Halle, Sean}, + note = {http://www.soe.ucsc.edu/share/technical-reports/2006/ucsc-crl-06-11.pdf}, + title = {The Big-Step Operational Semantics of CodeTime Circuits}, + year = 2006 +} +@Misc{MentalFrameworkTechRep_06, + author = {Halle, Sean}, + note = {http://www.soe.ucsc.edu/share/technical-reports/2006/ucsc-crl-06-12.pdf}, + title = {A Mental Framework for use in Creating Hardware Independent Parallel Languages}, + year = 2006 +} +@Misc{DKUTechRep_09, + author = {Halle, Sean and Cohen, Albert}, + note = {http://www.soe.ucsc.edu/share/technical-reports/2009/ucsc-soe-09-06.pdf}, + title = {DKU Pattern for Performance Portable Parallel Software}, + year = 2009 +} +@Misc{EQNLangTechRep, + author = {Halle, Sean}, + note = {http://www.soe.ucsc.edu/share/technical-reports/2009/ucsc-soe-09-16.pdf}, + title = {An Extensible Parallel Language}, + year = 2009 +} +@Misc{CTOSTechRep, + author = {Halle, Sean}, + note = {http://www.soe.ucsc.edu/share/technical-reports/2009/ucsc-soe-09-15.pdf}, + title = {A Hardware-Independent Parallel Operating System Abstraction Layer for Parallelism}, + year = 2009 +} +@Misc{SideEffectsTechRep, + author = {Halle, Sean and Cohen, Albert}, + note = {http://www.soe.ucsc.edu/share/technical-reports/2009/ucsc-soe-09-14.pdf}, + title = {Parallel Language Extensions for Side Effects}, + year = 2009 +} +@Misc{BaCTiLTechRep, + author = {Halle, Sean}, + note = {http://www.soe.ucsc.edu/share/technical-reports/2006/ucsc-crl-06-08.pdf}, + title = {BaCTiL: Base CodeTime Language}, + year = 2006 +} +@Misc{CTPlatformTechRep, + author = {Halle, Sean}, + note = {http://www.soe.ucsc.edu/share/technical-reports/2006/ucsc-crl-06-09.pdf}, + title = {The Elements of the CodeTime Software Platform}, + year = 2006 +} +@Misc{CTRTTechRep, + author = {Halle, Sean}, + note = {http://www.soe.ucsc.edu/share/technical-reports/2006/ucsc-crl-06-10.pdf}, + title = {A Scalable and Efficient Peer-to-Peer Run-Time System for a Hardware Independent Software Platform}, + year = 2006 +} +@Misc{CIPTechRep, + author = {Halle, Sean}, + note = {http://www.soe.ucsc.edu/share/technical-reports/2005/ucsc-crl-05-05.pdf}, + title = {The Case for an Integrated Software Platform for {HEC} Illustrated Using the CodeTime Platform}, + year = 2005 +} +@Misc{DKU_Infra_site, + author = {Sean Halle and Albert Cohen}, + note = {http://omp.musictwodotoh.com}, + title = {{DKU} infrastructure server} +} +@Misc{DKUSourceForge, + author = {Sean Halle and Albert Cohen}, + month = {November}, + note = {http://dku.sourceforge.net}, + title = {{DKU} website}, + year = 2008 +} +@Misc{BLISHome, + author = {Sean Halle and Albert Cohen}, + month = {November}, + note = {http://blisplatform.sourceforge.net}, + title = {{BLIS} website}, + year = 2008 +} +@Misc{VMSHome, + author = {Sean Halle and Merten Sach and Ben Juurlink and Albert Cohen}, + note = {http://virtualizedmasterslave.org}, + title = {{VMS} Home Page}, + year = 2010 +} +@Misc{PStackHome, + author = {Sean Halle}, + note = {http://pstack.sourceforge.net}, + title = {{PStack} Home Page -- A Software Stack for Performantly Portable Parallelism}, + year = 2012 +} +@Misc{DeblockingCode, + note = {http://dku.svn.sourceforge.net/viewvc/dku/branches/DKU\_C\_\_Deblocking\_\_orig/}, + title = {{DKU-ized Deblocking Filter} code} +} +@Misc{SampleBLISCode, + note = {http://dku.sourceforge.net/SampleCode.htm}, + title = {{Sample BLIS Code}} +} +@Misc{OMPHome, + note = {http://www.openmediaplatform.eu/}, + title = {{Open Media Platform} homepage} +} +@Misc{MapReduceHome, + author = {Google Corp.}, + note = {http://labs.google.com/papers/mapreduce.html}, + title = {{MapReduce} Home page} +} +@Misc{TBBHome, + author = {Intel Corp.}, + note = {http://www.threadingbuildingblocks.org}, + title = {{TBB} Home page} +} +@Misc{HPFWikipedia, + author = {Wikipedia}, + note = {http://en.wikipedia.org/wiki/High_Performance_Fortran}, + title = {{HPF} wikipedia page} +} +@Misc{OpenMPHome, + author = {{OpenMP} organization}, + note = {http://www.openmp.org}, + title = {{OpenMP} Home page} +} +@Misc{MPIHome, + author = {open-mpi organization}, + note = {http://www.open-mpi.org}, + title = {{Open MPI} Home page} +} +@Misc{OpenCLHome, + author = {Kronos Group}, + note = {http://www.khronos.org/opencl}, + title = {{OpenCL} Home page} +} +@Misc{CILKHome, + author = {Cilk group at MIT}, + note = {http://supertech.csail.mit.edu/cilk/}, + title = {{CILK} homepage} +} +@InProceedings{Fri98, + author = {M. Frigo and C. E. Leiserson and K. H. Randall}, + title = {The Implementation of the Cilk-5 Multithreaded Language}, + booktitle = {PLDI '98: Proceedings of the 1998 ACM SIGPLAN conference on Programming language design and implementation}, + pages = {212--223}, + year = 1998, + address = {Montreal, Quebec}, + month = jun +} +@Misc{TitaniumHome, + note = {http://titanium.cs.berkeley.edu}, + title = {{Titanium} homepage} +} +@InProceedings{CnCInHotPar, + author = {Knobe, Kathleen}, + booktitle = {HOTPAR '09: USENIX Workshop on Hot Topics in Parallelism}, + title = {Ease of Use with Concurrent Collections {(CnC)}}, + year = 2009 +} +@Misc{CnCHome, + author = {Intel Corp.}, + note = {http://software.intel.com/en-us/articles/intel-concurrent-collections-for-cc/}, + title = {{CnC} homepage} +} +@Misc{SpiralHome, + author = {Spiral Group at CMU}, + note = {http://www.spiral.net}, + title = {{Spiral} homepage} +} +@Misc{ScalaHome, + author = {Scala organization}, + note = {http://www.scala-lang.org/}, + title = {{Scala} homepage} +} +@Misc{UPCHome, + author = {UPC group at UC Berkeley}, + note = {http://upc.lbl.gov/}, + title = {{Unified Parallel C} homepage} +} +@Misc{SuifHome, + note = {http://suif.stanford.edu}, + title = {{Suif} Parallelizing compiler homepage} +} +@Article{SEJITS, + author = {B. Catanzaro and S. Kamil and Y. Lee and K. Asanovic and J. Demmel and K. Keutzer and J. Shalf and K. Yelick and A. Fox}, + title = {SEJITS: Getting Productivity AND Performance With Selective Embedded JIT Specialization}, + journal = {First Workshop on Programmable Models for Emerging Architecture at the 18th International Conference on Parallel Architectures and Compilation Techniques }, + year = 2009 +} +@InProceedings{Arnaldo3D, + author = {Azevedo, Arnaldo and Meenderinck, Cor and Juurlink, Ben and Terechko, Andrei and Hoogerbrugge, Jan and Alvarez, Mauricio and Ramirez, Alex}, + title = {Parallel H.264 Decoding on an Embedded Multicore Processor}, + booktitle = {HiPEAC '09: Proceedings of the 4th International Conference on High Performance Embedded Architectures and Compilers}, + year = 2009, + pages = {404--418} +} +@Article{NarayananGPUSched, + author = {Narayanan Sundaram and Anand Raghunathan and Srimat T. Chakradhar}, + title = {A framework for efficient and scalable execution of domain-specific templates on GPUs}, + journal = {International Parallel and Distributed Processing Symposium {(IPDPS)}}, + year = 2009, + pages = {1-12} +} +@InProceedings{PolyForGPU, + author = {Baskaran, Muthu Manikandan and Bondhugula, Uday and Krishnamoorthy, Sriram and Ramanujam, J. and Rountev, Atanas and Sadayappan, P.}, + title = {A compiler framework for optimization of affine loop nests for gpgpus}, + booktitle = {ICS '08: Proceedings of the 22nd annual international conference on Supercomputing}, + year = 2008, + pages = {225--234} +} +@InProceedings{Loulou08, + author = {Pouchet, Louis-No\"{e}l and Bastoul, C\'{e}dric and Cohen, Albert and Cavazos, John}, + title = {Iterative optimization in the polyhedral model: part ii, multidimensional time}, + booktitle = {ACM SIGPLAN conference on Programming language design and implementation {(PLDI)} }, + year = 2008, + pages = {90--100} +} +@InProceedings{MergeInHotPar, + author = {Michael D. Linderman and James Balfour and Teresa H. Meng and William J. Dally}, + booktitle = {HOTPAR '09: USENIX Workshop on Hot Topics in Parallelism}, + month = {March}, + title = {Embracing Heterogeneity \- Parallel Programming for Changing Hardware}, + year = 2009 +} +@InProceedings{GaloisRef, + author = {Kulkarni, Milind and Pingali, Keshav and Walter, Bruce and Ramanarayanan, Ganesh and Bala, Kavita and Chew, L. Paul}, + title = {Optimistic parallelism requires abstractions}, + booktitle = {PLDI '07: Proceedings of the 2007 ACM SIGPLAN conference on Programming language design and implementation}, + year = 2007, + pages = {211--222} +} +@Book{Allen2002, + author = {Kennedy, Ken and Allen, John R.}, + title = {Optimizing compilers for modern architectures: a dependence-based approach}, + year = 2002, + publisher = {Morgan Kaufmann Publishers Inc.} +} +@Misc{Stephens95, + author = {R. Stephens}, + title = {A Survey Of Stream Processing}, + year = 1995 +} +@InProceedings{Palatin06, + author = {P Palatin and Y Lhuillier and O Temam}, + title = {CAPSULE: Hardware-assisted parallel execution of componentbased programs}, + booktitle = {In Proceedings of the 39th Annual International Symposium on Microarchitecture}, + year = 2006, + pages = {247--258} +} +@InProceedings{Sequioa06, + author = {Fatahalian,, Kayvon and Horn,, Daniel Reiter and Knight,, Timothy J. and Leem,, Larkhoon and Houston,, Mike and Park,, Ji Young and Erez,, Mattan and Ren,, Manman and Aiken,, Alex and Dally,, William J. and Hanrahan,, Pat}, + title = {Sequoia: programming the memory hierarchy}, + booktitle = {SC '06: Proceedings of the 2006 ACM/IEEE conference on Supercomputing}, + year = 2006, + pages = 83 +} +@Book{Cole89, + author = {M Cole}, + title = {Algorithmic skeletons: Structured management of parallel computation}, + publisher = {Pitman}, + year = 1989 +} +@InProceedings{Ginhac98, + author = {Dominique Ginhac and Jocelyn Serot and Jean Pierre Derutin}, + title = {Fast prototyping of image processing applications using functional skeletons on a MIMD-DM architecture}, + booktitle = {In IAPR Workshop on Machine Vision and Applications}, + year = 1998, + pages = {468--471} +} +@InProceedings{Serot08MetaParallel, + author = {Serot, Jocelyn and Falcou, Joel}, + title = {Functional Meta-programming for Parallel Skeletons}, + booktitle = {ICCS '08: Proceedings of the 8th international conference on Computational Science, Part I}, + year = 2008, + pages = {154--163} +} +@InProceedings{Darlington93, + author = {J. Darlington and A. J. Field and P. G. Harrison and P. H. J. Kelly and D. W. N. Sharp and Q. Wu}, + title = {Parallel programming using skeleton functions}, + booktitle = {}, + year = 1993, + pages = {146--160}, + publisher = {Springer-Verlag} +} +@Article{Asanovic06BerkeleyView, + title = {{The landscape of parallel computing research: A view from berkeley}}, + author = {Asanovic, K. and Bodik, R. and Catanzaro, B.C. and Gebis, J.J. and Husbands, P. and Keutzer, K. and Patterson, D.A. and Plishker, W.L. and Shalf, J. and Williams, S.W. and others}, + journal = {Electrical Engineering and Computer Sciences, University of California at Berkeley, Technical Report No. UCB/EECS-2006-183, December}, + volume = 18, + number = {2006-183}, + pages = 19, + year = 2006 +} +@Misc{BerkeleyPattLang, + note = {http://parlab.eecs.berkeley.edu/wiki/patterns}, + title = {{Berkeley Pattern Language}} +} +@Book{Mattson04Patterns, + title = {{Patterns for parallel programming}}, + author = {Mattson, T. and Sanders, B. and Massingill, B.}, + year = 2004, + publisher = {Addison-Wesley Professional} +} +@Article{Skillicorn98, + title = {{Models and languages for parallel computation}}, + author = {Skillicorn, D.B. and Talia, D.}, + journal = {ACM Computing Surveys (CSUR)}, + volume = 30, + number = 2, + pages = {123--169}, + year = 1998 +} +@Conference{Blelloch93NESL, + title = {{Implementation of a portable nested data-parallel language}}, + author = {Blelloch, G.E. and Hardwick, J.C. and Chatterjee, S. and Sipelstein, J. and Zagha, M.}, + booktitle = {Proceedings of the fourth ACM SIGPLAN symposium on Principles and practice of parallel programming}, + pages = {102--111}, + year = 1993, + organization = {ACM New York, NY, USA} +} +@Article{McgrawSisal, + title = {{SISAL: Streams and iteration in a single assignment language: Reference manual version 1.2}}, + author = {McGraw, J. and Skedzielewski, SK and Allan, SJ and Oldehoeft, RR and Glauert, J. and Kirkham, C. and Noyce, B. and Thomas, R.}, + journal = {Manual M-146, Rev}, + volume = 1 +} +@Article{Gelernter85Linda, + title = {{Generative communication in Linda}}, + author = {Gelernter, D.}, + journal = {ACM Transactions on Programming Languages and Systems (TOPLAS)}, + volume = 7, + number = 1, + pages = {80--112}, + year = 1985 +} +@Article{Lin94ZPL, + title = {{ZPL: An array sublanguage}}, + author = {Lin, C. and Snyder, L.}, + journal = {Lecture Notes in Computer Science}, + volume = 768, + pages = {96--114}, + year = 1994 +} +@Article{baecker97, + author = {Ron Baecker and Chris DiGiano and Aaron Marcus}, + title = {Software visualization for debugging}, + journal = {Communications of the ACM}, + volume = 40, + number = 4, + year = 1997, + issn = {0001-0782}, + pages = {44--54}, + publisher = {ACM Press} +} +@Article{ball96, + author = {T. A. Ball and S. G. Eick}, + title = {Software Visualization in the Large}, + journal = {IEEE Computer}, + volume = 29, + number = 4, + year = 1996, + month = {apr}, + pages = {33--43} +} +@Book{berry89, + title = {{The chemical abstract machine}}, + author = {Berry, G. and Boudol, G.}, + year = 1989, + publisher = {ACM Press} +} +@Article{blumofe95, + author = {Robert D. Blumofe and Christopher F. Joerg and Bradley C. Kuszmaul and Charles E. Leiserson and Keith H. Randall and Yuli Zhou}, + title = {Cilk: an efficient multithreaded runtime system}, + journal = {SIGPLAN Not.}, + volume = 30, + number = 8, + year = 1995, + pages = {207--216} +} +@Article{burch90, + title = {{Symbolic model checking: 10^{20} states and beyond}}, + author = {Burch, JR and Clarke, EM and McMillan, KL and Dill, DL and Hwang, LJ}, + journal = {Logic in Computer Science, 1990. LICS'90, Proceedings}, + pages = {428--439}, + year = 1990 +} +@Article{chamberlain98, + author = {B. Chamberlain and S. Choi and E. Lewis and C. Lin and L. Snyder and W. Weathersby}, + title = {ZPL's WYSIWYG Performance Model}, + journal = {hips}, + volume = 00, + year = 1998, + isbn = {0-8186-8412-7}, + pages = 50 +} +@Article{church41, + author = {A. Church}, + title = {The Calculi of Lambda-Conversion}, + journal = {Annals of Mathematics Studies}, + number = 6, + year = 1941, + publisher = {Princeton University} +} +@Misc{CodeTimeSite, + author = {Sean Halle}, + key = {CodeTime}, + title = {Homepage for The CodeTime Parallel Software Platform}, + note = {{\ttfamily http://codetime.sourceforge.net}} +} +@Misc{CodeTimePlatform, + author = {Sean Halle}, + key = {CodeTime}, + title = {The CodeTime Parallel Software Platform}, + note = {{\ttfamily http://codetime.sourceforge.net/content/CodeTime\_Platform.pdf}} +} +@Misc{CodeTimeVS, + author = {Sean Halle}, + key = {CodeTime}, + title = {The Specification of the CodeTime Platform's Virtual Server}, + note = {{\ttfamily http://codetime.sourceforge.net/content/CodeTime\_Virtual\_Server.pdf}} +} +@Misc{CodeTimeOS, + author = {Sean Halle}, + key = {CodeTime}, + title = {A Hardware Independent OS}, + note = {{\ttfamily http://codetime.sourceforge.net/content/CodeTime\_OS.pdf}} +} +@Misc{CodeTimeSem, + author = {Sean Halle}, + key = {CodeTime}, + title = {The Big-Step Operational Semantics of the CodeTime Computational Model}, + note = {{\ttfamily http://codetime.sourceforge.net/content/CodeTime\_Semantics.pdf}} +} +@Misc{CodeTimeTh, + author = {Sean Halle}, + key = {CodeTime}, + title = {A Mental Framework for Use in Creating Hardware-Independent Parallel Languages}, + note = {{\ttfamily http://codetime.sourceforge.net/content/CodeTiime\_Theoretical\_Framework.pdf}} +} +@Misc{CodeTimeTh1, + author = {Sean Halle}, + key = {CodeTime}, + title = {The CodeTime Parallel Software Platform}, + note = {{\ttfamily http://codetime.sourceforge.net}} +} +@Misc{CodeTimeTh2, + author = {Sean Halle}, + key = {CodeTime}, + title = {The CodeTime Parallel Software Platform}, + note = {{\ttfamily http://codetime.sourceforge.net}} +} +@Misc{CodeTimeRT, + author = {Sean Halle}, + key = {CodeTime}, + title = {The CodeTime Parallel Software Platform}, + note = {{\ttfamily http://codetime.sourceforge.net}} +} +@Misc{CodeTimeWebSite, + author = {Sean Halle}, + key = {CodeTime}, + title = {The CodeTime Parallel Software Platform}, + note = {{\ttfamily http://codetime.sourceforge.net}} +} +@Misc{CodeTimeBaCTiL, + author = {Sean Halle}, + key = {CodeTime}, + title = {The Base CodeTime Language}, + note = {{\ttfamily http://codetime.sourceforge.net/content/CodeTime\_BaCTiL.pdf}} +} +@Misc{CodeTimeCert, + author = {Sean Halle}, + key = {CodeTime}, + title = {The CodeTime Certification Strategy}, + note = {{\ttfamily http://codetime.sourceforge.net/content/CodeTime\_Certification.pdf}} +} +@InProceedings{ducournau94, + author = {R. Ducournau and M. Habib and M. Huchard and M. L. Mugnier}, + title = {Proposal for a monotonic multiple inheritance linearization}, + booktitle = {OOPSLA '94: Proceedings of the ninth annual conference on Object-oriented programming systems, language, and applications}, + year = 1994, + pages = {164--175}, + publisher = {ACM Press} +} +@Article{emerson91, + title = {{Tree automata, mu-calculus and determinacy}}, + author = {Emerson, EA and Jutla, CS}, + journal = {Proceedings of the 32nd Symposium on Foundations of Computer Science}, + pages = {368--377}, + year = 1991 +} +@Article{fortune78, + title = {{Parallelism in random access machines}}, + author = {Fortune, S. and Wyllie, J.}, + journal = {STOC '78: Proceedings of the tenth annual ACM symposium on Theory of computing}, + pages = {114--118}, + year = 1978, + publisher = {ACM Press New York, NY, USA} +} +@Book{goldberg83, + title = {{Smalltalk-80: the language and its implementation}}, + author = {Goldberg, A. and Robson, D.}, + year = 1983, + publisher = {Addison-Wesley} +} +@InProceedings{goldschlager78, + author = {Leslie M. Goldschlager}, + title = {A unified approach to models of synchronous parallel machines}, + booktitle = {STOC '78: Proceedings of the tenth annual ACM symposium on Theory of computing}, + year = 1978, + pages = {89--94}, + location = {San Diego, California, United States}, + doi = {http://doi.acm.org/10.1145/800133.804336}, + publisher = {ACM Press} +} +@Book{gosling96, + author = {J. Gosling and B. Joy and G. Steele and G. Bracha}, + title = {The Java Language Specification}, + publisher = {Addison-Wesley}, + year = 1996 +} +@Article{hasselbring00, + author = {Wilhelm Hasselbring}, + title = {Programming languages and systems for prototyping concurrent applications}, + journal = {ACM Comput. Surv.}, + volume = 32, + number = 1, + year = 2000, + issn = {0360-0300}, + pages = {43--79}, + doi = {http://doi.acm.org/10.1145/349194.349199}, + publisher = {ACM Press}, + address = {New York, NY, USA} +} +@Article{hoare78, + author = {C. A. R. Hoare}, + title = {Communicating Sequential Processes}, + journal = {Communications of the ACM}, + year = 1978, + volume = 21, + number = 8, + pages = {666-677} +} +@Article{huth, + title = {{A Unifying Framework for Model Checking Labeled Kripke Structures, Modal Transition Systems, and Interval Transition Systems}}, + author = {Huth, M.}, + journal = {Proceedings of the 19th International Conference on the Foundations of Software Technology \& Theoretical Computer Science, Lecture Notes in Computer Science}, + pages = {369--380}, + publisher = {Springer-Verlag} +} +@Article{johnston04, + author = {Wesley M. Johnston and J. R. Paul Hanna and Richard J. Millar}, + title = {Advances in dataflow programming languages}, + journal = {ACM Comput. Surv.}, + volume = 36, + number = 1, + year = 2004, + issn = {0360-0300}, + pages = {1--34}, + doi = {http://doi.acm.org/10.1145/1013208.1013209}, + publisher = {ACM Press}, + address = {New York, NY, USA} +} +@Book{koelbel93, + author = {C. H. Koelbel and D. Loveman and R. Schreiber and G. Steele Jr}, + title = {High Performance Fortran Handbook}, + year = 1993, + publisher = {MIT Press} +} +@Article{kozen83, + title = {{Results on the Propositional mu-Calculus}}, + author = {Kozen, D.}, + journal = {TCS}, + volume = 27, + pages = {333--354}, + year = 1983 +} +@Article{kripke63, + title = {{Semantical analysis of modal logic}}, + author = {Kripke, S.}, + journal = {Zeitschrift fur Mathematische Logik und Grundlagen der Mathematik}, + volume = 9, + pages = {67--96}, + year = 1963 +} +@Book{mcGraw85, + author = {J McGraw and S. Skedzielewski and S. Allan and R Odefoeft}, + title = {SISAL: Streams and Iteration in a Single-Assignment Language: Reference Manual Version 1.2}, + note = {Manual M-146 Rev. 1}, + publisher = {Lawrence Livermore National Laboratory}, + year = 1985 +} +@Book{milner80, + title = {{A Calculus of Communicating Systems, volume 92 of Lecture Notes in Computer Science}}, + author = {Milner, R.}, + year = 1980, + publisher = {Springer-Verlag} +} +@Article{milner92, + title = {{A calculus of mobile processes, parts I and II}}, + author = {Milner, R. and Parrow, J. and Walker, D.}, + journal = {Information and Computation}, + volume = 100, + number = 1, + pages = {1--40 and 41--77}, + year = 1992, + publisher = {Academic Press} +} +@Book{milner99, + author = {Robin Milner}, + title = {Communicating and Mobile Systems: The pi-Calculus}, + publisher = {Cambridge University Press}, + year = 1999 +} +@Book{MPIForum94, + author = {M. P. I. Forum}, + title = {MPI: A Message-Passing Interface Standard}, + year = 1994 +} +@Article{petri62, + title = {{Fundamentals of a theory of asynchronous information flow}}, + author = {Petri, C.A.}, + journal = {Proc. IFIP Congress}, + volume = 62, + pages = {386--390}, + year = 1962 +} +@Book{pierce02, + title = {Types and Programming Languages}, + author = {Pierce, B. C.}, + year = 2002, + publisher = {MIT Press} +} +@Article{price, + author = {B. A. Price and R. M. Baecker and L. S. Small}, + title = {A Principled Taxonomy of Software Visualization}, + journal = {Journal of Visual Languages and Computing}, + volume = 4, + number = 3, + pages = {211--266} +} +@Misc{pythonWebSite, + key = {Python}, + title = {The Python Software Foundation Mission Statement}, + note = {{\ttfamily http://www.python.org/psf/mission.html}} +} +@Unpublished{reed03, + editor = {Daniel A. Reed}, + title = {Workshop on The Roadmap for the Revitalization of High-End Computing}, + day = {16--18}, + month = {jun}, + year = 2003, + note = {Available at {\ttfamily http://www.cra.org/reports/supercomputing.web.pdf}} +} +@Article{reeves84, + author = {A. P. Reeves}, + title = {Parallel Pascal -- An Extended Pascal for Parallel Computers}, + journal = {Journal of Parallel and Distributed Computing}, + volume = 1, + number = {}, + year = 1984, + month = {aug}, + pages = {64--80} +} +@Article{skillicorn98, + author = {David B. Skillicorn and Domenico Talia}, + title = {Models and languages for parallel computation}, + journal = {ACM Comput. Surv.}, + volume = 30, + number = 2, + year = 1998, + issn = {0360-0300}, + pages = {123--169}, + doi = {http://doi.acm.org/10.1145/280277.280278}, + publisher = {ACM Press}, + address = {New York, NY, USA} +} +@Article{stefik86, + title = {Object Oriented Programming: Themes and Variations}, + author = {Stefik, M. and Bobrow, D. G.}, + journal = {The AI Magazine}, + volume = 6, + number = 4, + year = 1986 +} +@Book{stirling92, + title = {{Modal and Temporal Logics}}, + author = {Stirling, C.}, + year = 1992, + publisher = {University of Edinburgh, Department of Computer Science} +} +@Misc{TitaniumWebSite, + author = {Paul Hilfinger and et. al.}, + title = {The Titanium Project Home Page}, + note = {{\ttfamily http://www.cs.berkeley.edu/projects/titanium}} +} +@Misc{turing38, + author = {A. Turing}, + note = {http://www.turingarchive.org/intro/, and http://www.turing.org.uk/sources/biblio4.html, and http://web.comlab.ox.ac.uk/oucl/research/areas/ieg/e-library/sources/tp2-ie.pdf}, + year = 1938 +} +@Book{vonNeumann45, + title = {First Draft of a Report on the EDVAC}, + author = {J. von Neumann}, + year = 1945, + publisher = {United States Army Ordnance Department} +} +@Book{winskel93, + title = {{The Formal Semantics of Programming Languages}}, + author = {Winskel, G.}, + year = 1993, + publisher = {MIT Press} +} diff -r 9b9a2497757d -r eb146c5c05a8 CVs/13_Jy__ERCIM_CV/publication_list.pdf Binary file CVs/13_Jy__ERCIM_CV/publication_list.pdf has changed diff -r 9b9a2497757d -r eb146c5c05a8 CVs/13_Jy__ERCIM_CV/publication_list.tex --- /dev/null Thu Jan 01 00:00:00 1970 +0000 +++ b/CVs/13_Jy__ERCIM_CV/publication_list.tex Sat Aug 03 19:24:22 2013 -0700 @@ -0,0 +1,91 @@ +%&latex +%% Derived from: `cvctan.tex' + +\documentclass[a4paper]{article} + +\usepackage{tabularx} + +%\usepackage{doublespace} +%\setstretch{1.1} + +%\usepackage{ae} +\usepackage[T1]{fontenc} +\usepackage{CV} + + +\oddsidemargin 0in +\evensidemargin 0in +\textwidth\paperwidth +\advance \textwidth by -2in +\topmargin 0in +\textheight\paperheight +\advance\textheight -2in +\headheight 0pt +\headsep 0pt +\footskip 0pt + + +%%%%%%%%%%%%%%%%%%%%%% +\begin{document} + +\pagestyle{empty} +\bibliographystyle{plain} +%Ueberschrift +\begin{center} +\huge{\textsc{Publication List}} +\vspace{\baselineskip} + +\Large{\textsc{Sean Halle}} +\end{center} +%\vspace{1.5\baselineskip} + + +\section{Overview} Sean has produced a large body of work, however due to a number of factors has only recently begun concentrating on publishing in major conferences and journals. As such, most of the publications in the list are technical reports, or papers downloadable from development websites. + + +\cite{BLISHome, +HotPar10_w_BLIS, +HotPar11_w_Stack, +PStackHome, +VMS_LCPC_11, +VMSHome, +WorkTableHome, +BaCTiLTechRep, +CIPTechRep, +CTOSTechRep, +CTPlatformTechRep, +CTRTTechRep, +DKUTechRep_09, +EQNLangTechRep, +GainFromChaos_Halle_92, +MentalFrameworkTechRep_06, +Halle_GainFromChaos_pub, +Halle_Secure_pub, +Halle_SpreadSpect_pub} + +\bibliography{bib_for_papers_apr_2012} + + + +\end{document} + + + + + +%Tabellen +\begin{table}[htbp] \centering% +\begin{tabular}{lll}\hline\hline +1 & 2 & 3 \\ \hline +1 & \multicolumn{2}{c}{2} \\ +\hline +\end{tabular} +\caption{Titel\label{Tabelle: Label}} +\end{table} + + + + + + +

]JgoI^08j5l/F`JT + !TSSDbfRIuCXB3_`%aXQjOY<&q&^-tHXF#!-^2BV?Q\>ihb`!eZec735eXiQPPBJcXSR>iM + qT8l.N\mi@%OLc1[^nW1kqdj56LV.fA$1XK2m?l/Q+Ht[43*VkTLUp;,A_>5K"T0TN[Frp& + XFP2K.fAIP]Z*VmGn7;o^XU?hK4.C$BVDBD^o(\/!j?lJ-E7[W/SA5"s^?SpPQ6_XH9K2nlhP/:IH7pL4"$BZfPnW:$=G&VaAGl,"0TW0:.P-=\$7Hb!:mr/%`%)8PO&Lpljj@QO$JA[ + ^o3/^^o0g]M%!=AMQE)GLn__+;&kgd6aJ12!.mN/,7If2]IQ7`b_&-UCW:Hu7]Y=c>a1BS/ + EksW'CY(,;`]L/7(uELGAAN8[. + a+9SCK+oZUgPbf$-qe)`YYVb/X87^/6WMiNb;oJ% + Vbp:@KK[!4"c:Se+^&6's9ZXQX<(,539lR)?m,?2OJkgiSc,,^c1\a/PX\R+-:>'YXn:El% + n>YGTa,G\YL9;K?$n0#ROe;u3/f`+MbN + OPVPTC>B1Ig/5cg:DD/G`*ua$'%7a;kd&m&Z)lE0c+H8p]sC`?N1H?3n0//ut=:>ong3_6i + gm:\;%XN8i*WJ'DM;;Rs1>bpbi(d8,Gr1aOZt<8Gaeo>F7+-.6);@iW]T&Bmi!O]*T"bi)J + cafSd0NZ>J9,YClB5L*B5;lh*;r;*^'eVIKm;oKa*\JCG*_F`fb`e?m=gha1k'i]<*4sBkQ + D+H^Y)cWWi:6c`R]g=>fpr=[M<7IWlbs&Ne1JE=NeNFpO'gmp[4]IR^::'H8`@'47?rdQDc + Y.obW)!QfooJJ0cRia)4ElEspR_`[eg1>q/;-rm)q)Z7]/r-P=I-T>r)0(\;[gFj'k%R"ag + Z&4NuXB\V$7?6G)ne2O%jnVIqsSULE\M^5+PZ + lWc_F/.oso^LkR]@Z.p3K2bZ%u535GRMZORK^&O&Rua=#G"t$anF55ZZDi + 9p;V]Ccjh^SQTN$c]htp/W#X=U;<<+X`F]d.Vi6Fg!c4mgDuP_4dT5#[FDiKWBIW@A7sW?q + 9n'Lg@_p$rE^$lFBGBY>[>HLpca)h=9.ro.K$_!ZV)5HFgY)Cc)&jN_$QU2%D?f$A#&n3_QtHY3 + C(mR4$>?l-1+G##k)&c0i&.>fj+P\%92R4]?KLJY?4i2s'%Di>>HLra!4h&JT\^YuaA*]^" + s$VW=pbHVM;-b4eNg7r`Xn@m0*q1l@p"e%*>2j5BOfi+M@M8<28bKG`8: + J^A6c6AeF4#($jtJW&1m>^D9*6Gn\:?'-ImM"4p$N)Fogf0$7bX/emQ9I,mu%iuS + -9&Z:$N29e`BN?^`Af7IPfpNctBD1B@XWJ5kr0=0b2A4"A5s)cNGSP"Nfs]CPTt:m85>>N#aX + `^92/6736@$<(kc!'KB(uL/fp@8p6c=HdqW9UlBR\[@'c+`VWNS)idQ65Sr]$%OGJJ9>Ac= + `\7=CP^WCZ5 + laET\XqXtrSqH1H$jOL_>Y+0o^hKB;&dC^aN^W$le87kFgsolb3B3h>Yph7D4uQ]tMuP$GO:]K^''leaGKhhqmFM[MQFZa)2BQ#>!8,L9ZU_O5:>*s-)@-uJaMmIl+i[2.o5(Lf:NnAc(%ena"E:YOt + BE7Sa8#eBHes7#Gh$8.-5AN#r>2qf+0BYKFe[Z0M86.5QG$Z%%n"]mJL=:.uinTM2Iei9Is + q$6o<1AosJR-ScY;fYp;.&AH$3>(i/=ZZ^E@cfM\NoNhu-_HGJo00]geJ(tS:htgIl\P:U& + Jt!bV&R4,F($-Eh\AlNF`R!aEsFF>O!]^=1<%hlnCG>_!o]E!JM).+'o+nf]N+SpT1.X'$G + Sn6"T3?'HO2VfT0F`b7acffe*t+PF]suG@"[OM"_>]<.H0Y*B_B,cnAjX!mG229%?sgm.o3 + =NF*iehLF.,Q[jP0n$Y[B>q9a9_E"]p*+]+?r.N!@hTQ]gWGElOF#_mL>P?];3fMf99^l-`k;\9"e-$[83a(Go5/.,E8_5j[, + (k9M5_Mp>0h)3Rio?_6Pf^.OLpnqih-'&I5T1WO*\h=7&e0p4)N5G'k#AC5P:35Z-I&!E*G + je#ha'Vu:T3q9TFo3?AUgJ>dBkPG><<[kl(6N*<>5A@[n%b4Wf)Y*uk&FLonZ=]C/dLq'N+ + ge&'r]Rh3oQ3ejC<[/E7WE[9,*7].LM=kF>7fl&>aJrcjMh4BLbOr+GY:=&8W]cl/$k"GI! + XQ&:6ksHW(W(W5X,]^&pmAH1mC,caAW2WJNp"M@[d]B?@_l[gG@0BOA:UcajB0b5B!_Lc;L + -`(8Mc[W?VSO(Zo=[)mXpU[PD/I)o$0fXC_A?G+m'F)Qqm0>r2sU\dj-HnVc$#`AtdM2@9k + kEr2rC>+*Vc]"LIqo?[(O0Lh"K`4M+Ef],$+6nO2iK)ApBc8;,NR'Jb#'p!#'(r)4I + .n9Ur;$daj+_d9EVJAea6A12UO,=^ZC!"PV78JQhH,qh<&OF1*Tg9&Q^G.s\hbYF#.[#5a% + g@*n7n4O4C_\j8%6HsR1*KZRPb9iVnR+-Xu]Ee.K0Am^b2kqTbt7]'s/SCfGoAaM9^2PhKC + 27#^*@BurMGBSuO!i2aE=Z3o678mtRFRsXFSkXj+l'^;5r-jE5G9FqjFGRkaB.A`$Yq[k,Th\N^bT26/\'2$6#S"-n6._)S2s8Gb< + $uoRO*c8UOXkWU_fXlR$VQG+Qh^KP'!e0q;:@W3LG3(nECOW34/IS=5s!&aBZ?[V:,c-;2J + /_(I!&4RhOQW`4_Q/b=lqIo&Z&#st8K4V:(YZk<5'(8?ndQ%;@8:(tTG]eN40<8BQ0e("=^ + :t/Jc8Q+'g4],2/,@-cW_X;XOiUoI$(;btf + LXPdBA)u-4I@21;:TA)p=5pTgX_(0:V0[JS0lJEH[b%hDJdJ%:J2D[Y/TTEEBG*0/G;8%o` + Y>_?`C1-E8XA,\9FEoiFji"XSXAu$\f85@4'5T<*UC(`YXT;=E19^RYeI)N&0,8#EE<9L+' + @h3#tt$A]`5&=Y96?_(W.b&#JbugTPC:=nAt:>614q-?1rqY&!p#[S;ru*jHGmR[qKIU)W-cY[$FR + !9gE;)I%(U;Ll$MQ]l6]UD(p>p+AICk&1eecP;:L:G8 + lFEiC"i::^N&''?/KqapYGk#i:p:%AQi=2[;k1$?=0,_TU'ob>7,tV1[,7<.V=AM[cb/YqT + 0nVR@r^ZXmXr:=3KXVIWEVU.GC8+l))`J(7B4^1nJOUL_okE-T"3&o,S4*%ZX&V!4)0jBPs + f1F@q;))U>g$q_tO,Y6.QV50>Qfo(Yd8A643aEgdIWqJ%1fqO\/R[t2j#!8dBR(2^+D,)!m + L$Ip4`YR]nO'sq3m?j<7pr(b1&d3'ieIk?[["+6c?S$$P^_A]''o4C./1h&#_ka#.>l!'7/ + r5r\dt$[Sd;OmmOfFSsnD>J>09:e+73.S3!E8VP3R>D:"P@Q9$-ZD5VQ&&n7ohhZgoXFG&O + nhS,.HBmG*^S5>YCK-0'20-QdYk@9BV2=e[i;Y1EL(#P%sUsM'![/8SSoOMYl1g3Y8uT7`N_m7$\;_;0eT^@`oLHQja?NnotK&7r*Prd + IdcB#Y#I7:f7Iibf.Hs:fH16(S/$YFAT;^iB(Fm7c#9`g_&o!R=^MDHKWsSZ_q9GM@N7gmn + KmtI0HCso_f1Ro0`R_u9WjmJ98rD<29+;+*&W+>;X2Of]63uC==`%iXt>JT2D6._S<]9.Ak + gD#5:C(]pQ&nh>&o`%.:o$WQLa0D^Nf1Zj\3@)1'36J\IRV*l]#AWM;ESH3=][&)k=73ER* + 7`46Kl=T#T1J771XN!;mo@j$[T%%A^>_mMb+jn..7p3AdV(dWua + W%^FT0#?b3Yg)j,UN:o(rR$0sA^JsKH.A'$uJ'^7"=R)FlUCR9`dMh:KCQ0j@oZirY>9>rl + *Cb8G.+$Wd#?:!5>`*ZYd+[4^>&.sYYVprNf6TAGmG5=DoX:,KqJ/iD4g2(Jb<*aKjsPY_G-7%^3T!!g^!!*k6c%OT3o'.o5EU3IKAO2SI.1HI + "aBqpk5=>=bYoj_M_5D<.Hm\2rcckTUV#H37re$hS&9V<1#"ft8GZ[MMtm;=jF4jhjW3fkrK"mm^/;lFT-KisT* + s@;+4p@[)s_t1jn=g,_Z!mUn+g>.qA0+m2,DNpY(HK0]^5+^m;E^<%cIC@&H7`BqiC14:Pq + 7FNr`h%s3G6Y&2ODb2Zo.'"4078&43eNBYA>#]qS[N$<.\S3!56\47DP:_D;6\^B0K>r(o" + '&-3!S\H$-O!3ds=Dr0m-is%0Bl)u5p0Quc$Ain@T#d6"/0*#$lT)C:b!0LD1p.+!L4;60'(aKbb8W'p1 + -_,Z>@rR2V3E'_,'i0io7?[i)H_(.5nRZ)\hKR2;!6(_O:u;0<`'ORNjI*APqYOeEFWYoWA + T)UVCs9fF,u`>e>\ZOu.;dK6b;b1EnJ+*%Ar&_@mTQQZt\(%LB(;<]7OlPf4ZB-rdW-IQf[&p#EuG:/Q"/b2Zrl + N5%&5O^;QRS)e.FOh<&u-pSV^dk1.`r\Y%r3IhPq(e7%l1jH+b_IF].B,g/C + Mir'%8F1f.E0?/^Y:FdY.hME@p/W:nTm'!ce^Tp6Pf(0@KkRm6oWJlS+M10[gOe',**!(GV + *m0p:O]dcVp?%$MlS!Ac?/@H*PEGrfQ7W)t3R`gG';ITeV`L$B3n(8o + '=)nd/*q50bR[bC$OX>;3jP5 + JsdJ8!rBP#=+/G)&)I)'GEc3(I=9)6.?uC$X5]U;)OI\0VQZW"2k1LZ3Bk^68Unp'LP8f7m + rS77+=uBdu?+]$5$6@C2)IJ@*M/?B1??&Ho+\j'QZcDG=RmE8(<#J:+RJdLIdWB/`9c'#,V + keQ?cDl*g8T2'S/kUVb32S9%:%;'XK%,r3/#783Hh+a-g9sfa + M<9$_Qk>%9-:=S`.$meGD]H9cK5Ea\k@,c[O!$PccGUikM'b`9#o21bl;:Qad'dHUV-CH\j + .rsl*lN9i=02Q&[;oaKt6E)cK.9)R*<7OcE'iS+4<^ft7iq/3^'amiIEWHni*VF;od>f;)D + c`-D1Kf\'sh*:OK\>B&iH(,dk + `c;'3YHZ#Be=9dka-ef0+\+>?0Qe(#rV#k?aG>-<4<9FT3nhlk=Na.=_M.!P)T.G=g9j@+5 + Wlee;Im(L`UK@FcLB'eNcja9U9G.=`RO!1.1\qdY0jA&0U)!=r^+pLJf.ACHhF@[U_VqdL= + FA_(4#(1UrWB+Ro\8@2GLTtb5@!!".*B?"CX!XCN]Qq&>'*nH>bp6#W'Q39+8>QtFHiU'+# + Vaf6OC=]S((:.dW[qh29:j%pCPkZ>#@4K,T'hoIqJmCjsVacuH-)DG,DM[\XCK)LG<-Gll( + @uHFpMZApDo98#e;%k*K2$ID:"8-?pChOJ(NGc\ERnQ-<%TgjVfJ(45a7dhoat%W!n:9nF4 + WWu(IN:G7oD8j-$'i.e^lr_14])`.(8SdQXb2?B6KVWG171Iet5rbF]XcF=4_A8(P?s6LNo + /D0Xl+%'+6prcZc^4='(B-(Sc:XVg=]18%4U9Es`b.[qLR.>ut#h(#+&da*a5sI+Q\m%N`K + M;dseUW\O(k[WHLPV=QLK>jD\*OBe0R]9FIPhpt\>+p`Vi$kBI+XK72cG)(,B + ]AY4VXSGfWC*7a,HD/N7Sl('o@.$RM.W0N;2:j(upWYk?D';0_^onJMRqDH]FKjO4aJo)$> + Flm4d0B/K!8f2ns_V`K44AOkCh>)'_QE9/8@XHSYtVpZ!pSI\W7o3B36/Qgp5A8!KE7PhAh + n=Xc\H:GGrZLS>+h*hIgR=I5MrM@'3L?4<\!retS'P5V2TKGFMhdZ/L\\]U):P-Zf:@kKOHU&mJZ"_=7 + X:AlF*OCL\auFrpRdlM^:!K8fia4YnV^d!*-r-a_;U=jrLoZ!U"UT_$Y*D+o3:sQ=;]Y8\I + kPs2kug'UY7niqBqp^)1_n$#F\C:J3B_t+/F%Sgg+ + hW`iE&[Pb)]L+&]:XkL6p>.R0,:TOVcVBJQ3(g\RNbZ.iEXWWp0H@?5gRB=7HXoT'978]Dg + WNQ*hRc:=pEX:(99`Z@\"B79?sZ?8W[5VK]IK'Po??E`H=<[09R9_O7n[77k4fFhZs9YJQ3t`Drj@qGg_0QhomGnmA);kX6WBZ6`AaicW* + a;o3k8ZXm(P_Ps;!42BiuZ)(7"6?0p):W+Gu`+;fM>;`Y?/$:ufYueFc]O"Rm@K7B[<81E\ + Rk@]GF2ZjW)Fl_l[IOI^jRgaNY<_o25ut\WSKe=*CI + $AdD?gP_HO4p3jm"t&]`ViesaM-h)lZ>4f,a9Wh"L@*Ik2CFg/IgYs"$]K$h`[8][E\<4lr + n*,\aRRG+0+6.Fj%FaZTO[VI,l]g``.B>h8N%34lsq:l*\4l + [J^5-IInmmpf(PPd8)kSRsE7_V9QWOc24S@SeNP83`MX].@qX>*;.K;q5#(`"h`V"4Q%i_2 + pQg\cF^X4qn,p7(aiT0dJ-5"[(_g8:-94o&Q[T>`CLa#LR<%('U[T!D@5=qZ:8hBc+a@9r**O1ShsR!olO5+Cg*J%^C&D4\<(D-Q>An5Xq2RX( + s\i_/Y8C/j'?Kmpr,^>@DSj6O.N<*p4$i+IrU0E=8%,hKn"JLIt;?a<)n85pn_!cpfH]k:\NIsq5%*c]1>q.I;PUTV'2$&(_)OOsB`+D-Huib + c343\_M37cTW`oR9(LO\"Pr=Yu^I.@!NeP1ark@540Dk*&rThJkQH:?Rhoo_sD-Thss;=u@ + @`8Yo>LPhL7DTi%dglBPP\?EmY8;`7NNWNM8`roR+ujL+d'lWnsNak?SRtnB(MGGp4#B%d:i0@>rJj9F9Xo`2ktS$q2mM"=_16e[d9!Yh-/5%bJ[k:=ZoY0\4cN@_1[ZV=X0JcU + @cR$i6SDQ0K1R.&`::%=r4ARc_pHDBZo`%0B;\Ag\9X(dlT:F?5O))T!"$FjkSA2j + /#Wd$D?UCu/mF)0PuoH,@ZI#I=&\0/qGmKOHi@(PZA.F<,M][rCkmijcDX6-uOcYr#qS>4[ + =iC['Qp9m>e%'B@bH=-dEt[SE@+a%9'q$+[AKRgGnAG>[K2mX763)0DQD*]0ZT5j:,7*^A70l58VB2I&V=26[*oBbg"DqSD,@7IqRs@97Dm#ct)sG:[!0W>M1:(O[c + Ec!9i>2GCZmJ"[KR7m?ajl@u;P!Lo;^-TX5Mej2qf`ACgYk;so4@L(QB.&jP2F@;Ja4G!K_ + A9Ubf(J<1bp6bD<"^Md9p<6_b.ea%s"[,qEP)E6V4lC7M?kCE&1FF_ + RknSs`Y:U*\+^L@F@.`8mENLud2,c5,BY_LS"a#n+!WQA,H=p*Z?EnE+s@D@NaRo;Q?O*<, + ]/P%L"+!2$I2j#`.l3r4NNZuLuT.XN04='2cfSgd48`SEUZ[mis-\EUg>:.at:Y'],ch:,T + AM8Z:S`;(>I4RBFFes"P.P:Uc`9:0n=L>nBiLlr4&%'DHTK^ec6sO4-Tjp3MKS97i@JLNMI + %S1J(\W)Y?d_mjsMlOg?OuKPZq"IQ4%#QFeBBE/sMo(6dF^2l5m!&!FSb9efF$9H0Ia6ukm + YH0bMV_$cH)Du`Jg:GQC=#GDhWY=$9.mZ/>Q-1M:jcBZ>L*/X9,k"1t#Zdu;CQHbiL: + flu7-1pnp;t:Gn-7pRAm](Q")P%paaU)MHk+,KR>tV-0MlC^TIb#uW=U6lU0X[^9f#%ciR? + ]XG%Z6deOt_^WlccEj,-+@/F^Sub6RJ)p;:nod>DOkMW)_!;5V`LMd4LA$PtFKq8jd6-oq* + V94fD3JAg]/f*'HpLH7id=eW&SGZkg[7.O[p^;(Grt':#)sW[L*oj^#=u+d9IK0[-$:!hMe + ML8^-kg-ZU^bhrb + ;g:VFr3C'(C6tp-qUQ\@^r>Ij48/MIkDKYB6[s<@Pg`78,QmBe+F=2ZO$QrHY-nMqFScF"G + lQ]0uP=N%F+_HcNluJ_4tWMj%55`me-O`"N)HnbWn4/ps?pH3rI-ilk=3SqF%j)Pi(W8J-Z + nl+P7:1A8X6O0bc$lW./:ZpM4Z!8GF.> + G>C/6=`M4bYLZq?LflDC@9Uq]3]2fmA*3pLpA1d<06Qj1e.2Q^Y'kc@;59CYrG;af_ZA9CJ + )"034B^M)>4?M<^EG4)3Wh@2@40ZHr[lEt>"6'JPNS?tR.KkPctC!?,J4D_o0Nh%N%XAF/`@?2Jd5D%kr.c'm"Y,dgX?H + ^:8!"DKQ^"jbdRON+H/_*f:l=]H*c@GGe[PrY2j"QTa'[CA"'_oXaW2D7$0X=#'T!Yg*Vf+ + kbPi0?D9s?Z0O4kGuLjW?G4-816:q;r + S55P7dCe7c]fONkQ#tTi'uW0G4:U/OgGSDdOtRBQTl18;r-.orVr_[X7qG`mtL9nfcbL*o9 + T5+&bl3Yd-^k#KmeEo6)bocQ&Od_7A&X,Ihuf0T;Tbl5O\3#q<5DON^)j72/l#A)INhlp,E + HI3-^0AlfGjEg-Cl/S,#@Dl]%MZDa;b#![I)jZ,`fQq&Gn35pR)#,-rgDbeW_"VsE(VF8%q + Y(bh$uLbom`ETjej\1H(B/=Z8;e/L]bVRB\J5[3mf3YJA)n0C[-M'O31$m,a;*/0UtUX4ZK + dtU1O(pNWW#m:77.rgLrNuj3/5'"_&lc]Va]Y7@RtVN6!H;83AFoP`*K`Ku8".aNT1PjB9SL\3IV[73emflF]6+HH*%BM#<6aClZDkL + ;W@n7\lJDFC)rqS]UMbaK0a21o$bsZc?M\4]p/79W,gFW61@(b+u&[[&_?fXNK%pb2fXSKW + fo*Yfd`c9)&Zam'Fl'[*)FVb@J')FLTGH\BC,IbG;_m[(FN"]Z\gh@1\])@=3*_u1Cge>ERg:jjM/+S4N1\-1@nJ/.bbJLdjH@T[TKen]6<"iE0V(o$Q-?S + B8X$j*g9SgoU!7D96Nd2,eCbrI1HEpAc.#GnF"08ibQpnoM,`$?b9=W"cj4II#rLd9lW?X+ + M25-\b!bO?Z&64m+,r6$:?6H@o^C*/nBVg=cQr)-2"T$]oZpM0cXcaqFSF+7ps53#c_UE`[ + /7C"M9J)I);>&,CB[N"E^(e[`;@tIBRrDh!Jrpe^dQFA'K]"@N)3'2WU"jo1nIOVRQdPPLh + $ZNeCk4?$&N3t,D=ak*=B#mcV;@e:k].1bl^['%+,')UFiI8@b?cr]1&"0]buZDOBAmoZ=(OH_;A8!7jo&N8NiG5,o9)M);'ni;/J\G72`^(I_=+L2[\tW*F7>cAQY_NTB0J8FgmZn_ + @(I_N@e]R-l1RR*/9`lR6@^2]0eD:7,*F3N+8BEBm8$Z:VXT>_c.>^/WU/\J#*lZ7h[M20p + t3:_H_fPaID"rrt\9uB=X;ma(ISOtfK"GKg7T#OT + $?C@4q8TnEFOP^M6hci(K>`gOFY9a6r28u!;/Ip;gL7+n*N",3LgIp@,01/J!:^O?\ZZDPZ + oSG`t2b!\TII8%3ml5aRU>=e6!u>&$oiWu(?;$nt:"k=abM4EVi?:8-bq';E]*p:(!GNO/- + 5X$K1H>3hhoN[QSeC"tY[D$pQNRl\j(ETQ52J)Xn#RjKNC?2%eL0SmiZ0k->W:+i,M0?!QU2qW@+ZCb- + 7*9@r5P+6ZVOW[EGdpZ(i@:?sbEn"Q;5%\b?_-9EoH2XZSHsgo8e + Vtp3o*XV2Cg`t&,=Up!`fL\OMKSdMDTNV&Oc1n6CrXcO(;1=VLME(@lE1le\\H1DG + t4aXD.BeYXi'HT4m]&sO3ZF99.F0>g(WVnD2-k`nSho#dH+EWj^uu(Z'!(g9];T#mU5;GI^ + ;m`k)]5j$5M#t.)KTYknCM^$m*]3f'eke.TS)/>HZt%%c\/']nVZ5mntEn"@h*Lmq6n(m\] + IehWO9lkjPbRDlB7t`K9QA4H##5n0\;,0'2R5"I/kq$YJsEV(Lu@(6QH-5mUbi!6D+me0su + )Dj]KPPhubgc/_G;.djHBA[:J/87IllRd?P$?MlV1rpWbGnW9=+qD+oHC2ojdn`LsM0&W1a + o'hC_E02)tHe4$l[uRp9N8reh9U:Lh?.shJSGB[8JA9T8!!phTADA-pdZug*I*h`rP-42B6#o)Q4"@-K1ORiu=oO + gYcG=V:V!V8nUM.pT+/SGnbHAZo)F)`.-G]I5R:W/"+`0SBh-ADuIj97\Nh/J@RmKF!%5me + jqBZi'q[Yh@Broo`2ch(qQmmZl0@.kCFp*X=0-V`JA^*<*r[urr!23Ka?cbl5r+o6fE,ZK_>X\G@u*nGB`e3a*'_9p0H0[8>Ps/,*B=8^uh_g + EE[=aY]IOG#g.H@mWBp0%LD?CRG*+bDCAW4IktJ%BU,@W"q;8aEoQO"j5(@,Zc2^6FBqL.U + CNmOLdl<,k5rFP]s(jU3]mVuOY,5fdmTus?D0aj&#i8"TKj%ipb4tsp2_7YQ^kDVEDgP6RHs`HhLS4K.aS_CHr27\ + o3mf,E'NS#-o]``"8e5cGJ\<#!6(9[74(\2>\;Ue?h^/Z!1GJ_.l5=Kp,!,hPSIqSKTGPD,PL)7>CmM@#\DpFKBj@>O>%[B$:!.[+<:\Z1N%0n5s5S + 1G8_Arl6+!OP&@id35N'Yoi\BGj2n6&:lZ.83,.1;6=Ui8mf;HF^"b@I[,C^JQ2BMN/;Bft + LN09=7enHk_oKc-2o-1b`n2MWiZJ1:%GAQBZT-I&Q0=HW/Y5)<0IQ)`VKWf4.,B+q7-Su6& + '^Z0%-D9h0c]O#MX]B/bbJ&#H2=?HtH%:VG/E1":M2][t#A9(g8VH5@9b[tp!]]OE$T?q7n + >!44!9rHKUF]uIj[p?2iCj'#GVUo[oghq=?^#o';J:DNFS2]=ANPg30H!D0Zs!Bkl91?NXG + ?5!slr^k/0"$tbh['")?7'l_*H7pqR.Acl[c9f?qP"\TbdQ?(RnIP&s$^hNX.^pkY_FRi_q + J&)!br(;,YW"EPJ:j!U5uNSlJf]$.nY9'5**"LYc9B,pn'pl@QOOeX&>Pt+R&ZM'IbO7],A + VNW]LVD$rh'aa-#_:+35''Kd"O#/<(mr&knQ:ac^J2-d!'\V('QMXJk5&Y!\0.\8oKT.j48 + 1Gj.8Q"*St7"l.Wcc#Z26,::8QjZ1Uuo^)1L.\'n$6P-j>[_q=W2[qW!@PL57PQX[35j2V' + 8#*:,(B^^oRMQ77oKiho^IXS>4KfH6:;>0!'$.jd8>IYc,O&sI\?&\iA;3;>2/QQin\V$=N + toW^?e?,'KjiW"/WF8n(/:'*fp6KGBA+,\V&m11`3h1hDFD.qf+Sk>(>?.t$$:?u-FW+=U,7o/M!lM!#:Oo1#U'jgEb:W'`?PguCI\9bW(9AiujnP + 2!3-I0,`!T-RKHZ__#l#U.U]HTohZWG!&&W8`Xc@Buq\h[N(R#X0lSjkN,JK(%p#n\Xc$;PLLo2*Re[Z$^:^Q + uef/7FCau029pg*D]\copp#,fCfJ.M_)B(`fbeoqI?:u9YHMWngNnkl"]+mE- + kh+jtM\[>_KdlVE9 + H/ndqi$u>\^O3*;DU]Nk&ZO&@FOG5th_Y_qa3(2k2I5(cN:!JjtdMp[P?7TdnQj$[U@;6DfHf\ILjlksuK+YLU]] + 'dY7:P)0jD^S*S*tg:%O@c`E-KgR'8UCneAPM28;@:PN3WWa\mm.M0rHic6asYdP@^>EKQLiiE!2HWoYDRE+i+!!(JD[0BNDRQr=K(9Nd?0k![ + =Z7e(7a3&\5'o!W8;jkdfCX#83Cfp^r$ihu@1nfkHO,8-sW+O[^uJ-9(!Z]KmHVt2F4ba4- + K+H4KE9+d""H9m4_Q-0GDoB-e[SqZk89/6q18>M991W[R3ip'#MI.3P>:0pTY-Um7<)5C/K + N`"Ln8*L1#AS3b-**7%GAs@N`Om8&J'\k$LKe]GV>]uM!9)"3hWI-;k+2[(Q9&Gde0G8P5O + kJDPaNZX`,^"\o(Bd@nYr.>JN[+T0-W(t"6`B?6L_FHq5_'#"I0s,/PiD3]@OS.9ocV7NKa + C.\%4t^^Km7HY2At!hEC;Au/<+c8#46)?;SiO5iCID7)CndUo_[QI471(0]2 + 2rD6-3,Oo@k5^E8&NL&.S-r.T9A,e:@(#F*&\S@A5`oN,p)%5gn:a+cPVf(*J.NU!6!/4nJ + BdLFJ'(_^*u8:j?/EanjZ3m=YD+4gmreqSbC2nlMO?qoh($G/:n2>670e_O].3f:9!$jU@P + =a8tF*fZ?:DbHAZ#>D6])=7X?rji7[o3Q'LN[n:L#XH0clf@sMJDJe4BBPNHtY + .K1(DHkYrh6i!6).-t:S,3;+r827g(7I?4[dc:7q;4q&D\CbU^A%p6i*6e%DA"D5pa6C,;\ + e!<,E]9>qVQm#"+)oF]THrC-bqhtNc1Jpa*@n5jBR_,n7W?Bq'RWQ:fE+UDBB*75$$YsLQ: + a"TKAi;/*C+!O7U)6ch[l4J_qOHEf4i.bL?hMLmrrU#)]pjO@iNN//o0E + iQhk?']tF*EG$`GHqaYAf?*A\EM!<,EP#gju""d5]Z%5[\#=uJFQLpd%hrtAVn/`+WG[Cp= + r'uV&LBbS2NR`K(SlkEM^Ob&'+&(D'MXsag_0NdYkPYXZoNmU,1X6DYqd;NLYEJVK2m2K7^l\E5=U:/moRGI\r%J!K0Eh + Gq#lq1!peeF&2=9+3 + _0NA9EYl66.no,k*DDHJ*YXiX[ih4NQ&46\;k23;Z][1p00SKdOM$U>EJZbOHO4`9K,_@W6 + #7tuJDlj4r\Hq]+9Fs&gn?iXC\I5XT$fu@2B]f\?,6dPui,C)tmA14&fLW6Q%C"e$0]`d`k + mjIc!@ge5mUY`]jSFZHbV$4$KS]W/])M3d&EA*HnIZ@Q)%j+o&b-tcmi("7i:7HT%++p'/- + buZ,4@pV$=Xk@d3B?8;\;ku'_,$80i\s,cD6;f%l#RFA?,ba3qk9[pQ8Sp,`%D)XV/J$O[_%PmOB3Q]X[+n$Mt34W>! + W:W,"iDG_DDfc@?R*V&(k:Di3@MZHR_)m3k+.0L^[]^+Y*8C-l=/BJqg#U$CK+L2S&1)1sQ + (jFB8%$<1^a<$#;DW_S_+gNdn&e?3B3?tgm,P"*&dN8usnJN`"*"ZjU:i>9sUEhRf,B@':1 + 1_eQBdTX.,]U@4%@D`DT-]LN'B?C6&lU.)FX@`X..WKL16j:u7jen/YqdT`0[a4Q/LcfZ.+ + 54J1:8WQ\LXDt(lo[b18,d<+V5($&4D9bM$kEoN#r)W*T;SZ^t]\jQ3hTr0%0&0!E6*^'$ + 'a#X#iNsP(#uS)4;:PnKo`J&WZnaKI'bqlj2'l-X3DX-5)'K+oP6i+[DcQ4).Bro@IFY3031]-BS%ufk2VCWc!(HS%6HH + [@M.!i<^C8>8S#8'n.L6[PfXV&m$:RP>f*]n8#HL.I3e5WW + +2.-Lg7VZKN(S3MYH8<_(bk8!^D'U?KUe.8'$in++5r\rH0mP\W9K*'$GP-H0q1#`+FMj45 + %oX5Z-;&JiJWZ8m<8JVh.^YpjPIJ5T`/f;@*[\uiD$As;KSb-Oj#d"uI\Uh,==&WF8VFTI8 + bWf4<[hUY-"[141s%h#!rZ=S$G^m^C2APYl$15t@S%CsITPc_eTB^!H%u*RM"m*h,`@@39. + +`OOD_a="&/u:)djrXs$2Ck(mHf.-nmtOIRW6Da_n/r9%;c"MaVcEpcXEm6[nG8Mg43@39? + 01D.p.Gju<]?=:Tn*0%q).2#+\CK4Buf!1arN-1#Tf7"L=r_1VN:A6B)!3@0i6-o:YcATa2 + 2806ZJj/cpsr>XXAp>#0.S- + ,Gk\J[Ih*K@UT6T=V"\YYa?WLBRSP3u[oG$,Io>_+f+GZLV)!X)Gpp + b?rq?]l6jXDk<$W5HXdC:3mc36YEGU9ik>SToB'(&`=8?GbaPW9]g(l-Z,VCRK7IRBB]#6PnH&lX%I9ShP?S>``/7q.G*URshbZ+pgST+aTI7l&d7n,74 + :Zb07lAi2WNVR%an`_&0cDl&<_<,l"AglED<9+f8`K#'gnQRLB4#&2q$eU)K`*3i-q#R9ji + ?Jla-kQR3V\*(C<([=S[o@d'`-*HOX#+*'VIH'0`&4=_?$;QV&bQeGkXhRUE&TRm*QC%/$S + pmi;L+pX'tg4tU>NZsA!8(sir[&/2I8H$0,`*%& + hkk?n4*%)UEZ>0)I>)mK!RIgS9f^NNFKMtb_&57EU'bLh![d^7I + E#NB;WLH\8D + ln?0/H+U.L^#BCWg#+JULiQX+PIj",HWlY=F0Q\EOhKQf8/mVg9onjZbg[*A][T2L=i'+g\/EK-4FPL;I@ijY,)V)HC!=m36:(sB0ErJN7!9 + Wfe/^j7:>K4q_;lR:_3+X[d+r\h@HH*K7G#5$f>/3S4`b.^&Y"!QJU'4G[Z^prc'27K5f"s + Th',Aa.AM700?TQgHm0[/MAn+!e"SU]>u/;g?-#)7H`EChS>V>CZuqiUfR;^eeA7.Cj'7"j + KmC3VL9Ut$_FU1t/6`%K.M,0-INH]toiDLe;8jke + Bd_hAPg5 + djFE[e\2:fA/B5@W\3^@oG23&u19.ED[2N7<^9/p\n_7M[#(1?E[U8,;iUsrkp$kWA;=0Di + UQ9('ZO*u(KR)J7UYmUTnf-:>"-G9gCK1A-!5FV*5n3X<+n;-Kn\Qt)s%7,JLV[P4`Be$j) + >_=%;tRq.Z^ccd_8DjV*%Mj_GM^[>+4^=>f`42(U:p-XQkrK/Y+n1onglaYiNN9(dK+&X_'c3?=/Nj:We?#,kP!G(l'P, + I820@+(%!g@@q$&ZOj_:V%%Q-+Mccm)*'b/$XVb9Ufl2Ma(+ZX*0sALQ-3b1 + )4]8r3M"K/oGS_cO%H1sC%WC8:$.u;%XfB?= + Q"A&$uD!0$/G/4?u_2'*U[@A/bb>n:W"m6?&_N$UX@$1CZ]jj?!l>nH;2k43dqUhD\0`DVm + H*4:J;UmSfL)\\W)OfKb9:LE/]S&0i8enbL3K7a\QXJuX^G1uK3+@)42kP(V@8-/j6Oh`^1 + =ieTd=,eCr;b+g/]/Fo56r6*=.E.^F)7,'Xpo7Z-a:335s4&5Cco0#ljjSM/;oE>'?aCCKgGNZY`oijh#G8lY + QoV`:Q2*g;T".)Nmtb%3nHa[fZE`3;91jGi%ZnOX&Cic!&09kID7W#'_G2K-Z%,&rtRWN43 + /$&@/E;TW/A\X!l.:a8emnJidP:Q>SdHA9fLpP@XJY;jCp>Am:U5q1S]d>`hJ!hpH7#Dk.C + 6k'N]X&WJ(Sd[>tRm%!@ZFCE$UhO667qM(Ydl?Xro@,GNV4+B$Irk!A^nrO$[)>b`s/D$80 + /#p4"?9,F#f_Pi7mJEdH]5IMco=]'hk52o3r!*;?`7-\\'jURQM6ES7VY&i=g5dJURrF[XX + B9i_goj^]b!3#7/cd3E!?EN&Oph4T5[po#aLEjFU?>S[o.:RZUahnTBZofl(?aLtrWe)7G^ + _#uj*:PnPN@'"#&+d\]L.<(nRs!`jhVDVki9hb\c9q?#rb&m[tUHs#Q4NZ8-F-#n(T[CJ-U + MsIXe9]qgSRcoDO/gkPP8kG6gDI3f%bAhiip'a(+n(5!J2%fk[$#Ed7<"YU)M0F,ge + 3pdu@TSLHr>aQ8$O.6H7.R7qkR-c*X?BY@]:dKXI.uXSg`sn_?.VH)$@C4URdqWS:LWiXMU + DuIQg2Bf%bsSB39o#*E?Dsk=7B(Cc3!KHs4t:D;WcZa''/KtW#,'JG[=W5b- + 0=;cTU\fUGY*ISM=*jAoUcUE,BmM-,#b^#"qaj:k739E9Jrnt4))4H%`s+ + %:7E.3K!7k+-=`QbA/C=Y:(3IXK>.n)k'fr7I&t`,1dqW_=Be^>J,$Gpn6n3U^NjcsXe69" + ".a;2+f%R@Z1C7_HHtbkWbs_g(aB.5 + ,,VVaGfH5m1a;Bc(E']jl]JUI!!m6q^#gs+>C1]k.G40g[/U!\McaETFoSJMbeqs]LOsB^= + >6"TY$e=1DsJ](^m*soN:A#9/ij0.QV.itr'?-Y(*gbbQP0u.W1crGd"'6Lm)^%.E$!EH?J + (dnfY[\hST%gS=S2Wg66H>pGi^I`FFh])Zt/>ZmN"YSB4TeiPHopAb#qdoja=%n13!4NjqN + +kr3Mc2[URE_P]p#8&3InYg<>to1$8DV4Cp7'S:aCYFfsP)ef0nUi_odd[F614MtiNYuWB*\()%!qB97)m`KA'.>BQJEE\8?@&H`R@PeK-Ro(n.rV;7J"?Yk/L]Q]\5hOE,DDf\.K8)/s)Y>8e5%ABR=c8 + -Kpo&Yob&KO-U*iidIh?[F2_?ZCCg20&Y>i";O37f,0S9L$6r^!g@&\=*%-0OOR5H#ON%3C + jm;8F(r6E]UBK([uW$8-9d`V2I"TGeCD60lmC%E[Wn-qOj\PW9BhSM6h4+HDNn-0fsEe + 2C)61NLQ.*[kqHN4D6[D7[ppOuLe*YQd29gio&\#NY)E87*\c`:l+P]\GCK$rH3j0N^%]9c + mFWk7c\(_C978r%VdHq3g_]GGUhBT>q/?T$0Rk2nDD7_t$%7j?PgC6#7?'Hl,/-HRmdd]o%Q2H+bqrJg=#*\<)W+0ET*!T8k`L3=H2( + Ri[>a'gLIk6>S#9Hmh=?.4_INTHb445n?5+]KZsZ_+R]FF,IA'6(F?GJJ_"s3/`Hs2#sF1# + %TYR6le"P/1[d__ON\T]KAR*4[[p$+:V24!,4LpQbCg2%H.8sqojR-?: + :0=_Fo3jn8,1n@gN8j#UD&/nFAuqK0u_(74_A+4B+aC<>ff=S1DN!Lr9Eq=XdTZ7B@RFK>k + >.8%9KU_($Y1E'utt,)t!lW:2=W4,tRZKe.a/,iE?ldqKeX1.I`+L1lPWpe/WJKE03!72rd + $P7GQ:ECV!h7kA^O3Bk@PAO="@$lO0n0m4!//KeL-4(r.p\F)+kB.it?+J]<(WM9sECIf?X + XLL.o*.nO/abHbN3;eC71,As@4NO"0Kp6>d3,Z6A,UHP_Ju"G?J-H8r&BPnPUb#D67$L8:P + t>5H8SIP/X;_QnGDIepN;Rt4ask!pc&Uch`n9T;@#Z/57AA.f#@sS44JY>P$7BmY+0484#U + )!+D%5!n3UBF#5d;TV>/1t?X+Z\YFKeCHYtH(B9.7YKKKq4No/gV08d&Be'O<>1(sA:tW:X + [4BM^d:o`SAg9Bh!187>0t8k^2=!'J.)(aVjIrAiM;7#2ONGlPWS;*&Kbb0[4/&-5"+Y=A= + F`sf:Jr6S.Hd7kUdb=$M=Bb8CugEm$X"O'=FKT8a2.B/,&T:ep'\4fW7iJ9/n:@*KP;1L\(T$1T#c+$KW6 + c#:_m>*8o:,L63AC""eq+mOW:TXFU,j3.!m`ps-69=PMTQQ>)`.Ct]L`eM#3T\C;Fq?@a8/ + Q+jn-dU%>J4,X:orW+FUU@epHR/H4/Dc#r=Dg8&Q'KVcc[*MfqH.]\&4'i67D]3kYtA,JZB + FA*_bLEn:?4?*=0:J::&LpW(G8O1=@)Q:-B3(O>P@M,uS"q;JddZI4/!Q.8l]d;QVHI]e!( + +/Q1CW;XH,8r@h.Z0iK)J;^jJR>r5D$O$!k-;f+HlI5k/b3E)J0;lr,[]G6?h=n.8!:]V'=62OACin#dkpV`DBPD;,nW7< + @q-L4]GEU5:5J!iuf]e;fh2]ANds/e&2[o)n]jmS4!o^Bn + I\iKH4\H/+u`]bCN@.Z03pn\DogC,hCYt!Bk?Obp-(#:Y"iQ="SJp4`jb"F]Vjl=)E._79J + *-NRb.Tf<'C$]mNo+I2/kkMZmM;m/9\=5VY@(9$dRj4O"nnncd!e#e\fG&11M=76Yj?(c8# + k4`FBJ\Q%Zcf,0Z?3%Mp)O]`]f=Y5h?4d9)DQ!%CY=`'L.I@+/sR9?)L=fn/r]pr6MSQXd? + =m_harLd='TirJ2=tQLQ4eu7UV-7+k$H78AOGqhjJq6q%>%Oa<]rYD^X]jP`>4&LsrNKK8P + h?4&Mff\8R1.>;\iF<08%<(@8Dm&V&=k[L*YMERPFfeXM[DhA"V_e6A<7HU8;AM.=Nq=Lm1 + 39`O%4`.g4dR.D*s+2VqcNHg5pnG]uhs55p))H#rT'0Ct-GK'cUBXajF@T=X+bC:L.,Ia3` + [&C6'e$$I*r9!q"_U-mW*@jjsqQgg$:QD9UiEOPGYD>b/pjY^tTKi@DmlfBA?%r7!S%d56f + ](c*;]RD-:\+Fkt^"-AG;!*Fg&nM2(5[eV\l!k[:M&7+dW8Zh+3H[FTlJ_i9)?9j'J?+hDe?5&cD+T9 + oU1\r_biR&UiSEc4i4.q$7`3>(uhR"oMe$\6n(1MUWP0>sCBP@[jdMe0+t4:eMHQSX[^W!X + 9kMAgBFe,c)Up4#Bp`3&?H2CP*TQd-]cK@"I3Y).M?/@9BCXi+\_&sRPQj!I8Q^+Wt + "=lU.3jEcGg0XtQ(=4'243kQGlRt:lf(D)#,MS^&HZ1k8a5bs>eo3p2*51IZ&DZCdf^;1p?:LFU)75%WocB4 + e:sABk,`];S;[#@EkZ?ulbX4?^b7'>9gnn^a_p='\doKcT#%& + -ge;m_'$Qu]g8<@K3%%=[+$8Dj$ON.^8MWn5pML`!'X:1LDSMoo-#UZ/MStHD+j_;MgC17) + (i94hNdqB5B-k<4W"7/#mP.TfYm;?m*!HR@pd8gi&*;=RAgMrPuEmk23\AFVG.]KTmN(5V%^F>76s%ffu&-6ON_#K;^@gRVfM"_7Is#Z.r3Jela9" + 9q>[gADA4bu$\_!mG-#&TIR4H5+(M'=-_e`4,K;K3c!CgN97509kf!97Ze%9Ro=$.s;[Zh! + $5ob*_b!5^E306)b&MjkW@pJW<'1lN@YFc)VAOMZ$V2_fJ*S+UI4G%c_U&GpNRqK$@dC3I>l#6Ggq$m2ZAMiO532aEh8F,2JkPFllT + G=IW++nUKboT5F"+%ddh&rAe/1ukRi5n$sode4m4"X[IK0GX@QKm5h:GYa(h?\\Ya`!/e8p + kOcPIuJW5Mh+u6/C;<=c.dL#Oa,37JR=9;&B&iIQ$Fa9L=4BV,;f\WQ2&ssH)I,:;YI.8cM + =*(H)YNOMOOA0Rs?ZR"[Ks#O.gkqLA?n$"\5D8+.DspM>49QqQHiBO,egB`-Tb-qA5@k:TJ + g1LAE>%p=/p3k;W,T:3<^lCS+*&Ybha6N=(3/i&HY[/te*KXp?Z^&,<.8fRi@,SKR/G$Zo& + L&&8GnSo^j7$Ps)!#+r?l[trpcMg?u](WHkJ^C#2'SZo)NGInjhEJc^#L_5N#pof%-%=D!> + S]%628'C.qR\a]*Hha4k8(TZ?XVMVFI7TW\^p80&b"\53GE@c3-ek#]Q2=[.IB]N'.GOe+f + 81;gLa]e3n4e=eSpe\a*uF!eG_1?(C3QNkGHi.KYC*,nIGFG\0!#8%!4f`M^]0i697@n@5D + "$Ejo7n/H3[CT"9&H+JjEekGXNkn$\h#Wd.i8`,nl/)@aTG=Ai1Nf7q9sB"GQj6OoQcUGra + ka,*kl5deSR9AM]cLB#^7WU3,mr9rHJ8`9L27Th44-=Ye-b8>\ut'_kBcTgGS,U:"/<*jk1 + 7'5Q+O6))=gYYh+Ca+b:VQ\N5f7> + M6)BJ!@Y\=WVGaJ%e2SYkB#=57X>`@_SW[iHqcp>PL27a`DKfFS..-gHPSjUMU%eA96/+N[jp@bK,:fj@!FMBdjg5.WY3\6W(dm3W@cP + -+W;Kh6KXh/C>oZ$8EhpNKZQeAC2D*b1=721Z+@UGTlQefdo>il:J!W_QHdN7#+EhYX+5as.p@'Z9ksm8*h]ikR1`">&qZoTlLcWVd + O77*SPTNB%83r?b^WKf9I"/*d&QaL(ss\T(GIS/Z;FQGeV-2h7SnGh#Is1rQY>)RSZ%+NAL + jeHg:#hJDVNb@_!sOE6d50c:Li+,h,dh9q*'kFp2-'A19+1m+o4N$6t?X:P_ccI3o-a/)7DqmBW31mVBjm$ + )6X#YEXJ[Z-pE-DPkH8r>+,T!PR:eGlptfAFk[NgHmH2PKbbgs]>NS;hT_lSRWGbHhg@SEGAM#BWI,$RauAS=dJ5pC8*n\FjGO9sAqE/b;j_6O^S^]XfaE#i?m`pu_>ld@)^,b5p1(Cd)! + 4XRGgp3m-2[ThKpIelp*"_7p+@m^t!"[;81AM@eN`5\$jL + .R@f<@j#0b8u#kgL6$$pri-D,de0N_'jJ,fqm.ARq$r8V.C"V-FaeP(B$c.5jP)+97YE2G: + iR>:^oE6^*7I;A#d4e/S=+,&lJ)6`H&#j!6ll!E@..gc?qWCk`Q\QEfUAISNSuX6XRJ$!WlmFi73B1nTHk + FC96(5t.7kq^!q`3c.W@ip,s\DL^66?rfh*^h3j;"qahiB\:$JIeZGe]j&aLBKi)M.cG)a, + f>"rfZh6`6Ob/)Q=D#/"fU4lX2e!A0UDl*,)W5P.#=*p1=C100&f.@P;)khB#oi.O1^ktjc + \Q8"[orIE*PV6V<=X*fVSMsI=+n>E?LD[`Af=(G1iSZX!j3+Q`*k*a0Upi#10>FaDG)]A"H + nU$3(deTAb(l0\Y>,NnFl\cWBZknhrPcX^>q[''G$cB9,8[J[_YFQ`iG2e_Z4.j%\5GAhrigTV-abAh&`Aq#Mjdd9 + q5TUO.l_c]L(ub*Nhde@UUIsFeX%,\.b\J("fO,*r(et*^0nN7PjN\YK:`UN!7?SA.dPT9A + g^A:k9Y!2=<%%`6;COnqh%A0Qm[Xt2Bpg__9$''nR)/o!Y6buTY_oro>EU8fF'6oC;B3)B. + fHQTXG"$m1L'7*>H2\Oe8@?D?s0V6PB&i^DOZ0?@3S(EJSpJF@^\XA*3?1&PDc&H7a1peT&qNq=F^cBh3%qIu>d.!G?()C'//!"TYB_L24")#Q&>eUjZ + J:\9"3X=Au&9E.i5WC?:LojmSA$mk"ajRNX>1h+5Ql9;JHo`-^f2J#)'IA9e;HLtlp)mg=*k#[6Qr. + ^?4P+H;unNgf=PK#@q(l"*sj8IXKj#2(CU.utV;08a]PAq@tQ4:p?L"N!iA&5I3.KL-+X^m + `J$o%=Tm"-A8G7VrVeb43`S$fVg,`qp8*'b-2e+jiIsL2>dB,l]=H!H=SE65ot;,o'lp#_i + tH&I/4\BeoAh#8+heoSA2t6l$#uUWiG'.5?Q-c + l#7`6hB8dZ-edZVm)A0OiAcEMk,93aA!0&DTcYV^],3BH))Xs:)%t=p_JJ(`]nr0_.($U + ?)f%fY?u:kNPl!P!gF'859bA-*g@W0K/m3>0LI+,Xe1KYfcsmnG1DR+i*kf`(9drIih!%,S + G)5$54\J;LIql.<-FUJdWde!%ZKp+7`th5oD0c>Ur][gksJo1#jgI>$FnG+7]IhWuB5:!:K + =M/+NC__&+Z',aPOI+V?XKNmo5(Uc0X=0]P:]!Y#S.kTG_`kjmU$KP_dUAJ`3@(_BU(EJDc + a*>m'EcV>asOUa,S)DLZm0k&urb8N%?"V%Lh8&Tm5_UU'/"AHgO0^peEX"I)pg*1C#?1T/mUTkQ(E8d6JnrXtd1'3 + cYZ?On0SHaQKY:0>eqe!nBAPd-[$4$Na*",In*$^?)P;e'Lf@&QKlm.\G0.[dni)E!.2J6KE6c2JZ@UV + X22+-J&2l-X-8l[._m_lJ1ISZ:1F2fE26ngGh7hg43;#Fnad7>K&7<68T_i0@("[@!./BES + bo!C.#'1kM4-W@9=jc9KhQOtDd!qUb*K*+[h#qE9#+On^9;'Q_$j"]OL1+j3u:H#iV0_)fi/$kPQaBr7Q0p45\l9KoLLr_l9Q*P#q\3SFIsK#qO*GC7b(Wp:Y + /Q"dOS9G/[2W(oM&H(O$\HR2PeR)P$]h.q`H[E+EQHM'?_Y0TNKaS-3WKgF5nclNZjUA1kN + Y%d*XR75n'>a"8T`+q20nQTZ\%2IJKe9;l2oY43I + b/$P=41p8M^l/>HU>D!!XNQH[3/NW'2]bG[=_J%R=l]PKQ_idE63YXhg^;,G$l&.U`gcQF* + Q"YGF3iTMALs`Ko"BBLf]Lk%gdLnY'jE-FCIBd;0ZdjHm#k?';>nhQ"X(6`IO]CHu@@U2o/ + 4r1HWKjq_n0B=4YYUgJ1H,16*:EPjK>&n>\3UFb2I-=Ge8'WImfh`2qcp/[L + !:K!cDSg'QlBWn6S'+i'k[0]sGEqm>!l5PFRXtS%\KlpLp/\-dae5uFZagD1:3-0jc+,@@l + oU(8s!Z]dTWKqgJQOoXC6mu>LGF.!4Qf5E@=`RtRRi9BX6'_p+`a8QqY_A5Er%:aaXdLBAO + ,Gs>\2a'pGhCsLh"*AdiT\@b%eq;%k3fI=Roob6&+P&!)0@bCJdi"k/Idi!fpNOr,+6NmGZ + `]qRR&P7hC8]3]u>KTB=*D,>:A"`XZG;N'reZ'Rl+M&j%/T$f[:Un;sZ*2'OgZOn + befj\GS,/8TlGB\CAKKMpWm$="qes#Ib(mTWSuS'i(I6[njhL9sPZsuX4%HhB%B^9:\SOo@ + )%\nL[9##&]o1@Or+!a:CW=KfYp:NN+]ZRQHcMhVa;f*.K;aS]cZn%b^NS#Ck0[eiZbk3*$ + QDIU40="4otKgG7UkV2p7%eh%CK]pC7!h<0Nij,l$eMcn_u^V3O*9;FeG6TbFAl\LjC/\ef + H!I)r0o.4RaEng`=PraT)?%SCb:kho*A:R[VRARr,bVn\gX:`4Zi&*(E%VllACBcWp)`6,4 + HZ\"[m$a@`;KI7)MT9@V8g]]tQk4\i"]h0eD5a;2shR_,Ta/$Iopd3[>Tem/-H/H54C=T?2M\V49!bJpl2f5?55?,oA;8IC6O'O.Sa- + frH?^4Xn5`?ekSpdYR"MrO/gk8)B,uI4o"o$AapPoA8c)a$'EnI9hX,gRt%2*u=5V![.Qr$ + n'IN5l%852hBV5'&a+lFFB@C4;b3hTr::/s,hH$adX>i5YaZ5og?6*G + %mS2C)BhO.>=Z&BCp0C!c=XN$r0(h=ceukMMc.ic/&VhHHL\&)Y;i[tr#\UEQ$hR%@UcWAU + Z0Ff[>9D2E]J#10ojXh/9fBH]F\+k/o0I%+s3.hnRq-1q20rH$BcB6\kT+WFS;*63LP>SnO + ]&K_,E?N_Gm$?dGUXp2k/#/`Jc(*Sk6Bc_]W4WE,R*S.r+kru6>ijkn'H"e?8f=e6Q[mTQV + AQ\Xo=CELG3+9HhAs%Ou+ULs'QH'P`'S2tOuH1i$u+fsMpAmd-n`t4f4JO + .3>>,/TW*MUDc;G_#i;OB=$M&H@GNiK2]64s:Mp7,_XsZl03%NC>(Sf^s + VY+d#=VP#tY;;&Fp7jc5aN3Y:do9[Ao*F/C0KK + eoDD<>.)Z1K]Vm'\X/7SX2%;p1Zoe=ClJoni7PU(9R&Wm'XFE_flumhJZ1NMea(OaZIlGW + qR"W/oY]uEX6#:(URmtdr'np\(XX]f/5uAMqCHDJ06;/"?f$#]:1lb$7K=Ht:87^M3c48R/ + 0$^f0W`f`2KWcoP,(`Al%21LAR\S=.:I238/E8W<1hnZ);?#LM;8$%5/'uI:7Fj?'m,\[36/c&"[Io#W,P@E(eNHo+f/d"l;C,hY8c + $P4fliXYC/3***r/!cX;t'eKOR(S+KPIME][)X9*E(T/_7*_[N-&O25qdA_+Y2F-J$\2$om + jPO:;9;U[ATfXs['-m%c#1'EZ@OM7O(LWtoR*MDqf@E.LLke:er7&ep0H8B;^8rOoLARZ5< + 7@AmoR^ebc4Af5lms':t3b,I&h>8`7F#X[-n,8:OY,bt.''r.Dnp62@Q33Jkk'd9MkR-$Gk + C9(t-@\ghH8N*uHW-R'CStUI*c)2eR1];u'KBC4[[:qtZ[\0'->*iq^VK&:r)C9[)D(5m*H + I3$/ekL%\2AEIUM1"HNC(MChN)fe@Dos3T-SNaq[EWp@oK=![M)[F5h6Wfg:J#&88=gFF4WcSnmKe^N\RMlMjZqX8X3Mn,+[5ap[G50)FNO$D%2Y-U,Wj/-CG7,i:& + X`hSDWC*eiBK/[dFlpu/n=Xl.:Q?Eb4$i9cI"]<@&ec(50$g]'4+iP,Cf*.!4q,0X(_&2l< + ]\F`Z+OGN95IKoMQ5V$";$J0_2f(qoS%+8f^"4gV:*u].Q[#>Y"[%%%'k4OOMZf%&Woc'.S + t"8#_sT6(kH=Mb)ri'eQ'F,Fk0-u(:5^jH3CbhIr1?V8I^.Q + o]J*^`K-r.#2d+sRRH1Eu!*"sN=O,t_H2VLkDF]G&P+`KQAZqi8H8aE--EZR,pFe]q2$h<1;Ju^)F+oP^-?*9@[[mk*O6KD)@.m/6-l, + \^:<,Vj4pf-'#&9,3:+k]UJm\(V!lSH>ik#:LSV+Eqo + _A#_k$]7=bk_p6e;Lb,$Z(EdoGY4[&6_4So6H/m'aAMqL"6/eoO8o8!P(5nkN=^jk%ZXDB@ + ^HOa-!A,t8P*qg5DUlkT9SGX94A8]-W@'gFQi!`&lgXN'h>5<,d0n.q%lURbt#\:WDtsP). + $"f,:o^.`lRU/UO>ajF0\G>"1:-m[-4TVUodZG0ft4b(cPHp$^A/,>`Vj?,uh%Z=0r2ZJ-C + (Z'J,>"qBI:W2%1pU&;aKPJROC6E?\$a^Y&Z4W@Un\+VIV4dXhj=LiSt-[PWhC82<^Uc(;, + )V#o,_#u@Hl]3(<5d^PU1C6!F),8D-O>J#/8lcKsqXG^S)]eR;#4jTHKIF<*NN@@EAYo:c(_%> + (S`rCq1R`f7dn'b=Fp1o`_dc9aDQIkX4K,ik7<>j''5!CSr32Uj*<)h[Ah)N\.a`f'sNi42WMc?R:6Us"?ji3dYK._Q6\heOCj1=W#k;uedR0EcJ/EoJ)?j@)H\+bm=T"U$73Ki;@l87rf>aa*)o"GKTX;)Ea3j'Cl*]-*/!A_. + C)9Va9U8!55,6I>"#\ss;A4*D1aH8*.HQP$7j+(56:?/^Q7H@2WF[0ae*AW%%>QpN7[q[RC + 3pk/!BVkKa!;PpJnP%U[f$Mk*p(`8')D*.AELn2#`2NSW@,GE + ,OR0V?XY]/uoi%In0bGE223,"tS'/Nm:=[&`(QB2XgbS&0.dZBo3\[,tDSWnU"Niqu6?CP4 + R:XBB&b(!hhNDF^/+0+PpI-6uQ4!ksbO/Z#W@flDZj["&A1k+(V*'qM[n?BZ=4uL'6c2tAPh;Zt>-1OLl:"uHb.!*o1O-/EaB%RG-iUf>&G,G30e`5r5Z%PKGFj1*B + ?jmRi:'#l"_(r)skLCdY[qll+b-q`Y*&kW5gY\Sp:89\[Y%hi[G6Dj% + ]@(&*U*(r6'=NHq]FH[e9;\"7p&CN9`MI1t$F;uAlod5gHN#OrrqlURP7)HZ)g:9>?PsjZ^6NgW5")(%MX2%+[6VD@)C?7g(84.q4#H2_ + L5h?,!Bh"2+#"W:+6rKb,$pV<+7+>(rPRkJb5p+!pKUcc`XE-"qDo3P1^76"RZb)a.egK-K + />Ps-Zs^"/$o11N7d,TG;t:84MA7Bc^I1.S4B]EU;i'sA2L)@@C\J)38A@e2`(S%i6N5#e! + &'Rb7DS\m1M&'\*):oTZ]k@DF]&_c,4-;3XOac9\I"_o-C6ZlP@CEC9pAa\a\4e1 + AX\F$?B:6'@p'fDn&CT83>lb$qXrb_&=IK+R"5]1B@;>cA!5p^+8\$TmOg["$-gL)^Vl#]" + #gKW,Dg`3g/59&Mm*Ya7iU]WXC*/Ej>VlAlrj+33`GVrV*Gkop@S_9=1A#IMC6LpOs7,re: + sa[Em;K+^a`P=@&j7QX&VA(aG9dL<,c)e5rNC(LbCaZu]oV!^",&$0f!rYH-d>.YNMHI\hJ7M<'LPV2oPf2ZZ^lM:u6-oIf(_%EZLp,+BWR6VY'ZCss%-aC + SlHm?9dMjc9/?D`3=K^0CR=+PCFPEr$H7)CBbuA(H>pcK.:!r;N$TXk'1Ji_beASkZ%!iYF + XT-7Ta%spa:"X,Rkc#P07N?B;#jfur;16]rk"=:G+HVIZ41-A%^&pX20MOV7C6;C_0df[#& + X1=k[@eSYN%'@G-U.dV@2soq`u5J + .Q[Hg9MA2<&7pIIort4QKS\`Dbe,g\%91^p#YCdkYJ\)3m%hCTL"FD$b"[6;]s + osP*)iMc0D1qCj<)83'A0i"=73S/I7fe!3l0pZ_ReP9Ha + 5i#H5U93#(FnhPFfSJn:fO`de6.sdfRF*nSb8#q4fhC5h^>Ku.PpD2jV;EtC`OOt#g2Q63X + =.42MI(s$^.%i*"pi(($.iJL8gV[;h9-!OYTRYD7WFT\Zc!meJ\5GdASXp0uQHf0/3@R]ln=Et.5:4U + \#@cf=Qk[fE$6Xcpqik9_B._,``21o3giqQB%5SQgIo4'6qiAN`k%?Y,$aOq=k+BB=hnb;" + 65ia)'iP!oQb[XqU*ad"A&j9?XAc:H8k8R*#JnrOtjDJAdZ,/+@ff<[)hBihp1Z;A$f,dOq + 77^)EULc1WA%l"*L02gB5\6):j;qLd_)p^;M;P_Iaai4.H:64qo]29n?hE>XKf*2DWT-Yq? + qpc57VEQQpis%*jPFP.>mob+DB;PSk9b956igkrFIa1Ok@Sq!AmL4@ft + ^WqNNQ[4VI>NT@\"8D6>_2(hJhE&.63t/gSnf)r?0(FBFe]QAJTM"reG)tL/2E$\NgLTTF0 + o&NG-KIk;J-1#*?9rFgeH4kr+R+p313dQ&_/U#^1McHj1&PCPGARl*d)G\:!PgnR=*Lu&BX$`Ui-0q6;$NsrBg.OWW&b+_3bmSM + #,$*nTa$5_EJ>6glW\]Km]Yj,l%D$,"?s#E=F19TP&&-]lMeAJ3/E1E=p!isB[2V'(:%]CZ + g118kl.OIL<-Y1Oq'[WlJA]12R)KgZKu22CM(%k@63c#\neaeCY$48f"^OZ_/(IBlpf7d?F + 1BKQ#)c?NTQQ5DO=khHWsM*;'qnGY^[8KHj=n?mO$t3.s6WcCun]JLik@`d"g4BULs-BaL/ + fuW/0X8DUGRoj62\<#ifTam&'9"in!/X54]#BlL,d,=4XF4GZP*r=)E,un$]H:!=%p.NpGn + 6#5DG>8F(3Hk_[^C0tA0L0`MLDY:A(l)q:&FakhCMo*sG`Qi`kk&!<#E,a"rtYnV`9R + @mLQ!dD'WaSY,:pXI]#l"p^T3tCB%>*-X@3PJIXlLm + 5DZHk1&k6ZA>E1#QJ<"#8$P0HtF1,ppZ1S.;VQ`Q0fp1n%XAn+,:=ZOU`akDnfh=k.^-\L' + XE,G_V4QQXt15@<)m;H*T#B/^7VkOEQL8)#%c:O!ZnlYJ[8"G:8;I!PX1Sd;l'N;bnu3U\` + J2;k-_m=XSV'<7r*W44D9Ie(m4aJH>McE[Oq8/t]E>T(hj$c&P#O(oOhPpUC\$J$Tm,[^n]tVNa+&7?Y&R6k!3_UmO3I,He + VI9>Bg@IQ2b`ofM=e7[KW&O:Y0?li9(5X7IP8D@[0>Hq23T^YXCadf&&rLmW]RhTi@*:b)Ti^Yr#!A1?O6Gel_O,Wd + .[$].>\d@dR!)'"`-jA@oWH9Dd`XrH\[X$%sV$Hl>QV8OQ@0SQnTD+LZJ3B^e1fMZH1(6&b + U/IR[cUB'OKL/Uj0.S4ZS(m2b:n>XAI`q",JR]7dt8R0tN2]_;.h6r9=\,\-_4.?`IDS0:o + =1dSfrI;UjE*,4L(Cc/<@W>M_AiC`kaC/Bm4/Q!IQbU;A:Yb"%4T!K=F3i(jpGDljl>d!OA + lJa^fP7ZD`hQB^$3b;@4,0JD26u.ZG[*E[(QHJrEd:a*8CVFdh/c&u^8G&7fBd[-?+\:8]r + np-cQ'K[EmCi(1E?nFjQWX?RRF$<%s2mBbcFB#;9CH-r2cR6/+3GPDu_Am'M5qH"@.e(&B2 + %3s%n\H\jDlPqb"NrnCaSdsg]'uc;O>o1KmN+EmHOfWC=`t?K;#KMg + CQQNksF>!2>0H*FT4pbHSQ+i+0m.J+I,PqR2&(CaTb,L%8LYrBJX@Zr&nI9Zo?>ZcCT27C4Ws:I)0Z@!L9]!GlN)2 + U0.4hD`r<4\rLb[7*sBNHINc]2"VL"ZfXP?!#SlN*brm1a=^9:%0oKPV7k]d%dU5@[sAjDq + 0*,6]+$iX2rW8X!B*SF`rR,;duc"W+^!0WkGCd&ITk&3f@IA;_#7fUW>cNM^Z"@7r0Er^#6 + oKK1tYH<`dQ=IG^CYrI<`B%L%E^Z/?]G8/9"mQs+-^HAGYf2;AP=<[,nN=Qq]jA5,_9R]7f + ;Jk]r*fZ^(Pg?KA5[G-j-]YiM8e\n1eLc*Edj/Oue&D`3j-Ac&BA`]1PCQ(tM@%'iUVl;`q:t7[FEr#glk`;drAFUql]=u]%*Wnn + [bo_WA#lK]%Z_JfW'e!c&&lVV]n]qToJ)8b+W0R$ + 1*iaoRD^dg_RPU_'*S/4WVeJD@#cDi(9UH_2I,]IJ!,S;a9(EL.PEd[6fX!gd5(KL0hs2e= + KN=t`*#O3nB.O#I!-Y/6>tr)&J_fH6)%=,@cSFB&EY+YO*\s)OM2_MG>f'C`,gr8aMYp47h + ^[U5\LT=oL)6/P+8UF>)k/5a7@f$?\:j$nS1Zf=Y/q^af^,)nc"Tu7VGL.Sq(FH\%lJ;!ZM + OTDGX39aa%/Bh:**!0NqRO=_ruRg\QQ#E\N[K%%O#M/S3usWk&fX0jbe-N9RcYP$!J](mI] + <:20)cVkZ,.'J(BNc1OQ6N?[F6_2N@X(G->kJVg0p6thl7],>NKkCiAs;pK\>(q(g8)/%/P2`]>tl'qrI8 + =g(J4_[>6V+5,kR;$hNjQWKtFO!`$`jXWu0lrTcc*9mLaJW`X6"#?3HB1pD(BW\gWAPf8$B + \7<:3*CQPmXNF+f$DPX\,QZoJ2/#CG'/J01DpYnuhco;,CfX6Nek];0fht(+Nad<).5V(Y` + 4=]\%@li5:c2O@%bCrH-P0ZCdk<8=4CAO4/uE:jFQSG+XWjVZQ8QW]W + r7]eR+,"NIc>-09nXqQ,l;5CY`Yog[3p^9jnHPYp"eM'T@-G\*(9n&*`KLVhbc=WG-I5=ZoJ*)gJ8,b+5:WHNbkr%Cu4m4V7_T!l.XQ&#&]q*;NZ8mj7Ko6 + L6B1"]cuN^_j-8IL\Vq[;7O>Y/g7b$U^ + G9@W99BQr1l\A5`ScZ;Dhr=G4LqP:L\D?,q>8Z.>LHJ\Na-%_dYDPM0%OQeQT.WC=;j75R&mgff4KFJg$kqV$,2N]F*m#JV:;9bu + ]6M._/clpOS1H<;>6]9AAEAP6rPM[!*U!m+m:M$AG7sGY_ + meSMFWXrM\3#<5VR>*N<[_Oe(7qP&al'aletoek"/E!C7P+!$gJiEY&$V<.:hAri1f_ + D%>&C<(M*CEd<#:6@5`S\0DoIU(Z(Bb3;13D4'9)95#Kl,_E$AD")m<0X!d!/qojDU;Jq19 + RT-Yn;`V2gDZ6usatE;QS(g#))rJAVLNt-!pHS-F"b.iLKfJ-<%4-)J8G+0=*,fYf\:c,0$ + dOO3ZVBeNAn,3E7i^dTp-D7/fO);K'^/!_;\r/*hRuFYoj4bMntm%?HmKg^lSJqSYUJALpQ + m.I4GERkalGJm*%;q&K6tHSm^;E'0RY=/(]QQ1EUM-JVB=0M^8P;Fa/o/FCrl:`\m@<&M/) + ):Z.!mDG0PL%7Q6]P$IN)TIt-l-,BRgj+nRn;R.2-5Hi8H?pA_>ss6p0kcj9\+$NFQ41P6Y + h!Se^B%0>r'!Y>kD@HJP\a>+q&*5Tl$:cSS24T]'Y*C811+ljUD_#pnh"V;q$%Rr0]qB$n) + "7T:p:hUfap`AD^1!f:f0PVV:TGe7$]k;F,6$O3,i;O:D(P<(uYYPJ-B*Bso"b]c.U&$SWT + *k(&W.F4gd'X5mTaU?!!?q=@E#T23bl;,6*'qLu+mL'Kd1#N\"7Y"b&4m#O:_fXR#S$^Y,\ + GD=Us%eS=JB>NJc7k#M%G93@Vc,Y.%(ZcK%"UVas>sjc&BZZ32EFVj)I790i0G6<>*>5N39$kb"V*JD&i)m09U-; + mhfOoR5B"XS2?-XfCGi(c$NC'm5&-W3Mai2%VJo-[64i"'ce7Xh+FXp^9t.qaBlU5^[@&BV + 1@d4^<\O]re7R#H(.q2r*>P.]t;0cGZ;g/>"%YDgCp6H"si*A[:@EqqA`$Pro3.^IAMiKbH + ,QQ]9>0d/P3DL.EM<@d-n(Bg'Vd_ROAMUq@g!3j.*Q+TN&\K0#3[+EB+s!uWEVdlJ+]-Ltq8o>N\a(H + D$M]b6)KUEM(Mo-H/[.DRYc5ro*U2_%[X3eQjR&],0Zn1TP//u@!A:Q%)m*u`#)4RIqSY7` + !H-9Ul&EM?\bMB=EK:,%nW6IAFX@bjE2d4do2/J0Hd;-lZ]o/9Qf7l5?Adf;G9(5tZ6-<)$ + >FAdI;Y=Pjn7>F\k'K.C>3Zn!!(">QqoL:-K9(PnR0D(AYnK9L7UIG1L0f6G>.I, + 2MDSK9bJPQ + NseT0%UI$mfDPgjGhDb\Ku:(G + ?qZ0Jr`mU1V$)W@h:_&>kQWQ2;)7Mh-G0\>bUp7!Uqh[ar!Eu?5<-=[J*ubr#4N + \'I+e@5u8:2qd6%;&&A)J?r."-M@e_W@.hY]iG'.'+rVUO&p>R.ei-s0cl"!i0u=,8Fus&s + 9k0Jb!jF:3[DQ6m:LN-$&])g36'SCX0k46kB/WV"G!BL^)BU-`*`bpHG)'>kk5M+pB_I?s< + ek"(l7o^8?T+]RFfKqVY3[dZgonstFh7N-IrS + s5;ZI^?2`Med4`_E)7kaQT^t!P#f6$aR0i7ekf%"miQ3[.l/mouKG=i<1NHX??DU`TIf6MS + LI"F9RGNP%u(Pj\d$3;9SGr@,fUIT:naLP*1M13a\Ii*Q0"%i[*N,91t-9%>D\3(RgL#BBU=XeX"8M9C+GBk!gGr_(_NJeZ: + 7lE+8Goeiqp]+]ePp&qg@I9>Ss)AoDQ6sq;=0*Lr7nr;M4m.uVUP]N]FObRK*(S#=g=L-c&.oTSE+&qg" + DjK8mofQ%&&0'#UcLr?H:apD9r.V_V)hVQHT.%)63Gd)k+1+fZD]e1cWC12\K^4)^`XF4SWl + 25./O%Q)l^E\Xh+D7]0!F-?qn8C!"`68+^6V0gW@+5e$FWFZeMt&HeH*Eh7`^EYlHGkGUs= + YIMr8([QDaKA6$(4\$l%9XV\?[Rb*VtOpO2O!dk_Vg\CYu6]'e<(*"WAJ7FN]cajVfD'GYT + _9&&!4i@1``&pK,HqD8h9uQs,`B7/>Hs+G$?,c_M`]RhPHtgS[\$P!'`uo`LGA\87TtGala + ?5.Cqp6L:hoP_2aZPj1I$r*hS]Uf'aulNB5eY=P5QI=Y"['2h+>80&j,L6(C"2*Zd)l(\gL_AMEYkoTBf&LXWo>hpMd6/2iI#H + B^(WX,u[6Ocuh'`qb/WesdbP`I1@i_*B> + "@*dE7c-O(,1'"`6HNFDBI?]'>7[Yt&feqAENS*PQJSFY*]oXsdC_9kQ"F[,Yn*+Ng!Rk>D + gEQC@_N31arR>%oTK+tJh8uq4)@U0ngIH!R`*OBGh"S9Q%3=QcJUQ,I1=2TA0c>KCSbR&HF + p#Y$>X>MII1b@#%H-J&dCp/F>?G`dAcc+^a1BaRqRZP@c/F++gOcW1]5`i/8).6+F2?&,!0 + -'Q1#iH?h1SfHIT_onZfV*FW#]m>!rR'8TNKN3P]F$^a&KbT:B7@C#7E&+cl;s,po=(O4kE4Io7GuiXm8Pjs-qb^ + MESYHr_=&m3.nmH,'pMCD.qXl@4<2h_HJ4b8ri1gb.!=.Zb%++-b^:q`ZD'AcPTBHi*d&%0 + KiGT?6uhH8\/f,%)q!*c)N4\"(3Iqh.uDTB6'elpi.Mro9"6?hMKiRNN.9'Fk!EI_jp'Qdd + W*$%>1tYZLH,.2@b0it7[.DE/_u8)ki9&->EL(M2VlP5K^2Rr"T<$Fog&73I)?s2d'RoQWED7mh_JDmeKX8hs4&H(&&#g_dW'PS5q9\NQ5Q")'"r<.@#gDo+c:PD_7O+BCm&f/ + rm@X&3#*b_qt9=l5(6HbjkK.5O\aH^PscP#6; + R/6k]_iE+Bmm61BL@bQ7(Z3=*Lk`#d9C-0o + !hL&.b;2i`7+4"fF(/tm_P172HHp!$lT7kggtOtK&DT7 + Hg71)(0;J#tlQl]e\`#@i[Uj'f?,;9".?BUJk(`78h.IjuTY7$f-Dk[Cju_MiRGNL^3+V/thpsr7Bihg!.g4K + S`T<"fGih)KA,-00Ag^W#;/dn,(.4*clG^)pAbh'iMWF$Q;O59YAK;Rm#aAah,]ohrR7P?3 + MNo,!6@&XC^e:Uhi49u)2QKE;/ZU.iVR',D)O1J_>WAUmYqe;UYDm@F7anb^HXf:&Uq&!BG + j\t"laq&Q%eI-^=^nS$DgVcl2WfiKCmJ]C`)qHCk`1'&h.\d$_+^Yk.W+b?+"hEN#+m9h6! + C!nM%nbg3R\6s7mAcpq*r9PFm>"0Sa?<1CYO%2`n@hsRu_XJ-G/Pe^\@^TMXBni-Oc:1&RQ + 9m>s*ReG&gnEeKl$85kqI.-'u6t/\"@7nGqGhF7X^m6T]h!M20#0QCia6K"kYd5LsG[GO,2 + OrK;&P&aAFjVW%C.1cWX;!O1*r9Zm2P7_>HH\hlg,tU*O-=kUlMC;Y&\-T + *+,.sP4O:!U3,!Q6jd1'`+2DQ!J-S/-eZ^-aG`PLI5#ULo%4>o+Vp5E_?b + X7([oGl8FN?<=$b-AjF:b:!IfA(ron9+EM@AbemR/+IoC#%*D1m#qn;O<9p*7N_Z\Og=2r) + !0hQEHTC=cU.KI,H.',2'_N$)b\XeU;r!GF''p/X:^`tMi'Irh+[M[32'f*&?P-dX0;FXjH + K;Iq&l9`B727&A8Skpfan85.<9Kf/Wg?W[@&<%70k:sCHIGK*aCiXD;.K9i;t;"Ib+/Q8;c + L_48#]6S*=+7e_E&5%3CBfFCmWM;X&6g$9,caj("ICo4\S:_%W%tl^b7Q*R//5Okmn(U?MT5V@=aM0t1c8D)$"Q:9PE$C2Tplo + %)Tp8]O>O>(1f:GX_&08\KFE63HRrU+/EBol!0S'Y>Q>s*BhXhigKT#DC+Fnj[O!A'=e^#R + Nt"m8Q-F/MRujX#`;?I>rXC:Z@pu&/8Z*4c2Fc-h,6q3l!Yd%*%-t`M?qJucpMc:K>L?L?& + U(R(V.<:CRRp,*n@ha(g0VD]IW*VX[qd>e>4Q3KmKHZ>EX(Nl7Bp,Oh@!$//XtPIRYr56Ne + =f5>hr"YChVKJ\:s3-&L$b%6p;h0(mbFgOm.a8m+\f(W&ir9:0VXOaeMd.SWqoFHuZjn0GP + AWiuEW3EY0h:Wtub@EbB>.'JL`9_'YAYR/ZM36ct4G#86WHKPl3)BCVDSfScdL:Jj>26LQ] + 39[H@<0KI:WL@l/L(^b>G=jE0L2O;!fZ"+;E.9Z'P>Z+RMPj4bF$@6_i\j+jFr*=VmdX + ,;(G<@@)[eT,<+M>dXd=RcH&m<,^X&'9`En,fKamFV\c9*+rSm0_!o(BRqI[>CZ^p + V!Efs?28nAr(/)5XB^-RA@o+eCep>hKi^sTX + ohr"eH$jZc,cVb5%C:X(D@5]X[)I&P5sI4!IH`.eQI9)!<\fMq;#q3B'JZUQaCfBe&H$J^E + *;0j7uJS.A&gHg-qRTdKI,G/95_$ge9_nIo0$7pE8N,.I1uMDWX$`[D`&Go9=)ue*1b`rdY + BMNa7Oi1]CuV1agjn$\iG)Sd]Lpt2PH`3A.",'AS`H05U,6M4=NUbAAJ:O66^KK)jt$Sqt==@=Z$4gZK"r%/4c7@l=F_mDs&M*8_\PABF&V6u7F2e5V8"qmXJqPOt;09SWo71;2H[73aJ*QmYLnP/Ed&b"0 + lI#Z=5*X["!>%rc5K9U*JsQ,(>D^sn^Co@D(&[S(;a8[-1V=M7+:l\`<6#m@i53Y]^ufunI + ?bE.XuFGWF)1;T2bL1J4bE(hM'gkD9=9CU+CFKPr&),-uLbe,1D*+_c)KM:A'8(>US%+,K* + \3#'m.7BfPo-TMS0oo_,YT!QtP\;*PBh]Po9E9uE'Ac?6hoK5P"o;_[:pUNtgC.hXba9_P9 + BO&ibt%sM$?VT)bg9*9l;":j9dms)^q7Y)?\p>-Lr:2<,bn(tffNEl::%f4d#(QIVp$\ia4 + thjiMH_\qE@%6$qkpJFHJSV28te5c>0<%;lNS*oM1qRcohL=I-_8,LJ1,A:jO)d,h1+aQHo + q1Jnml4TiNSpJM94W`f0N99;PE\JiPV^c.r%cN.rF)>!+KiSD`K4>nII[L]Bj_2C"[oFWEq + '!#2g(M!Z:T]`V-&,#ThU:g$'2r,5$?JNs8;aB^#KjUqh2S3ncubTdJ.o'*pMIMbU7;Yut: + jQ4gGW.st$2BeqIkZ:6E*g@rnLtt"\XWc.>3`Du8;F*QHM".?imYN+RbIRr,Kf_/7.>Ra-/ + *)Q'N;(GVL'@s\!Q@S6D+R\DWl-;f.^62Y]UjjOIT()U$&(ChrD?F_4B35_e.kn2,=+nW`)X1?L"1,C/TD(G4'%H2;s42^eTD+>G"JN?f.`1b$UoncdeXB0h*#T\1m]o>F6HWSaF + f\5+^j>,?`%9O1;=.a@Z*I:m@X=ISP/)3t@bV[DCKA,_!63XAk]r + P@#[QA?.=.QKuC7JK+.lgV"&7oc<=@EEb70F038EIV@otXfQ_-AS-gc`MZ5\:6dAhTNtLJ> + Zk:!$Y"b$7BVLCe_9&?#f#FbZI0gmuVo%FA>sHjASW$@lH<#[ZM[$Le^<3t_1j(Q"sBiLJ:%TUia-K\>fFqpIEl*jiER,IL$N#K9nuqY + \R+T`gO4AS?p4JH7K24>rJ!RY#!f*j?u1O/"^nJ;?sX7KW-F*=G`%#;L+kpO[LD*.&HVB"Ja + fXj?rhkk&RfPi?e@1=eCP%epYUuIi>rtH:e6=S8;_q;LQHN7Fr]JSs'U!U$@W:hVBTB=%tk + tig!R$,iZhi.ceddRik''b!Sl\.cX.G=.$_@[2>&`d'[>roiN=>6:(,ta!=F8W?oB=j*][T + 1,@HNNkNZ!_/1h8d?@)a5GkbmD=+QRu>A#9Lk + [O#FL-K9:Kbs9/Ni-0q6;$Nsr?r/lg!'4[>;$N\9L7lYC&93F>qW3fI%/qjeYX=.16f7BUL + U(iTAm^=!s(0hMLr_1PTIsXg<97FbATh/ap+'VOC,EXV$:[m(-<"JF]B#r*VRg'"gB*=kfL&(7RL8X + GChQ>(McN0]uiesYd*Ru>kIMe8OEm[EDFRd(X-C*n\mY+o_sd7p&69rT?\^jCq5C2PBY"%M + ;<7cWo3k&+MgDF)I5Gc-9mAI!tQmV_-(cKoH*l_o>_$@qIJ7dKLam;F?67=]4@=@rf.o5AO + ;ms&RT&93Sp3.m$&mrn,;L?jnT@#B!ELXuBB%fL92*!_TmB>fVR7Aa$gH;EI0ZAdE^(W7d!CJukmEIVE^q$gL!nd:Vhg.XnqSc:89aT*((,O-E2 + Dc+.8YA[ZSi\;tKO[r\4MA)70%BU.^ss(HqAD,/W8`W]rkaD+ + WWj=ZR'(6&Zf7,s;Z@s3KAcA(R+VWg$2BQ+=Mn>?Ae?j!T%iPpc9-B%N1N8^(^hhP"defJK + W3+J%%"dglY&BpGT:CG3!hqhja:l=jUhXb^-o7d#%Y`JC[[WWdno>U\"d$8\7LZ%=M@).\B + %mfALa60E-E%'k&a)(J%!VY,_p?-@<%rc_7DMB9C#B6U^+EM`SEH_A+GAh_M@)6mIVf,(KG + JA@ra)KT@?j`:(#&ep7%t+-h>QWh95-V"3:gSA_Gk`Y0+^VcZ#fbuP`^ap/VI^R-G.Zl"**q7r7peW->_mI)!aVa*r7%-MRhiI"uZc2hVO!Kma3PpO@u0c\_TZbkGb/pt7t&6r;IJo + tsgZ_e5.eB9V6IPdEB7M5Rrrs5A(KC\HN0pNYH + \Fam,MCPok3^Na/KDQWdbKfG&XAUcgtZW'BlklHNo$"fV`EGZJ`L(qKGL'G?B!M$?`(f#Qt + &0"+igHd!.r*&f""B@?B\h.O>ac7:OYh`(hBnLrNrPki=uZ+-K(HNjba;E8OnhV/(nrSZ*N + ^aC9'(bJlkR=r/Hjq?.7#6NBtse7K^JK1i(?C!\c-:#lBWXt#]OX^8DWb`-5/= + .V1E)_/$4./2m@:_;P3s64ZS`c+E4th0N]hLA%mJ"1KJkh>XKAj[*t;\8;K4GW58FhO + >ZHhql^l,l?iOQ[YGn=f&N'aCI18k+Y!aa#@KP-BTh8u;"a%1"(jPRR]/"qej`2(@InLQ7) + hk_hl>U)t'nd./\*+\*F2EKiql7$,CLEO8ddLO$DZNAW%,-BM0E_7S]BL"="@:/8&I;1ZFR9E%d)7LFc + DW:2&3ga=%h_:T6r=[fO`X_CVm2cn)UgFREui<)%"BD@E[st[Pd3g[UmQ3L=]X)'I:67/1U9Tp/]FjYmdE`!F2 + K>LI%;pV$NMrLSa4'A<>SYAG$2VE:!=FhGB(?GL-#p6Vh$T]fgf$Z/\Pt,Vd-TK]*^EK1oV + HFSLLQQFOl]_FbQlB+fiE\FJ60I + -$Hp[IH,alQf[UjT\%bQHXG8j*J!B'(7*!KcOLP@7lY(t9k!nLN.U&8H68&%oefTHAU?Vg[ + -_(&Z!,7,\piPGXke8/[ak7d[NP8aMWJb\rrKq)>TX8T>#9@@_XUOC[C=nN^;#$41Q!p)Uf + jE<(Xc/q-)m\FU'VbcRbBEj,Z-m=KVi"CF+:*%m2UaXFGn&dY..eNL7oUX+0+Xf$7@jnYJL + st4?\Q0GPM\30o[ej?_Q][?D"4^WL5I2DH4^m?5El`_aKm:D7?A\E4DaC& + k*Vr0_o[L+UgE?H"/^QfiU#h@pAkuR?Jp.]1h%4ee"^UX4F@7;2-\mLE+'B,),RNQV;c;9] + 94iO4ILng_7$JX1mVW/m\LXBKh+-252N%UP\&2CSTc>qEd,#a0Pd'u0$]0X8r4tAF9]OFA3 + bX%D:I*>Z[tnheJd;)W+il(.889#aD01IsneDZ8W[N`n"t6Ej'[MUM<\mOR)%_R:q\5G8Ma + SHeZbd4lc?mf-/8cS#R.VN\jF'ZMD="Qqr?02QhDM:/n/]#tKHa#K,;Cr33Pl:08ISrKc`T + &mQ0(K0Ta-L_LS'=."#]1dmf$E)PA?MNMKlUO>u5m)B;j?&9.A0km9!(jLoN:PiKW + $8I@uRFDe=mh`$p3EM8kNQd\-39c9bbU>ZW&3BgB`rL&5&'uaF,(C"c1HM3=n0[ + rhZ[eJ^S@g5e&Ha-\PQl`X,-J'h87e+X*Fug%pe0-;,A(>^dq*$BWs7FJH,/NtYuY;&U`Ke + k=Y+mqR_QaUD&-60Of^as3UDFu(Qn-)@6=$3"EWV2gsWa>5Rd8 + #uaiR1MT90SLar#:jrT$%H!5fnT972-_kd#]bEcA]7mo'21aR^H2B4MWi'E0![aN3=Qr0Q9 + k0UVf^7>3fa:XiE8FO0S*m`V=MWQ.ig-;7\>pHod`sI/'N&5)%@)@\=C=JKfou5O;@M+I&j + Q:]qR4/=@3P;HTdEpubCEA6aO:/uVOtNrR5gLjsH5#86o#AuKFaU%S-3>8q-iaIO(l9VU6. + H8\X!m=IhaI.2p]H6:_oJKO@qK%SM"@S,sF6h[7)cME/fY++^6KSmuL9<2TZl&N*s-I>Z1+ + P8/dV5CMXkRsUmCs6E_.C"-'$'G^(.q"Ho`c%*#@q^p`'e)P'V(([I"!grA=cLM5s$.-"l?i#/+#irY + ],SriE$ec,RB%DpkoD(GoVRm0==Z^CA?05bE=-_IFjF&]/HT9b<6Ns9&':l]Ao-TRb_A1"5 + eBaWnN!%"cn3N!_LZJsD6MCAs'TXX>EFYY7+b53,Cg2dVXB15amM4MC&),7E7"X7D.]a&I8 + ,MTIO<7MF"gP[>A!P2B%AqLL[.*"C3@8S!ejIJ$rh)+D:/UAV('aaY + X4N5,3N!9jse_Y@aQiRPD2Ds[mro+fKci)K/MU(_R;[EdTUI#;D@=.BV9'm)Nu0XUXEapY3 + *`?[YXQX+i5p%K!Zgu"V>Tcu9\Lk6J\$_I\J:,U!T3FgekAYjE*,XA:;$Qq9"ocBnaHD(P& + HtMNnm]G&R2)E3Q/uV7;u<7=pd-%n-`>j%,iX@laVij68-CTT/GcP:D*)D9dt+![&:^@l($67L? + 0fsXZ$0Y`2"1Um[ML#4,F%4V$C7:?WK\q^N/Ys]V+jONQlk6`VA=4j=H=QbS(M]_\c1u;Vt + =a&``*LG>$jY0$$A-M%/9/QeVDcJ*q9RfBsWamsG&`;gZ>LhQANG(%(V`J"tTa?4`'?BNHq + `-"_*L(auR-rhX'1JQ`A363k>%#LE[$78X)I*_Gf_rr\u\0>;,^D!nC5,)?_lWBq`,-u+SY + `QlE4/D*^S85k)ZTWV2rNQCu@S:!]@gMGCDUJh"V0).i!a,hGLOF%5ZIQ283OX%%2Y@\tKm + e&7j,&fM(/$^::5U8mbj8p[pd$u5_R-X6E"n#.jY[GV-mfm^V$a/4^!_E9d;X[,OrZ\NEE. + JJ<9c,M"0ee#h&<"YLs + Me=1018+Ba\g_ioTnT62peBh'T>C'r%0D_HPKP\0DJiC$@ne&ST3W*=$UQ4Q/+8+Z'O7@L@ + .J.Pd\H;QD:gCDX9M]'e@'&1hHIV^6p,-aCVg&nNEs:a!&]C%?6ocjWpu/+3*IdBNkG?mPP+)H,8G_nFHW8,qpRM,-_.m + m3s:doeZ1q1dWK#1&a5qhREj66HT3OkT__^%5lKpln[WEKu!&n;!u1)@0OImkc.IR=M$>2- + j#kr15[IMh$#T[.rgk[%H@.EZe;(82GPnUbYcqN4AH54^sa@0%0W+QTd]?W^T5he!qfufe8?O1+i"ae%/ + X:1*%N66:2"bU5_Kj2+%MI0QRRSZOSjPTN;dBKi%(indR?!?SZ[Pi=PY?<#dr_2C)-$d^-B + ;oP$bC75Ug9s3tpt;/6s>GW7L[3qN):!_Z#4Mb+"H47mYN'TuZ7&63Q<6#QPFb_cpqXuQ%r + .?kr7oWA^V'2-;A9=1i6Pfaj8cU[$@4d7Bh6Am'sAOBB&0Z\/S_O3->p>Bj&7q5=M9Qr7FS + K\UK8]-la!Zsm14@q:m;)JS41ib`F\P`G1;G-9cFVnX'I6(@Z1t74@'f7'jO&ORq,P79aoH + 4ch:(('"*u.jV7A3=3U'7f,W^=u0.c+ghe@,EY + g9@]=H!eFE1i]Yf6&X;0I,?-9qH!NdA?WD\%LK;rZD0Ei?[InTNh."qC;.9KE"I!^JX)ik!?C*lqdP`= + /=*9+U?(s#Q(GB1JB5e&2cFuZ4_^[[(tYWp + "!@Y6:^7fCH0(0(NqZ.h^Ik5mH-#SYj'-Wb4a$mfES!TA_@e_Kl#Xe,?/rJ(QA,Dmp@sT^Z1QHts5Y[9j4qp!JNTFMoYgn*ifk_JDNQHU*6B?l<5COf;K=I\)U+q&(fh:A7 + OZ(U9o]9tUTl.r,1sZPZUMYMV4s*l.dC$ZK@Qf8U4']6hK)ubYfbPc4hdBF+,%F\u!\K'M> + F)^[OCAYc)-qraFs@k<6Bni%(hnkYs&aQ&8[hW=3Kt_3,8U*E,9e_.'f$oa>>(4ZPbi#NJs + m[i^(Iom=P%"1i&R=\[T3+MSH:*sDq8+e4(2/\.($[G+tmIm:S'fPAAM&Q!\\"_dpn#7F$Ic_`K.>%O7D1j,(H,Lm@N#ZT,K4j[U#Rb@4>X@VYM&Wg&%G91fY:`R,X`f!l9@emkIl6s-EC_f)'u?"f:2jPjnpB3?+_Sh3NAS25.,Wc$7OR;+GE[Z3L?pY#F63$=/%@6ifAkH"gK82Km@N@'nK'TWNK\pOl + D@lUTBoY)OgNN+PF=N+mlYU9F4p$.Y%c$jH9lI?aN5?SQfPGRG0sfRPf>(EB&Z;@M=/Mafr + AE.,kK@=3\4K&X%?JTOY<^]74ucJg.gtFdo$HpM5B8T68n%KGm0$_fcgm^'f;*GX)qMUYH" + lcauTKVC/#N!C.Wh0H>GuCB<-h;ues!We!MUbf_-7$bHuI%dq';A;&Y'rWi\SW#A35-%4@@6/!XH)a&3&R#b!:g+J-jBQm9 + m^qb?V$iS@cu"^W[\8bZr34SBK.3ccmHYc!8lFSD2i+eV'EO3MUg+4*DOYRVn7Nl)I7Lp*I7_aJ'/R_!e#jL]o1P!O4bP; + fj0rtSX\YE&Ffr"m'QBF2Hp= + (6E/\:Ytdf$a&S`cV.K0+MEWa6km(Et7@\)c99iVd-FFsDilj2it(,[3XL4J!YR\*!bgk?P + @s*^SuGJ*7r+k['&.Sr;ghO6I^K25(QFJdp$f[Eij*=a4Z/Jg\p>&"5f5R[u;0HLp!X`R#e + \QpV2H+siW4_f37^+J,q*F=XO8g#TlW.)*mj*p"0o]pfWj74)%s_;677hs\D<*eEr)SSfR= + 6UCeonN^USSsAj'+7^Kunm`'`:lT.5f3rEp"h + $(PUKHiH\`?L6*r^X:=4B3J->l-!.]^OaG/Uo\E6i8^S'LXmc"?1YJEH_<>>LEu^Hk$.4'g + /Jl@*09.bJ\lpdJc_R5I_k!%HIR<668A@!1VNr9AS/tkuWf)T=r7Ye`9%#j?L',hr4R,dDd + 5::?"Y'S$hCq!9/PR+G,t7!YG`m6K+$YF?Ui[M+$?c=L;Bh)3%,GOkB;T5p;@]i^e>Nr_Y+ + $b2MdqFJ`J$R7ub,=g[%*3Lrq.PM,U-JO,u+k`f5\eUVcLV#n$8D).)JWDB!@=CO%j;j]<* + OMsA3I(cdP.u\bT4_8?#\8@>IKt`1>Ct7i/WZ43BAZo2`[O(=(\M_&elfrg+NYc95_l,OsA + bteVa\RX@&WJiA>$7/sH//+C6(u\>o>(;]0UJc-]Ch#OE:708fh")k?+/X1\_V/tS)*^E[D + A7[G`_V@+%aT9EopG\"qDB%_r'uD)5fNFNeQOSPFHnck_tt]&XMa9pTZK?4?NO5It,'jo_L + ;+f2(6?B`1tkB""WB!LF?#"TZ7j1_02Pj2;_-+4,$)#XTp"-ON2%N#[=4nC!186`=Bs&4:F + O7hS4p1esT*Dj0IX77iU:(a4KIB!T*d=rQYF@VQu%%uK(I'ZH%?JJ:09'TF(bni?^o8+KlR + -bba;:3`BYM_M"W`#4M"aKkHQ0MEr7fPnZ'@X;W\,)k(Uc)oo03"49#k;lAE[-p+Q1Xu._: + UB]n5Ys9P#=;7o2%N)P1fY>X(A)WXQ&R5-?SPHc[4b.O$<4?,!johO9iNc#TZK@<>f`O2Ns + oo\53GQWYG$i4RcRS*rChoF$11]G]T3u8L0$t.G_K5I7:`&nLeWk)[#D%=::!XURqc-8Z^0 + &@m6ajES!NQsDunQ(GR`H8A^>I(2c\IQ?+4t6G[4kAk2EhKF,j\_pX5sD=77_9[T+hpHFft + tl=jfQ(1`=D+d''-"JKh`K%j^R7Lt,D0jLTS^T[P;!Pip85DZ#;=RcU3n:W3"IH(D"GT[+)=Xe( + dQ)r='Td.(a8N7_Og/3tbK5\+(N?);,?2M9>l=a$hCt.K7H0W"sk#Bm%+UB)(+=fU%hp`YW + hZp;n.7i-(\.LZ0Xu+\LcT*\I,kFM0^O3Nd68s$-,TB2'EJ0rI(J#7F"KK_4I>QQf0D'Alc'%KrXD + Cp"%9_C'3:M^rq$!LOL2@#'TC_(ob1Q!,SPmP2*qfDu@gEA;>6-2/3agC6Qh2[;%tNr_4br + ZQYRL^AdP&E]`!@Pbq:@oQ<[0lRuhA57ub$-f7^<<=AF6%k>YhS@W/XeM7X@o7Xu7OYS3h0 + RI)E?6u"[sUN%9=Q`%hDkqAkRsYp"cie4$q@c&+&*]pGq8#A,'V'Bd;36MY=5Lgp>Hemqup + .Q"J?>#9!ZUUBbj=O9Lr5]PbdP4*i%56%cQ2,V'Mq&Z4*JA_A79,E2!/;-THI.bQPMC(,M!)5e,22FZQBp1ZH + :#H%3&MtqR,r%!gaaZBT*&/TL\Blhd\0#@f,+f!G@SaPj5A0LJLh&Cfch[r6mE%);K#4T[\Zf`mPM>bp';&e>*u1Z7mRRFX![rp-:9TPt + XmdS>$Zmi;9:ae.E%.Aa2V.='[BOOJGhftc<,eXia#apJTQDW1FLR`!oCSS/` + (8MW\93GX2'=IKC[b.&Fk\89L!#>Kfg\N"2Cb.36`b%']]9m;,3=DY(*,/\4m<(\Ef-0(Xm + 9JDUn>Vfb?PdifdE?SdD;ATAcV0#I,emL'FQU6e/Xb+7d;Ub@i\&b6)-#9qb,U*bA^%RZ96 + gbC#YeL;(aZrIl\RT31YO!#p.Z28>m(FmAWma/7P#e93=_01_?;(i+*(8I-KSr*mZd9D-4j + Ah.n,@taY7.m&W6sdN?Lje)\S@Kktcjh`u%5^A$SsmD=ItRoN[*`r$G)PFQ=T*&Lo)?&G8C)A&p^]t^0N,Z4d + KIfpOMP9^;.Z3"Dl>n+X\$6fd+m*O]T;W*l2;4#!dS&WT'Rf%YBLTA^RnTao4(k3Me% + up^5/riYsa-`E!3jb*+\Bi\\cNmKShfMFX[pS<',&j.#@J/$F\_kNAq6P]hFC=`8p?,?O_4 + alsXh#Xg))N!nB50M:F/qe!:@jX38Rc,\QajOe$08V807%j*3(Ll1DbRqCnQ+!JdLA+msZ5 + Eb8l'#H8C8>XJ+=;J]UaRYl.ebZN1N5PaCcPB[G`iI9#FE402pQZ0V6egie;Q]) + ;>FC>r.M=hb==5fm:iNQ*Rs7!!A@1p$f^f!sD[a*k;lQi1A&G8rn1q.]^3.lYM(RD84j>_*f!-"18iLK,!Y15uO19/.KFS)Ok6u.jNb6ZlP5hb7#oJ( + k@q_q[o*?PE,]tZ-]Md:q+/l#f&h:$3=3_:olno1,4%k&hA#f81)+d#Js#J_H:Je.46#jo\KNb9i)9(ZDP8"u:"6N&U@Yulq4P5Q7fU4\fMF2.34V4;GOVioWbE4H]=_2_Zb<3rGf[7MVJtG6;Ehp*8r(K:#KT_rTM + W`EP"?L&LHoIm_EPs2Q-"",7MK<'I$oi$ZFkMD!c-*i'MLHDf=ai4Lg/Der0^(I"H"/BPmh + 2cm%"=HSe3L$"Come]@7!GfRlQEX[6%0oW$%6Kh;nTas3(8#dun4a[/ANMbL@J"EP?KRNak + :96@\&S9]VfHDfu9LQH,&BR%_IG_Y^+#I)RfUEd^1CC.AJ9!kZQY_50PT?B&I"686(d;(rd + V_*R+Pl-2"]P+qDL'fHB[\Qp>!LU=.&]K)!`Jh?%<7R_]ND/=q8F4nn4I46Vg56<+badE^e + D6^$fV;][:#Z+FK](,uR`hM=-ZB@lOBs"g>V-4pU(#pS/Er"EcQ15bV6&(:][EXpe$dcUcD + 9sU&s5qRn[M9H:Gh'*`2q9YpR-Jb;R`eP32X1= + YAN;ajL4'bF;l;8:pI9GGti\^F#t9aq78'h,&8gla6ZaK8U-4\= + /&:=QsNeeM`H;Ee(QA\[%teobZO%9Z_qNR^I4^-u&LeE,*>!)`C`f"fTNY]PN=4GM+$f0+1 + ,9j3D86<1u-e3*-J8C.Q8HB!&of>)dceL3tY=B5lMNpU:T[7j[+K%MfoQHh02lDGd&AV?D)f(kR)k89RunW#Dd=(&:"KldK`m$#@6s," + o2N%o\ZeHhmNC>`Vn](F,-E0N?E7sQu_)u!oMQ2?fhIJ89TcuG)Zh*L[G:QQ3CYk$K$qk#L + Ic+#^cm8HsiNR@&=IlP`LU@d"d^1LR&N\%Mdq&E"+,u#At8bDAcgT!"BtM?mZXtQ4Mr.nAJ + O!+)Cg`np]FQcsB#XiZ9Ar:$1G56/I:UgZ>Be*[[['lWUmB>0*5fgk]*U``\#9KQhn])(S,NP.Y'^dr?*]`;Q9B0VHiZ7";U-<$nAKFh"SgJ#H,N=#mh + NcW&C*;N@o\.:$@L^4Q5^uU"/mM\-ir.Y-rS:ci0pM)]j#GHH:,V,#B&p`7jNu:bk%EcF:? + ;K%j5+E\W!_Si5n+#bB&7Cc<^mN&7q@?kB1>7J-<''(FQSD+k+6PSG&,tF;.Z3EM.K._??T + tqIaY)oBCZjMH=,co.Hh*TjeuEj`'@cHQ.j<$:3#?48*O'6k?+PEIQM1ectAA\jM$a_G'dm_s5biVk?qs.:q,^2&e,+g + LT#=[(8>PUVY3MmfC6l)YfQW)&dK[L1L;pH5C7'li+,D\:(r%cj*s*#A1d<mI\-9^s[&ui9dE%mKV/FfPQDBdKZ(QbKf0d2WX9(#&G^6m1d6b^`3P@k2Nt + oilIX!h'LqL]]KqXAgQ@==DW[n8Hrj"Dg(noIe\T3BEZ-!"i,&1`q]#bq="%QE!H=2%fc!X + on?Mr"Xn-i0*-$)!cW>an:4l$&7:D,&o_apE5)hNI^=dEd,E"SE5r4R#5IOEFq"^k#>f,S* + t`L*&;6.nE0+Gs?Pd^S")pa6EM"6?Ii.0?Snu79C&Q4f@E&NhGm>25KSX5nNg\t"Mrn'!l, + P49i$N.,+*(s\`SQ`jrfZi6VeJ>5kt`r&QBl/9QZErqA>%<3?Rt/kNpO0KW@aq9qBKh*3:1 + nX=[,%&[lnfJ>Qq'0LJZ@hpiUZH6M'A-eSqs7\BbF'Dfdp$oS5qu*<$BmkOb*/FLYQfS(0^_#7P6mdo4`3VBjcbuZ!0_:io=b46EFnh25I + #:/kI1ZUJB%2Unq2J6a&cfr2$A2c&uSs"/,5NE<=A1qNXh_GW>F*=^/EdhVDL3I]^-#C>%S + YnNTLK&AV<;1o\p9_;0.oP]&"d/`g3dIanlGMQ>Bf[=m9:j<4toS6=e0[KK+8* + F6q`Bact>J#-Go%h"KG=RVee;O"ONLWLFgkT7,Dd`-+-$K8C@lB9i(R'_hArQIspA\h8QYL + ]k`cCk#k6IIgBoDhN?GG`;qop^_oL\BoHGVL#IOGNdF + us*FOSk4g#no`(lb7tkf1GR*,"pjQKCMZ8d@nlM-6=8/KeQat#cNr,NZGm,u.J%^Qn^8/V, + "]/$C'mkUP_MB=&FW`gL^Vu_"3Ldf6Ju?]kJNqAV^_$RN%"PPcJ8b[B0E_A0( + kN#1K]$HqjHAimd-@iLaY2;g+5'4EgARr(rLB"(3,=I,d=r3PL)8Wn\(ps)ir0KnL@AE,+B + \p,=ah1Mr[6oXXH[hbcf$89I`L[Of@kuKGR!l:l;-dG2spU1]^+4sE9Hb@=7Sp"dXD/Rs(C + m%QfJ'?.XF%cRs1[76Q-Bh1a'G:WSKL+QnBOiF/iGcKfnMm=F/Jj@8@Z^o.3^!k + 3_dj=fS'CaIPY,F[#(t&c09O>Q8d,<[K^2aYdOa*k_\E-Oi)--L;KjDoNN^1TBqcffIn!EK8Cg=-SJ:"Ba4%Um`)93?5E_4<6I!m*3:AINO]Q+.7 + ,KUQlPa&k`oA6W&bG*qk^8m.G'?C^Er4tsFm(G'r'+<699Tp180Yu1Z+Z%B,CH2bi$O#9E7 + _uJ!&^Lpm"$Mdqm,pU['Fb43^bLd[-+e25@jfWfCRZJerJP77EotWF[8b3oJ9dl`r1TY:GsU-A!C"gJS!N#D4N + <3M^,Dn4&f-K7ToH.#tR#$'d[^%(Ce=Fg<9H!XNE2Ypp`r>Rb')\oeOWg>^*=;ELsY])1@d + Zl*Z#NeY)klXCVkMMA(5/Is^.57;ltn3,U#H=07K!M880>2.FL3<]jRH(rf",jI%M9BWQBH + [i7h?Cj8P4fc@TTgY%U(S*('bb0j`KS^U@e96/ndh=W%QGq=0:F/A,a!E#c@?jamVl@?UM0 + 5C\kZs2jO(;2t?-`gblCl=EuZ`IYKe;>lIDK1Heg$[\,\JVA;MscU6mCfZVcMXr!>RiaNE$ + 1:&_s]]`'ueb76H,40S;UC8[!Ai$bOZD`G-^O.2L`5N.r@bf0)@X-;p1]Wl/%XePbea37,DqtM8^]u%WreoY^^[g9cp&2[2g;LPTnssk4L!d(,I*rE*WIL!^ + "rK,^'OZRU6pP>k"@t'`@)/:b6RE9fA6*N`/0PJLN/@ig9N]8E.5&KO()I5pUL&SCH;MQ&-h@@XX/*2F + kMWiJj^K@pHip=(>;XBoC.*1S9l#L'h%FI"68n1RFEAiR*"98Xk0.)=>*-4d_9j$nV>)7*d + :jF8n8\DNjTtCPk-j@abVDuEAknm@%BVL;ls4lu.F#$:k6^Zee8#(ML,Z$a%d`4;#Tl=$4C + _+ljkVFVPa.Yn7.o=]J&ZCB%#P7(N*+fl[k<[\@oGc#46%>*WQi##!"& + $,a'DglJRYcM0Ec&mnDXFjN$d+R-pWI4Q*!i4S;1k7Do0b=Xd)Ym=&pV9la)ME?ilA?Rf*+ + 5%$,o`q>lYr5X(V_.5CJ"Mc/SN1M2&bZ:g&:$CI5VM\$*!9RpZ&A=IVH*S5QifmX\Mc\?41QA@jRm.Y.kUNq;#e93H3k$0%MUH/jhRZ!@d1*i&7"Ee;YQ#V + $.73Epf/toJR$/.)/MS*Ba@>4?6qY-MpB1kCFe[00;?qd2quqQT]1rp:Q]DccE,!P% + Q)"XWnMM=JnNGq31h):FR"M^E<.qHm%`I:',Lrl<^h?Z5@\hnAda#N>SfO7Ia,c2%B0l2=t + mp3toT,JHKOWkZ=FIp_UAs2Xs8?gmuDhu*ND!<=eW!,r5EVE!X4i^jLO!72SaYT3c6+Ta>D + !cQ/g#g+_JK__Rpq;bTQ0I[+n5m/l1"E6p8YY>8i;$AXR"_XS2,eEto=U$Qk#&n8\Y\aU6E + $sh&9/ + !fYmh97&J6`4&TJ[#YoOGH+VHLU&of?5Yq6UY0bZ9!'6-#GYrrcj,3V;%NhBkpj+n+=Uq@g + G'k5/gnQ`^L4VfP?#I-Q1Z#(0bUtE%Yp1)naLiX,)e-gCTVMu._!/+G]HDbFWPo\$XW9.H*HBaQZ/$Gji>s`8*c^EcZ + 0`V&nK0K'AauKckVsG7ocQ!n+E@c2Z4.rI&Krmh)@[&8D%>[,N?>GOB'SM57aqm0>R9=;'_ + 447@,W?i.)4`L.G,(S9%U;nA:C]W!a7j9A1Y89"d@5]oQ2 + KNP?ZMbsT'fNC?A?RR3WlbXB.(*JE/7A95VV!J3;IC[I_9)\G_W`j!?>udZ2fkopWCZ[?RN + ddCnL[-I1V>8Y:*P6h4CP?SZ`?4[d60;94_25anFJ)Mffg^Re4IqTa=%-Bp>Jcl^E?"<79J + q&q@URmAn;ehZj`S#!'[aN6"DArM+er,jZ`$g,(aJB!ljKa.3dtR'pKS'Zog.f5nHp36hEr + =:J^6dObcLpp$1qnG+cAhMlDDO8@mKm0l/n_Q0]n3?Qc9XORLZsFa6VY"=GiZNj3kurL$WiOCg&L&Z"FSer.+%qkB;KDA&&F + i1F!E,1>9B,=$TtOCl7/#P#<+a$0_4oS&b#NH\W*o%EX0FfapP)"qDcU&^.QeP(?'.TM^ + H$1W-biT3oGgk6f-,*`+2Pr._\;,?jK)p5iG@OXRXlV<]0pF/!9'9ukS!FReh?uH1pb7=!L + $"5).14nkb6H0El+Mpf!"I:J^79D1ddNXY*C+X>t2+@\@Y@KO+7?nE:NcZggRNdP=#a'Z)/ + NY\n.:dU5Ap.m#XW]@?:K'/gB4MN8Trf02cL!De!S/Y%KBhJilrL7:'Buk5i[>DITIb2d&c + sIg@2VoXGr?9ctgJ62h<673K4OD + BI4)dm4.QlK1'Eq].p"JXjMTn"\0_h!biP_ms.67B\X]SItb*/R*$i0Y^Tm<3_CL3REe\85 + !.18MA80m>^#`,U48Dh$:LFc0!t,0+$l.!G\?pL/MOW;7G)U_n^M#8jEW%+@N#CPs?IMg0i + V_W[59-j=k6hdbrN,0*3*-q'`r'R8;h\DiJo15D:^_,=R7e:+SP1jbq:)r+DN*eN`M-. + :lHAk+i.WL/`.2U;fR`?]@/aH-J-E&bKHki + _!F^\<;-]AqrT6^7)\bsG4$XibqTDAg>,2m&*^dcicPZ6(6[#7Gn)'\([k,D/"* + M615I&DC0-ca#md0/rB[]qCeZ@;5H:TNg=ga>$N0?7@p5&KuTjacB?H$'i!oT>h"AU["]cI + D-IM)V<+$7Uhrfb`.VOR,(R/%VP?\]8T%rE?+Plm\ui"-m>!8(LO-5%$1R>(S0E%V/8cj[M + S`E#.L`+;(5C[\_@eokHoei5Pu8^q+r#XK'AE4*M8],UP?6J,$[G[R]+)"A&V*shN8 + j(c)\]&;_a3Gm"pr#`QBr;QSj``o,CrWMT_YX + teso-EVUn[f673Sf@[*/W,%=Xm$ICa*Xh;8g]mJGG[5FeM*PL-rP`pPI@P7$9',q!%qEmc.^?,J2d![kf>RD:$$W-0,Z^ + 0F7J]M1c*iO:pFPe7p9UIHIuNd29d!PE+]?qr$\2AMiX=:`W#hhtoR3'qZW;9B + ._-nREW#7d4K:),hoC4$g/'+U2&`hOBF.F3=j60$)0j(#[RS"W@',&Yu0"(pRkFLX;nG89s + )]X`?I]HZ*Ub7fl[*BhmM5pfS`+nOU1>sj?V6RQD6/%=jrHBa6LOD6bB=fY@g2%W7%pHI`V + SFt)drAW+%4-[b%/t46l(rQSe.Be:b/8gB!liV!4$od0eg0IM.]rg#W"jFYQ2a+Er6\!?dW + %2?9/NVg*cP#po?nRt_QltXCV&Z42=hi2K,'eVD;0C^4-?*&7]P"sTM#/8CQE&T + r=c*19,MN*X'S^)c2"T>`t(iYSfH+OS:3s4eh(Iat]pU?UJE'!*t8Y(]e";Qk_[l7?bE$W> + ]2>4T3K;SL%=2u+;TR9-OW+sMPekAM#"mpA&FKB.Y$]]/s+_DTNS8&?;rl"=+G%.3/=nSNY1(.Q + U3mSh`n60V,/mZY-BdCJfD^pU67=a@jt(fNlTZ5+M_!R\(gFhRYFBI)jMI,YjiS@ + dSg!P#la_,*KkqEss7AFpI]j]ON>9_T-EH^"$CJ&"L=RmZXGIoZ\_XQ#rUM%&=_U6%+,E1] + L]5nortXa1Yh1q.?,ds-`]Y:<"!cgOC[K(?+iE-/Ff\8j_LVeq^EiJYYs^/t$YY!6b<3`B8 + OJ1&OA,o7-:RG4k)VPCgc;4+Xn!%!S)2ND8=kQE22/#S[aT"_5C+n!RR5TsY#2BnoE!tL+m;,ot+@tbPL(_gEM7jLhidn(b'bpo@(`+ + 8mB4[ctE*n0EG3*@o8q@Y"%i0@5'*pmD'5;#EZ@j8E2SKr?8`>U>5ulqgfn`nHOQ1QpSFoiF*K?KcAZt,j=#3/U!%D#V@c\@sI,tO(7ti + 6]ko)-;0P+YAKg(g'\nCQs^"SA!pq/DGQa6q8RH:?].?l&811GJn8V:TE6KSkY^$0=OXOD; + ebGl_5SPm_03$iqS@6T,;L0eIG\2Y_M>s]T#u`o>=ZD]8:(Ga2h + oD<8oAA:\EokN.gS3Rm]tdaPSesg2-G*Z36a(8?ZG*U'>ubUZm)RVlT- + 0rl;A48fU1*Ps,Qd*3uF]M`&WRIn.u\/\Zh^YnMV;p%]b!#O6l(+2S`lP%Q`N@?s46!**,A + J:LN"%i>k\^aok=6pQB`F`aHZU6]:;RJ!PR`'#6kXT@p5,!kc6+e]JM(,1uW3RE@*+]8k2K + `,*eASc>0`#"/ief-u$E=QF,4,8h*mZ5l5b1pbaHu;3B\KZA2@T6!WNodJba&)j;kUDCCG[ + JF1#1S8+Q#Z*i_N1B>(h$72+\:ZD&2B(]@ebD3Mo9b"V/S]UZ6_p"'j-G$R["Kf%0SuB57j + Ki+Ao^-)s;Th6-p\PdXi\XjSh0%=):[nA9j?$<_H#00d^G\S!/OI+-m1ab8->5P`h>24SYL + hUN"MDKod6Gn..'PJDM)lL%M7;<-j[)C/mp+Pr, + @6Qb>TGjB\b8GbfNY8/9s=B-Jr=Z(#:[fJQo85Mp\Lu"r1_6fq(KIn=G%L:O + 9eP'HYP_2?O1lP<:TL3u3TYY36NS>"Sa$L[[&Ue!0`(&?Pd[731ilbJO0kP7PS$S4A:VH>2 + .&s,7[$I#Bc-^D`/Q#mZ[^=#(Uk*!Oqk4q/,\(&!"rAl=$5$>2JVq'jBo7aV[6kMW)Zg-j/ + l;t5J>NDL7oUlkNcmf3O]O4(/!3K`FY04k'sR\BO``+BbR;*;abF&LW2oIN%- + EK(dk!$m[=\[IME0pYiT(bD'0JX@"o6A,8i\b*OKjl#m-@6k563])E=OZGg[?B\0=P/h1J0 + rB'DS(!gM:DFhbR1([A`;4s^C3;A`;7n(abseUn+aL.l@`+;]!jbpAH4%(-?E``Y;eCr@=V + hp8csck\(buFZ\7kFA7ddL7B`f[iWTq + Soi]r(';.`r3Y4Ir%+$6A%:QYjgGEeqM`aa$(Muhb9pOYj<-<.9+X8@),\RG)]b2SW + ZY[&Bo?c(DQ"G=9GfSCkiO+L1kG@^?Upg3StL_YEfLonDM%#k6Nd\_GLY[dd%Iu9Si=]7ru + pHNP.p5Qmh9LJ-g#g(2K]Uls54*=gb(RP%"=N-XH,sja;QKY$1a'N+u6*RqaUtI61!TKRuK + gC]-0H2hf)*tG;!&>H(Js7I".:LITO]R(P5KRJ!oqXOXeu=$[m6Q29pa3Xmc7[@)hBf-MKZ + ;+D_\\m6js,50EX]m=fI2_`(1KY=tck6"qskn"11W*:e8O)@AY3"WXscX5mA2=+>N2Y,@H( + V`)8h+OfiAO,.M!\#[4pK5t-0'3i"kHe3-6Z>;iPcT*)16]O!cg=g1FXL`1$Ale_`m@mZku + M^+r?OWZ=8#Xm%N517CcZ>h]TK`ZpD6O3^g10MG0(PkUO`sZ=_]O&W0F#\PMMkjOs4E`R"> + ceCt7r3H5K6SpqZ5t->SM5_qE)J[k@??X6]G,$/#TLi8]bW-4Lf:b_gkH1<`^I=(RlRi3FE + ts/M`/,q6BmHdCbj)EO"sCQS7Df**082lWOtjT]:-\blZ@q^#ZDe#)jqY, + fbfi$M\BQg/?hf]J\mNuLK)@t]ZMt=Z:%e,apCn'jG4(@CJ4$@9aoED*7>J$]h'/@M-MgWg + l3=Bd`m*N$R4`/6a`8MHHFMYP*uW,`8410hZtc"J2C:E5eDrkO%P4Zb1M3=0cRb%^V;QdcOC%S>m=,B#7==?Y7(S'g*6^:,RjVVd)pTjn^^H + 3It[J+#TKUr<;dGsY>6$X2.OHaEaI)(3R!S-%_W"$9CR`S;:2nZ%Cd%B&?`tp>V`60\MXgo + *?nB5,>pL]:lOd7fTshHT?dB\;Mn*YPE:=\ql%B'Z4iRWP;*EU67@X[dg;ErM^AorJq:SuN + b[gI/H%#UHAkB<#Z*k:S?.:d):Fd4;p@I(h$$QsD,?ml,W$O%m$H2_6QtBn,\2?c&1SSKPn + oc178Zg5]"p!q:_&Hb#Sd@c#V/*d#s\Y]eI>AU*E#H[e'nP!eOn&bN1disWmSoB^)4.#F[F + VY>?/@AKp1.DH:=^(,]K_U<*ZcKo#RBX/T8 + .I;5bg+fq>hdY2Ad*HG45F&c4Q8[WWk=Y!OCh$?&5&l=Z:BS-RVCsTVCUmU?\Yu+$AG$"Wm + =:Kg@`H93JJ_2t1f5W:"+O^W(3/B%`=2JS[FbNpdMcdZO=N_3'oa019NEGu^=K*b$TRo,\N + N*/0f8te/d*ErIM@63Z%98Nn"e&SrRp!>";H5s6opf1Ko%BEZQ.\g'Y`7=\JXE]#V+?Ks+k + YAueCk(u>)fLbSZ3lFN^_Ki>-4n63lhIc\d0U$"uqNEJ:sSDDP3pt'bt]nrM'W5CP]rGgBF + ;WU-"pRLPR)sUgq/q[BGB,[>8X@a3#9UXbtmCL^@o+Uh.8r&E6pBEnH?JgkEY%=VTXn!$lu + pgs+)Kh9He+5;aH.>j]oFBj4fSBNOklg/Y^!NRLI]>Zib7fg(-jd#D4:JR*e^>AUNK^kb.8 + Js?n*?1tDO4c1-;b9Nj]8N:Di4,'K\OL0FCX#j&\S7;`SHJJH!8cM:c&ToB>+_^Z[]Lo + '4fpkE$%T-n4ROU02A-0kg3>7jTkfnbI=+FfD39O2pGLhi5^%ME2&'4Ele==ht\7M](=on\ + `7?\S.n^l+0Ek*W[>M>eHM:&0Sd&VuSTO[/"6I@$rW8Vk@N@&\)iXchWKLY\&Ci$l=q5`"< + 5U]f&2=KT*]IJ[>o.UG0!gO9pu*\q4X1CIe0@m2bXl18BJO5SrTinBUME/*9+_2+rc@#0P! + pn-PBMV8fP#_j`5(+BN+h.--fih_s+NSOj]6jYHWPmG(g'uC41=n_(+JS/"'Lb=bQn::nrb@HotB$QVJ2L/c/Wp"&bC<`43Pd$#\X + _G#@.ZGb!7^(c/FbhAu#[M015+^U`X9a6XfCl`7\;B=\$jj'Z`7?$p#-!J4X,%g&A?L:Fk- + sY/_cSp"R@_An-H"u2m]e$^#NgU(D6<-FJng*pet.q-G`5[p6%B/2A9`i?-ie)qQ>5P7CVG + ..W2J>R5\;(7?A=d3m`KCLgMOW/m!CMqmSRi?l^cR?g'*Aj?GL($eV8dOjrg12-7e2T_2<, + $OVj_VfS+,?ent-IDU.WL%F9g\B^X]8@(o6>NkgHgc%cR]gpRCm?H[52M/,6FO\h%oVKRfV + cfB6s);a'S*K'4_o&&[U(odmRhWsV8")pI-:hH2RI6ggLmFABCcNW8A`fJj@Gi'p)k]VU\D + A`^l[LNd%'t3610(k2.#L<$%>Cf@P?2*h0N2J86A"\le^AmZQ_MV1MS[T/pQ:Y7E(C5d,KB + %Ztr_2a_rU>jnE_duR46JT3Z6(88j)3Cf>jCN6Tke=thPU$OAgU.GgMk_8muWI\-MiPNcZ7 + OTkCAOu(F&7=)i@CK@0/Q#7K7DC)/E:unu"Wlh`aK;J>EJ,M,bpC-PZ1=kobFmka4hWTShE + B'3hu'nW*\:\BGu%V;^@ngA$Wh(JBT*\r@KbAMHjj:6Pss\FhK)l!UHM429QIbgt-)>?=/) + LsB=0+nJb[F+6Q"hd1Hl+7a7TDZ<"CNtcW,?ZnG(l$$Z]?Y4It]Ppu>9jH7+CtEiSCD/pDG + /%m;hekrLX6bm4p?uu=%rCt^F*Bij6+rgkm:Z/hG8T4XpO@I4T6`VdFkXlZpTJu\5Buq[Is + :pC2Xb=(%tYJpIeYRLGYa#KpOW*HLNn<)G`R\Z7u$f2Mg3!qGgD@BT8NF$O*L\dGn6$(095 + iMPBfBWGu'\dhide?kl^]i"8FU)_p\@YRJF%VH,#nq\"7lkT)%99H4QZp+.rB_TmAYlH9\6 + P:SrG.Vg;^JqJWnEHN1/F&%-b&[X3M3 + qiA45QahC7]6g`oH`+Q(^V0LMs-C%6$;eabXKgqn;W`HV%Ceb]N)`FH2VCtA_sgK + uW4;IpHEJGMVESGCDbpf2qXk"bX[#E7fP--P_QZ@r^/tH2WPK0s1q1>eXDsS'>Se3W/#l4e + ^;;o\(ldQW'g4CNZ*E?H6?WfPL99?,k?9\)$IrS,N'dHc+44S#^@\-?=oQ+ugQ;(I+bDl?# + )C5/11(g[0334oXVsKWK!j3F72*Vq(,,H[XcNLWANJqL*hMJ&gaFqu2(YC[q8802($f!&+r + U&HopH>T!a^d!QuB_GHaO$Gt0&0atrrgc5k^d/60@`).LG'#`0[;&$c="9ANgBA3.`0!SAi + )TL1;E?*"rgj's]dJSPhM$[dsU+6Y"+0/!)D"UmQ=9DPkdMhe,99Hb>8Q9(X'kc%m\NA>o?,Ze9 + rK2dSubd9%)5&0Xf8^K^hg`6cCiXe5[M\$W(X"\O4b%/Ql-)eU:k.elA8T>1V6;EB-T\S=O + !/"J'UAfN'#KVGM8L;,g"Y%?"iOepX6*g/acDC>.7PZ#&/qh77F@Ps(=Mflm&1Eno80d<+2 + G?.jDWf6uV&hH-0aE$(3i@04XGAa+[$fDYf$i)h$,K&G9F&VT+F>8)?:8(Jh`9Gh@jMW3:& + 0oY-phDpVVf`"0u_RHrsP+PCt`iIS\m.!g2=aje;AWsbOREiu&C]J'#DKD9/fuAN4kZT$aU + ?L;pOI>0t2GUogQ!15Rk1OpAWp81'HO+C9`AUk7_a_J4OddE)=_`fM\#Zc<9H1De]'d>;k1 + ^akZL$i,h6h0*hYFnSg\l&G:tO50MGXFEHiqTF\Okoh>>l!! + dRs/AmqGXXplLUGOj6()^e+MpGrh$%PPlAC/\bht2dIdBE?eP.M2E\HZfmX1^qYo"UcMVOt + fD1_T/tA@Z[ncr+d+NrqOd81DYgqXQpO@,S:;?NN!)oZqIukL`^kFiOT.BYgd!cNm(duGPJ + qR9"mLd='<1i)_p2/%7E5N&Y]1 + o,)I6anop8&&g#(P-QQTRGEaiE+-63o-<[lJO]"jQ82mRtS&C)&nNL>S)20d,,&2>#&AH#< + M_aF'@s0Vml+5;dVW=hm:Cp'1'6\ELB!QW2"TDFreF*DF*7^QR\m.4hRgkoNk>(E1?I%dlX + tcdrKG&npNK14QInhRX%3)B0&te5*'7VG0_Vq:2!>mRC$:Z;49@3d( + ID5cMbXXb!ekD/-KOFLmgAK;b@A=S!jhPgs!RE)Xn;$7e'[)KWWSNb<;;k]d.nD+3BX8`!i<\QB2bjJ<[Lg=2i#PV6AbA;Q*k?5 + fXMB!lNDs9oTIR))b"H-+cg>RRO-Zl1YuSai0%DG1O6%7W!,O]t7&5oU/qX.s + 1&FZ('uA'nXSl]k"RL#%8C=?D> + @BY_"XP`Zfl/fjslAEkskE6@!.+_fR5lffS0PI,nqBc";("lJ65=@u8aB\F5BKe&=CmmhPR + u(fEn5ANPa+N"*[^G83KgEI8)t,cK@'RGruWm0XU[F7h[X@f]AaRmaM.ptE%26@4`pP`I1. + @gQb;eXH)?_kYE;A@Pa0RrbAlXGPr:;HP)uEa_^tc+<^N!f5U713UT=G97K8!p2+`@4/Do4 + %mG9P-Q*^bkZNgkBTc<8iE-bg%KRQN=h."NQ/cQ(IC"GQSrleU*c<\bNR_oWQE/A!#eD!kt + FaHYV$j>])Q/S*JG'rILt.Y*W"dLZ`K#>%'Opm=(C&W5NTj!OT`tIjiQPio,M,\!!;e.h#p + I:Gt)rPThB4&SUUt>cGM`)=mP'W[q2QuhA + FD3f]V21u\MNG4Q\"jaL"%i";sJbZ[1nT"c$PGslh=buPFf[UqSr$m)fpE!0'h!!-\_'H*G + G)B;rToLHKU.FAoJ57i;5@9^jA;fp^Y"!4PuUjr6NJ!3j[^g]%HQ;hoPI'X5*0YQh>dfR + EWO?P"jE<"p4PL.7^VnTJ&g9>-LrIo"pmOJ*1r$INHe,kg/m^io^n0sIOjA8+mOQ-gb$78U + 7Y9n)q6=CC%1ac,s#S?tU01N1hgeQ6)$aElBd3qr3pD)(f@5+ijk6DAi)]"QZ>75UlM+!J" + DC4iS^0sdP/+=Sb:6MlBp2F4(%]\>[`>*t'LPocj,'OO4!,Sp#YYA"2:$T\jb10-<)Id1\k + pVInfW>Y;e*U9W&N]2Bppt-a#fTFQ`lAo!kgg;h(lQ[cZ&X?)-Q-ZA!0Cn#,&\ANT,M^LMU + ARS;6q3^#d>g<'i2:@WQuP.D$-\7*26j]huJqFe8gSE%Di&6ncl6*4rckMB;J@K^UuFmG+j^4D/\ZT@M!smD"d4]P/aEU<`>e5]cr,%5Be%k(Cpq1L + PNgEl#dij!:$m;&X,t+#RN.nE/o[mPJVX3o&BHM`@<'ZCoUg)ZIW!==DUII1*VE37Vm3'65 + Qsu&b>BK7ja2$4X:UGWIV3R_+g^sP%P)CSNs26,ChdI`M6E;\YA2cAifF*d + +-I_7HS5*P:re*\i?l<+^;$SWYe'E:<3"$ffj5a2XA`>LBa[m9R%6'N#uq1IG,#6^0Z"_P9GlYZKq48]>m@oM7mi;ajYe7?h!7e+R,XN,[_Ea:qoLe8IhkF%92R + 7u0YNe7.BgY\HX?2fsC;e;m08P=\`?8VRUB&TL%PVaPVt8X)q@['*+:ZV+9,99d"g9H7LuK + 1j_79U*^oeB^i'dT!8B_=Y]@<8UFbj%`S::6b$6F@/gQo1r?[:R(`PeG_U"lr>mu:_a@7eI + PLl'2_aF.*.R#7JAN:),aH^;O&b1eLsQ1*/*m$;\_AmeN["J6W@#,;anY"F[oFH;cQh!IZ`YD4&+Cu9 + _0O]B5^dVHBZWf;g(W+ZCnsXb[I,VH + \R)\J(,btne\PU8`Xu4o>kPr@edl&Oh-;hq"ngt`Q1c.4+tZ*I@[6Wio%<0[WuN:;e:+G@Y'gsekW'290W + Yc7LpH?Zinu2=GLMi%:8V>W(&O6SEGEc#M\W@b1cdokd_3#Srb-B/`j,K%2Pcm3Y0P"4q:! + J+\R(s?r!S9G%0'HTKHeP)g>A.;n%,TpORQYC`6B`/ + O>/=f8k2$drli6%6)E]TNcg\UNAiUG@7h&[sfo[/Ug01HXWat\%ZJ+O;+GCB/dsB2pZmu4* + j6HJ'[U5\)\1Rl$J$2I\q1;(\hUorEt/#AXCaIU>(4%?n3'*B/dI?@b$%,D1U^!B/eRsGUn + 1Z0mp?C/GJgi\%RG2[V%ON&E;Gj``[u3fl=N!K&YHSAm%[!]7n7AK>Q.\V!Wo(D0OWPG@K< + N!1%2_Sh7I$;n.E0Q],P.?&6]iAXJW4Qu5j4T8D0>MDo=.B+TiBM0/DrFX%-L#%riq`Hc'. + H(ri7pMY77fm8>AHIoA4pP+qWd>d9kIohk5Q^KP;m<7+cI:CfV\)2MkfnPk/I_sQdf>2r]j + cJV;JjS.Bf@=lnomPGmIKJ,RQaMBRd?=7qHm70l\':,h!`'X;/U0&Qij4m3B7@@")H\#/=< + Wlr?nHVH;n+E55gt8#R?o7'Lq"=W=@JSO87pLqR!$Z/R?*&Rc%otERA/)^->/7Rf8Kk&RY' + (WK^kG^I>nqt4i57/H'sBgdtlo_S0HLRAFH%_du!kB"5(phL8UT:`K4XmNZulBH0QtAmS;E + Q/Xc<2\>>a!rap-DNHJ0![3&>"$5ja?#b!iMg-)3>O=`c_UmaND_)\>.V@-R$#_;ZG_V,RT + A#4^JVLmNL>$7WLX=P8WV]%W*!lq*fl)122V#`TQ>$5`pfqoo%VKuu/RW#*t]rFEK)LAH_H + @@DKK;`3'X+K%6]"b3\'<,/HUtTJginA4[LT3YRWg^&f]!*`S\#Z7VX5M1&2S:W1\.UiXXT + lJ@>,El4f;N^l/GeE?2G9m8l7KU?YCbH03d[m#VCc!UVn33cg4uYS&Z".rY<'4mH@d_?0;s + 4BZ?i@GEBYpWc)$mb/XF#R3kd2WMmN7OZm`\rHE)&,5IBr+/DF1#gK6%R>Ru-`T-D[k>'mU + Xe#/X]UcWT;4*JXGf=0Hu\3er[>D\32fspluVckTM<q0H8c[ + gY]^aj1\a\^74H&g[Dlro=nN(^RP,8g],&/"2J.H^mkeJg^h4@'>[oi_42I\g`OBQ,Jm\5_ + ON-ngb6Pb1W*HV_jig+gcr^s6c<5"`10K=geYm/;oN!C`LL/OggA&@A&_bd`gghagi(4QF2 + qO0a..LsgjdBbK?.;QaIJ10glKM:!'gSe~>Q +Q +showpage +%%Trailer +count op_count sub {pop} repeat +countdictstack dict_count sub {end} repeat +cairo_eps_state restore +%%EOF diff -r 9b9a2497757d -r eb146c5c05a8 0__Papers/PRT/PRT__formal_def/figures/VMS-core__internal_workings.svg --- /dev/null Thu Jan 01 00:00:00 1970 +0000 +++ b/0__Papers/PRT/PRT__formal_def/figures/VMS-core__internal_workings.svg Sat Aug 03 19:24:22 2013 -0700 @@ -0,0 +1,1010 @@ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + image/svg+xml + + + + + + + + Green = VMS-core + Blue = application + Red = plug-in + + + + + + + Physical-Core Controller(pthread) + + + core_loop + + + + + + slaveVP + + + top_VP_fn + + + + Shared Parallelism-Semantic State + + + + + + + Switch VPs + Switch VPs + + + schedSlot + + schedSlot + slaveVP ptr + + + Repeated for each physical core + 1 + + + + + comm_handler_fn + + + + scheduler_fn + + + + localMasterVP + + + + + master_loop + + + + readyQ + + + + 2 + 3 + 4 + 5 + + 6 + 8 + 9 + 10 + + + Switch VPs + Switch VPs + 7 + 11 + + diff -r 9b9a2497757d -r eb146c5c05a8 0__Papers/PRT/PRT__formal_def/figures/VMS-core__plugins.eps --- /dev/null Thu Jan 01 00:00:00 1970 +0000 +++ b/0__Papers/PRT/PRT__formal_def/figures/VMS-core__plugins.eps Sat Aug 03 19:24:22 2013 -0700 @@ -0,0 +1,365 @@ +%!PS-Adobe-3.0 EPSF-3.0 +%%Creator: cairo 1.8.6 (http://cairographics.org) +%%CreationDate: Sun Oct 17 19:38:15 2010 +%%Pages: 1 +%%BoundingBox: 0 0 116 67 +%%DocumentData: Clean7Bit +%%LanguageLevel: 2 +%%EndComments +%%BeginProlog +/cairo_eps_state save def +/dict_count countdictstack def +/op_count count 1 sub def +userdict begin +/q { gsave } bind def +/Q { grestore } bind def +/cm { 6 array astore concat } bind def +/w { setlinewidth } bind def +/J { setlinecap } bind def +/j { setlinejoin } bind def +/M { setmiterlimit } bind def +/d { setdash } bind def +/m { moveto } bind def +/l { lineto } bind def +/c { curveto } bind def +/h { closepath } bind def +/re { exch dup neg 3 1 roll 5 3 roll moveto 0 rlineto + 0 exch rlineto 0 rlineto closepath } bind def +/S { stroke } bind def +/f { fill } bind def +/f* { eofill } bind def +/B { fill stroke } bind def +/B* { eofill stroke } bind def +/n { newpath } bind def +/W { clip } bind def +/W* { eoclip } bind def +/BT { } bind def +/ET { } bind def +/pdfmark where { pop globaldict /?pdfmark /exec load put } + { globaldict begin /?pdfmark /pop load def /pdfmark + /cleartomark load def end } ifelse +/BDC { mark 3 1 roll /BDC pdfmark } bind def +/EMC { mark /EMC pdfmark } bind def +/cairo_store_point { /cairo_point_y exch def /cairo_point_x exch def } def +/Tj { show currentpoint cairo_store_point } bind def +/TJ { + { + dup + type /stringtype eq + { show } { -0.001 mul 0 cairo_font_matrix dtransform rmoveto } ifelse + } forall + currentpoint cairo_store_point +} bind def +/cairo_selectfont { cairo_font_matrix aload pop pop pop 0 0 6 array astore + cairo_font exch selectfont cairo_point_x cairo_point_y moveto } bind def +/Tf { pop /cairo_font exch def /cairo_font_matrix where + { pop cairo_selectfont } if } bind def +/Td { matrix translate cairo_font_matrix matrix concatmatrix dup + /cairo_font_matrix exch def dup 4 get exch 5 get cairo_store_point + /cairo_font where { pop cairo_selectfont } if } bind def +/Tm { 2 copy 8 2 roll 6 array astore /cairo_font_matrix exch def + cairo_store_point /cairo_font where { pop cairo_selectfont } if } bind def +/g { setgray } bind def +/rg { setrgbcolor } bind def +/d1 { setcachedevice } bind def +%%EndProlog +%%Page: 1 1 +%%BeginPageSetup +%%PageBoundingBox: 0 0 116 67 +%%EndPageSetup +q +Q q +q 0 0 117 67 rectclip +% Fallback Image: x=0, y=0, w=116, h=65 res=300dpi size=399300 +[ 0.24 0 0 0.24 0 0.327072 ] concat +/DeviceRGB setcolorspace +8 dict dup begin + /ImageType 1 def + /Width 484 def + /Height 275 def + /BitsPerComponent 8 def + /Decode [ 0 1 0 1 0 1 ] def + /DataSource currentfile /ASCII85Decode filter /LZWDecode filter def + /ImageMatrix [ 1 0 0 -1 0 275 ] def +end +image +J3I@:BHu(:pOk^R:T.dk*=mro@So+\<\5,H7Uo<*jE<[.O@Wn[3@'nb-^757;Rp>H>q_R=Al + C^cenm@9:1mM9jS"!dTMT(d8$g?t7s\'HOJg#PSPQ1`C/mioWjnAY&^Hf#!Qo!:QLNm9ApfKo@"^St*EZ$@h7Iu_ + dAb*B(hHM_+c/A3_/KTg;O43>N3c+5)[@l+5FLs\BULUaal`3%:o*cVOQKd#X?9bX/(9N + ;hHOZZn_7?NO1(WM6kAK/XoKPq^J0sl-?a0F-D'h>PLB,o"@,_I111+\T;ajP!l-d!&iT.% + e/>a[.cdZeMs92bu*/kbcJV__#PoP$$N1M#)o:%M?)+j1Opk9%o(KO6Z6F4AYo:,E+N3D]7 + S$Tq2Sh"*j$'D3;6:imCW5#QKF,=>9a`@jVR['[;:;RD-F8Q#.+Ki:rn"\Vipojq&s7-Kf$ + _Sb_TSJ.XGc#m=DQ0j!,fG4pM@G$ktNFUWW9pK;CQ>N1*g(o[EC"elTX_ZZ,c*_ECQL2A(g + _UF=ESQm4c#_\W:"=CB22WBi.$5D:LW)d^m3UV:)/KAQu + 3q"iY[\%M;jo*/W8X+c8CUAR-m+uj;AFrOlVo_9p=ZV20BS3MB`J*?BIu]RHBp?D4B]+c?5 + ]@RI5KqkSaqbU$.ptNMGKY>YUNWW&A%=?FiV&WToqTXfLb+cF'e?RdRkmll-E@V&u.7m?bb + [L1RW,Rr7&kmMh2J\aGrimCVg)-HTDpW&bNXT=`DQ_=3sJ%E%]U:DLk=Rg/S?A_M=UIHiq5 + /^*`*cS`u=SF8VekhLIRaI]tm.CJdg:K>s,Zn9T?<'.)e.H*9*nCCaIe-\7FN!r32`ri`XH.(GsdgeY.$ + ZN6DTr0]jokRPTMT:+4j4ac9.h2]-09KUJ'UN)D+P3geEYTl[qT + a*H\dkFA*2PM(u=3MSd*S;2mH>(TA$QR\IdP$W"*KJ2U*0VZarX&X&?7G$-7>\9M/[3j*G@ + )1E"fa>`WOdDV%4i64X#;`Y=kc)Pm002j9KL3]X!#5pPA%8-\UE&mDd4k7Z*m]Yg07cu@.%UZ]2rnYN^f^!Nskos7i&o"P=A0b4!)) + @67XM=JK<'3OZB0d36OiP=-f=Q^l=7C'\;0)c5.RT/D1`1[''2[Unjk + Q]!o)j-W)(R%$#\0(b^1#8])BIq:*tH5$EH.CO5%e-PSaU7\cU2n?BAE>kZQ^a-A.o.0N== + VlZo_]a#].D_S"nb6NsWBJ6g7j8IIo.XdnPX.l.CELfLW7O?M$UK$O0]r6X + L50_:r.L(]WUGHFDe_9HtlFU,^2Ec'S2qA^/V3@S&IpX]"3ULu3U&,W3`n`me.$i,K>o&X:ouBr\Y9FLBZd;T- + `"bRq20;/*9Nh7W6[3^EL?(?r6<;m[/,h([!uF>j6e.YtlE%2]\(jdH7_gscEJaU#RIs + U'^p*9.lV)qB_nDDX+kG=RH!VNY^:W$<)ZT/ok==pRJ3W%RbMnWHAZu[-%QZOed@D5]FU`H + 1]0&4>h,/R=*[d`U,Z"kDjf#SAk:Vn1d$LShPV5%XCjQi>o\WqqicZ.Y]SA55X=ns)0eX;#g7f&Uejf>!MrW3 + nql&fWWRrk9En?qQ(dCG>,Zdq5cXQr@/k1s,6^+5?P5KU\6C5&AGmIfTN;i7)OKs^&NEbms + HeS`F],J.!!a3:1=aB@*^`cjs:#(o'nBf!N&?b93>OfNZHIq!i$5H0HBX:l2V?l?Orn*%7F + OkieHmXs.BAdL%(f*neg + $RfunjmrU_!<c*e2r, + nb2E*DnB7-Hc*6bkPuGLN(iWmB$BH!>#f)fdLtScNmls2ZooEoM;:.7M-6P&HpEF?dWCkcq + P6%6Pf2Wngqel/mAuA?MI=I]$WXY0m_OcDZn.$$ml&U-1Me6!q58')@sp;L(t0=D\fU%)Ng + 3]Oab8hK$\>ZfBgqnYgjU'^=CRp)6f^e9g"38lsK8kU626YEUO*O]c(R/n\tkUW-%sb)]s( + NplWG!/#;a:JCTd@LJ^8YX]#S*D\\!*i95M(7K4&s`<=HK'SYu7m&q+!OC+r\f!,/N0+'Eg + >_b&(?a*5P;>eT+#6#'$LTQCT`Uo=QjNbaQ+#4tsOq+l1JJ`Ac(p"Sln;/O[;%EqN->!DAn + lfF!QiI[&%Z,fe`UPEkfdd7!,"SaYL%cIA$O^qea0LsQbFGZ8 + QZpOH,(ck$TsH"-Htu'(V$`[16*Z/1g)N%N&TY[#))_?df:>Y!g>"]a$=Vo+HYaP1h'Od_? + ARQ1<K`1+@ZdbP7KT + [Rb3es?k),F;T&PEk319AkAgkc0!-npaXD3h#P1"t''1-4T^kuD4*/'JPGGq@L3Bj?..SB? + ;nkIOeNI[74=h(,Cn2Qi4Xh&t5-sW?lG5X-1HlEf5#N<2'Ce=E"[H]d5=PSBKDtGjb7h5.1 + _^6^oH?OK"[L'*!Y'Ze6%)*D,.(J9os%T^csN&l>;a)uotalj`E[PF=f48_jn9R7e=[-H%L/t7Fi + drIj^*)o?FB-T[=DU!]3b1+?a]i>p&S6;b]@k;bg=^D&;;`KV-XFL`g.WRp*!m'-";$H@^[ + jtp+^&82.LeiA%"O1p-E4I7:^R5A@>3Cp/,BZp4mfoB!uPgp2O_'F_>l + CB=<5$p46l'qC3+82lDG2g:Q[YK%;CNN0UQ-`l=fg41*=t"H0( + @o0tkAI`s@94)R[e>JWqJ0.2?ZfdAe'1,^Z#/]?EVC0089o32Ys+L:^%WabL]VBo.UQ0CX` + V6/2bA(7%#5W2FK=)7FgbY$)f<'#\X-'H(FI*6d][]C-s"YVQSCdm1hubE#FBbM[r@HE\TD + p4H0a.-k\k\mZ#sXLE&V3OVR(QWXLn5$?ak5uQc?QpYQ,KHCA55F$RJHQo5I`uHoGYlpM51 + -Z[B6Z"h.uk9='%jg8oLQZ1j/4"A^#'%rHOVG!J0FGOp=mQ%,-CHC'tM99k$/;RrJ2\a5Ls + %*LgmQ%>.*I0Pa[=>7:Q-sp'%Kf=E:f"$EF_0tG6He+O:[[Va>T6%MJJp0J8G=@#5_2#(RK + 1J@P=:2Ff%m"oqKNDN8p\np[;2C-kKlr$"bP@$_MhW#CL.8q4L$a#m7UF[OLH$?1=Pi'k2 + (5Vi^4UOERaf[iLWi4-:l,keN%=q*C5G]p*VU'3\>R5fnPq5KZ^\T1fc + RJ<87(R&#>cZ&[\Rk#AFfV=t[':IF2D"F]'(=ejUFc@`)-e[!]q9b"Dn""a5FVp0>o;JkgD + j\)uS>M@=g%K$Go:$X2Y8Pu63:3;?a**m[B\F&lVGX%3Z_JD-T=9B@\_E8=WKd\LRV%>LqD + `#s23%H2U"VYV3^KJXCI)+@P$/6=`i#XO>%Cf'6b*5Gu%JWCj + e$-SM2TNMbj;W@I8c':PuuYqegLWL71ob."AU/ZM*.XKa2e5s)2.rJ_^FBY(<)o5M`i%,?e + c?.&;"/k7n[AL6qm'3<7`Bdi2rL=/ePb4<5*V/YEi0;uD(IbH0!)V^jiSmm`ji@*F>dn(pj`6PM=&BLKE- + 2TRa$J)Z/Z!1gI)f"Fc+#O6-\4HY0P#3s^CUWUP\-A#$]2#MU;K8)CM>0Z5-E3s+K<=]"l: + E]B&Y=ciI#P:+?PAT`'.4_0h72S8,YfjIL'bQWk37mAl.WX^]S4e7&fV + f.Pd\u.+oes[*KU&9C0SbdcW8Ihgsi1j&:o0>d^^H[U(NOd_oR82!WOZI[c):(iq!rs/X\/ + rCgg0Y__0ZlY2@.P5n?E]`BXFmHZKmpe&CmIa,T`7W-u_s0dS"%\L;gU=ZaWM_iA@Znf?P.^^?A,mQ`4c + )>P8[nb@Tra5AS`>kY.k]M\C_9.)AV>&Z?2Z8I_Fbt1YS+l$94h3;'qoo>'b$>jbgo>+ZYGQK,]@b6S=Ja2g/^@r^s'\^<8;Y + &D9tl$U)Eir$I,Wb+jk7=XaA.`J*Eh(cD'4s0!Bmf&SScsC\^r1+f6P-,H&7Crp"2DfSsiI + 0jrFV(C6Dkf&P_f*nO;"Tq'pf,!I`oK*OX`uD!?;hfWS#qL&p1pH.g__C7W8t>>`f##KkjJ + ]Nlt&g-nb"e%>S1?2]K+rVkR?8sc+70YNn)`U>>&n\q#N,OLW6h=Mff>M;imjD_4Zr9j&\= + il&FjrF1tP8i)d&;NC`j1ZXZ4ihADc/Ug>5(8H*Hc4Y;6=@7b!)1#OIV%8?BAVFg^SrsF^& + crWFmMEolEL6PqkMZT\6p;4NP<6Y#.`^lNclJ,Bc`T%g#$r(kBm%Cl5i0_rha(mSLbgT`dO + WLIAc0IpW3^(n=?90rlOYMs/uA9?eg$cruJf%JqlFTE*hYoB3jr&O7)OlGoKo=*^/>kA)7. + *c2RkF*jt\<'AH)-faT4_S,`&>J&@!GI=B`-h\5.,!VX8dLYm#/^N*]Q(E8,;oD_'uT1!AM + 8OiV$b<=OqR]H-de+L&P&ERUq<(^"%gW^J#mGpP+V4?I/f>+R6fJ[pPYNYBKd#IfB[]R6(5KZ#&'5LE8G861AJ + .MNmTBFS70f"nci@9-O%ndNRE0]"1RO4N<#QJ5B*G!JO-H'',l$>r6sVYcKhWFbU;7sJ#c1 + c,7t9,7K\I3d]fB$El\jLs7]+Nh>O.MeKeeudV`8E+.]$=P=g6Q=<`lZN$!aL*)`X4]h[$N + b@'UXe?/E+/6clBNmGl\sf/9f@lBkN"]oZ*Sq\Fo_788]`[g$a)99A83.]jQ]K0(?Hq+5)F\T0+jnM + l4>BYnMN3ro_o/1\eWJ]@)BrDef'".?FVU0r?"ea225l&+WoG + gRX9T%PU]8H15pF>XD%`Y^!b[VM[EMR@NTPD)G)`3PKY1klA$:^2Skt4M*\?XgukdkL3P+= + n%Jg0n*nq%;_0sA_E/>t>X*j_+%X0BX=d57Nn^Mb;D.Ej1cY/8F3PeT+/1E%bp:1tm?[`QZ + 3,bi/3K/3mhZf6$`UJ,Gh4.t#j4L^:U/G?nJ81YCD_fDjE6IU&<4&7`=aqIQ+&aG8rW%H29 + PrIqnlJX%gI7D^XB[VB55SM&>`Mq@]Y,4k]&fC,cnKbM%-rT=T0A)K2`@o19CZeA6Pd2XJf + kZ0rVGX:/P)(a`lAK#Np'MUEgFDJ?Cf2$^RqK!,MPFm9(9/X]Z+$/0EKp*\DOaMESH+Gl8C + KSKEcp$mGDOJF:JnDpKl;_mni:t;JNAK)dM]H;Aaa]E_q'JatSG>R'h+1&T=X'\bK8k + sKoqDn"ApMC:cf:rU+.ZI.iX)5im]HPL?q>GHK4*B__apeDKZbl3kdHG&/(6foKd+hMd^;O + M@dbbFOR@t3D"u#%K4FdG;Re9Dn_sp + *P+CCnUM5@YN!6.i3WNWQ_@s$FJN*+M + 3Zld3&((:p4K+ZVu&`13OmY.[AIK7S!-'+id:!$=$F,-RgdO(DLqc6IL\n&>+>aDaJ4b.2i + &jF>(SnIK(!ep.NqjX:foo2HrIKEN0d]qs(A>:U1FcZM*,Z`_6fS(f'dQ*[Z8#mXRpXKb#"Pt*XJ8ek31Ni3:SuYeh+!Ja/NlnM@?SW;#9#Xt&dD4!sU;/k1J,O%u-:OQTM[8'HOG9Ys+]#]1btHp`p72161(J5b + U`&Y$($=pN0d?7-[lP`,ekYW.goU0DJZA.hoT=_=EM#rlqH[0Jk)K_MA=I$(^#)ik'21785 + >=#"BDQ'\/H80jq&;5SCN(oFU2m1LPe@@U$?@62J?/nM5h)'k"'2H"B9V3JET,A7tq+F+?H + ,goJtGBiXK[1QN:iXCoY_ZaMS$u/0F.F[ob0FM;f3sn//UmZ*d$p?s.-\dH)65:_@\`&$,[ + U+IiSp8G9O/R'VLK&j^Qfu[!/[Y'3a_#0V.=EIQca%=aLZqF1I=&/_o[M>.AjWJu'5b*1!) + `$<;]`hU-W2e5`6o#VaE<4f2&0jlE[kA[rAb1l4R0eQ4@CE^&Z.FeMUq)(/r5c!/6!ID]gB + \=#d%I$b_!B'l:C4kZ`]c1*Lfd'rGZWh_^P3[GI3dtip"'lT:c3Z&Cor?e9"P<'uGK"U)ud + %XcTPO<2!=XW48\(14lkmcqg,U!hdAE@J2I6dG%VsTWOn3[l3ESX)CXJbH,SkhVM/"I,;"0 + /r19_(Dof@QPMa&73tY)d&\(=DD[iS&pEA42Zme6"gA<2P`8'Z.^3*`GdEAtWS+Q`IHqLD, + *FkfTrEhJ/WgaZQ%6@']&$JF4H2/$O]c%[=^=/u(g$(ZmtKG,i#m&,"`\Z!*`> + >p>UP$`oKJY&58Tko6t8YBgm[l'2+pQY'Iip%nRf,_T)-M,1's$PJ]^0:\=NsdM;3m5]a3" + LrL>1aICMr*:^?B\o>h + nDsa%dg#W+Aq+.Q3J@J.64RG+kk!4J:%S4\7^\bidETUpBTP>73>.I8m#e;j4/bE(G;/XJ0/V`X68R?72peo-":/?kr8mOg8-[heJ`e8Fo + 9IX5NdL$F?i%DHp^2Fgb8IXPB4h<8;oe#/NDaS,WZddF.Aq`g80DhuF#Y.Elor`\YFgTe=? + %--er6,pU:LiP6W]*OE8Xp.514d0ALI)N>ZKKA7fIAB4bX[sHpjM?2K$1-OSIW#,bK62-Td + W@%l,(;$Mpr&S-I#c\H\%b!$m="'T+Q6UN(oinV/ZJ=RVsLt_3$+ds^+kK=6s.aKH+5#`r: + @Y5^@MR%H7U9HoI8rK58PeGKbSdOXcVrtnqjo]kJ/bO&JGta!]Rd.H*DgSP+'lT:l%<&M(4 + FN$EI:$fV^r14sjcgRp'GDoA^*,j9`^%Ru73Kqo$!c`O^]AYS5'eU[8l)&\DPq2r!pii?uI + QadeP@P^E-7YjXBbF,ud>%f>36C\T?Rq(*]A.#]/qo62YcbR!_J]eG:!Gm(I!3P1+bYULtc + Y^aMgQ'5VQ^[)uK^s>@k0YN*'-p^\/$,StfJjDqs^/Mq`A/BgWOI>uXZ;_qPK3>AL*lE(F5 + ,pM/.NbpQM)UqL`(F"*JNQ*3?$=L^>cG7k5$PXqSoAU^*49,LI#kU;?=I;C,kJVnjSUF4f%`b:&k^kK + &c0IO*2XYBR[&PBp]kI&\'.\$JDqPqEEFh\j/`6a"8*)<%;-Gs5]2&ogbg/LS+P_tA3LhO5 + Z',3^a7M1!uPjr]?qXBV^1.IDb&1C!V1k^TFI7-oZ,FT_kgg7E'&Y1I7*"65p(lLj6V7:$4 + `^@!pK-WXB^;q1r_##smqb9JRlaYH3`Oq$5HEY:qKs``i%8:aK]99,@"=5T1XpfJDF3hM?O + $YCn8m9t?an!7uU'Sj_4;4M8o7WnJ@m4^l5Fc:V4D$JJ=@Xn.6sNtbCdoBAC']3&%$[@,3_ + W1M'?Vk$8j&tDXLfK8?^jHDb+n%1+r@gg]=MC*5'2t1lc2R`N^=uo8Y_9g,asT9)p9n4_$qW:nb5D2I2"aStl;6]!`pkr^(tHfH&P^4Yc= + A$e5aO'kW3n4t$D"s%fR#oQ,9RO0E.VHudnkl + 54;OJBLZ(b+6e!3n_6gWAG'_=A^+?MG(c6/k"_A#g#S;Y$>5@Fdk\Cf57bX)1^UfAg;I4A1 + /4:R9#)>J!rkZ(R[5Z@nC,OEoB/AOPo*m4-te!qX(jKSuDS&YO57"jWWU[X.KmRg>(;hX#T + <@1Mt(8l3\3s@%]bu7V&S^90BVKupO!8p`5o@!Jt97X32Lp954&l4[eMfS=8Emu!R:/n=me + G>J0X;KJVA6)7Be(PelC2(i/OKIje\8HciN&b+>6Fk*/$$=kiRNMgnit9>On$d#D/[bGj1RqO:HTg-H!H>cq7AW)cW<+_@>R70l9R7*sbg + Tf%7%fZ@<=cW^"H:aN*74aL'rU=Pg5A]mJHj[TnAI78Yj4IE`3i`n^O?3pk$3?" + Z,sBWqZU>!:8qZ:RT%L5N*!h.Xl8%GG+".,??Q>OALr9cmZW:+%XG0+r@C,fSUBDHX!Tfu4 + fb7HZ2gh&icU;Wrl;[Hdi.ls@co!_j+iVCPK_$Fko>'ZiD`U[A`\DC5 + Tau/s$Wbtg:TGok/hq25lmJgP_H/K,Obt*4YH+I5P_91T7\W(!7$/l3<@#bh-.GE^Z>N!0.i6:[o*T"mXf2b'.gr:"9WS6;X)e$k&iB^UT< + :=7,Md9$He$MDLVB',+^>['W@Tf71iDJS,#0fQ:eUAYINV244NSt'g@bH6?<\@kWKAplH@Y + A2mX!-)rA)WDjiLSNSc7iaR:?(t,A!o[D&Ph@3O5i(diiL_].@K2H3b/O7A!TDk.2cX#:1M + -Vj45#QV@I*9L1=fPj>KUBSjHtj9FY#j'])7aV5fhmDi\],@tau%5q5JhHr?]r(,TV:fG0S2@NL7(bYu + f7YoPpZte`t\H\hpNaHR!^?:5#B9ogf(;";+\^`%0ZMPIUDGbb@:atS%d##p;QCD<:%RB>4$QO,"6>$[d%H,iI7HbdQS0$d'@%99sXQR6D)qXC + @)XNf'/caIbHT;3EY7fD7t!051:b=e/Lm&Lj42_CP"MWGj^T?>?Z%!)*1kOd1;Vag0Gn*S> + :#MB9Sckfj+FsVW3m&o:bm=Rm,rl:1iM*&*kD]<4KP6=RKCAgd&m=:Rp\n0>aDq4fdt5qB-202b'hfLgKJP$E%bmZkLD6(")9\8 + hd3RK!74;8&=riiZZk^Db\]-$Yan<0)c,t2G$ee5oTXA.1qBf/rMe-^FIk,YZX4m4Y8Dko/ + lF.X\VlR.e4_7nhOltG$5/Y$$!)u+YlOW!4'SjlgGc?^n`fFMIgYcQS@W[`Gk.j2`SFa>[A + Z@:+o3FUXTgU3F@f)#W:`$UJ:@_T'_?Dp.J=UpkJLDBg8e-m`.>J^LLK1.eZYEDS2\8rD'L + 3;%6l1#]BA!%jkp1f-*(i8-^Q!HT1N*LG^mCFB:=,03K\cMXR_W(6]U.EWbs\V\bjMX^]T* + OLqVbCC:"_1&$)bk>)@d'j[/T+C@>Vo,f]j?[-"*NoJP)l*Y['KpS0^<0'D&;PWi:hGt2BG + cPZU\:o1K7U//,Kg14q%u#;*70PrbYt=F[m?D2ThnH=?p!o<7GtT*)h(-E( + 8BsF:akBOqb$=k3h>mp0As?%fqG[9.WnlHS9:0"QXY6Suh*==f5iVG)T5rND)bT[hl+>kaB + K/n?o#47&OS`3A.Q!\W$,86q6VAEsVUbeG:kQl2N&kT8LE%Q0 + N2m.&k+]1oA*!Hp:7Tj4sT,R_K6SIFh7Er!pqn3;mc]NKhQ]'#/gEe9m@3 + GA_#?\V'h&*"0C_6Ss;2O4%0jK>G3X<2'nD"Xa1[KfNt + M02L.*>F+lq&')bO*TInO.3pVb&<1O@;X08J?Eq`BXq-dg=Y#"_1V7>'*7m.bipVGh3YpbQ + NX9r^]b[ZeAA6 + Fh%8-CV,D\.rqMOZ<],2nRd/m[,,j#S\JgDpg+JV[A/MV1[^lJ[11\W9ca)UWt2H(m&[oKr + Un'4d:E0cbeKT"jFm@^+"r!p\,6/NYN[hGTWk,*q#\/]U5K.=-rM2UTk]^qW2`DQdgDhnRn + Bfpj$VVs^($#bVSC:&g5Wp^)W^c\d9@7_s`0/#up+_lMQ,qS*U5oRo"gd]BNBOCYg7/s0+!.\nYLRXn'$<7%>WBgVn$Y`=VN1sS] + 5U689M1_A7qW&-8\6Y[hma,c&CY8#,lr5o"5l5ZuYQaAS9LX,L^.#5d`6t&]enX<;nUe,B? + QmPD!Cm_bNCRuSso52B[*5o8ss!jFn4:%?-"V9L!qu,1JT1%nj?5D$+ + l4dT!@mT+AKj9=4(d"W&SMrkaDj^/A2.eM_>/,h:fTXiV9N^tGOA".O7g?(,7Bp + VNZq`Jd?"bgYY:>oN=dYm`H6$\W\YWkG[.XhO"@+Ht8F#MaO^nD8'p#]=a<3aFl0T + 4Q[Pc_quug:'DCX^b!0+h[gaas%i*!43pj-LSU@gi+S_9MM0XUVFkBD,Z3P[Oa@.(u__,/+6Lr1/]TJN@]2sX + r7,Rpp7>*MfC:HNXZB9@BF,=5p#_nO\8M8VFr&@g[Y5/ndrsV)6\tN;sSRK?4 + `0,j(oY019sG:$KVPjnJhC1QClD2oQHU4(NaqFt8(KZT9J0oq'XfLs9Y<6)N!/S!2i^1'^N + =BHo@(Z^uc1f>o\Q]/o?29+::[pA?$87>X/_96-sS\.s_ce]P3Qu7E767Isd<^ + 1<.U.XJdP`0U!+3!qsQ_Y:g:E>0Nb'6Z=Q]-Z.Eun[IGo2.Zgln.rmSG03Pk!idfRGZY(Wu + Jj/?h7GC9m69U3Y",8loX51CTliq(b=HCP/*u-57X")DW04-!mqZI(5t)IHI&^LNKVK9\N= + ;B[mWeZp>(=g+H(a.;qC]5c<$Rnb_N%3^<5:ee\,;1M`P(Y(n@;M62BFfK!bXWM<$c-$8KS-[iE:M`ABZ + rFKm%G%\umZN`6VsMecYW*RR.]>Jbp."_kkY;@AD.Mb8G,uZ1Q:3S2ql)gbW0G5Rd1P2EW! + FsuO2Y%OjZLr#FPZNEXUg)@c9mHLd0S+S7.g"**_1I^H/YWRX7<;=AK6UA@iU,]CH_+MpW3 + J`jBk"<%/%EE2[%IXkC[[c[$C3+/EZ%KRmC\?7N/W-@r=qO)K$#*pD517_uH\KNi;NTIWDr + fG_L:=fsQX&>r"QmT+J!>Z?dI2kb&$QO`$@MkBRQi\as>'qaK36EIHYRUUbM`_`-M2_fOmu + q8qIYff:^EdJc/<(;D*Fo-]gG?=1/2o"i/SlYc1j"H(R4NIcI'[IDl;pugBt1V@(doAbVHi + 56YS4IHp>Dr6F8+!i%cUnQU,[j?=CPD;4Y^@Ar?d$:`fgrUYY1-[%er(i\Jrcc]`\c^NkT3 + o=ac3*cQ,Gf3PEV2KG#l;JF#Ul.TWdd)W25pB$:W1dr./_)Po5-*ll]/[IVTj&IGiGV$!X/ + O@/gA28JZ&)>:?^DmbieFqhQP@BO4H9Bpf&]nWCpjsV,FINW8Om",)ebe$iL$c`qSZg(T*- + s:9Ok@#6hssqG:5uU*BjRAHIH/R`%h]L.MW3G6:Rq#>g!r&3sli7+^p%XRG-lmgf(F')-.8 + pTU=fOMW2sVZLaPs00`PJg+&EKPD*Nj^,ENFCt#Vj4u,I&.&"QO&Uf\"r-5-DU3_M%\"Q' + ,':*nj/'L51&`@P)^*QM+7]uuiXI&E,:%g7j_'Bk0t;0oF!Hi#o?lE&n`$)oC8HlnWQkSUA + f1cS\GW+.IY9m3l*GX_/k5*piHT/Wu.hd\MYn??">]L@ + $79"`4c)"Y!/?-GgcQkUA#64!t3r-VfdFC)\52&0/"P)m]Jt!QQlilEi5bMiY17#44$P0TV + C:ogc$J$_I,Yq#>&C%1tHA%:'h7raN,riT!,PmPbG-0bap7'MOQ%O/h'C%M=l'0k)djY;-E + j+H>t<`%rho@K/+30Q49`1Ld='%D+MR$J#]2!Rg7=o'Z!Cgdc9rXY1$MEebD$VQKEu(R(g[ + $K!iIg_9:j#'7OA'>PQ.`sSk*`Y!7"d3?%3-Ta-*1Yk5eWB4h6n8k2pe"ZA2k!hZpHZ)(U=8'%ZlMJ)nNc?OYRtc#o?`qiV*]8bSs1B4ZopfKWC + !Sr5r:G`;q0.c7n&>15OH8QZs-!k]gSj!7.Pf$1\X@\G+(6R2,nil#N&"MVaft%6$!E)1m3 + a'I7[D,K(Oed:LuPii<:aD7oZ$P#>[pUZV-%Z8dV7`Z_3ad3D6a%=]Dk(eC%Nb^7#bR5;^D + Qo[Q]*@nd[#:;nYVM3gr\%nRK(:W1^W[/Wrj=\gK#6KZ6''QC;Je0&-f;:Qad'dHUV-W63[ + ;UmF!'f/cg2cGu';q4*3'gkr#7oYaH<7OcE'iS+4=&kMi;;_a]"9/i]O=PHZ1Kf\'sh+E[p,-0>LgJn'u + O9V`dUlp_fa(,("6Ggf3OZr?.Ih=(#rO+&C/_q"V^D0;6jsdj'Ga_?e,0a('@rF#@NhK>gK + f?'loWkEn92hJgGEWbAGnM8OLmTc],YVA8m,L'Pt\Gd7hSC` + 3"fLKLs@R!p%8An"lYM3sG^ps"T(S.bUiLq(ujR&Un]GE*Mr`rcj-+hs&IH]2(J>PRrJK6N + >Y!JX^N2gF#;Qs5S=%>82Y?^7m*8:_=p_A'O12IVB)'u]eInF-%O!VnoZjF()+a$19jI@rPp"L6FiBZ?/X?EmP?,m]q1k9rCR=_/ + Ddr;[),ZYe$^%0AOnGo@,+k-cZ'F"#R.*R"3BLET4otJ!P]a[(U@jcHI@=ogP'+U1UD8t1N + L!_/06rgf3R*mhfpu8m>5)@ABK&R5*+>Ii083S0o!g,=51QF[ + B-).k>oBj9:+PrYC'3ZS-EV4o41Ie*6.@Q#7\VlH2dWnOYW)RHGrN](H7X'39>)T#!3AiY1 + TXP2"#KQ2n.n#[M_X!-B'"*P`SkH3J(WhJOX"*P_HpTE6H?eW(;])/]th5k*$XLe_?g=.iD + Dm:5JY$1(p]$IP\jf_k`Z9$76j(kssg*Z[;-Ta8h)\b"g)71=+2eDrp]"bFWi\u33[5t_%3 + h:S[I=G?d[bG`0#q;=TF17Wc\&ITW':hEnJ%1u+\A_U\2RFQ1QaXMe\_Eaf"*dcIRR[L&Y] + kH)@J$e!S%G0%]A(*5)oK&+k)tUgKpV3 + 3p^YAe(*!Q +Q +showpage +%%Trailer +count op_count sub {pop} repeat +countdictstack dict_count sub {end} repeat +cairo_eps_state restore +%%EOF diff -r 9b9a2497757d -r eb146c5c05a8 0__Papers/PRT/PRT__formal_def/figures/plots_exec_vs_task_size/cray1_pthread_vthread_8_32_128_512thds__o30000__perfCtrs.eps --- /dev/null Thu Jan 01 00:00:00 1970 +0000 +++ b/0__Papers/PRT/PRT__formal_def/figures/plots_exec_vs_task_size/cray1_pthread_vthread_8_32_128_512thds__o30000__perfCtrs.eps Sat Aug 03 19:24:22 2013 -0700 @@ -0,0 +1,1135 @@ +%!PS-Adobe-2.0 +%%Title: cray1_pthreads_vthread_8_32_128_512thds__o30000__perfCtrs.meas.eps +%%Creator: gnuplot 4.4 patchlevel 2 +%%CreationDate: Thu Jan 26 18:06:46 2012 +%%DocumentFonts: (atend) +%%BoundingBox: 251 50 554 482 +%%Orientation: Landscape +%%Pages: (atend) +%%EndComments +%%BeginProlog +/gnudict 256 dict def +gnudict begin +% +% The following true/false flags may be edited by hand if desired. +% The unit line width and grayscale image gamma correction may also be changed. +% +/Color true def +/Blacktext false def +/Solid false def +/Dashlength 1 def +/Landscape true def +/Level1 false def +/Rounded false def +/ClipToBoundingBox false def +/TransparentPatterns false def +/gnulinewidth 5.000 def +/userlinewidth gnulinewidth def +/Gamma 1.0 def +% +/vshift -46 def +/dl1 { + 10.0 Dashlength mul mul + Rounded { currentlinewidth 0.75 mul sub dup 0 le { pop 0.01 } if } if +} def +/dl2 { + 10.0 Dashlength mul mul + Rounded { currentlinewidth 0.75 mul add } if +} def +/hpt_ 31.5 def +/vpt_ 31.5 def +/hpt hpt_ def +/vpt vpt_ def +Level1 {} { +/SDict 10 dict def +systemdict /pdfmark known not { + userdict /pdfmark systemdict /cleartomark get put +} if +SDict begin [ + /Title (cray1_pthreads_vthread_8_32_128_512thds__o30000__perfCtrs.meas.eps) + /Subject (gnuplot plot) + /Creator (gnuplot 4.4 patchlevel 2) + /Author (msach) +% /Producer (gnuplot) +% /Keywords () + /CreationDate (Thu Jan 26 18:06:46 2012) + /DOCINFO pdfmark +end +} ifelse +/doclip { + ClipToBoundingBox { + newpath 251 50 moveto 554 50 lineto 554 482 lineto 251 482 lineto closepath + clip + } if +} def +% +% Gnuplot Prolog Version 4.4 (August 2010) +% +%/SuppressPDFMark true def +% +/M {moveto} bind def +/L {lineto} bind def +/R {rmoveto} bind def +/V {rlineto} bind def +/N {newpath moveto} bind def +/Z {closepath} bind def +/C {setrgbcolor} bind def +/f {rlineto fill} bind def +/g {setgray} bind def +/Gshow {show} def % May be redefined later in the file to support UTF-8 +/vpt2 vpt 2 mul def +/hpt2 hpt 2 mul def +/Lshow {currentpoint stroke M 0 vshift R + Blacktext {gsave 0 setgray show grestore} {show} ifelse} def +/Rshow {currentpoint stroke M dup stringwidth pop neg vshift R + Blacktext {gsave 0 setgray show grestore} {show} ifelse} def +/Cshow {currentpoint stroke M dup stringwidth pop -2 div vshift R + Blacktext {gsave 0 setgray show grestore} {show} ifelse} def +/UP {dup vpt_ mul /vpt exch def hpt_ mul /hpt exch def + /hpt2 hpt 2 mul def /vpt2 vpt 2 mul def} def +/DL {Color {setrgbcolor Solid {pop []} if 0 setdash} + {pop pop pop 0 setgray Solid {pop []} if 0 setdash} ifelse} def +/BL {stroke userlinewidth 2 mul setlinewidth + Rounded {1 setlinejoin 1 setlinecap} if} def +/AL {stroke userlinewidth 2 div setlinewidth + Rounded {1 setlinejoin 1 setlinecap} if} def +/UL {dup gnulinewidth mul /userlinewidth exch def + dup 1 lt {pop 1} if 10 mul /udl exch def} def +/PL {stroke userlinewidth setlinewidth + Rounded {1 setlinejoin 1 setlinecap} if} def +3.8 setmiterlimit +% Default Line colors +/LCw {1 1 1} def +/LCb {0 0 0} def +/LCa {0 0 0} def +/LC0 {1 0 0} def +/LC1 {0 1 0} def +/LC2 {0 0 1} def +/LC3 {1 0 1} def +/LC4 {0 1 1} def +/LC5 {1 1 0} def +/LC6 {0 0 0} def +/LC7 {1 0.3 0} def +/LC8 {0.5 0.5 0.5} def +% Default Line Types +/LTw {PL [] 1 setgray} def +/LTb {BL [] LCb DL} def +/LTa {AL [1 udl mul 2 udl mul] 0 setdash LCa setrgbcolor} def +/LT0 {PL [] LC0 DL} def +/LT1 {PL [4 dl1 2 dl2] LC1 DL} def +/LT2 {PL [2 dl1 3 dl2] LC2 DL} def +/LT3 {PL [1 dl1 1.5 dl2] LC3 DL} def +/LT4 {PL [6 dl1 2 dl2 1 dl1 2 dl2] LC4 DL} def +/LT5 {PL [3 dl1 3 dl2 1 dl1 3 dl2] LC5 DL} def +/LT6 {PL [2 dl1 2 dl2 2 dl1 6 dl2] LC6 DL} def +/LT7 {PL [1 dl1 2 dl2 6 dl1 2 dl2 1 dl1 2 dl2] LC7 DL} def +/LT8 {PL [2 dl1 2 dl2 2 dl1 2 dl2 2 dl1 2 dl2 2 dl1 4 dl2] LC8 DL} def +/Pnt {stroke [] 0 setdash gsave 1 setlinecap M 0 0 V stroke grestore} def +/Dia {stroke [] 0 setdash 2 copy vpt add M + hpt neg vpt neg V hpt vpt neg V + hpt vpt V hpt neg vpt V closepath stroke + Pnt} def +/Pls {stroke [] 0 setdash vpt sub M 0 vpt2 V + currentpoint stroke M + hpt neg vpt neg R hpt2 0 V stroke + } def +/Box {stroke [] 0 setdash 2 copy exch hpt sub exch vpt add M + 0 vpt2 neg V hpt2 0 V 0 vpt2 V + hpt2 neg 0 V closepath stroke + Pnt} def +/Crs {stroke [] 0 setdash exch hpt sub exch vpt add M + hpt2 vpt2 neg V currentpoint stroke M + hpt2 neg 0 R hpt2 vpt2 V stroke} def +/TriU {stroke [] 0 setdash 2 copy vpt 1.12 mul add M + hpt neg vpt -1.62 mul V + hpt 2 mul 0 V + hpt neg vpt 1.62 mul V closepath stroke + Pnt} def +/Star {2 copy Pls Crs} def +/BoxF {stroke [] 0 setdash exch hpt sub exch vpt add M + 0 vpt2 neg V hpt2 0 V 0 vpt2 V + hpt2 neg 0 V closepath fill} def +/TriUF {stroke [] 0 setdash vpt 1.12 mul add M + hpt neg vpt -1.62 mul V + hpt 2 mul 0 V + hpt neg vpt 1.62 mul V closepath fill} def +/TriD {stroke [] 0 setdash 2 copy vpt 1.12 mul sub M + hpt neg vpt 1.62 mul V + hpt 2 mul 0 V + hpt neg vpt -1.62 mul V closepath stroke + Pnt} def +/TriDF {stroke [] 0 setdash vpt 1.12 mul sub M + hpt neg vpt 1.62 mul V + hpt 2 mul 0 V + hpt neg vpt -1.62 mul V closepath fill} def +/DiaF {stroke [] 0 setdash vpt add M + hpt neg vpt neg V hpt vpt neg V + hpt vpt V hpt neg vpt V closepath fill} def +/Pent {stroke [] 0 setdash 2 copy gsave + translate 0 hpt M 4 {72 rotate 0 hpt L} repeat + closepath stroke grestore Pnt} def +/PentF {stroke [] 0 setdash gsave + translate 0 hpt M 4 {72 rotate 0 hpt L} repeat + closepath fill grestore} def +/Circle {stroke [] 0 setdash 2 copy + hpt 0 360 arc stroke Pnt} def +/CircleF {stroke [] 0 setdash hpt 0 360 arc fill} def +/C0 {BL [] 0 setdash 2 copy moveto vpt 90 450 arc} bind def +/C1 {BL [] 0 setdash 2 copy moveto + 2 copy vpt 0 90 arc closepath fill + vpt 0 360 arc closepath} bind def +/C2 {BL [] 0 setdash 2 copy moveto + 2 copy vpt 90 180 arc closepath fill + vpt 0 360 arc closepath} bind def +/C3 {BL [] 0 setdash 2 copy moveto + 2 copy vpt 0 180 arc closepath fill + vpt 0 360 arc closepath} bind def +/C4 {BL [] 0 setdash 2 copy moveto + 2 copy vpt 180 270 arc closepath fill + vpt 0 360 arc closepath} bind def +/C5 {BL [] 0 setdash 2 copy moveto + 2 copy vpt 0 90 arc + 2 copy moveto + 2 copy vpt 180 270 arc closepath fill + vpt 0 360 arc} bind def +/C6 {BL [] 0 setdash 2 copy moveto + 2 copy vpt 90 270 arc closepath fill + vpt 0 360 arc closepath} bind def +/C7 {BL [] 0 setdash 2 copy moveto + 2 copy vpt 0 270 arc closepath fill + vpt 0 360 arc closepath} bind def +/C8 {BL [] 0 setdash 2 copy moveto + 2 copy vpt 270 360 arc closepath fill + vpt 0 360 arc closepath} bind def +/C9 {BL [] 0 setdash 2 copy moveto + 2 copy vpt 270 450 arc closepath fill + vpt 0 360 arc closepath} bind def +/C10 {BL [] 0 setdash 2 copy 2 copy moveto vpt 270 360 arc closepath fill + 2 copy moveto + 2 copy vpt 90 180 arc closepath fill + vpt 0 360 arc closepath} bind def +/C11 {BL [] 0 setdash 2 copy moveto + 2 copy vpt 0 180 arc closepath fill + 2 copy moveto + 2 copy vpt 270 360 arc closepath fill + vpt 0 360 arc closepath} bind def +/C12 {BL [] 0 setdash 2 copy moveto + 2 copy vpt 180 360 arc closepath fill + vpt 0 360 arc closepath} bind def +/C13 {BL [] 0 setdash 2 copy moveto + 2 copy vpt 0 90 arc closepath fill + 2 copy moveto + 2 copy vpt 180 360 arc closepath fill + vpt 0 360 arc closepath} bind def +/C14 {BL [] 0 setdash 2 copy moveto + 2 copy vpt 90 360 arc closepath fill + vpt 0 360 arc} bind def +/C15 {BL [] 0 setdash 2 copy vpt 0 360 arc closepath fill + vpt 0 360 arc closepath} bind def +/Rec {newpath 4 2 roll moveto 1 index 0 rlineto 0 exch rlineto + neg 0 rlineto closepath} bind def +/Square {dup Rec} bind def +/Bsquare {vpt sub exch vpt sub exch vpt2 Square} bind def +/S0 {BL [] 0 setdash 2 copy moveto 0 vpt rlineto BL Bsquare} bind def +/S1 {BL [] 0 setdash 2 copy vpt Square fill Bsquare} bind def +/S2 {BL [] 0 setdash 2 copy exch vpt sub exch vpt Square fill Bsquare} bind def +/S3 {BL [] 0 setdash 2 copy exch vpt sub exch vpt2 vpt Rec fill Bsquare} bind def +/S4 {BL [] 0 setdash 2 copy exch vpt sub exch vpt sub vpt Square fill Bsquare} bind def +/S5 {BL [] 0 setdash 2 copy 2 copy vpt Square fill + exch vpt sub exch vpt sub vpt Square fill Bsquare} bind def +/S6 {BL [] 0 setdash 2 copy exch vpt sub exch vpt sub vpt vpt2 Rec fill Bsquare} bind def +/S7 {BL [] 0 setdash 2 copy exch vpt sub exch vpt sub vpt vpt2 Rec fill + 2 copy vpt Square fill Bsquare} bind def +/S8 {BL [] 0 setdash 2 copy vpt sub vpt Square fill Bsquare} bind def +/S9 {BL [] 0 setdash 2 copy vpt sub vpt vpt2 Rec fill Bsquare} bind def +/S10 {BL [] 0 setdash 2 copy vpt sub vpt Square fill 2 copy exch vpt sub exch vpt Square fill + Bsquare} bind def +/S11 {BL [] 0 setdash 2 copy vpt sub vpt Square fill 2 copy exch vpt sub exch vpt2 vpt Rec fill + Bsquare} bind def +/S12 {BL [] 0 setdash 2 copy exch vpt sub exch vpt sub vpt2 vpt Rec fill Bsquare} bind def +/S13 {BL [] 0 setdash 2 copy exch vpt sub exch vpt sub vpt2 vpt Rec fill + 2 copy vpt Square fill Bsquare} bind def +/S14 {BL [] 0 setdash 2 copy exch vpt sub exch vpt sub vpt2 vpt Rec fill + 2 copy exch vpt sub exch vpt Square fill Bsquare} bind def +/S15 {BL [] 0 setdash 2 copy Bsquare fill Bsquare} bind def +/D0 {gsave translate 45 rotate 0 0 S0 stroke grestore} bind def +/D1 {gsave translate 45 rotate 0 0 S1 stroke grestore} bind def +/D2 {gsave translate 45 rotate 0 0 S2 stroke grestore} bind def +/D3 {gsave translate 45 rotate 0 0 S3 stroke grestore} bind def +/D4 {gsave translate 45 rotate 0 0 S4 stroke grestore} bind def +/D5 {gsave translate 45 rotate 0 0 S5 stroke grestore} bind def +/D6 {gsave translate 45 rotate 0 0 S6 stroke grestore} bind def +/D7 {gsave translate 45 rotate 0 0 S7 stroke grestore} bind def +/D8 {gsave translate 45 rotate 0 0 S8 stroke grestore} bind def +/D9 {gsave translate 45 rotate 0 0 S9 stroke grestore} bind def +/D10 {gsave translate 45 rotate 0 0 S10 stroke grestore} bind def +/D11 {gsave translate 45 rotate 0 0 S11 stroke grestore} bind def +/D12 {gsave translate 45 rotate 0 0 S12 stroke grestore} bind def +/D13 {gsave translate 45 rotate 0 0 S13 stroke grestore} bind def +/D14 {gsave translate 45 rotate 0 0 S14 stroke grestore} bind def +/D15 {gsave translate 45 rotate 0 0 S15 stroke grestore} bind def +/DiaE {stroke [] 0 setdash vpt add M + hpt neg vpt neg V hpt vpt neg V + hpt vpt V hpt neg vpt V closepath stroke} def +/BoxE {stroke [] 0 setdash exch hpt sub exch vpt add M + 0 vpt2 neg V hpt2 0 V 0 vpt2 V + hpt2 neg 0 V closepath stroke} def +/TriUE {stroke [] 0 setdash vpt 1.12 mul add M + hpt neg vpt -1.62 mul V + hpt 2 mul 0 V + hpt neg vpt 1.62 mul V closepath stroke} def +/TriDE {stroke [] 0 setdash vpt 1.12 mul sub M + hpt neg vpt 1.62 mul V + hpt 2 mul 0 V + hpt neg vpt -1.62 mul V closepath stroke} def +/PentE {stroke [] 0 setdash gsave + translate 0 hpt M 4 {72 rotate 0 hpt L} repeat + closepath stroke grestore} def +/CircE {stroke [] 0 setdash + hpt 0 360 arc stroke} def +/Opaque {gsave closepath 1 setgray fill grestore 0 setgray closepath} def +/DiaW {stroke [] 0 setdash vpt add M + hpt neg vpt neg V hpt vpt neg V + hpt vpt V hpt neg vpt V Opaque stroke} def +/BoxW {stroke [] 0 setdash exch hpt sub exch vpt add M + 0 vpt2 neg V hpt2 0 V 0 vpt2 V + hpt2 neg 0 V Opaque stroke} def +/TriUW {stroke [] 0 setdash vpt 1.12 mul add M + hpt neg vpt -1.62 mul V + hpt 2 mul 0 V + hpt neg vpt 1.62 mul V Opaque stroke} def +/TriDW {stroke [] 0 setdash vpt 1.12 mul sub M + hpt neg vpt 1.62 mul V + hpt 2 mul 0 V + hpt neg vpt -1.62 mul V Opaque stroke} def +/PentW {stroke [] 0 setdash gsave + translate 0 hpt M 4 {72 rotate 0 hpt L} repeat + Opaque stroke grestore} def +/CircW {stroke [] 0 setdash + hpt 0 360 arc Opaque stroke} def +/BoxFill {gsave Rec 1 setgray fill grestore} def +/Density { + /Fillden exch def + currentrgbcolor + /ColB exch def /ColG exch def /ColR exch def + /ColR ColR Fillden mul Fillden sub 1 add def + /ColG ColG Fillden mul Fillden sub 1 add def + /ColB ColB Fillden mul Fillden sub 1 add def + ColR ColG ColB setrgbcolor} def +/BoxColFill {gsave Rec PolyFill} def +/PolyFill {gsave Density fill grestore grestore} def +/h {rlineto rlineto rlineto gsave closepath fill grestore} bind def +% +% PostScript Level 1 Pattern Fill routine for rectangles +% Usage: x y w h s a XX PatternFill +% x,y = lower left corner of box to be filled +% w,h = width and height of box +% a = angle in degrees between lines and x-axis +% XX = 0/1 for no/yes cross-hatch +% +/PatternFill {gsave /PFa [ 9 2 roll ] def + PFa 0 get PFa 2 get 2 div add PFa 1 get PFa 3 get 2 div add translate + PFa 2 get -2 div PFa 3 get -2 div PFa 2 get PFa 3 get Rec + gsave 1 setgray fill grestore clip + currentlinewidth 0.5 mul setlinewidth + /PFs PFa 2 get dup mul PFa 3 get dup mul add sqrt def + 0 0 M PFa 5 get rotate PFs -2 div dup translate + 0 1 PFs PFa 4 get div 1 add floor cvi + {PFa 4 get mul 0 M 0 PFs V} for + 0 PFa 6 get ne { + 0 1 PFs PFa 4 get div 1 add floor cvi + {PFa 4 get mul 0 2 1 roll M PFs 0 V} for + } if + stroke grestore} def +% +/languagelevel where + {pop languagelevel} {1} ifelse + 2 lt + {/InterpretLevel1 true def} + {/InterpretLevel1 Level1 def} + ifelse +% +% PostScript level 2 pattern fill definitions +% +/Level2PatternFill { +/Tile8x8 {/PaintType 2 /PatternType 1 /TilingType 1 /BBox [0 0 8 8] /XStep 8 /YStep 8} + bind def +/KeepColor {currentrgbcolor [/Pattern /DeviceRGB] setcolorspace} bind def +<< Tile8x8 + /PaintProc {0.5 setlinewidth pop 0 0 M 8 8 L 0 8 M 8 0 L stroke} +>> matrix makepattern +/Pat1 exch def +<< Tile8x8 + /PaintProc {0.5 setlinewidth pop 0 0 M 8 8 L 0 8 M 8 0 L stroke + 0 4 M 4 8 L 8 4 L 4 0 L 0 4 L stroke} +>> matrix makepattern +/Pat2 exch def +<< Tile8x8 + /PaintProc {0.5 setlinewidth pop 0 0 M 0 8 L + 8 8 L 8 0 L 0 0 L fill} +>> matrix makepattern +/Pat3 exch def +<< Tile8x8 + /PaintProc {0.5 setlinewidth pop -4 8 M 8 -4 L + 0 12 M 12 0 L stroke} +>> matrix makepattern +/Pat4 exch def +<< Tile8x8 + /PaintProc {0.5 setlinewidth pop -4 0 M 8 12 L + 0 -4 M 12 8 L stroke} +>> matrix makepattern +/Pat5 exch def +<< Tile8x8 + /PaintProc {0.5 setlinewidth pop -2 8 M 4 -4 L + 0 12 M 8 -4 L 4 12 M 10 0 L stroke} +>> matrix makepattern +/Pat6 exch def +<< Tile8x8 + /PaintProc {0.5 setlinewidth pop -2 0 M 4 12 L + 0 -4 M 8 12 L 4 -4 M 10 8 L stroke} +>> matrix makepattern +/Pat7 exch def +<< Tile8x8 + /PaintProc {0.5 setlinewidth pop 8 -2 M -4 4 L + 12 0 M -4 8 L 12 4 M 0 10 L stroke} +>> matrix makepattern +/Pat8 exch def +<< Tile8x8 + /PaintProc {0.5 setlinewidth pop 0 -2 M 12 4 L + -4 0 M 12 8 L -4 4 M 8 10 L stroke} +>> matrix makepattern +/Pat9 exch def +/Pattern1 {PatternBgnd KeepColor Pat1 setpattern} bind def +/Pattern2 {PatternBgnd KeepColor Pat2 setpattern} bind def +/Pattern3 {PatternBgnd KeepColor Pat3 setpattern} bind def +/Pattern4 {PatternBgnd KeepColor Landscape {Pat5} {Pat4} ifelse setpattern} bind def +/Pattern5 {PatternBgnd KeepColor Landscape {Pat4} {Pat5} ifelse setpattern} bind def +/Pattern6 {PatternBgnd KeepColor Landscape {Pat9} {Pat6} ifelse setpattern} bind def +/Pattern7 {PatternBgnd KeepColor Landscape {Pat8} {Pat7} ifelse setpattern} bind def +} def +% +% +%End of PostScript Level 2 code +% +/PatternBgnd { + TransparentPatterns {} {gsave 1 setgray fill grestore} ifelse +} def +% +% Substitute for Level 2 pattern fill codes with +% grayscale if Level 2 support is not selected. +% +/Level1PatternFill { +/Pattern1 {0.250 Density} bind def +/Pattern2 {0.500 Density} bind def +/Pattern3 {0.750 Density} bind def +/Pattern4 {0.125 Density} bind def +/Pattern5 {0.375 Density} bind def +/Pattern6 {0.625 Density} bind def +/Pattern7 {0.875 Density} bind def +} def +% +% Now test for support of Level 2 code +% +Level1 {Level1PatternFill} {Level2PatternFill} ifelse +% +/Symbol-Oblique /Symbol findfont [1 0 .167 1 0 0] makefont +dup length dict begin {1 index /FID eq {pop pop} {def} ifelse} forall +currentdict end definefont pop +/MFshow { + { dup 5 get 3 ge + { 5 get 3 eq {gsave} {grestore} ifelse } + {dup dup 0 get findfont exch 1 get scalefont setfont + [ currentpoint ] exch dup 2 get 0 exch R dup 5 get 2 ne {dup dup 6 + get exch 4 get {Gshow} {stringwidth pop 0 R} ifelse }if dup 5 get 0 eq + {dup 3 get {2 get neg 0 exch R pop} {pop aload pop M} ifelse} {dup 5 + get 1 eq {dup 2 get exch dup 3 get exch 6 get stringwidth pop -2 div + dup 0 R} {dup 6 get stringwidth pop -2 div 0 R 6 get + show 2 index {aload pop M neg 3 -1 roll neg R pop pop} {pop pop pop + pop aload pop M} ifelse }ifelse }ifelse } + ifelse } + forall} def +/Gswidth {dup type /stringtype eq {stringwidth} {pop (n) stringwidth} ifelse} def +/MFwidth {0 exch { dup 5 get 3 ge { 5 get 3 eq { 0 } { pop } ifelse } + {dup 3 get{dup dup 0 get findfont exch 1 get scalefont setfont + 6 get Gswidth pop add} {pop} ifelse} ifelse} forall} def +/MLshow { currentpoint stroke M + 0 exch R + Blacktext {gsave 0 setgray MFshow grestore} {MFshow} ifelse } bind def +/MRshow { currentpoint stroke M + exch dup MFwidth neg 3 -1 roll R + Blacktext {gsave 0 setgray MFshow grestore} {MFshow} ifelse } bind def +/MCshow { currentpoint stroke M + exch dup MFwidth -2 div 3 -1 roll R + Blacktext {gsave 0 setgray MFshow grestore} {MFshow} ifelse } bind def +/XYsave { [( ) 1 2 true false 3 ()] } bind def +/XYrestore { [( ) 1 2 true false 4 ()] } bind def +end +%%EndProlog +%%Page: 1 1 +gnudict begin +gsave +doclip +50 50 translate +0.100 0.100 scale +90 rotate +0 -5040 translate +0 setgray +newpath +(Helvetica) findfont 140 scalefont setfont +1.000 UL +LTb +602 448 M +63 0 V +stroke +518 448 M +[ [(Helvetica) 140.0 0.0 true true 0 ( 1)] +] -46.7 MRshow +1.000 UL +LTb +602 715 M +63 0 V +stroke +518 715 M +[ [(Helvetica) 140.0 0.0 true true 0 ( 2)] +] -46.7 MRshow +1.000 UL +LTb +602 983 M +63 0 V +stroke +518 983 M +[ [(Helvetica) 140.0 0.0 true true 0 ( 3)] +] -46.7 MRshow +1.000 UL +LTb +602 1250 M +63 0 V +stroke +518 1250 M +[ [(Helvetica) 140.0 0.0 true true 0 ( 4)] +] -46.7 MRshow +1.000 UL +LTb +602 1518 M +63 0 V +stroke +518 1518 M +[ [(Helvetica) 140.0 0.0 true true 0 ( 5)] +] -46.7 MRshow +1.000 UL +LTb +602 1785 M +63 0 V +stroke +518 1785 M +[ [(Helvetica) 140.0 0.0 true true 0 ( 6)] +] -46.7 MRshow +1.000 UL +LTb +602 2053 M +63 0 V +stroke +518 2053 M +[ [(Helvetica) 140.0 0.0 true true 0 ( 7)] +] -46.7 MRshow +1.000 UL +LTb +602 2320 M +63 0 V +stroke +518 2320 M +[ [(Helvetica) 140.0 0.0 true true 0 ( 8)] +] -46.7 MRshow +1.000 UL +LTb +602 2588 M +63 0 V +stroke +518 2588 M +[ [(Helvetica) 140.0 0.0 true true 0 ( 9)] +] -46.7 MRshow +1.000 UL +LTb +602 2855 M +63 0 V +stroke +518 2855 M +[ [(Helvetica) 140.0 0.0 true true 0 ( 10)] +] -46.7 MRshow +1.000 UL +LTb +602 448 M +0 63 V +stroke +602 308 M +[ [(Helvetica) 140.0 0.0 true true 0 ( 0)] +] -46.7 MCshow +1.000 UL +LTb +1035 448 M +0 63 V +stroke +1035 308 M +[ [(Helvetica) 140.0 0.0 true true 0 ( 1000)] +] -46.7 MCshow +1.000 UL +LTb +1468 448 M +0 63 V +stroke +1468 308 M +[ [(Helvetica) 140.0 0.0 true true 0 ( 2000)] +] -46.7 MCshow +1.000 UL +LTb +1901 448 M +0 63 V +stroke +1901 308 M +[ [(Helvetica) 140.0 0.0 true true 0 ( 3000)] +] -46.7 MCshow +1.000 UL +LTb +2335 448 M +0 63 V +stroke +2335 308 M +[ [(Helvetica) 140.0 0.0 true true 0 ( 4000)] +] -46.7 MCshow +1.000 UL +LTb +2768 448 M +0 63 V +stroke +2768 308 M +[ [(Helvetica) 140.0 0.0 true true 0 ( 5000)] +] -46.7 MCshow +1.000 UL +LTb +3201 448 M +0 63 V +stroke +3201 308 M +[ [(Helvetica) 140.0 0.0 true true 0 ( 6000)] +] -46.7 MCshow +1.000 UL +LTb +3634 448 M +0 63 V +stroke +3634 308 M +[ [(Helvetica) 140.0 0.0 true true 0 ( 7000)] +] -46.7 MCshow +1.000 UL +LTb +4067 448 M +0 63 V +stroke +4067 308 M +[ [(Helvetica) 140.0 0.0 true true 0 ( 8000)] +] -46.7 MCshow +1.000 UL +LTb +1.000 UL +LTb +602 2855 M +602 448 L +3465 0 V +0 2407 R +-3465 0 R +stroke +LCb setrgbcolor +112 1651 M +currentpoint gsave translate -270 rotate 0 0 moveto +[ [(Helvetica) 140.0 0.0 true true 0 (Ratio of Total Execution to Total Work)] +] -46.7 MCshow +grestore +LTb +LCb setrgbcolor +2334 98 M +[ [(Helvetica) 140.0 0.0 true true 0 (Cycles in one Task)] +] -46.7 MCshow +LTb +1.000 UP +1.000 UL +LTb +LCb setrgbcolor +3538 2919 M +[ [(Helvetica) 140.0 0.0 true true 0 (pthreads)] +] -46.7 MCshow +LTb +1.000 UL +LTb +2793 2289 N +0 700 V +1491 0 V +0 -700 V +-1491 0 V +Z stroke +2793 2849 M +1491 0 V +% Begin plot #1 +stroke +4.000 UL +LT5 +LC7 setrgbcolor +LCb setrgbcolor +3717 2779 M +[ [(Helvetica) 140.0 0.0 true true 0 (8 Threads)] +] -46.7 MRshow +LT5 +LC7 setrgbcolor +3801 2779 M +399 0 V +775 2855 M +28 -401 V +924 1709 L +249 -553 V +1658 827 L +2629 643 L +4067 572 L +% End plot #1 +% Begin plot #2 +stroke +LT6 +LCb setrgbcolor +3717 2639 M +[ [(Helvetica) 140.0 0.0 true true 0 (32 Threads)] +] -46.7 MRshow +LT6 +3801 2639 M +399 0 V +1064 2855 M +111 -618 V +488 -826 V +2631 949 L +4067 767 L +% End plot #2 +% Begin plot #3 +stroke +LT7 +LC1 setrgbcolor +LCb setrgbcolor +3717 2499 M +[ [(Helvetica) 140.0 0.0 true true 0 (128 Threads)] +] -46.7 MRshow +LT7 +LC1 setrgbcolor +3801 2499 M +399 0 V +2210 2855 M +429 -685 V +4067 1557 L +% End plot #3 +% Begin plot #4 +stroke +LT8 +LCb setrgbcolor +3717 2359 M +[ [(Helvetica) 140.0 0.0 true true 0 (512 Threads)] +] -46.7 MRshow +LT8 +3801 2359 M +399 0 V +% End plot #4 +stroke +1.000 UL +LTb +602 2855 M +602 448 L +3465 0 V +0 2407 R +-3465 0 R +1.000 UP +602 448 M +63 0 V +stroke +518 448 M +[ [(Helvetica) 140.0 0.0 true true 0 ( 1)] +] -46.7 MRshow +1.000 UL +LTb +602 715 M +63 0 V +stroke +518 715 M +[ [(Helvetica) 140.0 0.0 true true 0 ( 2)] +] -46.7 MRshow +1.000 UL +LTb +602 983 M +63 0 V +stroke +518 983 M +[ [(Helvetica) 140.0 0.0 true true 0 ( 3)] +] -46.7 MRshow +1.000 UL +LTb +602 1250 M +63 0 V +stroke +518 1250 M +[ [(Helvetica) 140.0 0.0 true true 0 ( 4)] +] -46.7 MRshow +1.000 UL +LTb +602 1518 M +63 0 V +stroke +518 1518 M +[ [(Helvetica) 140.0 0.0 true true 0 ( 5)] +] -46.7 MRshow +1.000 UL +LTb +602 1785 M +63 0 V +stroke +518 1785 M +[ [(Helvetica) 140.0 0.0 true true 0 ( 6)] +] -46.7 MRshow +1.000 UL +LTb +602 2053 M +63 0 V +stroke +518 2053 M +[ [(Helvetica) 140.0 0.0 true true 0 ( 7)] +] -46.7 MRshow +1.000 UL +LTb +602 2320 M +63 0 V +stroke +518 2320 M +[ [(Helvetica) 140.0 0.0 true true 0 ( 8)] +] -46.7 MRshow +1.000 UL +LTb +602 2588 M +63 0 V +stroke +518 2588 M +[ [(Helvetica) 140.0 0.0 true true 0 ( 9)] +] -46.7 MRshow +1.000 UL +LTb +602 2855 M +63 0 V +stroke +518 2855 M +[ [(Helvetica) 140.0 0.0 true true 0 ( 10)] +] -46.7 MRshow +1.000 UL +LTb +602 448 M +0 63 V +stroke +602 308 M +[ [(Helvetica) 140.0 0.0 true true 0 ( 0)] +] -46.7 MCshow +1.000 UL +LTb +1035 448 M +0 63 V +stroke +1035 308 M +[ [(Helvetica) 140.0 0.0 true true 0 ( 1000)] +] -46.7 MCshow +1.000 UL +LTb +1468 448 M +0 63 V +stroke +1468 308 M +[ [(Helvetica) 140.0 0.0 true true 0 ( 2000)] +] -46.7 MCshow +1.000 UL +LTb +1901 448 M +0 63 V +stroke +1901 308 M +[ [(Helvetica) 140.0 0.0 true true 0 ( 3000)] +] -46.7 MCshow +1.000 UL +LTb +2335 448 M +0 63 V +stroke +2335 308 M +[ [(Helvetica) 140.0 0.0 true true 0 ( 4000)] +] -46.7 MCshow +1.000 UL +LTb +2768 448 M +0 63 V +stroke +2768 308 M +[ [(Helvetica) 140.0 0.0 true true 0 ( 5000)] +] -46.7 MCshow +1.000 UL +LTb +3201 448 M +0 63 V +stroke +3201 308 M +[ [(Helvetica) 140.0 0.0 true true 0 ( 6000)] +] -46.7 MCshow +1.000 UL +LTb +3634 448 M +0 63 V +stroke +3634 308 M +[ [(Helvetica) 140.0 0.0 true true 0 ( 7000)] +] -46.7 MCshow +1.000 UL +LTb +4067 448 M +0 63 V +stroke +4067 308 M +[ [(Helvetica) 140.0 0.0 true true 0 ( 8000)] +] -46.7 MCshow +1.000 UL +LTb +1.000 UL +LTb +602 2855 M +602 448 L +3465 0 V +0 2407 R +-3465 0 R +stroke +LCb setrgbcolor +112 1651 M +currentpoint gsave translate -270 rotate 0 0 moveto +[ [(Helvetica) 140.0 0.0 true true 0 (Ratio of Total Execution to Total Work)] +] -46.7 MCshow +grestore +LTb +LCb setrgbcolor +2334 98 M +[ [(Helvetica) 140.0 0.0 true true 0 (Cycles in one Task)] +] -46.7 MCshow +LTb +1.000 UP +1.000 UL +LTb +LCb setrgbcolor +2022 2919 M +[ [(Helvetica) 140.0 0.0 true true 0 (Vthread)] +] -46.7 MCshow +LTb +1.000 UL +LTb +1277 2289 N +0 700 V +1491 0 V +0 -700 V +-1491 0 V +Z stroke +1277 2849 M +1491 0 V +% Begin plot #1 +stroke +4.000 UL +LT1 +LCa setrgbcolor +602 715 M +35 0 V +35 0 V +35 0 V +35 0 V +35 0 V +35 0 V +35 0 V +35 0 V +35 0 V +35 0 V +35 0 V +35 0 V +35 0 V +35 0 V +35 0 V +35 0 V +35 0 V +35 0 V +35 0 V +35 0 V +35 0 V +35 0 V +35 0 V +35 0 V +35 0 V +35 0 V +35 0 V +35 0 V +35 0 V +35 0 V +35 0 V +35 0 V +35 0 V +35 0 V +35 0 V +35 0 V +35 0 V +35 0 V +35 0 V +35 0 V +35 0 V +35 0 V +35 0 V +35 0 V +35 0 V +35 0 V +35 0 V +35 0 V +35 0 V +35 0 V +35 0 V +35 0 V +35 0 V +35 0 V +35 0 V +35 0 V +35 0 V +35 0 V +35 0 V +35 0 V +35 0 V +35 0 V +35 0 V +35 0 V +35 0 V +35 0 V +35 0 V +35 0 V +35 0 V +35 0 V +35 0 V +35 0 V +35 0 V +35 0 V +35 0 V +35 0 V +35 0 V +35 0 V +35 0 V +35 0 V +35 0 V +35 0 V +35 0 V +35 0 V +35 0 V +35 0 V +35 0 V +35 0 V +35 0 V +35 0 V +35 0 V +35 0 V +35 0 V +35 0 V +35 0 V +35 0 V +35 0 V +35 0 V +35 0 V +% End plot #1 +% Begin plot #2 +stroke +LT0 +LCb setrgbcolor +2201 2779 M +[ [(Helvetica) 140.0 0.0 true true 0 (8 Threads)] +] -46.7 MRshow +LT0 +2285 2779 M +399 0 V +692 1306 M +18 -111 V +31 -149 V +801 842 L +922 697 L +1172 589 L +486 -65 V +970 -37 V +4067 473 L +% End plot #2 +% Begin plot #3 +stroke +LT2 +LCb setrgbcolor +2201 2639 M +[ [(Helvetica) 140.0 0.0 true true 0 (32 Threads)] +] -46.7 MRshow +LT2 +2285 2639 M +399 0 V +692 1319 M +18 -134 V +30 -176 V +801 845 L +922 690 L +1173 582 L +485 -60 V +970 -36 V +4067 472 L +% End plot #3 +% Begin plot #4 +stroke +LT3 +LCb setrgbcolor +2201 2499 M +[ [(Helvetica) 140.0 0.0 true true 0 (128 Threads)] +] -46.7 MRshow +LT3 +2285 2499 M +399 0 V +693 1386 M +18 -167 V +30 -161 V +801 865 L +923 711 L +1173 595 L +485 -67 V +970 -39 V +4067 474 L +% End plot #4 +% Begin plot #5 +stroke +LT4 +LCb setrgbcolor +2201 2359 M +[ [(Helvetica) 140.0 0.0 true true 0 (512 Threads)] +] -46.7 MRshow +LT4 +2285 2359 M +399 0 V +692 1425 M +19 -158 V +30 -179 V +802 892 L +923 725 L +1173 602 L +485 -70 V +970 -40 V +4067 476 L +% End plot #5 +stroke +1.000 UL +LTb +602 2855 M +602 448 L +3465 0 V +0 2407 R +-3465 0 R +1.000 UP +stroke +grestore +end +showpage +%%Trailer +%%DocumentFonts: Helvetica +%%Pages: 1 diff -r 9b9a2497757d -r eb146c5c05a8 0__Papers/PRT/PRT__formal_def/figures/plots_exec_vs_task_size/not_used/cray1_pthreads_8_32_128_512thds__o30000__perfCtrs.result.eps --- /dev/null Thu Jan 01 00:00:00 1970 +0000 +++ b/0__Papers/PRT/PRT__formal_def/figures/plots_exec_vs_task_size/not_used/cray1_pthreads_8_32_128_512thds__o30000__perfCtrs.result.eps Sat Aug 03 19:24:22 2013 -0700 @@ -0,0 +1,818 @@ +%!PS-Adobe-2.0 +%%Title: cray1_pthreads_8_32_128_512thds__o30000__perfCtrs.result.eps +%%Creator: gnuplot 4.4 patchlevel 2 +%%CreationDate: Thu Jan 26 18:08:51 2012 +%%DocumentFonts: (atend) +%%BoundingBox: 251 50 554 482 +%%Orientation: Landscape +%%Pages: (atend) +%%EndComments +%%BeginProlog +/gnudict 256 dict def +gnudict begin +% +% The following true/false flags may be edited by hand if desired. +% The unit line width and grayscale image gamma correction may also be changed. +% +/Color true def +/Blacktext false def +/Solid false def +/Dashlength 1 def +/Landscape true def +/Level1 false def +/Rounded false def +/ClipToBoundingBox false def +/TransparentPatterns false def +/gnulinewidth 5.000 def +/userlinewidth gnulinewidth def +/Gamma 1.0 def +% +/vshift -46 def +/dl1 { + 10.0 Dashlength mul mul + Rounded { currentlinewidth 0.75 mul sub dup 0 le { pop 0.01 } if } if +} def +/dl2 { + 10.0 Dashlength mul mul + Rounded { currentlinewidth 0.75 mul add } if +} def +/hpt_ 31.5 def +/vpt_ 31.5 def +/hpt hpt_ def +/vpt vpt_ def +Level1 {} { +/SDict 10 dict def +systemdict /pdfmark known not { + userdict /pdfmark systemdict /cleartomark get put +} if +SDict begin [ + /Title (cray1_pthreads_8_32_128_512thds__o30000__perfCtrs.result.eps) + /Subject (gnuplot plot) + /Creator (gnuplot 4.4 patchlevel 2) + /Author (msach) +% /Producer (gnuplot) +% /Keywords () + /CreationDate (Thu Jan 26 18:08:51 2012) + /DOCINFO pdfmark +end +} ifelse +/doclip { + ClipToBoundingBox { + newpath 251 50 moveto 554 50 lineto 554 482 lineto 251 482 lineto closepath + clip + } if +} def +% +% Gnuplot Prolog Version 4.4 (August 2010) +% +%/SuppressPDFMark true def +% +/M {moveto} bind def +/L {lineto} bind def +/R {rmoveto} bind def +/V {rlineto} bind def +/N {newpath moveto} bind def +/Z {closepath} bind def +/C {setrgbcolor} bind def +/f {rlineto fill} bind def +/g {setgray} bind def +/Gshow {show} def % May be redefined later in the file to support UTF-8 +/vpt2 vpt 2 mul def +/hpt2 hpt 2 mul def +/Lshow {currentpoint stroke M 0 vshift R + Blacktext {gsave 0 setgray show grestore} {show} ifelse} def +/Rshow {currentpoint stroke M dup stringwidth pop neg vshift R + Blacktext {gsave 0 setgray show grestore} {show} ifelse} def +/Cshow {currentpoint stroke M dup stringwidth pop -2 div vshift R + Blacktext {gsave 0 setgray show grestore} {show} ifelse} def +/UP {dup vpt_ mul /vpt exch def hpt_ mul /hpt exch def + /hpt2 hpt 2 mul def /vpt2 vpt 2 mul def} def +/DL {Color {setrgbcolor Solid {pop []} if 0 setdash} + {pop pop pop 0 setgray Solid {pop []} if 0 setdash} ifelse} def +/BL {stroke userlinewidth 2 mul setlinewidth + Rounded {1 setlinejoin 1 setlinecap} if} def +/AL {stroke userlinewidth 2 div setlinewidth + Rounded {1 setlinejoin 1 setlinecap} if} def +/UL {dup gnulinewidth mul /userlinewidth exch def + dup 1 lt {pop 1} if 10 mul /udl exch def} def +/PL {stroke userlinewidth setlinewidth + Rounded {1 setlinejoin 1 setlinecap} if} def +3.8 setmiterlimit +% Default Line colors +/LCw {1 1 1} def +/LCb {0 0 0} def +/LCa {0 0 0} def +/LC0 {1 0 0} def +/LC1 {0 1 0} def +/LC2 {0 0 1} def +/LC3 {1 0 1} def +/LC4 {0 1 1} def +/LC5 {1 1 0} def +/LC6 {0 0 0} def +/LC7 {1 0.3 0} def +/LC8 {0.5 0.5 0.5} def +% Default Line Types +/LTw {PL [] 1 setgray} def +/LTb {BL [] LCb DL} def +/LTa {AL [1 udl mul 2 udl mul] 0 setdash LCa setrgbcolor} def +/LT0 {PL [] LC0 DL} def +/LT1 {PL [4 dl1 2 dl2] LC1 DL} def +/LT2 {PL [2 dl1 3 dl2] LC2 DL} def +/LT3 {PL [1 dl1 1.5 dl2] LC3 DL} def +/LT4 {PL [6 dl1 2 dl2 1 dl1 2 dl2] LC4 DL} def +/LT5 {PL [3 dl1 3 dl2 1 dl1 3 dl2] LC5 DL} def +/LT6 {PL [2 dl1 2 dl2 2 dl1 6 dl2] LC6 DL} def +/LT7 {PL [1 dl1 2 dl2 6 dl1 2 dl2 1 dl1 2 dl2] LC7 DL} def +/LT8 {PL [2 dl1 2 dl2 2 dl1 2 dl2 2 dl1 2 dl2 2 dl1 4 dl2] LC8 DL} def +/Pnt {stroke [] 0 setdash gsave 1 setlinecap M 0 0 V stroke grestore} def +/Dia {stroke [] 0 setdash 2 copy vpt add M + hpt neg vpt neg V hpt vpt neg V + hpt vpt V hpt neg vpt V closepath stroke + Pnt} def +/Pls {stroke [] 0 setdash vpt sub M 0 vpt2 V + currentpoint stroke M + hpt neg vpt neg R hpt2 0 V stroke + } def +/Box {stroke [] 0 setdash 2 copy exch hpt sub exch vpt add M + 0 vpt2 neg V hpt2 0 V 0 vpt2 V + hpt2 neg 0 V closepath stroke + Pnt} def +/Crs {stroke [] 0 setdash exch hpt sub exch vpt add M + hpt2 vpt2 neg V currentpoint stroke M + hpt2 neg 0 R hpt2 vpt2 V stroke} def +/TriU {stroke [] 0 setdash 2 copy vpt 1.12 mul add M + hpt neg vpt -1.62 mul V + hpt 2 mul 0 V + hpt neg vpt 1.62 mul V closepath stroke + Pnt} def +/Star {2 copy Pls Crs} def +/BoxF {stroke [] 0 setdash exch hpt sub exch vpt add M + 0 vpt2 neg V hpt2 0 V 0 vpt2 V + hpt2 neg 0 V closepath fill} def +/TriUF {stroke [] 0 setdash vpt 1.12 mul add M + hpt neg vpt -1.62 mul V + hpt 2 mul 0 V + hpt neg vpt 1.62 mul V closepath fill} def +/TriD {stroke [] 0 setdash 2 copy vpt 1.12 mul sub M + hpt neg vpt 1.62 mul V + hpt 2 mul 0 V + hpt neg vpt -1.62 mul V closepath stroke + Pnt} def +/TriDF {stroke [] 0 setdash vpt 1.12 mul sub M + hpt neg vpt 1.62 mul V + hpt 2 mul 0 V + hpt neg vpt -1.62 mul V closepath fill} def +/DiaF {stroke [] 0 setdash vpt add M + hpt neg vpt neg V hpt vpt neg V + hpt vpt V hpt neg vpt V closepath fill} def +/Pent {stroke [] 0 setdash 2 copy gsave + translate 0 hpt M 4 {72 rotate 0 hpt L} repeat + closepath stroke grestore Pnt} def +/PentF {stroke [] 0 setdash gsave + translate 0 hpt M 4 {72 rotate 0 hpt L} repeat + closepath fill grestore} def +/Circle {stroke [] 0 setdash 2 copy + hpt 0 360 arc stroke Pnt} def +/CircleF {stroke [] 0 setdash hpt 0 360 arc fill} def +/C0 {BL [] 0 setdash 2 copy moveto vpt 90 450 arc} bind def +/C1 {BL [] 0 setdash 2 copy moveto + 2 copy vpt 0 90 arc closepath fill + vpt 0 360 arc closepath} bind def +/C2 {BL [] 0 setdash 2 copy moveto + 2 copy vpt 90 180 arc closepath fill + vpt 0 360 arc closepath} bind def +/C3 {BL [] 0 setdash 2 copy moveto + 2 copy vpt 0 180 arc closepath fill + vpt 0 360 arc closepath} bind def +/C4 {BL [] 0 setdash 2 copy moveto + 2 copy vpt 180 270 arc closepath fill + vpt 0 360 arc closepath} bind def +/C5 {BL [] 0 setdash 2 copy moveto + 2 copy vpt 0 90 arc + 2 copy moveto + 2 copy vpt 180 270 arc closepath fill + vpt 0 360 arc} bind def +/C6 {BL [] 0 setdash 2 copy moveto + 2 copy vpt 90 270 arc closepath fill + vpt 0 360 arc closepath} bind def +/C7 {BL [] 0 setdash 2 copy moveto + 2 copy vpt 0 270 arc closepath fill + vpt 0 360 arc closepath} bind def +/C8 {BL [] 0 setdash 2 copy moveto + 2 copy vpt 270 360 arc closepath fill + vpt 0 360 arc closepath} bind def +/C9 {BL [] 0 setdash 2 copy moveto + 2 copy vpt 270 450 arc closepath fill + vpt 0 360 arc closepath} bind def +/C10 {BL [] 0 setdash 2 copy 2 copy moveto vpt 270 360 arc closepath fill + 2 copy moveto + 2 copy vpt 90 180 arc closepath fill + vpt 0 360 arc closepath} bind def +/C11 {BL [] 0 setdash 2 copy moveto + 2 copy vpt 0 180 arc closepath fill + 2 copy moveto + 2 copy vpt 270 360 arc closepath fill + vpt 0 360 arc closepath} bind def +/C12 {BL [] 0 setdash 2 copy moveto + 2 copy vpt 180 360 arc closepath fill + vpt 0 360 arc closepath} bind def +/C13 {BL [] 0 setdash 2 copy moveto + 2 copy vpt 0 90 arc closepath fill + 2 copy moveto + 2 copy vpt 180 360 arc closepath fill + vpt 0 360 arc closepath} bind def +/C14 {BL [] 0 setdash 2 copy moveto + 2 copy vpt 90 360 arc closepath fill + vpt 0 360 arc} bind def +/C15 {BL [] 0 setdash 2 copy vpt 0 360 arc closepath fill + vpt 0 360 arc closepath} bind def +/Rec {newpath 4 2 roll moveto 1 index 0 rlineto 0 exch rlineto + neg 0 rlineto closepath} bind def +/Square {dup Rec} bind def +/Bsquare {vpt sub exch vpt sub exch vpt2 Square} bind def +/S0 {BL [] 0 setdash 2 copy moveto 0 vpt rlineto BL Bsquare} bind def +/S1 {BL [] 0 setdash 2 copy vpt Square fill Bsquare} bind def +/S2 {BL [] 0 setdash 2 copy exch vpt sub exch vpt Square fill Bsquare} bind def +/S3 {BL [] 0 setdash 2 copy exch vpt sub exch vpt2 vpt Rec fill Bsquare} bind def +/S4 {BL [] 0 setdash 2 copy exch vpt sub exch vpt sub vpt Square fill Bsquare} bind def +/S5 {BL [] 0 setdash 2 copy 2 copy vpt Square fill + exch vpt sub exch vpt sub vpt Square fill Bsquare} bind def +/S6 {BL [] 0 setdash 2 copy exch vpt sub exch vpt sub vpt vpt2 Rec fill Bsquare} bind def +/S7 {BL [] 0 setdash 2 copy exch vpt sub exch vpt sub vpt vpt2 Rec fill + 2 copy vpt Square fill Bsquare} bind def +/S8 {BL [] 0 setdash 2 copy vpt sub vpt Square fill Bsquare} bind def +/S9 {BL [] 0 setdash 2 copy vpt sub vpt vpt2 Rec fill Bsquare} bind def +/S10 {BL [] 0 setdash 2 copy vpt sub vpt Square fill 2 copy exch vpt sub exch vpt Square fill + Bsquare} bind def +/S11 {BL [] 0 setdash 2 copy vpt sub vpt Square fill 2 copy exch vpt sub exch vpt2 vpt Rec fill + Bsquare} bind def +/S12 {BL [] 0 setdash 2 copy exch vpt sub exch vpt sub vpt2 vpt Rec fill Bsquare} bind def +/S13 {BL [] 0 setdash 2 copy exch vpt sub exch vpt sub vpt2 vpt Rec fill + 2 copy vpt Square fill Bsquare} bind def +/S14 {BL [] 0 setdash 2 copy exch vpt sub exch vpt sub vpt2 vpt Rec fill + 2 copy exch vpt sub exch vpt Square fill Bsquare} bind def +/S15 {BL [] 0 setdash 2 copy Bsquare fill Bsquare} bind def +/D0 {gsave translate 45 rotate 0 0 S0 stroke grestore} bind def +/D1 {gsave translate 45 rotate 0 0 S1 stroke grestore} bind def +/D2 {gsave translate 45 rotate 0 0 S2 stroke grestore} bind def +/D3 {gsave translate 45 rotate 0 0 S3 stroke grestore} bind def +/D4 {gsave translate 45 rotate 0 0 S4 stroke grestore} bind def +/D5 {gsave translate 45 rotate 0 0 S5 stroke grestore} bind def +/D6 {gsave translate 45 rotate 0 0 S6 stroke grestore} bind def +/D7 {gsave translate 45 rotate 0 0 S7 stroke grestore} bind def +/D8 {gsave translate 45 rotate 0 0 S8 stroke grestore} bind def +/D9 {gsave translate 45 rotate 0 0 S9 stroke grestore} bind def +/D10 {gsave translate 45 rotate 0 0 S10 stroke grestore} bind def +/D11 {gsave translate 45 rotate 0 0 S11 stroke grestore} bind def +/D12 {gsave translate 45 rotate 0 0 S12 stroke grestore} bind def +/D13 {gsave translate 45 rotate 0 0 S13 stroke grestore} bind def +/D14 {gsave translate 45 rotate 0 0 S14 stroke grestore} bind def +/D15 {gsave translate 45 rotate 0 0 S15 stroke grestore} bind def +/DiaE {stroke [] 0 setdash vpt add M + hpt neg vpt neg V hpt vpt neg V + hpt vpt V hpt neg vpt V closepath stroke} def +/BoxE {stroke [] 0 setdash exch hpt sub exch vpt add M + 0 vpt2 neg V hpt2 0 V 0 vpt2 V + hpt2 neg 0 V closepath stroke} def +/TriUE {stroke [] 0 setdash vpt 1.12 mul add M + hpt neg vpt -1.62 mul V + hpt 2 mul 0 V + hpt neg vpt 1.62 mul V closepath stroke} def +/TriDE {stroke [] 0 setdash vpt 1.12 mul sub M + hpt neg vpt 1.62 mul V + hpt 2 mul 0 V + hpt neg vpt -1.62 mul V closepath stroke} def +/PentE {stroke [] 0 setdash gsave + translate 0 hpt M 4 {72 rotate 0 hpt L} repeat + closepath stroke grestore} def +/CircE {stroke [] 0 setdash + hpt 0 360 arc stroke} def +/Opaque {gsave closepath 1 setgray fill grestore 0 setgray closepath} def +/DiaW {stroke [] 0 setdash vpt add M + hpt neg vpt neg V hpt vpt neg V + hpt vpt V hpt neg vpt V Opaque stroke} def +/BoxW {stroke [] 0 setdash exch hpt sub exch vpt add M + 0 vpt2 neg V hpt2 0 V 0 vpt2 V + hpt2 neg 0 V Opaque stroke} def +/TriUW {stroke [] 0 setdash vpt 1.12 mul add M + hpt neg vpt -1.62 mul V + hpt 2 mul 0 V + hpt neg vpt 1.62 mul V Opaque stroke} def +/TriDW {stroke [] 0 setdash vpt 1.12 mul sub M + hpt neg vpt 1.62 mul V + hpt 2 mul 0 V + hpt neg vpt -1.62 mul V Opaque stroke} def +/PentW {stroke [] 0 setdash gsave + translate 0 hpt M 4 {72 rotate 0 hpt L} repeat + Opaque stroke grestore} def +/CircW {stroke [] 0 setdash + hpt 0 360 arc Opaque stroke} def +/BoxFill {gsave Rec 1 setgray fill grestore} def +/Density { + /Fillden exch def + currentrgbcolor + /ColB exch def /ColG exch def /ColR exch def + /ColR ColR Fillden mul Fillden sub 1 add def + /ColG ColG Fillden mul Fillden sub 1 add def + /ColB ColB Fillden mul Fillden sub 1 add def + ColR ColG ColB setrgbcolor} def +/BoxColFill {gsave Rec PolyFill} def +/PolyFill {gsave Density fill grestore grestore} def +/h {rlineto rlineto rlineto gsave closepath fill grestore} bind def +% +% PostScript Level 1 Pattern Fill routine for rectangles +% Usage: x y w h s a XX PatternFill +% x,y = lower left corner of box to be filled +% w,h = width and height of box +% a = angle in degrees between lines and x-axis +% XX = 0/1 for no/yes cross-hatch +% +/PatternFill {gsave /PFa [ 9 2 roll ] def + PFa 0 get PFa 2 get 2 div add PFa 1 get PFa 3 get 2 div add translate + PFa 2 get -2 div PFa 3 get -2 div PFa 2 get PFa 3 get Rec + gsave 1 setgray fill grestore clip + currentlinewidth 0.5 mul setlinewidth + /PFs PFa 2 get dup mul PFa 3 get dup mul add sqrt def + 0 0 M PFa 5 get rotate PFs -2 div dup translate + 0 1 PFs PFa 4 get div 1 add floor cvi + {PFa 4 get mul 0 M 0 PFs V} for + 0 PFa 6 get ne { + 0 1 PFs PFa 4 get div 1 add floor cvi + {PFa 4 get mul 0 2 1 roll M PFs 0 V} for + } if + stroke grestore} def +% +/languagelevel where + {pop languagelevel} {1} ifelse + 2 lt + {/InterpretLevel1 true def} + {/InterpretLevel1 Level1 def} + ifelse +% +% PostScript level 2 pattern fill definitions +% +/Level2PatternFill { +/Tile8x8 {/PaintType 2 /PatternType 1 /TilingType 1 /BBox [0 0 8 8] /XStep 8 /YStep 8} + bind def +/KeepColor {currentrgbcolor [/Pattern /DeviceRGB] setcolorspace} bind def +<< Tile8x8 + /PaintProc {0.5 setlinewidth pop 0 0 M 8 8 L 0 8 M 8 0 L stroke} +>> matrix makepattern +/Pat1 exch def +<< Tile8x8 + /PaintProc {0.5 setlinewidth pop 0 0 M 8 8 L 0 8 M 8 0 L stroke + 0 4 M 4 8 L 8 4 L 4 0 L 0 4 L stroke} +>> matrix makepattern +/Pat2 exch def +<< Tile8x8 + /PaintProc {0.5 setlinewidth pop 0 0 M 0 8 L + 8 8 L 8 0 L 0 0 L fill} +>> matrix makepattern +/Pat3 exch def +<< Tile8x8 + /PaintProc {0.5 setlinewidth pop -4 8 M 8 -4 L + 0 12 M 12 0 L stroke} +>> matrix makepattern +/Pat4 exch def +<< Tile8x8 + /PaintProc {0.5 setlinewidth pop -4 0 M 8 12 L + 0 -4 M 12 8 L stroke} +>> matrix makepattern +/Pat5 exch def +<< Tile8x8 + /PaintProc {0.5 setlinewidth pop -2 8 M 4 -4 L + 0 12 M 8 -4 L 4 12 M 10 0 L stroke} +>> matrix makepattern +/Pat6 exch def +<< Tile8x8 + /PaintProc {0.5 setlinewidth pop -2 0 M 4 12 L + 0 -4 M 8 12 L 4 -4 M 10 8 L stroke} +>> matrix makepattern +/Pat7 exch def +<< Tile8x8 + /PaintProc {0.5 setlinewidth pop 8 -2 M -4 4 L + 12 0 M -4 8 L 12 4 M 0 10 L stroke} +>> matrix makepattern +/Pat8 exch def +<< Tile8x8 + /PaintProc {0.5 setlinewidth pop 0 -2 M 12 4 L + -4 0 M 12 8 L -4 4 M 8 10 L stroke} +>> matrix makepattern +/Pat9 exch def +/Pattern1 {PatternBgnd KeepColor Pat1 setpattern} bind def +/Pattern2 {PatternBgnd KeepColor Pat2 setpattern} bind def +/Pattern3 {PatternBgnd KeepColor Pat3 setpattern} bind def +/Pattern4 {PatternBgnd KeepColor Landscape {Pat5} {Pat4} ifelse setpattern} bind def +/Pattern5 {PatternBgnd KeepColor Landscape {Pat4} {Pat5} ifelse setpattern} bind def +/Pattern6 {PatternBgnd KeepColor Landscape {Pat9} {Pat6} ifelse setpattern} bind def +/Pattern7 {PatternBgnd KeepColor Landscape {Pat8} {Pat7} ifelse setpattern} bind def +} def +% +% +%End of PostScript Level 2 code +% +/PatternBgnd { + TransparentPatterns {} {gsave 1 setgray fill grestore} ifelse +} def +% +% Substitute for Level 2 pattern fill codes with +% grayscale if Level 2 support is not selected. +% +/Level1PatternFill { +/Pattern1 {0.250 Density} bind def +/Pattern2 {0.500 Density} bind def +/Pattern3 {0.750 Density} bind def +/Pattern4 {0.125 Density} bind def +/Pattern5 {0.375 Density} bind def +/Pattern6 {0.625 Density} bind def +/Pattern7 {0.875 Density} bind def +} def +% +% Now test for support of Level 2 code +% +Level1 {Level1PatternFill} {Level2PatternFill} ifelse +% +/Symbol-Oblique /Symbol findfont [1 0 .167 1 0 0] makefont +dup length dict begin {1 index /FID eq {pop pop} {def} ifelse} forall +currentdict end definefont pop +/MFshow { + { dup 5 get 3 ge + { 5 get 3 eq {gsave} {grestore} ifelse } + {dup dup 0 get findfont exch 1 get scalefont setfont + [ currentpoint ] exch dup 2 get 0 exch R dup 5 get 2 ne {dup dup 6 + get exch 4 get {Gshow} {stringwidth pop 0 R} ifelse }if dup 5 get 0 eq + {dup 3 get {2 get neg 0 exch R pop} {pop aload pop M} ifelse} {dup 5 + get 1 eq {dup 2 get exch dup 3 get exch 6 get stringwidth pop -2 div + dup 0 R} {dup 6 get stringwidth pop -2 div 0 R 6 get + show 2 index {aload pop M neg 3 -1 roll neg R pop pop} {pop pop pop + pop aload pop M} ifelse }ifelse }ifelse } + ifelse } + forall} def +/Gswidth {dup type /stringtype eq {stringwidth} {pop (n) stringwidth} ifelse} def +/MFwidth {0 exch { dup 5 get 3 ge { 5 get 3 eq { 0 } { pop } ifelse } + {dup 3 get{dup dup 0 get findfont exch 1 get scalefont setfont + 6 get Gswidth pop add} {pop} ifelse} ifelse} forall} def +/MLshow { currentpoint stroke M + 0 exch R + Blacktext {gsave 0 setgray MFshow grestore} {MFshow} ifelse } bind def +/MRshow { currentpoint stroke M + exch dup MFwidth neg 3 -1 roll R + Blacktext {gsave 0 setgray MFshow grestore} {MFshow} ifelse } bind def +/MCshow { currentpoint stroke M + exch dup MFwidth -2 div 3 -1 roll R + Blacktext {gsave 0 setgray MFshow grestore} {MFshow} ifelse } bind def +/XYsave { [( ) 1 2 true false 3 ()] } bind def +/XYrestore { [( ) 1 2 true false 4 ()] } bind def +end +%%EndProlog +%%Page: 1 1 +gnudict begin +gsave +doclip +50 50 translate +0.100 0.100 scale +90 rotate +0 -5040 translate +0 setgray +newpath +(Helvetica) findfont 140 scalefont setfont +1.000 UL +LTb +518 448 M +63 0 V +stroke +434 448 M +[ [(Helvetica) 140.0 0.0 true true 0 ( 1)] +] -46.7 MRshow +1.000 UL +LTb +518 792 M +63 0 V +stroke +434 792 M +[ [(Helvetica) 140.0 0.0 true true 0 ( 2)] +] -46.7 MRshow +1.000 UL +LTb +518 1136 M +63 0 V +stroke +434 1136 M +[ [(Helvetica) 140.0 0.0 true true 0 ( 3)] +] -46.7 MRshow +1.000 UL +LTb +518 1480 M +63 0 V +stroke +434 1480 M +[ [(Helvetica) 140.0 0.0 true true 0 ( 4)] +] -46.7 MRshow +1.000 UL +LTb +518 1823 M +63 0 V +stroke +434 1823 M +[ [(Helvetica) 140.0 0.0 true true 0 ( 5)] +] -46.7 MRshow +1.000 UL +LTb +518 2167 M +63 0 V +stroke +434 2167 M +[ [(Helvetica) 140.0 0.0 true true 0 ( 6)] +] -46.7 MRshow +1.000 UL +LTb +518 2511 M +63 0 V +stroke +434 2511 M +[ [(Helvetica) 140.0 0.0 true true 0 ( 7)] +] -46.7 MRshow +1.000 UL +LTb +518 2855 M +63 0 V +stroke +434 2855 M +[ [(Helvetica) 140.0 0.0 true true 0 ( 8)] +] -46.7 MRshow +1.000 UL +LTb +518 448 M +0 63 V +stroke +518 308 M +[ [(Helvetica) 140.0 0.0 true true 0 ( 0)] +] -46.7 MCshow +1.000 UL +LTb +962 448 M +0 63 V +stroke +962 308 M +[ [(Helvetica) 140.0 0.0 true true 0 ( 1000)] +] -46.7 MCshow +1.000 UL +LTb +1405 448 M +0 63 V +stroke +1405 308 M +[ [(Helvetica) 140.0 0.0 true true 0 ( 2000)] +] -46.7 MCshow +1.000 UL +LTb +1849 448 M +0 63 V +stroke +1849 308 M +[ [(Helvetica) 140.0 0.0 true true 0 ( 3000)] +] -46.7 MCshow +1.000 UL +LTb +2293 448 M +0 63 V +stroke +2293 308 M +[ [(Helvetica) 140.0 0.0 true true 0 ( 4000)] +] -46.7 MCshow +1.000 UL +LTb +2736 448 M +0 63 V +stroke +2736 308 M +[ [(Helvetica) 140.0 0.0 true true 0 ( 5000)] +] -46.7 MCshow +1.000 UL +LTb +3180 448 M +0 63 V +stroke +3180 308 M +[ [(Helvetica) 140.0 0.0 true true 0 ( 6000)] +] -46.7 MCshow +1.000 UL +LTb +3623 448 M +0 63 V +stroke +3623 308 M +[ [(Helvetica) 140.0 0.0 true true 0 ( 7000)] +] -46.7 MCshow +1.000 UL +LTb +4067 448 M +0 63 V +stroke +4067 308 M +[ [(Helvetica) 140.0 0.0 true true 0 ( 8000)] +] -46.7 MCshow +1.000 UL +LTb +1.000 UL +LTb +518 2855 M +518 448 L +3549 0 V +0 2407 R +-3549 0 R +stroke +LCb setrgbcolor +112 1651 M +currentpoint gsave translate -270 rotate 0 0 moveto +[ [(Helvetica) 140.0 0.0 true true 0 (Ratio of Total Execution to Total Work)] +] -46.7 MCshow +grestore +LTb +LCb setrgbcolor +2292 98 M +[ [(Helvetica) 140.0 0.0 true true 0 (Cycles in one Task)] +] -46.7 MCshow +LTb +1.000 UP +1.000 UL +LTb +1.000 UL +LTb +2798 2538 N +0 420 V +1491 0 V +0 -420 V +-1491 0 V +Z stroke +2798 2958 M +1491 0 V +% Begin plot #1 +stroke +4.000 UL +LT1 +LCa setrgbcolor +518 792 M +36 0 V +36 0 V +36 0 V +35 0 V +36 0 V +36 0 V +36 0 V +36 0 V +36 0 V +35 0 V +36 0 V +36 0 V +36 0 V +36 0 V +36 0 V +36 0 V +35 0 V +36 0 V +36 0 V +36 0 V +36 0 V +36 0 V +36 0 V +35 0 V +36 0 V +36 0 V +36 0 V +36 0 V +36 0 V +35 0 V +36 0 V +36 0 V +36 0 V +36 0 V +36 0 V +36 0 V +35 0 V +36 0 V +36 0 V +36 0 V +36 0 V +36 0 V +35 0 V +36 0 V +36 0 V +36 0 V +36 0 V +36 0 V +36 0 V +35 0 V +36 0 V +36 0 V +36 0 V +36 0 V +36 0 V +36 0 V +35 0 V +36 0 V +36 0 V +36 0 V +36 0 V +36 0 V +35 0 V +36 0 V +36 0 V +36 0 V +36 0 V +36 0 V +36 0 V +35 0 V +36 0 V +36 0 V +36 0 V +36 0 V +36 0 V +35 0 V +36 0 V +36 0 V +36 0 V +36 0 V +36 0 V +36 0 V +35 0 V +36 0 V +36 0 V +36 0 V +36 0 V +36 0 V +36 0 V +35 0 V +36 0 V +36 0 V +36 0 V +36 0 V +36 0 V +35 0 V +36 0 V +36 0 V +36 0 V +% End plot #1 +% Begin plot #2 +stroke +LT1 +LCb setrgbcolor +3722 2888 M +[ [(Helvetica) 140.0 0.0 true true 0 (8 Threads)] +] -46.7 MRshow +LT1 +3806 2888 M +399 0 V +746 2855 M +848 2069 L +255 -711 V +1600 935 L +2594 699 L +4067 607 L +% End plot #2 +% Begin plot #3 +stroke +LT2 +LCb setrgbcolor +3722 2748 M +[ [(Helvetica) 140.0 0.0 true true 0 (32 Threads)] +] -46.7 MRshow +LT2 +3806 2748 M +399 0 V +1089 2855 M +15 -106 V +1605 1686 L +991 -594 V +4067 858 L +% End plot #3 +% Begin plot #4 +stroke +LT3 +LCb setrgbcolor +3722 2608 M +[ [(Helvetica) 140.0 0.0 true true 0 (128 Threads)] +] -46.7 MRshow +LT3 +3806 2608 M +399 0 V +2508 2855 M +97 -193 V +4067 1874 L +% End plot #4 +stroke +1.000 UL +LTb +518 2855 M +518 448 L +3549 0 V +0 2407 R +-3549 0 R +1.000 UP +stroke +grestore +end +showpage +%%Trailer +%%DocumentFonts: Helvetica +%%Pages: 1 diff -r 9b9a2497757d -r eb146c5c05a8 0__Papers/PRT/PRT__formal_def/figures/plots_exec_vs_task_size/not_used/cray1_vthread_8_32_128_512thds__o30000__perfCtrs.result.eps --- /dev/null Thu Jan 01 00:00:00 1970 +0000 +++ b/0__Papers/PRT/PRT__formal_def/figures/plots_exec_vs_task_size/not_used/cray1_vthread_8_32_128_512thds__o30000__perfCtrs.result.eps Sat Aug 03 19:24:22 2013 -0700 @@ -0,0 +1,851 @@ +%!PS-Adobe-2.0 +%%Title: cray1_vthread_8_32_128_512thds__o30000__perfCtrs.result.eps +%%Creator: gnuplot 4.4 patchlevel 2 +%%CreationDate: Thu Jan 26 18:09:54 2012 +%%DocumentFonts: (atend) +%%BoundingBox: 251 50 554 482 +%%Orientation: Landscape +%%Pages: (atend) +%%EndComments +%%BeginProlog +/gnudict 256 dict def +gnudict begin +% +% The following true/false flags may be edited by hand if desired. +% The unit line width and grayscale image gamma correction may also be changed. +% +/Color true def +/Blacktext false def +/Solid false def +/Dashlength 1 def +/Landscape true def +/Level1 false def +/Rounded false def +/ClipToBoundingBox false def +/TransparentPatterns false def +/gnulinewidth 5.000 def +/userlinewidth gnulinewidth def +/Gamma 1.0 def +% +/vshift -46 def +/dl1 { + 10.0 Dashlength mul mul + Rounded { currentlinewidth 0.75 mul sub dup 0 le { pop 0.01 } if } if +} def +/dl2 { + 10.0 Dashlength mul mul + Rounded { currentlinewidth 0.75 mul add } if +} def +/hpt_ 31.5 def +/vpt_ 31.5 def +/hpt hpt_ def +/vpt vpt_ def +Level1 {} { +/SDict 10 dict def +systemdict /pdfmark known not { + userdict /pdfmark systemdict /cleartomark get put +} if +SDict begin [ + /Title (cray1_vthread_8_32_128_512thds__o30000__perfCtrs.result.eps) + /Subject (gnuplot plot) + /Creator (gnuplot 4.4 patchlevel 2) + /Author (msach) +% /Producer (gnuplot) +% /Keywords () + /CreationDate (Thu Jan 26 18:09:54 2012) + /DOCINFO pdfmark +end +} ifelse +/doclip { + ClipToBoundingBox { + newpath 251 50 moveto 554 50 lineto 554 482 lineto 251 482 lineto closepath + clip + } if +} def +% +% Gnuplot Prolog Version 4.4 (August 2010) +% +%/SuppressPDFMark true def +% +/M {moveto} bind def +/L {lineto} bind def +/R {rmoveto} bind def +/V {rlineto} bind def +/N {newpath moveto} bind def +/Z {closepath} bind def +/C {setrgbcolor} bind def +/f {rlineto fill} bind def +/g {setgray} bind def +/Gshow {show} def % May be redefined later in the file to support UTF-8 +/vpt2 vpt 2 mul def +/hpt2 hpt 2 mul def +/Lshow {currentpoint stroke M 0 vshift R + Blacktext {gsave 0 setgray show grestore} {show} ifelse} def +/Rshow {currentpoint stroke M dup stringwidth pop neg vshift R + Blacktext {gsave 0 setgray show grestore} {show} ifelse} def +/Cshow {currentpoint stroke M dup stringwidth pop -2 div vshift R + Blacktext {gsave 0 setgray show grestore} {show} ifelse} def +/UP {dup vpt_ mul /vpt exch def hpt_ mul /hpt exch def + /hpt2 hpt 2 mul def /vpt2 vpt 2 mul def} def +/DL {Color {setrgbcolor Solid {pop []} if 0 setdash} + {pop pop pop 0 setgray Solid {pop []} if 0 setdash} ifelse} def +/BL {stroke userlinewidth 2 mul setlinewidth + Rounded {1 setlinejoin 1 setlinecap} if} def +/AL {stroke userlinewidth 2 div setlinewidth + Rounded {1 setlinejoin 1 setlinecap} if} def +/UL {dup gnulinewidth mul /userlinewidth exch def + dup 1 lt {pop 1} if 10 mul /udl exch def} def +/PL {stroke userlinewidth setlinewidth + Rounded {1 setlinejoin 1 setlinecap} if} def +3.8 setmiterlimit +% Default Line colors +/LCw {1 1 1} def +/LCb {0 0 0} def +/LCa {0 0 0} def +/LC0 {1 0 0} def +/LC1 {0 1 0} def +/LC2 {0 0 1} def +/LC3 {1 0 1} def +/LC4 {0 1 1} def +/LC5 {1 1 0} def +/LC6 {0 0 0} def +/LC7 {1 0.3 0} def +/LC8 {0.5 0.5 0.5} def +% Default Line Types +/LTw {PL [] 1 setgray} def +/LTb {BL [] LCb DL} def +/LTa {AL [1 udl mul 2 udl mul] 0 setdash LCa setrgbcolor} def +/LT0 {PL [] LC0 DL} def +/LT1 {PL [4 dl1 2 dl2] LC1 DL} def +/LT2 {PL [2 dl1 3 dl2] LC2 DL} def +/LT3 {PL [1 dl1 1.5 dl2] LC3 DL} def +/LT4 {PL [6 dl1 2 dl2 1 dl1 2 dl2] LC4 DL} def +/LT5 {PL [3 dl1 3 dl2 1 dl1 3 dl2] LC5 DL} def +/LT6 {PL [2 dl1 2 dl2 2 dl1 6 dl2] LC6 DL} def +/LT7 {PL [1 dl1 2 dl2 6 dl1 2 dl2 1 dl1 2 dl2] LC7 DL} def +/LT8 {PL [2 dl1 2 dl2 2 dl1 2 dl2 2 dl1 2 dl2 2 dl1 4 dl2] LC8 DL} def +/Pnt {stroke [] 0 setdash gsave 1 setlinecap M 0 0 V stroke grestore} def +/Dia {stroke [] 0 setdash 2 copy vpt add M + hpt neg vpt neg V hpt vpt neg V + hpt vpt V hpt neg vpt V closepath stroke + Pnt} def +/Pls {stroke [] 0 setdash vpt sub M 0 vpt2 V + currentpoint stroke M + hpt neg vpt neg R hpt2 0 V stroke + } def +/Box {stroke [] 0 setdash 2 copy exch hpt sub exch vpt add M + 0 vpt2 neg V hpt2 0 V 0 vpt2 V + hpt2 neg 0 V closepath stroke + Pnt} def +/Crs {stroke [] 0 setdash exch hpt sub exch vpt add M + hpt2 vpt2 neg V currentpoint stroke M + hpt2 neg 0 R hpt2 vpt2 V stroke} def +/TriU {stroke [] 0 setdash 2 copy vpt 1.12 mul add M + hpt neg vpt -1.62 mul V + hpt 2 mul 0 V + hpt neg vpt 1.62 mul V closepath stroke + Pnt} def +/Star {2 copy Pls Crs} def +/BoxF {stroke [] 0 setdash exch hpt sub exch vpt add M + 0 vpt2 neg V hpt2 0 V 0 vpt2 V + hpt2 neg 0 V closepath fill} def +/TriUF {stroke [] 0 setdash vpt 1.12 mul add M + hpt neg vpt -1.62 mul V + hpt 2 mul 0 V + hpt neg vpt 1.62 mul V closepath fill} def +/TriD {stroke [] 0 setdash 2 copy vpt 1.12 mul sub M + hpt neg vpt 1.62 mul V + hpt 2 mul 0 V + hpt neg vpt -1.62 mul V closepath stroke + Pnt} def +/TriDF {stroke [] 0 setdash vpt 1.12 mul sub M + hpt neg vpt 1.62 mul V + hpt 2 mul 0 V + hpt neg vpt -1.62 mul V closepath fill} def +/DiaF {stroke [] 0 setdash vpt add M + hpt neg vpt neg V hpt vpt neg V + hpt vpt V hpt neg vpt V closepath fill} def +/Pent {stroke [] 0 setdash 2 copy gsave + translate 0 hpt M 4 {72 rotate 0 hpt L} repeat + closepath stroke grestore Pnt} def +/PentF {stroke [] 0 setdash gsave + translate 0 hpt M 4 {72 rotate 0 hpt L} repeat + closepath fill grestore} def +/Circle {stroke [] 0 setdash 2 copy + hpt 0 360 arc stroke Pnt} def +/CircleF {stroke [] 0 setdash hpt 0 360 arc fill} def +/C0 {BL [] 0 setdash 2 copy moveto vpt 90 450 arc} bind def +/C1 {BL [] 0 setdash 2 copy moveto + 2 copy vpt 0 90 arc closepath fill + vpt 0 360 arc closepath} bind def +/C2 {BL [] 0 setdash 2 copy moveto + 2 copy vpt 90 180 arc closepath fill + vpt 0 360 arc closepath} bind def +/C3 {BL [] 0 setdash 2 copy moveto + 2 copy vpt 0 180 arc closepath fill + vpt 0 360 arc closepath} bind def +/C4 {BL [] 0 setdash 2 copy moveto + 2 copy vpt 180 270 arc closepath fill + vpt 0 360 arc closepath} bind def +/C5 {BL [] 0 setdash 2 copy moveto + 2 copy vpt 0 90 arc + 2 copy moveto + 2 copy vpt 180 270 arc closepath fill + vpt 0 360 arc} bind def +/C6 {BL [] 0 setdash 2 copy moveto + 2 copy vpt 90 270 arc closepath fill + vpt 0 360 arc closepath} bind def +/C7 {BL [] 0 setdash 2 copy moveto + 2 copy vpt 0 270 arc closepath fill + vpt 0 360 arc closepath} bind def +/C8 {BL [] 0 setdash 2 copy moveto + 2 copy vpt 270 360 arc closepath fill + vpt 0 360 arc closepath} bind def +/C9 {BL [] 0 setdash 2 copy moveto + 2 copy vpt 270 450 arc closepath fill + vpt 0 360 arc closepath} bind def +/C10 {BL [] 0 setdash 2 copy 2 copy moveto vpt 270 360 arc closepath fill + 2 copy moveto + 2 copy vpt 90 180 arc closepath fill + vpt 0 360 arc closepath} bind def +/C11 {BL [] 0 setdash 2 copy moveto + 2 copy vpt 0 180 arc closepath fill + 2 copy moveto + 2 copy vpt 270 360 arc closepath fill + vpt 0 360 arc closepath} bind def +/C12 {BL [] 0 setdash 2 copy moveto + 2 copy vpt 180 360 arc closepath fill + vpt 0 360 arc closepath} bind def +/C13 {BL [] 0 setdash 2 copy moveto + 2 copy vpt 0 90 arc closepath fill + 2 copy moveto + 2 copy vpt 180 360 arc closepath fill + vpt 0 360 arc closepath} bind def +/C14 {BL [] 0 setdash 2 copy moveto + 2 copy vpt 90 360 arc closepath fill + vpt 0 360 arc} bind def +/C15 {BL [] 0 setdash 2 copy vpt 0 360 arc closepath fill + vpt 0 360 arc closepath} bind def +/Rec {newpath 4 2 roll moveto 1 index 0 rlineto 0 exch rlineto + neg 0 rlineto closepath} bind def +/Square {dup Rec} bind def +/Bsquare {vpt sub exch vpt sub exch vpt2 Square} bind def +/S0 {BL [] 0 setdash 2 copy moveto 0 vpt rlineto BL Bsquare} bind def +/S1 {BL [] 0 setdash 2 copy vpt Square fill Bsquare} bind def +/S2 {BL [] 0 setdash 2 copy exch vpt sub exch vpt Square fill Bsquare} bind def +/S3 {BL [] 0 setdash 2 copy exch vpt sub exch vpt2 vpt Rec fill Bsquare} bind def +/S4 {BL [] 0 setdash 2 copy exch vpt sub exch vpt sub vpt Square fill Bsquare} bind def +/S5 {BL [] 0 setdash 2 copy 2 copy vpt Square fill + exch vpt sub exch vpt sub vpt Square fill Bsquare} bind def +/S6 {BL [] 0 setdash 2 copy exch vpt sub exch vpt sub vpt vpt2 Rec fill Bsquare} bind def +/S7 {BL [] 0 setdash 2 copy exch vpt sub exch vpt sub vpt vpt2 Rec fill + 2 copy vpt Square fill Bsquare} bind def +/S8 {BL [] 0 setdash 2 copy vpt sub vpt Square fill Bsquare} bind def +/S9 {BL [] 0 setdash 2 copy vpt sub vpt vpt2 Rec fill Bsquare} bind def +/S10 {BL [] 0 setdash 2 copy vpt sub vpt Square fill 2 copy exch vpt sub exch vpt Square fill + Bsquare} bind def +/S11 {BL [] 0 setdash 2 copy vpt sub vpt Square fill 2 copy exch vpt sub exch vpt2 vpt Rec fill + Bsquare} bind def +/S12 {BL [] 0 setdash 2 copy exch vpt sub exch vpt sub vpt2 vpt Rec fill Bsquare} bind def +/S13 {BL [] 0 setdash 2 copy exch vpt sub exch vpt sub vpt2 vpt Rec fill + 2 copy vpt Square fill Bsquare} bind def +/S14 {BL [] 0 setdash 2 copy exch vpt sub exch vpt sub vpt2 vpt Rec fill + 2 copy exch vpt sub exch vpt Square fill Bsquare} bind def +/S15 {BL [] 0 setdash 2 copy Bsquare fill Bsquare} bind def +/D0 {gsave translate 45 rotate 0 0 S0 stroke grestore} bind def +/D1 {gsave translate 45 rotate 0 0 S1 stroke grestore} bind def +/D2 {gsave translate 45 rotate 0 0 S2 stroke grestore} bind def +/D3 {gsave translate 45 rotate 0 0 S3 stroke grestore} bind def +/D4 {gsave translate 45 rotate 0 0 S4 stroke grestore} bind def +/D5 {gsave translate 45 rotate 0 0 S5 stroke grestore} bind def +/D6 {gsave translate 45 rotate 0 0 S6 stroke grestore} bind def +/D7 {gsave translate 45 rotate 0 0 S7 stroke grestore} bind def +/D8 {gsave translate 45 rotate 0 0 S8 stroke grestore} bind def +/D9 {gsave translate 45 rotate 0 0 S9 stroke grestore} bind def +/D10 {gsave translate 45 rotate 0 0 S10 stroke grestore} bind def +/D11 {gsave translate 45 rotate 0 0 S11 stroke grestore} bind def +/D12 {gsave translate 45 rotate 0 0 S12 stroke grestore} bind def +/D13 {gsave translate 45 rotate 0 0 S13 stroke grestore} bind def +/D14 {gsave translate 45 rotate 0 0 S14 stroke grestore} bind def +/D15 {gsave translate 45 rotate 0 0 S15 stroke grestore} bind def +/DiaE {stroke [] 0 setdash vpt add M + hpt neg vpt neg V hpt vpt neg V + hpt vpt V hpt neg vpt V closepath stroke} def +/BoxE {stroke [] 0 setdash exch hpt sub exch vpt add M + 0 vpt2 neg V hpt2 0 V 0 vpt2 V + hpt2 neg 0 V closepath stroke} def +/TriUE {stroke [] 0 setdash vpt 1.12 mul add M + hpt neg vpt -1.62 mul V + hpt 2 mul 0 V + hpt neg vpt 1.62 mul V closepath stroke} def +/TriDE {stroke [] 0 setdash vpt 1.12 mul sub M + hpt neg vpt 1.62 mul V + hpt 2 mul 0 V + hpt neg vpt -1.62 mul V closepath stroke} def +/PentE {stroke [] 0 setdash gsave + translate 0 hpt M 4 {72 rotate 0 hpt L} repeat + closepath stroke grestore} def +/CircE {stroke [] 0 setdash + hpt 0 360 arc stroke} def +/Opaque {gsave closepath 1 setgray fill grestore 0 setgray closepath} def +/DiaW {stroke [] 0 setdash vpt add M + hpt neg vpt neg V hpt vpt neg V + hpt vpt V hpt neg vpt V Opaque stroke} def +/BoxW {stroke [] 0 setdash exch hpt sub exch vpt add M + 0 vpt2 neg V hpt2 0 V 0 vpt2 V + hpt2 neg 0 V Opaque stroke} def +/TriUW {stroke [] 0 setdash vpt 1.12 mul add M + hpt neg vpt -1.62 mul V + hpt 2 mul 0 V + hpt neg vpt 1.62 mul V Opaque stroke} def +/TriDW {stroke [] 0 setdash vpt 1.12 mul sub M + hpt neg vpt 1.62 mul V + hpt 2 mul 0 V + hpt neg vpt -1.62 mul V Opaque stroke} def +/PentW {stroke [] 0 setdash gsave + translate 0 hpt M 4 {72 rotate 0 hpt L} repeat + Opaque stroke grestore} def +/CircW {stroke [] 0 setdash + hpt 0 360 arc Opaque stroke} def +/BoxFill {gsave Rec 1 setgray fill grestore} def +/Density { + /Fillden exch def + currentrgbcolor + /ColB exch def /ColG exch def /ColR exch def + /ColR ColR Fillden mul Fillden sub 1 add def + /ColG ColG Fillden mul Fillden sub 1 add def + /ColB ColB Fillden mul Fillden sub 1 add def + ColR ColG ColB setrgbcolor} def +/BoxColFill {gsave Rec PolyFill} def +/PolyFill {gsave Density fill grestore grestore} def +/h {rlineto rlineto rlineto gsave closepath fill grestore} bind def +% +% PostScript Level 1 Pattern Fill routine for rectangles +% Usage: x y w h s a XX PatternFill +% x,y = lower left corner of box to be filled +% w,h = width and height of box +% a = angle in degrees between lines and x-axis +% XX = 0/1 for no/yes cross-hatch +% +/PatternFill {gsave /PFa [ 9 2 roll ] def + PFa 0 get PFa 2 get 2 div add PFa 1 get PFa 3 get 2 div add translate + PFa 2 get -2 div PFa 3 get -2 div PFa 2 get PFa 3 get Rec + gsave 1 setgray fill grestore clip + currentlinewidth 0.5 mul setlinewidth + /PFs PFa 2 get dup mul PFa 3 get dup mul add sqrt def + 0 0 M PFa 5 get rotate PFs -2 div dup translate + 0 1 PFs PFa 4 get div 1 add floor cvi + {PFa 4 get mul 0 M 0 PFs V} for + 0 PFa 6 get ne { + 0 1 PFs PFa 4 get div 1 add floor cvi + {PFa 4 get mul 0 2 1 roll M PFs 0 V} for + } if + stroke grestore} def +% +/languagelevel where + {pop languagelevel} {1} ifelse + 2 lt + {/InterpretLevel1 true def} + {/InterpretLevel1 Level1 def} + ifelse +% +% PostScript level 2 pattern fill definitions +% +/Level2PatternFill { +/Tile8x8 {/PaintType 2 /PatternType 1 /TilingType 1 /BBox [0 0 8 8] /XStep 8 /YStep 8} + bind def +/KeepColor {currentrgbcolor [/Pattern /DeviceRGB] setcolorspace} bind def +<< Tile8x8 + /PaintProc {0.5 setlinewidth pop 0 0 M 8 8 L 0 8 M 8 0 L stroke} +>> matrix makepattern +/Pat1 exch def +<< Tile8x8 + /PaintProc {0.5 setlinewidth pop 0 0 M 8 8 L 0 8 M 8 0 L stroke + 0 4 M 4 8 L 8 4 L 4 0 L 0 4 L stroke} +>> matrix makepattern +/Pat2 exch def +<< Tile8x8 + /PaintProc {0.5 setlinewidth pop 0 0 M 0 8 L + 8 8 L 8 0 L 0 0 L fill} +>> matrix makepattern +/Pat3 exch def +<< Tile8x8 + /PaintProc {0.5 setlinewidth pop -4 8 M 8 -4 L + 0 12 M 12 0 L stroke} +>> matrix makepattern +/Pat4 exch def +<< Tile8x8 + /PaintProc {0.5 setlinewidth pop -4 0 M 8 12 L + 0 -4 M 12 8 L stroke} +>> matrix makepattern +/Pat5 exch def +<< Tile8x8 + /PaintProc {0.5 setlinewidth pop -2 8 M 4 -4 L + 0 12 M 8 -4 L 4 12 M 10 0 L stroke} +>> matrix makepattern +/Pat6 exch def +<< Tile8x8 + /PaintProc {0.5 setlinewidth pop -2 0 M 4 12 L + 0 -4 M 8 12 L 4 -4 M 10 8 L stroke} +>> matrix makepattern +/Pat7 exch def +<< Tile8x8 + /PaintProc {0.5 setlinewidth pop 8 -2 M -4 4 L + 12 0 M -4 8 L 12 4 M 0 10 L stroke} +>> matrix makepattern +/Pat8 exch def +<< Tile8x8 + /PaintProc {0.5 setlinewidth pop 0 -2 M 12 4 L + -4 0 M 12 8 L -4 4 M 8 10 L stroke} +>> matrix makepattern +/Pat9 exch def +/Pattern1 {PatternBgnd KeepColor Pat1 setpattern} bind def +/Pattern2 {PatternBgnd KeepColor Pat2 setpattern} bind def +/Pattern3 {PatternBgnd KeepColor Pat3 setpattern} bind def +/Pattern4 {PatternBgnd KeepColor Landscape {Pat5} {Pat4} ifelse setpattern} bind def +/Pattern5 {PatternBgnd KeepColor Landscape {Pat4} {Pat5} ifelse setpattern} bind def +/Pattern6 {PatternBgnd KeepColor Landscape {Pat9} {Pat6} ifelse setpattern} bind def +/Pattern7 {PatternBgnd KeepColor Landscape {Pat8} {Pat7} ifelse setpattern} bind def +} def +% +% +%End of PostScript Level 2 code +% +/PatternBgnd { + TransparentPatterns {} {gsave 1 setgray fill grestore} ifelse +} def +% +% Substitute for Level 2 pattern fill codes with +% grayscale if Level 2 support is not selected. +% +/Level1PatternFill { +/Pattern1 {0.250 Density} bind def +/Pattern2 {0.500 Density} bind def +/Pattern3 {0.750 Density} bind def +/Pattern4 {0.125 Density} bind def +/Pattern5 {0.375 Density} bind def +/Pattern6 {0.625 Density} bind def +/Pattern7 {0.875 Density} bind def +} def +% +% Now test for support of Level 2 code +% +Level1 {Level1PatternFill} {Level2PatternFill} ifelse +% +/Symbol-Oblique /Symbol findfont [1 0 .167 1 0 0] makefont +dup length dict begin {1 index /FID eq {pop pop} {def} ifelse} forall +currentdict end definefont pop +/MFshow { + { dup 5 get 3 ge + { 5 get 3 eq {gsave} {grestore} ifelse } + {dup dup 0 get findfont exch 1 get scalefont setfont + [ currentpoint ] exch dup 2 get 0 exch R dup 5 get 2 ne {dup dup 6 + get exch 4 get {Gshow} {stringwidth pop 0 R} ifelse }if dup 5 get 0 eq + {dup 3 get {2 get neg 0 exch R pop} {pop aload pop M} ifelse} {dup 5 + get 1 eq {dup 2 get exch dup 3 get exch 6 get stringwidth pop -2 div + dup 0 R} {dup 6 get stringwidth pop -2 div 0 R 6 get + show 2 index {aload pop M neg 3 -1 roll neg R pop pop} {pop pop pop + pop aload pop M} ifelse }ifelse }ifelse } + ifelse } + forall} def +/Gswidth {dup type /stringtype eq {stringwidth} {pop (n) stringwidth} ifelse} def +/MFwidth {0 exch { dup 5 get 3 ge { 5 get 3 eq { 0 } { pop } ifelse } + {dup 3 get{dup dup 0 get findfont exch 1 get scalefont setfont + 6 get Gswidth pop add} {pop} ifelse} ifelse} forall} def +/MLshow { currentpoint stroke M + 0 exch R + Blacktext {gsave 0 setgray MFshow grestore} {MFshow} ifelse } bind def +/MRshow { currentpoint stroke M + exch dup MFwidth neg 3 -1 roll R + Blacktext {gsave 0 setgray MFshow grestore} {MFshow} ifelse } bind def +/MCshow { currentpoint stroke M + exch dup MFwidth -2 div 3 -1 roll R + Blacktext {gsave 0 setgray MFshow grestore} {MFshow} ifelse } bind def +/XYsave { [( ) 1 2 true false 3 ()] } bind def +/XYrestore { [( ) 1 2 true false 4 ()] } bind def +end +%%EndProlog +%%Page: 1 1 +gnudict begin +gsave +doclip +50 50 translate +0.100 0.100 scale +90 rotate +0 -5040 translate +0 setgray +newpath +(Helvetica) findfont 140 scalefont setfont +1.000 UL +LTb +518 448 M +63 0 V +stroke +434 448 M +[ [(Helvetica) 140.0 0.0 true true 0 ( 1)] +] -46.7 MRshow +1.000 UL +LTb +518 792 M +63 0 V +stroke +434 792 M +[ [(Helvetica) 140.0 0.0 true true 0 ( 2)] +] -46.7 MRshow +1.000 UL +LTb +518 1136 M +63 0 V +stroke +434 1136 M +[ [(Helvetica) 140.0 0.0 true true 0 ( 3)] +] -46.7 MRshow +1.000 UL +LTb +518 1480 M +63 0 V +stroke +434 1480 M +[ [(Helvetica) 140.0 0.0 true true 0 ( 4)] +] -46.7 MRshow +1.000 UL +LTb +518 1823 M +63 0 V +stroke +434 1823 M +[ [(Helvetica) 140.0 0.0 true true 0 ( 5)] +] -46.7 MRshow +1.000 UL +LTb +518 2167 M +63 0 V +stroke +434 2167 M +[ [(Helvetica) 140.0 0.0 true true 0 ( 6)] +] -46.7 MRshow +1.000 UL +LTb +518 2511 M +63 0 V +stroke +434 2511 M +[ [(Helvetica) 140.0 0.0 true true 0 ( 7)] +] -46.7 MRshow +1.000 UL +LTb +518 2855 M +63 0 V +stroke +434 2855 M +[ [(Helvetica) 140.0 0.0 true true 0 ( 8)] +] -46.7 MRshow +1.000 UL +LTb +518 448 M +0 63 V +stroke +518 308 M +[ [(Helvetica) 140.0 0.0 true true 0 ( 0)] +] -46.7 MCshow +1.000 UL +LTb +962 448 M +0 63 V +stroke +962 308 M +[ [(Helvetica) 140.0 0.0 true true 0 ( 1000)] +] -46.7 MCshow +1.000 UL +LTb +1405 448 M +0 63 V +stroke +1405 308 M +[ [(Helvetica) 140.0 0.0 true true 0 ( 2000)] +] -46.7 MCshow +1.000 UL +LTb +1849 448 M +0 63 V +stroke +1849 308 M +[ [(Helvetica) 140.0 0.0 true true 0 ( 3000)] +] -46.7 MCshow +1.000 UL +LTb +2293 448 M +0 63 V +stroke +2293 308 M +[ [(Helvetica) 140.0 0.0 true true 0 ( 4000)] +] -46.7 MCshow +1.000 UL +LTb +2736 448 M +0 63 V +stroke +2736 308 M +[ [(Helvetica) 140.0 0.0 true true 0 ( 5000)] +] -46.7 MCshow +1.000 UL +LTb +3180 448 M +0 63 V +stroke +3180 308 M +[ [(Helvetica) 140.0 0.0 true true 0 ( 6000)] +] -46.7 MCshow +1.000 UL +LTb +3623 448 M +0 63 V +stroke +3623 308 M +[ [(Helvetica) 140.0 0.0 true true 0 ( 7000)] +] -46.7 MCshow +1.000 UL +LTb +4067 448 M +0 63 V +stroke +4067 308 M +[ [(Helvetica) 140.0 0.0 true true 0 ( 8000)] +] -46.7 MCshow +1.000 UL +LTb +1.000 UL +LTb +518 2855 M +518 448 L +3549 0 V +0 2407 R +-3549 0 R +stroke +LCb setrgbcolor +112 1651 M +currentpoint gsave translate -270 rotate 0 0 moveto +[ [(Helvetica) 140.0 0.0 true true 0 (Ratio of Total Execution to Total Work)] +] -46.7 MCshow +grestore +LTb +LCb setrgbcolor +2292 98 M +[ [(Helvetica) 140.0 0.0 true true 0 (Cycles in one Task)] +] -46.7 MCshow +LTb +1.000 UP +1.000 UL +LTb +1.000 UL +LTb +2492 2232 N +0 560 V +1491 0 V +0 -560 V +-1491 0 V +Z stroke +2492 2792 M +1491 0 V +% Begin plot #1 +stroke +4.000 UL +LT1 +LCa setrgbcolor +518 792 M +36 0 V +36 0 V +36 0 V +35 0 V +36 0 V +36 0 V +36 0 V +36 0 V +36 0 V +35 0 V +36 0 V +36 0 V +36 0 V +36 0 V +36 0 V +36 0 V +35 0 V +36 0 V +36 0 V +36 0 V +36 0 V +36 0 V +36 0 V +35 0 V +36 0 V +36 0 V +36 0 V +36 0 V +36 0 V +35 0 V +36 0 V +36 0 V +36 0 V +36 0 V +36 0 V +36 0 V +35 0 V +36 0 V +36 0 V +36 0 V +36 0 V +36 0 V +35 0 V +36 0 V +36 0 V +36 0 V +36 0 V +36 0 V +36 0 V +35 0 V +36 0 V +36 0 V +36 0 V +36 0 V +36 0 V +36 0 V +35 0 V +36 0 V +36 0 V +36 0 V +36 0 V +36 0 V +35 0 V +36 0 V +36 0 V +36 0 V +36 0 V +36 0 V +36 0 V +35 0 V +36 0 V +36 0 V +36 0 V +36 0 V +36 0 V +35 0 V +36 0 V +36 0 V +36 0 V +36 0 V +36 0 V +36 0 V +35 0 V +36 0 V +36 0 V +36 0 V +36 0 V +36 0 V +36 0 V +35 0 V +36 0 V +36 0 V +36 0 V +36 0 V +36 0 V +35 0 V +36 0 V +36 0 V +36 0 V +% End plot #1 +% Begin plot #2 +stroke +LT1 +LCb setrgbcolor +3416 2722 M +[ [(Helvetica) 140.0 0.0 true true 0 (8 Threads)] +] -46.7 MRshow +LT1 +3500 2722 M +399 0 V +610 1551 M +19 -143 V +31 -191 V +722 955 L +846 769 L +1102 629 L +497 -83 V +994 -48 V +4067 480 L +% End plot #2 +% Begin plot #3 +stroke +LT2 +LCb setrgbcolor +3416 2582 M +[ [(Helvetica) 140.0 0.0 true true 0 (32 Threads)] +] -46.7 MRshow +LT2 +3500 2582 M +399 0 V +610 1568 M +19 -173 V +31 -226 V +722 958 L +846 759 L +1102 621 L +497 -78 V +994 -46 V +4067 479 L +% End plot #3 +% Begin plot #4 +stroke +LT3 +LCb setrgbcolor +3416 2442 M +[ [(Helvetica) 140.0 0.0 true true 0 (128 Threads)] +] -46.7 MRshow +LT3 +3500 2442 M +399 0 V +611 1654 M +18 -214 V +31 -208 V +722 984 L +847 786 L +1103 636 L +496 -85 V +994 -50 V +4067 482 L +% End plot #4 +% Begin plot #5 +stroke +LT4 +LCb setrgbcolor +3416 2302 M +[ [(Helvetica) 140.0 0.0 true true 0 (512 Threads)] +] -46.7 MRshow +LT4 +3500 2302 M +399 0 V +611 1704 M +18 -203 V +31 -230 V +63 -252 V +846 804 L +1103 645 L +497 -89 V +993 -52 V +4067 484 L +% End plot #5 +stroke +1.000 UL +LTb +518 2855 M +518 448 L +3549 0 V +0 2407 R +-3549 0 R +1.000 UP +stroke +grestore +end +showpage +%%Trailer +%%DocumentFonts: Helvetica +%%Pages: 1 diff -r 9b9a2497757d -r eb146c5c05a8 0__Papers/PRT/PRT__formal_def/figures/plots_exec_vs_task_size/not_used/vms_pthreads_8_32_128thds__o30000__perfCtrs.result.eps --- /dev/null Thu Jan 01 00:00:00 1970 +0000 +++ b/0__Papers/PRT/PRT__formal_def/figures/plots_exec_vs_task_size/not_used/vms_pthreads_8_32_128thds__o30000__perfCtrs.result.eps Sat Aug 03 19:24:22 2013 -0700 @@ -0,0 +1,819 @@ +%!PS-Adobe-2.0 +%%Title: vms_pthreads_8_32_128thds__o30000__perfCtrs.result.eps +%%Creator: gnuplot 4.4 patchlevel 2 +%%CreationDate: Thu Jan 26 18:11:43 2012 +%%DocumentFonts: (atend) +%%BoundingBox: 251 50 554 482 +%%Orientation: Landscape +%%Pages: (atend) +%%EndComments +%%BeginProlog +/gnudict 256 dict def +gnudict begin +% +% The following true/false flags may be edited by hand if desired. +% The unit line width and grayscale image gamma correction may also be changed. +% +/Color true def +/Blacktext false def +/Solid false def +/Dashlength 1 def +/Landscape true def +/Level1 false def +/Rounded false def +/ClipToBoundingBox false def +/TransparentPatterns false def +/gnulinewidth 5.000 def +/userlinewidth gnulinewidth def +/Gamma 1.0 def +% +/vshift -46 def +/dl1 { + 10.0 Dashlength mul mul + Rounded { currentlinewidth 0.75 mul sub dup 0 le { pop 0.01 } if } if +} def +/dl2 { + 10.0 Dashlength mul mul + Rounded { currentlinewidth 0.75 mul add } if +} def +/hpt_ 31.5 def +/vpt_ 31.5 def +/hpt hpt_ def +/vpt vpt_ def +Level1 {} { +/SDict 10 dict def +systemdict /pdfmark known not { + userdict /pdfmark systemdict /cleartomark get put +} if +SDict begin [ + /Title (vms_pthreads_8_32_128thds__o30000__perfCtrs.result.eps) + /Subject (gnuplot plot) + /Creator (gnuplot 4.4 patchlevel 2) + /Author (msach) +% /Producer (gnuplot) +% /Keywords () + /CreationDate (Thu Jan 26 18:11:43 2012) + /DOCINFO pdfmark +end +} ifelse +/doclip { + ClipToBoundingBox { + newpath 251 50 moveto 554 50 lineto 554 482 lineto 251 482 lineto closepath + clip + } if +} def +% +% Gnuplot Prolog Version 4.4 (August 2010) +% +%/SuppressPDFMark true def +% +/M {moveto} bind def +/L {lineto} bind def +/R {rmoveto} bind def +/V {rlineto} bind def +/N {newpath moveto} bind def +/Z {closepath} bind def +/C {setrgbcolor} bind def +/f {rlineto fill} bind def +/g {setgray} bind def +/Gshow {show} def % May be redefined later in the file to support UTF-8 +/vpt2 vpt 2 mul def +/hpt2 hpt 2 mul def +/Lshow {currentpoint stroke M 0 vshift R + Blacktext {gsave 0 setgray show grestore} {show} ifelse} def +/Rshow {currentpoint stroke M dup stringwidth pop neg vshift R + Blacktext {gsave 0 setgray show grestore} {show} ifelse} def +/Cshow {currentpoint stroke M dup stringwidth pop -2 div vshift R + Blacktext {gsave 0 setgray show grestore} {show} ifelse} def +/UP {dup vpt_ mul /vpt exch def hpt_ mul /hpt exch def + /hpt2 hpt 2 mul def /vpt2 vpt 2 mul def} def +/DL {Color {setrgbcolor Solid {pop []} if 0 setdash} + {pop pop pop 0 setgray Solid {pop []} if 0 setdash} ifelse} def +/BL {stroke userlinewidth 2 mul setlinewidth + Rounded {1 setlinejoin 1 setlinecap} if} def +/AL {stroke userlinewidth 2 div setlinewidth + Rounded {1 setlinejoin 1 setlinecap} if} def +/UL {dup gnulinewidth mul /userlinewidth exch def + dup 1 lt {pop 1} if 10 mul /udl exch def} def +/PL {stroke userlinewidth setlinewidth + Rounded {1 setlinejoin 1 setlinecap} if} def +3.8 setmiterlimit +% Default Line colors +/LCw {1 1 1} def +/LCb {0 0 0} def +/LCa {0 0 0} def +/LC0 {1 0 0} def +/LC1 {0 1 0} def +/LC2 {0 0 1} def +/LC3 {1 0 1} def +/LC4 {0 1 1} def +/LC5 {1 1 0} def +/LC6 {0 0 0} def +/LC7 {1 0.3 0} def +/LC8 {0.5 0.5 0.5} def +% Default Line Types +/LTw {PL [] 1 setgray} def +/LTb {BL [] LCb DL} def +/LTa {AL [1 udl mul 2 udl mul] 0 setdash LCa setrgbcolor} def +/LT0 {PL [] LC0 DL} def +/LT1 {PL [4 dl1 2 dl2] LC1 DL} def +/LT2 {PL [2 dl1 3 dl2] LC2 DL} def +/LT3 {PL [1 dl1 1.5 dl2] LC3 DL} def +/LT4 {PL [6 dl1 2 dl2 1 dl1 2 dl2] LC4 DL} def +/LT5 {PL [3 dl1 3 dl2 1 dl1 3 dl2] LC5 DL} def +/LT6 {PL [2 dl1 2 dl2 2 dl1 6 dl2] LC6 DL} def +/LT7 {PL [1 dl1 2 dl2 6 dl1 2 dl2 1 dl1 2 dl2] LC7 DL} def +/LT8 {PL [2 dl1 2 dl2 2 dl1 2 dl2 2 dl1 2 dl2 2 dl1 4 dl2] LC8 DL} def +/Pnt {stroke [] 0 setdash gsave 1 setlinecap M 0 0 V stroke grestore} def +/Dia {stroke [] 0 setdash 2 copy vpt add M + hpt neg vpt neg V hpt vpt neg V + hpt vpt V hpt neg vpt V closepath stroke + Pnt} def +/Pls {stroke [] 0 setdash vpt sub M 0 vpt2 V + currentpoint stroke M + hpt neg vpt neg R hpt2 0 V stroke + } def +/Box {stroke [] 0 setdash 2 copy exch hpt sub exch vpt add M + 0 vpt2 neg V hpt2 0 V 0 vpt2 V + hpt2 neg 0 V closepath stroke + Pnt} def +/Crs {stroke [] 0 setdash exch hpt sub exch vpt add M + hpt2 vpt2 neg V currentpoint stroke M + hpt2 neg 0 R hpt2 vpt2 V stroke} def +/TriU {stroke [] 0 setdash 2 copy vpt 1.12 mul add M + hpt neg vpt -1.62 mul V + hpt 2 mul 0 V + hpt neg vpt 1.62 mul V closepath stroke + Pnt} def +/Star {2 copy Pls Crs} def +/BoxF {stroke [] 0 setdash exch hpt sub exch vpt add M + 0 vpt2 neg V hpt2 0 V 0 vpt2 V + hpt2 neg 0 V closepath fill} def +/TriUF {stroke [] 0 setdash vpt 1.12 mul add M + hpt neg vpt -1.62 mul V + hpt 2 mul 0 V + hpt neg vpt 1.62 mul V closepath fill} def +/TriD {stroke [] 0 setdash 2 copy vpt 1.12 mul sub M + hpt neg vpt 1.62 mul V + hpt 2 mul 0 V + hpt neg vpt -1.62 mul V closepath stroke + Pnt} def +/TriDF {stroke [] 0 setdash vpt 1.12 mul sub M + hpt neg vpt 1.62 mul V + hpt 2 mul 0 V + hpt neg vpt -1.62 mul V closepath fill} def +/DiaF {stroke [] 0 setdash vpt add M + hpt neg vpt neg V hpt vpt neg V + hpt vpt V hpt neg vpt V closepath fill} def +/Pent {stroke [] 0 setdash 2 copy gsave + translate 0 hpt M 4 {72 rotate 0 hpt L} repeat + closepath stroke grestore Pnt} def +/PentF {stroke [] 0 setdash gsave + translate 0 hpt M 4 {72 rotate 0 hpt L} repeat + closepath fill grestore} def +/Circle {stroke [] 0 setdash 2 copy + hpt 0 360 arc stroke Pnt} def +/CircleF {stroke [] 0 setdash hpt 0 360 arc fill} def +/C0 {BL [] 0 setdash 2 copy moveto vpt 90 450 arc} bind def +/C1 {BL [] 0 setdash 2 copy moveto + 2 copy vpt 0 90 arc closepath fill + vpt 0 360 arc closepath} bind def +/C2 {BL [] 0 setdash 2 copy moveto + 2 copy vpt 90 180 arc closepath fill + vpt 0 360 arc closepath} bind def +/C3 {BL [] 0 setdash 2 copy moveto + 2 copy vpt 0 180 arc closepath fill + vpt 0 360 arc closepath} bind def +/C4 {BL [] 0 setdash 2 copy moveto + 2 copy vpt 180 270 arc closepath fill + vpt 0 360 arc closepath} bind def +/C5 {BL [] 0 setdash 2 copy moveto + 2 copy vpt 0 90 arc + 2 copy moveto + 2 copy vpt 180 270 arc closepath fill + vpt 0 360 arc} bind def +/C6 {BL [] 0 setdash 2 copy moveto + 2 copy vpt 90 270 arc closepath fill + vpt 0 360 arc closepath} bind def +/C7 {BL [] 0 setdash 2 copy moveto + 2 copy vpt 0 270 arc closepath fill + vpt 0 360 arc closepath} bind def +/C8 {BL [] 0 setdash 2 copy moveto + 2 copy vpt 270 360 arc closepath fill + vpt 0 360 arc closepath} bind def +/C9 {BL [] 0 setdash 2 copy moveto + 2 copy vpt 270 450 arc closepath fill + vpt 0 360 arc closepath} bind def +/C10 {BL [] 0 setdash 2 copy 2 copy moveto vpt 270 360 arc closepath fill + 2 copy moveto + 2 copy vpt 90 180 arc closepath fill + vpt 0 360 arc closepath} bind def +/C11 {BL [] 0 setdash 2 copy moveto + 2 copy vpt 0 180 arc closepath fill + 2 copy moveto + 2 copy vpt 270 360 arc closepath fill + vpt 0 360 arc closepath} bind def +/C12 {BL [] 0 setdash 2 copy moveto + 2 copy vpt 180 360 arc closepath fill + vpt 0 360 arc closepath} bind def +/C13 {BL [] 0 setdash 2 copy moveto + 2 copy vpt 0 90 arc closepath fill + 2 copy moveto + 2 copy vpt 180 360 arc closepath fill + vpt 0 360 arc closepath} bind def +/C14 {BL [] 0 setdash 2 copy moveto + 2 copy vpt 90 360 arc closepath fill + vpt 0 360 arc} bind def +/C15 {BL [] 0 setdash 2 copy vpt 0 360 arc closepath fill + vpt 0 360 arc closepath} bind def +/Rec {newpath 4 2 roll moveto 1 index 0 rlineto 0 exch rlineto + neg 0 rlineto closepath} bind def +/Square {dup Rec} bind def +/Bsquare {vpt sub exch vpt sub exch vpt2 Square} bind def +/S0 {BL [] 0 setdash 2 copy moveto 0 vpt rlineto BL Bsquare} bind def +/S1 {BL [] 0 setdash 2 copy vpt Square fill Bsquare} bind def +/S2 {BL [] 0 setdash 2 copy exch vpt sub exch vpt Square fill Bsquare} bind def +/S3 {BL [] 0 setdash 2 copy exch vpt sub exch vpt2 vpt Rec fill Bsquare} bind def +/S4 {BL [] 0 setdash 2 copy exch vpt sub exch vpt sub vpt Square fill Bsquare} bind def +/S5 {BL [] 0 setdash 2 copy 2 copy vpt Square fill + exch vpt sub exch vpt sub vpt Square fill Bsquare} bind def +/S6 {BL [] 0 setdash 2 copy exch vpt sub exch vpt sub vpt vpt2 Rec fill Bsquare} bind def +/S7 {BL [] 0 setdash 2 copy exch vpt sub exch vpt sub vpt vpt2 Rec fill + 2 copy vpt Square fill Bsquare} bind def +/S8 {BL [] 0 setdash 2 copy vpt sub vpt Square fill Bsquare} bind def +/S9 {BL [] 0 setdash 2 copy vpt sub vpt vpt2 Rec fill Bsquare} bind def +/S10 {BL [] 0 setdash 2 copy vpt sub vpt Square fill 2 copy exch vpt sub exch vpt Square fill + Bsquare} bind def +/S11 {BL [] 0 setdash 2 copy vpt sub vpt Square fill 2 copy exch vpt sub exch vpt2 vpt Rec fill + Bsquare} bind def +/S12 {BL [] 0 setdash 2 copy exch vpt sub exch vpt sub vpt2 vpt Rec fill Bsquare} bind def +/S13 {BL [] 0 setdash 2 copy exch vpt sub exch vpt sub vpt2 vpt Rec fill + 2 copy vpt Square fill Bsquare} bind def +/S14 {BL [] 0 setdash 2 copy exch vpt sub exch vpt sub vpt2 vpt Rec fill + 2 copy exch vpt sub exch vpt Square fill Bsquare} bind def +/S15 {BL [] 0 setdash 2 copy Bsquare fill Bsquare} bind def +/D0 {gsave translate 45 rotate 0 0 S0 stroke grestore} bind def +/D1 {gsave translate 45 rotate 0 0 S1 stroke grestore} bind def +/D2 {gsave translate 45 rotate 0 0 S2 stroke grestore} bind def +/D3 {gsave translate 45 rotate 0 0 S3 stroke grestore} bind def +/D4 {gsave translate 45 rotate 0 0 S4 stroke grestore} bind def +/D5 {gsave translate 45 rotate 0 0 S5 stroke grestore} bind def +/D6 {gsave translate 45 rotate 0 0 S6 stroke grestore} bind def +/D7 {gsave translate 45 rotate 0 0 S7 stroke grestore} bind def +/D8 {gsave translate 45 rotate 0 0 S8 stroke grestore} bind def +/D9 {gsave translate 45 rotate 0 0 S9 stroke grestore} bind def +/D10 {gsave translate 45 rotate 0 0 S10 stroke grestore} bind def +/D11 {gsave translate 45 rotate 0 0 S11 stroke grestore} bind def +/D12 {gsave translate 45 rotate 0 0 S12 stroke grestore} bind def +/D13 {gsave translate 45 rotate 0 0 S13 stroke grestore} bind def +/D14 {gsave translate 45 rotate 0 0 S14 stroke grestore} bind def +/D15 {gsave translate 45 rotate 0 0 S15 stroke grestore} bind def +/DiaE {stroke [] 0 setdash vpt add M + hpt neg vpt neg V hpt vpt neg V + hpt vpt V hpt neg vpt V closepath stroke} def +/BoxE {stroke [] 0 setdash exch hpt sub exch vpt add M + 0 vpt2 neg V hpt2 0 V 0 vpt2 V + hpt2 neg 0 V closepath stroke} def +/TriUE {stroke [] 0 setdash vpt 1.12 mul add M + hpt neg vpt -1.62 mul V + hpt 2 mul 0 V + hpt neg vpt 1.62 mul V closepath stroke} def +/TriDE {stroke [] 0 setdash vpt 1.12 mul sub M + hpt neg vpt 1.62 mul V + hpt 2 mul 0 V + hpt neg vpt -1.62 mul V closepath stroke} def +/PentE {stroke [] 0 setdash gsave + translate 0 hpt M 4 {72 rotate 0 hpt L} repeat + closepath stroke grestore} def +/CircE {stroke [] 0 setdash + hpt 0 360 arc stroke} def +/Opaque {gsave closepath 1 setgray fill grestore 0 setgray closepath} def +/DiaW {stroke [] 0 setdash vpt add M + hpt neg vpt neg V hpt vpt neg V + hpt vpt V hpt neg vpt V Opaque stroke} def +/BoxW {stroke [] 0 setdash exch hpt sub exch vpt add M + 0 vpt2 neg V hpt2 0 V 0 vpt2 V + hpt2 neg 0 V Opaque stroke} def +/TriUW {stroke [] 0 setdash vpt 1.12 mul add M + hpt neg vpt -1.62 mul V + hpt 2 mul 0 V + hpt neg vpt 1.62 mul V Opaque stroke} def +/TriDW {stroke [] 0 setdash vpt 1.12 mul sub M + hpt neg vpt 1.62 mul V + hpt 2 mul 0 V + hpt neg vpt -1.62 mul V Opaque stroke} def +/PentW {stroke [] 0 setdash gsave + translate 0 hpt M 4 {72 rotate 0 hpt L} repeat + Opaque stroke grestore} def +/CircW {stroke [] 0 setdash + hpt 0 360 arc Opaque stroke} def +/BoxFill {gsave Rec 1 setgray fill grestore} def +/Density { + /Fillden exch def + currentrgbcolor + /ColB exch def /ColG exch def /ColR exch def + /ColR ColR Fillden mul Fillden sub 1 add def + /ColG ColG Fillden mul Fillden sub 1 add def + /ColB ColB Fillden mul Fillden sub 1 add def + ColR ColG ColB setrgbcolor} def +/BoxColFill {gsave Rec PolyFill} def +/PolyFill {gsave Density fill grestore grestore} def +/h {rlineto rlineto rlineto gsave closepath fill grestore} bind def +% +% PostScript Level 1 Pattern Fill routine for rectangles +% Usage: x y w h s a XX PatternFill +% x,y = lower left corner of box to be filled +% w,h = width and height of box +% a = angle in degrees between lines and x-axis +% XX = 0/1 for no/yes cross-hatch +% +/PatternFill {gsave /PFa [ 9 2 roll ] def + PFa 0 get PFa 2 get 2 div add PFa 1 get PFa 3 get 2 div add translate + PFa 2 get -2 div PFa 3 get -2 div PFa 2 get PFa 3 get Rec + gsave 1 setgray fill grestore clip + currentlinewidth 0.5 mul setlinewidth + /PFs PFa 2 get dup mul PFa 3 get dup mul add sqrt def + 0 0 M PFa 5 get rotate PFs -2 div dup translate + 0 1 PFs PFa 4 get div 1 add floor cvi + {PFa 4 get mul 0 M 0 PFs V} for + 0 PFa 6 get ne { + 0 1 PFs PFa 4 get div 1 add floor cvi + {PFa 4 get mul 0 2 1 roll M PFs 0 V} for + } if + stroke grestore} def +% +/languagelevel where + {pop languagelevel} {1} ifelse + 2 lt + {/InterpretLevel1 true def} + {/InterpretLevel1 Level1 def} + ifelse +% +% PostScript level 2 pattern fill definitions +% +/Level2PatternFill { +/Tile8x8 {/PaintType 2 /PatternType 1 /TilingType 1 /BBox [0 0 8 8] /XStep 8 /YStep 8} + bind def +/KeepColor {currentrgbcolor [/Pattern /DeviceRGB] setcolorspace} bind def +<< Tile8x8 + /PaintProc {0.5 setlinewidth pop 0 0 M 8 8 L 0 8 M 8 0 L stroke} +>> matrix makepattern +/Pat1 exch def +<< Tile8x8 + /PaintProc {0.5 setlinewidth pop 0 0 M 8 8 L 0 8 M 8 0 L stroke + 0 4 M 4 8 L 8 4 L 4 0 L 0 4 L stroke} +>> matrix makepattern +/Pat2 exch def +<< Tile8x8 + /PaintProc {0.5 setlinewidth pop 0 0 M 0 8 L + 8 8 L 8 0 L 0 0 L fill} +>> matrix makepattern +/Pat3 exch def +<< Tile8x8 + /PaintProc {0.5 setlinewidth pop -4 8 M 8 -4 L + 0 12 M 12 0 L stroke} +>> matrix makepattern +/Pat4 exch def +<< Tile8x8 + /PaintProc {0.5 setlinewidth pop -4 0 M 8 12 L + 0 -4 M 12 8 L stroke} +>> matrix makepattern +/Pat5 exch def +<< Tile8x8 + /PaintProc {0.5 setlinewidth pop -2 8 M 4 -4 L + 0 12 M 8 -4 L 4 12 M 10 0 L stroke} +>> matrix makepattern +/Pat6 exch def +<< Tile8x8 + /PaintProc {0.5 setlinewidth pop -2 0 M 4 12 L + 0 -4 M 8 12 L 4 -4 M 10 8 L stroke} +>> matrix makepattern +/Pat7 exch def +<< Tile8x8 + /PaintProc {0.5 setlinewidth pop 8 -2 M -4 4 L + 12 0 M -4 8 L 12 4 M 0 10 L stroke} +>> matrix makepattern +/Pat8 exch def +<< Tile8x8 + /PaintProc {0.5 setlinewidth pop 0 -2 M 12 4 L + -4 0 M 12 8 L -4 4 M 8 10 L stroke} +>> matrix makepattern +/Pat9 exch def +/Pattern1 {PatternBgnd KeepColor Pat1 setpattern} bind def +/Pattern2 {PatternBgnd KeepColor Pat2 setpattern} bind def +/Pattern3 {PatternBgnd KeepColor Pat3 setpattern} bind def +/Pattern4 {PatternBgnd KeepColor Landscape {Pat5} {Pat4} ifelse setpattern} bind def +/Pattern5 {PatternBgnd KeepColor Landscape {Pat4} {Pat5} ifelse setpattern} bind def +/Pattern6 {PatternBgnd KeepColor Landscape {Pat9} {Pat6} ifelse setpattern} bind def +/Pattern7 {PatternBgnd KeepColor Landscape {Pat8} {Pat7} ifelse setpattern} bind def +} def +% +% +%End of PostScript Level 2 code +% +/PatternBgnd { + TransparentPatterns {} {gsave 1 setgray fill grestore} ifelse +} def +% +% Substitute for Level 2 pattern fill codes with +% grayscale if Level 2 support is not selected. +% +/Level1PatternFill { +/Pattern1 {0.250 Density} bind def +/Pattern2 {0.500 Density} bind def +/Pattern3 {0.750 Density} bind def +/Pattern4 {0.125 Density} bind def +/Pattern5 {0.375 Density} bind def +/Pattern6 {0.625 Density} bind def +/Pattern7 {0.875 Density} bind def +} def +% +% Now test for support of Level 2 code +% +Level1 {Level1PatternFill} {Level2PatternFill} ifelse +% +/Symbol-Oblique /Symbol findfont [1 0 .167 1 0 0] makefont +dup length dict begin {1 index /FID eq {pop pop} {def} ifelse} forall +currentdict end definefont pop +/MFshow { + { dup 5 get 3 ge + { 5 get 3 eq {gsave} {grestore} ifelse } + {dup dup 0 get findfont exch 1 get scalefont setfont + [ currentpoint ] exch dup 2 get 0 exch R dup 5 get 2 ne {dup dup 6 + get exch 4 get {Gshow} {stringwidth pop 0 R} ifelse }if dup 5 get 0 eq + {dup 3 get {2 get neg 0 exch R pop} {pop aload pop M} ifelse} {dup 5 + get 1 eq {dup 2 get exch dup 3 get exch 6 get stringwidth pop -2 div + dup 0 R} {dup 6 get stringwidth pop -2 div 0 R 6 get + show 2 index {aload pop M neg 3 -1 roll neg R pop pop} {pop pop pop + pop aload pop M} ifelse }ifelse }ifelse } + ifelse } + forall} def +/Gswidth {dup type /stringtype eq {stringwidth} {pop (n) stringwidth} ifelse} def +/MFwidth {0 exch { dup 5 get 3 ge { 5 get 3 eq { 0 } { pop } ifelse } + {dup 3 get{dup dup 0 get findfont exch 1 get scalefont setfont + 6 get Gswidth pop add} {pop} ifelse} ifelse} forall} def +/MLshow { currentpoint stroke M + 0 exch R + Blacktext {gsave 0 setgray MFshow grestore} {MFshow} ifelse } bind def +/MRshow { currentpoint stroke M + exch dup MFwidth neg 3 -1 roll R + Blacktext {gsave 0 setgray MFshow grestore} {MFshow} ifelse } bind def +/MCshow { currentpoint stroke M + exch dup MFwidth -2 div 3 -1 roll R + Blacktext {gsave 0 setgray MFshow grestore} {MFshow} ifelse } bind def +/XYsave { [( ) 1 2 true false 3 ()] } bind def +/XYrestore { [( ) 1 2 true false 4 ()] } bind def +end +%%EndProlog +%%Page: 1 1 +gnudict begin +gsave +doclip +50 50 translate +0.100 0.100 scale +90 rotate +0 -5040 translate +0 setgray +newpath +(Helvetica) findfont 140 scalefont setfont +1.000 UL +LTb +518 448 M +63 0 V +stroke +434 448 M +[ [(Helvetica) 140.0 0.0 true true 0 ( 1)] +] -46.7 MRshow +1.000 UL +LTb +518 792 M +63 0 V +stroke +434 792 M +[ [(Helvetica) 140.0 0.0 true true 0 ( 2)] +] -46.7 MRshow +1.000 UL +LTb +518 1136 M +63 0 V +stroke +434 1136 M +[ [(Helvetica) 140.0 0.0 true true 0 ( 3)] +] -46.7 MRshow +1.000 UL +LTb +518 1480 M +63 0 V +stroke +434 1480 M +[ [(Helvetica) 140.0 0.0 true true 0 ( 4)] +] -46.7 MRshow +1.000 UL +LTb +518 1823 M +63 0 V +stroke +434 1823 M +[ [(Helvetica) 140.0 0.0 true true 0 ( 5)] +] -46.7 MRshow +1.000 UL +LTb +518 2167 M +63 0 V +stroke +434 2167 M +[ [(Helvetica) 140.0 0.0 true true 0 ( 6)] +] -46.7 MRshow +1.000 UL +LTb +518 2511 M +63 0 V +stroke +434 2511 M +[ [(Helvetica) 140.0 0.0 true true 0 ( 7)] +] -46.7 MRshow +1.000 UL +LTb +518 2855 M +63 0 V +stroke +434 2855 M +[ [(Helvetica) 140.0 0.0 true true 0 ( 8)] +] -46.7 MRshow +1.000 UL +LTb +518 448 M +0 63 V +stroke +518 308 M +[ [(Helvetica) 140.0 0.0 true true 0 ( 0)] +] -46.7 MCshow +1.000 UL +LTb +962 448 M +0 63 V +stroke +962 308 M +[ [(Helvetica) 140.0 0.0 true true 0 ( 1000)] +] -46.7 MCshow +1.000 UL +LTb +1405 448 M +0 63 V +stroke +1405 308 M +[ [(Helvetica) 140.0 0.0 true true 0 ( 2000)] +] -46.7 MCshow +1.000 UL +LTb +1849 448 M +0 63 V +stroke +1849 308 M +[ [(Helvetica) 140.0 0.0 true true 0 ( 3000)] +] -46.7 MCshow +1.000 UL +LTb +2293 448 M +0 63 V +stroke +2293 308 M +[ [(Helvetica) 140.0 0.0 true true 0 ( 4000)] +] -46.7 MCshow +1.000 UL +LTb +2736 448 M +0 63 V +stroke +2736 308 M +[ [(Helvetica) 140.0 0.0 true true 0 ( 5000)] +] -46.7 MCshow +1.000 UL +LTb +3180 448 M +0 63 V +stroke +3180 308 M +[ [(Helvetica) 140.0 0.0 true true 0 ( 6000)] +] -46.7 MCshow +1.000 UL +LTb +3623 448 M +0 63 V +stroke +3623 308 M +[ [(Helvetica) 140.0 0.0 true true 0 ( 7000)] +] -46.7 MCshow +1.000 UL +LTb +4067 448 M +0 63 V +stroke +4067 308 M +[ [(Helvetica) 140.0 0.0 true true 0 ( 8000)] +] -46.7 MCshow +1.000 UL +LTb +1.000 UL +LTb +518 2855 M +518 448 L +3549 0 V +0 2407 R +-3549 0 R +stroke +LCb setrgbcolor +112 1651 M +currentpoint gsave translate -270 rotate 0 0 moveto +[ [(Helvetica) 140.0 0.0 true true 0 (Ratio of Total Execution to Total Work)] +] -46.7 MCshow +grestore +LTb +LCb setrgbcolor +2292 98 M +[ [(Helvetica) 140.0 0.0 true true 0 (Cycles in one Task)] +] -46.7 MCshow +LTb +1.000 UP +1.000 UL +LTb +1.000 UL +LTb +2492 2372 N +0 420 V +1491 0 V +0 -420 V +-1491 0 V +Z stroke +2492 2792 M +1491 0 V +% Begin plot #1 +stroke +3.000 UL +LT1 +LCa setrgbcolor +518 792 M +36 0 V +36 0 V +36 0 V +35 0 V +36 0 V +36 0 V +36 0 V +36 0 V +36 0 V +35 0 V +36 0 V +36 0 V +36 0 V +36 0 V +36 0 V +36 0 V +35 0 V +36 0 V +36 0 V +36 0 V +36 0 V +36 0 V +36 0 V +35 0 V +36 0 V +36 0 V +36 0 V +36 0 V +36 0 V +35 0 V +36 0 V +36 0 V +36 0 V +36 0 V +36 0 V +36 0 V +35 0 V +36 0 V +36 0 V +36 0 V +36 0 V +36 0 V +35 0 V +36 0 V +36 0 V +36 0 V +36 0 V +36 0 V +36 0 V +35 0 V +36 0 V +36 0 V +36 0 V +36 0 V +36 0 V +36 0 V +35 0 V +36 0 V +36 0 V +36 0 V +36 0 V +36 0 V +35 0 V +36 0 V +36 0 V +36 0 V +36 0 V +36 0 V +36 0 V +35 0 V +36 0 V +36 0 V +36 0 V +36 0 V +36 0 V +35 0 V +36 0 V +36 0 V +36 0 V +36 0 V +36 0 V +36 0 V +35 0 V +36 0 V +36 0 V +36 0 V +36 0 V +36 0 V +36 0 V +35 0 V +36 0 V +36 0 V +36 0 V +36 0 V +36 0 V +35 0 V +36 0 V +36 0 V +36 0 V +% End plot #1 +% Begin plot #2 +stroke +4.000 UL +LT1 +LCb setrgbcolor +3416 2722 M +[ [(Helvetica) 140.0 0.0 true true 0 (8 Threads)] +] -46.7 MRshow +LT1 +3500 2722 M +399 0 V +715 2855 M +58 -684 V +984 1411 L +1411 947 L +2263 700 L +3965 573 L +% End plot #2 +% Begin plot #3 +stroke +LT2 +LCb setrgbcolor +3416 2582 M +[ [(Helvetica) 140.0 0.0 true true 0 (32 Threads)] +] -46.7 MRshow +LT2 +3500 2582 M +399 0 V +947 2855 M +38 -338 V +427 -979 V +849 -507 V +3969 747 L +% End plot #3 +% Begin plot #4 +stroke +LT3 +LCb setrgbcolor +3416 2442 M +[ [(Helvetica) 140.0 0.0 true true 0 (128 Threads)] +] -46.7 MRshow +LT3 +3500 2442 M +399 0 V +2070 2855 M +197 -434 V +3969 1446 L +% End plot #4 +stroke +1.000 UL +LTb +518 2855 M +518 448 L +3549 0 V +0 2407 R +-3549 0 R +1.000 UP +stroke +grestore +end +showpage +%%Trailer +%%DocumentFonts: Helvetica +%%Pages: 1 diff -r 9b9a2497757d -r eb146c5c05a8 0__Papers/PRT/PRT__formal_def/figures/plots_exec_vs_task_size/not_used/vms_vthread_8_32_128_512thds__o30000__perfCtrs.result.eps --- /dev/null Thu Jan 01 00:00:00 1970 +0000 +++ b/0__Papers/PRT/PRT__formal_def/figures/plots_exec_vs_task_size/not_used/vms_vthread_8_32_128_512thds__o30000__perfCtrs.result.eps Sat Aug 03 19:24:22 2013 -0700 @@ -0,0 +1,852 @@ +%!PS-Adobe-2.0 +%%Title: vms_vthread_8_32_128_512thds__o30000__perfCtrs.result.eps +%%Creator: gnuplot 4.4 patchlevel 2 +%%CreationDate: Thu Jan 26 18:12:20 2012 +%%DocumentFonts: (atend) +%%BoundingBox: 251 50 554 482 +%%Orientation: Landscape +%%Pages: (atend) +%%EndComments +%%BeginProlog +/gnudict 256 dict def +gnudict begin +% +% The following true/false flags may be edited by hand if desired. +% The unit line width and grayscale image gamma correction may also be changed. +% +/Color true def +/Blacktext false def +/Solid false def +/Dashlength 1 def +/Landscape true def +/Level1 false def +/Rounded false def +/ClipToBoundingBox false def +/TransparentPatterns false def +/gnulinewidth 5.000 def +/userlinewidth gnulinewidth def +/Gamma 1.0 def +% +/vshift -46 def +/dl1 { + 10.0 Dashlength mul mul + Rounded { currentlinewidth 0.75 mul sub dup 0 le { pop 0.01 } if } if +} def +/dl2 { + 10.0 Dashlength mul mul + Rounded { currentlinewidth 0.75 mul add } if +} def +/hpt_ 31.5 def +/vpt_ 31.5 def +/hpt hpt_ def +/vpt vpt_ def +Level1 {} { +/SDict 10 dict def +systemdict /pdfmark known not { + userdict /pdfmark systemdict /cleartomark get put +} if +SDict begin [ + /Title (vms_vthread_8_32_128_512thds__o30000__perfCtrs.result.eps) + /Subject (gnuplot plot) + /Creator (gnuplot 4.4 patchlevel 2) + /Author (msach) +% /Producer (gnuplot) +% /Keywords () + /CreationDate (Thu Jan 26 18:12:20 2012) + /DOCINFO pdfmark +end +} ifelse +/doclip { + ClipToBoundingBox { + newpath 251 50 moveto 554 50 lineto 554 482 lineto 251 482 lineto closepath + clip + } if +} def +% +% Gnuplot Prolog Version 4.4 (August 2010) +% +%/SuppressPDFMark true def +% +/M {moveto} bind def +/L {lineto} bind def +/R {rmoveto} bind def +/V {rlineto} bind def +/N {newpath moveto} bind def +/Z {closepath} bind def +/C {setrgbcolor} bind def +/f {rlineto fill} bind def +/g {setgray} bind def +/Gshow {show} def % May be redefined later in the file to support UTF-8 +/vpt2 vpt 2 mul def +/hpt2 hpt 2 mul def +/Lshow {currentpoint stroke M 0 vshift R + Blacktext {gsave 0 setgray show grestore} {show} ifelse} def +/Rshow {currentpoint stroke M dup stringwidth pop neg vshift R + Blacktext {gsave 0 setgray show grestore} {show} ifelse} def +/Cshow {currentpoint stroke M dup stringwidth pop -2 div vshift R + Blacktext {gsave 0 setgray show grestore} {show} ifelse} def +/UP {dup vpt_ mul /vpt exch def hpt_ mul /hpt exch def + /hpt2 hpt 2 mul def /vpt2 vpt 2 mul def} def +/DL {Color {setrgbcolor Solid {pop []} if 0 setdash} + {pop pop pop 0 setgray Solid {pop []} if 0 setdash} ifelse} def +/BL {stroke userlinewidth 2 mul setlinewidth + Rounded {1 setlinejoin 1 setlinecap} if} def +/AL {stroke userlinewidth 2 div setlinewidth + Rounded {1 setlinejoin 1 setlinecap} if} def +/UL {dup gnulinewidth mul /userlinewidth exch def + dup 1 lt {pop 1} if 10 mul /udl exch def} def +/PL {stroke userlinewidth setlinewidth + Rounded {1 setlinejoin 1 setlinecap} if} def +3.8 setmiterlimit +% Default Line colors +/LCw {1 1 1} def +/LCb {0 0 0} def +/LCa {0 0 0} def +/LC0 {1 0 0} def +/LC1 {0 1 0} def +/LC2 {0 0 1} def +/LC3 {1 0 1} def +/LC4 {0 1 1} def +/LC5 {1 1 0} def +/LC6 {0 0 0} def +/LC7 {1 0.3 0} def +/LC8 {0.5 0.5 0.5} def +% Default Line Types +/LTw {PL [] 1 setgray} def +/LTb {BL [] LCb DL} def +/LTa {AL [1 udl mul 2 udl mul] 0 setdash LCa setrgbcolor} def +/LT0 {PL [] LC0 DL} def +/LT1 {PL [4 dl1 2 dl2] LC1 DL} def +/LT2 {PL [2 dl1 3 dl2] LC2 DL} def +/LT3 {PL [1 dl1 1.5 dl2] LC3 DL} def +/LT4 {PL [6 dl1 2 dl2 1 dl1 2 dl2] LC4 DL} def +/LT5 {PL [3 dl1 3 dl2 1 dl1 3 dl2] LC5 DL} def +/LT6 {PL [2 dl1 2 dl2 2 dl1 6 dl2] LC6 DL} def +/LT7 {PL [1 dl1 2 dl2 6 dl1 2 dl2 1 dl1 2 dl2] LC7 DL} def +/LT8 {PL [2 dl1 2 dl2 2 dl1 2 dl2 2 dl1 2 dl2 2 dl1 4 dl2] LC8 DL} def +/Pnt {stroke [] 0 setdash gsave 1 setlinecap M 0 0 V stroke grestore} def +/Dia {stroke [] 0 setdash 2 copy vpt add M + hpt neg vpt neg V hpt vpt neg V + hpt vpt V hpt neg vpt V closepath stroke + Pnt} def +/Pls {stroke [] 0 setdash vpt sub M 0 vpt2 V + currentpoint stroke M + hpt neg vpt neg R hpt2 0 V stroke + } def +/Box {stroke [] 0 setdash 2 copy exch hpt sub exch vpt add M + 0 vpt2 neg V hpt2 0 V 0 vpt2 V + hpt2 neg 0 V closepath stroke + Pnt} def +/Crs {stroke [] 0 setdash exch hpt sub exch vpt add M + hpt2 vpt2 neg V currentpoint stroke M + hpt2 neg 0 R hpt2 vpt2 V stroke} def +/TriU {stroke [] 0 setdash 2 copy vpt 1.12 mul add M + hpt neg vpt -1.62 mul V + hpt 2 mul 0 V + hpt neg vpt 1.62 mul V closepath stroke + Pnt} def +/Star {2 copy Pls Crs} def +/BoxF {stroke [] 0 setdash exch hpt sub exch vpt add M + 0 vpt2 neg V hpt2 0 V 0 vpt2 V + hpt2 neg 0 V closepath fill} def +/TriUF {stroke [] 0 setdash vpt 1.12 mul add M + hpt neg vpt -1.62 mul V + hpt 2 mul 0 V + hpt neg vpt 1.62 mul V closepath fill} def +/TriD {stroke [] 0 setdash 2 copy vpt 1.12 mul sub M + hpt neg vpt 1.62 mul V + hpt 2 mul 0 V + hpt neg vpt -1.62 mul V closepath stroke + Pnt} def +/TriDF {stroke [] 0 setdash vpt 1.12 mul sub M + hpt neg vpt 1.62 mul V + hpt 2 mul 0 V + hpt neg vpt -1.62 mul V closepath fill} def +/DiaF {stroke [] 0 setdash vpt add M + hpt neg vpt neg V hpt vpt neg V + hpt vpt V hpt neg vpt V closepath fill} def +/Pent {stroke [] 0 setdash 2 copy gsave + translate 0 hpt M 4 {72 rotate 0 hpt L} repeat + closepath stroke grestore Pnt} def +/PentF {stroke [] 0 setdash gsave + translate 0 hpt M 4 {72 rotate 0 hpt L} repeat + closepath fill grestore} def +/Circle {stroke [] 0 setdash 2 copy + hpt 0 360 arc stroke Pnt} def +/CircleF {stroke [] 0 setdash hpt 0 360 arc fill} def +/C0 {BL [] 0 setdash 2 copy moveto vpt 90 450 arc} bind def +/C1 {BL [] 0 setdash 2 copy moveto + 2 copy vpt 0 90 arc closepath fill + vpt 0 360 arc closepath} bind def +/C2 {BL [] 0 setdash 2 copy moveto + 2 copy vpt 90 180 arc closepath fill + vpt 0 360 arc closepath} bind def +/C3 {BL [] 0 setdash 2 copy moveto + 2 copy vpt 0 180 arc closepath fill + vpt 0 360 arc closepath} bind def +/C4 {BL [] 0 setdash 2 copy moveto + 2 copy vpt 180 270 arc closepath fill + vpt 0 360 arc closepath} bind def +/C5 {BL [] 0 setdash 2 copy moveto + 2 copy vpt 0 90 arc + 2 copy moveto + 2 copy vpt 180 270 arc closepath fill + vpt 0 360 arc} bind def +/C6 {BL [] 0 setdash 2 copy moveto + 2 copy vpt 90 270 arc closepath fill + vpt 0 360 arc closepath} bind def +/C7 {BL [] 0 setdash 2 copy moveto + 2 copy vpt 0 270 arc closepath fill + vpt 0 360 arc closepath} bind def +/C8 {BL [] 0 setdash 2 copy moveto + 2 copy vpt 270 360 arc closepath fill + vpt 0 360 arc closepath} bind def +/C9 {BL [] 0 setdash 2 copy moveto + 2 copy vpt 270 450 arc closepath fill + vpt 0 360 arc closepath} bind def +/C10 {BL [] 0 setdash 2 copy 2 copy moveto vpt 270 360 arc closepath fill + 2 copy moveto + 2 copy vpt 90 180 arc closepath fill + vpt 0 360 arc closepath} bind def +/C11 {BL [] 0 setdash 2 copy moveto + 2 copy vpt 0 180 arc closepath fill + 2 copy moveto + 2 copy vpt 270 360 arc closepath fill + vpt 0 360 arc closepath} bind def +/C12 {BL [] 0 setdash 2 copy moveto + 2 copy vpt 180 360 arc closepath fill + vpt 0 360 arc closepath} bind def +/C13 {BL [] 0 setdash 2 copy moveto + 2 copy vpt 0 90 arc closepath fill + 2 copy moveto + 2 copy vpt 180 360 arc closepath fill + vpt 0 360 arc closepath} bind def +/C14 {BL [] 0 setdash 2 copy moveto + 2 copy vpt 90 360 arc closepath fill + vpt 0 360 arc} bind def +/C15 {BL [] 0 setdash 2 copy vpt 0 360 arc closepath fill + vpt 0 360 arc closepath} bind def +/Rec {newpath 4 2 roll moveto 1 index 0 rlineto 0 exch rlineto + neg 0 rlineto closepath} bind def +/Square {dup Rec} bind def +/Bsquare {vpt sub exch vpt sub exch vpt2 Square} bind def +/S0 {BL [] 0 setdash 2 copy moveto 0 vpt rlineto BL Bsquare} bind def +/S1 {BL [] 0 setdash 2 copy vpt Square fill Bsquare} bind def +/S2 {BL [] 0 setdash 2 copy exch vpt sub exch vpt Square fill Bsquare} bind def +/S3 {BL [] 0 setdash 2 copy exch vpt sub exch vpt2 vpt Rec fill Bsquare} bind def +/S4 {BL [] 0 setdash 2 copy exch vpt sub exch vpt sub vpt Square fill Bsquare} bind def +/S5 {BL [] 0 setdash 2 copy 2 copy vpt Square fill + exch vpt sub exch vpt sub vpt Square fill Bsquare} bind def +/S6 {BL [] 0 setdash 2 copy exch vpt sub exch vpt sub vpt vpt2 Rec fill Bsquare} bind def +/S7 {BL [] 0 setdash 2 copy exch vpt sub exch vpt sub vpt vpt2 Rec fill + 2 copy vpt Square fill Bsquare} bind def +/S8 {BL [] 0 setdash 2 copy vpt sub vpt Square fill Bsquare} bind def +/S9 {BL [] 0 setdash 2 copy vpt sub vpt vpt2 Rec fill Bsquare} bind def +/S10 {BL [] 0 setdash 2 copy vpt sub vpt Square fill 2 copy exch vpt sub exch vpt Square fill + Bsquare} bind def +/S11 {BL [] 0 setdash 2 copy vpt sub vpt Square fill 2 copy exch vpt sub exch vpt2 vpt Rec fill + Bsquare} bind def +/S12 {BL [] 0 setdash 2 copy exch vpt sub exch vpt sub vpt2 vpt Rec fill Bsquare} bind def +/S13 {BL [] 0 setdash 2 copy exch vpt sub exch vpt sub vpt2 vpt Rec fill + 2 copy vpt Square fill Bsquare} bind def +/S14 {BL [] 0 setdash 2 copy exch vpt sub exch vpt sub vpt2 vpt Rec fill + 2 copy exch vpt sub exch vpt Square fill Bsquare} bind def +/S15 {BL [] 0 setdash 2 copy Bsquare fill Bsquare} bind def +/D0 {gsave translate 45 rotate 0 0 S0 stroke grestore} bind def +/D1 {gsave translate 45 rotate 0 0 S1 stroke grestore} bind def +/D2 {gsave translate 45 rotate 0 0 S2 stroke grestore} bind def +/D3 {gsave translate 45 rotate 0 0 S3 stroke grestore} bind def +/D4 {gsave translate 45 rotate 0 0 S4 stroke grestore} bind def +/D5 {gsave translate 45 rotate 0 0 S5 stroke grestore} bind def +/D6 {gsave translate 45 rotate 0 0 S6 stroke grestore} bind def +/D7 {gsave translate 45 rotate 0 0 S7 stroke grestore} bind def +/D8 {gsave translate 45 rotate 0 0 S8 stroke grestore} bind def +/D9 {gsave translate 45 rotate 0 0 S9 stroke grestore} bind def +/D10 {gsave translate 45 rotate 0 0 S10 stroke grestore} bind def +/D11 {gsave translate 45 rotate 0 0 S11 stroke grestore} bind def +/D12 {gsave translate 45 rotate 0 0 S12 stroke grestore} bind def +/D13 {gsave translate 45 rotate 0 0 S13 stroke grestore} bind def +/D14 {gsave translate 45 rotate 0 0 S14 stroke grestore} bind def +/D15 {gsave translate 45 rotate 0 0 S15 stroke grestore} bind def +/DiaE {stroke [] 0 setdash vpt add M + hpt neg vpt neg V hpt vpt neg V + hpt vpt V hpt neg vpt V closepath stroke} def +/BoxE {stroke [] 0 setdash exch hpt sub exch vpt add M + 0 vpt2 neg V hpt2 0 V 0 vpt2 V + hpt2 neg 0 V closepath stroke} def +/TriUE {stroke [] 0 setdash vpt 1.12 mul add M + hpt neg vpt -1.62 mul V + hpt 2 mul 0 V + hpt neg vpt 1.62 mul V closepath stroke} def +/TriDE {stroke [] 0 setdash vpt 1.12 mul sub M + hpt neg vpt 1.62 mul V + hpt 2 mul 0 V + hpt neg vpt -1.62 mul V closepath stroke} def +/PentE {stroke [] 0 setdash gsave + translate 0 hpt M 4 {72 rotate 0 hpt L} repeat + closepath stroke grestore} def +/CircE {stroke [] 0 setdash + hpt 0 360 arc stroke} def +/Opaque {gsave closepath 1 setgray fill grestore 0 setgray closepath} def +/DiaW {stroke [] 0 setdash vpt add M + hpt neg vpt neg V hpt vpt neg V + hpt vpt V hpt neg vpt V Opaque stroke} def +/BoxW {stroke [] 0 setdash exch hpt sub exch vpt add M + 0 vpt2 neg V hpt2 0 V 0 vpt2 V + hpt2 neg 0 V Opaque stroke} def +/TriUW {stroke [] 0 setdash vpt 1.12 mul add M + hpt neg vpt -1.62 mul V + hpt 2 mul 0 V + hpt neg vpt 1.62 mul V Opaque stroke} def +/TriDW {stroke [] 0 setdash vpt 1.12 mul sub M + hpt neg vpt 1.62 mul V + hpt 2 mul 0 V + hpt neg vpt -1.62 mul V Opaque stroke} def +/PentW {stroke [] 0 setdash gsave + translate 0 hpt M 4 {72 rotate 0 hpt L} repeat + Opaque stroke grestore} def +/CircW {stroke [] 0 setdash + hpt 0 360 arc Opaque stroke} def +/BoxFill {gsave Rec 1 setgray fill grestore} def +/Density { + /Fillden exch def + currentrgbcolor + /ColB exch def /ColG exch def /ColR exch def + /ColR ColR Fillden mul Fillden sub 1 add def + /ColG ColG Fillden mul Fillden sub 1 add def + /ColB ColB Fillden mul Fillden sub 1 add def + ColR ColG ColB setrgbcolor} def +/BoxColFill {gsave Rec PolyFill} def +/PolyFill {gsave Density fill grestore grestore} def +/h {rlineto rlineto rlineto gsave closepath fill grestore} bind def +% +% PostScript Level 1 Pattern Fill routine for rectangles +% Usage: x y w h s a XX PatternFill +% x,y = lower left corner of box to be filled +% w,h = width and height of box +% a = angle in degrees between lines and x-axis +% XX = 0/1 for no/yes cross-hatch +% +/PatternFill {gsave /PFa [ 9 2 roll ] def + PFa 0 get PFa 2 get 2 div add PFa 1 get PFa 3 get 2 div add translate + PFa 2 get -2 div PFa 3 get -2 div PFa 2 get PFa 3 get Rec + gsave 1 setgray fill grestore clip + currentlinewidth 0.5 mul setlinewidth + /PFs PFa 2 get dup mul PFa 3 get dup mul add sqrt def + 0 0 M PFa 5 get rotate PFs -2 div dup translate + 0 1 PFs PFa 4 get div 1 add floor cvi + {PFa 4 get mul 0 M 0 PFs V} for + 0 PFa 6 get ne { + 0 1 PFs PFa 4 get div 1 add floor cvi + {PFa 4 get mul 0 2 1 roll M PFs 0 V} for + } if + stroke grestore} def +% +/languagelevel where + {pop languagelevel} {1} ifelse + 2 lt + {/InterpretLevel1 true def} + {/InterpretLevel1 Level1 def} + ifelse +% +% PostScript level 2 pattern fill definitions +% +/Level2PatternFill { +/Tile8x8 {/PaintType 2 /PatternType 1 /TilingType 1 /BBox [0 0 8 8] /XStep 8 /YStep 8} + bind def +/KeepColor {currentrgbcolor [/Pattern /DeviceRGB] setcolorspace} bind def +<< Tile8x8 + /PaintProc {0.5 setlinewidth pop 0 0 M 8 8 L 0 8 M 8 0 L stroke} +>> matrix makepattern +/Pat1 exch def +<< Tile8x8 + /PaintProc {0.5 setlinewidth pop 0 0 M 8 8 L 0 8 M 8 0 L stroke + 0 4 M 4 8 L 8 4 L 4 0 L 0 4 L stroke} +>> matrix makepattern +/Pat2 exch def +<< Tile8x8 + /PaintProc {0.5 setlinewidth pop 0 0 M 0 8 L + 8 8 L 8 0 L 0 0 L fill} +>> matrix makepattern +/Pat3 exch def +<< Tile8x8 + /PaintProc {0.5 setlinewidth pop -4 8 M 8 -4 L + 0 12 M 12 0 L stroke} +>> matrix makepattern +/Pat4 exch def +<< Tile8x8 + /PaintProc {0.5 setlinewidth pop -4 0 M 8 12 L + 0 -4 M 12 8 L stroke} +>> matrix makepattern +/Pat5 exch def +<< Tile8x8 + /PaintProc {0.5 setlinewidth pop -2 8 M 4 -4 L + 0 12 M 8 -4 L 4 12 M 10 0 L stroke} +>> matrix makepattern +/Pat6 exch def +<< Tile8x8 + /PaintProc {0.5 setlinewidth pop -2 0 M 4 12 L + 0 -4 M 8 12 L 4 -4 M 10 8 L stroke} +>> matrix makepattern +/Pat7 exch def +<< Tile8x8 + /PaintProc {0.5 setlinewidth pop 8 -2 M -4 4 L + 12 0 M -4 8 L 12 4 M 0 10 L stroke} +>> matrix makepattern +/Pat8 exch def +<< Tile8x8 + /PaintProc {0.5 setlinewidth pop 0 -2 M 12 4 L + -4 0 M 12 8 L -4 4 M 8 10 L stroke} +>> matrix makepattern +/Pat9 exch def +/Pattern1 {PatternBgnd KeepColor Pat1 setpattern} bind def +/Pattern2 {PatternBgnd KeepColor Pat2 setpattern} bind def +/Pattern3 {PatternBgnd KeepColor Pat3 setpattern} bind def +/Pattern4 {PatternBgnd KeepColor Landscape {Pat5} {Pat4} ifelse setpattern} bind def +/Pattern5 {PatternBgnd KeepColor Landscape {Pat4} {Pat5} ifelse setpattern} bind def +/Pattern6 {PatternBgnd KeepColor Landscape {Pat9} {Pat6} ifelse setpattern} bind def +/Pattern7 {PatternBgnd KeepColor Landscape {Pat8} {Pat7} ifelse setpattern} bind def +} def +% +% +%End of PostScript Level 2 code +% +/PatternBgnd { + TransparentPatterns {} {gsave 1 setgray fill grestore} ifelse +} def +% +% Substitute for Level 2 pattern fill codes with +% grayscale if Level 2 support is not selected. +% +/Level1PatternFill { +/Pattern1 {0.250 Density} bind def +/Pattern2 {0.500 Density} bind def +/Pattern3 {0.750 Density} bind def +/Pattern4 {0.125 Density} bind def +/Pattern5 {0.375 Density} bind def +/Pattern6 {0.625 Density} bind def +/Pattern7 {0.875 Density} bind def +} def +% +% Now test for support of Level 2 code +% +Level1 {Level1PatternFill} {Level2PatternFill} ifelse +% +/Symbol-Oblique /Symbol findfont [1 0 .167 1 0 0] makefont +dup length dict begin {1 index /FID eq {pop pop} {def} ifelse} forall +currentdict end definefont pop +/MFshow { + { dup 5 get 3 ge + { 5 get 3 eq {gsave} {grestore} ifelse } + {dup dup 0 get findfont exch 1 get scalefont setfont + [ currentpoint ] exch dup 2 get 0 exch R dup 5 get 2 ne {dup dup 6 + get exch 4 get {Gshow} {stringwidth pop 0 R} ifelse }if dup 5 get 0 eq + {dup 3 get {2 get neg 0 exch R pop} {pop aload pop M} ifelse} {dup 5 + get 1 eq {dup 2 get exch dup 3 get exch 6 get stringwidth pop -2 div + dup 0 R} {dup 6 get stringwidth pop -2 div 0 R 6 get + show 2 index {aload pop M neg 3 -1 roll neg R pop pop} {pop pop pop + pop aload pop M} ifelse }ifelse }ifelse } + ifelse } + forall} def +/Gswidth {dup type /stringtype eq {stringwidth} {pop (n) stringwidth} ifelse} def +/MFwidth {0 exch { dup 5 get 3 ge { 5 get 3 eq { 0 } { pop } ifelse } + {dup 3 get{dup dup 0 get findfont exch 1 get scalefont setfont + 6 get Gswidth pop add} {pop} ifelse} ifelse} forall} def +/MLshow { currentpoint stroke M + 0 exch R + Blacktext {gsave 0 setgray MFshow grestore} {MFshow} ifelse } bind def +/MRshow { currentpoint stroke M + exch dup MFwidth neg 3 -1 roll R + Blacktext {gsave 0 setgray MFshow grestore} {MFshow} ifelse } bind def +/MCshow { currentpoint stroke M + exch dup MFwidth -2 div 3 -1 roll R + Blacktext {gsave 0 setgray MFshow grestore} {MFshow} ifelse } bind def +/XYsave { [( ) 1 2 true false 3 ()] } bind def +/XYrestore { [( ) 1 2 true false 4 ()] } bind def +end +%%EndProlog +%%Page: 1 1 +gnudict begin +gsave +doclip +50 50 translate +0.100 0.100 scale +90 rotate +0 -5040 translate +0 setgray +newpath +(Helvetica) findfont 140 scalefont setfont +1.000 UL +LTb +518 448 M +63 0 V +stroke +434 448 M +[ [(Helvetica) 140.0 0.0 true true 0 ( 1)] +] -46.7 MRshow +1.000 UL +LTb +518 792 M +63 0 V +stroke +434 792 M +[ [(Helvetica) 140.0 0.0 true true 0 ( 2)] +] -46.7 MRshow +1.000 UL +LTb +518 1136 M +63 0 V +stroke +434 1136 M +[ [(Helvetica) 140.0 0.0 true true 0 ( 3)] +] -46.7 MRshow +1.000 UL +LTb +518 1480 M +63 0 V +stroke +434 1480 M +[ [(Helvetica) 140.0 0.0 true true 0 ( 4)] +] -46.7 MRshow +1.000 UL +LTb +518 1823 M +63 0 V +stroke +434 1823 M +[ [(Helvetica) 140.0 0.0 true true 0 ( 5)] +] -46.7 MRshow +1.000 UL +LTb +518 2167 M +63 0 V +stroke +434 2167 M +[ [(Helvetica) 140.0 0.0 true true 0 ( 6)] +] -46.7 MRshow +1.000 UL +LTb +518 2511 M +63 0 V +stroke +434 2511 M +[ [(Helvetica) 140.0 0.0 true true 0 ( 7)] +] -46.7 MRshow +1.000 UL +LTb +518 2855 M +63 0 V +stroke +434 2855 M +[ [(Helvetica) 140.0 0.0 true true 0 ( 8)] +] -46.7 MRshow +1.000 UL +LTb +518 448 M +0 63 V +stroke +518 308 M +[ [(Helvetica) 140.0 0.0 true true 0 ( 0)] +] -46.7 MCshow +1.000 UL +LTb +962 448 M +0 63 V +stroke +962 308 M +[ [(Helvetica) 140.0 0.0 true true 0 ( 1000)] +] -46.7 MCshow +1.000 UL +LTb +1405 448 M +0 63 V +stroke +1405 308 M +[ [(Helvetica) 140.0 0.0 true true 0 ( 2000)] +] -46.7 MCshow +1.000 UL +LTb +1849 448 M +0 63 V +stroke +1849 308 M +[ [(Helvetica) 140.0 0.0 true true 0 ( 3000)] +] -46.7 MCshow +1.000 UL +LTb +2293 448 M +0 63 V +stroke +2293 308 M +[ [(Helvetica) 140.0 0.0 true true 0 ( 4000)] +] -46.7 MCshow +1.000 UL +LTb +2736 448 M +0 63 V +stroke +2736 308 M +[ [(Helvetica) 140.0 0.0 true true 0 ( 5000)] +] -46.7 MCshow +1.000 UL +LTb +3180 448 M +0 63 V +stroke +3180 308 M +[ [(Helvetica) 140.0 0.0 true true 0 ( 6000)] +] -46.7 MCshow +1.000 UL +LTb +3623 448 M +0 63 V +stroke +3623 308 M +[ [(Helvetica) 140.0 0.0 true true 0 ( 7000)] +] -46.7 MCshow +1.000 UL +LTb +4067 448 M +0 63 V +stroke +4067 308 M +[ [(Helvetica) 140.0 0.0 true true 0 ( 8000)] +] -46.7 MCshow +1.000 UL +LTb +1.000 UL +LTb +518 2855 M +518 448 L +3549 0 V +0 2407 R +-3549 0 R +stroke +LCb setrgbcolor +112 1651 M +currentpoint gsave translate -270 rotate 0 0 moveto +[ [(Helvetica) 140.0 0.0 true true 0 (Ratio of Total Execution to Total Work)] +] -46.7 MCshow +grestore +LTb +LCb setrgbcolor +2292 98 M +[ [(Helvetica) 140.0 0.0 true true 0 (Cycles in one Task)] +] -46.7 MCshow +LTb +1.000 UP +1.000 UL +LTb +1.000 UL +LTb +2492 2232 N +0 560 V +1491 0 V +0 -560 V +-1491 0 V +Z stroke +2492 2792 M +1491 0 V +% Begin plot #1 +stroke +3.000 UL +LT1 +LCa setrgbcolor +518 792 M +36 0 V +36 0 V +36 0 V +35 0 V +36 0 V +36 0 V +36 0 V +36 0 V +36 0 V +35 0 V +36 0 V +36 0 V +36 0 V +36 0 V +36 0 V +36 0 V +35 0 V +36 0 V +36 0 V +36 0 V +36 0 V +36 0 V +36 0 V +35 0 V +36 0 V +36 0 V +36 0 V +36 0 V +36 0 V +35 0 V +36 0 V +36 0 V +36 0 V +36 0 V +36 0 V +36 0 V +35 0 V +36 0 V +36 0 V +36 0 V +36 0 V +36 0 V +35 0 V +36 0 V +36 0 V +36 0 V +36 0 V +36 0 V +36 0 V +35 0 V +36 0 V +36 0 V +36 0 V +36 0 V +36 0 V +36 0 V +35 0 V +36 0 V +36 0 V +36 0 V +36 0 V +36 0 V +35 0 V +36 0 V +36 0 V +36 0 V +36 0 V +36 0 V +36 0 V +35 0 V +36 0 V +36 0 V +36 0 V +36 0 V +36 0 V +35 0 V +36 0 V +36 0 V +36 0 V +36 0 V +36 0 V +36 0 V +35 0 V +36 0 V +36 0 V +36 0 V +36 0 V +36 0 V +36 0 V +35 0 V +36 0 V +36 0 V +36 0 V +36 0 V +36 0 V +35 0 V +36 0 V +36 0 V +36 0 V +% End plot #1 +% Begin plot #2 +stroke +4.000 UL +LT1 +LCb setrgbcolor +3416 2722 M +[ [(Helvetica) 140.0 0.0 true true 0 (8 Threads)] +] -46.7 MRshow +LT1 +3500 2722 M +399 0 V +572 2677 M +16 -429 V +24 -559 V +55 -454 V +774 920 L +987 706 L +1411 563 L +852 -54 V +3966 478 L +% End plot #2 +% Begin plot #3 +stroke +LT2 +LCb setrgbcolor +3416 2582 M +[ [(Helvetica) 140.0 0.0 true true 0 (32 Threads)] +] -46.7 MRshow +LT2 +3500 2582 M +399 0 V +571 2168 M +17 -436 V +24 -217 V +55 -464 V +774 801 L +986 651 L +1412 549 L +852 -55 V +3966 472 L +% End plot #3 +% Begin plot #4 +stroke +LT3 +LCb setrgbcolor +3416 2442 M +[ [(Helvetica) 140.0 0.0 true true 0 (128 Threads)] +] -46.7 MRshow +LT3 +3500 2442 M +399 0 V +572 2234 M +16 -381 V +26 -417 V +53 -317 V +773 823 L +987 656 L +1412 553 L +852 -51 V +3968 472 L +% End plot #4 +% Begin plot #5 +stroke +LT4 +LCb setrgbcolor +3416 2302 M +[ [(Helvetica) 140.0 0.0 true true 0 (512 Threads)] +] -46.7 MRshow +LT4 +3500 2302 M +399 0 V +572 2389 M +14 -445 V +27 -449 V +54 -383 V +772 837 L +985 659 L +1411 552 L +853 -52 V +3968 473 L +% End plot #5 +stroke +1.000 UL +LTb +518 2855 M +518 448 L +3549 0 V +0 2407 R +-3549 0 R +1.000 UP +stroke +grestore +end +showpage +%%Trailer +%%DocumentFonts: Helvetica +%%Pages: 1 diff -r 9b9a2497757d -r eb146c5c05a8 0__Papers/PRT/PRT__formal_def/figures/plots_exec_vs_task_size/not_used/xoanon_pthreads_40cores_80_160_320_640thds__o30000__perfCtrs.result.eps --- /dev/null Thu Jan 01 00:00:00 1970 +0000 +++ b/0__Papers/PRT/PRT__formal_def/figures/plots_exec_vs_task_size/not_used/xoanon_pthreads_40cores_80_160_320_640thds__o30000__perfCtrs.result.eps Sat Aug 03 19:24:22 2013 -0700 @@ -0,0 +1,699 @@ +%!PS-Adobe-2.0 +%%Title: xoanon_pthreads_40cores_80_160_320_640thds__o30000__perfCtrs.result.eps +%%Creator: gnuplot 4.4 patchlevel 2 +%%CreationDate: Thu Jan 26 18:22:29 2012 +%%DocumentFonts: (atend) +%%BoundingBox: 251 50 554 482 +%%Orientation: Landscape +%%Pages: (atend) +%%EndComments +%%BeginProlog +/gnudict 256 dict def +gnudict begin +% +% The following true/false flags may be edited by hand if desired. +% The unit line width and grayscale image gamma correction may also be changed. +% +/Color true def +/Blacktext false def +/Solid false def +/Dashlength 1 def +/Landscape true def +/Level1 false def +/Rounded false def +/ClipToBoundingBox false def +/TransparentPatterns false def +/gnulinewidth 5.000 def +/userlinewidth gnulinewidth def +/Gamma 1.0 def +% +/vshift -46 def +/dl1 { + 10.0 Dashlength mul mul + Rounded { currentlinewidth 0.75 mul sub dup 0 le { pop 0.01 } if } if +} def +/dl2 { + 10.0 Dashlength mul mul + Rounded { currentlinewidth 0.75 mul add } if +} def +/hpt_ 31.5 def +/vpt_ 31.5 def +/hpt hpt_ def +/vpt vpt_ def +Level1 {} { +/SDict 10 dict def +systemdict /pdfmark known not { + userdict /pdfmark systemdict /cleartomark get put +} if +SDict begin [ + /Title (xoanon_pthreads_40cores_80_160_320_640thds__o30000__perfCtrs.result.eps) + /Subject (gnuplot plot) + /Creator (gnuplot 4.4 patchlevel 2) + /Author (msach) +% /Producer (gnuplot) +% /Keywords () + /CreationDate (Thu Jan 26 18:22:29 2012) + /DOCINFO pdfmark +end +} ifelse +/doclip { + ClipToBoundingBox { + newpath 251 50 moveto 554 50 lineto 554 482 lineto 251 482 lineto closepath + clip + } if +} def +% +% Gnuplot Prolog Version 4.4 (August 2010) +% +%/SuppressPDFMark true def +% +/M {moveto} bind def +/L {lineto} bind def +/R {rmoveto} bind def +/V {rlineto} bind def +/N {newpath moveto} bind def +/Z {closepath} bind def +/C {setrgbcolor} bind def +/f {rlineto fill} bind def +/g {setgray} bind def +/Gshow {show} def % May be redefined later in the file to support UTF-8 +/vpt2 vpt 2 mul def +/hpt2 hpt 2 mul def +/Lshow {currentpoint stroke M 0 vshift R + Blacktext {gsave 0 setgray show grestore} {show} ifelse} def +/Rshow {currentpoint stroke M dup stringwidth pop neg vshift R + Blacktext {gsave 0 setgray show grestore} {show} ifelse} def +/Cshow {currentpoint stroke M dup stringwidth pop -2 div vshift R + Blacktext {gsave 0 setgray show grestore} {show} ifelse} def +/UP {dup vpt_ mul /vpt exch def hpt_ mul /hpt exch def + /hpt2 hpt 2 mul def /vpt2 vpt 2 mul def} def +/DL {Color {setrgbcolor Solid {pop []} if 0 setdash} + {pop pop pop 0 setgray Solid {pop []} if 0 setdash} ifelse} def +/BL {stroke userlinewidth 2 mul setlinewidth + Rounded {1 setlinejoin 1 setlinecap} if} def +/AL {stroke userlinewidth 2 div setlinewidth + Rounded {1 setlinejoin 1 setlinecap} if} def +/UL {dup gnulinewidth mul /userlinewidth exch def + dup 1 lt {pop 1} if 10 mul /udl exch def} def +/PL {stroke userlinewidth setlinewidth + Rounded {1 setlinejoin 1 setlinecap} if} def +3.8 setmiterlimit +% Default Line colors +/LCw {1 1 1} def +/LCb {0 0 0} def +/LCa {0 0 0} def +/LC0 {1 0 0} def +/LC1 {0 1 0} def +/LC2 {0 0 1} def +/LC3 {1 0 1} def +/LC4 {0 1 1} def +/LC5 {1 1 0} def +/LC6 {0 0 0} def +/LC7 {1 0.3 0} def +/LC8 {0.5 0.5 0.5} def +% Default Line Types +/LTw {PL [] 1 setgray} def +/LTb {BL [] LCb DL} def +/LTa {AL [1 udl mul 2 udl mul] 0 setdash LCa setrgbcolor} def +/LT0 {PL [] LC0 DL} def +/LT1 {PL [4 dl1 2 dl2] LC1 DL} def +/LT2 {PL [2 dl1 3 dl2] LC2 DL} def +/LT3 {PL [1 dl1 1.5 dl2] LC3 DL} def +/LT4 {PL [6 dl1 2 dl2 1 dl1 2 dl2] LC4 DL} def +/LT5 {PL [3 dl1 3 dl2 1 dl1 3 dl2] LC5 DL} def +/LT6 {PL [2 dl1 2 dl2 2 dl1 6 dl2] LC6 DL} def +/LT7 {PL [1 dl1 2 dl2 6 dl1 2 dl2 1 dl1 2 dl2] LC7 DL} def +/LT8 {PL [2 dl1 2 dl2 2 dl1 2 dl2 2 dl1 2 dl2 2 dl1 4 dl2] LC8 DL} def +/Pnt {stroke [] 0 setdash gsave 1 setlinecap M 0 0 V stroke grestore} def +/Dia {stroke [] 0 setdash 2 copy vpt add M + hpt neg vpt neg V hpt vpt neg V + hpt vpt V hpt neg vpt V closepath stroke + Pnt} def +/Pls {stroke [] 0 setdash vpt sub M 0 vpt2 V + currentpoint stroke M + hpt neg vpt neg R hpt2 0 V stroke + } def +/Box {stroke [] 0 setdash 2 copy exch hpt sub exch vpt add M + 0 vpt2 neg V hpt2 0 V 0 vpt2 V + hpt2 neg 0 V closepath stroke + Pnt} def +/Crs {stroke [] 0 setdash exch hpt sub exch vpt add M + hpt2 vpt2 neg V currentpoint stroke M + hpt2 neg 0 R hpt2 vpt2 V stroke} def +/TriU {stroke [] 0 setdash 2 copy vpt 1.12 mul add M + hpt neg vpt -1.62 mul V + hpt 2 mul 0 V + hpt neg vpt 1.62 mul V closepath stroke + Pnt} def +/Star {2 copy Pls Crs} def +/BoxF {stroke [] 0 setdash exch hpt sub exch vpt add M + 0 vpt2 neg V hpt2 0 V 0 vpt2 V + hpt2 neg 0 V closepath fill} def +/TriUF {stroke [] 0 setdash vpt 1.12 mul add M + hpt neg vpt -1.62 mul V + hpt 2 mul 0 V + hpt neg vpt 1.62 mul V closepath fill} def +/TriD {stroke [] 0 setdash 2 copy vpt 1.12 mul sub M + hpt neg vpt 1.62 mul V + hpt 2 mul 0 V + hpt neg vpt -1.62 mul V closepath stroke + Pnt} def +/TriDF {stroke [] 0 setdash vpt 1.12 mul sub M + hpt neg vpt 1.62 mul V + hpt 2 mul 0 V + hpt neg vpt -1.62 mul V closepath fill} def +/DiaF {stroke [] 0 setdash vpt add M + hpt neg vpt neg V hpt vpt neg V + hpt vpt V hpt neg vpt V closepath fill} def +/Pent {stroke [] 0 setdash 2 copy gsave + translate 0 hpt M 4 {72 rotate 0 hpt L} repeat + closepath stroke grestore Pnt} def +/PentF {stroke [] 0 setdash gsave + translate 0 hpt M 4 {72 rotate 0 hpt L} repeat + closepath fill grestore} def +/Circle {stroke [] 0 setdash 2 copy + hpt 0 360 arc stroke Pnt} def +/CircleF {stroke [] 0 setdash hpt 0 360 arc fill} def +/C0 {BL [] 0 setdash 2 copy moveto vpt 90 450 arc} bind def +/C1 {BL [] 0 setdash 2 copy moveto + 2 copy vpt 0 90 arc closepath fill + vpt 0 360 arc closepath} bind def +/C2 {BL [] 0 setdash 2 copy moveto + 2 copy vpt 90 180 arc closepath fill + vpt 0 360 arc closepath} bind def +/C3 {BL [] 0 setdash 2 copy moveto + 2 copy vpt 0 180 arc closepath fill + vpt 0 360 arc closepath} bind def +/C4 {BL [] 0 setdash 2 copy moveto + 2 copy vpt 180 270 arc closepath fill + vpt 0 360 arc closepath} bind def +/C5 {BL [] 0 setdash 2 copy moveto + 2 copy vpt 0 90 arc + 2 copy moveto + 2 copy vpt 180 270 arc closepath fill + vpt 0 360 arc} bind def +/C6 {BL [] 0 setdash 2 copy moveto + 2 copy vpt 90 270 arc closepath fill + vpt 0 360 arc closepath} bind def +/C7 {BL [] 0 setdash 2 copy moveto + 2 copy vpt 0 270 arc closepath fill + vpt 0 360 arc closepath} bind def +/C8 {BL [] 0 setdash 2 copy moveto + 2 copy vpt 270 360 arc closepath fill + vpt 0 360 arc closepath} bind def +/C9 {BL [] 0 setdash 2 copy moveto + 2 copy vpt 270 450 arc closepath fill + vpt 0 360 arc closepath} bind def +/C10 {BL [] 0 setdash 2 copy 2 copy moveto vpt 270 360 arc closepath fill + 2 copy moveto + 2 copy vpt 90 180 arc closepath fill + vpt 0 360 arc closepath} bind def +/C11 {BL [] 0 setdash 2 copy moveto + 2 copy vpt 0 180 arc closepath fill + 2 copy moveto + 2 copy vpt 270 360 arc closepath fill + vpt 0 360 arc closepath} bind def +/C12 {BL [] 0 setdash 2 copy moveto + 2 copy vpt 180 360 arc closepath fill + vpt 0 360 arc closepath} bind def +/C13 {BL [] 0 setdash 2 copy moveto + 2 copy vpt 0 90 arc closepath fill + 2 copy moveto + 2 copy vpt 180 360 arc closepath fill + vpt 0 360 arc closepath} bind def +/C14 {BL [] 0 setdash 2 copy moveto + 2 copy vpt 90 360 arc closepath fill + vpt 0 360 arc} bind def +/C15 {BL [] 0 setdash 2 copy vpt 0 360 arc closepath fill + vpt 0 360 arc closepath} bind def +/Rec {newpath 4 2 roll moveto 1 index 0 rlineto 0 exch rlineto + neg 0 rlineto closepath} bind def +/Square {dup Rec} bind def +/Bsquare {vpt sub exch vpt sub exch vpt2 Square} bind def +/S0 {BL [] 0 setdash 2 copy moveto 0 vpt rlineto BL Bsquare} bind def +/S1 {BL [] 0 setdash 2 copy vpt Square fill Bsquare} bind def +/S2 {BL [] 0 setdash 2 copy exch vpt sub exch vpt Square fill Bsquare} bind def +/S3 {BL [] 0 setdash 2 copy exch vpt sub exch vpt2 vpt Rec fill Bsquare} bind def +/S4 {BL [] 0 setdash 2 copy exch vpt sub exch vpt sub vpt Square fill Bsquare} bind def +/S5 {BL [] 0 setdash 2 copy 2 copy vpt Square fill + exch vpt sub exch vpt sub vpt Square fill Bsquare} bind def +/S6 {BL [] 0 setdash 2 copy exch vpt sub exch vpt sub vpt vpt2 Rec fill Bsquare} bind def +/S7 {BL [] 0 setdash 2 copy exch vpt sub exch vpt sub vpt vpt2 Rec fill + 2 copy vpt Square fill Bsquare} bind def +/S8 {BL [] 0 setdash 2 copy vpt sub vpt Square fill Bsquare} bind def +/S9 {BL [] 0 setdash 2 copy vpt sub vpt vpt2 Rec fill Bsquare} bind def +/S10 {BL [] 0 setdash 2 copy vpt sub vpt Square fill 2 copy exch vpt sub exch vpt Square fill + Bsquare} bind def +/S11 {BL [] 0 setdash 2 copy vpt sub vpt Square fill 2 copy exch vpt sub exch vpt2 vpt Rec fill + Bsquare} bind def +/S12 {BL [] 0 setdash 2 copy exch vpt sub exch vpt sub vpt2 vpt Rec fill Bsquare} bind def +/S13 {BL [] 0 setdash 2 copy exch vpt sub exch vpt sub vpt2 vpt Rec fill + 2 copy vpt Square fill Bsquare} bind def +/S14 {BL [] 0 setdash 2 copy exch vpt sub exch vpt sub vpt2 vpt Rec fill + 2 copy exch vpt sub exch vpt Square fill Bsquare} bind def +/S15 {BL [] 0 setdash 2 copy Bsquare fill Bsquare} bind def +/D0 {gsave translate 45 rotate 0 0 S0 stroke grestore} bind def +/D1 {gsave translate 45 rotate 0 0 S1 stroke grestore} bind def +/D2 {gsave translate 45 rotate 0 0 S2 stroke grestore} bind def +/D3 {gsave translate 45 rotate 0 0 S3 stroke grestore} bind def +/D4 {gsave translate 45 rotate 0 0 S4 stroke grestore} bind def +/D5 {gsave translate 45 rotate 0 0 S5 stroke grestore} bind def +/D6 {gsave translate 45 rotate 0 0 S6 stroke grestore} bind def +/D7 {gsave translate 45 rotate 0 0 S7 stroke grestore} bind def +/D8 {gsave translate 45 rotate 0 0 S8 stroke grestore} bind def +/D9 {gsave translate 45 rotate 0 0 S9 stroke grestore} bind def +/D10 {gsave translate 45 rotate 0 0 S10 stroke grestore} bind def +/D11 {gsave translate 45 rotate 0 0 S11 stroke grestore} bind def +/D12 {gsave translate 45 rotate 0 0 S12 stroke grestore} bind def +/D13 {gsave translate 45 rotate 0 0 S13 stroke grestore} bind def +/D14 {gsave translate 45 rotate 0 0 S14 stroke grestore} bind def +/D15 {gsave translate 45 rotate 0 0 S15 stroke grestore} bind def +/DiaE {stroke [] 0 setdash vpt add M + hpt neg vpt neg V hpt vpt neg V + hpt vpt V hpt neg vpt V closepath stroke} def +/BoxE {stroke [] 0 setdash exch hpt sub exch vpt add M + 0 vpt2 neg V hpt2 0 V 0 vpt2 V + hpt2 neg 0 V closepath stroke} def +/TriUE {stroke [] 0 setdash vpt 1.12 mul add M + hpt neg vpt -1.62 mul V + hpt 2 mul 0 V + hpt neg vpt 1.62 mul V closepath stroke} def +/TriDE {stroke [] 0 setdash vpt 1.12 mul sub M + hpt neg vpt 1.62 mul V + hpt 2 mul 0 V + hpt neg vpt -1.62 mul V closepath stroke} def +/PentE {stroke [] 0 setdash gsave + translate 0 hpt M 4 {72 rotate 0 hpt L} repeat + closepath stroke grestore} def +/CircE {stroke [] 0 setdash + hpt 0 360 arc stroke} def +/Opaque {gsave closepath 1 setgray fill grestore 0 setgray closepath} def +/DiaW {stroke [] 0 setdash vpt add M + hpt neg vpt neg V hpt vpt neg V + hpt vpt V hpt neg vpt V Opaque stroke} def +/BoxW {stroke [] 0 setdash exch hpt sub exch vpt add M + 0 vpt2 neg V hpt2 0 V 0 vpt2 V + hpt2 neg 0 V Opaque stroke} def +/TriUW {stroke [] 0 setdash vpt 1.12 mul add M + hpt neg vpt -1.62 mul V + hpt 2 mul 0 V + hpt neg vpt 1.62 mul V Opaque stroke} def +/TriDW {stroke [] 0 setdash vpt 1.12 mul sub M + hpt neg vpt 1.62 mul V + hpt 2 mul 0 V + hpt neg vpt -1.62 mul V Opaque stroke} def +/PentW {stroke [] 0 setdash gsave + translate 0 hpt M 4 {72 rotate 0 hpt L} repeat + Opaque stroke grestore} def +/CircW {stroke [] 0 setdash + hpt 0 360 arc Opaque stroke} def +/BoxFill {gsave Rec 1 setgray fill grestore} def +/Density { + /Fillden exch def + currentrgbcolor + /ColB exch def /ColG exch def /ColR exch def + /ColR ColR Fillden mul Fillden sub 1 add def + /ColG ColG Fillden mul Fillden sub 1 add def + /ColB ColB Fillden mul Fillden sub 1 add def + ColR ColG ColB setrgbcolor} def +/BoxColFill {gsave Rec PolyFill} def +/PolyFill {gsave Density fill grestore grestore} def +/h {rlineto rlineto rlineto gsave closepath fill grestore} bind def +% +% PostScript Level 1 Pattern Fill routine for rectangles +% Usage: x y w h s a XX PatternFill +% x,y = lower left corner of box to be filled +% w,h = width and height of box +% a = angle in degrees between lines and x-axis +% XX = 0/1 for no/yes cross-hatch +% +/PatternFill {gsave /PFa [ 9 2 roll ] def + PFa 0 get PFa 2 get 2 div add PFa 1 get PFa 3 get 2 div add translate + PFa 2 get -2 div PFa 3 get -2 div PFa 2 get PFa 3 get Rec + gsave 1 setgray fill grestore clip + currentlinewidth 0.5 mul setlinewidth + /PFs PFa 2 get dup mul PFa 3 get dup mul add sqrt def + 0 0 M PFa 5 get rotate PFs -2 div dup translate + 0 1 PFs PFa 4 get div 1 add floor cvi + {PFa 4 get mul 0 M 0 PFs V} for + 0 PFa 6 get ne { + 0 1 PFs PFa 4 get div 1 add floor cvi + {PFa 4 get mul 0 2 1 roll M PFs 0 V} for + } if + stroke grestore} def +% +/languagelevel where + {pop languagelevel} {1} ifelse + 2 lt + {/InterpretLevel1 true def} + {/InterpretLevel1 Level1 def} + ifelse +% +% PostScript level 2 pattern fill definitions +% +/Level2PatternFill { +/Tile8x8 {/PaintType 2 /PatternType 1 /TilingType 1 /BBox [0 0 8 8] /XStep 8 /YStep 8} + bind def +/KeepColor {currentrgbcolor [/Pattern /DeviceRGB] setcolorspace} bind def +<< Tile8x8 + /PaintProc {0.5 setlinewidth pop 0 0 M 8 8 L 0 8 M 8 0 L stroke} +>> matrix makepattern +/Pat1 exch def +<< Tile8x8 + /PaintProc {0.5 setlinewidth pop 0 0 M 8 8 L 0 8 M 8 0 L stroke + 0 4 M 4 8 L 8 4 L 4 0 L 0 4 L stroke} +>> matrix makepattern +/Pat2 exch def +<< Tile8x8 + /PaintProc {0.5 setlinewidth pop 0 0 M 0 8 L + 8 8 L 8 0 L 0 0 L fill} +>> matrix makepattern +/Pat3 exch def +<< Tile8x8 + /PaintProc {0.5 setlinewidth pop -4 8 M 8 -4 L + 0 12 M 12 0 L stroke} +>> matrix makepattern +/Pat4 exch def +<< Tile8x8 + /PaintProc {0.5 setlinewidth pop -4 0 M 8 12 L + 0 -4 M 12 8 L stroke} +>> matrix makepattern +/Pat5 exch def +<< Tile8x8 + /PaintProc {0.5 setlinewidth pop -2 8 M 4 -4 L + 0 12 M 8 -4 L 4 12 M 10 0 L stroke} +>> matrix makepattern +/Pat6 exch def +<< Tile8x8 + /PaintProc {0.5 setlinewidth pop -2 0 M 4 12 L + 0 -4 M 8 12 L 4 -4 M 10 8 L stroke} +>> matrix makepattern +/Pat7 exch def +<< Tile8x8 + /PaintProc {0.5 setlinewidth pop 8 -2 M -4 4 L + 12 0 M -4 8 L 12 4 M 0 10 L stroke} +>> matrix makepattern +/Pat8 exch def +<< Tile8x8 + /PaintProc {0.5 setlinewidth pop 0 -2 M 12 4 L + -4 0 M 12 8 L -4 4 M 8 10 L stroke} +>> matrix makepattern +/Pat9 exch def +/Pattern1 {PatternBgnd KeepColor Pat1 setpattern} bind def +/Pattern2 {PatternBgnd KeepColor Pat2 setpattern} bind def +/Pattern3 {PatternBgnd KeepColor Pat3 setpattern} bind def +/Pattern4 {PatternBgnd KeepColor Landscape {Pat5} {Pat4} ifelse setpattern} bind def +/Pattern5 {PatternBgnd KeepColor Landscape {Pat4} {Pat5} ifelse setpattern} bind def +/Pattern6 {PatternBgnd KeepColor Landscape {Pat9} {Pat6} ifelse setpattern} bind def +/Pattern7 {PatternBgnd KeepColor Landscape {Pat8} {Pat7} ifelse setpattern} bind def +} def +% +% +%End of PostScript Level 2 code +% +/PatternBgnd { + TransparentPatterns {} {gsave 1 setgray fill grestore} ifelse +} def +% +% Substitute for Level 2 pattern fill codes with +% grayscale if Level 2 support is not selected. +% +/Level1PatternFill { +/Pattern1 {0.250 Density} bind def +/Pattern2 {0.500 Density} bind def +/Pattern3 {0.750 Density} bind def +/Pattern4 {0.125 Density} bind def +/Pattern5 {0.375 Density} bind def +/Pattern6 {0.625 Density} bind def +/Pattern7 {0.875 Density} bind def +} def +% +% Now test for support of Level 2 code +% +Level1 {Level1PatternFill} {Level2PatternFill} ifelse +% +/Symbol-Oblique /Symbol findfont [1 0 .167 1 0 0] makefont +dup length dict begin {1 index /FID eq {pop pop} {def} ifelse} forall +currentdict end definefont pop +/MFshow { + { dup 5 get 3 ge + { 5 get 3 eq {gsave} {grestore} ifelse } + {dup dup 0 get findfont exch 1 get scalefont setfont + [ currentpoint ] exch dup 2 get 0 exch R dup 5 get 2 ne {dup dup 6 + get exch 4 get {Gshow} {stringwidth pop 0 R} ifelse }if dup 5 get 0 eq + {dup 3 get {2 get neg 0 exch R pop} {pop aload pop M} ifelse} {dup 5 + get 1 eq {dup 2 get exch dup 3 get exch 6 get stringwidth pop -2 div + dup 0 R} {dup 6 get stringwidth pop -2 div 0 R 6 get + show 2 index {aload pop M neg 3 -1 roll neg R pop pop} {pop pop pop + pop aload pop M} ifelse }ifelse }ifelse } + ifelse } + forall} def +/Gswidth {dup type /stringtype eq {stringwidth} {pop (n) stringwidth} ifelse} def +/MFwidth {0 exch { dup 5 get 3 ge { 5 get 3 eq { 0 } { pop } ifelse } + {dup 3 get{dup dup 0 get findfont exch 1 get scalefont setfont + 6 get Gswidth pop add} {pop} ifelse} ifelse} forall} def +/MLshow { currentpoint stroke M + 0 exch R + Blacktext {gsave 0 setgray MFshow grestore} {MFshow} ifelse } bind def +/MRshow { currentpoint stroke M + exch dup MFwidth neg 3 -1 roll R + Blacktext {gsave 0 setgray MFshow grestore} {MFshow} ifelse } bind def +/MCshow { currentpoint stroke M + exch dup MFwidth -2 div 3 -1 roll R + Blacktext {gsave 0 setgray MFshow grestore} {MFshow} ifelse } bind def +/XYsave { [( ) 1 2 true false 3 ()] } bind def +/XYrestore { [( ) 1 2 true false 4 ()] } bind def +end +%%EndProlog +%%Page: 1 1 +gnudict begin +gsave +doclip +50 50 translate +0.100 0.100 scale +90 rotate +0 -5040 translate +0 setgray +newpath +(Helvetica) findfont 140 scalefont setfont +1.000 UL +LTb +686 922 M +63 0 V +stroke +602 922 M +[ [(Helvetica) 140.0 0.0 true true 0 ( 50)] +] -46.7 MRshow +1.000 UL +LTb +686 1405 M +63 0 V +stroke +602 1405 M +[ [(Helvetica) 140.0 0.0 true true 0 ( 100)] +] -46.7 MRshow +1.000 UL +LTb +686 1888 M +63 0 V +stroke +602 1888 M +[ [(Helvetica) 140.0 0.0 true true 0 ( 150)] +] -46.7 MRshow +1.000 UL +LTb +686 2372 M +63 0 V +stroke +602 2372 M +[ [(Helvetica) 140.0 0.0 true true 0 ( 200)] +] -46.7 MRshow +1.000 UL +LTb +686 2855 M +63 0 V +stroke +602 2855 M +[ [(Helvetica) 140.0 0.0 true true 0 ( 250)] +] -46.7 MRshow +1.000 UL +LTb +686 448 M +0 63 V +stroke +686 308 M +[ [(Helvetica) 140.0 0.0 true true 0 ( 0)] +] -46.7 MCshow +1.000 UL +LTb +1109 448 M +0 63 V +stroke +1109 308 M +[ [(Helvetica) 140.0 0.0 true true 0 ( 1000)] +] -46.7 MCshow +1.000 UL +LTb +1531 448 M +0 63 V +stroke +1531 308 M +[ [(Helvetica) 140.0 0.0 true true 0 ( 2000)] +] -46.7 MCshow +1.000 UL +LTb +1954 448 M +0 63 V +stroke +1954 308 M +[ [(Helvetica) 140.0 0.0 true true 0 ( 3000)] +] -46.7 MCshow +1.000 UL +LTb +2377 448 M +0 63 V +stroke +2377 308 M +[ [(Helvetica) 140.0 0.0 true true 0 ( 4000)] +] -46.7 MCshow +1.000 UL +LTb +2799 448 M +0 63 V +stroke +2799 308 M +[ [(Helvetica) 140.0 0.0 true true 0 ( 5000)] +] -46.7 MCshow +1.000 UL +LTb +3222 448 M +0 63 V +stroke +3222 308 M +[ [(Helvetica) 140.0 0.0 true true 0 ( 6000)] +] -46.7 MCshow +1.000 UL +LTb +3644 448 M +0 63 V +stroke +3644 308 M +[ [(Helvetica) 140.0 0.0 true true 0 ( 7000)] +] -46.7 MCshow +1.000 UL +LTb +4067 448 M +0 63 V +stroke +4067 308 M +[ [(Helvetica) 140.0 0.0 true true 0 ( 8000)] +] -46.7 MCshow +1.000 UL +LTb +1.000 UL +LTb +686 2855 M +686 448 L +3381 0 V +0 2407 R +-3381 0 R +stroke +LCb setrgbcolor +112 1651 M +currentpoint gsave translate -270 rotate 0 0 moveto +[ [(Helvetica) 140.0 0.0 true true 0 (Ratio of Total Execution to Total Work)] +] -46.7 MCshow +grestore +LTb +LCb setrgbcolor +2376 98 M +[ [(Helvetica) 140.0 0.0 true true 0 (Cycles in one Task)] +] -46.7 MCshow +LTb +1.000 UP +1.000 UL +LTb +1.000 UL +LTb +770 511 N +0 560 V +1491 0 V +0 -560 V +770 511 L +Z stroke +770 1071 M +1491 0 V +% Begin plot #1 +stroke +4.000 UL +LT0 +LCb setrgbcolor +1694 1001 M +[ [(Helvetica) 140.0 0.0 true true 0 (80 Threads)] +] -46.7 MRshow +LT0 +1778 1001 M +399 0 V +1735 2855 M +662 -919 V +4067 1238 L +% End plot #1 +% Begin plot #2 +stroke +LT1 +LCb setrgbcolor +1694 861 M +[ [(Helvetica) 140.0 0.0 true true 0 (160 Threads)] +] -46.7 MRshow +LT1 +1778 861 M +399 0 V +1748 2855 M +2555 1723 L +4067 1065 L +% End plot #2 +% Begin plot #3 +stroke +LT2 +LCb setrgbcolor +1694 721 M +[ [(Helvetica) 140.0 0.0 true true 0 (320 Threads)] +] -46.7 MRshow +LT2 +1778 721 M +399 0 V +1420 2855 M +170 -542 V +784 -867 V +3986 870 L +% End plot #3 +% Begin plot #4 +stroke +LT3 +LCb setrgbcolor +1694 581 M +[ [(Helvetica) 140.0 0.0 true true 0 (640 Threads)] +] -46.7 MRshow +LT3 +1778 581 M +399 0 V +1802 2855 M +572 -574 V +4007 1207 L +% End plot #4 +stroke +1.000 UL +LTb +686 2855 M +686 448 L +3381 0 V +0 2407 R +-3381 0 R +1.000 UP +stroke +grestore +end +showpage +%%Trailer +%%DocumentFonts: Helvetica +%%Pages: 1 diff -r 9b9a2497757d -r eb146c5c05a8 0__Papers/PRT/PRT__formal_def/figures/plots_exec_vs_task_size/not_used/xoanon_pthreads_80cores_80_160_320_640thds__o30000__perfCtrs.result.eps --- /dev/null Thu Jan 01 00:00:00 1970 +0000 +++ b/0__Papers/PRT/PRT__formal_def/figures/plots_exec_vs_task_size/not_used/xoanon_pthreads_80cores_80_160_320_640thds__o30000__perfCtrs.result.eps Sat Aug 03 19:24:22 2013 -0700 @@ -0,0 +1,695 @@ +%!PS-Adobe-2.0 +%%Title: xoanon_pthreads_80cores_80_160_320_640thds__o30000__perfCtrs.result.eps +%%Creator: gnuplot 4.4 patchlevel 2 +%%CreationDate: Thu Jan 26 18:23:26 2012 +%%DocumentFonts: (atend) +%%BoundingBox: 251 50 554 482 +%%Orientation: Landscape +%%Pages: (atend) +%%EndComments +%%BeginProlog +/gnudict 256 dict def +gnudict begin +% +% The following true/false flags may be edited by hand if desired. +% The unit line width and grayscale image gamma correction may also be changed. +% +/Color true def +/Blacktext false def +/Solid false def +/Dashlength 1 def +/Landscape true def +/Level1 false def +/Rounded false def +/ClipToBoundingBox false def +/TransparentPatterns false def +/gnulinewidth 5.000 def +/userlinewidth gnulinewidth def +/Gamma 1.0 def +% +/vshift -46 def +/dl1 { + 10.0 Dashlength mul mul + Rounded { currentlinewidth 0.75 mul sub dup 0 le { pop 0.01 } if } if +} def +/dl2 { + 10.0 Dashlength mul mul + Rounded { currentlinewidth 0.75 mul add } if +} def +/hpt_ 31.5 def +/vpt_ 31.5 def +/hpt hpt_ def +/vpt vpt_ def +Level1 {} { +/SDict 10 dict def +systemdict /pdfmark known not { + userdict /pdfmark systemdict /cleartomark get put +} if +SDict begin [ + /Title (xoanon_pthreads_80cores_80_160_320_640thds__o30000__perfCtrs.result.eps) + /Subject (gnuplot plot) + /Creator (gnuplot 4.4 patchlevel 2) + /Author (msach) +% /Producer (gnuplot) +% /Keywords () + /CreationDate (Thu Jan 26 18:23:26 2012) + /DOCINFO pdfmark +end +} ifelse +/doclip { + ClipToBoundingBox { + newpath 251 50 moveto 554 50 lineto 554 482 lineto 251 482 lineto closepath + clip + } if +} def +% +% Gnuplot Prolog Version 4.4 (August 2010) +% +%/SuppressPDFMark true def +% +/M {moveto} bind def +/L {lineto} bind def +/R {rmoveto} bind def +/V {rlineto} bind def +/N {newpath moveto} bind def +/Z {closepath} bind def +/C {setrgbcolor} bind def +/f {rlineto fill} bind def +/g {setgray} bind def +/Gshow {show} def % May be redefined later in the file to support UTF-8 +/vpt2 vpt 2 mul def +/hpt2 hpt 2 mul def +/Lshow {currentpoint stroke M 0 vshift R + Blacktext {gsave 0 setgray show grestore} {show} ifelse} def +/Rshow {currentpoint stroke M dup stringwidth pop neg vshift R + Blacktext {gsave 0 setgray show grestore} {show} ifelse} def +/Cshow {currentpoint stroke M dup stringwidth pop -2 div vshift R + Blacktext {gsave 0 setgray show grestore} {show} ifelse} def +/UP {dup vpt_ mul /vpt exch def hpt_ mul /hpt exch def + /hpt2 hpt 2 mul def /vpt2 vpt 2 mul def} def +/DL {Color {setrgbcolor Solid {pop []} if 0 setdash} + {pop pop pop 0 setgray Solid {pop []} if 0 setdash} ifelse} def +/BL {stroke userlinewidth 2 mul setlinewidth + Rounded {1 setlinejoin 1 setlinecap} if} def +/AL {stroke userlinewidth 2 div setlinewidth + Rounded {1 setlinejoin 1 setlinecap} if} def +/UL {dup gnulinewidth mul /userlinewidth exch def + dup 1 lt {pop 1} if 10 mul /udl exch def} def +/PL {stroke userlinewidth setlinewidth + Rounded {1 setlinejoin 1 setlinecap} if} def +3.8 setmiterlimit +% Default Line colors +/LCw {1 1 1} def +/LCb {0 0 0} def +/LCa {0 0 0} def +/LC0 {1 0 0} def +/LC1 {0 1 0} def +/LC2 {0 0 1} def +/LC3 {1 0 1} def +/LC4 {0 1 1} def +/LC5 {1 1 0} def +/LC6 {0 0 0} def +/LC7 {1 0.3 0} def +/LC8 {0.5 0.5 0.5} def +% Default Line Types +/LTw {PL [] 1 setgray} def +/LTb {BL [] LCb DL} def +/LTa {AL [1 udl mul 2 udl mul] 0 setdash LCa setrgbcolor} def +/LT0 {PL [] LC0 DL} def +/LT1 {PL [4 dl1 2 dl2] LC1 DL} def +/LT2 {PL [2 dl1 3 dl2] LC2 DL} def +/LT3 {PL [1 dl1 1.5 dl2] LC3 DL} def +/LT4 {PL [6 dl1 2 dl2 1 dl1 2 dl2] LC4 DL} def +/LT5 {PL [3 dl1 3 dl2 1 dl1 3 dl2] LC5 DL} def +/LT6 {PL [2 dl1 2 dl2 2 dl1 6 dl2] LC6 DL} def +/LT7 {PL [1 dl1 2 dl2 6 dl1 2 dl2 1 dl1 2 dl2] LC7 DL} def +/LT8 {PL [2 dl1 2 dl2 2 dl1 2 dl2 2 dl1 2 dl2 2 dl1 4 dl2] LC8 DL} def +/Pnt {stroke [] 0 setdash gsave 1 setlinecap M 0 0 V stroke grestore} def +/Dia {stroke [] 0 setdash 2 copy vpt add M + hpt neg vpt neg V hpt vpt neg V + hpt vpt V hpt neg vpt V closepath stroke + Pnt} def +/Pls {stroke [] 0 setdash vpt sub M 0 vpt2 V + currentpoint stroke M + hpt neg vpt neg R hpt2 0 V stroke + } def +/Box {stroke [] 0 setdash 2 copy exch hpt sub exch vpt add M + 0 vpt2 neg V hpt2 0 V 0 vpt2 V + hpt2 neg 0 V closepath stroke + Pnt} def +/Crs {stroke [] 0 setdash exch hpt sub exch vpt add M + hpt2 vpt2 neg V currentpoint stroke M + hpt2 neg 0 R hpt2 vpt2 V stroke} def +/TriU {stroke [] 0 setdash 2 copy vpt 1.12 mul add M + hpt neg vpt -1.62 mul V + hpt 2 mul 0 V + hpt neg vpt 1.62 mul V closepath stroke + Pnt} def +/Star {2 copy Pls Crs} def +/BoxF {stroke [] 0 setdash exch hpt sub exch vpt add M + 0 vpt2 neg V hpt2 0 V 0 vpt2 V + hpt2 neg 0 V closepath fill} def +/TriUF {stroke [] 0 setdash vpt 1.12 mul add M + hpt neg vpt -1.62 mul V + hpt 2 mul 0 V + hpt neg vpt 1.62 mul V closepath fill} def +/TriD {stroke [] 0 setdash 2 copy vpt 1.12 mul sub M + hpt neg vpt 1.62 mul V + hpt 2 mul 0 V + hpt neg vpt -1.62 mul V closepath stroke + Pnt} def +/TriDF {stroke [] 0 setdash vpt 1.12 mul sub M + hpt neg vpt 1.62 mul V + hpt 2 mul 0 V + hpt neg vpt -1.62 mul V closepath fill} def +/DiaF {stroke [] 0 setdash vpt add M + hpt neg vpt neg V hpt vpt neg V + hpt vpt V hpt neg vpt V closepath fill} def +/Pent {stroke [] 0 setdash 2 copy gsave + translate 0 hpt M 4 {72 rotate 0 hpt L} repeat + closepath stroke grestore Pnt} def +/PentF {stroke [] 0 setdash gsave + translate 0 hpt M 4 {72 rotate 0 hpt L} repeat + closepath fill grestore} def +/Circle {stroke [] 0 setdash 2 copy + hpt 0 360 arc stroke Pnt} def +/CircleF {stroke [] 0 setdash hpt 0 360 arc fill} def +/C0 {BL [] 0 setdash 2 copy moveto vpt 90 450 arc} bind def +/C1 {BL [] 0 setdash 2 copy moveto + 2 copy vpt 0 90 arc closepath fill + vpt 0 360 arc closepath} bind def +/C2 {BL [] 0 setdash 2 copy moveto + 2 copy vpt 90 180 arc closepath fill + vpt 0 360 arc closepath} bind def +/C3 {BL [] 0 setdash 2 copy moveto + 2 copy vpt 0 180 arc closepath fill + vpt 0 360 arc closepath} bind def +/C4 {BL [] 0 setdash 2 copy moveto + 2 copy vpt 180 270 arc closepath fill + vpt 0 360 arc closepath} bind def +/C5 {BL [] 0 setdash 2 copy moveto + 2 copy vpt 0 90 arc + 2 copy moveto + 2 copy vpt 180 270 arc closepath fill + vpt 0 360 arc} bind def +/C6 {BL [] 0 setdash 2 copy moveto + 2 copy vpt 90 270 arc closepath fill + vpt 0 360 arc closepath} bind def +/C7 {BL [] 0 setdash 2 copy moveto + 2 copy vpt 0 270 arc closepath fill + vpt 0 360 arc closepath} bind def +/C8 {BL [] 0 setdash 2 copy moveto + 2 copy vpt 270 360 arc closepath fill + vpt 0 360 arc closepath} bind def +/C9 {BL [] 0 setdash 2 copy moveto + 2 copy vpt 270 450 arc closepath fill + vpt 0 360 arc closepath} bind def +/C10 {BL [] 0 setdash 2 copy 2 copy moveto vpt 270 360 arc closepath fill + 2 copy moveto + 2 copy vpt 90 180 arc closepath fill + vpt 0 360 arc closepath} bind def +/C11 {BL [] 0 setdash 2 copy moveto + 2 copy vpt 0 180 arc closepath fill + 2 copy moveto + 2 copy vpt 270 360 arc closepath fill + vpt 0 360 arc closepath} bind def +/C12 {BL [] 0 setdash 2 copy moveto + 2 copy vpt 180 360 arc closepath fill + vpt 0 360 arc closepath} bind def +/C13 {BL [] 0 setdash 2 copy moveto + 2 copy vpt 0 90 arc closepath fill + 2 copy moveto + 2 copy vpt 180 360 arc closepath fill + vpt 0 360 arc closepath} bind def +/C14 {BL [] 0 setdash 2 copy moveto + 2 copy vpt 90 360 arc closepath fill + vpt 0 360 arc} bind def +/C15 {BL [] 0 setdash 2 copy vpt 0 360 arc closepath fill + vpt 0 360 arc closepath} bind def +/Rec {newpath 4 2 roll moveto 1 index 0 rlineto 0 exch rlineto + neg 0 rlineto closepath} bind def +/Square {dup Rec} bind def +/Bsquare {vpt sub exch vpt sub exch vpt2 Square} bind def +/S0 {BL [] 0 setdash 2 copy moveto 0 vpt rlineto BL Bsquare} bind def +/S1 {BL [] 0 setdash 2 copy vpt Square fill Bsquare} bind def +/S2 {BL [] 0 setdash 2 copy exch vpt sub exch vpt Square fill Bsquare} bind def +/S3 {BL [] 0 setdash 2 copy exch vpt sub exch vpt2 vpt Rec fill Bsquare} bind def +/S4 {BL [] 0 setdash 2 copy exch vpt sub exch vpt sub vpt Square fill Bsquare} bind def +/S5 {BL [] 0 setdash 2 copy 2 copy vpt Square fill + exch vpt sub exch vpt sub vpt Square fill Bsquare} bind def +/S6 {BL [] 0 setdash 2 copy exch vpt sub exch vpt sub vpt vpt2 Rec fill Bsquare} bind def +/S7 {BL [] 0 setdash 2 copy exch vpt sub exch vpt sub vpt vpt2 Rec fill + 2 copy vpt Square fill Bsquare} bind def +/S8 {BL [] 0 setdash 2 copy vpt sub vpt Square fill Bsquare} bind def +/S9 {BL [] 0 setdash 2 copy vpt sub vpt vpt2 Rec fill Bsquare} bind def +/S10 {BL [] 0 setdash 2 copy vpt sub vpt Square fill 2 copy exch vpt sub exch vpt Square fill + Bsquare} bind def +/S11 {BL [] 0 setdash 2 copy vpt sub vpt Square fill 2 copy exch vpt sub exch vpt2 vpt Rec fill + Bsquare} bind def +/S12 {BL [] 0 setdash 2 copy exch vpt sub exch vpt sub vpt2 vpt Rec fill Bsquare} bind def +/S13 {BL [] 0 setdash 2 copy exch vpt sub exch vpt sub vpt2 vpt Rec fill + 2 copy vpt Square fill Bsquare} bind def +/S14 {BL [] 0 setdash 2 copy exch vpt sub exch vpt sub vpt2 vpt Rec fill + 2 copy exch vpt sub exch vpt Square fill Bsquare} bind def +/S15 {BL [] 0 setdash 2 copy Bsquare fill Bsquare} bind def +/D0 {gsave translate 45 rotate 0 0 S0 stroke grestore} bind def +/D1 {gsave translate 45 rotate 0 0 S1 stroke grestore} bind def +/D2 {gsave translate 45 rotate 0 0 S2 stroke grestore} bind def +/D3 {gsave translate 45 rotate 0 0 S3 stroke grestore} bind def +/D4 {gsave translate 45 rotate 0 0 S4 stroke grestore} bind def +/D5 {gsave translate 45 rotate 0 0 S5 stroke grestore} bind def +/D6 {gsave translate 45 rotate 0 0 S6 stroke grestore} bind def +/D7 {gsave translate 45 rotate 0 0 S7 stroke grestore} bind def +/D8 {gsave translate 45 rotate 0 0 S8 stroke grestore} bind def +/D9 {gsave translate 45 rotate 0 0 S9 stroke grestore} bind def +/D10 {gsave translate 45 rotate 0 0 S10 stroke grestore} bind def +/D11 {gsave translate 45 rotate 0 0 S11 stroke grestore} bind def +/D12 {gsave translate 45 rotate 0 0 S12 stroke grestore} bind def +/D13 {gsave translate 45 rotate 0 0 S13 stroke grestore} bind def +/D14 {gsave translate 45 rotate 0 0 S14 stroke grestore} bind def +/D15 {gsave translate 45 rotate 0 0 S15 stroke grestore} bind def +/DiaE {stroke [] 0 setdash vpt add M + hpt neg vpt neg V hpt vpt neg V + hpt vpt V hpt neg vpt V closepath stroke} def +/BoxE {stroke [] 0 setdash exch hpt sub exch vpt add M + 0 vpt2 neg V hpt2 0 V 0 vpt2 V + hpt2 neg 0 V closepath stroke} def +/TriUE {stroke [] 0 setdash vpt 1.12 mul add M + hpt neg vpt -1.62 mul V + hpt 2 mul 0 V + hpt neg vpt 1.62 mul V closepath stroke} def +/TriDE {stroke [] 0 setdash vpt 1.12 mul sub M + hpt neg vpt 1.62 mul V + hpt 2 mul 0 V + hpt neg vpt -1.62 mul V closepath stroke} def +/PentE {stroke [] 0 setdash gsave + translate 0 hpt M 4 {72 rotate 0 hpt L} repeat + closepath stroke grestore} def +/CircE {stroke [] 0 setdash + hpt 0 360 arc stroke} def +/Opaque {gsave closepath 1 setgray fill grestore 0 setgray closepath} def +/DiaW {stroke [] 0 setdash vpt add M + hpt neg vpt neg V hpt vpt neg V + hpt vpt V hpt neg vpt V Opaque stroke} def +/BoxW {stroke [] 0 setdash exch hpt sub exch vpt add M + 0 vpt2 neg V hpt2 0 V 0 vpt2 V + hpt2 neg 0 V Opaque stroke} def +/TriUW {stroke [] 0 setdash vpt 1.12 mul add M + hpt neg vpt -1.62 mul V + hpt 2 mul 0 V + hpt neg vpt 1.62 mul V Opaque stroke} def +/TriDW {stroke [] 0 setdash vpt 1.12 mul sub M + hpt neg vpt 1.62 mul V + hpt 2 mul 0 V + hpt neg vpt -1.62 mul V Opaque stroke} def +/PentW {stroke [] 0 setdash gsave + translate 0 hpt M 4 {72 rotate 0 hpt L} repeat + Opaque stroke grestore} def +/CircW {stroke [] 0 setdash + hpt 0 360 arc Opaque stroke} def +/BoxFill {gsave Rec 1 setgray fill grestore} def +/Density { + /Fillden exch def + currentrgbcolor + /ColB exch def /ColG exch def /ColR exch def + /ColR ColR Fillden mul Fillden sub 1 add def + /ColG ColG Fillden mul Fillden sub 1 add def + /ColB ColB Fillden mul Fillden sub 1 add def + ColR ColG ColB setrgbcolor} def +/BoxColFill {gsave Rec PolyFill} def +/PolyFill {gsave Density fill grestore grestore} def +/h {rlineto rlineto rlineto gsave closepath fill grestore} bind def +% +% PostScript Level 1 Pattern Fill routine for rectangles +% Usage: x y w h s a XX PatternFill +% x,y = lower left corner of box to be filled +% w,h = width and height of box +% a = angle in degrees between lines and x-axis +% XX = 0/1 for no/yes cross-hatch +% +/PatternFill {gsave /PFa [ 9 2 roll ] def + PFa 0 get PFa 2 get 2 div add PFa 1 get PFa 3 get 2 div add translate + PFa 2 get -2 div PFa 3 get -2 div PFa 2 get PFa 3 get Rec + gsave 1 setgray fill grestore clip + currentlinewidth 0.5 mul setlinewidth + /PFs PFa 2 get dup mul PFa 3 get dup mul add sqrt def + 0 0 M PFa 5 get rotate PFs -2 div dup translate + 0 1 PFs PFa 4 get div 1 add floor cvi + {PFa 4 get mul 0 M 0 PFs V} for + 0 PFa 6 get ne { + 0 1 PFs PFa 4 get div 1 add floor cvi + {PFa 4 get mul 0 2 1 roll M PFs 0 V} for + } if + stroke grestore} def +% +/languagelevel where + {pop languagelevel} {1} ifelse + 2 lt + {/InterpretLevel1 true def} + {/InterpretLevel1 Level1 def} + ifelse +% +% PostScript level 2 pattern fill definitions +% +/Level2PatternFill { +/Tile8x8 {/PaintType 2 /PatternType 1 /TilingType 1 /BBox [0 0 8 8] /XStep 8 /YStep 8} + bind def +/KeepColor {currentrgbcolor [/Pattern /DeviceRGB] setcolorspace} bind def +<< Tile8x8 + /PaintProc {0.5 setlinewidth pop 0 0 M 8 8 L 0 8 M 8 0 L stroke} +>> matrix makepattern +/Pat1 exch def +<< Tile8x8 + /PaintProc {0.5 setlinewidth pop 0 0 M 8 8 L 0 8 M 8 0 L stroke + 0 4 M 4 8 L 8 4 L 4 0 L 0 4 L stroke} +>> matrix makepattern +/Pat2 exch def +<< Tile8x8 + /PaintProc {0.5 setlinewidth pop 0 0 M 0 8 L + 8 8 L 8 0 L 0 0 L fill} +>> matrix makepattern +/Pat3 exch def +<< Tile8x8 + /PaintProc {0.5 setlinewidth pop -4 8 M 8 -4 L + 0 12 M 12 0 L stroke} +>> matrix makepattern +/Pat4 exch def +<< Tile8x8 + /PaintProc {0.5 setlinewidth pop -4 0 M 8 12 L + 0 -4 M 12 8 L stroke} +>> matrix makepattern +/Pat5 exch def +<< Tile8x8 + /PaintProc {0.5 setlinewidth pop -2 8 M 4 -4 L + 0 12 M 8 -4 L 4 12 M 10 0 L stroke} +>> matrix makepattern +/Pat6 exch def +<< Tile8x8 + /PaintProc {0.5 setlinewidth pop -2 0 M 4 12 L + 0 -4 M 8 12 L 4 -4 M 10 8 L stroke} +>> matrix makepattern +/Pat7 exch def +<< Tile8x8 + /PaintProc {0.5 setlinewidth pop 8 -2 M -4 4 L + 12 0 M -4 8 L 12 4 M 0 10 L stroke} +>> matrix makepattern +/Pat8 exch def +<< Tile8x8 + /PaintProc {0.5 setlinewidth pop 0 -2 M 12 4 L + -4 0 M 12 8 L -4 4 M 8 10 L stroke} +>> matrix makepattern +/Pat9 exch def +/Pattern1 {PatternBgnd KeepColor Pat1 setpattern} bind def +/Pattern2 {PatternBgnd KeepColor Pat2 setpattern} bind def +/Pattern3 {PatternBgnd KeepColor Pat3 setpattern} bind def +/Pattern4 {PatternBgnd KeepColor Landscape {Pat5} {Pat4} ifelse setpattern} bind def +/Pattern5 {PatternBgnd KeepColor Landscape {Pat4} {Pat5} ifelse setpattern} bind def +/Pattern6 {PatternBgnd KeepColor Landscape {Pat9} {Pat6} ifelse setpattern} bind def +/Pattern7 {PatternBgnd KeepColor Landscape {Pat8} {Pat7} ifelse setpattern} bind def +} def +% +% +%End of PostScript Level 2 code +% +/PatternBgnd { + TransparentPatterns {} {gsave 1 setgray fill grestore} ifelse +} def +% +% Substitute for Level 2 pattern fill codes with +% grayscale if Level 2 support is not selected. +% +/Level1PatternFill { +/Pattern1 {0.250 Density} bind def +/Pattern2 {0.500 Density} bind def +/Pattern3 {0.750 Density} bind def +/Pattern4 {0.125 Density} bind def +/Pattern5 {0.375 Density} bind def +/Pattern6 {0.625 Density} bind def +/Pattern7 {0.875 Density} bind def +} def +% +% Now test for support of Level 2 code +% +Level1 {Level1PatternFill} {Level2PatternFill} ifelse +% +/Symbol-Oblique /Symbol findfont [1 0 .167 1 0 0] makefont +dup length dict begin {1 index /FID eq {pop pop} {def} ifelse} forall +currentdict end definefont pop +/MFshow { + { dup 5 get 3 ge + { 5 get 3 eq {gsave} {grestore} ifelse } + {dup dup 0 get findfont exch 1 get scalefont setfont + [ currentpoint ] exch dup 2 get 0 exch R dup 5 get 2 ne {dup dup 6 + get exch 4 get {Gshow} {stringwidth pop 0 R} ifelse }if dup 5 get 0 eq + {dup 3 get {2 get neg 0 exch R pop} {pop aload pop M} ifelse} {dup 5 + get 1 eq {dup 2 get exch dup 3 get exch 6 get stringwidth pop -2 div + dup 0 R} {dup 6 get stringwidth pop -2 div 0 R 6 get + show 2 index {aload pop M neg 3 -1 roll neg R pop pop} {pop pop pop + pop aload pop M} ifelse }ifelse }ifelse } + ifelse } + forall} def +/Gswidth {dup type /stringtype eq {stringwidth} {pop (n) stringwidth} ifelse} def +/MFwidth {0 exch { dup 5 get 3 ge { 5 get 3 eq { 0 } { pop } ifelse } + {dup 3 get{dup dup 0 get findfont exch 1 get scalefont setfont + 6 get Gswidth pop add} {pop} ifelse} ifelse} forall} def +/MLshow { currentpoint stroke M + 0 exch R + Blacktext {gsave 0 setgray MFshow grestore} {MFshow} ifelse } bind def +/MRshow { currentpoint stroke M + exch dup MFwidth neg 3 -1 roll R + Blacktext {gsave 0 setgray MFshow grestore} {MFshow} ifelse } bind def +/MCshow { currentpoint stroke M + exch dup MFwidth -2 div 3 -1 roll R + Blacktext {gsave 0 setgray MFshow grestore} {MFshow} ifelse } bind def +/XYsave { [( ) 1 2 true false 3 ()] } bind def +/XYrestore { [( ) 1 2 true false 4 ()] } bind def +end +%%EndProlog +%%Page: 1 1 +gnudict begin +gsave +doclip +50 50 translate +0.100 0.100 scale +90 rotate +0 -5040 translate +0 setgray +newpath +(Helvetica) findfont 140 scalefont setfont +1.000 UL +LTb +686 922 M +63 0 V +stroke +602 922 M +[ [(Helvetica) 140.0 0.0 true true 0 ( 50)] +] -46.7 MRshow +1.000 UL +LTb +686 1405 M +63 0 V +stroke +602 1405 M +[ [(Helvetica) 140.0 0.0 true true 0 ( 100)] +] -46.7 MRshow +1.000 UL +LTb +686 1888 M +63 0 V +stroke +602 1888 M +[ [(Helvetica) 140.0 0.0 true true 0 ( 150)] +] -46.7 MRshow +1.000 UL +LTb +686 2372 M +63 0 V +stroke +602 2372 M +[ [(Helvetica) 140.0 0.0 true true 0 ( 200)] +] -46.7 MRshow +1.000 UL +LTb +686 2855 M +63 0 V +stroke +602 2855 M +[ [(Helvetica) 140.0 0.0 true true 0 ( 250)] +] -46.7 MRshow +1.000 UL +LTb +686 448 M +0 63 V +stroke +686 308 M +[ [(Helvetica) 140.0 0.0 true true 0 ( 0)] +] -46.7 MCshow +1.000 UL +LTb +1109 448 M +0 63 V +stroke +1109 308 M +[ [(Helvetica) 140.0 0.0 true true 0 ( 1000)] +] -46.7 MCshow +1.000 UL +LTb +1531 448 M +0 63 V +stroke +1531 308 M +[ [(Helvetica) 140.0 0.0 true true 0 ( 2000)] +] -46.7 MCshow +1.000 UL +LTb +1954 448 M +0 63 V +stroke +1954 308 M +[ [(Helvetica) 140.0 0.0 true true 0 ( 3000)] +] -46.7 MCshow +1.000 UL +LTb +2377 448 M +0 63 V +stroke +2377 308 M +[ [(Helvetica) 140.0 0.0 true true 0 ( 4000)] +] -46.7 MCshow +1.000 UL +LTb +2799 448 M +0 63 V +stroke +2799 308 M +[ [(Helvetica) 140.0 0.0 true true 0 ( 5000)] +] -46.7 MCshow +1.000 UL +LTb +3222 448 M +0 63 V +stroke +3222 308 M +[ [(Helvetica) 140.0 0.0 true true 0 ( 6000)] +] -46.7 MCshow +1.000 UL +LTb +3644 448 M +0 63 V +stroke +3644 308 M +[ [(Helvetica) 140.0 0.0 true true 0 ( 7000)] +] -46.7 MCshow +1.000 UL +LTb +4067 448 M +0 63 V +stroke +4067 308 M +[ [(Helvetica) 140.0 0.0 true true 0 ( 8000)] +] -46.7 MCshow +1.000 UL +LTb +1.000 UL +LTb +686 2855 M +686 448 L +3381 0 V +0 2407 R +-3381 0 R +stroke +LCb setrgbcolor +112 1651 M +currentpoint gsave translate -270 rotate 0 0 moveto +[ [(Helvetica) 140.0 0.0 true true 0 (Ratio of Total Execution to Total Work)] +] -46.7 MCshow +grestore +LTb +LCb setrgbcolor +2376 98 M +[ [(Helvetica) 140.0 0.0 true true 0 (Cycles in one Task)] +] -46.7 MCshow +LTb +1.000 UP +1.000 UL +LTb +1.000 UL +LTb +770 511 N +0 560 V +1491 0 V +0 -560 V +770 511 L +Z stroke +770 1071 M +1491 0 V +% Begin plot #1 +stroke +4.000 UL +LT0 +LCb setrgbcolor +1694 1001 M +[ [(Helvetica) 140.0 0.0 true true 0 (80 Threads)] +] -46.7 MRshow +LT0 +1778 1001 M +399 0 V +154 1854 R +25 -124 V +3985 1744 L +% End plot #1 +% Begin plot #2 +stroke +LT1 +LCb setrgbcolor +1694 861 M +[ [(Helvetica) 140.0 0.0 true true 0 (160 Threads)] +] -46.7 MRshow +LT1 +1778 861 M +399 0 V +% End plot #2 +% Begin plot #3 +stroke +LT2 +LCb setrgbcolor +1694 721 M +[ [(Helvetica) 140.0 0.0 true true 0 (320 Threads)] +] -46.7 MRshow +LT2 +1778 721 M +399 0 V +618 2134 R +476 -856 V +796 -271 V +% End plot #3 +% Begin plot #4 +stroke +LT3 +LCb setrgbcolor +1694 581 M +[ [(Helvetica) 140.0 0.0 true true 0 (640 Threads)] +] -46.7 MRshow +LT3 +1778 581 M +399 0 V +166 2274 R +586 -716 V +4067 1495 L +% End plot #4 +stroke +1.000 UL +LTb +686 2855 M +686 448 L +3381 0 V +0 2407 R +-3381 0 R +1.000 UP +stroke +grestore +end +showpage +%%Trailer +%%DocumentFonts: Helvetica +%%Pages: 1 diff -r 9b9a2497757d -r eb146c5c05a8 0__Papers/PRT/PRT__formal_def/figures/plots_exec_vs_task_size/not_used/xoanon_pthreads_vthread_40core_80_160_320_640thds__o30000__perfCtrs.meas.key-out.eps --- /dev/null Thu Jan 01 00:00:00 1970 +0000 +++ b/0__Papers/PRT/PRT__formal_def/figures/plots_exec_vs_task_size/not_used/xoanon_pthreads_vthread_40core_80_160_320_640thds__o30000__perfCtrs.meas.key-out.eps Sat Aug 03 19:24:22 2013 -0700 @@ -0,0 +1,884 @@ +%!PS-Adobe-2.0 +%%Title: xoanon_pthreads_vthread_40core_80_160_320_640thds__o30000__perfCtrs.meas.key-out.eps +%%Creator: gnuplot 4.4 patchlevel 2 +%%CreationDate: Thu Jan 26 18:45:12 2012 +%%DocumentFonts: (atend) +%%BoundingBox: 251 50 554 482 +%%Orientation: Landscape +%%Pages: (atend) +%%EndComments +%%BeginProlog +/gnudict 256 dict def +gnudict begin +% +% The following true/false flags may be edited by hand if desired. +% The unit line width and grayscale image gamma correction may also be changed. +% +/Color true def +/Blacktext false def +/Solid false def +/Dashlength 1 def +/Landscape true def +/Level1 false def +/Rounded false def +/ClipToBoundingBox false def +/TransparentPatterns false def +/gnulinewidth 5.000 def +/userlinewidth gnulinewidth def +/Gamma 1.0 def +% +/vshift -46 def +/dl1 { + 10.0 Dashlength mul mul + Rounded { currentlinewidth 0.75 mul sub dup 0 le { pop 0.01 } if } if +} def +/dl2 { + 10.0 Dashlength mul mul + Rounded { currentlinewidth 0.75 mul add } if +} def +/hpt_ 31.5 def +/vpt_ 31.5 def +/hpt hpt_ def +/vpt vpt_ def +Level1 {} { +/SDict 10 dict def +systemdict /pdfmark known not { + userdict /pdfmark systemdict /cleartomark get put +} if +SDict begin [ + /Title (xoanon_pthreads_vthread_40core_80_160_320_640thds__o30000__perfCtrs.meas.key-out.eps) + /Subject (gnuplot plot) + /Creator (gnuplot 4.4 patchlevel 2) + /Author (msach) +% /Producer (gnuplot) +% /Keywords () + /CreationDate (Thu Jan 26 18:45:12 2012) + /DOCINFO pdfmark +end +} ifelse +/doclip { + ClipToBoundingBox { + newpath 251 50 moveto 554 50 lineto 554 482 lineto 251 482 lineto closepath + clip + } if +} def +% +% Gnuplot Prolog Version 4.4 (August 2010) +% +%/SuppressPDFMark true def +% +/M {moveto} bind def +/L {lineto} bind def +/R {rmoveto} bind def +/V {rlineto} bind def +/N {newpath moveto} bind def +/Z {closepath} bind def +/C {setrgbcolor} bind def +/f {rlineto fill} bind def +/g {setgray} bind def +/Gshow {show} def % May be redefined later in the file to support UTF-8 +/vpt2 vpt 2 mul def +/hpt2 hpt 2 mul def +/Lshow {currentpoint stroke M 0 vshift R + Blacktext {gsave 0 setgray show grestore} {show} ifelse} def +/Rshow {currentpoint stroke M dup stringwidth pop neg vshift R + Blacktext {gsave 0 setgray show grestore} {show} ifelse} def +/Cshow {currentpoint stroke M dup stringwidth pop -2 div vshift R + Blacktext {gsave 0 setgray show grestore} {show} ifelse} def +/UP {dup vpt_ mul /vpt exch def hpt_ mul /hpt exch def + /hpt2 hpt 2 mul def /vpt2 vpt 2 mul def} def +/DL {Color {setrgbcolor Solid {pop []} if 0 setdash} + {pop pop pop 0 setgray Solid {pop []} if 0 setdash} ifelse} def +/BL {stroke userlinewidth 2 mul setlinewidth + Rounded {1 setlinejoin 1 setlinecap} if} def +/AL {stroke userlinewidth 2 div setlinewidth + Rounded {1 setlinejoin 1 setlinecap} if} def +/UL {dup gnulinewidth mul /userlinewidth exch def + dup 1 lt {pop 1} if 10 mul /udl exch def} def +/PL {stroke userlinewidth setlinewidth + Rounded {1 setlinejoin 1 setlinecap} if} def +3.8 setmiterlimit +% Default Line colors +/LCw {1 1 1} def +/LCb {0 0 0} def +/LCa {0 0 0} def +/LC0 {1 0 0} def +/LC1 {0 1 0} def +/LC2 {0 0 1} def +/LC3 {1 0 1} def +/LC4 {0 1 1} def +/LC5 {1 1 0} def +/LC6 {0 0 0} def +/LC7 {1 0.3 0} def +/LC8 {0.5 0.5 0.5} def +% Default Line Types +/LTw {PL [] 1 setgray} def +/LTb {BL [] LCb DL} def +/LTa {AL [1 udl mul 2 udl mul] 0 setdash LCa setrgbcolor} def +/LT0 {PL [] LC0 DL} def +/LT1 {PL [4 dl1 2 dl2] LC1 DL} def +/LT2 {PL [2 dl1 3 dl2] LC2 DL} def +/LT3 {PL [1 dl1 1.5 dl2] LC3 DL} def +/LT4 {PL [6 dl1 2 dl2 1 dl1 2 dl2] LC4 DL} def +/LT5 {PL [3 dl1 3 dl2 1 dl1 3 dl2] LC5 DL} def +/LT6 {PL [2 dl1 2 dl2 2 dl1 6 dl2] LC6 DL} def +/LT7 {PL [1 dl1 2 dl2 6 dl1 2 dl2 1 dl1 2 dl2] LC7 DL} def +/LT8 {PL [2 dl1 2 dl2 2 dl1 2 dl2 2 dl1 2 dl2 2 dl1 4 dl2] LC8 DL} def +/Pnt {stroke [] 0 setdash gsave 1 setlinecap M 0 0 V stroke grestore} def +/Dia {stroke [] 0 setdash 2 copy vpt add M + hpt neg vpt neg V hpt vpt neg V + hpt vpt V hpt neg vpt V closepath stroke + Pnt} def +/Pls {stroke [] 0 setdash vpt sub M 0 vpt2 V + currentpoint stroke M + hpt neg vpt neg R hpt2 0 V stroke + } def +/Box {stroke [] 0 setdash 2 copy exch hpt sub exch vpt add M + 0 vpt2 neg V hpt2 0 V 0 vpt2 V + hpt2 neg 0 V closepath stroke + Pnt} def +/Crs {stroke [] 0 setdash exch hpt sub exch vpt add M + hpt2 vpt2 neg V currentpoint stroke M + hpt2 neg 0 R hpt2 vpt2 V stroke} def +/TriU {stroke [] 0 setdash 2 copy vpt 1.12 mul add M + hpt neg vpt -1.62 mul V + hpt 2 mul 0 V + hpt neg vpt 1.62 mul V closepath stroke + Pnt} def +/Star {2 copy Pls Crs} def +/BoxF {stroke [] 0 setdash exch hpt sub exch vpt add M + 0 vpt2 neg V hpt2 0 V 0 vpt2 V + hpt2 neg 0 V closepath fill} def +/TriUF {stroke [] 0 setdash vpt 1.12 mul add M + hpt neg vpt -1.62 mul V + hpt 2 mul 0 V + hpt neg vpt 1.62 mul V closepath fill} def +/TriD {stroke [] 0 setdash 2 copy vpt 1.12 mul sub M + hpt neg vpt 1.62 mul V + hpt 2 mul 0 V + hpt neg vpt -1.62 mul V closepath stroke + Pnt} def +/TriDF {stroke [] 0 setdash vpt 1.12 mul sub M + hpt neg vpt 1.62 mul V + hpt 2 mul 0 V + hpt neg vpt -1.62 mul V closepath fill} def +/DiaF {stroke [] 0 setdash vpt add M + hpt neg vpt neg V hpt vpt neg V + hpt vpt V hpt neg vpt V closepath fill} def +/Pent {stroke [] 0 setdash 2 copy gsave + translate 0 hpt M 4 {72 rotate 0 hpt L} repeat + closepath stroke grestore Pnt} def +/PentF {stroke [] 0 setdash gsave + translate 0 hpt M 4 {72 rotate 0 hpt L} repeat + closepath fill grestore} def +/Circle {stroke [] 0 setdash 2 copy + hpt 0 360 arc stroke Pnt} def +/CircleF {stroke [] 0 setdash hpt 0 360 arc fill} def +/C0 {BL [] 0 setdash 2 copy moveto vpt 90 450 arc} bind def +/C1 {BL [] 0 setdash 2 copy moveto + 2 copy vpt 0 90 arc closepath fill + vpt 0 360 arc closepath} bind def +/C2 {BL [] 0 setdash 2 copy moveto + 2 copy vpt 90 180 arc closepath fill + vpt 0 360 arc closepath} bind def +/C3 {BL [] 0 setdash 2 copy moveto + 2 copy vpt 0 180 arc closepath fill + vpt 0 360 arc closepath} bind def +/C4 {BL [] 0 setdash 2 copy moveto + 2 copy vpt 180 270 arc closepath fill + vpt 0 360 arc closepath} bind def +/C5 {BL [] 0 setdash 2 copy moveto + 2 copy vpt 0 90 arc + 2 copy moveto + 2 copy vpt 180 270 arc closepath fill + vpt 0 360 arc} bind def +/C6 {BL [] 0 setdash 2 copy moveto + 2 copy vpt 90 270 arc closepath fill + vpt 0 360 arc closepath} bind def +/C7 {BL [] 0 setdash 2 copy moveto + 2 copy vpt 0 270 arc closepath fill + vpt 0 360 arc closepath} bind def +/C8 {BL [] 0 setdash 2 copy moveto + 2 copy vpt 270 360 arc closepath fill + vpt 0 360 arc closepath} bind def +/C9 {BL [] 0 setdash 2 copy moveto + 2 copy vpt 270 450 arc closepath fill + vpt 0 360 arc closepath} bind def +/C10 {BL [] 0 setdash 2 copy 2 copy moveto vpt 270 360 arc closepath fill + 2 copy moveto + 2 copy vpt 90 180 arc closepath fill + vpt 0 360 arc closepath} bind def +/C11 {BL [] 0 setdash 2 copy moveto + 2 copy vpt 0 180 arc closepath fill + 2 copy moveto + 2 copy vpt 270 360 arc closepath fill + vpt 0 360 arc closepath} bind def +/C12 {BL [] 0 setdash 2 copy moveto + 2 copy vpt 180 360 arc closepath fill + vpt 0 360 arc closepath} bind def +/C13 {BL [] 0 setdash 2 copy moveto + 2 copy vpt 0 90 arc closepath fill + 2 copy moveto + 2 copy vpt 180 360 arc closepath fill + vpt 0 360 arc closepath} bind def +/C14 {BL [] 0 setdash 2 copy moveto + 2 copy vpt 90 360 arc closepath fill + vpt 0 360 arc} bind def +/C15 {BL [] 0 setdash 2 copy vpt 0 360 arc closepath fill + vpt 0 360 arc closepath} bind def +/Rec {newpath 4 2 roll moveto 1 index 0 rlineto 0 exch rlineto + neg 0 rlineto closepath} bind def +/Square {dup Rec} bind def +/Bsquare {vpt sub exch vpt sub exch vpt2 Square} bind def +/S0 {BL [] 0 setdash 2 copy moveto 0 vpt rlineto BL Bsquare} bind def +/S1 {BL [] 0 setdash 2 copy vpt Square fill Bsquare} bind def +/S2 {BL [] 0 setdash 2 copy exch vpt sub exch vpt Square fill Bsquare} bind def +/S3 {BL [] 0 setdash 2 copy exch vpt sub exch vpt2 vpt Rec fill Bsquare} bind def +/S4 {BL [] 0 setdash 2 copy exch vpt sub exch vpt sub vpt Square fill Bsquare} bind def +/S5 {BL [] 0 setdash 2 copy 2 copy vpt Square fill + exch vpt sub exch vpt sub vpt Square fill Bsquare} bind def +/S6 {BL [] 0 setdash 2 copy exch vpt sub exch vpt sub vpt vpt2 Rec fill Bsquare} bind def +/S7 {BL [] 0 setdash 2 copy exch vpt sub exch vpt sub vpt vpt2 Rec fill + 2 copy vpt Square fill Bsquare} bind def +/S8 {BL [] 0 setdash 2 copy vpt sub vpt Square fill Bsquare} bind def +/S9 {BL [] 0 setdash 2 copy vpt sub vpt vpt2 Rec fill Bsquare} bind def +/S10 {BL [] 0 setdash 2 copy vpt sub vpt Square fill 2 copy exch vpt sub exch vpt Square fill + Bsquare} bind def +/S11 {BL [] 0 setdash 2 copy vpt sub vpt Square fill 2 copy exch vpt sub exch vpt2 vpt Rec fill + Bsquare} bind def +/S12 {BL [] 0 setdash 2 copy exch vpt sub exch vpt sub vpt2 vpt Rec fill Bsquare} bind def +/S13 {BL [] 0 setdash 2 copy exch vpt sub exch vpt sub vpt2 vpt Rec fill + 2 copy vpt Square fill Bsquare} bind def +/S14 {BL [] 0 setdash 2 copy exch vpt sub exch vpt sub vpt2 vpt Rec fill + 2 copy exch vpt sub exch vpt Square fill Bsquare} bind def +/S15 {BL [] 0 setdash 2 copy Bsquare fill Bsquare} bind def +/D0 {gsave translate 45 rotate 0 0 S0 stroke grestore} bind def +/D1 {gsave translate 45 rotate 0 0 S1 stroke grestore} bind def +/D2 {gsave translate 45 rotate 0 0 S2 stroke grestore} bind def +/D3 {gsave translate 45 rotate 0 0 S3 stroke grestore} bind def +/D4 {gsave translate 45 rotate 0 0 S4 stroke grestore} bind def +/D5 {gsave translate 45 rotate 0 0 S5 stroke grestore} bind def +/D6 {gsave translate 45 rotate 0 0 S6 stroke grestore} bind def +/D7 {gsave translate 45 rotate 0 0 S7 stroke grestore} bind def +/D8 {gsave translate 45 rotate 0 0 S8 stroke grestore} bind def +/D9 {gsave translate 45 rotate 0 0 S9 stroke grestore} bind def +/D10 {gsave translate 45 rotate 0 0 S10 stroke grestore} bind def +/D11 {gsave translate 45 rotate 0 0 S11 stroke grestore} bind def +/D12 {gsave translate 45 rotate 0 0 S12 stroke grestore} bind def +/D13 {gsave translate 45 rotate 0 0 S13 stroke grestore} bind def +/D14 {gsave translate 45 rotate 0 0 S14 stroke grestore} bind def +/D15 {gsave translate 45 rotate 0 0 S15 stroke grestore} bind def +/DiaE {stroke [] 0 setdash vpt add M + hpt neg vpt neg V hpt vpt neg V + hpt vpt V hpt neg vpt V closepath stroke} def +/BoxE {stroke [] 0 setdash exch hpt sub exch vpt add M + 0 vpt2 neg V hpt2 0 V 0 vpt2 V + hpt2 neg 0 V closepath stroke} def +/TriUE {stroke [] 0 setdash vpt 1.12 mul add M + hpt neg vpt -1.62 mul V + hpt 2 mul 0 V + hpt neg vpt 1.62 mul V closepath stroke} def +/TriDE {stroke [] 0 setdash vpt 1.12 mul sub M + hpt neg vpt 1.62 mul V + hpt 2 mul 0 V + hpt neg vpt -1.62 mul V closepath stroke} def +/PentE {stroke [] 0 setdash gsave + translate 0 hpt M 4 {72 rotate 0 hpt L} repeat + closepath stroke grestore} def +/CircE {stroke [] 0 setdash + hpt 0 360 arc stroke} def +/Opaque {gsave closepath 1 setgray fill grestore 0 setgray closepath} def +/DiaW {stroke [] 0 setdash vpt add M + hpt neg vpt neg V hpt vpt neg V + hpt vpt V hpt neg vpt V Opaque stroke} def +/BoxW {stroke [] 0 setdash exch hpt sub exch vpt add M + 0 vpt2 neg V hpt2 0 V 0 vpt2 V + hpt2 neg 0 V Opaque stroke} def +/TriUW {stroke [] 0 setdash vpt 1.12 mul add M + hpt neg vpt -1.62 mul V + hpt 2 mul 0 V + hpt neg vpt 1.62 mul V Opaque stroke} def +/TriDW {stroke [] 0 setdash vpt 1.12 mul sub M + hpt neg vpt 1.62 mul V + hpt 2 mul 0 V + hpt neg vpt -1.62 mul V Opaque stroke} def +/PentW {stroke [] 0 setdash gsave + translate 0 hpt M 4 {72 rotate 0 hpt L} repeat + Opaque stroke grestore} def +/CircW {stroke [] 0 setdash + hpt 0 360 arc Opaque stroke} def +/BoxFill {gsave Rec 1 setgray fill grestore} def +/Density { + /Fillden exch def + currentrgbcolor + /ColB exch def /ColG exch def /ColR exch def + /ColR ColR Fillden mul Fillden sub 1 add def + /ColG ColG Fillden mul Fillden sub 1 add def + /ColB ColB Fillden mul Fillden sub 1 add def + ColR ColG ColB setrgbcolor} def +/BoxColFill {gsave Rec PolyFill} def +/PolyFill {gsave Density fill grestore grestore} def +/h {rlineto rlineto rlineto gsave closepath fill grestore} bind def +% +% PostScript Level 1 Pattern Fill routine for rectangles +% Usage: x y w h s a XX PatternFill +% x,y = lower left corner of box to be filled +% w,h = width and height of box +% a = angle in degrees between lines and x-axis +% XX = 0/1 for no/yes cross-hatch +% +/PatternFill {gsave /PFa [ 9 2 roll ] def + PFa 0 get PFa 2 get 2 div add PFa 1 get PFa 3 get 2 div add translate + PFa 2 get -2 div PFa 3 get -2 div PFa 2 get PFa 3 get Rec + gsave 1 setgray fill grestore clip + currentlinewidth 0.5 mul setlinewidth + /PFs PFa 2 get dup mul PFa 3 get dup mul add sqrt def + 0 0 M PFa 5 get rotate PFs -2 div dup translate + 0 1 PFs PFa 4 get div 1 add floor cvi + {PFa 4 get mul 0 M 0 PFs V} for + 0 PFa 6 get ne { + 0 1 PFs PFa 4 get div 1 add floor cvi + {PFa 4 get mul 0 2 1 roll M PFs 0 V} for + } if + stroke grestore} def +% +/languagelevel where + {pop languagelevel} {1} ifelse + 2 lt + {/InterpretLevel1 true def} + {/InterpretLevel1 Level1 def} + ifelse +% +% PostScript level 2 pattern fill definitions +% +/Level2PatternFill { +/Tile8x8 {/PaintType 2 /PatternType 1 /TilingType 1 /BBox [0 0 8 8] /XStep 8 /YStep 8} + bind def +/KeepColor {currentrgbcolor [/Pattern /DeviceRGB] setcolorspace} bind def +<< Tile8x8 + /PaintProc {0.5 setlinewidth pop 0 0 M 8 8 L 0 8 M 8 0 L stroke} +>> matrix makepattern +/Pat1 exch def +<< Tile8x8 + /PaintProc {0.5 setlinewidth pop 0 0 M 8 8 L 0 8 M 8 0 L stroke + 0 4 M 4 8 L 8 4 L 4 0 L 0 4 L stroke} +>> matrix makepattern +/Pat2 exch def +<< Tile8x8 + /PaintProc {0.5 setlinewidth pop 0 0 M 0 8 L + 8 8 L 8 0 L 0 0 L fill} +>> matrix makepattern +/Pat3 exch def +<< Tile8x8 + /PaintProc {0.5 setlinewidth pop -4 8 M 8 -4 L + 0 12 M 12 0 L stroke} +>> matrix makepattern +/Pat4 exch def +<< Tile8x8 + /PaintProc {0.5 setlinewidth pop -4 0 M 8 12 L + 0 -4 M 12 8 L stroke} +>> matrix makepattern +/Pat5 exch def +<< Tile8x8 + /PaintProc {0.5 setlinewidth pop -2 8 M 4 -4 L + 0 12 M 8 -4 L 4 12 M 10 0 L stroke} +>> matrix makepattern +/Pat6 exch def +<< Tile8x8 + /PaintProc {0.5 setlinewidth pop -2 0 M 4 12 L + 0 -4 M 8 12 L 4 -4 M 10 8 L stroke} +>> matrix makepattern +/Pat7 exch def +<< Tile8x8 + /PaintProc {0.5 setlinewidth pop 8 -2 M -4 4 L + 12 0 M -4 8 L 12 4 M 0 10 L stroke} +>> matrix makepattern +/Pat8 exch def +<< Tile8x8 + /PaintProc {0.5 setlinewidth pop 0 -2 M 12 4 L + -4 0 M 12 8 L -4 4 M 8 10 L stroke} +>> matrix makepattern +/Pat9 exch def +/Pattern1 {PatternBgnd KeepColor Pat1 setpattern} bind def +/Pattern2 {PatternBgnd KeepColor Pat2 setpattern} bind def +/Pattern3 {PatternBgnd KeepColor Pat3 setpattern} bind def +/Pattern4 {PatternBgnd KeepColor Landscape {Pat5} {Pat4} ifelse setpattern} bind def +/Pattern5 {PatternBgnd KeepColor Landscape {Pat4} {Pat5} ifelse setpattern} bind def +/Pattern6 {PatternBgnd KeepColor Landscape {Pat9} {Pat6} ifelse setpattern} bind def +/Pattern7 {PatternBgnd KeepColor Landscape {Pat8} {Pat7} ifelse setpattern} bind def +} def +% +% +%End of PostScript Level 2 code +% +/PatternBgnd { + TransparentPatterns {} {gsave 1 setgray fill grestore} ifelse +} def +% +% Substitute for Level 2 pattern fill codes with +% grayscale if Level 2 support is not selected. +% +/Level1PatternFill { +/Pattern1 {0.250 Density} bind def +/Pattern2 {0.500 Density} bind def +/Pattern3 {0.750 Density} bind def +/Pattern4 {0.125 Density} bind def +/Pattern5 {0.375 Density} bind def +/Pattern6 {0.625 Density} bind def +/Pattern7 {0.875 Density} bind def +} def +% +% Now test for support of Level 2 code +% +Level1 {Level1PatternFill} {Level2PatternFill} ifelse +% +/Symbol-Oblique /Symbol findfont [1 0 .167 1 0 0] makefont +dup length dict begin {1 index /FID eq {pop pop} {def} ifelse} forall +currentdict end definefont pop +/MFshow { + { dup 5 get 3 ge + { 5 get 3 eq {gsave} {grestore} ifelse } + {dup dup 0 get findfont exch 1 get scalefont setfont + [ currentpoint ] exch dup 2 get 0 exch R dup 5 get 2 ne {dup dup 6 + get exch 4 get {Gshow} {stringwidth pop 0 R} ifelse }if dup 5 get 0 eq + {dup 3 get {2 get neg 0 exch R pop} {pop aload pop M} ifelse} {dup 5 + get 1 eq {dup 2 get exch dup 3 get exch 6 get stringwidth pop -2 div + dup 0 R} {dup 6 get stringwidth pop -2 div 0 R 6 get + show 2 index {aload pop M neg 3 -1 roll neg R pop pop} {pop pop pop + pop aload pop M} ifelse }ifelse }ifelse } + ifelse } + forall} def +/Gswidth {dup type /stringtype eq {stringwidth} {pop (n) stringwidth} ifelse} def +/MFwidth {0 exch { dup 5 get 3 ge { 5 get 3 eq { 0 } { pop } ifelse } + {dup 3 get{dup dup 0 get findfont exch 1 get scalefont setfont + 6 get Gswidth pop add} {pop} ifelse} ifelse} forall} def +/MLshow { currentpoint stroke M + 0 exch R + Blacktext {gsave 0 setgray MFshow grestore} {MFshow} ifelse } bind def +/MRshow { currentpoint stroke M + exch dup MFwidth neg 3 -1 roll R + Blacktext {gsave 0 setgray MFshow grestore} {MFshow} ifelse } bind def +/MCshow { currentpoint stroke M + exch dup MFwidth -2 div 3 -1 roll R + Blacktext {gsave 0 setgray MFshow grestore} {MFshow} ifelse } bind def +/XYsave { [( ) 1 2 true false 3 ()] } bind def +/XYrestore { [( ) 1 2 true false 4 ()] } bind def +end +%%EndProlog +%%Page: 1 1 +gnudict begin +gsave +doclip +50 50 translate +0.100 0.100 scale +90 rotate +0 -5040 translate +0 setgray +newpath +(Helvetica) findfont 140 scalefont setfont +1.000 UL +LTb +686 922 M +63 0 V +stroke +602 922 M +[ [(Helvetica) 140.0 0.0 true true 0 ( 50)] +] -46.7 MRshow +1.000 UL +LTb +686 1405 M +63 0 V +stroke +602 1405 M +[ [(Helvetica) 140.0 0.0 true true 0 ( 100)] +] -46.7 MRshow +1.000 UL +LTb +686 1888 M +63 0 V +stroke +602 1888 M +[ [(Helvetica) 140.0 0.0 true true 0 ( 150)] +] -46.7 MRshow +1.000 UL +LTb +686 2372 M +63 0 V +stroke +602 2372 M +[ [(Helvetica) 140.0 0.0 true true 0 ( 200)] +] -46.7 MRshow +1.000 UL +LTb +686 2855 M +63 0 V +stroke +602 2855 M +[ [(Helvetica) 140.0 0.0 true true 0 ( 250)] +] -46.7 MRshow +1.000 UL +LTb +686 448 M +0 63 V +stroke +686 308 M +[ [(Helvetica) 140.0 0.0 true true 0 ( 0)] +] -46.7 MCshow +1.000 UL +LTb +1159 448 M +0 63 V +stroke +1159 308 M +[ [(Helvetica) 140.0 0.0 true true 0 ( 2000)] +] -46.7 MCshow +1.000 UL +LTb +1631 448 M +0 63 V +stroke +1631 308 M +[ [(Helvetica) 140.0 0.0 true true 0 ( 4000)] +] -46.7 MCshow +1.000 UL +LTb +2104 448 M +0 63 V +stroke +2104 308 M +[ [(Helvetica) 140.0 0.0 true true 0 ( 6000)] +] -46.7 MCshow +1.000 UL +LTb +2576 448 M +0 63 V +stroke +2576 308 M +[ [(Helvetica) 140.0 0.0 true true 0 ( 8000)] +] -46.7 MCshow +1.000 UL +LTb +1.000 UL +LTb +686 2855 M +686 448 L +1890 0 V +0 2407 R +-1890 0 R +stroke +LCb setrgbcolor +112 1651 M +currentpoint gsave translate -270 rotate 0 0 moveto +[ [(Helvetica) 140.0 0.0 true true 0 (Ratio of Total Execution to Total Work)] +] -46.7 MCshow +grestore +LTb +LCb setrgbcolor +1631 98 M +[ [(Helvetica) 140.0 0.0 true true 0 (Cycles in one Task)] +] -46.7 MCshow +LTb +1.000 UP +1.000 UL +LTb +LCb setrgbcolor +3489 2785 M +[ [(Helvetica) 140.0 0.0 true true 0 (pthreads)] +] -46.7 MCshow +LTb +1.000 UL +LTb +2744 2155 N +0 700 V +1491 0 V +0 -700 V +-1491 0 V +Z stroke +2744 2715 M +1491 0 V +% Begin plot #1 +stroke +4.000 UL +LT5 +LC7 setrgbcolor +LCb setrgbcolor +3668 2645 M +[ [(Helvetica) 140.0 0.0 true true 0 (80 Threads)] +] -46.7 MRshow +LT5 +LC7 setrgbcolor +3752 2645 M +399 0 V +1272 2855 M +371 -919 V +933 -698 V +% End plot #1 +% Begin plot #2 +stroke +LT6 +LCb setrgbcolor +3668 2505 M +[ [(Helvetica) 140.0 0.0 true true 0 (160 Threads)] +] -46.7 MRshow +LT6 +3752 2505 M +399 0 V +1280 2855 M +1731 1723 L +845 -658 V +% End plot #2 +% Begin plot #3 +stroke +LT7 +LC1 setrgbcolor +LCb setrgbcolor +3668 2365 M +[ [(Helvetica) 140.0 0.0 true true 0 (320 Threads)] +] -46.7 MRshow +LT7 +LC1 setrgbcolor +3752 2365 M +399 0 V +1096 2855 M +95 -542 V +439 -867 V +2531 870 L +% End plot #3 +% Begin plot #4 +stroke +LT8 +LCb setrgbcolor +3668 2225 M +[ [(Helvetica) 140.0 0.0 true true 0 (640 Threads)] +] -46.7 MRshow +LT8 +3752 2225 M +399 0 V +1310 2855 M +320 -574 V +2543 1207 L +% End plot #4 +stroke +1.000 UL +LTb +686 2855 M +686 448 L +1890 0 V +0 2407 R +-1890 0 R +1.000 UP +686 922 M +63 0 V +stroke +602 922 M +[ [(Helvetica) 140.0 0.0 true true 0 ( 50)] +] -46.7 MRshow +1.000 UL +LTb +686 1405 M +63 0 V +stroke +602 1405 M +[ [(Helvetica) 140.0 0.0 true true 0 ( 100)] +] -46.7 MRshow +1.000 UL +LTb +686 1888 M +63 0 V +stroke +602 1888 M +[ [(Helvetica) 140.0 0.0 true true 0 ( 150)] +] -46.7 MRshow +1.000 UL +LTb +686 2372 M +63 0 V +stroke +602 2372 M +[ [(Helvetica) 140.0 0.0 true true 0 ( 200)] +] -46.7 MRshow +1.000 UL +LTb +686 2855 M +63 0 V +stroke +602 2855 M +[ [(Helvetica) 140.0 0.0 true true 0 ( 250)] +] -46.7 MRshow +1.000 UL +LTb +686 448 M +0 63 V +stroke +686 308 M +[ [(Helvetica) 140.0 0.0 true true 0 ( 0)] +] -46.7 MCshow +1.000 UL +LTb +1159 448 M +0 63 V +stroke +1159 308 M +[ [(Helvetica) 140.0 0.0 true true 0 ( 2000)] +] -46.7 MCshow +1.000 UL +LTb +1631 448 M +0 63 V +stroke +1631 308 M +[ [(Helvetica) 140.0 0.0 true true 0 ( 4000)] +] -46.7 MCshow +1.000 UL +LTb +2104 448 M +0 63 V +stroke +2104 308 M +[ [(Helvetica) 140.0 0.0 true true 0 ( 6000)] +] -46.7 MCshow +1.000 UL +LTb +2576 448 M +0 63 V +stroke +2576 308 M +[ [(Helvetica) 140.0 0.0 true true 0 ( 8000)] +] -46.7 MCshow +1.000 UL +LTb +1.000 UL +LTb +686 2855 M +686 448 L +1890 0 V +0 2407 R +-1890 0 R +stroke +LCb setrgbcolor +112 1651 M +currentpoint gsave translate -270 rotate 0 0 moveto +[ [(Helvetica) 140.0 0.0 true true 0 (Ratio of Total Execution to Total Work)] +] -46.7 MCshow +grestore +LTb +LCb setrgbcolor +1631 98 M +[ [(Helvetica) 140.0 0.0 true true 0 (Cycles in one Task)] +] -46.7 MCshow +LTb +1.000 UP +1.000 UL +LTb +LCb setrgbcolor +3489 1931 M +[ [(Helvetica) 140.0 0.0 true true 0 (Vthread)] +] -46.7 MCshow +LTb +1.000 UL +LTb +2744 1301 N +0 700 V +1491 0 V +0 -700 V +-1491 0 V +Z stroke +2744 1861 M +1491 0 V +% Begin plot #1 +stroke +4.000 UL +LT0 +LCb setrgbcolor +3668 1791 M +[ [(Helvetica) 140.0 0.0 true true 0 (80 Threads)] +] -46.7 MRshow +LT0 +3752 1791 M +399 0 V +718 626 M +12 -61 V +22 -36 V +42 -37 V +86 -17 V +169 -13 V +341 -7 V +681 -2 V +505 -1 V +% End plot #1 +% Begin plot #2 +stroke +LT2 +LCb setrgbcolor +3668 1651 M +[ [(Helvetica) 140.0 0.0 true true 0 (160 Threads)] +] -46.7 MRshow +LT2 +3752 1651 M +399 0 V +718 575 M +13 4 V +20 -82 V +43 -20 V +85 -6 V +170 -12 V +340 -4 V +681 -4 V +506 -1 V +% End plot #2 +% Begin plot #3 +stroke +LT3 +LCb setrgbcolor +3668 1511 M +[ [(Helvetica) 140.0 0.0 true true 0 (320 Threads)] +] -46.7 MRshow +LT3 +3752 1511 M +399 0 V +717 581 M +13 -38 V +23 -9 V +42 -41 V +85 -19 V +169 -11 V +341 -7 V +680 -5 V +506 -1 V +% End plot #3 +% Begin plot #4 +stroke +LT4 +LCb setrgbcolor +3668 1371 M +[ [(Helvetica) 140.0 0.0 true true 0 (640 Threads)] +] -46.7 MRshow +LT4 +3752 1371 M +399 0 V +718 589 M +13 -41 V +21 -29 V +43 -20 V +85 -28 V +169 -12 V +341 -4 V +680 -4 V +506 0 V +% End plot #4 +stroke +1.000 UL +LTb +686 2855 M +686 448 L +1890 0 V +0 2407 R +-1890 0 R +1.000 UP +stroke +grestore +end +showpage +%%Trailer +%%DocumentFonts: Helvetica +%%Pages: 1 diff -r 9b9a2497757d -r eb146c5c05a8 0__Papers/PRT/PRT__formal_def/figures/plots_exec_vs_task_size/not_used/xoanon_pthreads_vthread_40core_80_160_320_640thds__o30000__perfCtrs.meas.key-right.eps --- /dev/null Thu Jan 01 00:00:00 1970 +0000 +++ b/0__Papers/PRT/PRT__formal_def/figures/plots_exec_vs_task_size/not_used/xoanon_pthreads_vthread_40core_80_160_320_640thds__o30000__perfCtrs.meas.key-right.eps Sat Aug 03 19:24:22 2013 -0700 @@ -0,0 +1,948 @@ +%!PS-Adobe-2.0 +%%Title: xoanon_pthreads_vthread_40core_80_160_320_640thds__o30000__perfCtrs.meas.key-right.eps +%%Creator: gnuplot 4.4 patchlevel 2 +%%CreationDate: Thu Jan 26 18:32:06 2012 +%%DocumentFonts: (atend) +%%BoundingBox: 251 50 554 482 +%%Orientation: Landscape +%%Pages: (atend) +%%EndComments +%%BeginProlog +/gnudict 256 dict def +gnudict begin +% +% The following true/false flags may be edited by hand if desired. +% The unit line width and grayscale image gamma correction may also be changed. +% +/Color true def +/Blacktext false def +/Solid false def +/Dashlength 1 def +/Landscape true def +/Level1 false def +/Rounded false def +/ClipToBoundingBox false def +/TransparentPatterns false def +/gnulinewidth 5.000 def +/userlinewidth gnulinewidth def +/Gamma 1.0 def +% +/vshift -46 def +/dl1 { + 10.0 Dashlength mul mul + Rounded { currentlinewidth 0.75 mul sub dup 0 le { pop 0.01 } if } if +} def +/dl2 { + 10.0 Dashlength mul mul + Rounded { currentlinewidth 0.75 mul add } if +} def +/hpt_ 31.5 def +/vpt_ 31.5 def +/hpt hpt_ def +/vpt vpt_ def +Level1 {} { +/SDict 10 dict def +systemdict /pdfmark known not { + userdict /pdfmark systemdict /cleartomark get put +} if +SDict begin [ + /Title (xoanon_pthreads_vthread_40core_80_160_320_640thds__o30000__perfCtrs.meas.key-right.eps) + /Subject (gnuplot plot) + /Creator (gnuplot 4.4 patchlevel 2) + /Author (msach) +% /Producer (gnuplot) +% /Keywords () + /CreationDate (Thu Jan 26 18:32:06 2012) + /DOCINFO pdfmark +end +} ifelse +/doclip { + ClipToBoundingBox { + newpath 251 50 moveto 554 50 lineto 554 482 lineto 251 482 lineto closepath + clip + } if +} def +% +% Gnuplot Prolog Version 4.4 (August 2010) +% +%/SuppressPDFMark true def +% +/M {moveto} bind def +/L {lineto} bind def +/R {rmoveto} bind def +/V {rlineto} bind def +/N {newpath moveto} bind def +/Z {closepath} bind def +/C {setrgbcolor} bind def +/f {rlineto fill} bind def +/g {setgray} bind def +/Gshow {show} def % May be redefined later in the file to support UTF-8 +/vpt2 vpt 2 mul def +/hpt2 hpt 2 mul def +/Lshow {currentpoint stroke M 0 vshift R + Blacktext {gsave 0 setgray show grestore} {show} ifelse} def +/Rshow {currentpoint stroke M dup stringwidth pop neg vshift R + Blacktext {gsave 0 setgray show grestore} {show} ifelse} def +/Cshow {currentpoint stroke M dup stringwidth pop -2 div vshift R + Blacktext {gsave 0 setgray show grestore} {show} ifelse} def +/UP {dup vpt_ mul /vpt exch def hpt_ mul /hpt exch def + /hpt2 hpt 2 mul def /vpt2 vpt 2 mul def} def +/DL {Color {setrgbcolor Solid {pop []} if 0 setdash} + {pop pop pop 0 setgray Solid {pop []} if 0 setdash} ifelse} def +/BL {stroke userlinewidth 2 mul setlinewidth + Rounded {1 setlinejoin 1 setlinecap} if} def +/AL {stroke userlinewidth 2 div setlinewidth + Rounded {1 setlinejoin 1 setlinecap} if} def +/UL {dup gnulinewidth mul /userlinewidth exch def + dup 1 lt {pop 1} if 10 mul /udl exch def} def +/PL {stroke userlinewidth setlinewidth + Rounded {1 setlinejoin 1 setlinecap} if} def +3.8 setmiterlimit +% Default Line colors +/LCw {1 1 1} def +/LCb {0 0 0} def +/LCa {0 0 0} def +/LC0 {1 0 0} def +/LC1 {0 1 0} def +/LC2 {0 0 1} def +/LC3 {1 0 1} def +/LC4 {0 1 1} def +/LC5 {1 1 0} def +/LC6 {0 0 0} def +/LC7 {1 0.3 0} def +/LC8 {0.5 0.5 0.5} def +% Default Line Types +/LTw {PL [] 1 setgray} def +/LTb {BL [] LCb DL} def +/LTa {AL [1 udl mul 2 udl mul] 0 setdash LCa setrgbcolor} def +/LT0 {PL [] LC0 DL} def +/LT1 {PL [4 dl1 2 dl2] LC1 DL} def +/LT2 {PL [2 dl1 3 dl2] LC2 DL} def +/LT3 {PL [1 dl1 1.5 dl2] LC3 DL} def +/LT4 {PL [6 dl1 2 dl2 1 dl1 2 dl2] LC4 DL} def +/LT5 {PL [3 dl1 3 dl2 1 dl1 3 dl2] LC5 DL} def +/LT6 {PL [2 dl1 2 dl2 2 dl1 6 dl2] LC6 DL} def +/LT7 {PL [1 dl1 2 dl2 6 dl1 2 dl2 1 dl1 2 dl2] LC7 DL} def +/LT8 {PL [2 dl1 2 dl2 2 dl1 2 dl2 2 dl1 2 dl2 2 dl1 4 dl2] LC8 DL} def +/Pnt {stroke [] 0 setdash gsave 1 setlinecap M 0 0 V stroke grestore} def +/Dia {stroke [] 0 setdash 2 copy vpt add M + hpt neg vpt neg V hpt vpt neg V + hpt vpt V hpt neg vpt V closepath stroke + Pnt} def +/Pls {stroke [] 0 setdash vpt sub M 0 vpt2 V + currentpoint stroke M + hpt neg vpt neg R hpt2 0 V stroke + } def +/Box {stroke [] 0 setdash 2 copy exch hpt sub exch vpt add M + 0 vpt2 neg V hpt2 0 V 0 vpt2 V + hpt2 neg 0 V closepath stroke + Pnt} def +/Crs {stroke [] 0 setdash exch hpt sub exch vpt add M + hpt2 vpt2 neg V currentpoint stroke M + hpt2 neg 0 R hpt2 vpt2 V stroke} def +/TriU {stroke [] 0 setdash 2 copy vpt 1.12 mul add M + hpt neg vpt -1.62 mul V + hpt 2 mul 0 V + hpt neg vpt 1.62 mul V closepath stroke + Pnt} def +/Star {2 copy Pls Crs} def +/BoxF {stroke [] 0 setdash exch hpt sub exch vpt add M + 0 vpt2 neg V hpt2 0 V 0 vpt2 V + hpt2 neg 0 V closepath fill} def +/TriUF {stroke [] 0 setdash vpt 1.12 mul add M + hpt neg vpt -1.62 mul V + hpt 2 mul 0 V + hpt neg vpt 1.62 mul V closepath fill} def +/TriD {stroke [] 0 setdash 2 copy vpt 1.12 mul sub M + hpt neg vpt 1.62 mul V + hpt 2 mul 0 V + hpt neg vpt -1.62 mul V closepath stroke + Pnt} def +/TriDF {stroke [] 0 setdash vpt 1.12 mul sub M + hpt neg vpt 1.62 mul V + hpt 2 mul 0 V + hpt neg vpt -1.62 mul V closepath fill} def +/DiaF {stroke [] 0 setdash vpt add M + hpt neg vpt neg V hpt vpt neg V + hpt vpt V hpt neg vpt V closepath fill} def +/Pent {stroke [] 0 setdash 2 copy gsave + translate 0 hpt M 4 {72 rotate 0 hpt L} repeat + closepath stroke grestore Pnt} def +/PentF {stroke [] 0 setdash gsave + translate 0 hpt M 4 {72 rotate 0 hpt L} repeat + closepath fill grestore} def +/Circle {stroke [] 0 setdash 2 copy + hpt 0 360 arc stroke Pnt} def +/CircleF {stroke [] 0 setdash hpt 0 360 arc fill} def +/C0 {BL [] 0 setdash 2 copy moveto vpt 90 450 arc} bind def +/C1 {BL [] 0 setdash 2 copy moveto + 2 copy vpt 0 90 arc closepath fill + vpt 0 360 arc closepath} bind def +/C2 {BL [] 0 setdash 2 copy moveto + 2 copy vpt 90 180 arc closepath fill + vpt 0 360 arc closepath} bind def +/C3 {BL [] 0 setdash 2 copy moveto + 2 copy vpt 0 180 arc closepath fill + vpt 0 360 arc closepath} bind def +/C4 {BL [] 0 setdash 2 copy moveto + 2 copy vpt 180 270 arc closepath fill + vpt 0 360 arc closepath} bind def +/C5 {BL [] 0 setdash 2 copy moveto + 2 copy vpt 0 90 arc + 2 copy moveto + 2 copy vpt 180 270 arc closepath fill + vpt 0 360 arc} bind def +/C6 {BL [] 0 setdash 2 copy moveto + 2 copy vpt 90 270 arc closepath fill + vpt 0 360 arc closepath} bind def +/C7 {BL [] 0 setdash 2 copy moveto + 2 copy vpt 0 270 arc closepath fill + vpt 0 360 arc closepath} bind def +/C8 {BL [] 0 setdash 2 copy moveto + 2 copy vpt 270 360 arc closepath fill + vpt 0 360 arc closepath} bind def +/C9 {BL [] 0 setdash 2 copy moveto + 2 copy vpt 270 450 arc closepath fill + vpt 0 360 arc closepath} bind def +/C10 {BL [] 0 setdash 2 copy 2 copy moveto vpt 270 360 arc closepath fill + 2 copy moveto + 2 copy vpt 90 180 arc closepath fill + vpt 0 360 arc closepath} bind def +/C11 {BL [] 0 setdash 2 copy moveto + 2 copy vpt 0 180 arc closepath fill + 2 copy moveto + 2 copy vpt 270 360 arc closepath fill + vpt 0 360 arc closepath} bind def +/C12 {BL [] 0 setdash 2 copy moveto + 2 copy vpt 180 360 arc closepath fill + vpt 0 360 arc closepath} bind def +/C13 {BL [] 0 setdash 2 copy moveto + 2 copy vpt 0 90 arc closepath fill + 2 copy moveto + 2 copy vpt 180 360 arc closepath fill + vpt 0 360 arc closepath} bind def +/C14 {BL [] 0 setdash 2 copy moveto + 2 copy vpt 90 360 arc closepath fill + vpt 0 360 arc} bind def +/C15 {BL [] 0 setdash 2 copy vpt 0 360 arc closepath fill + vpt 0 360 arc closepath} bind def +/Rec {newpath 4 2 roll moveto 1 index 0 rlineto 0 exch rlineto + neg 0 rlineto closepath} bind def +/Square {dup Rec} bind def +/Bsquare {vpt sub exch vpt sub exch vpt2 Square} bind def +/S0 {BL [] 0 setdash 2 copy moveto 0 vpt rlineto BL Bsquare} bind def +/S1 {BL [] 0 setdash 2 copy vpt Square fill Bsquare} bind def +/S2 {BL [] 0 setdash 2 copy exch vpt sub exch vpt Square fill Bsquare} bind def +/S3 {BL [] 0 setdash 2 copy exch vpt sub exch vpt2 vpt Rec fill Bsquare} bind def +/S4 {BL [] 0 setdash 2 copy exch vpt sub exch vpt sub vpt Square fill Bsquare} bind def +/S5 {BL [] 0 setdash 2 copy 2 copy vpt Square fill + exch vpt sub exch vpt sub vpt Square fill Bsquare} bind def +/S6 {BL [] 0 setdash 2 copy exch vpt sub exch vpt sub vpt vpt2 Rec fill Bsquare} bind def +/S7 {BL [] 0 setdash 2 copy exch vpt sub exch vpt sub vpt vpt2 Rec fill + 2 copy vpt Square fill Bsquare} bind def +/S8 {BL [] 0 setdash 2 copy vpt sub vpt Square fill Bsquare} bind def +/S9 {BL [] 0 setdash 2 copy vpt sub vpt vpt2 Rec fill Bsquare} bind def +/S10 {BL [] 0 setdash 2 copy vpt sub vpt Square fill 2 copy exch vpt sub exch vpt Square fill + Bsquare} bind def +/S11 {BL [] 0 setdash 2 copy vpt sub vpt Square fill 2 copy exch vpt sub exch vpt2 vpt Rec fill + Bsquare} bind def +/S12 {BL [] 0 setdash 2 copy exch vpt sub exch vpt sub vpt2 vpt Rec fill Bsquare} bind def +/S13 {BL [] 0 setdash 2 copy exch vpt sub exch vpt sub vpt2 vpt Rec fill + 2 copy vpt Square fill Bsquare} bind def +/S14 {BL [] 0 setdash 2 copy exch vpt sub exch vpt sub vpt2 vpt Rec fill + 2 copy exch vpt sub exch vpt Square fill Bsquare} bind def +/S15 {BL [] 0 setdash 2 copy Bsquare fill Bsquare} bind def +/D0 {gsave translate 45 rotate 0 0 S0 stroke grestore} bind def +/D1 {gsave translate 45 rotate 0 0 S1 stroke grestore} bind def +/D2 {gsave translate 45 rotate 0 0 S2 stroke grestore} bind def +/D3 {gsave translate 45 rotate 0 0 S3 stroke grestore} bind def +/D4 {gsave translate 45 rotate 0 0 S4 stroke grestore} bind def +/D5 {gsave translate 45 rotate 0 0 S5 stroke grestore} bind def +/D6 {gsave translate 45 rotate 0 0 S6 stroke grestore} bind def +/D7 {gsave translate 45 rotate 0 0 S7 stroke grestore} bind def +/D8 {gsave translate 45 rotate 0 0 S8 stroke grestore} bind def +/D9 {gsave translate 45 rotate 0 0 S9 stroke grestore} bind def +/D10 {gsave translate 45 rotate 0 0 S10 stroke grestore} bind def +/D11 {gsave translate 45 rotate 0 0 S11 stroke grestore} bind def +/D12 {gsave translate 45 rotate 0 0 S12 stroke grestore} bind def +/D13 {gsave translate 45 rotate 0 0 S13 stroke grestore} bind def +/D14 {gsave translate 45 rotate 0 0 S14 stroke grestore} bind def +/D15 {gsave translate 45 rotate 0 0 S15 stroke grestore} bind def +/DiaE {stroke [] 0 setdash vpt add M + hpt neg vpt neg V hpt vpt neg V + hpt vpt V hpt neg vpt V closepath stroke} def +/BoxE {stroke [] 0 setdash exch hpt sub exch vpt add M + 0 vpt2 neg V hpt2 0 V 0 vpt2 V + hpt2 neg 0 V closepath stroke} def +/TriUE {stroke [] 0 setdash vpt 1.12 mul add M + hpt neg vpt -1.62 mul V + hpt 2 mul 0 V + hpt neg vpt 1.62 mul V closepath stroke} def +/TriDE {stroke [] 0 setdash vpt 1.12 mul sub M + hpt neg vpt 1.62 mul V + hpt 2 mul 0 V + hpt neg vpt -1.62 mul V closepath stroke} def +/PentE {stroke [] 0 setdash gsave + translate 0 hpt M 4 {72 rotate 0 hpt L} repeat + closepath stroke grestore} def +/CircE {stroke [] 0 setdash + hpt 0 360 arc stroke} def +/Opaque {gsave closepath 1 setgray fill grestore 0 setgray closepath} def +/DiaW {stroke [] 0 setdash vpt add M + hpt neg vpt neg V hpt vpt neg V + hpt vpt V hpt neg vpt V Opaque stroke} def +/BoxW {stroke [] 0 setdash exch hpt sub exch vpt add M + 0 vpt2 neg V hpt2 0 V 0 vpt2 V + hpt2 neg 0 V Opaque stroke} def +/TriUW {stroke [] 0 setdash vpt 1.12 mul add M + hpt neg vpt -1.62 mul V + hpt 2 mul 0 V + hpt neg vpt 1.62 mul V Opaque stroke} def +/TriDW {stroke [] 0 setdash vpt 1.12 mul sub M + hpt neg vpt 1.62 mul V + hpt 2 mul 0 V + hpt neg vpt -1.62 mul V Opaque stroke} def +/PentW {stroke [] 0 setdash gsave + translate 0 hpt M 4 {72 rotate 0 hpt L} repeat + Opaque stroke grestore} def +/CircW {stroke [] 0 setdash + hpt 0 360 arc Opaque stroke} def +/BoxFill {gsave Rec 1 setgray fill grestore} def +/Density { + /Fillden exch def + currentrgbcolor + /ColB exch def /ColG exch def /ColR exch def + /ColR ColR Fillden mul Fillden sub 1 add def + /ColG ColG Fillden mul Fillden sub 1 add def + /ColB ColB Fillden mul Fillden sub 1 add def + ColR ColG ColB setrgbcolor} def +/BoxColFill {gsave Rec PolyFill} def +/PolyFill {gsave Density fill grestore grestore} def +/h {rlineto rlineto rlineto gsave closepath fill grestore} bind def +% +% PostScript Level 1 Pattern Fill routine for rectangles +% Usage: x y w h s a XX PatternFill +% x,y = lower left corner of box to be filled +% w,h = width and height of box +% a = angle in degrees between lines and x-axis +% XX = 0/1 for no/yes cross-hatch +% +/PatternFill {gsave /PFa [ 9 2 roll ] def + PFa 0 get PFa 2 get 2 div add PFa 1 get PFa 3 get 2 div add translate + PFa 2 get -2 div PFa 3 get -2 div PFa 2 get PFa 3 get Rec + gsave 1 setgray fill grestore clip + currentlinewidth 0.5 mul setlinewidth + /PFs PFa 2 get dup mul PFa 3 get dup mul add sqrt def + 0 0 M PFa 5 get rotate PFs -2 div dup translate + 0 1 PFs PFa 4 get div 1 add floor cvi + {PFa 4 get mul 0 M 0 PFs V} for + 0 PFa 6 get ne { + 0 1 PFs PFa 4 get div 1 add floor cvi + {PFa 4 get mul 0 2 1 roll M PFs 0 V} for + } if + stroke grestore} def +% +/languagelevel where + {pop languagelevel} {1} ifelse + 2 lt + {/InterpretLevel1 true def} + {/InterpretLevel1 Level1 def} + ifelse +% +% PostScript level 2 pattern fill definitions +% +/Level2PatternFill { +/Tile8x8 {/PaintType 2 /PatternType 1 /TilingType 1 /BBox [0 0 8 8] /XStep 8 /YStep 8} + bind def +/KeepColor {currentrgbcolor [/Pattern /DeviceRGB] setcolorspace} bind def +<< Tile8x8 + /PaintProc {0.5 setlinewidth pop 0 0 M 8 8 L 0 8 M 8 0 L stroke} +>> matrix makepattern +/Pat1 exch def +<< Tile8x8 + /PaintProc {0.5 setlinewidth pop 0 0 M 8 8 L 0 8 M 8 0 L stroke + 0 4 M 4 8 L 8 4 L 4 0 L 0 4 L stroke} +>> matrix makepattern +/Pat2 exch def +<< Tile8x8 + /PaintProc {0.5 setlinewidth pop 0 0 M 0 8 L + 8 8 L 8 0 L 0 0 L fill} +>> matrix makepattern +/Pat3 exch def +<< Tile8x8 + /PaintProc {0.5 setlinewidth pop -4 8 M 8 -4 L + 0 12 M 12 0 L stroke} +>> matrix makepattern +/Pat4 exch def +<< Tile8x8 + /PaintProc {0.5 setlinewidth pop -4 0 M 8 12 L + 0 -4 M 12 8 L stroke} +>> matrix makepattern +/Pat5 exch def +<< Tile8x8 + /PaintProc {0.5 setlinewidth pop -2 8 M 4 -4 L + 0 12 M 8 -4 L 4 12 M 10 0 L stroke} +>> matrix makepattern +/Pat6 exch def +<< Tile8x8 + /PaintProc {0.5 setlinewidth pop -2 0 M 4 12 L + 0 -4 M 8 12 L 4 -4 M 10 8 L stroke} +>> matrix makepattern +/Pat7 exch def +<< Tile8x8 + /PaintProc {0.5 setlinewidth pop 8 -2 M -4 4 L + 12 0 M -4 8 L 12 4 M 0 10 L stroke} +>> matrix makepattern +/Pat8 exch def +<< Tile8x8 + /PaintProc {0.5 setlinewidth pop 0 -2 M 12 4 L + -4 0 M 12 8 L -4 4 M 8 10 L stroke} +>> matrix makepattern +/Pat9 exch def +/Pattern1 {PatternBgnd KeepColor Pat1 setpattern} bind def +/Pattern2 {PatternBgnd KeepColor Pat2 setpattern} bind def +/Pattern3 {PatternBgnd KeepColor Pat3 setpattern} bind def +/Pattern4 {PatternBgnd KeepColor Landscape {Pat5} {Pat4} ifelse setpattern} bind def +/Pattern5 {PatternBgnd KeepColor Landscape {Pat4} {Pat5} ifelse setpattern} bind def +/Pattern6 {PatternBgnd KeepColor Landscape {Pat9} {Pat6} ifelse setpattern} bind def +/Pattern7 {PatternBgnd KeepColor Landscape {Pat8} {Pat7} ifelse setpattern} bind def +} def +% +% +%End of PostScript Level 2 code +% +/PatternBgnd { + TransparentPatterns {} {gsave 1 setgray fill grestore} ifelse +} def +% +% Substitute for Level 2 pattern fill codes with +% grayscale if Level 2 support is not selected. +% +/Level1PatternFill { +/Pattern1 {0.250 Density} bind def +/Pattern2 {0.500 Density} bind def +/Pattern3 {0.750 Density} bind def +/Pattern4 {0.125 Density} bind def +/Pattern5 {0.375 Density} bind def +/Pattern6 {0.625 Density} bind def +/Pattern7 {0.875 Density} bind def +} def +% +% Now test for support of Level 2 code +% +Level1 {Level1PatternFill} {Level2PatternFill} ifelse +% +/Symbol-Oblique /Symbol findfont [1 0 .167 1 0 0] makefont +dup length dict begin {1 index /FID eq {pop pop} {def} ifelse} forall +currentdict end definefont pop +/MFshow { + { dup 5 get 3 ge + { 5 get 3 eq {gsave} {grestore} ifelse } + {dup dup 0 get findfont exch 1 get scalefont setfont + [ currentpoint ] exch dup 2 get 0 exch R dup 5 get 2 ne {dup dup 6 + get exch 4 get {Gshow} {stringwidth pop 0 R} ifelse }if dup 5 get 0 eq + {dup 3 get {2 get neg 0 exch R pop} {pop aload pop M} ifelse} {dup 5 + get 1 eq {dup 2 get exch dup 3 get exch 6 get stringwidth pop -2 div + dup 0 R} {dup 6 get stringwidth pop -2 div 0 R 6 get + show 2 index {aload pop M neg 3 -1 roll neg R pop pop} {pop pop pop + pop aload pop M} ifelse }ifelse }ifelse } + ifelse } + forall} def +/Gswidth {dup type /stringtype eq {stringwidth} {pop (n) stringwidth} ifelse} def +/MFwidth {0 exch { dup 5 get 3 ge { 5 get 3 eq { 0 } { pop } ifelse } + {dup 3 get{dup dup 0 get findfont exch 1 get scalefont setfont + 6 get Gswidth pop add} {pop} ifelse} ifelse} forall} def +/MLshow { currentpoint stroke M + 0 exch R + Blacktext {gsave 0 setgray MFshow grestore} {MFshow} ifelse } bind def +/MRshow { currentpoint stroke M + exch dup MFwidth neg 3 -1 roll R + Blacktext {gsave 0 setgray MFshow grestore} {MFshow} ifelse } bind def +/MCshow { currentpoint stroke M + exch dup MFwidth -2 div 3 -1 roll R + Blacktext {gsave 0 setgray MFshow grestore} {MFshow} ifelse } bind def +/XYsave { [( ) 1 2 true false 3 ()] } bind def +/XYrestore { [( ) 1 2 true false 4 ()] } bind def +end +%%EndProlog +%%Page: 1 1 +gnudict begin +gsave +doclip +50 50 translate +0.100 0.100 scale +90 rotate +0 -5040 translate +0 setgray +newpath +(Helvetica) findfont 140 scalefont setfont +1.000 UL +LTb +686 922 M +63 0 V +stroke +602 922 M +[ [(Helvetica) 140.0 0.0 true true 0 ( 50)] +] -46.7 MRshow +1.000 UL +LTb +686 1405 M +63 0 V +stroke +602 1405 M +[ [(Helvetica) 140.0 0.0 true true 0 ( 100)] +] -46.7 MRshow +1.000 UL +LTb +686 1888 M +63 0 V +stroke +602 1888 M +[ [(Helvetica) 140.0 0.0 true true 0 ( 150)] +] -46.7 MRshow +1.000 UL +LTb +686 2372 M +63 0 V +stroke +602 2372 M +[ [(Helvetica) 140.0 0.0 true true 0 ( 200)] +] -46.7 MRshow +1.000 UL +LTb +686 2855 M +63 0 V +stroke +602 2855 M +[ [(Helvetica) 140.0 0.0 true true 0 ( 250)] +] -46.7 MRshow +1.000 UL +LTb +686 448 M +0 63 V +stroke +686 308 M +[ [(Helvetica) 140.0 0.0 true true 0 ( 0)] +] -46.7 MCshow +1.000 UL +LTb +1109 448 M +0 63 V +stroke +1109 308 M +[ [(Helvetica) 140.0 0.0 true true 0 ( 1000)] +] -46.7 MCshow +1.000 UL +LTb +1531 448 M +0 63 V +stroke +1531 308 M +[ [(Helvetica) 140.0 0.0 true true 0 ( 2000)] +] -46.7 MCshow +1.000 UL +LTb +1954 448 M +0 63 V +stroke +1954 308 M +[ [(Helvetica) 140.0 0.0 true true 0 ( 3000)] +] -46.7 MCshow +1.000 UL +LTb +2377 448 M +0 63 V +stroke +2377 308 M +[ [(Helvetica) 140.0 0.0 true true 0 ( 4000)] +] -46.7 MCshow +1.000 UL +LTb +2799 448 M +0 63 V +stroke +2799 308 M +[ [(Helvetica) 140.0 0.0 true true 0 ( 5000)] +] -46.7 MCshow +1.000 UL +LTb +3222 448 M +0 63 V +stroke +3222 308 M +[ [(Helvetica) 140.0 0.0 true true 0 ( 6000)] +] -46.7 MCshow +1.000 UL +LTb +3644 448 M +0 63 V +stroke +3644 308 M +[ [(Helvetica) 140.0 0.0 true true 0 ( 7000)] +] -46.7 MCshow +1.000 UL +LTb +4067 448 M +0 63 V +stroke +4067 308 M +[ [(Helvetica) 140.0 0.0 true true 0 ( 8000)] +] -46.7 MCshow +1.000 UL +LTb +1.000 UL +LTb +686 2855 M +686 448 L +3381 0 V +0 2407 R +-3381 0 R +stroke +LCb setrgbcolor +112 1651 M +currentpoint gsave translate -270 rotate 0 0 moveto +[ [(Helvetica) 140.0 0.0 true true 0 (Ratio of Total Execution to Total Work)] +] -46.7 MCshow +grestore +LTb +LCb setrgbcolor +2376 98 M +[ [(Helvetica) 140.0 0.0 true true 0 (Cycles in one Task)] +] -46.7 MCshow +LTb +1.000 UP +1.000 UL +LTb +LCb setrgbcolor +3532 2882 M +[ [(Helvetica) 140.0 0.0 true true 0 (pthreads)] +] -46.7 MCshow +LTb +1.000 UL +LTb +2787 2252 N +0 700 V +1491 0 V +0 -700 V +-1491 0 V +Z stroke +2787 2812 M +1491 0 V +% Begin plot #1 +stroke +4.000 UL +LT5 +LC7 setrgbcolor +LCb setrgbcolor +3711 2742 M +[ [(Helvetica) 140.0 0.0 true true 0 (80 Threads)] +] -46.7 MRshow +LT5 +LC7 setrgbcolor +3795 2742 M +399 0 V +1735 2855 M +662 -919 V +4067 1238 L +% End plot #1 +% Begin plot #2 +stroke +LT6 +LCb setrgbcolor +3711 2602 M +[ [(Helvetica) 140.0 0.0 true true 0 (160 Threads)] +] -46.7 MRshow +LT6 +3795 2602 M +399 0 V +1748 2855 M +2555 1723 L +4067 1065 L +% End plot #2 +% Begin plot #3 +stroke +LT7 +LC1 setrgbcolor +LCb setrgbcolor +3711 2462 M +[ [(Helvetica) 140.0 0.0 true true 0 (320 Threads)] +] -46.7 MRshow +LT7 +LC1 setrgbcolor +3795 2462 M +399 0 V +1420 2855 M +170 -542 V +784 -867 V +3986 870 L +% End plot #3 +% Begin plot #4 +stroke +LT8 +LCb setrgbcolor +3711 2322 M +[ [(Helvetica) 140.0 0.0 true true 0 (640 Threads)] +] -46.7 MRshow +LT8 +3795 2322 M +399 0 V +1802 2855 M +572 -574 V +4007 1207 L +% End plot #4 +stroke +1.000 UL +LTb +686 2855 M +686 448 L +3381 0 V +0 2407 R +-3381 0 R +1.000 UP +686 922 M +63 0 V +stroke +602 922 M +[ [(Helvetica) 140.0 0.0 true true 0 ( 50)] +] -46.7 MRshow +1.000 UL +LTb +686 1405 M +63 0 V +stroke +602 1405 M +[ [(Helvetica) 140.0 0.0 true true 0 ( 100)] +] -46.7 MRshow +1.000 UL +LTb +686 1888 M +63 0 V +stroke +602 1888 M +[ [(Helvetica) 140.0 0.0 true true 0 ( 150)] +] -46.7 MRshow +1.000 UL +LTb +686 2372 M +63 0 V +stroke +602 2372 M +[ [(Helvetica) 140.0 0.0 true true 0 ( 200)] +] -46.7 MRshow +1.000 UL +LTb +686 2855 M +63 0 V +stroke +602 2855 M +[ [(Helvetica) 140.0 0.0 true true 0 ( 250)] +] -46.7 MRshow +1.000 UL +LTb +686 448 M +0 63 V +stroke +686 308 M +[ [(Helvetica) 140.0 0.0 true true 0 ( 0)] +] -46.7 MCshow +1.000 UL +LTb +1109 448 M +0 63 V +stroke +1109 308 M +[ [(Helvetica) 140.0 0.0 true true 0 ( 1000)] +] -46.7 MCshow +1.000 UL +LTb +1531 448 M +0 63 V +stroke +1531 308 M +[ [(Helvetica) 140.0 0.0 true true 0 ( 2000)] +] -46.7 MCshow +1.000 UL +LTb +1954 448 M +0 63 V +stroke +1954 308 M +[ [(Helvetica) 140.0 0.0 true true 0 ( 3000)] +] -46.7 MCshow +1.000 UL +LTb +2377 448 M +0 63 V +stroke +2377 308 M +[ [(Helvetica) 140.0 0.0 true true 0 ( 4000)] +] -46.7 MCshow +1.000 UL +LTb +2799 448 M +0 63 V +stroke +2799 308 M +[ [(Helvetica) 140.0 0.0 true true 0 ( 5000)] +] -46.7 MCshow +1.000 UL +LTb +3222 448 M +0 63 V +stroke +3222 308 M +[ [(Helvetica) 140.0 0.0 true true 0 ( 6000)] +] -46.7 MCshow +1.000 UL +LTb +3644 448 M +0 63 V +stroke +3644 308 M +[ [(Helvetica) 140.0 0.0 true true 0 ( 7000)] +] -46.7 MCshow +1.000 UL +LTb +4067 448 M +0 63 V +stroke +4067 308 M +[ [(Helvetica) 140.0 0.0 true true 0 ( 8000)] +] -46.7 MCshow +1.000 UL +LTb +1.000 UL +LTb +686 2855 M +686 448 L +3381 0 V +0 2407 R +-3381 0 R +stroke +LCb setrgbcolor +112 1651 M +currentpoint gsave translate -270 rotate 0 0 moveto +[ [(Helvetica) 140.0 0.0 true true 0 (Ratio of Total Execution to Total Work)] +] -46.7 MCshow +grestore +LTb +LCb setrgbcolor +2376 98 M +[ [(Helvetica) 140.0 0.0 true true 0 (Cycles in one Task)] +] -46.7 MCshow +LTb +1.000 UP +1.000 UL +LTb +LCb setrgbcolor +3532 2108 M +[ [(Helvetica) 140.0 0.0 true true 0 (Vthread)] +] -46.7 MCshow +LTb +1.000 UL +LTb +2787 1478 N +0 700 V +1491 0 V +0 -700 V +-1491 0 V +Z stroke +2787 2038 M +1491 0 V +% Begin plot #1 +stroke +4.000 UL +LT0 +LCb setrgbcolor +3711 1968 M +[ [(Helvetica) 140.0 0.0 true true 0 (80 Threads)] +] -46.7 MRshow +LT0 +3795 1968 M +399 0 V +743 626 M +22 -61 V +39 -36 V +75 -37 V +154 -17 V +303 -13 V +609 -7 V +1218 -2 V +904 -1 V +% End plot #1 +% Begin plot #2 +stroke +LT2 +LCb setrgbcolor +3711 1828 M +[ [(Helvetica) 140.0 0.0 true true 0 (160 Threads)] +] -46.7 MRshow +LT2 +3795 1828 M +399 0 V +743 575 M +24 4 V +36 -82 V +76 -20 V +153 -6 V +303 -12 V +609 -4 V +1217 -4 V +906 -1 V +% End plot #2 +% Begin plot #3 +stroke +LT3 +LCb setrgbcolor +3711 1688 M +[ [(Helvetica) 140.0 0.0 true true 0 (320 Threads)] +] -46.7 MRshow +LT3 +3795 1688 M +399 0 V +742 581 M +24 -38 V +39 -9 V +76 -41 V +151 -19 V +304 -11 V +610 -7 V +1216 -5 V +905 -1 V +% End plot #3 +% Begin plot #4 +stroke +LT4 +LCb setrgbcolor +3711 1548 M +[ [(Helvetica) 140.0 0.0 true true 0 (640 Threads)] +] -46.7 MRshow +LT4 +3795 1548 M +399 0 V +743 589 M +23 -41 V +38 -29 V +77 -20 V +151 -28 V +303 -12 V +610 -4 V +1217 -4 V +905 0 V +% End plot #4 +stroke +1.000 UL +LTb +686 2855 M +686 448 L +3381 0 V +0 2407 R +-3381 0 R +1.000 UP +stroke +grestore +end +showpage +%%Trailer +%%DocumentFonts: Helvetica +%%Pages: 1 diff -r 9b9a2497757d -r eb146c5c05a8 0__Papers/PRT/PRT__formal_def/figures/plots_exec_vs_task_size/not_used/xoanon_vthread_40cores_80_160_320_640thds__o30000__perfCtrs.result.eps --- /dev/null Thu Jan 01 00:00:00 1970 +0000 +++ b/0__Papers/PRT/PRT__formal_def/figures/plots_exec_vs_task_size/not_used/xoanon_vthread_40cores_80_160_320_640thds__o30000__perfCtrs.result.eps Sat Aug 03 19:24:22 2013 -0700 @@ -0,0 +1,844 @@ +%!PS-Adobe-2.0 +%%Title: xoanon_vthread_40cores_80_160_320_640thds__o30000__perfCtrs.result.eps +%%Creator: gnuplot 4.4 patchlevel 2 +%%CreationDate: Thu Jan 26 18:23:52 2012 +%%DocumentFonts: (atend) +%%BoundingBox: 251 50 554 482 +%%Orientation: Landscape +%%Pages: (atend) +%%EndComments +%%BeginProlog +/gnudict 256 dict def +gnudict begin +% +% The following true/false flags may be edited by hand if desired. +% The unit line width and grayscale image gamma correction may also be changed. +% +/Color true def +/Blacktext false def +/Solid false def +/Dashlength 1 def +/Landscape true def +/Level1 false def +/Rounded false def +/ClipToBoundingBox false def +/TransparentPatterns false def +/gnulinewidth 5.000 def +/userlinewidth gnulinewidth def +/Gamma 1.0 def +% +/vshift -46 def +/dl1 { + 10.0 Dashlength mul mul + Rounded { currentlinewidth 0.75 mul sub dup 0 le { pop 0.01 } if } if +} def +/dl2 { + 10.0 Dashlength mul mul + Rounded { currentlinewidth 0.75 mul add } if +} def +/hpt_ 31.5 def +/vpt_ 31.5 def +/hpt hpt_ def +/vpt vpt_ def +Level1 {} { +/SDict 10 dict def +systemdict /pdfmark known not { + userdict /pdfmark systemdict /cleartomark get put +} if +SDict begin [ + /Title (xoanon_vthread_40cores_80_160_320_640thds__o30000__perfCtrs.result.eps) + /Subject (gnuplot plot) + /Creator (gnuplot 4.4 patchlevel 2) + /Author (msach) +% /Producer (gnuplot) +% /Keywords () + /CreationDate (Thu Jan 26 18:23:52 2012) + /DOCINFO pdfmark +end +} ifelse +/doclip { + ClipToBoundingBox { + newpath 251 50 moveto 554 50 lineto 554 482 lineto 251 482 lineto closepath + clip + } if +} def +% +% Gnuplot Prolog Version 4.4 (August 2010) +% +%/SuppressPDFMark true def +% +/M {moveto} bind def +/L {lineto} bind def +/R {rmoveto} bind def +/V {rlineto} bind def +/N {newpath moveto} bind def +/Z {closepath} bind def +/C {setrgbcolor} bind def +/f {rlineto fill} bind def +/g {setgray} bind def +/Gshow {show} def % May be redefined later in the file to support UTF-8 +/vpt2 vpt 2 mul def +/hpt2 hpt 2 mul def +/Lshow {currentpoint stroke M 0 vshift R + Blacktext {gsave 0 setgray show grestore} {show} ifelse} def +/Rshow {currentpoint stroke M dup stringwidth pop neg vshift R + Blacktext {gsave 0 setgray show grestore} {show} ifelse} def +/Cshow {currentpoint stroke M dup stringwidth pop -2 div vshift R + Blacktext {gsave 0 setgray show grestore} {show} ifelse} def +/UP {dup vpt_ mul /vpt exch def hpt_ mul /hpt exch def + /hpt2 hpt 2 mul def /vpt2 vpt 2 mul def} def +/DL {Color {setrgbcolor Solid {pop []} if 0 setdash} + {pop pop pop 0 setgray Solid {pop []} if 0 setdash} ifelse} def +/BL {stroke userlinewidth 2 mul setlinewidth + Rounded {1 setlinejoin 1 setlinecap} if} def +/AL {stroke userlinewidth 2 div setlinewidth + Rounded {1 setlinejoin 1 setlinecap} if} def +/UL {dup gnulinewidth mul /userlinewidth exch def + dup 1 lt {pop 1} if 10 mul /udl exch def} def +/PL {stroke userlinewidth setlinewidth + Rounded {1 setlinejoin 1 setlinecap} if} def +3.8 setmiterlimit +% Default Line colors +/LCw {1 1 1} def +/LCb {0 0 0} def +/LCa {0 0 0} def +/LC0 {1 0 0} def +/LC1 {0 1 0} def +/LC2 {0 0 1} def +/LC3 {1 0 1} def +/LC4 {0 1 1} def +/LC5 {1 1 0} def +/LC6 {0 0 0} def +/LC7 {1 0.3 0} def +/LC8 {0.5 0.5 0.5} def +% Default Line Types +/LTw {PL [] 1 setgray} def +/LTb {BL [] LCb DL} def +/LTa {AL [1 udl mul 2 udl mul] 0 setdash LCa setrgbcolor} def +/LT0 {PL [] LC0 DL} def +/LT1 {PL [4 dl1 2 dl2] LC1 DL} def +/LT2 {PL [2 dl1 3 dl2] LC2 DL} def +/LT3 {PL [1 dl1 1.5 dl2] LC3 DL} def +/LT4 {PL [6 dl1 2 dl2 1 dl1 2 dl2] LC4 DL} def +/LT5 {PL [3 dl1 3 dl2 1 dl1 3 dl2] LC5 DL} def +/LT6 {PL [2 dl1 2 dl2 2 dl1 6 dl2] LC6 DL} def +/LT7 {PL [1 dl1 2 dl2 6 dl1 2 dl2 1 dl1 2 dl2] LC7 DL} def +/LT8 {PL [2 dl1 2 dl2 2 dl1 2 dl2 2 dl1 2 dl2 2 dl1 4 dl2] LC8 DL} def +/Pnt {stroke [] 0 setdash gsave 1 setlinecap M 0 0 V stroke grestore} def +/Dia {stroke [] 0 setdash 2 copy vpt add M + hpt neg vpt neg V hpt vpt neg V + hpt vpt V hpt neg vpt V closepath stroke + Pnt} def +/Pls {stroke [] 0 setdash vpt sub M 0 vpt2 V + currentpoint stroke M + hpt neg vpt neg R hpt2 0 V stroke + } def +/Box {stroke [] 0 setdash 2 copy exch hpt sub exch vpt add M + 0 vpt2 neg V hpt2 0 V 0 vpt2 V + hpt2 neg 0 V closepath stroke + Pnt} def +/Crs {stroke [] 0 setdash exch hpt sub exch vpt add M + hpt2 vpt2 neg V currentpoint stroke M + hpt2 neg 0 R hpt2 vpt2 V stroke} def +/TriU {stroke [] 0 setdash 2 copy vpt 1.12 mul add M + hpt neg vpt -1.62 mul V + hpt 2 mul 0 V + hpt neg vpt 1.62 mul V closepath stroke + Pnt} def +/Star {2 copy Pls Crs} def +/BoxF {stroke [] 0 setdash exch hpt sub exch vpt add M + 0 vpt2 neg V hpt2 0 V 0 vpt2 V + hpt2 neg 0 V closepath fill} def +/TriUF {stroke [] 0 setdash vpt 1.12 mul add M + hpt neg vpt -1.62 mul V + hpt 2 mul 0 V + hpt neg vpt 1.62 mul V closepath fill} def +/TriD {stroke [] 0 setdash 2 copy vpt 1.12 mul sub M + hpt neg vpt 1.62 mul V + hpt 2 mul 0 V + hpt neg vpt -1.62 mul V closepath stroke + Pnt} def +/TriDF {stroke [] 0 setdash vpt 1.12 mul sub M + hpt neg vpt 1.62 mul V + hpt 2 mul 0 V + hpt neg vpt -1.62 mul V closepath fill} def +/DiaF {stroke [] 0 setdash vpt add M + hpt neg vpt neg V hpt vpt neg V + hpt vpt V hpt neg vpt V closepath fill} def +/Pent {stroke [] 0 setdash 2 copy gsave + translate 0 hpt M 4 {72 rotate 0 hpt L} repeat + closepath stroke grestore Pnt} def +/PentF {stroke [] 0 setdash gsave + translate 0 hpt M 4 {72 rotate 0 hpt L} repeat + closepath fill grestore} def +/Circle {stroke [] 0 setdash 2 copy + hpt 0 360 arc stroke Pnt} def +/CircleF {stroke [] 0 setdash hpt 0 360 arc fill} def +/C0 {BL [] 0 setdash 2 copy moveto vpt 90 450 arc} bind def +/C1 {BL [] 0 setdash 2 copy moveto + 2 copy vpt 0 90 arc closepath fill + vpt 0 360 arc closepath} bind def +/C2 {BL [] 0 setdash 2 copy moveto + 2 copy vpt 90 180 arc closepath fill + vpt 0 360 arc closepath} bind def +/C3 {BL [] 0 setdash 2 copy moveto + 2 copy vpt 0 180 arc closepath fill + vpt 0 360 arc closepath} bind def +/C4 {BL [] 0 setdash 2 copy moveto + 2 copy vpt 180 270 arc closepath fill + vpt 0 360 arc closepath} bind def +/C5 {BL [] 0 setdash 2 copy moveto + 2 copy vpt 0 90 arc + 2 copy moveto + 2 copy vpt 180 270 arc closepath fill + vpt 0 360 arc} bind def +/C6 {BL [] 0 setdash 2 copy moveto + 2 copy vpt 90 270 arc closepath fill + vpt 0 360 arc closepath} bind def +/C7 {BL [] 0 setdash 2 copy moveto + 2 copy vpt 0 270 arc closepath fill + vpt 0 360 arc closepath} bind def +/C8 {BL [] 0 setdash 2 copy moveto + 2 copy vpt 270 360 arc closepath fill + vpt 0 360 arc closepath} bind def +/C9 {BL [] 0 setdash 2 copy moveto + 2 copy vpt 270 450 arc closepath fill + vpt 0 360 arc closepath} bind def +/C10 {BL [] 0 setdash 2 copy 2 copy moveto vpt 270 360 arc closepath fill + 2 copy moveto + 2 copy vpt 90 180 arc closepath fill + vpt 0 360 arc closepath} bind def +/C11 {BL [] 0 setdash 2 copy moveto + 2 copy vpt 0 180 arc closepath fill + 2 copy moveto + 2 copy vpt 270 360 arc closepath fill + vpt 0 360 arc closepath} bind def +/C12 {BL [] 0 setdash 2 copy moveto + 2 copy vpt 180 360 arc closepath fill + vpt 0 360 arc closepath} bind def +/C13 {BL [] 0 setdash 2 copy moveto + 2 copy vpt 0 90 arc closepath fill + 2 copy moveto + 2 copy vpt 180 360 arc closepath fill + vpt 0 360 arc closepath} bind def +/C14 {BL [] 0 setdash 2 copy moveto + 2 copy vpt 90 360 arc closepath fill + vpt 0 360 arc} bind def +/C15 {BL [] 0 setdash 2 copy vpt 0 360 arc closepath fill + vpt 0 360 arc closepath} bind def +/Rec {newpath 4 2 roll moveto 1 index 0 rlineto 0 exch rlineto + neg 0 rlineto closepath} bind def +/Square {dup Rec} bind def +/Bsquare {vpt sub exch vpt sub exch vpt2 Square} bind def +/S0 {BL [] 0 setdash 2 copy moveto 0 vpt rlineto BL Bsquare} bind def +/S1 {BL [] 0 setdash 2 copy vpt Square fill Bsquare} bind def +/S2 {BL [] 0 setdash 2 copy exch vpt sub exch vpt Square fill Bsquare} bind def +/S3 {BL [] 0 setdash 2 copy exch vpt sub exch vpt2 vpt Rec fill Bsquare} bind def +/S4 {BL [] 0 setdash 2 copy exch vpt sub exch vpt sub vpt Square fill Bsquare} bind def +/S5 {BL [] 0 setdash 2 copy 2 copy vpt Square fill + exch vpt sub exch vpt sub vpt Square fill Bsquare} bind def +/S6 {BL [] 0 setdash 2 copy exch vpt sub exch vpt sub vpt vpt2 Rec fill Bsquare} bind def +/S7 {BL [] 0 setdash 2 copy exch vpt sub exch vpt sub vpt vpt2 Rec fill + 2 copy vpt Square fill Bsquare} bind def +/S8 {BL [] 0 setdash 2 copy vpt sub vpt Square fill Bsquare} bind def +/S9 {BL [] 0 setdash 2 copy vpt sub vpt vpt2 Rec fill Bsquare} bind def +/S10 {BL [] 0 setdash 2 copy vpt sub vpt Square fill 2 copy exch vpt sub exch vpt Square fill + Bsquare} bind def +/S11 {BL [] 0 setdash 2 copy vpt sub vpt Square fill 2 copy exch vpt sub exch vpt2 vpt Rec fill + Bsquare} bind def +/S12 {BL [] 0 setdash 2 copy exch vpt sub exch vpt sub vpt2 vpt Rec fill Bsquare} bind def +/S13 {BL [] 0 setdash 2 copy exch vpt sub exch vpt sub vpt2 vpt Rec fill + 2 copy vpt Square fill Bsquare} bind def +/S14 {BL [] 0 setdash 2 copy exch vpt sub exch vpt sub vpt2 vpt Rec fill + 2 copy exch vpt sub exch vpt Square fill Bsquare} bind def +/S15 {BL [] 0 setdash 2 copy Bsquare fill Bsquare} bind def +/D0 {gsave translate 45 rotate 0 0 S0 stroke grestore} bind def +/D1 {gsave translate 45 rotate 0 0 S1 stroke grestore} bind def +/D2 {gsave translate 45 rotate 0 0 S2 stroke grestore} bind def +/D3 {gsave translate 45 rotate 0 0 S3 stroke grestore} bind def +/D4 {gsave translate 45 rotate 0 0 S4 stroke grestore} bind def +/D5 {gsave translate 45 rotate 0 0 S5 stroke grestore} bind def +/D6 {gsave translate 45 rotate 0 0 S6 stroke grestore} bind def +/D7 {gsave translate 45 rotate 0 0 S7 stroke grestore} bind def +/D8 {gsave translate 45 rotate 0 0 S8 stroke grestore} bind def +/D9 {gsave translate 45 rotate 0 0 S9 stroke grestore} bind def +/D10 {gsave translate 45 rotate 0 0 S10 stroke grestore} bind def +/D11 {gsave translate 45 rotate 0 0 S11 stroke grestore} bind def +/D12 {gsave translate 45 rotate 0 0 S12 stroke grestore} bind def +/D13 {gsave translate 45 rotate 0 0 S13 stroke grestore} bind def +/D14 {gsave translate 45 rotate 0 0 S14 stroke grestore} bind def +/D15 {gsave translate 45 rotate 0 0 S15 stroke grestore} bind def +/DiaE {stroke [] 0 setdash vpt add M + hpt neg vpt neg V hpt vpt neg V + hpt vpt V hpt neg vpt V closepath stroke} def +/BoxE {stroke [] 0 setdash exch hpt sub exch vpt add M + 0 vpt2 neg V hpt2 0 V 0 vpt2 V + hpt2 neg 0 V closepath stroke} def +/TriUE {stroke [] 0 setdash vpt 1.12 mul add M + hpt neg vpt -1.62 mul V + hpt 2 mul 0 V + hpt neg vpt 1.62 mul V closepath stroke} def +/TriDE {stroke [] 0 setdash vpt 1.12 mul sub M + hpt neg vpt 1.62 mul V + hpt 2 mul 0 V + hpt neg vpt -1.62 mul V closepath stroke} def +/PentE {stroke [] 0 setdash gsave + translate 0 hpt M 4 {72 rotate 0 hpt L} repeat + closepath stroke grestore} def +/CircE {stroke [] 0 setdash + hpt 0 360 arc stroke} def +/Opaque {gsave closepath 1 setgray fill grestore 0 setgray closepath} def +/DiaW {stroke [] 0 setdash vpt add M + hpt neg vpt neg V hpt vpt neg V + hpt vpt V hpt neg vpt V Opaque stroke} def +/BoxW {stroke [] 0 setdash exch hpt sub exch vpt add M + 0 vpt2 neg V hpt2 0 V 0 vpt2 V + hpt2 neg 0 V Opaque stroke} def +/TriUW {stroke [] 0 setdash vpt 1.12 mul add M + hpt neg vpt -1.62 mul V + hpt 2 mul 0 V + hpt neg vpt 1.62 mul V Opaque stroke} def +/TriDW {stroke [] 0 setdash vpt 1.12 mul sub M + hpt neg vpt 1.62 mul V + hpt 2 mul 0 V + hpt neg vpt -1.62 mul V Opaque stroke} def +/PentW {stroke [] 0 setdash gsave + translate 0 hpt M 4 {72 rotate 0 hpt L} repeat + Opaque stroke grestore} def +/CircW {stroke [] 0 setdash + hpt 0 360 arc Opaque stroke} def +/BoxFill {gsave Rec 1 setgray fill grestore} def +/Density { + /Fillden exch def + currentrgbcolor + /ColB exch def /ColG exch def /ColR exch def + /ColR ColR Fillden mul Fillden sub 1 add def + /ColG ColG Fillden mul Fillden sub 1 add def + /ColB ColB Fillden mul Fillden sub 1 add def + ColR ColG ColB setrgbcolor} def +/BoxColFill {gsave Rec PolyFill} def +/PolyFill {gsave Density fill grestore grestore} def +/h {rlineto rlineto rlineto gsave closepath fill grestore} bind def +% +% PostScript Level 1 Pattern Fill routine for rectangles +% Usage: x y w h s a XX PatternFill +% x,y = lower left corner of box to be filled +% w,h = width and height of box +% a = angle in degrees between lines and x-axis +% XX = 0/1 for no/yes cross-hatch +% +/PatternFill {gsave /PFa [ 9 2 roll ] def + PFa 0 get PFa 2 get 2 div add PFa 1 get PFa 3 get 2 div add translate + PFa 2 get -2 div PFa 3 get -2 div PFa 2 get PFa 3 get Rec + gsave 1 setgray fill grestore clip + currentlinewidth 0.5 mul setlinewidth + /PFs PFa 2 get dup mul PFa 3 get dup mul add sqrt def + 0 0 M PFa 5 get rotate PFs -2 div dup translate + 0 1 PFs PFa 4 get div 1 add floor cvi + {PFa 4 get mul 0 M 0 PFs V} for + 0 PFa 6 get ne { + 0 1 PFs PFa 4 get div 1 add floor cvi + {PFa 4 get mul 0 2 1 roll M PFs 0 V} for + } if + stroke grestore} def +% +/languagelevel where + {pop languagelevel} {1} ifelse + 2 lt + {/InterpretLevel1 true def} + {/InterpretLevel1 Level1 def} + ifelse +% +% PostScript level 2 pattern fill definitions +% +/Level2PatternFill { +/Tile8x8 {/PaintType 2 /PatternType 1 /TilingType 1 /BBox [0 0 8 8] /XStep 8 /YStep 8} + bind def +/KeepColor {currentrgbcolor [/Pattern /DeviceRGB] setcolorspace} bind def +<< Tile8x8 + /PaintProc {0.5 setlinewidth pop 0 0 M 8 8 L 0 8 M 8 0 L stroke} +>> matrix makepattern +/Pat1 exch def +<< Tile8x8 + /PaintProc {0.5 setlinewidth pop 0 0 M 8 8 L 0 8 M 8 0 L stroke + 0 4 M 4 8 L 8 4 L 4 0 L 0 4 L stroke} +>> matrix makepattern +/Pat2 exch def +<< Tile8x8 + /PaintProc {0.5 setlinewidth pop 0 0 M 0 8 L + 8 8 L 8 0 L 0 0 L fill} +>> matrix makepattern +/Pat3 exch def +<< Tile8x8 + /PaintProc {0.5 setlinewidth pop -4 8 M 8 -4 L + 0 12 M 12 0 L stroke} +>> matrix makepattern +/Pat4 exch def +<< Tile8x8 + /PaintProc {0.5 setlinewidth pop -4 0 M 8 12 L + 0 -4 M 12 8 L stroke} +>> matrix makepattern +/Pat5 exch def +<< Tile8x8 + /PaintProc {0.5 setlinewidth pop -2 8 M 4 -4 L + 0 12 M 8 -4 L 4 12 M 10 0 L stroke} +>> matrix makepattern +/Pat6 exch def +<< Tile8x8 + /PaintProc {0.5 setlinewidth pop -2 0 M 4 12 L + 0 -4 M 8 12 L 4 -4 M 10 8 L stroke} +>> matrix makepattern +/Pat7 exch def +<< Tile8x8 + /PaintProc {0.5 setlinewidth pop 8 -2 M -4 4 L + 12 0 M -4 8 L 12 4 M 0 10 L stroke} +>> matrix makepattern +/Pat8 exch def +<< Tile8x8 + /PaintProc {0.5 setlinewidth pop 0 -2 M 12 4 L + -4 0 M 12 8 L -4 4 M 8 10 L stroke} +>> matrix makepattern +/Pat9 exch def +/Pattern1 {PatternBgnd KeepColor Pat1 setpattern} bind def +/Pattern2 {PatternBgnd KeepColor Pat2 setpattern} bind def +/Pattern3 {PatternBgnd KeepColor Pat3 setpattern} bind def +/Pattern4 {PatternBgnd KeepColor Landscape {Pat5} {Pat4} ifelse setpattern} bind def +/Pattern5 {PatternBgnd KeepColor Landscape {Pat4} {Pat5} ifelse setpattern} bind def +/Pattern6 {PatternBgnd KeepColor Landscape {Pat9} {Pat6} ifelse setpattern} bind def +/Pattern7 {PatternBgnd KeepColor Landscape {Pat8} {Pat7} ifelse setpattern} bind def +} def +% +% +%End of PostScript Level 2 code +% +/PatternBgnd { + TransparentPatterns {} {gsave 1 setgray fill grestore} ifelse +} def +% +% Substitute for Level 2 pattern fill codes with +% grayscale if Level 2 support is not selected. +% +/Level1PatternFill { +/Pattern1 {0.250 Density} bind def +/Pattern2 {0.500 Density} bind def +/Pattern3 {0.750 Density} bind def +/Pattern4 {0.125 Density} bind def +/Pattern5 {0.375 Density} bind def +/Pattern6 {0.625 Density} bind def +/Pattern7 {0.875 Density} bind def +} def +% +% Now test for support of Level 2 code +% +Level1 {Level1PatternFill} {Level2PatternFill} ifelse +% +/Symbol-Oblique /Symbol findfont [1 0 .167 1 0 0] makefont +dup length dict begin {1 index /FID eq {pop pop} {def} ifelse} forall +currentdict end definefont pop +/MFshow { + { dup 5 get 3 ge + { 5 get 3 eq {gsave} {grestore} ifelse } + {dup dup 0 get findfont exch 1 get scalefont setfont + [ currentpoint ] exch dup 2 get 0 exch R dup 5 get 2 ne {dup dup 6 + get exch 4 get {Gshow} {stringwidth pop 0 R} ifelse }if dup 5 get 0 eq + {dup 3 get {2 get neg 0 exch R pop} {pop aload pop M} ifelse} {dup 5 + get 1 eq {dup 2 get exch dup 3 get exch 6 get stringwidth pop -2 div + dup 0 R} {dup 6 get stringwidth pop -2 div 0 R 6 get + show 2 index {aload pop M neg 3 -1 roll neg R pop pop} {pop pop pop + pop aload pop M} ifelse }ifelse }ifelse } + ifelse } + forall} def +/Gswidth {dup type /stringtype eq {stringwidth} {pop (n) stringwidth} ifelse} def +/MFwidth {0 exch { dup 5 get 3 ge { 5 get 3 eq { 0 } { pop } ifelse } + {dup 3 get{dup dup 0 get findfont exch 1 get scalefont setfont + 6 get Gswidth pop add} {pop} ifelse} ifelse} forall} def +/MLshow { currentpoint stroke M + 0 exch R + Blacktext {gsave 0 setgray MFshow grestore} {MFshow} ifelse } bind def +/MRshow { currentpoint stroke M + exch dup MFwidth neg 3 -1 roll R + Blacktext {gsave 0 setgray MFshow grestore} {MFshow} ifelse } bind def +/MCshow { currentpoint stroke M + exch dup MFwidth -2 div 3 -1 roll R + Blacktext {gsave 0 setgray MFshow grestore} {MFshow} ifelse } bind def +/XYsave { [( ) 1 2 true false 3 ()] } bind def +/XYrestore { [( ) 1 2 true false 4 ()] } bind def +end +%%EndProlog +%%Page: 1 1 +gnudict begin +gsave +doclip +50 50 translate +0.100 0.100 scale +90 rotate +0 -5040 translate +0 setgray +newpath +(Helvetica) findfont 140 scalefont setfont +1.000 UL +LTb +518 448 M +63 0 V +stroke +434 448 M +[ [(Helvetica) 140.0 0.0 true true 0 ( 1)] +] -46.7 MRshow +1.000 UL +LTb +518 792 M +63 0 V +stroke +434 792 M +[ [(Helvetica) 140.0 0.0 true true 0 ( 2)] +] -46.7 MRshow +1.000 UL +LTb +518 1136 M +63 0 V +stroke +434 1136 M +[ [(Helvetica) 140.0 0.0 true true 0 ( 3)] +] -46.7 MRshow +1.000 UL +LTb +518 1480 M +63 0 V +stroke +434 1480 M +[ [(Helvetica) 140.0 0.0 true true 0 ( 4)] +] -46.7 MRshow +1.000 UL +LTb +518 1823 M +63 0 V +stroke +434 1823 M +[ [(Helvetica) 140.0 0.0 true true 0 ( 5)] +] -46.7 MRshow +1.000 UL +LTb +518 2167 M +63 0 V +stroke +434 2167 M +[ [(Helvetica) 140.0 0.0 true true 0 ( 6)] +] -46.7 MRshow +1.000 UL +LTb +518 2511 M +63 0 V +stroke +434 2511 M +[ [(Helvetica) 140.0 0.0 true true 0 ( 7)] +] -46.7 MRshow +1.000 UL +LTb +518 2855 M +63 0 V +stroke +434 2855 M +[ [(Helvetica) 140.0 0.0 true true 0 ( 8)] +] -46.7 MRshow +1.000 UL +LTb +518 448 M +0 63 V +stroke +518 308 M +[ [(Helvetica) 140.0 0.0 true true 0 ( 0)] +] -46.7 MCshow +1.000 UL +LTb +962 448 M +0 63 V +stroke +962 308 M +[ [(Helvetica) 140.0 0.0 true true 0 ( 1000)] +] -46.7 MCshow +1.000 UL +LTb +1405 448 M +0 63 V +stroke +1405 308 M +[ [(Helvetica) 140.0 0.0 true true 0 ( 2000)] +] -46.7 MCshow +1.000 UL +LTb +1849 448 M +0 63 V +stroke +1849 308 M +[ [(Helvetica) 140.0 0.0 true true 0 ( 3000)] +] -46.7 MCshow +1.000 UL +LTb +2293 448 M +0 63 V +stroke +2293 308 M +[ [(Helvetica) 140.0 0.0 true true 0 ( 4000)] +] -46.7 MCshow +1.000 UL +LTb +2736 448 M +0 63 V +stroke +2736 308 M +[ [(Helvetica) 140.0 0.0 true true 0 ( 5000)] +] -46.7 MCshow +1.000 UL +LTb +3180 448 M +0 63 V +stroke +3180 308 M +[ [(Helvetica) 140.0 0.0 true true 0 ( 6000)] +] -46.7 MCshow +1.000 UL +LTb +3623 448 M +0 63 V +stroke +3623 308 M +[ [(Helvetica) 140.0 0.0 true true 0 ( 7000)] +] -46.7 MCshow +1.000 UL +LTb +4067 448 M +0 63 V +stroke +4067 308 M +[ [(Helvetica) 140.0 0.0 true true 0 ( 8000)] +] -46.7 MCshow +1.000 UL +LTb +1.000 UL +LTb +518 2855 M +518 448 L +3549 0 V +0 2407 R +-3549 0 R +stroke +LCb setrgbcolor +112 1651 M +currentpoint gsave translate -270 rotate 0 0 moveto +[ [(Helvetica) 140.0 0.0 true true 0 (Ratio of Total Execution to Total Work)] +] -46.7 MCshow +grestore +LTb +LCb setrgbcolor +2292 98 M +[ [(Helvetica) 140.0 0.0 true true 0 (Cycles in one Task)] +] -46.7 MCshow +LTb +1.000 UP +1.000 UL +LTb +1.000 UL +LTb +2492 2232 N +0 560 V +1491 0 V +0 -560 V +-1491 0 V +Z stroke +2492 2792 M +1491 0 V +% Begin plot #1 +stroke +4.000 UL +LT1 +LCa setrgbcolor +518 792 M +36 0 V +36 0 V +36 0 V +35 0 V +36 0 V +36 0 V +36 0 V +36 0 V +36 0 V +35 0 V +36 0 V +36 0 V +36 0 V +36 0 V +36 0 V +36 0 V +35 0 V +36 0 V +36 0 V +36 0 V +36 0 V +36 0 V +36 0 V +35 0 V +36 0 V +36 0 V +36 0 V +36 0 V +36 0 V +35 0 V +36 0 V +36 0 V +36 0 V +36 0 V +36 0 V +36 0 V +35 0 V +36 0 V +36 0 V +36 0 V +36 0 V +36 0 V +35 0 V +36 0 V +36 0 V +36 0 V +36 0 V +36 0 V +36 0 V +35 0 V +36 0 V +36 0 V +36 0 V +36 0 V +36 0 V +36 0 V +35 0 V +36 0 V +36 0 V +36 0 V +36 0 V +36 0 V +35 0 V +36 0 V +36 0 V +36 0 V +36 0 V +36 0 V +36 0 V +35 0 V +36 0 V +36 0 V +36 0 V +36 0 V +36 0 V +35 0 V +36 0 V +36 0 V +36 0 V +36 0 V +36 0 V +36 0 V +35 0 V +36 0 V +36 0 V +36 0 V +36 0 V +36 0 V +36 0 V +35 0 V +36 0 V +36 0 V +36 0 V +36 0 V +36 0 V +35 0 V +36 0 V +36 0 V +36 0 V +% End plot #1 +% Begin plot #2 +stroke +LT1 +LCb setrgbcolor +3416 2722 M +[ [(Helvetica) 140.0 0.0 true true 0 (80 Threads)] +] -46.7 MRshow +LT1 +3500 2722 M +399 0 V +670 2855 M +51 -852 V +882 1405 L +1200 930 L +1839 705 L +3118 625 L +949 -39 V +% End plot #2 +% Begin plot #3 +stroke +LT2 +LCb setrgbcolor +3416 2582 M +[ [(Helvetica) 140.0 0.0 true true 0 (160 Threads)] +] -46.7 MRshow +LT2 +3500 2582 M +399 0 V +632 2855 M +8 -651 V +80 -714 V +881 1280 L +1200 856 L +1839 682 L +3116 544 L +951 -19 V +% End plot #3 +% Begin plot #4 +stroke +LT3 +LCb setrgbcolor +3416 2442 M +[ [(Helvetica) 140.0 0.0 true true 0 (320 Threads)] +] -46.7 MRshow +LT3 +3500 2442 M +399 0 V +678 2855 M +45 -823 V +882 1374 L +1200 997 L +1840 716 L +3117 544 L +950 -16 V +% End plot #4 +% Begin plot #5 +stroke +LT4 +LCb setrgbcolor +3416 2302 M +[ [(Helvetica) 140.0 0.0 true true 0 (640 Threads)] +] -46.7 MRshow +LT4 +3500 2302 M +399 0 V +656 2855 M +67 -607 V +881 1260 L +1200 822 L +1840 687 L +3117 564 L +950 -21 V +% End plot #5 +stroke +1.000 UL +LTb +518 2855 M +518 448 L +3549 0 V +0 2407 R +-3549 0 R +1.000 UP +stroke +grestore +end +showpage +%%Trailer +%%DocumentFonts: Helvetica +%%Pages: 1 diff -r 9b9a2497757d -r eb146c5c05a8 0__Papers/PRT/PRT__formal_def/figures/plots_exec_vs_task_size/not_used/xoanon_vthread_80cores_80_160_320_640thds__o30000__perfCtrs.result.eps --- /dev/null Thu Jan 01 00:00:00 1970 +0000 +++ b/0__Papers/PRT/PRT__formal_def/figures/plots_exec_vs_task_size/not_used/xoanon_vthread_80cores_80_160_320_640thds__o30000__perfCtrs.result.eps Sat Aug 03 19:24:22 2013 -0700 @@ -0,0 +1,821 @@ +%!PS-Adobe-2.0 +%%Title: xoanon_vthread_80cores_80_160_320_640thds__o30000__perfCtrs.result.eps +%%Creator: gnuplot 4.4 patchlevel 2 +%%CreationDate: Thu Jan 26 18:25:10 2012 +%%DocumentFonts: (atend) +%%BoundingBox: 251 50 554 482 +%%Orientation: Landscape +%%Pages: (atend) +%%EndComments +%%BeginProlog +/gnudict 256 dict def +gnudict begin +% +% The following true/false flags may be edited by hand if desired. +% The unit line width and grayscale image gamma correction may also be changed. +% +/Color true def +/Blacktext false def +/Solid false def +/Dashlength 1 def +/Landscape true def +/Level1 false def +/Rounded false def +/ClipToBoundingBox false def +/TransparentPatterns false def +/gnulinewidth 5.000 def +/userlinewidth gnulinewidth def +/Gamma 1.0 def +% +/vshift -46 def +/dl1 { + 10.0 Dashlength mul mul + Rounded { currentlinewidth 0.75 mul sub dup 0 le { pop 0.01 } if } if +} def +/dl2 { + 10.0 Dashlength mul mul + Rounded { currentlinewidth 0.75 mul add } if +} def +/hpt_ 31.5 def +/vpt_ 31.5 def +/hpt hpt_ def +/vpt vpt_ def +Level1 {} { +/SDict 10 dict def +systemdict /pdfmark known not { + userdict /pdfmark systemdict /cleartomark get put +} if +SDict begin [ + /Title (xoanon_vthread_80cores_80_160_320_640thds__o30000__perfCtrs.result.eps) + /Subject (gnuplot plot) + /Creator (gnuplot 4.4 patchlevel 2) + /Author (msach) +% /Producer (gnuplot) +% /Keywords () + /CreationDate (Thu Jan 26 18:25:10 2012) + /DOCINFO pdfmark +end +} ifelse +/doclip { + ClipToBoundingBox { + newpath 251 50 moveto 554 50 lineto 554 482 lineto 251 482 lineto closepath + clip + } if +} def +% +% Gnuplot Prolog Version 4.4 (August 2010) +% +%/SuppressPDFMark true def +% +/M {moveto} bind def +/L {lineto} bind def +/R {rmoveto} bind def +/V {rlineto} bind def +/N {newpath moveto} bind def +/Z {closepath} bind def +/C {setrgbcolor} bind def +/f {rlineto fill} bind def +/g {setgray} bind def +/Gshow {show} def % May be redefined later in the file to support UTF-8 +/vpt2 vpt 2 mul def +/hpt2 hpt 2 mul def +/Lshow {currentpoint stroke M 0 vshift R + Blacktext {gsave 0 setgray show grestore} {show} ifelse} def +/Rshow {currentpoint stroke M dup stringwidth pop neg vshift R + Blacktext {gsave 0 setgray show grestore} {show} ifelse} def +/Cshow {currentpoint stroke M dup stringwidth pop -2 div vshift R + Blacktext {gsave 0 setgray show grestore} {show} ifelse} def +/UP {dup vpt_ mul /vpt exch def hpt_ mul /hpt exch def + /hpt2 hpt 2 mul def /vpt2 vpt 2 mul def} def +/DL {Color {setrgbcolor Solid {pop []} if 0 setdash} + {pop pop pop 0 setgray Solid {pop []} if 0 setdash} ifelse} def +/BL {stroke userlinewidth 2 mul setlinewidth + Rounded {1 setlinejoin 1 setlinecap} if} def +/AL {stroke userlinewidth 2 div setlinewidth + Rounded {1 setlinejoin 1 setlinecap} if} def +/UL {dup gnulinewidth mul /userlinewidth exch def + dup 1 lt {pop 1} if 10 mul /udl exch def} def +/PL {stroke userlinewidth setlinewidth + Rounded {1 setlinejoin 1 setlinecap} if} def +3.8 setmiterlimit +% Default Line colors +/LCw {1 1 1} def +/LCb {0 0 0} def +/LCa {0 0 0} def +/LC0 {1 0 0} def +/LC1 {0 1 0} def +/LC2 {0 0 1} def +/LC3 {1 0 1} def +/LC4 {0 1 1} def +/LC5 {1 1 0} def +/LC6 {0 0 0} def +/LC7 {1 0.3 0} def +/LC8 {0.5 0.5 0.5} def +% Default Line Types +/LTw {PL [] 1 setgray} def +/LTb {BL [] LCb DL} def +/LTa {AL [1 udl mul 2 udl mul] 0 setdash LCa setrgbcolor} def +/LT0 {PL [] LC0 DL} def +/LT1 {PL [4 dl1 2 dl2] LC1 DL} def +/LT2 {PL [2 dl1 3 dl2] LC2 DL} def +/LT3 {PL [1 dl1 1.5 dl2] LC3 DL} def +/LT4 {PL [6 dl1 2 dl2 1 dl1 2 dl2] LC4 DL} def +/LT5 {PL [3 dl1 3 dl2 1 dl1 3 dl2] LC5 DL} def +/LT6 {PL [2 dl1 2 dl2 2 dl1 6 dl2] LC6 DL} def +/LT7 {PL [1 dl1 2 dl2 6 dl1 2 dl2 1 dl1 2 dl2] LC7 DL} def +/LT8 {PL [2 dl1 2 dl2 2 dl1 2 dl2 2 dl1 2 dl2 2 dl1 4 dl2] LC8 DL} def +/Pnt {stroke [] 0 setdash gsave 1 setlinecap M 0 0 V stroke grestore} def +/Dia {stroke [] 0 setdash 2 copy vpt add M + hpt neg vpt neg V hpt vpt neg V + hpt vpt V hpt neg vpt V closepath stroke + Pnt} def +/Pls {stroke [] 0 setdash vpt sub M 0 vpt2 V + currentpoint stroke M + hpt neg vpt neg R hpt2 0 V stroke + } def +/Box {stroke [] 0 setdash 2 copy exch hpt sub exch vpt add M + 0 vpt2 neg V hpt2 0 V 0 vpt2 V + hpt2 neg 0 V closepath stroke + Pnt} def +/Crs {stroke [] 0 setdash exch hpt sub exch vpt add M + hpt2 vpt2 neg V currentpoint stroke M + hpt2 neg 0 R hpt2 vpt2 V stroke} def +/TriU {stroke [] 0 setdash 2 copy vpt 1.12 mul add M + hpt neg vpt -1.62 mul V + hpt 2 mul 0 V + hpt neg vpt 1.62 mul V closepath stroke + Pnt} def +/Star {2 copy Pls Crs} def +/BoxF {stroke [] 0 setdash exch hpt sub exch vpt add M + 0 vpt2 neg V hpt2 0 V 0 vpt2 V + hpt2 neg 0 V closepath fill} def +/TriUF {stroke [] 0 setdash vpt 1.12 mul add M + hpt neg vpt -1.62 mul V + hpt 2 mul 0 V + hpt neg vpt 1.62 mul V closepath fill} def +/TriD {stroke [] 0 setdash 2 copy vpt 1.12 mul sub M + hpt neg vpt 1.62 mul V + hpt 2 mul 0 V + hpt neg vpt -1.62 mul V closepath stroke + Pnt} def +/TriDF {stroke [] 0 setdash vpt 1.12 mul sub M + hpt neg vpt 1.62 mul V + hpt 2 mul 0 V + hpt neg vpt -1.62 mul V closepath fill} def +/DiaF {stroke [] 0 setdash vpt add M + hpt neg vpt neg V hpt vpt neg V + hpt vpt V hpt neg vpt V closepath fill} def +/Pent {stroke [] 0 setdash 2 copy gsave + translate 0 hpt M 4 {72 rotate 0 hpt L} repeat + closepath stroke grestore Pnt} def +/PentF {stroke [] 0 setdash gsave + translate 0 hpt M 4 {72 rotate 0 hpt L} repeat + closepath fill grestore} def +/Circle {stroke [] 0 setdash 2 copy + hpt 0 360 arc stroke Pnt} def +/CircleF {stroke [] 0 setdash hpt 0 360 arc fill} def +/C0 {BL [] 0 setdash 2 copy moveto vpt 90 450 arc} bind def +/C1 {BL [] 0 setdash 2 copy moveto + 2 copy vpt 0 90 arc closepath fill + vpt 0 360 arc closepath} bind def +/C2 {BL [] 0 setdash 2 copy moveto + 2 copy vpt 90 180 arc closepath fill + vpt 0 360 arc closepath} bind def +/C3 {BL [] 0 setdash 2 copy moveto + 2 copy vpt 0 180 arc closepath fill + vpt 0 360 arc closepath} bind def +/C4 {BL [] 0 setdash 2 copy moveto + 2 copy vpt 180 270 arc closepath fill + vpt 0 360 arc closepath} bind def +/C5 {BL [] 0 setdash 2 copy moveto + 2 copy vpt 0 90 arc + 2 copy moveto + 2 copy vpt 180 270 arc closepath fill + vpt 0 360 arc} bind def +/C6 {BL [] 0 setdash 2 copy moveto + 2 copy vpt 90 270 arc closepath fill + vpt 0 360 arc closepath} bind def +/C7 {BL [] 0 setdash 2 copy moveto + 2 copy vpt 0 270 arc closepath fill + vpt 0 360 arc closepath} bind def +/C8 {BL [] 0 setdash 2 copy moveto + 2 copy vpt 270 360 arc closepath fill + vpt 0 360 arc closepath} bind def +/C9 {BL [] 0 setdash 2 copy moveto + 2 copy vpt 270 450 arc closepath fill + vpt 0 360 arc closepath} bind def +/C10 {BL [] 0 setdash 2 copy 2 copy moveto vpt 270 360 arc closepath fill + 2 copy moveto + 2 copy vpt 90 180 arc closepath fill + vpt 0 360 arc closepath} bind def +/C11 {BL [] 0 setdash 2 copy moveto + 2 copy vpt 0 180 arc closepath fill + 2 copy moveto + 2 copy vpt 270 360 arc closepath fill + vpt 0 360 arc closepath} bind def +/C12 {BL [] 0 setdash 2 copy moveto + 2 copy vpt 180 360 arc closepath fill + vpt 0 360 arc closepath} bind def +/C13 {BL [] 0 setdash 2 copy moveto + 2 copy vpt 0 90 arc closepath fill + 2 copy moveto + 2 copy vpt 180 360 arc closepath fill + vpt 0 360 arc closepath} bind def +/C14 {BL [] 0 setdash 2 copy moveto + 2 copy vpt 90 360 arc closepath fill + vpt 0 360 arc} bind def +/C15 {BL [] 0 setdash 2 copy vpt 0 360 arc closepath fill + vpt 0 360 arc closepath} bind def +/Rec {newpath 4 2 roll moveto 1 index 0 rlineto 0 exch rlineto + neg 0 rlineto closepath} bind def +/Square {dup Rec} bind def +/Bsquare {vpt sub exch vpt sub exch vpt2 Square} bind def +/S0 {BL [] 0 setdash 2 copy moveto 0 vpt rlineto BL Bsquare} bind def +/S1 {BL [] 0 setdash 2 copy vpt Square fill Bsquare} bind def +/S2 {BL [] 0 setdash 2 copy exch vpt sub exch vpt Square fill Bsquare} bind def +/S3 {BL [] 0 setdash 2 copy exch vpt sub exch vpt2 vpt Rec fill Bsquare} bind def +/S4 {BL [] 0 setdash 2 copy exch vpt sub exch vpt sub vpt Square fill Bsquare} bind def +/S5 {BL [] 0 setdash 2 copy 2 copy vpt Square fill + exch vpt sub exch vpt sub vpt Square fill Bsquare} bind def +/S6 {BL [] 0 setdash 2 copy exch vpt sub exch vpt sub vpt vpt2 Rec fill Bsquare} bind def +/S7 {BL [] 0 setdash 2 copy exch vpt sub exch vpt sub vpt vpt2 Rec fill + 2 copy vpt Square fill Bsquare} bind def +/S8 {BL [] 0 setdash 2 copy vpt sub vpt Square fill Bsquare} bind def +/S9 {BL [] 0 setdash 2 copy vpt sub vpt vpt2 Rec fill Bsquare} bind def +/S10 {BL [] 0 setdash 2 copy vpt sub vpt Square fill 2 copy exch vpt sub exch vpt Square fill + Bsquare} bind def +/S11 {BL [] 0 setdash 2 copy vpt sub vpt Square fill 2 copy exch vpt sub exch vpt2 vpt Rec fill + Bsquare} bind def +/S12 {BL [] 0 setdash 2 copy exch vpt sub exch vpt sub vpt2 vpt Rec fill Bsquare} bind def +/S13 {BL [] 0 setdash 2 copy exch vpt sub exch vpt sub vpt2 vpt Rec fill + 2 copy vpt Square fill Bsquare} bind def +/S14 {BL [] 0 setdash 2 copy exch vpt sub exch vpt sub vpt2 vpt Rec fill + 2 copy exch vpt sub exch vpt Square fill Bsquare} bind def +/S15 {BL [] 0 setdash 2 copy Bsquare fill Bsquare} bind def +/D0 {gsave translate 45 rotate 0 0 S0 stroke grestore} bind def +/D1 {gsave translate 45 rotate 0 0 S1 stroke grestore} bind def +/D2 {gsave translate 45 rotate 0 0 S2 stroke grestore} bind def +/D3 {gsave translate 45 rotate 0 0 S3 stroke grestore} bind def +/D4 {gsave translate 45 rotate 0 0 S4 stroke grestore} bind def +/D5 {gsave translate 45 rotate 0 0 S5 stroke grestore} bind def +/D6 {gsave translate 45 rotate 0 0 S6 stroke grestore} bind def +/D7 {gsave translate 45 rotate 0 0 S7 stroke grestore} bind def +/D8 {gsave translate 45 rotate 0 0 S8 stroke grestore} bind def +/D9 {gsave translate 45 rotate 0 0 S9 stroke grestore} bind def +/D10 {gsave translate 45 rotate 0 0 S10 stroke grestore} bind def +/D11 {gsave translate 45 rotate 0 0 S11 stroke grestore} bind def +/D12 {gsave translate 45 rotate 0 0 S12 stroke grestore} bind def +/D13 {gsave translate 45 rotate 0 0 S13 stroke grestore} bind def +/D14 {gsave translate 45 rotate 0 0 S14 stroke grestore} bind def +/D15 {gsave translate 45 rotate 0 0 S15 stroke grestore} bind def +/DiaE {stroke [] 0 setdash vpt add M + hpt neg vpt neg V hpt vpt neg V + hpt vpt V hpt neg vpt V closepath stroke} def +/BoxE {stroke [] 0 setdash exch hpt sub exch vpt add M + 0 vpt2 neg V hpt2 0 V 0 vpt2 V + hpt2 neg 0 V closepath stroke} def +/TriUE {stroke [] 0 setdash vpt 1.12 mul add M + hpt neg vpt -1.62 mul V + hpt 2 mul 0 V + hpt neg vpt 1.62 mul V closepath stroke} def +/TriDE {stroke [] 0 setdash vpt 1.12 mul sub M + hpt neg vpt 1.62 mul V + hpt 2 mul 0 V + hpt neg vpt -1.62 mul V closepath stroke} def +/PentE {stroke [] 0 setdash gsave + translate 0 hpt M 4 {72 rotate 0 hpt L} repeat + closepath stroke grestore} def +/CircE {stroke [] 0 setdash + hpt 0 360 arc stroke} def +/Opaque {gsave closepath 1 setgray fill grestore 0 setgray closepath} def +/DiaW {stroke [] 0 setdash vpt add M + hpt neg vpt neg V hpt vpt neg V + hpt vpt V hpt neg vpt V Opaque stroke} def +/BoxW {stroke [] 0 setdash exch hpt sub exch vpt add M + 0 vpt2 neg V hpt2 0 V 0 vpt2 V + hpt2 neg 0 V Opaque stroke} def +/TriUW {stroke [] 0 setdash vpt 1.12 mul add M + hpt neg vpt -1.62 mul V + hpt 2 mul 0 V + hpt neg vpt 1.62 mul V Opaque stroke} def +/TriDW {stroke [] 0 setdash vpt 1.12 mul sub M + hpt neg vpt 1.62 mul V + hpt 2 mul 0 V + hpt neg vpt -1.62 mul V Opaque stroke} def +/PentW {stroke [] 0 setdash gsave + translate 0 hpt M 4 {72 rotate 0 hpt L} repeat + Opaque stroke grestore} def +/CircW {stroke [] 0 setdash + hpt 0 360 arc Opaque stroke} def +/BoxFill {gsave Rec 1 setgray fill grestore} def +/Density { + /Fillden exch def + currentrgbcolor + /ColB exch def /ColG exch def /ColR exch def + /ColR ColR Fillden mul Fillden sub 1 add def + /ColG ColG Fillden mul Fillden sub 1 add def + /ColB ColB Fillden mul Fillden sub 1 add def + ColR ColG ColB setrgbcolor} def +/BoxColFill {gsave Rec PolyFill} def +/PolyFill {gsave Density fill grestore grestore} def +/h {rlineto rlineto rlineto gsave closepath fill grestore} bind def +% +% PostScript Level 1 Pattern Fill routine for rectangles +% Usage: x y w h s a XX PatternFill +% x,y = lower left corner of box to be filled +% w,h = width and height of box +% a = angle in degrees between lines and x-axis +% XX = 0/1 for no/yes cross-hatch +% +/PatternFill {gsave /PFa [ 9 2 roll ] def + PFa 0 get PFa 2 get 2 div add PFa 1 get PFa 3 get 2 div add translate + PFa 2 get -2 div PFa 3 get -2 div PFa 2 get PFa 3 get Rec + gsave 1 setgray fill grestore clip + currentlinewidth 0.5 mul setlinewidth + /PFs PFa 2 get dup mul PFa 3 get dup mul add sqrt def + 0 0 M PFa 5 get rotate PFs -2 div dup translate + 0 1 PFs PFa 4 get div 1 add floor cvi + {PFa 4 get mul 0 M 0 PFs V} for + 0 PFa 6 get ne { + 0 1 PFs PFa 4 get div 1 add floor cvi + {PFa 4 get mul 0 2 1 roll M PFs 0 V} for + } if + stroke grestore} def +% +/languagelevel where + {pop languagelevel} {1} ifelse + 2 lt + {/InterpretLevel1 true def} + {/InterpretLevel1 Level1 def} + ifelse +% +% PostScript level 2 pattern fill definitions +% +/Level2PatternFill { +/Tile8x8 {/PaintType 2 /PatternType 1 /TilingType 1 /BBox [0 0 8 8] /XStep 8 /YStep 8} + bind def +/KeepColor {currentrgbcolor [/Pattern /DeviceRGB] setcolorspace} bind def +<< Tile8x8 + /PaintProc {0.5 setlinewidth pop 0 0 M 8 8 L 0 8 M 8 0 L stroke} +>> matrix makepattern +/Pat1 exch def +<< Tile8x8 + /PaintProc {0.5 setlinewidth pop 0 0 M 8 8 L 0 8 M 8 0 L stroke + 0 4 M 4 8 L 8 4 L 4 0 L 0 4 L stroke} +>> matrix makepattern +/Pat2 exch def +<< Tile8x8 + /PaintProc {0.5 setlinewidth pop 0 0 M 0 8 L + 8 8 L 8 0 L 0 0 L fill} +>> matrix makepattern +/Pat3 exch def +<< Tile8x8 + /PaintProc {0.5 setlinewidth pop -4 8 M 8 -4 L + 0 12 M 12 0 L stroke} +>> matrix makepattern +/Pat4 exch def +<< Tile8x8 + /PaintProc {0.5 setlinewidth pop -4 0 M 8 12 L + 0 -4 M 12 8 L stroke} +>> matrix makepattern +/Pat5 exch def +<< Tile8x8 + /PaintProc {0.5 setlinewidth pop -2 8 M 4 -4 L + 0 12 M 8 -4 L 4 12 M 10 0 L stroke} +>> matrix makepattern +/Pat6 exch def +<< Tile8x8 + /PaintProc {0.5 setlinewidth pop -2 0 M 4 12 L + 0 -4 M 8 12 L 4 -4 M 10 8 L stroke} +>> matrix makepattern +/Pat7 exch def +<< Tile8x8 + /PaintProc {0.5 setlinewidth pop 8 -2 M -4 4 L + 12 0 M -4 8 L 12 4 M 0 10 L stroke} +>> matrix makepattern +/Pat8 exch def +<< Tile8x8 + /PaintProc {0.5 setlinewidth pop 0 -2 M 12 4 L + -4 0 M 12 8 L -4 4 M 8 10 L stroke} +>> matrix makepattern +/Pat9 exch def +/Pattern1 {PatternBgnd KeepColor Pat1 setpattern} bind def +/Pattern2 {PatternBgnd KeepColor Pat2 setpattern} bind def +/Pattern3 {PatternBgnd KeepColor Pat3 setpattern} bind def +/Pattern4 {PatternBgnd KeepColor Landscape {Pat5} {Pat4} ifelse setpattern} bind def +/Pattern5 {PatternBgnd KeepColor Landscape {Pat4} {Pat5} ifelse setpattern} bind def +/Pattern6 {PatternBgnd KeepColor Landscape {Pat9} {Pat6} ifelse setpattern} bind def +/Pattern7 {PatternBgnd KeepColor Landscape {Pat8} {Pat7} ifelse setpattern} bind def +} def +% +% +%End of PostScript Level 2 code +% +/PatternBgnd { + TransparentPatterns {} {gsave 1 setgray fill grestore} ifelse +} def +% +% Substitute for Level 2 pattern fill codes with +% grayscale if Level 2 support is not selected. +% +/Level1PatternFill { +/Pattern1 {0.250 Density} bind def +/Pattern2 {0.500 Density} bind def +/Pattern3 {0.750 Density} bind def +/Pattern4 {0.125 Density} bind def +/Pattern5 {0.375 Density} bind def +/Pattern6 {0.625 Density} bind def +/Pattern7 {0.875 Density} bind def +} def +% +% Now test for support of Level 2 code +% +Level1 {Level1PatternFill} {Level2PatternFill} ifelse +% +/Symbol-Oblique /Symbol findfont [1 0 .167 1 0 0] makefont +dup length dict begin {1 index /FID eq {pop pop} {def} ifelse} forall +currentdict end definefont pop +/MFshow { + { dup 5 get 3 ge + { 5 get 3 eq {gsave} {grestore} ifelse } + {dup dup 0 get findfont exch 1 get scalefont setfont + [ currentpoint ] exch dup 2 get 0 exch R dup 5 get 2 ne {dup dup 6 + get exch 4 get {Gshow} {stringwidth pop 0 R} ifelse }if dup 5 get 0 eq + {dup 3 get {2 get neg 0 exch R pop} {pop aload pop M} ifelse} {dup 5 + get 1 eq {dup 2 get exch dup 3 get exch 6 get stringwidth pop -2 div + dup 0 R} {dup 6 get stringwidth pop -2 div 0 R 6 get + show 2 index {aload pop M neg 3 -1 roll neg R pop pop} {pop pop pop + pop aload pop M} ifelse }ifelse }ifelse } + ifelse } + forall} def +/Gswidth {dup type /stringtype eq {stringwidth} {pop (n) stringwidth} ifelse} def +/MFwidth {0 exch { dup 5 get 3 ge { 5 get 3 eq { 0 } { pop } ifelse } + {dup 3 get{dup dup 0 get findfont exch 1 get scalefont setfont + 6 get Gswidth pop add} {pop} ifelse} ifelse} forall} def +/MLshow { currentpoint stroke M + 0 exch R + Blacktext {gsave 0 setgray MFshow grestore} {MFshow} ifelse } bind def +/MRshow { currentpoint stroke M + exch dup MFwidth neg 3 -1 roll R + Blacktext {gsave 0 setgray MFshow grestore} {MFshow} ifelse } bind def +/MCshow { currentpoint stroke M + exch dup MFwidth -2 div 3 -1 roll R + Blacktext {gsave 0 setgray MFshow grestore} {MFshow} ifelse } bind def +/XYsave { [( ) 1 2 true false 3 ()] } bind def +/XYrestore { [( ) 1 2 true false 4 ()] } bind def +end +%%EndProlog +%%Page: 1 1 +gnudict begin +gsave +doclip +50 50 translate +0.100 0.100 scale +90 rotate +0 -5040 translate +0 setgray +newpath +(Helvetica) findfont 140 scalefont setfont +1.000 UL +LTb +518 448 M +63 0 V +stroke +434 448 M +[ [(Helvetica) 140.0 0.0 true true 0 ( 1)] +] -46.7 MRshow +1.000 UL +LTb +518 792 M +63 0 V +stroke +434 792 M +[ [(Helvetica) 140.0 0.0 true true 0 ( 2)] +] -46.7 MRshow +1.000 UL +LTb +518 1136 M +63 0 V +stroke +434 1136 M +[ [(Helvetica) 140.0 0.0 true true 0 ( 3)] +] -46.7 MRshow +1.000 UL +LTb +518 1480 M +63 0 V +stroke +434 1480 M +[ [(Helvetica) 140.0 0.0 true true 0 ( 4)] +] -46.7 MRshow +1.000 UL +LTb +518 1823 M +63 0 V +stroke +434 1823 M +[ [(Helvetica) 140.0 0.0 true true 0 ( 5)] +] -46.7 MRshow +1.000 UL +LTb +518 2167 M +63 0 V +stroke +434 2167 M +[ [(Helvetica) 140.0 0.0 true true 0 ( 6)] +] -46.7 MRshow +1.000 UL +LTb +518 2511 M +63 0 V +stroke +434 2511 M +[ [(Helvetica) 140.0 0.0 true true 0 ( 7)] +] -46.7 MRshow +1.000 UL +LTb +518 2855 M +63 0 V +stroke +434 2855 M +[ [(Helvetica) 140.0 0.0 true true 0 ( 8)] +] -46.7 MRshow +1.000 UL +LTb +518 448 M +0 63 V +stroke +518 308 M +[ [(Helvetica) 140.0 0.0 true true 0 ( 0)] +] -46.7 MCshow +1.000 UL +LTb +962 448 M +0 63 V +stroke +962 308 M +[ [(Helvetica) 140.0 0.0 true true 0 ( 1000)] +] -46.7 MCshow +1.000 UL +LTb +1405 448 M +0 63 V +stroke +1405 308 M +[ [(Helvetica) 140.0 0.0 true true 0 ( 2000)] +] -46.7 MCshow +1.000 UL +LTb +1849 448 M +0 63 V +stroke +1849 308 M +[ [(Helvetica) 140.0 0.0 true true 0 ( 3000)] +] -46.7 MCshow +1.000 UL +LTb +2293 448 M +0 63 V +stroke +2293 308 M +[ [(Helvetica) 140.0 0.0 true true 0 ( 4000)] +] -46.7 MCshow +1.000 UL +LTb +2736 448 M +0 63 V +stroke +2736 308 M +[ [(Helvetica) 140.0 0.0 true true 0 ( 5000)] +] -46.7 MCshow +1.000 UL +LTb +3180 448 M +0 63 V +stroke +3180 308 M +[ [(Helvetica) 140.0 0.0 true true 0 ( 6000)] +] -46.7 MCshow +1.000 UL +LTb +3623 448 M +0 63 V +stroke +3623 308 M +[ [(Helvetica) 140.0 0.0 true true 0 ( 7000)] +] -46.7 MCshow +1.000 UL +LTb +4067 448 M +0 63 V +stroke +4067 308 M +[ [(Helvetica) 140.0 0.0 true true 0 ( 8000)] +] -46.7 MCshow +1.000 UL +LTb +1.000 UL +LTb +518 2855 M +518 448 L +3549 0 V +0 2407 R +-3549 0 R +stroke +LCb setrgbcolor +112 1651 M +currentpoint gsave translate -270 rotate 0 0 moveto +[ [(Helvetica) 140.0 0.0 true true 0 (Ratio of Total Execution to Total Work)] +] -46.7 MCshow +grestore +LTb +LCb setrgbcolor +2292 98 M +[ [(Helvetica) 140.0 0.0 true true 0 (Cycles in one Task)] +] -46.7 MCshow +LTb +1.000 UP +1.000 UL +LTb +1.000 UL +LTb +2492 2372 N +0 420 V +1491 0 V +0 -420 V +-1491 0 V +Z stroke +2492 2792 M +1491 0 V +% Begin plot #1 +stroke +4.000 UL +LT1 +LCa setrgbcolor +518 792 M +36 0 V +36 0 V +36 0 V +35 0 V +36 0 V +36 0 V +36 0 V +36 0 V +36 0 V +35 0 V +36 0 V +36 0 V +36 0 V +36 0 V +36 0 V +36 0 V +35 0 V +36 0 V +36 0 V +36 0 V +36 0 V +36 0 V +36 0 V +35 0 V +36 0 V +36 0 V +36 0 V +36 0 V +36 0 V +35 0 V +36 0 V +36 0 V +36 0 V +36 0 V +36 0 V +36 0 V +35 0 V +36 0 V +36 0 V +36 0 V +36 0 V +36 0 V +35 0 V +36 0 V +36 0 V +36 0 V +36 0 V +36 0 V +36 0 V +35 0 V +36 0 V +36 0 V +36 0 V +36 0 V +36 0 V +36 0 V +35 0 V +36 0 V +36 0 V +36 0 V +36 0 V +36 0 V +35 0 V +36 0 V +36 0 V +36 0 V +36 0 V +36 0 V +36 0 V +35 0 V +36 0 V +36 0 V +36 0 V +36 0 V +36 0 V +35 0 V +36 0 V +36 0 V +36 0 V +36 0 V +36 0 V +36 0 V +35 0 V +36 0 V +36 0 V +36 0 V +36 0 V +36 0 V +36 0 V +35 0 V +36 0 V +36 0 V +36 0 V +36 0 V +36 0 V +35 0 V +36 0 V +36 0 V +36 0 V +% End plot #1 +% Begin plot #2 +stroke +LT1 +LCb setrgbcolor +3416 2722 M +[ [(Helvetica) 140.0 0.0 true true 0 (160 Threads)] +] -46.7 MRshow +LT1 +3500 2722 M +399 0 V +1143 2855 M +119 -356 V +1884 1393 L +3173 986 L +4067 875 L +% End plot #2 +% Begin plot #3 +stroke +LT2 +LCb setrgbcolor +3416 2582 M +[ [(Helvetica) 140.0 0.0 true true 0 (320 Threads)] +] -46.7 MRshow +LT2 +3500 2582 M +399 0 V +938 2855 M +11 -154 V +298 -610 V +661 -716 V +3205 912 L +862 -78 V +% End plot #3 +% Begin plot #4 +stroke +LT3 +LCb setrgbcolor +3416 2442 M +[ [(Helvetica) 140.0 0.0 true true 0 (640 Threads)] +] -46.7 MRshow +LT3 +3500 2442 M +399 0 V +933 2855 M +7 -106 V +316 -533 V +639 -908 V +3183 912 L +884 -75 V +% End plot #4 +stroke +1.000 UL +LTb +518 2855 M +518 448 L +3549 0 V +0 2407 R +-3549 0 R +1.000 UP +stroke +grestore +end +showpage +%%Trailer +%%DocumentFonts: Helvetica +%%Pages: 1 diff -r 9b9a2497757d -r eb146c5c05a8 0__Papers/PRT/PRT__formal_def/figures/plots_exec_vs_task_size/vms_pthread_vthread_8_32_128_512thds__o30000__perfCtrs.eps --- /dev/null Thu Jan 01 00:00:00 1970 +0000 +++ b/0__Papers/PRT/PRT__formal_def/figures/plots_exec_vs_task_size/vms_pthread_vthread_8_32_128_512thds__o30000__perfCtrs.eps Sat Aug 03 19:24:22 2013 -0700 @@ -0,0 +1,1319 @@ +%!PS-Adobe-2.0 +%%Title: vms_pthreads_vthread_8_32_128_512thds__o30000__perfCtrs.meas.eps +%%Creator: gnuplot 4.4 patchlevel 2 +%%CreationDate: Thu Jan 26 18:20:37 2012 +%%DocumentFonts: (atend) +%%BoundingBox: 251 50 554 482 +%%Orientation: Landscape +%%Pages: (atend) +%%EndComments +%%BeginProlog +/gnudict 256 dict def +gnudict begin +% +% The following true/false flags may be edited by hand if desired. +% The unit line width and grayscale image gamma correction may also be changed. +% +/Color true def +/Blacktext false def +/Solid false def +/Dashlength 1 def +/Landscape true def +/Level1 false def +/Rounded false def +/ClipToBoundingBox false def +/TransparentPatterns false def +/gnulinewidth 5.000 def +/userlinewidth gnulinewidth def +/Gamma 1.0 def +% +/vshift -46 def +/dl1 { + 10.0 Dashlength mul mul + Rounded { currentlinewidth 0.75 mul sub dup 0 le { pop 0.01 } if } if +} def +/dl2 { + 10.0 Dashlength mul mul + Rounded { currentlinewidth 0.75 mul add } if +} def +/hpt_ 31.5 def +/vpt_ 31.5 def +/hpt hpt_ def +/vpt vpt_ def +Level1 {} { +/SDict 10 dict def +systemdict /pdfmark known not { + userdict /pdfmark systemdict /cleartomark get put +} if +SDict begin [ + /Title (vms_pthreads_vthread_8_32_128_512thds__o30000__perfCtrs.meas.eps) + /Subject (gnuplot plot) + /Creator (gnuplot 4.4 patchlevel 2) + /Author (msach) +% /Producer (gnuplot) +% /Keywords () + /CreationDate (Thu Jan 26 18:20:37 2012) + /DOCINFO pdfmark +end +} ifelse +/doclip { + ClipToBoundingBox { + newpath 251 50 moveto 554 50 lineto 554 482 lineto 251 482 lineto closepath + clip + } if +} def +% +% Gnuplot Prolog Version 4.4 (August 2010) +% +%/SuppressPDFMark true def +% +/M {moveto} bind def +/L {lineto} bind def +/R {rmoveto} bind def +/V {rlineto} bind def +/N {newpath moveto} bind def +/Z {closepath} bind def +/C {setrgbcolor} bind def +/f {rlineto fill} bind def +/g {setgray} bind def +/Gshow {show} def % May be redefined later in the file to support UTF-8 +/vpt2 vpt 2 mul def +/hpt2 hpt 2 mul def +/Lshow {currentpoint stroke M 0 vshift R + Blacktext {gsave 0 setgray show grestore} {show} ifelse} def +/Rshow {currentpoint stroke M dup stringwidth pop neg vshift R + Blacktext {gsave 0 setgray show grestore} {show} ifelse} def +/Cshow {currentpoint stroke M dup stringwidth pop -2 div vshift R + Blacktext {gsave 0 setgray show grestore} {show} ifelse} def +/UP {dup vpt_ mul /vpt exch def hpt_ mul /hpt exch def + /hpt2 hpt 2 mul def /vpt2 vpt 2 mul def} def +/DL {Color {setrgbcolor Solid {pop []} if 0 setdash} + {pop pop pop 0 setgray Solid {pop []} if 0 setdash} ifelse} def +/BL {stroke userlinewidth 2 mul setlinewidth + Rounded {1 setlinejoin 1 setlinecap} if} def +/AL {stroke userlinewidth 2 div setlinewidth + Rounded {1 setlinejoin 1 setlinecap} if} def +/UL {dup gnulinewidth mul /userlinewidth exch def + dup 1 lt {pop 1} if 10 mul /udl exch def} def +/PL {stroke userlinewidth setlinewidth + Rounded {1 setlinejoin 1 setlinecap} if} def +3.8 setmiterlimit +% Default Line colors +/LCw {1 1 1} def +/LCb {0 0 0} def +/LCa {0 0 0} def +/LC0 {1 0 0} def +/LC1 {0 1 0} def +/LC2 {0 0 1} def +/LC3 {1 0 1} def +/LC4 {0 1 1} def +/LC5 {1 1 0} def +/LC6 {0 0 0} def +/LC7 {1 0.3 0} def +/LC8 {0.5 0.5 0.5} def +% Default Line Types +/LTw {PL [] 1 setgray} def +/LTb {BL [] LCb DL} def +/LTa {AL [1 udl mul 2 udl mul] 0 setdash LCa setrgbcolor} def +/LT0 {PL [] LC0 DL} def +/LT1 {PL [4 dl1 2 dl2] LC1 DL} def +/LT2 {PL [2 dl1 3 dl2] LC2 DL} def +/LT3 {PL [1 dl1 1.5 dl2] LC3 DL} def +/LT4 {PL [6 dl1 2 dl2 1 dl1 2 dl2] LC4 DL} def +/LT5 {PL [3 dl1 3 dl2 1 dl1 3 dl2] LC5 DL} def +/LT6 {PL [2 dl1 2 dl2 2 dl1 6 dl2] LC6 DL} def +/LT7 {PL [1 dl1 2 dl2 6 dl1 2 dl2 1 dl1 2 dl2] LC7 DL} def +/LT8 {PL [2 dl1 2 dl2 2 dl1 2 dl2 2 dl1 2 dl2 2 dl1 4 dl2] LC8 DL} def +/Pnt {stroke [] 0 setdash gsave 1 setlinecap M 0 0 V stroke grestore} def +/Dia {stroke [] 0 setdash 2 copy vpt add M + hpt neg vpt neg V hpt vpt neg V + hpt vpt V hpt neg vpt V closepath stroke + Pnt} def +/Pls {stroke [] 0 setdash vpt sub M 0 vpt2 V + currentpoint stroke M + hpt neg vpt neg R hpt2 0 V stroke + } def +/Box {stroke [] 0 setdash 2 copy exch hpt sub exch vpt add M + 0 vpt2 neg V hpt2 0 V 0 vpt2 V + hpt2 neg 0 V closepath stroke + Pnt} def +/Crs {stroke [] 0 setdash exch hpt sub exch vpt add M + hpt2 vpt2 neg V currentpoint stroke M + hpt2 neg 0 R hpt2 vpt2 V stroke} def +/TriU {stroke [] 0 setdash 2 copy vpt 1.12 mul add M + hpt neg vpt -1.62 mul V + hpt 2 mul 0 V + hpt neg vpt 1.62 mul V closepath stroke + Pnt} def +/Star {2 copy Pls Crs} def +/BoxF {stroke [] 0 setdash exch hpt sub exch vpt add M + 0 vpt2 neg V hpt2 0 V 0 vpt2 V + hpt2 neg 0 V closepath fill} def +/TriUF {stroke [] 0 setdash vpt 1.12 mul add M + hpt neg vpt -1.62 mul V + hpt 2 mul 0 V + hpt neg vpt 1.62 mul V closepath fill} def +/TriD {stroke [] 0 setdash 2 copy vpt 1.12 mul sub M + hpt neg vpt 1.62 mul V + hpt 2 mul 0 V + hpt neg vpt -1.62 mul V closepath stroke + Pnt} def +/TriDF {stroke [] 0 setdash vpt 1.12 mul sub M + hpt neg vpt 1.62 mul V + hpt 2 mul 0 V + hpt neg vpt -1.62 mul V closepath fill} def +/DiaF {stroke [] 0 setdash vpt add M + hpt neg vpt neg V hpt vpt neg V + hpt vpt V hpt neg vpt V closepath fill} def +/Pent {stroke [] 0 setdash 2 copy gsave + translate 0 hpt M 4 {72 rotate 0 hpt L} repeat + closepath stroke grestore Pnt} def +/PentF {stroke [] 0 setdash gsave + translate 0 hpt M 4 {72 rotate 0 hpt L} repeat + closepath fill grestore} def +/Circle {stroke [] 0 setdash 2 copy + hpt 0 360 arc stroke Pnt} def +/CircleF {stroke [] 0 setdash hpt 0 360 arc fill} def +/C0 {BL [] 0 setdash 2 copy moveto vpt 90 450 arc} bind def +/C1 {BL [] 0 setdash 2 copy moveto + 2 copy vpt 0 90 arc closepath fill + vpt 0 360 arc closepath} bind def +/C2 {BL [] 0 setdash 2 copy moveto + 2 copy vpt 90 180 arc closepath fill + vpt 0 360 arc closepath} bind def +/C3 {BL [] 0 setdash 2 copy moveto + 2 copy vpt 0 180 arc closepath fill + vpt 0 360 arc closepath} bind def +/C4 {BL [] 0 setdash 2 copy moveto + 2 copy vpt 180 270 arc closepath fill + vpt 0 360 arc closepath} bind def +/C5 {BL [] 0 setdash 2 copy moveto + 2 copy vpt 0 90 arc + 2 copy moveto + 2 copy vpt 180 270 arc closepath fill + vpt 0 360 arc} bind def +/C6 {BL [] 0 setdash 2 copy moveto + 2 copy vpt 90 270 arc closepath fill + vpt 0 360 arc closepath} bind def +/C7 {BL [] 0 setdash 2 copy moveto + 2 copy vpt 0 270 arc closepath fill + vpt 0 360 arc closepath} bind def +/C8 {BL [] 0 setdash 2 copy moveto + 2 copy vpt 270 360 arc closepath fill + vpt 0 360 arc closepath} bind def +/C9 {BL [] 0 setdash 2 copy moveto + 2 copy vpt 270 450 arc closepath fill + vpt 0 360 arc closepath} bind def +/C10 {BL [] 0 setdash 2 copy 2 copy moveto vpt 270 360 arc closepath fill + 2 copy moveto + 2 copy vpt 90 180 arc closepath fill + vpt 0 360 arc closepath} bind def +/C11 {BL [] 0 setdash 2 copy moveto + 2 copy vpt 0 180 arc closepath fill + 2 copy moveto + 2 copy vpt 270 360 arc closepath fill + vpt 0 360 arc closepath} bind def +/C12 {BL [] 0 setdash 2 copy moveto + 2 copy vpt 180 360 arc closepath fill + vpt 0 360 arc closepath} bind def +/C13 {BL [] 0 setdash 2 copy moveto + 2 copy vpt 0 90 arc closepath fill + 2 copy moveto + 2 copy vpt 180 360 arc closepath fill + vpt 0 360 arc closepath} bind def +/C14 {BL [] 0 setdash 2 copy moveto + 2 copy vpt 90 360 arc closepath fill + vpt 0 360 arc} bind def +/C15 {BL [] 0 setdash 2 copy vpt 0 360 arc closepath fill + vpt 0 360 arc closepath} bind def +/Rec {newpath 4 2 roll moveto 1 index 0 rlineto 0 exch rlineto + neg 0 rlineto closepath} bind def +/Square {dup Rec} bind def +/Bsquare {vpt sub exch vpt sub exch vpt2 Square} bind def +/S0 {BL [] 0 setdash 2 copy moveto 0 vpt rlineto BL Bsquare} bind def +/S1 {BL [] 0 setdash 2 copy vpt Square fill Bsquare} bind def +/S2 {BL [] 0 setdash 2 copy exch vpt sub exch vpt Square fill Bsquare} bind def +/S3 {BL [] 0 setdash 2 copy exch vpt sub exch vpt2 vpt Rec fill Bsquare} bind def +/S4 {BL [] 0 setdash 2 copy exch vpt sub exch vpt sub vpt Square fill Bsquare} bind def +/S5 {BL [] 0 setdash 2 copy 2 copy vpt Square fill + exch vpt sub exch vpt sub vpt Square fill Bsquare} bind def +/S6 {BL [] 0 setdash 2 copy exch vpt sub exch vpt sub vpt vpt2 Rec fill Bsquare} bind def +/S7 {BL [] 0 setdash 2 copy exch vpt sub exch vpt sub vpt vpt2 Rec fill + 2 copy vpt Square fill Bsquare} bind def +/S8 {BL [] 0 setdash 2 copy vpt sub vpt Square fill Bsquare} bind def +/S9 {BL [] 0 setdash 2 copy vpt sub vpt vpt2 Rec fill Bsquare} bind def +/S10 {BL [] 0 setdash 2 copy vpt sub vpt Square fill 2 copy exch vpt sub exch vpt Square fill + Bsquare} bind def +/S11 {BL [] 0 setdash 2 copy vpt sub vpt Square fill 2 copy exch vpt sub exch vpt2 vpt Rec fill + Bsquare} bind def +/S12 {BL [] 0 setdash 2 copy exch vpt sub exch vpt sub vpt2 vpt Rec fill Bsquare} bind def +/S13 {BL [] 0 setdash 2 copy exch vpt sub exch vpt sub vpt2 vpt Rec fill + 2 copy vpt Square fill Bsquare} bind def +/S14 {BL [] 0 setdash 2 copy exch vpt sub exch vpt sub vpt2 vpt Rec fill + 2 copy exch vpt sub exch vpt Square fill Bsquare} bind def +/S15 {BL [] 0 setdash 2 copy Bsquare fill Bsquare} bind def +/D0 {gsave translate 45 rotate 0 0 S0 stroke grestore} bind def +/D1 {gsave translate 45 rotate 0 0 S1 stroke grestore} bind def +/D2 {gsave translate 45 rotate 0 0 S2 stroke grestore} bind def +/D3 {gsave translate 45 rotate 0 0 S3 stroke grestore} bind def +/D4 {gsave translate 45 rotate 0 0 S4 stroke grestore} bind def +/D5 {gsave translate 45 rotate 0 0 S5 stroke grestore} bind def +/D6 {gsave translate 45 rotate 0 0 S6 stroke grestore} bind def +/D7 {gsave translate 45 rotate 0 0 S7 stroke grestore} bind def +/D8 {gsave translate 45 rotate 0 0 S8 stroke grestore} bind def +/D9 {gsave translate 45 rotate 0 0 S9 stroke grestore} bind def +/D10 {gsave translate 45 rotate 0 0 S10 stroke grestore} bind def +/D11 {gsave translate 45 rotate 0 0 S11 stroke grestore} bind def +/D12 {gsave translate 45 rotate 0 0 S12 stroke grestore} bind def +/D13 {gsave translate 45 rotate 0 0 S13 stroke grestore} bind def +/D14 {gsave translate 45 rotate 0 0 S14 stroke grestore} bind def +/D15 {gsave translate 45 rotate 0 0 S15 stroke grestore} bind def +/DiaE {stroke [] 0 setdash vpt add M + hpt neg vpt neg V hpt vpt neg V + hpt vpt V hpt neg vpt V closepath stroke} def +/BoxE {stroke [] 0 setdash exch hpt sub exch vpt add M + 0 vpt2 neg V hpt2 0 V 0 vpt2 V + hpt2 neg 0 V closepath stroke} def +/TriUE {stroke [] 0 setdash vpt 1.12 mul add M + hpt neg vpt -1.62 mul V + hpt 2 mul 0 V + hpt neg vpt 1.62 mul V closepath stroke} def +/TriDE {stroke [] 0 setdash vpt 1.12 mul sub M + hpt neg vpt 1.62 mul V + hpt 2 mul 0 V + hpt neg vpt -1.62 mul V closepath stroke} def +/PentE {stroke [] 0 setdash gsave + translate 0 hpt M 4 {72 rotate 0 hpt L} repeat + closepath stroke grestore} def +/CircE {stroke [] 0 setdash + hpt 0 360 arc stroke} def +/Opaque {gsave closepath 1 setgray fill grestore 0 setgray closepath} def +/DiaW {stroke [] 0 setdash vpt add M + hpt neg vpt neg V hpt vpt neg V + hpt vpt V hpt neg vpt V Opaque stroke} def +/BoxW {stroke [] 0 setdash exch hpt sub exch vpt add M + 0 vpt2 neg V hpt2 0 V 0 vpt2 V + hpt2 neg 0 V Opaque stroke} def +/TriUW {stroke [] 0 setdash vpt 1.12 mul add M + hpt neg vpt -1.62 mul V + hpt 2 mul 0 V + hpt neg vpt 1.62 mul V Opaque stroke} def +/TriDW {stroke [] 0 setdash vpt 1.12 mul sub M + hpt neg vpt 1.62 mul V + hpt 2 mul 0 V + hpt neg vpt -1.62 mul V Opaque stroke} def +/PentW {stroke [] 0 setdash gsave + translate 0 hpt M 4 {72 rotate 0 hpt L} repeat + Opaque stroke grestore} def +/CircW {stroke [] 0 setdash + hpt 0 360 arc Opaque stroke} def +/BoxFill {gsave Rec 1 setgray fill grestore} def +/Density { + /Fillden exch def + currentrgbcolor + /ColB exch def /ColG exch def /ColR exch def + /ColR ColR Fillden mul Fillden sub 1 add def + /ColG ColG Fillden mul Fillden sub 1 add def + /ColB ColB Fillden mul Fillden sub 1 add def + ColR ColG ColB setrgbcolor} def +/BoxColFill {gsave Rec PolyFill} def +/PolyFill {gsave Density fill grestore grestore} def +/h {rlineto rlineto rlineto gsave closepath fill grestore} bind def +% +% PostScript Level 1 Pattern Fill routine for rectangles +% Usage: x y w h s a XX PatternFill +% x,y = lower left corner of box to be filled +% w,h = width and height of box +% a = angle in degrees between lines and x-axis +% XX = 0/1 for no/yes cross-hatch +% +/PatternFill {gsave /PFa [ 9 2 roll ] def + PFa 0 get PFa 2 get 2 div add PFa 1 get PFa 3 get 2 div add translate + PFa 2 get -2 div PFa 3 get -2 div PFa 2 get PFa 3 get Rec + gsave 1 setgray fill grestore clip + currentlinewidth 0.5 mul setlinewidth + /PFs PFa 2 get dup mul PFa 3 get dup mul add sqrt def + 0 0 M PFa 5 get rotate PFs -2 div dup translate + 0 1 PFs PFa 4 get div 1 add floor cvi + {PFa 4 get mul 0 M 0 PFs V} for + 0 PFa 6 get ne { + 0 1 PFs PFa 4 get div 1 add floor cvi + {PFa 4 get mul 0 2 1 roll M PFs 0 V} for + } if + stroke grestore} def +% +/languagelevel where + {pop languagelevel} {1} ifelse + 2 lt + {/InterpretLevel1 true def} + {/InterpretLevel1 Level1 def} + ifelse +% +% PostScript level 2 pattern fill definitions +% +/Level2PatternFill { +/Tile8x8 {/PaintType 2 /PatternType 1 /TilingType 1 /BBox [0 0 8 8] /XStep 8 /YStep 8} + bind def +/KeepColor {currentrgbcolor [/Pattern /DeviceRGB] setcolorspace} bind def +<< Tile8x8 + /PaintProc {0.5 setlinewidth pop 0 0 M 8 8 L 0 8 M 8 0 L stroke} +>> matrix makepattern +/Pat1 exch def +<< Tile8x8 + /PaintProc {0.5 setlinewidth pop 0 0 M 8 8 L 0 8 M 8 0 L stroke + 0 4 M 4 8 L 8 4 L 4 0 L 0 4 L stroke} +>> matrix makepattern +/Pat2 exch def +<< Tile8x8 + /PaintProc {0.5 setlinewidth pop 0 0 M 0 8 L + 8 8 L 8 0 L 0 0 L fill} +>> matrix makepattern +/Pat3 exch def +<< Tile8x8 + /PaintProc {0.5 setlinewidth pop -4 8 M 8 -4 L + 0 12 M 12 0 L stroke} +>> matrix makepattern +/Pat4 exch def +<< Tile8x8 + /PaintProc {0.5 setlinewidth pop -4 0 M 8 12 L + 0 -4 M 12 8 L stroke} +>> matrix makepattern +/Pat5 exch def +<< Tile8x8 + /PaintProc {0.5 setlinewidth pop -2 8 M 4 -4 L + 0 12 M 8 -4 L 4 12 M 10 0 L stroke} +>> matrix makepattern +/Pat6 exch def +<< Tile8x8 + /PaintProc {0.5 setlinewidth pop -2 0 M 4 12 L + 0 -4 M 8 12 L 4 -4 M 10 8 L stroke} +>> matrix makepattern +/Pat7 exch def +<< Tile8x8 + /PaintProc {0.5 setlinewidth pop 8 -2 M -4 4 L + 12 0 M -4 8 L 12 4 M 0 10 L stroke} +>> matrix makepattern +/Pat8 exch def +<< Tile8x8 + /PaintProc {0.5 setlinewidth pop 0 -2 M 12 4 L + -4 0 M 12 8 L -4 4 M 8 10 L stroke} +>> matrix makepattern +/Pat9 exch def +/Pattern1 {PatternBgnd KeepColor Pat1 setpattern} bind def +/Pattern2 {PatternBgnd KeepColor Pat2 setpattern} bind def +/Pattern3 {PatternBgnd KeepColor Pat3 setpattern} bind def +/Pattern4 {PatternBgnd KeepColor Landscape {Pat5} {Pat4} ifelse setpattern} bind def +/Pattern5 {PatternBgnd KeepColor Landscape {Pat4} {Pat5} ifelse setpattern} bind def +/Pattern6 {PatternBgnd KeepColor Landscape {Pat9} {Pat6} ifelse setpattern} bind def +/Pattern7 {PatternBgnd KeepColor Landscape {Pat8} {Pat7} ifelse setpattern} bind def +} def +% +% +%End of PostScript Level 2 code +% +/PatternBgnd { + TransparentPatterns {} {gsave 1 setgray fill grestore} ifelse +} def +% +% Substitute for Level 2 pattern fill codes with +% grayscale if Level 2 support is not selected. +% +/Level1PatternFill { +/Pattern1 {0.250 Density} bind def +/Pattern2 {0.500 Density} bind def +/Pattern3 {0.750 Density} bind def +/Pattern4 {0.125 Density} bind def +/Pattern5 {0.375 Density} bind def +/Pattern6 {0.625 Density} bind def +/Pattern7 {0.875 Density} bind def +} def +% +% Now test for support of Level 2 code +% +Level1 {Level1PatternFill} {Level2PatternFill} ifelse +% +/Symbol-Oblique /Symbol findfont [1 0 .167 1 0 0] makefont +dup length dict begin {1 index /FID eq {pop pop} {def} ifelse} forall +currentdict end definefont pop +/MFshow { + { dup 5 get 3 ge + { 5 get 3 eq {gsave} {grestore} ifelse } + {dup dup 0 get findfont exch 1 get scalefont setfont + [ currentpoint ] exch dup 2 get 0 exch R dup 5 get 2 ne {dup dup 6 + get exch 4 get {Gshow} {stringwidth pop 0 R} ifelse }if dup 5 get 0 eq + {dup 3 get {2 get neg 0 exch R pop} {pop aload pop M} ifelse} {dup 5 + get 1 eq {dup 2 get exch dup 3 get exch 6 get stringwidth pop -2 div + dup 0 R} {dup 6 get stringwidth pop -2 div 0 R 6 get + show 2 index {aload pop M neg 3 -1 roll neg R pop pop} {pop pop pop + pop aload pop M} ifelse }ifelse }ifelse } + ifelse } + forall} def +/Gswidth {dup type /stringtype eq {stringwidth} {pop (n) stringwidth} ifelse} def +/MFwidth {0 exch { dup 5 get 3 ge { 5 get 3 eq { 0 } { pop } ifelse } + {dup 3 get{dup dup 0 get findfont exch 1 get scalefont setfont + 6 get Gswidth pop add} {pop} ifelse} ifelse} forall} def +/MLshow { currentpoint stroke M + 0 exch R + Blacktext {gsave 0 setgray MFshow grestore} {MFshow} ifelse } bind def +/MRshow { currentpoint stroke M + exch dup MFwidth neg 3 -1 roll R + Blacktext {gsave 0 setgray MFshow grestore} {MFshow} ifelse } bind def +/MCshow { currentpoint stroke M + exch dup MFwidth -2 div 3 -1 roll R + Blacktext {gsave 0 setgray MFshow grestore} {MFshow} ifelse } bind def +/XYsave { [( ) 1 2 true false 3 ()] } bind def +/XYrestore { [( ) 1 2 true false 4 ()] } bind def +end +%%EndProlog +%%Page: 1 1 +gnudict begin +gsave +doclip +50 50 translate +0.100 0.100 scale +90 rotate +0 -5040 translate +0 setgray +newpath +(Helvetica) findfont 140 scalefont setfont +1.000 UL +LTb +602 448 M +63 0 V +stroke +518 448 M +[ [(Helvetica) 140.0 0.0 true true 0 ( 1)] +] -46.7 MRshow +1.000 UL +LTb +602 715 M +63 0 V +stroke +518 715 M +[ [(Helvetica) 140.0 0.0 true true 0 ( 2)] +] -46.7 MRshow +1.000 UL +LTb +602 983 M +63 0 V +stroke +518 983 M +[ [(Helvetica) 140.0 0.0 true true 0 ( 3)] +] -46.7 MRshow +1.000 UL +LTb +602 1250 M +63 0 V +stroke +518 1250 M +[ [(Helvetica) 140.0 0.0 true true 0 ( 4)] +] -46.7 MRshow +1.000 UL +LTb +602 1518 M +63 0 V +stroke +518 1518 M +[ [(Helvetica) 140.0 0.0 true true 0 ( 5)] +] -46.7 MRshow +1.000 UL +LTb +602 1785 M +63 0 V +stroke +518 1785 M +[ [(Helvetica) 140.0 0.0 true true 0 ( 6)] +] -46.7 MRshow +1.000 UL +LTb +602 2053 M +63 0 V +stroke +518 2053 M +[ [(Helvetica) 140.0 0.0 true true 0 ( 7)] +] -46.7 MRshow +1.000 UL +LTb +602 2320 M +63 0 V +stroke +518 2320 M +[ [(Helvetica) 140.0 0.0 true true 0 ( 8)] +] -46.7 MRshow +1.000 UL +LTb +602 2588 M +63 0 V +stroke +518 2588 M +[ [(Helvetica) 140.0 0.0 true true 0 ( 9)] +] -46.7 MRshow +1.000 UL +LTb +602 2855 M +63 0 V +stroke +518 2855 M +[ [(Helvetica) 140.0 0.0 true true 0 ( 10)] +] -46.7 MRshow +1.000 UL +LTb +602 448 M +0 63 V +stroke +602 308 M +[ [(Helvetica) 140.0 0.0 true true 0 ( 0)] +] -46.7 MCshow +1.000 UL +LTb +1035 448 M +0 63 V +stroke +1035 308 M +[ [(Helvetica) 140.0 0.0 true true 0 ( 1000)] +] -46.7 MCshow +1.000 UL +LTb +1468 448 M +0 63 V +stroke +1468 308 M +[ [(Helvetica) 140.0 0.0 true true 0 ( 2000)] +] -46.7 MCshow +1.000 UL +LTb +1901 448 M +0 63 V +stroke +1901 308 M +[ [(Helvetica) 140.0 0.0 true true 0 ( 3000)] +] -46.7 MCshow +1.000 UL +LTb +2335 448 M +0 63 V +stroke +2335 308 M +[ [(Helvetica) 140.0 0.0 true true 0 ( 4000)] +] -46.7 MCshow +1.000 UL +LTb +2768 448 M +0 63 V +stroke +2768 308 M +[ [(Helvetica) 140.0 0.0 true true 0 ( 5000)] +] -46.7 MCshow +1.000 UL +LTb +3201 448 M +0 63 V +stroke +3201 308 M +[ [(Helvetica) 140.0 0.0 true true 0 ( 6000)] +] -46.7 MCshow +1.000 UL +LTb +3634 448 M +0 63 V +stroke +3634 308 M +[ [(Helvetica) 140.0 0.0 true true 0 ( 7000)] +] -46.7 MCshow +1.000 UL +LTb +4067 448 M +0 63 V +stroke +4067 308 M +[ [(Helvetica) 140.0 0.0 true true 0 ( 8000)] +] -46.7 MCshow +1.000 UL +LTb +1.000 UL +LTb +602 2855 M +602 448 L +3465 0 V +0 2407 R +-3465 0 R +stroke +LCb setrgbcolor +112 1651 M +currentpoint gsave translate -270 rotate 0 0 moveto +[ [(Helvetica) 140.0 0.0 true true 0 (Ratio of Total Execution to Total Work)] +] -46.7 MCshow +grestore +LTb +LCb setrgbcolor +2334 98 M +[ [(Helvetica) 140.0 0.0 true true 0 (Cycles in one Task)] +] -46.7 MCshow +LTb +1.000 UP +1.000 UL +LTb +% Begin plot #1 +3.000 UL +LT1 +LCa setrgbcolor +602 715 M +35 0 V +35 0 V +35 0 V +35 0 V +35 0 V +35 0 V +35 0 V +35 0 V +35 0 V +35 0 V +35 0 V +35 0 V +35 0 V +35 0 V +35 0 V +35 0 V +35 0 V +35 0 V +35 0 V +35 0 V +35 0 V +35 0 V +35 0 V +35 0 V +35 0 V +35 0 V +35 0 V +35 0 V +35 0 V +35 0 V +35 0 V +35 0 V +35 0 V +35 0 V +35 0 V +35 0 V +35 0 V +35 0 V +35 0 V +35 0 V +35 0 V +35 0 V +35 0 V +35 0 V +35 0 V +35 0 V +35 0 V +35 0 V +35 0 V +35 0 V +35 0 V +35 0 V +35 0 V +35 0 V +35 0 V +35 0 V +35 0 V +35 0 V +35 0 V +35 0 V +35 0 V +35 0 V +35 0 V +35 0 V +35 0 V +35 0 V +35 0 V +35 0 V +35 0 V +35 0 V +35 0 V +35 0 V +35 0 V +35 0 V +35 0 V +35 0 V +35 0 V +35 0 V +35 0 V +35 0 V +35 0 V +35 0 V +35 0 V +35 0 V +35 0 V +35 0 V +35 0 V +35 0 V +35 0 V +35 0 V +35 0 V +35 0 V +35 0 V +35 0 V +35 0 V +35 0 V +35 0 V +35 0 V +35 0 V +% End plot #1 +stroke +1.000 UL +LTb +602 2855 M +602 448 L +3465 0 V +0 2407 R +-3465 0 R +1.000 UP +602 448 M +63 0 V +stroke +518 448 M +[ [(Helvetica) 140.0 0.0 true true 0 ( 1)] +] -46.7 MRshow +1.000 UL +LTb +602 715 M +63 0 V +stroke +518 715 M +[ [(Helvetica) 140.0 0.0 true true 0 ( 2)] +] -46.7 MRshow +1.000 UL +LTb +602 983 M +63 0 V +stroke +518 983 M +[ [(Helvetica) 140.0 0.0 true true 0 ( 3)] +] -46.7 MRshow +1.000 UL +LTb +602 1250 M +63 0 V +stroke +518 1250 M +[ [(Helvetica) 140.0 0.0 true true 0 ( 4)] +] -46.7 MRshow +1.000 UL +LTb +602 1518 M +63 0 V +stroke +518 1518 M +[ [(Helvetica) 140.0 0.0 true true 0 ( 5)] +] -46.7 MRshow +1.000 UL +LTb +602 1785 M +63 0 V +stroke +518 1785 M +[ [(Helvetica) 140.0 0.0 true true 0 ( 6)] +] -46.7 MRshow +1.000 UL +LTb +602 2053 M +63 0 V +stroke +518 2053 M +[ [(Helvetica) 140.0 0.0 true true 0 ( 7)] +] -46.7 MRshow +1.000 UL +LTb +602 2320 M +63 0 V +stroke +518 2320 M +[ [(Helvetica) 140.0 0.0 true true 0 ( 8)] +] -46.7 MRshow +1.000 UL +LTb +602 2588 M +63 0 V +stroke +518 2588 M +[ [(Helvetica) 140.0 0.0 true true 0 ( 9)] +] -46.7 MRshow +1.000 UL +LTb +602 2855 M +63 0 V +stroke +518 2855 M +[ [(Helvetica) 140.0 0.0 true true 0 ( 10)] +] -46.7 MRshow +1.000 UL +LTb +602 448 M +0 63 V +stroke +602 308 M +[ [(Helvetica) 140.0 0.0 true true 0 ( 0)] +] -46.7 MCshow +1.000 UL +LTb +1035 448 M +0 63 V +stroke +1035 308 M +[ [(Helvetica) 140.0 0.0 true true 0 ( 1000)] +] -46.7 MCshow +1.000 UL +LTb +1468 448 M +0 63 V +stroke +1468 308 M +[ [(Helvetica) 140.0 0.0 true true 0 ( 2000)] +] -46.7 MCshow +1.000 UL +LTb +1901 448 M +0 63 V +stroke +1901 308 M +[ [(Helvetica) 140.0 0.0 true true 0 ( 3000)] +] -46.7 MCshow +1.000 UL +LTb +2335 448 M +0 63 V +stroke +2335 308 M +[ [(Helvetica) 140.0 0.0 true true 0 ( 4000)] +] -46.7 MCshow +1.000 UL +LTb +2768 448 M +0 63 V +stroke +2768 308 M +[ [(Helvetica) 140.0 0.0 true true 0 ( 5000)] +] -46.7 MCshow +1.000 UL +LTb +3201 448 M +0 63 V +stroke +3201 308 M +[ [(Helvetica) 140.0 0.0 true true 0 ( 6000)] +] -46.7 MCshow +1.000 UL +LTb +3634 448 M +0 63 V +stroke +3634 308 M +[ [(Helvetica) 140.0 0.0 true true 0 ( 7000)] +] -46.7 MCshow +1.000 UL +LTb +4067 448 M +0 63 V +stroke +4067 308 M +[ [(Helvetica) 140.0 0.0 true true 0 ( 8000)] +] -46.7 MCshow +1.000 UL +LTb +1.000 UL +LTb +602 2855 M +602 448 L +3465 0 V +0 2407 R +-3465 0 R +stroke +LCb setrgbcolor +112 1651 M +currentpoint gsave translate -270 rotate 0 0 moveto +[ [(Helvetica) 140.0 0.0 true true 0 (Ratio of Total Execution to Total Work)] +] -46.7 MCshow +grestore +LTb +LCb setrgbcolor +2334 98 M +[ [(Helvetica) 140.0 0.0 true true 0 (Cycles in one Task)] +] -46.7 MCshow +LTb +1.000 UP +1.000 UL +LTb +LCb setrgbcolor +3538 2919 M +[ [(Helvetica) 140.0 0.0 true true 0 (pthreads)] +] -46.7 MCshow +LTb +1.000 UL +LTb +2793 2289 N +0 700 V +1491 0 V +0 -700 V +-1491 0 V +Z stroke +2793 2849 M +1491 0 V +% Begin plot #1 +stroke +4.000 UL +LT5 +LC7 setrgbcolor +LCb setrgbcolor +3717 2779 M +[ [(Helvetica) 140.0 0.0 true true 0 (8 Threads)] +] -46.7 MRshow +LT5 +LC7 setrgbcolor +3801 2779 M +399 0 V +742 2855 M +2 -67 V +851 1788 L +206 -591 V +1473 836 L +2306 644 L +3967 545 L +% End plot #1 +% Begin plot #2 +stroke +LT6 +LCb setrgbcolor +3717 2639 M +[ [(Helvetica) 140.0 0.0 true true 0 (32 Threads)] +] -46.7 MRshow +LT6 +3801 2639 M +399 0 V +946 2855 M +112 -798 V +417 -761 V +2304 901 L +3971 681 L +% End plot #2 +% Begin plot #3 +stroke +LT7 +LC1 setrgbcolor +LCb setrgbcolor +3717 2499 M +[ [(Helvetica) 140.0 0.0 true true 0 (128 Threads)] +] -46.7 MRshow +LT7 +LC1 setrgbcolor +3801 2499 M +399 0 V +1813 2855 M +496 -872 V +3972 1224 L +% End plot #3 +% Begin plot #4 +stroke +LT8 +LCb setrgbcolor +3717 2359 M +[ [(Helvetica) 140.0 0.0 true true 0 (512 Threads)] +] -46.7 MRshow +LT8 +3801 2359 M +399 0 V +% End plot #4 +stroke +1.000 UL +LTb +602 2855 M +602 448 L +3465 0 V +0 2407 R +-3465 0 R +1.000 UP +602 448 M +63 0 V +stroke +518 448 M +[ [(Helvetica) 140.0 0.0 true true 0 ( 1)] +] -46.7 MRshow +1.000 UL +LTb +602 715 M +63 0 V +stroke +518 715 M +[ [(Helvetica) 140.0 0.0 true true 0 ( 2)] +] -46.7 MRshow +1.000 UL +LTb +602 983 M +63 0 V +stroke +518 983 M +[ [(Helvetica) 140.0 0.0 true true 0 ( 3)] +] -46.7 MRshow +1.000 UL +LTb +602 1250 M +63 0 V +stroke +518 1250 M +[ [(Helvetica) 140.0 0.0 true true 0 ( 4)] +] -46.7 MRshow +1.000 UL +LTb +602 1518 M +63 0 V +stroke +518 1518 M +[ [(Helvetica) 140.0 0.0 true true 0 ( 5)] +] -46.7 MRshow +1.000 UL +LTb +602 1785 M +63 0 V +stroke +518 1785 M +[ [(Helvetica) 140.0 0.0 true true 0 ( 6)] +] -46.7 MRshow +1.000 UL +LTb +602 2053 M +63 0 V +stroke +518 2053 M +[ [(Helvetica) 140.0 0.0 true true 0 ( 7)] +] -46.7 MRshow +1.000 UL +LTb +602 2320 M +63 0 V +stroke +518 2320 M +[ [(Helvetica) 140.0 0.0 true true 0 ( 8)] +] -46.7 MRshow +1.000 UL +LTb +602 2588 M +63 0 V +stroke +518 2588 M +[ [(Helvetica) 140.0 0.0 true true 0 ( 9)] +] -46.7 MRshow +1.000 UL +LTb +602 2855 M +63 0 V +stroke +518 2855 M +[ [(Helvetica) 140.0 0.0 true true 0 ( 10)] +] -46.7 MRshow +1.000 UL +LTb +602 448 M +0 63 V +stroke +602 308 M +[ [(Helvetica) 140.0 0.0 true true 0 ( 0)] +] -46.7 MCshow +1.000 UL +LTb +1035 448 M +0 63 V +stroke +1035 308 M +[ [(Helvetica) 140.0 0.0 true true 0 ( 1000)] +] -46.7 MCshow +1.000 UL +LTb +1468 448 M +0 63 V +stroke +1468 308 M +[ [(Helvetica) 140.0 0.0 true true 0 ( 2000)] +] -46.7 MCshow +1.000 UL +LTb +1901 448 M +0 63 V +stroke +1901 308 M +[ [(Helvetica) 140.0 0.0 true true 0 ( 3000)] +] -46.7 MCshow +1.000 UL +LTb +2335 448 M +0 63 V +stroke +2335 308 M +[ [(Helvetica) 140.0 0.0 true true 0 ( 4000)] +] -46.7 MCshow +1.000 UL +LTb +2768 448 M +0 63 V +stroke +2768 308 M +[ [(Helvetica) 140.0 0.0 true true 0 ( 5000)] +] -46.7 MCshow +1.000 UL +LTb +3201 448 M +0 63 V +stroke +3201 308 M +[ [(Helvetica) 140.0 0.0 true true 0 ( 6000)] +] -46.7 MCshow +1.000 UL +LTb +3634 448 M +0 63 V +stroke +3634 308 M +[ [(Helvetica) 140.0 0.0 true true 0 ( 7000)] +] -46.7 MCshow +1.000 UL +LTb +4067 448 M +0 63 V +stroke +4067 308 M +[ [(Helvetica) 140.0 0.0 true true 0 ( 8000)] +] -46.7 MCshow +1.000 UL +LTb +1.000 UL +LTb +602 2855 M +602 448 L +3465 0 V +0 2407 R +-3465 0 R +stroke +LCb setrgbcolor +112 1651 M +currentpoint gsave translate -270 rotate 0 0 moveto +[ [(Helvetica) 140.0 0.0 true true 0 (Ratio of Total Execution to Total Work)] +] -46.7 MCshow +grestore +LTb +LCb setrgbcolor +2334 98 M +[ [(Helvetica) 140.0 0.0 true true 0 (Cycles in one Task)] +] -46.7 MCshow +LTb +1.000 UP +1.000 UL +LTb +LCb setrgbcolor +2022 2919 M +[ [(Helvetica) 140.0 0.0 true true 0 (Vthread)] +] -46.7 MCshow +LTb +1.000 UL +LTb +1277 2289 N +0 700 V +1491 0 V +0 -700 V +-1491 0 V +Z stroke +1277 2849 M +1491 0 V +% Begin plot #1 +stroke +4.000 UL +LT0 +LCb setrgbcolor +2201 2779 M +[ [(Helvetica) 140.0 0.0 true true 0 (8 Threads)] +] -46.7 MRshow +LT0 +2285 2779 M +399 0 V +654 2182 M +16 -334 V +24 -434 V +54 -354 V +852 815 L +1060 648 L +1474 537 L +832 -41 V +3969 471 L +% End plot #1 +% Begin plot #2 +stroke +LT2 +LCb setrgbcolor +2201 2639 M +[ [(Helvetica) 140.0 0.0 true true 0 (32 Threads)] +] -46.7 MRshow +LT2 +2285 2639 M +399 0 V +654 1786 M +16 -339 V +24 -169 V +748 917 L +852 723 L +1059 606 L +416 -79 V +832 -43 V +3969 467 L +% End plot #2 +% Begin plot #3 +stroke +LT3 +LCb setrgbcolor +2201 2499 M +[ [(Helvetica) 140.0 0.0 true true 0 (128 Threads)] +] -46.7 MRshow +LT3 +2285 2499 M +399 0 V +654 1837 M +16 -296 V +26 -324 V +748 970 L +851 740 L +1059 610 L +416 -81 V +832 -39 V +3970 466 L +% End plot #3 +% Begin plot #4 +stroke +LT4 +LCb setrgbcolor +2201 2359 M +[ [(Helvetica) 140.0 0.0 true true 0 (512 Threads)] +] -46.7 MRshow +LT4 +2285 2359 M +399 0 V +654 1958 M +14 -347 V +26 -349 V +748 965 L +850 751 L +1058 612 L +416 -83 V +833 -41 V +3970 467 L +% End plot #4 +stroke +1.000 UL +LTb +602 2855 M +602 448 L +3465 0 V +0 2407 R +-3465 0 R +1.000 UP +stroke +grestore +end +showpage +%%Trailer +%%DocumentFonts: Helvetica +%%Pages: 1 diff -r 9b9a2497757d -r eb146c5c05a8 0__Papers/PRT/PRT__formal_def/figures/plots_exec_vs_task_size/xoanon_pthread_vthread_40core_80_160_320_640thds__o30000__perfCtrs.eps --- /dev/null Thu Jan 01 00:00:00 1970 +0000 +++ b/0__Papers/PRT/PRT__formal_def/figures/plots_exec_vs_task_size/xoanon_pthread_vthread_40core_80_160_320_640thds__o30000__perfCtrs.eps Sat Aug 03 19:24:22 2013 -0700 @@ -0,0 +1,948 @@ +%!PS-Adobe-2.0 +%%Title: xoanon_pthreads_vthread_40core_80_160_320_640thds__o30000__perfCtrs.meas.eps +%%Creator: gnuplot 4.4 patchlevel 2 +%%CreationDate: Thu Jan 26 18:27:40 2012 +%%DocumentFonts: (atend) +%%BoundingBox: 251 50 554 482 +%%Orientation: Landscape +%%Pages: (atend) +%%EndComments +%%BeginProlog +/gnudict 256 dict def +gnudict begin +% +% The following true/false flags may be edited by hand if desired. +% The unit line width and grayscale image gamma correction may also be changed. +% +/Color true def +/Blacktext false def +/Solid false def +/Dashlength 1 def +/Landscape true def +/Level1 false def +/Rounded false def +/ClipToBoundingBox false def +/TransparentPatterns false def +/gnulinewidth 5.000 def +/userlinewidth gnulinewidth def +/Gamma 1.0 def +% +/vshift -46 def +/dl1 { + 10.0 Dashlength mul mul + Rounded { currentlinewidth 0.75 mul sub dup 0 le { pop 0.01 } if } if +} def +/dl2 { + 10.0 Dashlength mul mul + Rounded { currentlinewidth 0.75 mul add } if +} def +/hpt_ 31.5 def +/vpt_ 31.5 def +/hpt hpt_ def +/vpt vpt_ def +Level1 {} { +/SDict 10 dict def +systemdict /pdfmark known not { + userdict /pdfmark systemdict /cleartomark get put +} if +SDict begin [ + /Title (xoanon_pthreads_vthread_40core_80_160_320_640thds__o30000__perfCtrs.meas.eps) + /Subject (gnuplot plot) + /Creator (gnuplot 4.4 patchlevel 2) + /Author (msach) +% /Producer (gnuplot) +% /Keywords () + /CreationDate (Thu Jan 26 18:27:40 2012) + /DOCINFO pdfmark +end +} ifelse +/doclip { + ClipToBoundingBox { + newpath 251 50 moveto 554 50 lineto 554 482 lineto 251 482 lineto closepath + clip + } if +} def +% +% Gnuplot Prolog Version 4.4 (August 2010) +% +%/SuppressPDFMark true def +% +/M {moveto} bind def +/L {lineto} bind def +/R {rmoveto} bind def +/V {rlineto} bind def +/N {newpath moveto} bind def +/Z {closepath} bind def +/C {setrgbcolor} bind def +/f {rlineto fill} bind def +/g {setgray} bind def +/Gshow {show} def % May be redefined later in the file to support UTF-8 +/vpt2 vpt 2 mul def +/hpt2 hpt 2 mul def +/Lshow {currentpoint stroke M 0 vshift R + Blacktext {gsave 0 setgray show grestore} {show} ifelse} def +/Rshow {currentpoint stroke M dup stringwidth pop neg vshift R + Blacktext {gsave 0 setgray show grestore} {show} ifelse} def +/Cshow {currentpoint stroke M dup stringwidth pop -2 div vshift R + Blacktext {gsave 0 setgray show grestore} {show} ifelse} def +/UP {dup vpt_ mul /vpt exch def hpt_ mul /hpt exch def + /hpt2 hpt 2 mul def /vpt2 vpt 2 mul def} def +/DL {Color {setrgbcolor Solid {pop []} if 0 setdash} + {pop pop pop 0 setgray Solid {pop []} if 0 setdash} ifelse} def +/BL {stroke userlinewidth 2 mul setlinewidth + Rounded {1 setlinejoin 1 setlinecap} if} def +/AL {stroke userlinewidth 2 div setlinewidth + Rounded {1 setlinejoin 1 setlinecap} if} def +/UL {dup gnulinewidth mul /userlinewidth exch def + dup 1 lt {pop 1} if 10 mul /udl exch def} def +/PL {stroke userlinewidth setlinewidth + Rounded {1 setlinejoin 1 setlinecap} if} def +3.8 setmiterlimit +% Default Line colors +/LCw {1 1 1} def +/LCb {0 0 0} def +/LCa {0 0 0} def +/LC0 {1 0 0} def +/LC1 {0 1 0} def +/LC2 {0 0 1} def +/LC3 {1 0 1} def +/LC4 {0 1 1} def +/LC5 {1 1 0} def +/LC6 {0 0 0} def +/LC7 {1 0.3 0} def +/LC8 {0.5 0.5 0.5} def +% Default Line Types +/LTw {PL [] 1 setgray} def +/LTb {BL [] LCb DL} def +/LTa {AL [1 udl mul 2 udl mul] 0 setdash LCa setrgbcolor} def +/LT0 {PL [] LC0 DL} def +/LT1 {PL [4 dl1 2 dl2] LC1 DL} def +/LT2 {PL [2 dl1 3 dl2] LC2 DL} def +/LT3 {PL [1 dl1 1.5 dl2] LC3 DL} def +/LT4 {PL [6 dl1 2 dl2 1 dl1 2 dl2] LC4 DL} def +/LT5 {PL [3 dl1 3 dl2 1 dl1 3 dl2] LC5 DL} def +/LT6 {PL [2 dl1 2 dl2 2 dl1 6 dl2] LC6 DL} def +/LT7 {PL [1 dl1 2 dl2 6 dl1 2 dl2 1 dl1 2 dl2] LC7 DL} def +/LT8 {PL [2 dl1 2 dl2 2 dl1 2 dl2 2 dl1 2 dl2 2 dl1 4 dl2] LC8 DL} def +/Pnt {stroke [] 0 setdash gsave 1 setlinecap M 0 0 V stroke grestore} def +/Dia {stroke [] 0 setdash 2 copy vpt add M + hpt neg vpt neg V hpt vpt neg V + hpt vpt V hpt neg vpt V closepath stroke + Pnt} def +/Pls {stroke [] 0 setdash vpt sub M 0 vpt2 V + currentpoint stroke M + hpt neg vpt neg R hpt2 0 V stroke + } def +/Box {stroke [] 0 setdash 2 copy exch hpt sub exch vpt add M + 0 vpt2 neg V hpt2 0 V 0 vpt2 V + hpt2 neg 0 V closepath stroke + Pnt} def +/Crs {stroke [] 0 setdash exch hpt sub exch vpt add M + hpt2 vpt2 neg V currentpoint stroke M + hpt2 neg 0 R hpt2 vpt2 V stroke} def +/TriU {stroke [] 0 setdash 2 copy vpt 1.12 mul add M + hpt neg vpt -1.62 mul V + hpt 2 mul 0 V + hpt neg vpt 1.62 mul V closepath stroke + Pnt} def +/Star {2 copy Pls Crs} def +/BoxF {stroke [] 0 setdash exch hpt sub exch vpt add M + 0 vpt2 neg V hpt2 0 V 0 vpt2 V + hpt2 neg 0 V closepath fill} def +/TriUF {stroke [] 0 setdash vpt 1.12 mul add M + hpt neg vpt -1.62 mul V + hpt 2 mul 0 V + hpt neg vpt 1.62 mul V closepath fill} def +/TriD {stroke [] 0 setdash 2 copy vpt 1.12 mul sub M + hpt neg vpt 1.62 mul V + hpt 2 mul 0 V + hpt neg vpt -1.62 mul V closepath stroke + Pnt} def +/TriDF {stroke [] 0 setdash vpt 1.12 mul sub M + hpt neg vpt 1.62 mul V + hpt 2 mul 0 V + hpt neg vpt -1.62 mul V closepath fill} def +/DiaF {stroke [] 0 setdash vpt add M + hpt neg vpt neg V hpt vpt neg V + hpt vpt V hpt neg vpt V closepath fill} def +/Pent {stroke [] 0 setdash 2 copy gsave + translate 0 hpt M 4 {72 rotate 0 hpt L} repeat + closepath stroke grestore Pnt} def +/PentF {stroke [] 0 setdash gsave + translate 0 hpt M 4 {72 rotate 0 hpt L} repeat + closepath fill grestore} def +/Circle {stroke [] 0 setdash 2 copy + hpt 0 360 arc stroke Pnt} def +/CircleF {stroke [] 0 setdash hpt 0 360 arc fill} def +/C0 {BL [] 0 setdash 2 copy moveto vpt 90 450 arc} bind def +/C1 {BL [] 0 setdash 2 copy moveto + 2 copy vpt 0 90 arc closepath fill + vpt 0 360 arc closepath} bind def +/C2 {BL [] 0 setdash 2 copy moveto + 2 copy vpt 90 180 arc closepath fill + vpt 0 360 arc closepath} bind def +/C3 {BL [] 0 setdash 2 copy moveto + 2 copy vpt 0 180 arc closepath fill + vpt 0 360 arc closepath} bind def +/C4 {BL [] 0 setdash 2 copy moveto + 2 copy vpt 180 270 arc closepath fill + vpt 0 360 arc closepath} bind def +/C5 {BL [] 0 setdash 2 copy moveto + 2 copy vpt 0 90 arc + 2 copy moveto + 2 copy vpt 180 270 arc closepath fill + vpt 0 360 arc} bind def +/C6 {BL [] 0 setdash 2 copy moveto + 2 copy vpt 90 270 arc closepath fill + vpt 0 360 arc closepath} bind def +/C7 {BL [] 0 setdash 2 copy moveto + 2 copy vpt 0 270 arc closepath fill + vpt 0 360 arc closepath} bind def +/C8 {BL [] 0 setdash 2 copy moveto + 2 copy vpt 270 360 arc closepath fill + vpt 0 360 arc closepath} bind def +/C9 {BL [] 0 setdash 2 copy moveto + 2 copy vpt 270 450 arc closepath fill + vpt 0 360 arc closepath} bind def +/C10 {BL [] 0 setdash 2 copy 2 copy moveto vpt 270 360 arc closepath fill + 2 copy moveto + 2 copy vpt 90 180 arc closepath fill + vpt 0 360 arc closepath} bind def +/C11 {BL [] 0 setdash 2 copy moveto + 2 copy vpt 0 180 arc closepath fill + 2 copy moveto + 2 copy vpt 270 360 arc closepath fill + vpt 0 360 arc closepath} bind def +/C12 {BL [] 0 setdash 2 copy moveto + 2 copy vpt 180 360 arc closepath fill + vpt 0 360 arc closepath} bind def +/C13 {BL [] 0 setdash 2 copy moveto + 2 copy vpt 0 90 arc closepath fill + 2 copy moveto + 2 copy vpt 180 360 arc closepath fill + vpt 0 360 arc closepath} bind def +/C14 {BL [] 0 setdash 2 copy moveto + 2 copy vpt 90 360 arc closepath fill + vpt 0 360 arc} bind def +/C15 {BL [] 0 setdash 2 copy vpt 0 360 arc closepath fill + vpt 0 360 arc closepath} bind def +/Rec {newpath 4 2 roll moveto 1 index 0 rlineto 0 exch rlineto + neg 0 rlineto closepath} bind def +/Square {dup Rec} bind def +/Bsquare {vpt sub exch vpt sub exch vpt2 Square} bind def +/S0 {BL [] 0 setdash 2 copy moveto 0 vpt rlineto BL Bsquare} bind def +/S1 {BL [] 0 setdash 2 copy vpt Square fill Bsquare} bind def +/S2 {BL [] 0 setdash 2 copy exch vpt sub exch vpt Square fill Bsquare} bind def +/S3 {BL [] 0 setdash 2 copy exch vpt sub exch vpt2 vpt Rec fill Bsquare} bind def +/S4 {BL [] 0 setdash 2 copy exch vpt sub exch vpt sub vpt Square fill Bsquare} bind def +/S5 {BL [] 0 setdash 2 copy 2 copy vpt Square fill + exch vpt sub exch vpt sub vpt Square fill Bsquare} bind def +/S6 {BL [] 0 setdash 2 copy exch vpt sub exch vpt sub vpt vpt2 Rec fill Bsquare} bind def +/S7 {BL [] 0 setdash 2 copy exch vpt sub exch vpt sub vpt vpt2 Rec fill + 2 copy vpt Square fill Bsquare} bind def +/S8 {BL [] 0 setdash 2 copy vpt sub vpt Square fill Bsquare} bind def +/S9 {BL [] 0 setdash 2 copy vpt sub vpt vpt2 Rec fill Bsquare} bind def +/S10 {BL [] 0 setdash 2 copy vpt sub vpt Square fill 2 copy exch vpt sub exch vpt Square fill + Bsquare} bind def +/S11 {BL [] 0 setdash 2 copy vpt sub vpt Square fill 2 copy exch vpt sub exch vpt2 vpt Rec fill + Bsquare} bind def +/S12 {BL [] 0 setdash 2 copy exch vpt sub exch vpt sub vpt2 vpt Rec fill Bsquare} bind def +/S13 {BL [] 0 setdash 2 copy exch vpt sub exch vpt sub vpt2 vpt Rec fill + 2 copy vpt Square fill Bsquare} bind def +/S14 {BL [] 0 setdash 2 copy exch vpt sub exch vpt sub vpt2 vpt Rec fill + 2 copy exch vpt sub exch vpt Square fill Bsquare} bind def +/S15 {BL [] 0 setdash 2 copy Bsquare fill Bsquare} bind def +/D0 {gsave translate 45 rotate 0 0 S0 stroke grestore} bind def +/D1 {gsave translate 45 rotate 0 0 S1 stroke grestore} bind def +/D2 {gsave translate 45 rotate 0 0 S2 stroke grestore} bind def +/D3 {gsave translate 45 rotate 0 0 S3 stroke grestore} bind def +/D4 {gsave translate 45 rotate 0 0 S4 stroke grestore} bind def +/D5 {gsave translate 45 rotate 0 0 S5 stroke grestore} bind def +/D6 {gsave translate 45 rotate 0 0 S6 stroke grestore} bind def +/D7 {gsave translate 45 rotate 0 0 S7 stroke grestore} bind def +/D8 {gsave translate 45 rotate 0 0 S8 stroke grestore} bind def +/D9 {gsave translate 45 rotate 0 0 S9 stroke grestore} bind def +/D10 {gsave translate 45 rotate 0 0 S10 stroke grestore} bind def +/D11 {gsave translate 45 rotate 0 0 S11 stroke grestore} bind def +/D12 {gsave translate 45 rotate 0 0 S12 stroke grestore} bind def +/D13 {gsave translate 45 rotate 0 0 S13 stroke grestore} bind def +/D14 {gsave translate 45 rotate 0 0 S14 stroke grestore} bind def +/D15 {gsave translate 45 rotate 0 0 S15 stroke grestore} bind def +/DiaE {stroke [] 0 setdash vpt add M + hpt neg vpt neg V hpt vpt neg V + hpt vpt V hpt neg vpt V closepath stroke} def +/BoxE {stroke [] 0 setdash exch hpt sub exch vpt add M + 0 vpt2 neg V hpt2 0 V 0 vpt2 V + hpt2 neg 0 V closepath stroke} def +/TriUE {stroke [] 0 setdash vpt 1.12 mul add M + hpt neg vpt -1.62 mul V + hpt 2 mul 0 V + hpt neg vpt 1.62 mul V closepath stroke} def +/TriDE {stroke [] 0 setdash vpt 1.12 mul sub M + hpt neg vpt 1.62 mul V + hpt 2 mul 0 V + hpt neg vpt -1.62 mul V closepath stroke} def +/PentE {stroke [] 0 setdash gsave + translate 0 hpt M 4 {72 rotate 0 hpt L} repeat + closepath stroke grestore} def +/CircE {stroke [] 0 setdash + hpt 0 360 arc stroke} def +/Opaque {gsave closepath 1 setgray fill grestore 0 setgray closepath} def +/DiaW {stroke [] 0 setdash vpt add M + hpt neg vpt neg V hpt vpt neg V + hpt vpt V hpt neg vpt V Opaque stroke} def +/BoxW {stroke [] 0 setdash exch hpt sub exch vpt add M + 0 vpt2 neg V hpt2 0 V 0 vpt2 V + hpt2 neg 0 V Opaque stroke} def +/TriUW {stroke [] 0 setdash vpt 1.12 mul add M + hpt neg vpt -1.62 mul V + hpt 2 mul 0 V + hpt neg vpt 1.62 mul V Opaque stroke} def +/TriDW {stroke [] 0 setdash vpt 1.12 mul sub M + hpt neg vpt 1.62 mul V + hpt 2 mul 0 V + hpt neg vpt -1.62 mul V Opaque stroke} def +/PentW {stroke [] 0 setdash gsave + translate 0 hpt M 4 {72 rotate 0 hpt L} repeat + Opaque stroke grestore} def +/CircW {stroke [] 0 setdash + hpt 0 360 arc Opaque stroke} def +/BoxFill {gsave Rec 1 setgray fill grestore} def +/Density { + /Fillden exch def + currentrgbcolor + /ColB exch def /ColG exch def /ColR exch def + /ColR ColR Fillden mul Fillden sub 1 add def + /ColG ColG Fillden mul Fillden sub 1 add def + /ColB ColB Fillden mul Fillden sub 1 add def + ColR ColG ColB setrgbcolor} def +/BoxColFill {gsave Rec PolyFill} def +/PolyFill {gsave Density fill grestore grestore} def +/h {rlineto rlineto rlineto gsave closepath fill grestore} bind def +% +% PostScript Level 1 Pattern Fill routine for rectangles +% Usage: x y w h s a XX PatternFill +% x,y = lower left corner of box to be filled +% w,h = width and height of box +% a = angle in degrees between lines and x-axis +% XX = 0/1 for no/yes cross-hatch +% +/PatternFill {gsave /PFa [ 9 2 roll ] def + PFa 0 get PFa 2 get 2 div add PFa 1 get PFa 3 get 2 div add translate + PFa 2 get -2 div PFa 3 get -2 div PFa 2 get PFa 3 get Rec + gsave 1 setgray fill grestore clip + currentlinewidth 0.5 mul setlinewidth + /PFs PFa 2 get dup mul PFa 3 get dup mul add sqrt def + 0 0 M PFa 5 get rotate PFs -2 div dup translate + 0 1 PFs PFa 4 get div 1 add floor cvi + {PFa 4 get mul 0 M 0 PFs V} for + 0 PFa 6 get ne { + 0 1 PFs PFa 4 get div 1 add floor cvi + {PFa 4 get mul 0 2 1 roll M PFs 0 V} for + } if + stroke grestore} def +% +/languagelevel where + {pop languagelevel} {1} ifelse + 2 lt + {/InterpretLevel1 true def} + {/InterpretLevel1 Level1 def} + ifelse +% +% PostScript level 2 pattern fill definitions +% +/Level2PatternFill { +/Tile8x8 {/PaintType 2 /PatternType 1 /TilingType 1 /BBox [0 0 8 8] /XStep 8 /YStep 8} + bind def +/KeepColor {currentrgbcolor [/Pattern /DeviceRGB] setcolorspace} bind def +<< Tile8x8 + /PaintProc {0.5 setlinewidth pop 0 0 M 8 8 L 0 8 M 8 0 L stroke} +>> matrix makepattern +/Pat1 exch def +<< Tile8x8 + /PaintProc {0.5 setlinewidth pop 0 0 M 8 8 L 0 8 M 8 0 L stroke + 0 4 M 4 8 L 8 4 L 4 0 L 0 4 L stroke} +>> matrix makepattern +/Pat2 exch def +<< Tile8x8 + /PaintProc {0.5 setlinewidth pop 0 0 M 0 8 L + 8 8 L 8 0 L 0 0 L fill} +>> matrix makepattern +/Pat3 exch def +<< Tile8x8 + /PaintProc {0.5 setlinewidth pop -4 8 M 8 -4 L + 0 12 M 12 0 L stroke} +>> matrix makepattern +/Pat4 exch def +<< Tile8x8 + /PaintProc {0.5 setlinewidth pop -4 0 M 8 12 L + 0 -4 M 12 8 L stroke} +>> matrix makepattern +/Pat5 exch def +<< Tile8x8 + /PaintProc {0.5 setlinewidth pop -2 8 M 4 -4 L + 0 12 M 8 -4 L 4 12 M 10 0 L stroke} +>> matrix makepattern +/Pat6 exch def +<< Tile8x8 + /PaintProc {0.5 setlinewidth pop -2 0 M 4 12 L + 0 -4 M 8 12 L 4 -4 M 10 8 L stroke} +>> matrix makepattern +/Pat7 exch def +<< Tile8x8 + /PaintProc {0.5 setlinewidth pop 8 -2 M -4 4 L + 12 0 M -4 8 L 12 4 M 0 10 L stroke} +>> matrix makepattern +/Pat8 exch def +<< Tile8x8 + /PaintProc {0.5 setlinewidth pop 0 -2 M 12 4 L + -4 0 M 12 8 L -4 4 M 8 10 L stroke} +>> matrix makepattern +/Pat9 exch def +/Pattern1 {PatternBgnd KeepColor Pat1 setpattern} bind def +/Pattern2 {PatternBgnd KeepColor Pat2 setpattern} bind def +/Pattern3 {PatternBgnd KeepColor Pat3 setpattern} bind def +/Pattern4 {PatternBgnd KeepColor Landscape {Pat5} {Pat4} ifelse setpattern} bind def +/Pattern5 {PatternBgnd KeepColor Landscape {Pat4} {Pat5} ifelse setpattern} bind def +/Pattern6 {PatternBgnd KeepColor Landscape {Pat9} {Pat6} ifelse setpattern} bind def +/Pattern7 {PatternBgnd KeepColor Landscape {Pat8} {Pat7} ifelse setpattern} bind def +} def +% +% +%End of PostScript Level 2 code +% +/PatternBgnd { + TransparentPatterns {} {gsave 1 setgray fill grestore} ifelse +} def +% +% Substitute for Level 2 pattern fill codes with +% grayscale if Level 2 support is not selected. +% +/Level1PatternFill { +/Pattern1 {0.250 Density} bind def +/Pattern2 {0.500 Density} bind def +/Pattern3 {0.750 Density} bind def +/Pattern4 {0.125 Density} bind def +/Pattern5 {0.375 Density} bind def +/Pattern6 {0.625 Density} bind def +/Pattern7 {0.875 Density} bind def +} def +% +% Now test for support of Level 2 code +% +Level1 {Level1PatternFill} {Level2PatternFill} ifelse +% +/Symbol-Oblique /Symbol findfont [1 0 .167 1 0 0] makefont +dup length dict begin {1 index /FID eq {pop pop} {def} ifelse} forall +currentdict end definefont pop +/MFshow { + { dup 5 get 3 ge + { 5 get 3 eq {gsave} {grestore} ifelse } + {dup dup 0 get findfont exch 1 get scalefont setfont + [ currentpoint ] exch dup 2 get 0 exch R dup 5 get 2 ne {dup dup 6 + get exch 4 get {Gshow} {stringwidth pop 0 R} ifelse }if dup 5 get 0 eq + {dup 3 get {2 get neg 0 exch R pop} {pop aload pop M} ifelse} {dup 5 + get 1 eq {dup 2 get exch dup 3 get exch 6 get stringwidth pop -2 div + dup 0 R} {dup 6 get stringwidth pop -2 div 0 R 6 get + show 2 index {aload pop M neg 3 -1 roll neg R pop pop} {pop pop pop + pop aload pop M} ifelse }ifelse }ifelse } + ifelse } + forall} def +/Gswidth {dup type /stringtype eq {stringwidth} {pop (n) stringwidth} ifelse} def +/MFwidth {0 exch { dup 5 get 3 ge { 5 get 3 eq { 0 } { pop } ifelse } + {dup 3 get{dup dup 0 get findfont exch 1 get scalefont setfont + 6 get Gswidth pop add} {pop} ifelse} ifelse} forall} def +/MLshow { currentpoint stroke M + 0 exch R + Blacktext {gsave 0 setgray MFshow grestore} {MFshow} ifelse } bind def +/MRshow { currentpoint stroke M + exch dup MFwidth neg 3 -1 roll R + Blacktext {gsave 0 setgray MFshow grestore} {MFshow} ifelse } bind def +/MCshow { currentpoint stroke M + exch dup MFwidth -2 div 3 -1 roll R + Blacktext {gsave 0 setgray MFshow grestore} {MFshow} ifelse } bind def +/XYsave { [( ) 1 2 true false 3 ()] } bind def +/XYrestore { [( ) 1 2 true false 4 ()] } bind def +end +%%EndProlog +%%Page: 1 1 +gnudict begin +gsave +doclip +50 50 translate +0.100 0.100 scale +90 rotate +0 -5040 translate +0 setgray +newpath +(Helvetica) findfont 140 scalefont setfont +1.000 UL +LTb +686 922 M +63 0 V +stroke +602 922 M +[ [(Helvetica) 140.0 0.0 true true 0 ( 50)] +] -46.7 MRshow +1.000 UL +LTb +686 1405 M +63 0 V +stroke +602 1405 M +[ [(Helvetica) 140.0 0.0 true true 0 ( 100)] +] -46.7 MRshow +1.000 UL +LTb +686 1888 M +63 0 V +stroke +602 1888 M +[ [(Helvetica) 140.0 0.0 true true 0 ( 150)] +] -46.7 MRshow +1.000 UL +LTb +686 2372 M +63 0 V +stroke +602 2372 M +[ [(Helvetica) 140.0 0.0 true true 0 ( 200)] +] -46.7 MRshow +1.000 UL +LTb +686 2855 M +63 0 V +stroke +602 2855 M +[ [(Helvetica) 140.0 0.0 true true 0 ( 250)] +] -46.7 MRshow +1.000 UL +LTb +686 448 M +0 63 V +stroke +686 308 M +[ [(Helvetica) 140.0 0.0 true true 0 ( 0)] +] -46.7 MCshow +1.000 UL +LTb +1109 448 M +0 63 V +stroke +1109 308 M +[ [(Helvetica) 140.0 0.0 true true 0 ( 1000)] +] -46.7 MCshow +1.000 UL +LTb +1531 448 M +0 63 V +stroke +1531 308 M +[ [(Helvetica) 140.0 0.0 true true 0 ( 2000)] +] -46.7 MCshow +1.000 UL +LTb +1954 448 M +0 63 V +stroke +1954 308 M +[ [(Helvetica) 140.0 0.0 true true 0 ( 3000)] +] -46.7 MCshow +1.000 UL +LTb +2377 448 M +0 63 V +stroke +2377 308 M +[ [(Helvetica) 140.0 0.0 true true 0 ( 4000)] +] -46.7 MCshow +1.000 UL +LTb +2799 448 M +0 63 V +stroke +2799 308 M +[ [(Helvetica) 140.0 0.0 true true 0 ( 5000)] +] -46.7 MCshow +1.000 UL +LTb +3222 448 M +0 63 V +stroke +3222 308 M +[ [(Helvetica) 140.0 0.0 true true 0 ( 6000)] +] -46.7 MCshow +1.000 UL +LTb +3644 448 M +0 63 V +stroke +3644 308 M +[ [(Helvetica) 140.0 0.0 true true 0 ( 7000)] +] -46.7 MCshow +1.000 UL +LTb +4067 448 M +0 63 V +stroke +4067 308 M +[ [(Helvetica) 140.0 0.0 true true 0 ( 8000)] +] -46.7 MCshow +1.000 UL +LTb +1.000 UL +LTb +686 2855 M +686 448 L +3381 0 V +0 2407 R +-3381 0 R +stroke +LCb setrgbcolor +112 1651 M +currentpoint gsave translate -270 rotate 0 0 moveto +[ [(Helvetica) 140.0 0.0 true true 0 (Ratio of Total Execution to Total Work)] +] -46.7 MCshow +grestore +LTb +LCb setrgbcolor +2376 98 M +[ [(Helvetica) 140.0 0.0 true true 0 (Cycles in one Task)] +] -46.7 MCshow +LTb +1.000 UP +1.000 UL +LTb +LCb setrgbcolor +3532 2882 M +[ [(Helvetica) 140.0 0.0 true true 0 (pthreads)] +] -46.7 MCshow +LTb +1.000 UL +LTb +2787 2252 N +0 700 V +1491 0 V +0 -700 V +-1491 0 V +Z stroke +2787 2812 M +1491 0 V +% Begin plot #1 +stroke +4.000 UL +LT5 +LC7 setrgbcolor +LCb setrgbcolor +3711 2742 M +[ [(Helvetica) 140.0 0.0 true true 0 (80 Threads)] +] -46.7 MRshow +LT5 +LC7 setrgbcolor +3795 2742 M +399 0 V +1735 2855 M +662 -919 V +4067 1238 L +% End plot #1 +% Begin plot #2 +stroke +LT6 +LCb setrgbcolor +3711 2602 M +[ [(Helvetica) 140.0 0.0 true true 0 (160 Threads)] +] -46.7 MRshow +LT6 +3795 2602 M +399 0 V +1748 2855 M +2555 1723 L +4067 1065 L +% End plot #2 +% Begin plot #3 +stroke +LT7 +LC1 setrgbcolor +LCb setrgbcolor +3711 2462 M +[ [(Helvetica) 140.0 0.0 true true 0 (320 Threads)] +] -46.7 MRshow +LT7 +LC1 setrgbcolor +3795 2462 M +399 0 V +1420 2855 M +170 -542 V +784 -867 V +3986 870 L +% End plot #3 +% Begin plot #4 +stroke +LT8 +LCb setrgbcolor +3711 2322 M +[ [(Helvetica) 140.0 0.0 true true 0 (640 Threads)] +] -46.7 MRshow +LT8 +3795 2322 M +399 0 V +1802 2855 M +572 -574 V +4007 1207 L +% End plot #4 +stroke +1.000 UL +LTb +686 2855 M +686 448 L +3381 0 V +0 2407 R +-3381 0 R +1.000 UP +686 922 M +63 0 V +stroke +602 922 M +[ [(Helvetica) 140.0 0.0 true true 0 ( 50)] +] -46.7 MRshow +1.000 UL +LTb +686 1405 M +63 0 V +stroke +602 1405 M +[ [(Helvetica) 140.0 0.0 true true 0 ( 100)] +] -46.7 MRshow +1.000 UL +LTb +686 1888 M +63 0 V +stroke +602 1888 M +[ [(Helvetica) 140.0 0.0 true true 0 ( 150)] +] -46.7 MRshow +1.000 UL +LTb +686 2372 M +63 0 V +stroke +602 2372 M +[ [(Helvetica) 140.0 0.0 true true 0 ( 200)] +] -46.7 MRshow +1.000 UL +LTb +686 2855 M +63 0 V +stroke +602 2855 M +[ [(Helvetica) 140.0 0.0 true true 0 ( 250)] +] -46.7 MRshow +1.000 UL +LTb +686 448 M +0 63 V +stroke +686 308 M +[ [(Helvetica) 140.0 0.0 true true 0 ( 0)] +] -46.7 MCshow +1.000 UL +LTb +1109 448 M +0 63 V +stroke +1109 308 M +[ [(Helvetica) 140.0 0.0 true true 0 ( 1000)] +] -46.7 MCshow +1.000 UL +LTb +1531 448 M +0 63 V +stroke +1531 308 M +[ [(Helvetica) 140.0 0.0 true true 0 ( 2000)] +] -46.7 MCshow +1.000 UL +LTb +1954 448 M +0 63 V +stroke +1954 308 M +[ [(Helvetica) 140.0 0.0 true true 0 ( 3000)] +] -46.7 MCshow +1.000 UL +LTb +2377 448 M +0 63 V +stroke +2377 308 M +[ [(Helvetica) 140.0 0.0 true true 0 ( 4000)] +] -46.7 MCshow +1.000 UL +LTb +2799 448 M +0 63 V +stroke +2799 308 M +[ [(Helvetica) 140.0 0.0 true true 0 ( 5000)] +] -46.7 MCshow +1.000 UL +LTb +3222 448 M +0 63 V +stroke +3222 308 M +[ [(Helvetica) 140.0 0.0 true true 0 ( 6000)] +] -46.7 MCshow +1.000 UL +LTb +3644 448 M +0 63 V +stroke +3644 308 M +[ [(Helvetica) 140.0 0.0 true true 0 ( 7000)] +] -46.7 MCshow +1.000 UL +LTb +4067 448 M +0 63 V +stroke +4067 308 M +[ [(Helvetica) 140.0 0.0 true true 0 ( 8000)] +] -46.7 MCshow +1.000 UL +LTb +1.000 UL +LTb +686 2855 M +686 448 L +3381 0 V +0 2407 R +-3381 0 R +stroke +LCb setrgbcolor +112 1651 M +currentpoint gsave translate -270 rotate 0 0 moveto +[ [(Helvetica) 140.0 0.0 true true 0 (Ratio of Total Execution to Total Work)] +] -46.7 MCshow +grestore +LTb +LCb setrgbcolor +2376 98 M +[ [(Helvetica) 140.0 0.0 true true 0 (Cycles in one Task)] +] -46.7 MCshow +LTb +1.000 UP +1.000 UL +LTb +LCb setrgbcolor +2011 2882 M +[ [(Helvetica) 140.0 0.0 true true 0 (Vthread)] +] -46.7 MCshow +LTb +1.000 UL +LTb +1266 2252 N +0 700 V +1491 0 V +0 -700 V +-1491 0 V +Z stroke +1266 2812 M +1491 0 V +% Begin plot #1 +stroke +4.000 UL +LT0 +LCb setrgbcolor +2190 2742 M +[ [(Helvetica) 140.0 0.0 true true 0 (80 Threads)] +] -46.7 MRshow +LT0 +2274 2742 M +399 0 V +743 626 M +22 -61 V +39 -36 V +75 -37 V +154 -17 V +303 -13 V +609 -7 V +1218 -2 V +904 -1 V +% End plot #1 +% Begin plot #2 +stroke +LT2 +LCb setrgbcolor +2190 2602 M +[ [(Helvetica) 140.0 0.0 true true 0 (160 Threads)] +] -46.7 MRshow +LT2 +2274 2602 M +399 0 V +743 575 M +24 4 V +36 -82 V +76 -20 V +153 -6 V +303 -12 V +609 -4 V +1217 -4 V +906 -1 V +% End plot #2 +% Begin plot #3 +stroke +LT3 +LCb setrgbcolor +2190 2462 M +[ [(Helvetica) 140.0 0.0 true true 0 (320 Threads)] +] -46.7 MRshow +LT3 +2274 2462 M +399 0 V +742 581 M +24 -38 V +39 -9 V +76 -41 V +151 -19 V +304 -11 V +610 -7 V +1216 -5 V +905 -1 V +% End plot #3 +% Begin plot #4 +stroke +LT4 +LCb setrgbcolor +2190 2322 M +[ [(Helvetica) 140.0 0.0 true true 0 (640 Threads)] +] -46.7 MRshow +LT4 +2274 2322 M +399 0 V +743 589 M +23 -41 V +38 -29 V +77 -20 V +151 -28 V +303 -12 V +610 -4 V +1217 -4 V +905 0 V +% End plot #4 +stroke +1.000 UL +LTb +686 2855 M +686 448 L +3381 0 V +0 2407 R +-3381 0 R +1.000 UP +stroke +grestore +end +showpage +%%Trailer +%%DocumentFonts: Helvetica +%%Pages: 1 diff -r 9b9a2497757d -r eb146c5c05a8 0__Papers/PRT/PRT__formal_def/helpers/07_F_26__The_Questions__blank.txt --- /dev/null Thu Jan 01 00:00:00 1970 +0000 +++ b/0__Papers/PRT/PRT__formal_def/helpers/07_F_26__The_Questions__blank.txt Sat Aug 03 19:24:22 2013 -0700 @@ -0,0 +1,100 @@ + + +1) What are the problems the authors are trying to solve? + When done, for each problem, how does one decide the value of a proposed solution? Suggest a priority domain for deciding whether to use a proposed solution. + +The problem is + +A priority domain for deciding the value of some proposed solution to this problem is + +The value of this solution is determined by + + + +2) What "things" does the proposed solution to this problem enable? + What benefit to reader is bought by each "thing", & what related to the "thing", gives the benefit. + What details are unique about the proposed solution that enables the thing that gives benefit? + How does that uniqueness enable or achieve the thing? + +It enables + +The benefit to me is + +Unique details of solution that enable the thing gives benefit are + +The uniqueness enables the thing that gives benefit by + + + +3) What are the fundamentals underlying the problem? + What makes this problem hard? + What are the basic elements and forces of the problem that the proposed solution has to be in terms of, avoid, use to advantage? ie: gravity, invariant relationships, market forces, human capacity (avg level of real programmers, hubris, legacy is held onto, barriers to adoption), and so on +How does the proposed solution work within/relate to/address/take advantage of/deal with the fundamentals underlying the problem? + +The fundamentals are + +The hard part is + +The basic elements are + +The proposed solution + + + +4) What are other approaches and conventional wisdom to solving these problems? + What benefits enabled by the proposed solution are not enabled by other work, and vice versa? + How does each approach address something the others miss? + Try to suggest groupings or categories for the various approaches. + Try to suggest ways multiple approaches may be combined to get more pros with fewer cons. + +Other approaches are + +A benefit enabled by the proposed that is not enabled by other work is + +Categories: + +Combining: + + + +5) What is/are the unique main "things" that enable what the proposed solution does? + Sketch the details of each of these "things". + Did you detect any drawbacks, not stated in the paper, from the details? + Did you see any really cool techniques? + +Unique main "things" are + +Drawbacks from details: + +Idea of + + + +6) What aspects of the implementation/proof/design need results given in order to convince you that the proposed solution delivers the stated benefits? + +They have to show + + + +7) What results did they show? + Did they show results in all the needed aspects (which were left out)? + Were the testing method and results shown good enough to convince you? + Did you detect any cons, not stated in the paper, from the results? + +They showed + +Con.. + + + +8) How do you think this work may provide some value to you in your future research? + +The work my provide value for me + + + +3 or more comments/questions: (pick out the most important things to you from the discussion you gave above, or add things that were not brought out by the above questions. I am asking for these as things to bring up during class). + +1) + + \ No newline at end of file diff -r 9b9a2497757d -r eb146c5c05a8 0__Papers/PRT/PRT__formal_def/helpers/bib_for_papers.bib --- /dev/null Thu Jan 01 00:00:00 1970 +0000 +++ b/0__Papers/PRT/PRT__formal_def/helpers/bib_for_papers.bib Sat Aug 03 19:24:22 2013 -0700 @@ -0,0 +1,1257 @@ + + + +"" +@Article{, + author = {}, + title = {}, + journal = {}, + volume = {}, + number = {}, + year = {}, + pages = {} +} + + + +"" +@Book{, + author = {}, + title = {}, + publisher = {}, + year = {}, + pages = {} +} + + + +"" +@misc{, + author = {}, + title = {}, + url = {} +} + + +"Lamport paper with clock sync" +@article{Lamport78, + author = {Lamport, Leslie}, + title = {Time, clocks, and the ordering of events in a distributed system}, + journal = {Commun. ACM}, + volume = {21}, + issue = {7}, + year = {1978}, + pages = {558--565}, + } + +"Lamport paper with mutex lock algorithm" +@article{Lamport87, + author = {Lamport, Leslie}, + title = {A fast mutual exclusion algorithm}, + journal = {ACM Trans. Comput. Syst.}, + volume = {5}, + issue = {1}, + year = {1987}, + pages = {1--11} +} + +"Dijkstra semaphore definition paper" +@inproceedings{Dijkstra67, + author = {Dijkstra, Edsger W.}, + title = {The structure of the "{THE}"-multiprogramming system}, + booktitle = {Proceedings of the first ACM symposium on Operating System Principles}, + series = {SOSP '67}, + year = {1967}, + pages = {10.1--10.6} + } + +"Original coroutine paper" +@article{Conway63, + author = {Conway, Melvin E.}, + title = {Design of a separable transition-diagram compiler}, + journal = {Commun. ACM}, + volume = {6}, + issue = {7}, + year = {1963}, + pages = {396--408} +} + +"Component model book Leavens G, Sitaraman M(eds.). Foundations of Component-Based Systems. Cambridge University Press: Cambridge, 2000" +@Book{ComponentModel00, + author = {G Leavens and M Sitaraman (eds)}, + title = {Foundations of Component-Based Systems}, + publisher = {Cambridge University Press}, + year = {2000} +} + + +"Hewitt Actors Ref on ArXiv" +@misc{Hewitt10, + author = {Carl Hewitt}, + title = {Actor Model of Computation}, + year = {2010}, + note = {http://arxiv.org/abs/1008.1459} +} + +"Actors paper -- AGHA has a 1985 tech report looks like it introduces Actors as an execution model..?" +@article{Actors97, +author = {Agha,G. and Mason,I. and Smith,S. and Talcott,C.}, +title = {A foundation for actor computation}, +journal = {Journal of Functional Programming}, +volume = {7}, +number = {01}, +pages = {1-72}, +year = {1997}, +} + +"Scheduler Activations: M onto N thread technique" +@article{SchedActivations, + author = {Anderson, Thomas E. and Bershad, Brian N. and Lazowska, Edward D. and Levy, Henry M.}, + title = {Scheduler activations: effective kernel support for the user-level management of parallelism}, + journal = {ACM Trans. Comput. Syst.}, + volume = {10}, + issue = {1}, + month = {February}, + year = {1992}, + pages = {53--79} +} + +"BOM in Manticore project: functional language for scheduling and concurrency" +@inproceedings{BOMinManticore, + author = {Fluet, Matthew and Rainey, Mike and Reppy, John and Shaw, Adam and Xiao, Yingqi}, + title = {Manticore: a heterogeneous parallel language}, + booktitle = {Proceedings of the 2007 workshop on Declarative aspects of multicore programming}, + series = {DAMP '07}, + year = {2007}, + pages = {37--44}, + numpages = {8} +} + + +//===================================== +"Gain from Chaos tech report" +@techreport + {Halle92, + Author = {Halle, K.S. and Chua, Leon O. and Anishchenko, V.S. and Safonova, M.A.}, + Title = {Signal Amplification via Chaos: Experimental Evidence}, + Institution = {EECS Department, University of California, Berkeley}, + Year = {1992}, + URL = {http://www.eecs.berkeley.edu/Pubs/TechRpts/1992/2223.html}, + Number = {UCB/ERL M92/130} +} + + +Reprinted in: +Madan, R. N. (1993) Chua’s Circuit : A Paradigm for Chaos, World Scientific, Singapore. +"Signal Amplification via Chaos: Experimental Evidence" +K.S. Halle, Leon O. Chua, V.S. Anishchenko and M.A. Safonova +pgs 290-308 + + +"Spread Spectrum Communication Through Modulation of Chaos" +Halle K.S., Wu C.W., Itoh M., Chua L.O. Spread Spectrum Communication Through Modulation of Chaos. Int. J. of Bifur. and Chaos, (3):469–477. 1993. +cited by 232 + + +"Experimental Demonstration of Secure Communications Via Chaotic Synchronization" +Kocarev V, Halle K.S., Eckert K., Chua L.O., Parlitz V. Experimental Demonstration of Secure Communications Via Chaotic Synchronization. Int. J. Bifur. and Chaos, (2):709 713. 1992. + + +//========================================== + +"BLIS 2010 HotPar: Leveraging Semantics Attached to Function Calls to Isolate Applications from Hardware" +@inproceedings + {BLISInHotPar, + author = {Sean Halle and Albert Cohen}, + booktitle = {HOTPAR '10: USENIX Workshop on Hot Topics in Parallelism}, + month = {June}, + title = {Leveraging Semantics Attached to Function Calls to Isolate Applications from Hardware}, + year = {2010} + } + +"2011 HotPar: " +@inproceedings + {HotPar11, + author = {Sean Halle and Albert Cohen}, + booktitle = {HOTPAR '11: USENIX Workshop on Hot Topics in Parallelism}, + month = {May}, + title = {}, + year = {2011} + } + +"VMS in LCPC 2011" +@article{VMSLCPC, + author = {Sean Halle and Albert Cohen}, + title = {A Mutable Hardware Abstraction to Replace Threads}, + journal = {24th International Workshop on Languages and Compilers for Parallel Languages (LCPC11)}, + year = {2011} +} + + +"A Framework to Support Research on Portable High Performance Parallelism" +@misc{FrameworkTechRep, + Author = {Halle, Sean and Nadezhkin, Dmitry and Cohen, Albert}, + Note = {http://www.soe.ucsc.edu/share/technical-reports/2010/ucsc-soe-10-02.pdf}, + Title = {A Framework to Support Research on Portable High Performance Parallelism}, + Year = 2010 +} + +"DKU Pattern for Performance Portable Parallel Software" +@misc{DKUTechRep, + Author = {Halle, Sean and Cohen, Albert}, + Note = {http://www.soe.ucsc.edu/share/technical-reports/2009/ucsc-soe-09-06.pdf}, + Title = {DKU Pattern for Performance Portable Parallel Software}, + Year = 2009 +} + +"An Extensible Parallel Language" +@misc{EQNLangTechRep, + Author = {Halle, Sean}, + Note = {http://www.soe.ucsc.edu/share/technical-reports/2009/ucsc-soe-09-16.pdf}, + Title = {An Extensible Parallel Language}, + Year = 2009 +} + +"A Hardware-Independent Parallel Operating System Abstraction Layer" +@misc{CTOSTechRep, + Author = {Halle, Sean}, + Note = {http://www.soe.ucsc.edu/share/technical-reports/2009/ucsc-soe-09-15.pdf}, + Title = {A Hardware-Independent Parallel Operating System Abstraction LayerParallelism}, + Year = 2009 +} + +"Parallel Language Extensions for Side Effects" +@misc{SideEffectsTechRep, + Author = {Halle, Sean and Cohen, Albert}, + Note = {http://www.soe.ucsc.edu/share/technical-reports/2009/ucsc-soe-09-14.pdf}, + Title = {Parallel Language Extensions for Side Effects}, + Year = 2009 +} + + +"BaCTiL: Base CodeTime Language" +@misc{BaCTiLTechRep, + Author = {Halle, Sean}, + Note = {http://www.soe.ucsc.edu/share/technical-reports/2006/ucsc-crl-06-08.pdf}, + Title = {BaCTiL: Base CodeTime Language}, + Year = 2006 +} + + +"The Elements of the CodeTime Software Platform" +@misc{CTPlatformTechRep, + Author = {Halle, Sean}, + Note = {http://www.soe.ucsc.edu/share/technical-reports/2006/ucsc-crl-06-09.pdf}, + Title = {The Elements of the CodeTime Software Platform}, + Year = 2006 +} + + +"A Scalable and Efficient Peer-to-Peer Run-Time System for a Hardware Independent Software Platform" +@misc{CTRTTechRep, + Author = {Halle, Sean}, + Note = {http://www.soe.ucsc.edu/share/technical-reports/2006/ucsc-crl-06-10.pdf}, + Title = {A Scalable and Efficient Peer-to-Peer Run-Time System for a Hardware Independent Software Platform}, + Year = 2006 +} + + +"The Big-Step Operational Semantics of CodeTime Circuits" +@misc{FrameworkTechRep, + Author = {Halle, Sean}, + Note = {http://www.soe.ucsc.edu/share/technical-reports/2006/ucsc-crl-06-11.pdf}, + Title = {The Big-Step Operational Semantics of CodeTime Circuits}, + Year = 2006 +} + + +"A Mental Framework for use in Creating Hardware Independent Parallel Languages" +@misc{FrameworkTechRep, + Author = {Halle, Sean}, + Note = {http://www.soe.ucsc.edu/share/technical-reports/2006/ucsc-crl-06-12.pdf}, + Title = {A Mental Framework for use in Creating Hardware Independent Parallel Languages}, + Year = 2006 +} + + +"The Case for an Integrated Software Platform for HEC Illustrated Using the CodeTime Platform" +@misc{CIPTechRep, + Author = {Halle, Sean}, + Note = {http://www.soe.ucsc.edu/share/technical-reports/2005/ucsc-crl-05-05.pdf}, + Title = {The Case for an Integrated Software Platform for HEC Illustrated Using the CodeTime Platform}, + Year = 2005 +} + +//========================================== + + +"OMP Hompe page" +@misc{OMPHome, + Note = {http://www.openmediaplatform.eu/}, + Title = {{Open Media Platform} homepage}, +} + +"The OMP infrastructure site" +@misc{Halle2008, + Author = {Sean Halle and Albert Cohen}, + Note = {http://omp.musictwodotoh.com}, + Title = {{DKU} infrastructure server} +} + + + +"The DKU sourceforge site" +@misc{DKUSourceForge, + Author = {Sean Halle and Albert Cohen}, + Month = {November}, + Note = {http://dku.sourceforge.net}, + Title = {{DKU} website}, + Year = {2008} +} + + +"The BLIS sourceforge site" +@misc{BLISHome, + Author = {Sean Halle and Albert Cohen}, + Month = {November}, + Note = {http://blisplatform.sourceforge.net}, + Title = {{BLIS} website}, + Year = {2008} +} + + +"The VMS Home page" +@misc{VMSHome, + Author = {Sean Halle and Merten Sach and Ben Juurlink and Albert Cohen}, + Note = {http://virtualizedmasterslave.org}, + Title = {{VMS} Home Page}, + Year = {2010} +} + + +"The PStack Home page" +@misc{PStackHome, + Author = {Sean Halle}, + Note = {http://pstack.sourceforge.net}, + Title = {{PStack} Home Page}, + Year = {2012} +} + + +"Deblocking code in SVN" +@misc{DeblockingCode, + Note = {http://dku.svn.sourceforge.net/viewvc/dku/branches/DKU\_C\_\_Deblocking\_\_orig/}, + Title ={{DKU-ized Deblocking Filter} code} +} + + + +"Sample code on BLIS site" +@misc{SampleBLISCode, + Note = {http://dku.sourceforge.net/SampleCode.htm}, + Title ={{Sample BLIS Code}} +} + +"Framework Technical Report" +@misc{FrameworkTechRep, + Author = {Halle, Sean and Nadezhkin, Dmitry and Cohen, Albert}, + Note = {http://www.soe.ucsc.edu/share/technical-reports/2010/ucsc-soe-10-02.pdf}, + Title = {A Framework to Support Research on Portable High Performance Parallelism} +} + +"Map reduce" +@misc{MapReduceHome, + Author = {Google Corp.}, + Note = {http://labs.google.com/papers/mapreduce.html}, + Title = {{MapReduce} Home page}, +} + + +"TBB Thread Building Blocks" +@misc{TBBHome, + Author = {Intel Corp.}, + Note = {http://www.threadingbuildingblocks.org}, + Title = {{TBB} Home page}, +} + + +"HPF Wikipedia entry" +@misc{HPFWikipedia, + Author = {Wikipedia}, + Note = {http://en.wikipedia.org/wiki/High_Performance_Fortran}, + Title = {{HPF} wikipedia page}, +} + + +"OpenMP Home page" +@misc{OpenMPHome, + Author = {{OpenMP} organization}, + Note = {http://www.openmp.org}, + Title = {{OpenMP} Home page} +} + + + +"Open MPI Home page" +@misc{MPIHome, + Author = {open-mpi organization}, + Note = {http://www.open-mpi.org}, + Title = {{Open MPI} Home page} +} + +"OpenCL Home page" +@misc{OpenCLHome, + Author = {Kronos Group}, + Note = {http://www.khronos.org/opencl}, + Title = {{OpenCL} Home page} +} + + +"CILK Hompe page" +@misc{CILKHome, + Author = {Cilk group at MIT}, + Note = {http://supertech.csail.mit.edu/cilk/}, + Title = {{CILK} homepage}, +} + +@InProceedings{Fri98, + author = {M. Frigo and C. E. Leiserson and K. H. Randall}, + title = {The Implementation of the Cilk-5 Multithreaded Language}, + booktitle = {PLDI '98: Proceedings of the 1998 ACM SIGPLAN conference on Programming language design and implementation}, + pages = {212--223}, + year = 1998, + address = {Montreal, Quebec}, + month = jun +} + + +"Titanium Hompe page" +@misc{TitaniumHome, + Note = {http://titanium.cs.berkeley.edu}, + Title = {{Titanium} homepage} +} + + +"CnC in HotPar" +@inproceedings{CnCInHotPar, + author = {Knobe, Kathleen}, + booktitle = {HOTPAR '09: USENIX Workshop on Hot Topics in Parallelism}, + month = {March}, + title = {Ease of Use with Concurrent Collections {(CnC)}}, + year = {2009} +} + + +"CnC Hompe page" +@misc{CnCHome, + Author = {Intel Corp.}, + Note = {http://software.intel.com/en-us/articles/intel-concurrent-collections-for-cc/}, + Title = {{CnC} homepage}, +} + +"Spiral Home page" +@misc{SpiralHome, + Author = {Spiral Group at CMU}, + Note = {http://www.spiral.net}, + Title = {{Spiral} homepage}, +} + + +"Scala Hompe page" +@misc{ScalaHome, + Author = {Scala organization}, + Note = {http://www.scala-lang.org/}, + Title = {{Scala} homepage}, +} + + + + +"UPC Hompe page" +@misc{UPCHome, + Author = {UPC group at UC Berkeley}, + Note = {http://upc.lbl.gov/}, + Title = {{Unified Parallel C} homepage}, +} + + +"Suif Hompe page" +@misc{SuifHome, + Note = {http://suif.stanford.edu}, + Title = {{Suif} Parallelizing compiler homepage}, +} + + + +"SEJITS" +@article{SEJITS, + author = {B. Catanzaro and S. Kamil and Y. Lee and K. Asanovic and J. Demmel and K. Keutzer and J. Shalf and K. Yelick and A. Fox}, + title = {SEJITS: Getting Productivity AND Performance With Selective Embedded JIT Specialization}, + journal = {First Workshop on Programmable Models for Emerging Architecture at the 18th International Conference on Parallel Architectures and Compilation Techniques }, + year = {2009} +} + + +"Arnaldo 3D parallel on NXP chip" +@inproceedings{Arnaldo3D, + author = {Azevedo, Arnaldo and Meenderinck, Cor and Juurlink, Ben and Terechko, Andrei and Hoogerbrugge, Jan and Alvarez, Mauricio and Ramirez, Alex}, + title = {Parallel H.264 Decoding on an Embedded Multicore Processor}, + booktitle = {HiPEAC '09: Proceedings of the 4th International Conference on High Performance Embedded Architectures and Compilers}, + year = {2009}, + pages = {404--418} + } + + +"Narayanan's GPU scheduling tool" +@article{NarayananGPUSched, + author = {Narayanan Sundaram and Anand Raghunathan and Srimat T. Chakradhar}, + title = {A framework for efficient and scalable execution of domain-specific templates on GPUs}, + journal ={International Parallel and Distributed Processing Symposium {(IPDPS)}}, + year = {2009}, + pages = {1-12}, +} + +"Polyhedral for GPU from Ohio State" +@inproceedings{PolyForGPU, + author = {Baskaran, Muthu Manikandan and Bondhugula, Uday and Krishnamoorthy, Sriram and Ramanujam, J. and Rountev, Atanas and Sadayappan, P.}, + title = {A compiler framework for optimization of affine loop nests for gpgpus}, + booktitle = {ICS '08: Proceedings of the 22nd annual international conference on Supercomputing}, + year = {2008}, + pages = {225--234}, + } + +"Loulou's Polyhedral loop-nest optimization paper in PLDI 08" +@inproceedings{Loulou08, + author = {Pouchet, Louis-No\"{e}l and Bastoul, C\'{e}dric and Cohen, Albert and Cavazos, John}, + title = {Iterative optimization in the polyhedral model: part ii, multidimensional time}, + booktitle = {ACM SIGPLAN conference on Programming language design and implementation {(PLDI)} }, + year = {2008}, + pages = {90--100}, + } + + +"Merge in HotPar" +@inproceedings{MergeInHotPar, + author = {Michael D. Linderman and James Balfour and Teresa H. Meng and William J. Dally}, + booktitle = {HOTPAR '09: USENIX Workshop on Hot Topics in Parallelism}, + month = {March}, + title = {Embracing Heterogeneity \- Parallel Programming for Changing Hardware}, + year = {2009} +} + + +"Galois system for irregular problems" +@inproceedings{GaloisRef, + author = {Kulkarni, Milind and Pingali, Keshav and Walter, Bruce and Ramanarayanan, Ganesh and Bala, Kavita and Chew, L. Paul}, + title = {Optimistic parallelism requires abstractions}, + booktitle = {PLDI '07: Proceedings of the 2007 ACM SIGPLAN conference on Programming language design and implementation}, + year = {2007}, + pages = {211--222} +} + +"Cool compiler book that talks about balancing task size with machine characteristics.. the one Amit had" +@book{Allen2002, + author = {Kennedy, Ken and Allen, John R.}, + title = {Optimizing compilers for modern architectures: a dependence-based approach}, + year = {2002}, + publisher = {Morgan Kaufmann Publishers Inc.} + } + + +"Streaming languages and tools survery paper" +@MISC{Stephens95, + author = {R. Stephens}, + title = {A Survey Of Stream Processing}, + year = {1995} +} + + +"Capsule" +@INPROCEEDINGS{Palatin06, + author = {P Palatin and Y Lhuillier and O Temam}, + title = {CAPSULE: Hardware-assisted parallel execution of componentbased programs}, + booktitle = {In Proceedings of the 39th Annual International Symposium on Microarchitecture}, + year = {2006}, + pages = {247--258} +} + +"Sequioa" +@inproceedings{Sequioa06, + author = {Fatahalian,, Kayvon and Horn,, Daniel Reiter and Knight,, Timothy J. and Leem,, Larkhoon and Houston,, Mike and Park,, Ji Young and Erez,, Mattan and Ren,, Manman and Aiken,, Alex and Dally,, William J. and Hanrahan,, Pat}, + title = {Sequoia: programming the memory hierarchy}, + booktitle = {SC '06: Proceedings of the 2006 ACM/IEEE conference on Supercomputing}, + year = {2006}, + pages = {83} + } + + + + +"Cole meta skeletons book" +@Book{Cole89, + author = {M Cole}, + title = {Algorithmic skeletons: Structured management of parallel computation}, + publisher = {Pitman}, + year = {1989} +} + + +"Meta programming skeletons example" +@INPROCEEDINGS{Ginhac98, + author = {Dominique Ginhac and Jocelyn Serot and Jean Pierre Derutin}, + title = {Fast prototyping of image processing applications using functional skeletons on a MIMD-DM architecture}, + booktitle = {In IAPR Workshop on Machine Vision and Applications}, + year = {1998}, + pages = {468--471} +} + + +"Parallel Skeletons meta programming" +@inproceedings{Serot08MetaParallel, + author = {Serot, Jocelyn and Falcou, Joel}, + title = {Functional Meta-programming for Parallel Skeletons}, + booktitle = {ICCS '08: Proceedings of the 8th international conference on Computational Science, Part I}, + year = {2008}, + pages = {154--163} + } + + +"Random skeletons for parallel programming article with lots of citations" +@INPROCEEDINGS{Darlington93, + author = {J. Darlington and A. J. Field and P. G. Harrison and P. H. J. Kelly and D. W. N. Sharp and Q. Wu}, + title = {Parallel programming using skeleton functions}, + booktitle = {}, + year = {1993}, + pages = {146--160}, + publisher = {Springer-Verlag} +} + + +"View from Berkeley paper" +@article{Asanovic06BerkeleyView, + title={{The landscape of parallel computing research: A view from berkeley}}, + author={Asanovic, K. and Bodik, R. and Catanzaro, B.C. and Gebis, J.J. and Husbands, P. and Keutzer, K. and Patterson, D.A. and Plishker, W.L. and Shalf, J. and Williams, S.W. and others}, + journal={Electrical Engineering and Computer Sciences, University of California at Berkeley, Technical Report No. UCB/EECS-2006-183, December}, + volume={18}, + number={2006-183}, + pages={19}, + year={2006}, +} + + + + +"Berkeley Pattern Language" +@misc{BerkeleyPattLang, + Note = {http://parlab.eecs.berkeley.edu/wiki/patterns}, + Title = {{Berkeley Pattern Language}} +} + + +"Keutzer reccomended Parallel Prog Patterns book" +@book{Mattson04Patterns, + title={{Patterns for parallel programming}}, + author={Mattson, T. and Sanders, B. and Massingill, B.}, + year={2004}, + publisher={Addison-Wesley Professional} +} + + +"Skillicorn Parallel Languages Survery book" +@article{Skillicorn98, + title={{Models and languages for parallel computation}}, + author={Skillicorn, D.B. and Talia, D.}, + journal={ACM Computing Surveys (CSUR)}, + volume={30}, + number={2}, + pages={123--169}, + year={1998} +} + + + +"NESL language" +@conference{Blelloch93NESL, + title={{Implementation of a portable nested data-parallel language}}, + author={Blelloch, G.E. and Hardwick, J.C. and Chatterjee, S. and Sipelstein, J. and Zagha, M.}, + booktitle={Proceedings of the fourth ACM SIGPLAN symposium on Principles and practice of parallel programming}, + pages={102--111}, + year={1993}, + organization={ACM New York, NY, USA} +} + + +"Sisal" +@article{McgrawSisal, + title={{SISAL: Streams and iteration in a single assignment language: Reference manual version 1.2}}, + author={McGraw, J. and Skedzielewski, SK and Allan, SJ and Oldehoeft, RR and Glauert, J. and Kirkham, C. and Noyce, B. and Thomas, R.}, + journal={Manual M-146, Rev}, + volume={1} +} + + +"Linda" +@article{Gelernter85Linda, + title={{Generative communication in Linda}}, + author={Gelernter, D.}, + journal={ACM Transactions on Programming Languages and Systems (TOPLAS)}, + volume={7}, + number={1}, + pages={80--112}, + year={1985} +} + + +"ZPL" +@article{Lin94ZPL, + title={{ZPL: An array sublanguage}}, + author={Lin, C. and Snyder, L.}, + journal={Lecture Notes in Computer Science}, + volume={768}, + pages={96--114}, + year={1994} +} + + + + +// Visual programming +@article + { baecker97, + author = {Ron Baecker and Chris DiGiano and Aaron Marcus}, + title = {Software visualization for debugging}, + journal = {Communications of the ACM}, + volume = {40}, + number = {4}, + year = {1997}, + issn = {0001-0782}, + pages = {44--54}, + publisher = {ACM Press} + } + + +// Visual programming +@article + { ball96, + author = {T. A. Ball and S. G. Eick}, + title = {Software Visualization in the Large}, + journal ={IEEE Computer}, + volume = {29}, + number = {4}, + year = {1996}, + month = {apr}, + pages = {33--43} + } + + +// Milner references this, Chemical Abstract Machine +@book + {berry89, + title={{The chemical abstract machine}}, + author={Berry, G. and Boudol, G.}, + year={1989}, + publisher={ACM Press} +} + + +// Cilk reference +@article + {blumofe95, + author = {Robert D. Blumofe and Christopher F. Joerg and Bradley C. Kuszmaul and Charles E. Leiserson and Keith H. Randall and Yuli Zhou}, + title = {Cilk: an efficient multithreaded runtime system}, + journal = {SIGPLAN Not.}, + volume = {30}, + number = {8}, + year = {1995}, + pages = {207--216} + } + + +// this has 1440 citations, so throwing it in.. +// The complexity of symbolic checking of program correctness +@article + {burch90, + title={{Symbolic model checking: 10^{20} states and beyond}}, + author={Burch, JR and Clarke, EM and McMillan, KL and Dill, DL and Hwang, LJ}, + journal={Logic in Computer Science, 1990. LICS'90, Proceedings}, + pages={428--439}, + year={1990} +} + +@article + {chamberlain98, +author = {B. Chamberlain and S. Choi and E. Lewis and C. Lin and L. Snyder and W. Weathersby}, +title = {ZPL's WYSIWYG Performance Model}, +journal = {hips}, +volume = {00}, +year = {1998}, +isbn = {0-8186-8412-7}, +pages = {50} +} + + + +// from http://libweb.princeton.edu/libraries/firestone/rbsc/aids/church/church1.html#1 +@article{church41, + author={A. Church}, + title={The Calculi of Lambda-Conversion}, + journal={Annals of Mathematics Studies}, + number={6}, + year={1941}, + publisher={Princeton University} +} + + +@misc + { CodeTimeSite, + author = {Sean Halle}, + key = {CodeTime}, + title = {Homepage for The CodeTime Parallel Software Platform}, + note = {{\ttfamily http://codetime.sourceforge.net}} + } + + + +@misc + { CodeTimePlatform, + author = {Sean Halle}, + key = {CodeTime}, + title = {The CodeTime Parallel Software Platform}, + note = {{\ttfamily http://codetime.sourceforge.net/content/CodeTime\_Platform.pdf}} + } + + +@misc + { CodeTimeVS, + author = {Sean Halle}, + key = {CodeTime}, + title = {The Specification of the CodeTime Platform's Virtual Server}, + note = {{\ttfamily http://codetime.sourceforge.net/content/CodeTime\_Virtual\_Server.pdf}} + } + + +@misc + { CodeTimeOS, + author = {Sean Halle}, + key = {CodeTime}, + title = {A Hardware Independent OS}, + note = {{\ttfamily http://codetime.sourceforge.net/content/CodeTime\_OS.pdf}} + } + + +@misc + { CodeTimeSem, + author = {Sean Halle}, + key = {CodeTime}, + title = {The Big-Step Operational Semantics of the CodeTime Computational Model}, + note = {{\ttfamily http://codetime.sourceforge.net/content/CodeTime\_Semantics.pdf}} + } + + +@misc + { CodeTimeTh, + author = {Sean Halle}, + key = {CodeTime}, + title = {A Mental Framework for Use in Creating Hardware-Independent Parallel Languages}, + note = {{\ttfamily http://codetime.sourceforge.net/content/CodeTiime\_Theoretical\_Framework.pdf}} + } + + +@misc + { CodeTimeTh1, + author = {Sean Halle}, + key = {CodeTime}, + title = {The CodeTime Parallel Software Platform}, + note = {{\ttfamily http://codetime.sourceforge.net}} + } + + +@misc + { CodeTimeTh2, + author = {Sean Halle}, + key = {CodeTime}, + title = {The CodeTime Parallel Software Platform}, + note = {{\ttfamily http://codetime.sourceforge.net}} + } + + +@misc + { CodeTimeRT, + author = {Sean Halle}, + key = {CodeTime}, + title = {The CodeTime Parallel Software Platform}, + note = {{\ttfamily http://codetime.sourceforge.net}} + } + + +@misc + { CodeTimeWebSite + author = {Sean Halle}, + key = {CodeTime}, + title = {The CodeTime Parallel Software Platform}, + note = {{\ttfamily http://codetime.sourceforge.net}} + } + + +@misc + { CodeTimeBaCTiL, + author = {Sean Halle}, + key = {CodeTime}, + title = {The Base CodeTime Language}, + note = {{\ttfamily http://codetime.sourceforge.net/content/CodeTime\_BaCTiL.pdf}} + } + +@misc + { CodeTimeCert, + author = {Sean Halle}, + key = {CodeTime}, + title = {The CodeTime Certification Strategy}, + note = {{\ttfamily http://codetime.sourceforge.net/content/CodeTime\_Certification.pdf}} + } + + +// Multiple inheritance: explains issues well and references LOOPS and CLOS +@inproceedings{ducournau94, + author = {R. Ducournau and M. Habib and M. Huchard and M. L. Mugnier}, + title = {Proposal for a monotonic multiple inheritance linearization}, + booktitle = {OOPSLA '94: Proceedings of the ninth annual conference on Object-oriented programming systems, language, and applications}, + year = {1994}, + pages = {164--175}, + publisher = {ACM Press} +} + + +// 252 Citations, shows equivalence of mu-calculus and (nondeterministic) tree automata, +// so cited as foundation a lot +@article{emerson91, + title={{Tree automata, mu-calculus and determinacy}}, + author={Emerson, EA and Jutla, CS}, + journal={Proceedings of the 32nd Symposium on Foundations of Computer Science}, + pages={368--377}, + year={1991} +} + + +// Introducs PRAM model, at same time, in same conference as +@article{fortune78, + title={{Parallelism in random access machines}}, + author={Fortune, S. and Wyllie, J.}, + journal={STOC '78: Proceedings of the tenth annual ACM symposium on Theory of computing}, + pages={114--118}, + year={1978}, + publisher={ACM Press New York, NY, USA} +} + + + +// Smalltalk reference +@book{goldberg83, + title={{Smalltalk-80: the language and its implementation}}, + author={Goldberg, A. and Robson, D.}, + year={1983}, + publisher={Addison-Wesley} +} + + +// also introduces PRAM model, apparently independently +@inproceedings{goldschlager78, + author = {Leslie M. Goldschlager}, + title = {A unified approach to models of synchronous parallel machines}, + booktitle = {STOC '78: Proceedings of the tenth annual ACM symposium on Theory of computing}, + year = {1978}, + pages = {89--94}, + location = {San Diego, California, United States}, + doi = {http://doi.acm.org/10.1145/800133.804336}, + publisher = {ACM Press}, +} + + +// Java spec +@book + { gosling96, + author = {J. Gosling and B. Joy and G. Steele and G. Bracha}, + title = {The Java Language Specification}, + publisher = {Addison-Wesley}, + year = {1996} + } + + +// Survey of prototyping parallel apps +@article{hasselbring00, + author = {Wilhelm Hasselbring}, + title = {Programming languages and systems for prototyping concurrent applications}, + journal = {ACM Comput. Surv.}, + volume = {32}, + number = {1}, + year = {2000}, + issn = {0360-0300}, + pages = {43--79}, + doi = {http://doi.acm.org/10.1145/349194.349199}, + publisher = {ACM Press}, + address = {New York, NY, USA}, + } + + +// Original CSP paper +@article{hoare78, + author={C. A. R. Hoare}, + title={Communicating Sequential Processes}, + journal={Communications of the ACM}, + year={1978}, + volume={21}, + number={8}, + pages={666-677} +} + + +// 8 citations.. probably from self.. want a paper that ties areas together.. +// This paper does a beautiful job.. +@article{huth, + title={{A Unifying Framework for Model Checking Labeled Kripke Structures, Modal Transition Systems, and Interval Transition Systems}}, + author={Huth, M.}, + journal={Proceedings of the 19th International Conference on the Foundations of Software Technology \& Theoretical Computer Science, Lecture Notes in Computer Science}, + pages={369--380}, + publisher={Springer-Verlag} +} + + +// Dataflow advances survey, includes large grain dataflow +@article + { johnston04, + author = {Wesley M. Johnston and J. R. Paul Hanna and Richard J. Millar}, + title = {Advances in dataflow programming languages}, + journal = {ACM Comput. Surv.}, + volume = {36}, + number = {1}, + year = {2004}, + issn = {0360-0300}, + pages = {1--34}, + doi = {http://doi.acm.org/10.1145/1013208.1013209}, + publisher = {ACM Press}, + address = {New York, NY, USA} + } + + +@book + { koelbel93, + author = {C. H. Koelbel and D. Loveman and R. Schreiber and G. Steele Jr}, + title = {High Performance Fortran Handbook}, + year = {1993}, + publisher = {MIT Press} + } + + +// mu calculus paper with 430 citations +@article{kozen83, + title={{Results on the Propositional mu-Calculus}}, + author={Kozen, D.}, + journal={TCS}, + volume={27}, + pages={333--354}, + year={1983} +} + + +// original kripke structure paper +@article{kripke63, + title={{Semantical analysis of modal logic}}, + author={Kripke, S.}, + journal={Zeitschrift fur Mathematische Logik und Grundlagen der Mathematik}, + volume={9}, + pages={67--96}, + year={1963} +} + + +@book + { mcGraw85, + author = {J McGraw and S. Skedzielewski and S. Allan and R Odefoeft}, + title = {SISAL: Streams and Iteration in a Single-Assignment Language: Reference Manual Version 1.2}, + note = {Manual M-146 Rev. 1}, + publisher = {Lawrence Livermore National Laboratory}, + year = {1985} + } + + +// Milner's own citation to development of CCS +@book{milner80, + title={{A Calculus of Communicating Systems, volume 92 of Lecture Notes in Computer Science}}, + author={Milner, R.}, + year={1980}, + publisher={Springer-Verlag} +} + + +// Milner's own pi-calculus reference +@article{milner92, + title={{A calculus of mobile processes, parts I and II}}, + author={Milner, R. and Parrow, J. and Walker, D.}, + journal={Information and Computation}, + volume={100}, + number={1}, + pages={1--40 and 41--77}, + year={1992}, + publisher={Academic Press} +} + + +// more recent Pi calculus reference +@book + { milner99, + author = {Robin Milner}, + title = {Communicating and Mobile Systems: The pi-Calculus}, + publisher = {Cambridge University Press}, + year = {1999} + } + + +// MPI reference +@book + { MPIForum94, + author = {M. P. I. Forum}, + title = {MPI: A Message-Passing Interface Standard}, + year = {1994} + } + + +// Petri nets original citation +@article{petri62, + title={{Fundamentals of a theory of asynchronous information flow}}, + author={Petri, C.A.}, + journal={Proc. IFIP Congress}, + volume={62}, + pages={386--390}, + year={1962} +} + + +// Pierce Type system book +@book{pierce02, + title={Types and Programming Languages}, + author={Pierce, B. C.}, + year={2002}, + publisher={MIT Press} +} + + +// Survey of Visual programming +@Article + { price, + author = {B. A. Price and R. M. Baecker and L. S. Small}, + title = {A Principled Taxonomy of Software Visualization}, + journal ={Journal of Visual Languages and Computing}, + volume = {4}, + number = {3}, + pages = {211--266} + } + + + +@misc + { pythonWebSite, + key = {Python}, + title = {The Python Software Foundation Mission Statement}, + note = {{\ttfamily http://www.python.org/psf/mission.html}} + } + + +// Roadmap for Revitalization of High End Computing +@unpublished + { reed03, + editor = {Daniel A. Reed}, + title = {Workshop on The Roadmap for the Revitalization of High-End Computing}, + day = {16--18}, + month = {jun}, + year = {2003}, + note = {Available at {\ttfamily http://www.cra.org/reports/supercomputing.web.pdf}} + } + + +// Parallel Pascal +@Article + { reeves84, + author = {A. P. Reeves}, + title = {Parallel Pascal -- An Extended Pascal for Parallel Computers}, + journal = {Journal of Parallel and Distributed Computing}, + volume = {1}, + number = {}, + year = {1984}, + month = {aug}, + pages = {64--80} + } + + +// Survey of parallel langs and models +@article{skillicorn98, + author = {David B. Skillicorn and Domenico Talia}, + title = {Models and languages for parallel computation}, + journal = {ACM Comput. Surv.}, + volume = {30}, + number = {2}, + year = {1998}, + issn = {0360-0300}, + pages = {123--169}, + doi = {http://doi.acm.org/10.1145/280277.280278}, + publisher = {ACM Press}, + address = {New York, NY, USA}, + } + + +// LOOPS ref for multiple inheritance issues +@article{stefik86, + title={Object Oriented Programming: Themes and Variations}, + author={Stefik, M. and Bobrow, D. G.}, + journal={The AI Magazine}, + volume={6}, + number={4}, + year={1986} +} + + +// 240 citations to this book, so seems safe.. covers modal logics which is superset +// of temporal logics +@book{stirling92, + title={{Modal and Temporal Logics}}, + author={Stirling, C.}, + year={1992}, + publisher={University of Edinburgh, Department of Computer Science} +} + + +// Titanium website +@misc + { TitaniumWebSite, + author = {Paul Hilfinger and et. al.}, + title = {The Titanium Project Home Page}, + note = {{\ttfamily http://www.cs.berkeley.edu/projects/titanium}} + } + + +// website with scans of original work by Turing +@misc{turing38, + author={A. Turing}, + note={http://www.turingarchive.org/intro/, and +http://www.turing.org.uk/sources/biblio4.html, and +http://web.comlab.ox.ac.uk/oucl/research/areas/ieg/e-library/sources/tp2-ie.pdf}, + year={1938} +} + + +// First mention of von Neumann's architecture ideas +@book{vonNeumann45, + title={First Draft of a Report on the EDVAC}, + author={J. von Neumann}, + year={1945}, + publisher={United States Army Ordnance Department} +} + + +// The 203 Glynn Winskel book for Formal Semantics +@book{winskel93, + title={{The Formal Semantics of Programming Languages}}, + author={Winskel, G.}, + year={1993}, + publisher={MIT Press} +} + + diff -r 9b9a2497757d -r eb146c5c05a8 0__Papers/PRT/PRT__formal_def/helpers/plain.bst --- /dev/null Thu Jan 01 00:00:00 1970 +0000 +++ b/0__Papers/PRT/PRT__formal_def/helpers/plain.bst Sat Aug 03 19:24:22 2013 -0700 @@ -0,0 +1,1098 @@ +% BibTeX standard bibliography style `plain' + % version 0.99a for BibTeX versions 0.99a or later, LaTeX version 2.09. + % Copyright (C) 1985, all rights reserved. + % Copying of this file is authorized only if either + % (1) you make absolutely no changes to your copy, including name, or + % (2) if you do make changes, you name it something other than + % btxbst.doc, plain.bst, unsrt.bst, alpha.bst, and abbrv.bst. + % This restriction helps ensure that all standard styles are identical. + % The file btxbst.doc has the documentation for this style. + +ENTRY + { address + author + booktitle + chapter + edition + editor + howpublished + institution + journal + key + month + note + number + organization + pages + publisher + school + series + title + type + volume + year + } + {} + { label } + +INTEGERS { output.state before.all mid.sentence after.sentence after.block } + +FUNCTION {init.state.consts} +{ #0 'before.all := + #1 'mid.sentence := + #2 'after.sentence := + #3 'after.block := +} + +STRINGS { s t } + +FUNCTION {output.nonnull} +{ 's := + output.state mid.sentence = + { ", " * write$ } + { output.state after.block = + { add.period$ write$ + newline$ + "\newblock " write$ + } + { output.state before.all = + 'write$ + { add.period$ " " * write$ } + if$ + } + if$ + mid.sentence 'output.state := + } + if$ + s +} + +FUNCTION {output} +{ duplicate$ empty$ + 'pop$ + 'output.nonnull + if$ +} + +FUNCTION {output.check} +{ 't := + duplicate$ empty$ + { pop$ "empty " t * " in " * cite$ * warning$ } + 'output.nonnull + if$ +} + +FUNCTION {output.bibitem} +{ newline$ + "\bibitem{" write$ + cite$ write$ + "}" write$ + newline$ + "" + before.all 'output.state := +} + +FUNCTION {fin.entry} +{ add.period$ + write$ + newline$ +} + +FUNCTION {new.block} +{ output.state before.all = + 'skip$ + { after.block 'output.state := } + if$ +} + +FUNCTION {new.sentence} +{ output.state after.block = + 'skip$ + { output.state before.all = + 'skip$ + { after.sentence 'output.state := } + if$ + } + if$ +} + +FUNCTION {not} +{ { #0 } + { #1 } + if$ +} + +FUNCTION {and} +{ 'skip$ + { pop$ #0 } + if$ +} + +FUNCTION {or} +{ { pop$ #1 } + 'skip$ + if$ +} + +FUNCTION {new.block.checka} +{ empty$ + 'skip$ + 'new.block + if$ +} + +FUNCTION {new.block.checkb} +{ empty$ + swap$ empty$ + and + 'skip$ + 'new.block + if$ +} + +FUNCTION {new.sentence.checka} +{ empty$ + 'skip$ + 'new.sentence + if$ +} + +FUNCTION {new.sentence.checkb} +{ empty$ + swap$ empty$ + and + 'skip$ + 'new.sentence + if$ +} + +FUNCTION {field.or.null} +{ duplicate$ empty$ + { pop$ "" } + 'skip$ + if$ +} + +FUNCTION {emphasize} +{ duplicate$ empty$ + { pop$ "" } + { "{\em " swap$ * "}" * } + if$ +} + +INTEGERS { nameptr namesleft numnames } + +FUNCTION {format.names} +{ 's := + #1 'nameptr := + s num.names$ 'numnames := + numnames 'namesleft := + { namesleft #0 > } + { s nameptr "{ff~}{vv~}{ll}{, jj}" format.name$ 't := + nameptr #1 > + { namesleft #1 > + { ", " * t * } + { numnames #2 > + { "," * } + 'skip$ + if$ + t "others" = + { " et~al." * } + { " and " * t * } + if$ + } + if$ + } + 't + if$ + nameptr #1 + 'nameptr := + namesleft #1 - 'namesleft := + } + while$ +} + +FUNCTION {format.authors} +{ author empty$ + { "" } + { author format.names } + if$ +} + +FUNCTION {format.editors} +{ editor empty$ + { "" } + { editor format.names + editor num.names$ #1 > + { ", editors" * } + { ", editor" * } + if$ + } + if$ +} + +FUNCTION {format.title} +{ title empty$ + { "" } + { title "t" change.case$ } + if$ +} + +FUNCTION {n.dashify} +{ 't := + "" + { t empty$ not } + { t #1 #1 substring$ "-" = + { t #1 #2 substring$ "--" = not + { "--" * + t #2 global.max$ substring$ 't := + } + { { t #1 #1 substring$ "-" = } + { "-" * + t #2 global.max$ substring$ 't := + } + while$ + } + if$ + } + { t #1 #1 substring$ * + t #2 global.max$ substring$ 't := + } + if$ + } + while$ +} + +FUNCTION {format.date} +{ year empty$ + { month empty$ + { "" } + { "there's a month but no year in " cite$ * warning$ + month + } + if$ + } + { month empty$ + 'year + { month " " * year * } + if$ + } + if$ +} + +FUNCTION {format.btitle} +{ title emphasize +} + +FUNCTION {tie.or.space.connect} +{ duplicate$ text.length$ #3 < + { "~" } + { " " } + if$ + swap$ * * +} + +FUNCTION {either.or.check} +{ empty$ + 'pop$ + { "can't use both " swap$ * " fields in " * cite$ * warning$ } + if$ +} + +FUNCTION {format.bvolume} +{ volume empty$ + { "" } + { "volume" volume tie.or.space.connect + series empty$ + 'skip$ + { " of " * series emphasize * } + if$ + "volume and number" number either.or.check + } + if$ +} + +FUNCTION {format.number.series} +{ volume empty$ + { number empty$ + { series field.or.null } + { output.state mid.sentence = + { "number" } + { "Number" } + if$ + number tie.or.space.connect + series empty$ + { "there's a number but no series in " cite$ * warning$ } + { " in " * series * } + if$ + } + if$ + } + { "" } + if$ +} + +FUNCTION {format.edition} +{ edition empty$ + { "" } + { output.state mid.sentence = + { edition "l" change.case$ " edition" * } + { edition "t" change.case$ " edition" * } + if$ + } + if$ +} + +INTEGERS { multiresult } + +FUNCTION {multi.page.check} +{ 't := + #0 'multiresult := + { multiresult not + t empty$ not + and + } + { t #1 #1 substring$ + duplicate$ "-" = + swap$ duplicate$ "," = + swap$ "+" = + or or + { #1 'multiresult := } + { t #2 global.max$ substring$ 't := } + if$ + } + while$ + multiresult +} + +FUNCTION {format.pages} +{ pages empty$ + { "" } + { pages multi.page.check + { "pages" pages n.dashify tie.or.space.connect } + { "page" pages tie.or.space.connect } + if$ + } + if$ +} + +FUNCTION {format.vol.num.pages} +{ volume field.or.null + number empty$ + 'skip$ + { "(" number * ")" * * + volume empty$ + { "there's a number but no volume in " cite$ * warning$ } + 'skip$ + if$ + } + if$ + pages empty$ + 'skip$ + { duplicate$ empty$ + { pop$ format.pages } + { ":" * pages n.dashify * } + if$ + } + if$ +} + +FUNCTION {format.chapter.pages} +{ chapter empty$ + 'format.pages + { type empty$ + { "chapter" } + { type "l" change.case$ } + if$ + chapter tie.or.space.connect + pages empty$ + 'skip$ + { ", " * format.pages * } + if$ + } + if$ +} + +FUNCTION {format.in.ed.booktitle} +{ booktitle empty$ + { "" } + { editor empty$ + { "In " booktitle emphasize * } + { "In " format.editors * ", " * booktitle emphasize * } + if$ + } + if$ +} + +FUNCTION {empty.misc.check} +{ author empty$ title empty$ howpublished empty$ + month empty$ year empty$ note empty$ + and and and and and + key empty$ not and + { "all relevant fields are empty in " cite$ * warning$ } + 'skip$ + if$ +} + +FUNCTION {format.thesis.type} +{ type empty$ + 'skip$ + { pop$ + type "t" change.case$ + } + if$ +} + +FUNCTION {format.tr.number} +{ type empty$ + { "Technical Report" } + 'type + if$ + number empty$ + { "t" change.case$ } + { number tie.or.space.connect } + if$ +} + +FUNCTION {format.article.crossref} +{ key empty$ + { journal empty$ + { "need key or journal for " cite$ * " to crossref " * crossref * + warning$ + "" + } + { "In {\em " journal * "\/}" * } + if$ + } + { "In " key * } + if$ + " \cite{" * crossref * "}" * +} + +FUNCTION {format.crossref.editor} +{ editor #1 "{vv~}{ll}" format.name$ + editor num.names$ duplicate$ + #2 > + { pop$ " et~al." * } + { #2 < + 'skip$ + { editor #2 "{ff }{vv }{ll}{ jj}" format.name$ "others" = + { " et~al." * } + { " and " * editor #2 "{vv~}{ll}" format.name$ * } + if$ + } + if$ + } + if$ +} + +FUNCTION {format.book.crossref} +{ volume empty$ + { "empty volume in " cite$ * "'s crossref of " * crossref * warning$ + "In " + } + { "Volume" volume tie.or.space.connect + " of " * + } + if$ + editor empty$ + editor field.or.null author field.or.null = + or + { key empty$ + { series empty$ + { "need editor, key, or series for " cite$ * " to crossref " * + crossref * warning$ + "" * + } + { "{\em " * series * "\/}" * } + if$ + } + { key * } + if$ + } + { format.crossref.editor * } + if$ + " \cite{" * crossref * "}" * +} + +FUNCTION {format.incoll.inproc.crossref} +{ editor empty$ + editor field.or.null author field.or.null = + or + { key empty$ + { booktitle empty$ + { "need editor, key, or booktitle for " cite$ * " to crossref " * + crossref * warning$ + "" + } + { "In {\em " booktitle * "\/}" * } + if$ + } + { "In " key * } + if$ + } + { "In " format.crossref.editor * } + if$ + " \cite{" * crossref * "}" * +} + +FUNCTION {article} +{ output.bibitem + format.authors "author" output.check + new.block + format.title "title" output.check + new.block + crossref missing$ + { journal emphasize "journal" output.check + format.vol.num.pages output + format.date "year" output.check + } + { format.article.crossref output.nonnull + format.pages output + } + if$ + new.block + note output + fin.entry +} + +FUNCTION {book} +{ output.bibitem + author empty$ + { format.editors "author and editor" output.check } + { format.authors output.nonnull + crossref missing$ + { "author and editor" editor either.or.check } + 'skip$ + if$ + } + if$ + new.block + format.btitle "title" output.check + crossref missing$ + { format.bvolume output + new.block + format.number.series output + new.sentence + publisher "publisher" output.check + address output + } + { new.block + format.book.crossref output.nonnull + } + if$ + format.edition output + format.date "year" output.check + new.block + note output + fin.entry +} + +FUNCTION {booklet} +{ output.bibitem + format.authors output + new.block + format.title "title" output.check + howpublished address new.block.checkb + howpublished output + address output + format.date output + new.block + note output + fin.entry +} + +FUNCTION {inbook} +{ output.bibitem + author empty$ + { format.editors "author and editor" output.check } + { format.authors output.nonnull + crossref missing$ + { "author and editor" editor either.or.check } + 'skip$ + if$ + } + if$ + new.block + format.btitle "title" output.check + crossref missing$ + { format.bvolume output + format.chapter.pages "chapter and pages" output.check + new.block + format.number.series output + new.sentence + publisher "publisher" output.check + address output + } + { format.chapter.pages "chapter and pages" output.check + new.block + format.book.crossref output.nonnull + } + if$ + format.edition output + format.date "year" output.check + new.block + note output + fin.entry +} + +FUNCTION {incollection} +{ output.bibitem + format.authors "author" output.check + new.block + format.title "title" output.check + new.block + crossref missing$ + { format.in.ed.booktitle "booktitle" output.check + format.bvolume output + format.number.series output + format.chapter.pages output + new.sentence + publisher "publisher" output.check + address output + format.edition output + format.date "year" output.check + } + { format.incoll.inproc.crossref output.nonnull + format.chapter.pages output + } + if$ + new.block + note output + fin.entry +} + +FUNCTION {inproceedings} +{ output.bibitem + format.authors "author" output.check + new.block + format.title "title" output.check + new.block + crossref missing$ + { format.in.ed.booktitle "booktitle" output.check + format.bvolume output + format.number.series output + format.pages output + address empty$ + { organization publisher new.sentence.checkb + organization output + publisher output + format.date "year" output.check + } + { address output.nonnull + format.date "year" output.check + new.sentence + organization output + publisher output + } + if$ + } + { format.incoll.inproc.crossref output.nonnull + format.pages output + } + if$ + new.block + note output + fin.entry +} + +FUNCTION {conference} { inproceedings } + +FUNCTION {manual} +{ output.bibitem + author empty$ + { organization empty$ + 'skip$ + { organization output.nonnull + address output + } + if$ + } + { format.authors output.nonnull } + if$ + new.block + format.btitle "title" output.check + author empty$ + { organization empty$ + { address new.block.checka + address output + } + 'skip$ + if$ + } + { organization address new.block.checkb + organization output + address output + } + if$ + format.edition output + format.date output + new.block + note output + fin.entry +} + +FUNCTION {mastersthesis} +{ output.bibitem + format.authors "author" output.check + new.block + format.title "title" output.check + new.block + "Master's thesis" format.thesis.type output.nonnull + school "school" output.check + address output + format.date "year" output.check + new.block + note output + fin.entry +} + +FUNCTION {misc} +{ output.bibitem + format.authors output + title howpublished new.block.checkb + format.title output + howpublished new.block.checka + howpublished output + format.date output + new.block + note output + fin.entry + empty.misc.check +} + +FUNCTION {phdthesis} +{ output.bibitem + format.authors "author" output.check + new.block + format.btitle "title" output.check + new.block + "PhD thesis" format.thesis.type output.nonnull + school "school" output.check + address output + format.date "year" output.check + new.block + note output + fin.entry +} + +FUNCTION {proceedings} +{ output.bibitem + editor empty$ + { organization output } + { format.editors output.nonnull } + if$ + new.block + format.btitle "title" output.check + format.bvolume output + format.number.series output + address empty$ + { editor empty$ + { publisher new.sentence.checka } + { organization publisher new.sentence.checkb + organization output + } + if$ + publisher output + format.date "year" output.check + } + { address output.nonnull + format.date "year" output.check + new.sentence + editor empty$ + 'skip$ + { organization output } + if$ + publisher output + } + if$ + new.block + note output + fin.entry +} + +FUNCTION {techreport} +{ output.bibitem + format.authors "author" output.check + new.block + format.title "title" output.check + new.block + format.tr.number output.nonnull + institution "institution" output.check + address output + format.date "year" output.check + new.block + note output + fin.entry +} + +FUNCTION {unpublished} +{ output.bibitem + format.authors "author" output.check + new.block + format.title "title" output.check + new.block + note "note" output.check + format.date output + fin.entry +} + +FUNCTION {default.type} { misc } + +MACRO {jan} {"January"} + +MACRO {feb} {"February"} + +MACRO {mar} {"March"} + +MACRO {apr} {"April"} + +MACRO {may} {"May"} + +MACRO {jun} {"June"} + +MACRO {jul} {"July"} + +MACRO {aug} {"August"} + +MACRO {sep} {"September"} + +MACRO {oct} {"October"} + +MACRO {nov} {"November"} + +MACRO {dec} {"December"} + +MACRO {acmcs} {"ACM Computing Surveys"} + +MACRO {acta} {"Acta Informatica"} + +MACRO {cacm} {"Communications of the ACM"} + +MACRO {ibmjrd} {"IBM Journal of Research and Development"} + +MACRO {ibmsj} {"IBM Systems Journal"} + +MACRO {ieeese} {"IEEE Transactions on Software Engineering"} + +MACRO {ieeetc} {"IEEE Transactions on Computers"} + +MACRO {ieeetcad} + {"IEEE Transactions on Computer-Aided Design of Integrated Circuits"} + +MACRO {ipl} {"Information Processing Letters"} + +MACRO {jacm} {"Journal of the ACM"} + +MACRO {jcss} {"Journal of Computer and System Sciences"} + +MACRO {scp} {"Science of Computer Programming"} + +MACRO {sicomp} {"SIAM Journal on Computing"} + +MACRO {tocs} {"ACM Transactions on Computer Systems"} + +MACRO {tods} {"ACM Transactions on Database Systems"} + +MACRO {tog} {"ACM Transactions on Graphics"} + +MACRO {toms} {"ACM Transactions on Mathematical Software"} + +MACRO {toois} {"ACM Transactions on Office Information Systems"} + +MACRO {toplas} {"ACM Transactions on Programming Languages and Systems"} + +MACRO {tcs} {"Theoretical Computer Science"} + +READ + +FUNCTION {sortify} +{ purify$ + "l" change.case$ +} + +INTEGERS { len } + +FUNCTION {chop.word} +{ 's := + 'len := + s #1 len substring$ = + { s len #1 + global.max$ substring$ } + 's + if$ +} + +FUNCTION {sort.format.names} +{ 's := + #1 'nameptr := + "" + s num.names$ 'numnames := + numnames 'namesleft := + { namesleft #0 > } + { nameptr #1 > + { " " * } + 'skip$ + if$ + s nameptr "{vv{ } }{ll{ }}{ ff{ }}{ jj{ }}" format.name$ 't := + nameptr numnames = t "others" = and + { "et al" * } + { t sortify * } + if$ + nameptr #1 + 'nameptr := + namesleft #1 - 'namesleft := + } + while$ +} + +FUNCTION {sort.format.title} +{ 't := + "A " #2 + "An " #3 + "The " #4 t chop.word + chop.word + chop.word + sortify + #1 global.max$ substring$ +} + +FUNCTION {author.sort} +{ author empty$ + { key empty$ + { "to sort, need author or key in " cite$ * warning$ + "" + } + { key sortify } + if$ + } + { author sort.format.names } + if$ +} + +FUNCTION {author.editor.sort} +{ author empty$ + { editor empty$ + { key empty$ + { "to sort, need author, editor, or key in " cite$ * warning$ + "" + } + { key sortify } + if$ + } + { editor sort.format.names } + if$ + } + { author sort.format.names } + if$ +} + +FUNCTION {author.organization.sort} +{ author empty$ + { organization empty$ + { key empty$ + { "to sort, need author, organization, or key in " cite$ * warning$ + "" + } + { key sortify } + if$ + } + { "The " #4 organization chop.word sortify } + if$ + } + { author sort.format.names } + if$ +} + +FUNCTION {editor.organization.sort} +{ editor empty$ + { organization empty$ + { key empty$ + { "to sort, need editor, organization, or key in " cite$ * warning$ + "" + } + { key sortify } + if$ + } + { "The " #4 organization chop.word sortify } + if$ + } + { editor sort.format.names } + if$ +} + +FUNCTION {presort} +{ type$ "book" = + type$ "inbook" = + or + 'author.editor.sort + { type$ "proceedings" = + 'editor.organization.sort + { type$ "manual" = + 'author.organization.sort + 'author.sort + if$ + } + if$ + } + if$ + " " + * + year field.or.null sortify + * + " " + * + title field.or.null + sort.format.title + * + #1 entry.max$ substring$ + 'sort.key$ := +} + +ITERATE {presort} + +SORT + +STRINGS { longest.label } + +INTEGERS { number.label longest.label.width } + +FUNCTION {initialize.longest.label} +{ "" 'longest.label := + #1 'number.label := + #0 'longest.label.width := +} + +FUNCTION {longest.label.pass} +{ number.label int.to.str$ 'label := + number.label #1 + 'number.label := + label width$ longest.label.width > + { label 'longest.label := + label width$ 'longest.label.width := + } + 'skip$ + if$ +} + +EXECUTE {initialize.longest.label} + +ITERATE {longest.label.pass} + +FUNCTION {begin.bib} +{ preamble$ empty$ + 'skip$ + { preamble$ write$ newline$ } + if$ + "\begin{thebibliography}{" longest.label * "}" * write$ newline$ +} + +EXECUTE {begin.bib} + +EXECUTE {init.state.consts} + +ITERATE {call.type$} + +FUNCTION {end.bib} +{ newline$ + "\end{thebibliography}" write$ newline$ +} + +EXECUTE {end.bib} + diff -r 9b9a2497757d -r eb146c5c05a8 0__Papers/PRT/PRT__formal_def/helpers/url.sty --- /dev/null Thu Jan 01 00:00:00 1970 +0000 +++ b/0__Papers/PRT/PRT__formal_def/helpers/url.sty Sat Aug 03 19:24:22 2013 -0700 @@ -0,0 +1,325 @@ +% url.sty ver 1.4 02-Mar-1999 Donald Arseneau asnd@triumf.ca +% Copyright 1996-1999 Donald Arseneau, Vancouver, Canada. +% This program can be used, distributed, and modified under the terms +% of the LaTeX Project Public License. +% +% A form of \verb that allows linebreaks at certain characters or +% combinations of characters, accepts reconfiguration, and can usually +% be used in the argument to another command. It is intended for email +% addresses, hypertext links, directories/paths, etc., which normally +% have no spaces. The font may be selected using the \urlstyle command, +% and new url-like commands can be defined using \urldef. +% +% Usage: Conditions: +% \url{ } If the argument contains any "%", "#", or "^^", or ends with +% "\", it can't be used in the argument to another command. +% The argument must not contain unbalanced braces. +% \url| | ...where "|" is any character not used in the argument and not +% "{" or a space. The same restrictions as above except that the +% argument may contain unbalanced braces. +% \xyz for "\xyz" a defined-url; this can be used anywhere, no matter +% what characters it contains. +% +% See further instructions after "\endinput" +% +\def\Url@ttdo{% style assignments for tt fonts or T1 encoding +\def\UrlBreaks{\do\.\do\@\do\\\do\/\do\!\do\_\do\|\do\%\do\;\do\>\do\]% + \do\)\do\,\do\?\do\'\do\+\do\=}% +\def\UrlBigBreaks{\do\:\do@url@hyp}% +\def\UrlNoBreaks{\do\(\do\[\do\{\do\<}% (unnecessary) +\def\UrlSpecials{\do\ {\ }}% +\def\UrlOrds{\do\*\do\-\do\~}% any ordinary characters that aren't usually +} +\def\Url@do{% style assignments for OT1 fonts except tt +\def\UrlBreaks{\do\.\do\@\do\/\do\!\do\%\do\;\do\]\do\)\do\,\do\?\do\+\do\=}% +\def\UrlBigBreaks{\do\:\do@url@hyp}% +\def\UrlNoBreaks{\do\(\do\[\do\{}% prevents breaks after *next* character +\def\UrlSpecials{\do\<{\langle}\do\>{\mathbin{\rangle}}\do\_{\_% + \penalty\@m}\do\|{\mid}\do\{{\lbrace}\do\}{\mathbin{\rbrace}}\do + \\{\mathbin{\backslash}}\do\~{\raise.6ex\hbox{\m@th$\scriptstyle\sim$}}\do + \ {\ }}% +\def\UrlOrds{\do\'\do\"\do\-}% +} +\def\url@ttstyle{% +\@ifundefined{selectfont}{\def\UrlFont{\tt}}{\def\UrlFont{\ttfamily}}\Url@ttdo +} +\def\url@rmstyle{% +\@ifundefined{selectfont}{\def\UrlFont{\rm}}{\def\UrlFont{\rmfamily}}\Url@do +} +\def\url@sfstyle{% +\@ifundefined{selectfont}{\def\UrlFont{\sf}}{\def\UrlFont{\sffamily}}\Url@do +} +\def\url@samestyle{\ifdim\fontdimen\thr@@\font=\z@ \url@ttstyle \else + \url@rmstyle \fi \def\UrlFont{}} + +\@ifundefined{strip@prefix}{\def\strip@prefix#1>{}}{} +\@ifundefined{verbatim@nolig@list}{\def\verbatim@nolig@list{\do\`}}{} + +\def\Url{% + \begingroup \let\url@moving\relax\relax \endgroup + \ifmmode\@nomatherr$\fi + \UrlFont $\fam\z@ \textfont\z@\font + \let\do\@makeother \dospecials % verbatim catcodes + \catcode`{\@ne \catcode`}\tw@ \catcode`\ 10 % except braces and spaces + \medmuskip0mu \thickmuskip\medmuskip \thinmuskip\medmuskip + \@tempcnta\fam\multiply\@tempcnta\@cclvi + \let\do\set@mathcode \UrlOrds % ordinary characters that were special + \advance\@tempcnta 8192 \UrlBreaks % bin + \advance\@tempcnta 4096 \UrlBigBreaks % rel + \advance\@tempcnta 4096 \UrlNoBreaks % open + \let\do\set@mathact \UrlSpecials % active + \let\do\set@mathnolig \verbatim@nolig@list % prevent ligatures + \@ifnextchar\bgroup\Url@z\Url@y} + +\def\Url@y#1{\catcode`{11 \catcode`}11 + \def\@tempa##1#1{\Url@z{##1}}\@tempa} +\def\Url@z#1{\def\@tempa{#1}\expandafter\expandafter\expandafter\Url@Hook + \expandafter\strip@prefix\meaning\@tempa\UrlRight\m@th$\endgroup} +\def\Url@Hook{\UrlLeft} +\let\UrlRight\@empty +\let\UrlLeft\@empty + +\def\set@mathcode#1{\count@`#1\advance\count@\@tempcnta\mathcode`#1\count@} +\def\set@mathact#1#2{\mathcode`#132768 \lccode`\~`#1\lowercase{\def~{#2}}} +\def\set@mathnolig#1{\ifnum\mathcode`#1<32768 + \lccode`\~`#1\lowercase{\edef~{\mathchar\number\mathcode`#1_{\/}}}% + \mathcode`#132768 \fi} + +\def\urldef#1#2{\begingroup \setbox\z@\hbox\bgroup + \def\Url@z{\Url@def{#1}{#2}}#2} +\expandafter\ifx\csname DeclareRobustCommand\endcsname\relax + \def\Url@def#1#2#3{\m@th$\endgroup\egroup\endgroup + \def#1{#2{#3}}} +\else + \def\Url@def#1#2#3{\m@th$\endgroup\egroup\endgroup + \DeclareRobustCommand{#1}{#2{#3}}} +\fi + +\def\urlstyle#1{\csname url@#1style\endcsname} + +% Sample (and default) configuration: +% +\newcommand\url{\begingroup \Url} +% +% picTeX defines \path, so declare it optionally: +\@ifundefined{path}{\newcommand\path{\begingroup \urlstyle{tt}\Url}}{} +% +% too many styles define \email like \address, so I will not define it. +% \newcommand\email{\begingroup \urlstyle{rm}\Url} + +% Process LaTeX \package options +% +\urlstyle{tt} +\let\Url@sppen\@M +\def\do@url@hyp{}% by default, no breaks after hyphens + +\@ifundefined{ProvidesPackage}{}{ + \ProvidesPackage{url}[1999/03/02 \space ver 1.4 \space + Verb mode for urls, email addresses, and file names] + \DeclareOption{hyphens}{\def\do@url@hyp{\do\-}}% allow breaks after hyphens + \DeclareOption{obeyspaces}{\let\Url@Hook\relax}% a flag for later + \DeclareOption{spaces}{\let\Url@sppen\relpenalty} + \DeclareOption{T1}{\let\Url@do\Url@ttdo} + \ProcessOptions +\ifx\Url@Hook\relax % [obeyspaces] was declared + \def\Url@Hook#1\UrlRight\m@th{\edef\@tempa{\noexpand\UrlLeft + \Url@retain#1\Url@nosp\, }\@tempa\UrlRight\m@th} + \def\Url@retain#1 {#1\penalty\Url@sppen\ \Url@retain} + \def\Url@nosp\,#1\Url@retain{} +\fi +} + +\edef\url@moving{\csname Url Error\endcsname} +\expandafter\edef\url@moving + {\csname url used in a moving argument.\endcsname} +\expandafter\expandafter\expandafter \let \url@moving\undefined + +\endinput +% +% url.sty ver 1.4 02-Mar-1999 Donald Arseneau asnd@reg.triumf.ca +% +% This package defines "\url", a form of "\verb" that allows linebreaks, +% and can often be used in the argument to another command. It can be +% configured to print in different formats, and is particularly useful for +% hypertext links, email addresses, directories/paths, etc. The font may +% be selected using the "\urlstyle" command and pre-defined text can be +% stored with the "\urldef" command. New url-like commands can be defined, +% and a "\path" command is provided this way. +% +% Usage: Conditions: +% \url{ } If the argument contains any "%", "#", or "^^", or ends with +% "\", it can't be used in the argument to another command. +% The argument must not contain unbalanced braces. +% \url| | ...where "|" is any character not used in the argument and not +% "{" or a space. The same restrictions as above except that the +% argument may contain unbalanced braces. +% \xyz for "\xyz" a defined-url; this can be used anywhere, no matter +% what characters it contains. +% +% The "\url" command is fragile, and its argument is likely to be very +% fragile, but a defined-url is robust. +% +% Package Option: obeyspaces +% Ordinarily, all spaces are ignored in the url-text. The "[obeyspaces]" +% option allows spaces, but may introduce spurious spaces when a url +% containing "\" characters is given in the argument to another command. +% So if you need to obey spaces you can say "\usepackage[obeyspaces]{url}", +% and if you need both spaces and backslashes, use a `defined-url' for +% anything with "\". +% +% Package Option: hyphens +% Ordinarily, breaks are not allowed after "-" characters because this +% leads to confusion. (Is the "-" part of the address or just a hyphen?) +% The package option "[hyphens]" allows breaks after explicit hyphen +% characters. The "\url" command will *never ever* hyphenate words. +% +% Package Option: spaces +% Likewise, breaks are not usually allowed after spaces under the +% "[obeyspaces]" option, but giving the options "[obeyspaces,spaces]" +% will allow breaks at those spaces. +% +% Package Option: T1 +% This signifies that you will be using T1-encoded fonts which contain +% some characters missing from most older (OT1) encoded TeX fonts. This +% changes the default definition for "\urlstyle{rm}". +% +% Defining a defined-url: +% Take for example the email address "myself%node@gateway.net" which could +% not be given (using "\url" or "\verb") in a caption or parbox due to the +% percent sign. This address can be predefined with +% \urldef{\myself}\url{myself%node@gateway.net} or +% \urldef{\myself}\url|myself%node@gateway.net| +% and then you may use "\myself" instead of "\url{myself%node@gateway.net}" +% in an argument, and even in a moving argument like a caption because a +% defined-url is robust. +% +% Style: +% You can switch the style of printing using "\urlstyle{tt}", where "tt" +% can be any defined style. The pre-defined styles are "tt", "rm", "sf", +% and "same" which all allow the same linebreaks but different fonts -- +% the first three select a specific font and the "same" style uses the +% current text font. You can define your own styles with different fonts +% and/or line-breaking by following the explanations below. The "\url" +% command follows whatever the currently-set style dictates. +% +% Alternate commands: +% It may be desireable to have different things treated differently, each +% in a predefined style; e.g., if you want directory paths to always be +% in tt and email addresses to be rm, then you would define new url-like +% commands as follows: +% +% \newcommand\email{\begingroup \urlstyle{rm}\Url} +% \newcommand\directory{\begingroup \urlstyle{tt}\Url} +% +% You must follow this format closely, and NOTE that the final command is +% "\Url", not "\url". In fact, the "\directory" example is exactly the +% "\path" definition which is pre-defined in the package. If you look +% above, you will see that "\url" is defined with +% \newcommand\url{\begingroup \Url} +% I.e., using whatever url-style has been selected. +% +% You can make a defined-url for these other styles, using the usual +% "\urldef" command as in this example: +% +% \urldef{\myself}{\email}{myself%node.domain@gateway.net} +% +% which makes "\myself" act like "\email{myself%node.domain@gateway.net}", +% if the "\email" command is defined as above. The "\myself" command +% would then be robust. +% +% Defining styles: +% Before describing how to customize the printing style, it is best to +% mention something about the unusual implementation of "\url". Although +% the material is textual in nature, and the font specification required +% is a text-font command, the text is actually typeset in *math* mode. +% This allows the context-sensitive linebreaking, but also accounts for +% the default behavior of ignoring spaces. Now on to defining styles. +% +% To change the font or the list of characters that allow linebreaks, you +% could redefine the commands "\UrlFont", "\UrlBreaks", "\UrlSpecials" etc. +% directly in the document, but it is better to define a new `url-style' +% (following the example of "\url@ttstyle" and "\url@rmstyle") which defines +% all of "\UrlBigbreaks", "\UrlNoBreaks", "\UrlBreaks", "\UrlSpecials", and +% "\UrlFont". +% +% Changing font: +% The "\UrlFont" command selects the font. The definition of "\UrlFont" +% done by the pre-defined styles varies to cope with a variety of LaTeX +% font selection schemes, but it could be as simple as "\def\UrlFont{\tt}". +% Depending on the font selected, some characters may need to be defined +% in the "\UrlSpecials" list because many fonts don't contain all the +% standard input characters. +% +% Changing linebreaks: +% The list of characters that allow line-breaks is given by "\UrlBreaks" +% and "\UrlBigBreaks", which have the format "\do\c" for character "c". +% The differences are that `BigBreaks' have a lower penalty and have +% different breakpoints when in sequence (as in "http://"): `BigBreaks' +% are treated as mathrels while `Breaks' are mathbins (see The TeXbook, +% p.170). In particular, a series of `BigBreak' characters will break at +% the end and only at the end; a series of `Break' characters will break +% after the first and after every following *pair*; there will be no +% break after a `Break' character if a `BigBreak' follows. In the case +% of "http://" it doesn't matter whether ":" is a `Break' or `BigBreak' -- +% the breaks are the same in either case; but for DECnet nodes with "::" +% it is important to prevent breaks *between* the colons, and that is why +% colons are `BigBreaks'. +% +% It is possible for characters to prevent breaks after the next following +% character (I use this for parentheses). Specify these in "\UrlNoBreaks". +% +% You can do arbitrarily complex things with characters by making them +% active in math mode (mathcode hex-8000) and specifying the definition(s) +% in "\UrlSpecials". This is used in the rm and sf styles for OT1 font +% encoding to handle several characters that are not present in those +% computer-modern style fonts. See the definition of "\Url@do", which +% is used by both "\url@rmstyle" and "\url@sfstyle"; it handles missing +% characters via "\UrlSpecials". The nominal format for setting each +% special character "c" is: "\do\c{}", but you can include +% other definitions too. +% +% +% If all this sounds confusing ... well, it is! But I hope you won't need +% to redefine breakpoints -- the default assignments seem to work well for +% a wide variety of applications. If you do need to make changes, you can +% test for breakpoints using regular math mode and the characters "+=(a". +% +% Yet more flexibility: +% You can also customize the verbatim text by defining "\UrlRight" and/or +% "\UrlLeft", e.g., for ISO formatting of urls surrounded by "< >", define +% +% \renewcommand\url{\begingroup \def\UrlLeft{}% +% \urlstyle{tt}\Url} +% +% The meanings of "\UrlLeft" and "\UrlRight" are *not* reproduced verbatim. +% This lets you use formatting commands there, but you must be careful not +% to use TeX's special characters ("\^_%~#$&{}" etc.) improperly. +% You can also define "\UrlLeft" to reprocess the verbatim text, but the +% format of the definition is special: +% +% \def\UrlLeft#1\UrlRight{ ... do things with #1 ... } +% +% Yes, that is "#1" followed by "\UrlRight" then the definition. For +% example, to put a hyperTeX hypertext link in the DVI file: +% +% \def\UrlLeft#1\UrlRight{\special{html:}#1\special{html:}} +% +% Using this technique, url.sty can provide a convenient interface for +% performing various operations on verbatim text. You don't even need +% to print out the argument! For greatest efficiency in such obscure +% applications, you can define a null url-style where all the lists like +% "\UrlBreaks" are empty. +% +% Revision History: +% ver 1.1 6-Feb-1996: +% Fix hyphens that wouldn't break and ligatures that weren't suppressed. +% ver 1.2 19-Oct-1996: +% Package option for T1 encoding; Hooks: "\UrlLeft" and "\UrlRight". +% ver 1.3 21-Jul-1997: +% Prohibit spaces as delimiter characters; change ascii tilde in OT1. +% ver 1.4 02-Mar-1999 +% LaTeX license; moving-argument-error +% The End + +Test file integrity: ASCII 32-57, 58-126: !"#$%&'()*+,-./0123456789 +:;<=>?@ABCDEFGHIJKLMNOPQRSTUVWXYZ[\]^_`abcdefghijklmnopqrstuvwxyz{|}~ diff -r 9b9a2497757d -r eb146c5c05a8 0__Papers/PRT/PRT__formal_def/helpers/usetex-v1-anon.cls --- /dev/null Thu Jan 01 00:00:00 1970 +0000 +++ b/0__Papers/PRT/PRT__formal_def/helpers/usetex-v1-anon.cls Sat Aug 03 19:24:22 2013 -0700 @@ -0,0 +1,363 @@ +\NeedsTeXFormat{LaTeX2e} +\ProvidesClass{usetex-v1-anon}[2002/10/31 v1.2 usetex Usenix article class] + +% usetex-v1.cls - to be used with LaTeX2e for Usenix articles +% +% To use this style file, do this: +% +% \documentclass{usetex-v1} +% +% The following definitions are modifications of standard article.cls +% definitions, arranged to do a better job of matching the Usenix +% guidelines. and make for convenient Usenix paper writing +% +% Choose the appropriate option: +% +% 1. workingdraft: +% +% For initial submission and shepherding. Features prominent +% date, notice of draft status, page numbers, and annotation +% facilities. +% +% 2. proof: +% +% A galley proof identical to the final copy except for page +% numbering and proof date on the bottom. Annotations are +% removed. +% +% 3. webversion: +% +% A web-publishable version, uses \docstatus{} to indicate +% publication information (where and when paper was published), +% and page numbers. +% +% 4. finalversion: +% +% The final camera-ready-copy (CRC) version of the paper. +% Published in conference proceedings. This doesn't include +% page numbers, annotations, or draft status (Usenix adds +% headers, footers, and page numbers onto the CRC). +% +% If several are used, the last one in this list wins +% + +% +% In addition, the option "endnotes" permits the use of the +% otherwise-disabled, Usenix-deprecated footnote{} command in +% documents. In this case, be sure to include a +% \makeendnotes command at the end of your document or +% the endnotes will not actually appear. +% + +\newif\if@draftcopy \newif\ifworkingdraft +\DeclareOption{workingdraft}{\workingdrafttrue\@draftcopytrue} +\newif\ifproof \DeclareOption{proof}{\prooftrue\@draftcopytrue} +\newif\ifwebversion +\DeclareOption{webversion}{\prooftrue\webversiontrue\@draftcopytrue} +\DeclareOption{finalversion}{} +\newif\ifhasendnotes +\DeclareOption{endnotes}{\hasendnotestrue} + +% pass all other options to the article class +\DeclareOption*{% + \PassOptionsToClass{\CurrentOption}{article}% +} + +% actually process the options +\ProcessOptions + +% usetex is based on article +\LoadClass[twocolumn]{article} + +% Footnotes are not currently allowed, but +% endnotes (while a bad idea) are. +\ifhasendnotes + \RequirePackage{endnotes} +\fi + +% save any provided document status information +\def\@docstatus{} +\def\docstatus#1{\gdef\@docstatus{#1}} + +\ifworkingdraft + + % formatting helper for draft notes + \newcommand{\@noteleader[1]}{% + {\marginpar{\framebox{\scriptsize\textbf{#1}}}}% + \bfseries\itshape + } + + % put a small anonymous editing note in the draft copy + \newcommand{\edannote}[1]{{\@noteleader[note] (#1)}} + + % put a small attributed editing note in the draft copy + \newcommand{\edatnote}[2]{{\@noteleader[#1] #2}} + + % put an attributed editing note paragraph in the draft copy + \newenvironment{ednote}[1] + {\newcommand{\who}{#1}\@noteleader[\who]} + + % mark a spot where work has been left off for later + \newcommand{\HERE}{% + {\mbox{}\marginpar{\framebox{\textbf{here}}}}{\bf\ldots}} + +\else + + % dummy versions of editing commands to produce warnings + + \newcommand{\edannote}[1]{\@latex@warning + {Leftover edannote command in final version ignored}} + + \newcommand{\edatnote}[1]{\@latex@warning + {Leftover edatnote command in final version ignored}} + + \newsavebox{\@discard} + \newenvironment{ednote}[1]{\@latex@warning + {Leftover ednote environment in final version ignored}% + \begin{lrbox}{\@discard}}{\end{lrbox}} + + \newcommand{\HERE}{\@latex@warning + {Leftover HERE command in final version ignored}} + +\fi + +% set up the footers appropriately +\def\@setfoot{% + \ifwebversion + % webversions get whatever status the author says + \gdef\@evenfoot{\@docstatus \hfil \thepage}% + \else + % all other drafts get the standard draft footer + \gdef\@evenfoot{\textbf{Draft:} \@draftdate\hfil \textbf{Page:} \thepage}% + \fi + \gdef\@oddfoot{\@evenfoot}% +} + +% +% Usenix wants no page numbers for submitted papers, so that +% they can number them themselves. Drafts should have +% numbered pages, so they can be edited. +% +\if@draftcopy + % Compute a date and time for the draft for use + % either in \@setfoot (proof) or in \maketitle (workingdraft) + % + % Time code adapted from custom-bib/makebst.tex + % Copyright 1993-1999 Patrick W Daly + % Max-Planck-Institut f\"ur Aeronomie + % E-mail: daly@linmp.mpg.de + \newcount\hour + \hour=\time + \divide\hour by 60 + \newcount\minute + \minute=\hour + \multiply\minute by 60 + \advance\minute by -\time + \multiply\minute by -1 + \newcommand{\@draftdate} + {{\the\year/\/\two@digits{\the\month}/\/\two@digits{\the\day}% + ~\two@digits{\the\hour}:\two@digits{\the\minute}}} + \pagestyle{plain} + \@setfoot +\else + \pagestyle{empty} +\fi + +% Times-Roman font is nice if you can get it (requires NFSS, +% which is in latex2e). +\usepackage{times} + +% endnote support, as described at +% http://www.lyx.org/help/footnotes.php +\ifhasendnotes + \typeout + {Warning: endnotes support is deprecated (see documentation for details)} + \let\footnote=\endnote + \def\enoteformat{\rightskip\z@ \leftskip\z@ + \parindent=0pt\parskip=\baselineskip + \@theenmark. } + \newcommand{\makeendnotes}{ + \begingroup + \def\enotesize{\normalsize} + \theendnotes + \endgroup + } +\else + \long\gdef\footnote{\@latex@error + {Deprecated footnote command (see documentation for details)}} + \long\gdef\endnote{\@latex@error + {Deprecated endnote command (see documentation for details)}} +\fi + +% +% Usenix margins +% Gives active areas of 6.45" x 9.0" +% +\setlength{\textheight}{9.0in} +\setlength{\columnsep}{0.25in} +\setlength{\textwidth}{6.45in} +%\setlength{\footskip}{0.0in} +%\setlength{\footheight}{0.0in} +\setlength{\topmargin}{0.0in} +\setlength{\headheight}{0.0in} +\setlength{\headsep}{0.0in} +\setlength{\evensidemargin}{0.0in} +\setlength{\oddsidemargin}{0.0in} +\setlength{\marginparsep}{1.5em} +\setlength{\marginparwidth}{0.35in} + +% The standard maketitle insists on +% messing with the style of the first page. +% Thus, we will wrap maketitle with code to put +% things right again. +\let \save@maketitle=\maketitle +\def\maketitle{ + \save@maketitle + \if@draftcopy + \@specialpagefalse + \else + \thispagestyle{empty} + \fi +} + +% +% Usenix titles are in 14-point bold type, with no date, and with no +% change in the empty page headers. The author section is +% 12 point roman and italic: see below. +% +\def\@maketitle{% + \newpage + \null +% \vskip 3ex% + \begin{center}% +% \let \footnote \thanks + {\Large \bf \@title \par}% % use 14 pt bold +% \vskip 2ex% + {\large +% \lineskip .5ex% +% \begin{tabular}[t]{c}% +% \@author +% \end{tabular}\par + }% + \ifworkingdraft + \vskip 0.5ex + \textbf{Draft of \@draftdate} + \vskip 0.5ex + \fi + \ifwebversion + \vskip 0.5ex + \textit{Authors and affiliation elided for review.} + \vskip 0.5ex + \fi + \end{center}% + \par +% \vskip 2ex +} + +% +% The author section +% should have names in Roman, address in +% italic, e-mail/http in typewriter. +% This is enforced by use of these macros +% +\def\authname#1{{#1}\\} +\def\authaddr#1{\itshape{#1}\\} +\def\authurl#1{{\normalsize #1}\\} + +% +% The abstract is preceded by a 12-pt bold centered heading +% +\def\abstract{\begin{center}% + {\large\bf \abstractname\vspace{-.5ex}\vspace{\z@}}% + \end{center}} +\def\endabstract{} + +% +% Main section titles are 12-pt bold. Lower divisions can +% be same size or smaller: we choose same. +% Main section leading is tight. Subsection leading is even +% slightly tighter. All lower divisions are formatted like subsections. +% +\newcommand\@sectionfont{\reset@font\large\bf} +\newlength\@sectionaboveskip +\setlength\@sectionaboveskip{-0.7\baselineskip + plus -0.1\baselineskip + minus -0.1\baselineskip} +\newlength\@sectionbelowskip +\setlength\@sectionbelowskip{0.3\baselineskip + plus 0.1\baselineskip} +\newlength\@subsectionaboveskip +\setlength\@subsectionaboveskip{-0.5\baselineskip + plus -0.1\baselineskip} +\renewcommand\section{\@startsection {section}{1}{\z@}% + {\@sectionaboveskip}{\@sectionbelowskip}{\@sectionfont}} +\newcommand\@gensubsection[2]{\@startsection {#1}{#2}{\z@}% + {\@subsectionaboveskip}{\@sectionbelowskip}{\@sectionfont}} +\renewcommand\subsection{\@gensubsection{subsection}{2}} +\renewcommand\subsubsection{\@gensubsection{subsubsection}{3}} +%\renewcommand\paragraph{\@gensubsection{paragraph}{4}} +%\renewcommand\subparagraph{\@gensubsection{subparagaph}{5}} +\renewcommand\paragraph{\@startsection{paragraph}{4}{\z@}% + {1.25ex \@plus 0.2ex \@minus 0.2ex}% + {-1.0em}% + {\normalfont\normalsize\bfseries}} +\renewcommand\subparagraph{\@startsection{subparagraph}{5}{\parindent}% + {1.25ex \@plus 0.2ex \@minus 0.2ex}% + {-1.0em}% + {\normalfont\normalsize\bfseries}} + +% List items need to be tightened up. +% There must be a better way than copying +% the definitions to modify the list environment... +\def\@itemspacings{\listparindent=\parindent + \parsep=0pt\topsep=0.3\baselineskip\partopsep=0pt\itemsep=0pt} +% now make envs use itemspacings +\def\itemize{% + \ifnum \@itemdepth >\thr@@\@toodeep\else + \advance\@itemdepth\@ne + \edef\@itemitem{labelitem\romannumeral\the\@itemdepth}% + \expandafter + \list + \csname\@itemitem\endcsname + {\@itemspacings\def\makelabel##1{\hss\llap{##1}}}% + \fi} +\def\enumerate{% + \ifnum \@enumdepth >\thr@@\@toodeep\else + \advance\@enumdepth\@ne + \edef\@enumctr{enum\romannumeral\the\@enumdepth}% + \expandafter + \list + \csname label\@enumctr\endcsname + {\@itemspacings\usecounter\@enumctr\def\makelabel##1{\hss\llap{##1}}}% + \fi} +\def\description{% + \list{}{\labelwidth\z@ \itemindent-\leftmargin + \@itemspacings\let\makelabel\descriptionlabel}} + +% Bibliography items need to be tightened up. +% Again, there must be a better way than copying +% the definitions to modify the list environment... +\def\thebibliography#1% + {\section*{\refname}% + \@mkboth{\MakeUppercase\refname}{\MakeUppercase\refname}% + \list{\@biblabel{\@arabic\c@enumiv}}% + {\settowidth\labelwidth{\@biblabel{#1}}% + \leftmargin\labelwidth + \advance\leftmargin\labelsep + \@openbib@code + \usecounter{enumiv}% + \let\p@enumiv\@empty + \renewcommand\theenumiv{\@arabic\c@enumiv}% + \parsep=0pt}% pack entries + \sloppy + \hbadness=8000% mostly don't whine about bibliography fmt + \clubpenalty=4000% + \@clubpenalty=\clubpenalty + \widowpenalty=4000% + \sfcode`\.\@m} + +% Floating bodies need to be tightened up. +\setlength\textfloatsep{14pt plus 2pt} +\setlength\dbltextfloatsep{\textfloatsep} +\setlength\intextsep{0.8\textfloatsep} +\setlength\abovecaptionskip{8pt minus 2pt} diff -r 9b9a2497757d -r eb146c5c05a8 0__Papers/PRT/PRT__formal_def/helpers/usetex-v1.cls --- /dev/null Thu Jan 01 00:00:00 1970 +0000 +++ b/0__Papers/PRT/PRT__formal_def/helpers/usetex-v1.cls Sat Aug 03 19:24:22 2013 -0700 @@ -0,0 +1,357 @@ +\NeedsTeXFormat{LaTeX2e} +\ProvidesClass{usetex-v1}[2002/10/31 v1.2 usetex Usenix article class] + +% usetex-v1.cls - to be used with LaTeX2e for Usenix articles +% +% To use this style file, do this: +% +% \documentclass{usetex-v1} +% +% The following definitions are modifications of standard article.cls +% definitions, arranged to do a better job of matching the Usenix +% guidelines. and make for convenient Usenix paper writing +% +% Choose the appropriate option: +% +% 1. workingdraft: +% +% For initial submission and shepherding. Features prominent +% date, notice of draft status, page numbers, and annotation +% facilities. +% +% 2. proof: +% +% A galley proof identical to the final copy except for page +% numbering and proof date on the bottom. Annotations are +% removed. +% +% 3. webversion: +% +% A web-publishable version, uses \docstatus{} to indicate +% publication information (where and when paper was published), +% and page numbers. +% +% 4. finalversion: +% +% The final camera-ready-copy (CRC) version of the paper. +% Published in conference proceedings. This doesn't include +% page numbers, annotations, or draft status (Usenix adds +% headers, footers, and page numbers onto the CRC). +% +% If several are used, the last one in this list wins +% + +% +% In addition, the option "endnotes" permits the use of the +% otherwise-disabled, Usenix-deprecated footnote{} command in +% documents. In this case, be sure to include a +% \makeendnotes command at the end of your document or +% the endnotes will not actually appear. +% + +\newif\if@draftcopy \newif\ifworkingdraft +\DeclareOption{workingdraft}{\workingdrafttrue\@draftcopytrue} +\newif\ifproof \DeclareOption{proof}{\prooftrue\@draftcopytrue} +\newif\ifwebversion +\DeclareOption{webversion}{\prooftrue\webversiontrue\@draftcopytrue} +\DeclareOption{finalversion}{} +\newif\ifhasendnotes +\DeclareOption{endnotes}{\hasendnotestrue} + +% pass all other options to the article class +\DeclareOption*{% + \PassOptionsToClass{\CurrentOption}{article}% +} + +% actually process the options +\ProcessOptions + +% usetex is based on article +\LoadClass[twocolumn]{article} + +% Footnotes are not currently allowed, but +% endnotes (while a bad idea) are. +\ifhasendnotes + \RequirePackage{endnotes} +\fi + +% save any provided document status information +\def\@docstatus{} +\def\docstatus#1{\gdef\@docstatus{#1}} + +\ifworkingdraft + + % formatting helper for draft notes + \newcommand{\@noteleader[1]}{% + {\marginpar{\framebox{\scriptsize\textbf{#1}}}}% + \bfseries\itshape + } + + % put a small anonymous editing note in the draft copy + \newcommand{\edannote}[1]{{\@noteleader[note] (#1)}} + + % put a small attributed editing note in the draft copy + \newcommand{\edatnote}[2]{{\@noteleader[#1] #2}} + + % put an attributed editing note paragraph in the draft copy + \newenvironment{ednote}[1] + {\newcommand{\who}{#1}\@noteleader[\who]} + + % mark a spot where work has been left off for later + \newcommand{\HERE}{% + {\mbox{}\marginpar{\framebox{\textbf{here}}}}{\bf\ldots}} + +\else + + % dummy versions of editing commands to produce warnings + + \newcommand{\edannote}[1]{\@latex@warning + {Leftover edannote command in final version ignored}} + + \newcommand{\edatnote}[1]{\@latex@warning + {Leftover edatnote command in final version ignored}} + + \newsavebox{\@discard} + \newenvironment{ednote}[1]{\@latex@warning + {Leftover ednote environment in final version ignored}% + \begin{lrbox}{\@discard}}{\end{lrbox}} + + \newcommand{\HERE}{\@latex@warning + {Leftover HERE command in final version ignored}} + +\fi + +% set up the footers appropriately +\def\@setfoot{% + \ifwebversion + % webversions get whatever status the author says + \gdef\@evenfoot{\@docstatus \hfil \thepage}% + \else + % all other drafts get the standard draft footer + \gdef\@evenfoot{\textbf{Draft:} \@draftdate\hfil \textbf{Page:} \thepage}% + \fi + \gdef\@oddfoot{\@evenfoot}% +} + +% +% Usenix wants no page numbers for submitted papers, so that +% they can number them themselves. Drafts should have +% numbered pages, so they can be edited. +% +\if@draftcopy + % Compute a date and time for the draft for use + % either in \@setfoot (proof) or in \maketitle (workingdraft) + % + % Time code adapted from custom-bib/makebst.tex + % Copyright 1993-1999 Patrick W Daly + % Max-Planck-Institut f\"ur Aeronomie + % E-mail: daly@linmp.mpg.de + \newcount\hour + \hour=\time + \divide\hour by 60 + \newcount\minute + \minute=\hour + \multiply\minute by 60 + \advance\minute by -\time + \multiply\minute by -1 + \newcommand{\@draftdate} + {{\the\year/\/\two@digits{\the\month}/\/\two@digits{\the\day}% + ~\two@digits{\the\hour}:\two@digits{\the\minute}}} + \pagestyle{plain} + \@setfoot +\else + \pagestyle{empty} +\fi + +% Times-Roman font is nice if you can get it (requires NFSS, +% which is in latex2e). +\usepackage{times} + +% endnote support, as described at +% http://www.lyx.org/help/footnotes.php +\ifhasendnotes + \typeout + {Warning: endnotes support is deprecated (see documentation for details)} + \let\footnote=\endnote + \def\enoteformat{\rightskip\z@ \leftskip\z@ + \parindent=0pt\parskip=\baselineskip + \@theenmark. } + \newcommand{\makeendnotes}{ + \begingroup + \def\enotesize{\normalsize} + \theendnotes + \endgroup + } +\else + \long\gdef\footnote{\@latex@error + {Deprecated footnote command (see documentation for details)}} + \long\gdef\endnote{\@latex@error + {Deprecated endnote command (see documentation for details)}} +\fi + +% +% Usenix margins +% Gives active areas of 6.45" x 9.0" +% +\setlength{\textheight}{9.0in} +\setlength{\columnsep}{0.25in} +\setlength{\textwidth}{6.45in} +%\setlength{\footskip}{0.0in} +%\setlength{\footheight}{0.0in} +\setlength{\topmargin}{0.0in} +\setlength{\headheight}{0.0in} +\setlength{\headsep}{0.0in} +\setlength{\evensidemargin}{0.0in} +\setlength{\oddsidemargin}{0.0in} +\setlength{\marginparsep}{1.5em} +\setlength{\marginparwidth}{0.35in} + +% The standard maketitle insists on +% messing with the style of the first page. +% Thus, we will wrap maketitle with code to put +% things right again. +\let \save@maketitle=\maketitle +\def\maketitle{ + \save@maketitle + \if@draftcopy + \@specialpagefalse + \else + \thispagestyle{empty} + \fi +} + +% +% Usenix titles are in 14-point bold type, with no date, and with no +% change in the empty page headers. The author section is +% 12 point roman and italic: see below. +% +\def\@maketitle{% + \newpage + \null + \vskip 3ex% + \begin{center}% + \let \footnote \thanks + {\Large \bf \@title \par}% % use 14 pt bold + \vskip 2ex% + {\large + \lineskip .5ex% + \begin{tabular}[t]{c}% + \@author + \end{tabular}\par}% + \ifworkingdraft + \vskip 3ex \textbf{Draft of \@draftdate} \vskip 3ex + \fi + \ifwebversion + \vskip 3ex \textbf{\@docstatus} \vskip 3ex + \fi + \end{center}% + \par + \vskip 2ex} + +% +% The author section +% should have names in Roman, address in +% italic, e-mail/http in typewriter. +% This is enforced by use of these macros +% +\def\authname#1{{#1}\\} +\def\authaddr#1{\itshape{#1}\\} +\def\authurl#1{{\normalsize #1}\\} + +% +% The abstract is preceded by a 12-pt bold centered heading +% +\def\abstract{\begin{center}% + {\large\bf \abstractname\vspace{-.5ex}\vspace{\z@}}% + \end{center}} +\def\endabstract{} + +% +% Main section titles are 12-pt bold. Lower divisions can +% be same size or smaller: we choose same. +% Main section leading is tight. Subsection leading is even +% slightly tighter. All lower divisions are formatted like subsections. +% +\newcommand\@sectionfont{\reset@font\large\bf} +\newlength\@sectionaboveskip +\setlength\@sectionaboveskip{-0.7\baselineskip + plus -0.1\baselineskip + minus -0.1\baselineskip} +\newlength\@sectionbelowskip +\setlength\@sectionbelowskip{0.3\baselineskip + plus 0.1\baselineskip} +\newlength\@subsectionaboveskip +\setlength\@subsectionaboveskip{-0.5\baselineskip + plus -0.1\baselineskip} +\renewcommand\section{\@startsection {section}{1}{\z@}% + {\@sectionaboveskip}{\@sectionbelowskip}{\@sectionfont}} +\newcommand\@gensubsection[2]{\@startsection {#1}{#2}{\z@}% + {\@subsectionaboveskip}{\@sectionbelowskip}{\@sectionfont}} +\renewcommand\subsection{\@gensubsection{subsection}{2}} +\renewcommand\subsubsection{\@gensubsection{subsubsection}{3}} +%\renewcommand\paragraph{\@gensubsection{paragraph}{4}} +%\renewcommand\subparagraph{\@gensubsection{subparagaph}{5}} +\renewcommand\paragraph{\@startsection{paragraph}{4}{\z@}% + {1.25ex \@plus 0.2ex \@minus 0.2ex}% + {-1.0em}% + {\normalfont\normalsize\bfseries}} +\renewcommand\subparagraph{\@startsection{subparagraph}{5}{\parindent}% + {1.25ex \@plus 0.2ex \@minus 0.2ex}% + {-1.0em}% + {\normalfont\normalsize\bfseries}} + +% List items need to be tightened up. +% There must be a better way than copying +% the definitions to modify the list environment... +\def\@itemspacings{\listparindent=\parindent + \parsep=0pt\topsep=0.3\baselineskip\partopsep=0pt\itemsep=0pt} +% now make envs use itemspacings +\def\itemize{% + \ifnum \@itemdepth >\thr@@\@toodeep\else + \advance\@itemdepth\@ne + \edef\@itemitem{labelitem\romannumeral\the\@itemdepth}% + \expandafter + \list + \csname\@itemitem\endcsname + {\@itemspacings\def\makelabel##1{\hss\llap{##1}}}% + \fi} +\def\enumerate{% + \ifnum \@enumdepth >\thr@@\@toodeep\else + \advance\@enumdepth\@ne + \edef\@enumctr{enum\romannumeral\the\@enumdepth}% + \expandafter + \list + \csname label\@enumctr\endcsname + {\@itemspacings\usecounter\@enumctr\def\makelabel##1{\hss\llap{##1}}}% + \fi} +\def\description{% + \list{}{\labelwidth\z@ \itemindent-\leftmargin + \@itemspacings\let\makelabel\descriptionlabel}} + +% Bibliography items need to be tightened up. +% Again, there must be a better way than copying +% the definitions to modify the list environment... +\def\thebibliography#1% + {\section*{\refname}% + \@mkboth{\MakeUppercase\refname}{\MakeUppercase\refname}% + \list{\@biblabel{\@arabic\c@enumiv}}% + {\settowidth\labelwidth{\@biblabel{#1}}% + \leftmargin\labelwidth + \advance\leftmargin\labelsep + \@openbib@code + \usecounter{enumiv}% + \let\p@enumiv\@empty + \renewcommand\theenumiv{\@arabic\c@enumiv}% + \parsep=0pt}% pack entries + \sloppy + \hbadness=8000% mostly don't whine about bibliography fmt + \clubpenalty=4000% + \@clubpenalty=\clubpenalty + \widowpenalty=4000% + \sfcode`\.\@m} + +% Floating bodies need to be tightened up. +\setlength\textfloatsep{14pt plus 2pt} +\setlength\dbltextfloatsep{\textfloatsep} +\setlength\intextsep{0.8\textfloatsep} +\setlength\abovecaptionskip{8pt minus 2pt} diff -r 9b9a2497757d -r eb146c5c05a8 0__Papers/PRT/PRT__formal_def/latex/.pdf --- /dev/null Thu Jan 01 00:00:00 1970 +0000 +++ b/0__Papers/PRT/PRT__formal_def/latex/.pdf Sat Aug 03 19:24:22 2013 -0700 @@ -0,0 +1,31 @@ +%!PS-Adobe-3.0 EPSF-3.0 +%%Creator: PDF2EPS - BaKoMa TeX Portable Document Format (PDF) Import Filter. +%%Title: ..\figures\Proto-Runtime__mdoules_plus_plugin_plus +%%CreationDate: Sat May 04 20:18:38 2013 +%%LanguageLevel: 3 +%%DocumentData: Clean7Bit +%%BoundingBox: 0 0 612 792 +%%Rotate: 0 +%%EndComments + +%%Error: Can't find image + +%%Page: 1 1 +newpath +0 0 moveto 0 792 lineto 612 792 lineto 612 0 lineto closepath +1 0 0 setrgbcolor stroke +0 0 0.5 setrgbcolor +/Times-Roman findfont 30 scalefont setfont +0 396 moveto 0 90 rmoveto +gsave (Filter:) gsave show grestore 120 0 rmoveto (PDF2EPS) show grestore +0 -30 rmoveto gsave (File:) gsave show grestore 120 0 rmoveto (../figures/Proto-Runtime__mdoules_plus_plugin_plus) show grestore +1 0 0 setrgbcolor +0 -30 rmoveto gsave (Error:) gsave show grestore + /Times-Roman findfont 24 scalefont setfont 120 0 rmoveto (Can't find image) show grestore +0 0.5 0 setrgbcolor +0 -60 rmoveto gsave (Hint:) show grestore +/Times-Roman findfont 24 scalefont setfont +0 -30 rmoveto gsave 20 0 rmoveto (Open the file by Acrobat and then save) show grestore +%%EndPage +(\nPDF2EPS Error: ../figures/Proto-Runtime__mdoules_plus_plugin_plus - Can't find image\n) print flush +%%EndDocument diff -r 9b9a2497757d -r eb146c5c05a8 0__Papers/PRT/PRT__formal_def/latex/PRT__formal_short.tex --- /dev/null Thu Jan 01 00:00:00 1970 +0000 +++ b/0__Papers/PRT/PRT__formal_def/latex/PRT__formal_short.tex Sat Aug 03 19:24:22 2013 -0700 @@ -0,0 +1,452 @@ +%----------------------------------------------------------------------------- +% +% Template for sigplanconf LaTeX Class +% +% Name: sigplanconf-template.tex +% +% Purpose: A template for sigplanconf.cls, which is a LaTeX 2e class +% file for SIGPLAN conference proceedings. +% +% Guide: Refer to "Author's Guide to the ACM SIGPLAN Class," +% sigplanconf-guide.pdf +% +% Author: Paul C. Anagnostopoulos +% Windfall Software +% 978 371-2316 +% paul@windfall.com +% +% Created: 15 February 2005 +% +%----------------------------------------------------------------------------- + + +\documentclass[preprint]{sigplanconf} + +% The following \documentclass options may be useful: +% +% 10pt To set in 10-point type instead of 9-point. +% 11pt To set in 11-point type instead of 9-point. +% authoryear To obtain author/year citation style instead of numeric. +\usepackage{amssymb,graphicx,calc,ifthen,subfig,dblfloatfix,fixltx2e} + + +% correct bad hyphenation here +\hyphenation{op-tical net-works semi-conduc-tor} + +\usepackage{wasysym} + +\begin{document} + +\bibliographystyle{plain} +% + +\conferenceinfo{WXYZ '05}{date, City.} +\copyrightyear{2005} +\copyrightdata{[to be supplied]} + +\titlebanner{banner above paper title} % These are ignored unless +\preprintfooter{short description of paper} % 'preprint' option specified. + + +\title{A Proto-Runtime Approach to Domain Specific Languages} + + +\authorinfo{Sean Halle} + {Open Source Research Institute, INRIA, + and TU Berlin} + {seanhalle@opensourceresearchinstitute.org} +\authorinfo{Merten Sach} + {TU Berlin} + {msach@mailbox.tu-berlin.de} +\authorinfo{Albert Cohen} + {Ecole Normal Supereur, and INRIA} + {albert.cohen@inria.fr} + +\maketitle + + +\begin{abstract} + +? +replace lang-specific with interface, centralize services, minimize effort to create, give language control over hardware assignment.. side benefits: multi-lang, perf-tuning, debugging + +? + +Domain Specific Languages that are embedded into a base language have promise to provide productivity, performant-portability and wide adoption for parallel programming. However such languages have too few users to support the large effort required to create them and port them across hardware platforms, resulting in low adoption of the method. +To solve this, we introduce a proto-runtime approach, which reduces the effort to create and port domain specific languages. It modularizes the creation of runtime systems and the parallelism constructs they implement, by separating the language-construct and scheduling logic away from the low-level runtime details, including concurrency, memory consistency, and runtime-performance aspects. +As a result, new parallel constructs are written using sequential reasoning, and languages can be mixed within +the same program. In addition, scheduling of work onto hardware is under language and application control, without interference from an underlying thread package scheduler. This enables higher quality scheduling decisions for higher application performance. +We present measurements of the time taken to develop runtimes for new languages, as well as time to re-implement existing ones, which average a few days each. In addition, we measure performance of proto-runtime based implementations going head-to-head with the standard distributions of Cilk, StarSs (OMPSs), and posix threads, showing that the proto-runtime matches or outperforms on large servers in all cases. +\end{abstract} + + + + + +%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% +\section{Background and Motivation} +\label{sec:intro} + +[Note to reviewers: this paper's style and structure follow the official PPoPP guide to writing style, which is linked to the PPoPP website. We are taking on faith that the approach has been communicated effectively to reviewers and that we won't be penalized for following it's recommended structure and approach.] + +Programming in the past has been overwhelmingly sequential, with the applications being run on sequential hardware. But the laws of physics have forced the hardware to become parallel, which will force nearly all future programming to become parallel programming. However, the transition from sequential to parallel programming has been slow due to the difficulty of the traditional parallel programming methods. + +The difficulties with parallel programming fall into three main categories: 1) difficult mental model, 2) extra effort to rewrite the code for each hardware target to get acceptable performance and 3) disruption to existing practices, including steep learning curve, changes to the tools used, and changes in design practices. + +Many believe that these can be overcome with the use of Domain-Specific Languages []. But such languages have been slow to adopt, we believe due to the cost to create them and to port them across hardware targets. The small number of users of each language, which is specific to a narrow domain, makes this cost impractical. + +We propose that a method that makes Domain Specific Languages (DSLs) low cost to produce as well as to port across hardware targets will allow them to fulfill their promise, and we introduce what we call a proto-runtime to help towards this goal. + +The proto-runtime approach is a normal, full, runtime, but with two key pieces replaced by an interface. One piece replaced is the logic of language constructs, and the other is logic for choosing which core to assign work onto. The remaining proto-runtime piece handles the low-level hardware details of the runtime. + +The decomposition into a proto-runtime plus plugged-in language behaviors modularizes the construction of runtimes. The proto-runtime is one module, which embodies runtime internals, which are hardware oriented and independent of language. The plugged-in portions form the two other modules, which are language specific. The interface between them occurs at a natural boundary, which separates the hardware oriented portion of a runtime from the language oriented portion. + +We claim the following benefits of the proto-runtime approach, each of which is supported in the indicated section of the paper: + +\begin{itemize} + +\item The proto-runtime approach should reliably apply to future languages and hardware. because the patterns underlying it appear to be fundamental and so should hold for future languages and architectures (\S\ref{subsec:TiePoints}). + +\item The proto-runtime approach modularizes the runtime (\S\ref{sec:Proposal}). + +%\item The modularization is consistent with patterns that appear to be fundamental to parallel computation and runtimes (\S\ ). + +\item The modularization cleanly separates runtime internals from the language-specific logic (\S\ref{sec:Proposal} ). + +\item The modularization gives the language control +over timing and placement of executing work (\S\ref{sec:Proposal}). + +\item The modularization results in reduced time to implement a new language's behavior, and in reduced time to port a language to new hardware (\S\ref{sec:Proposal}). + +\begin{itemize} + + +\item Part of the time reduction is due to the proto-runtime providing a centralized location for services for all languages to use, so the language doesn't have to provide them separately. Such services include debugging facilities, automated verification, concurrency handling, hardware performance information gathering, and so on (\S\ ). + +\item Part of the time reduction is due to encapsulation of hardware aspects inside the hardware-oriented module (\S \ref{sec:intro}). + +\item Part of the time reduction is due to reuse of the performance-tuning effort for runtime internals (\S\ ). + +\item Part of the time reduction is due to using sequential thinking when implementing the language logic, enabled by the proto-runtime protecting shared internal runtime state and exporting an interface that presents a sequential model (\S\ ). + + +\end{itemize} + +\item + +The modularization also selectively exposes hardware aspects relevant to placement of work, giving the language control over placement of work onto the hardware. If the language takes advantage of this, it can result in reduced communication between cores and increased application performance (\S\ ). + +\begin{itemize} + +\item Similar control over hardware is not possible when the language is built on top of a package like Posix threads or TBB, which has its own work-to-hardware assignment (\S\ ). + +\end{itemize} + +\item Modularization with similar benefits does not appear possible when using a package such as Posix threads or TBB, unless the package itself is modified and then used according to the proto-runtime pattern (\S\ ). + +\end{itemize} + +The paper is organized as follows: We first expand on the value of embedded style DSLs (eDSL), and where the effort goes when creating one (\S \ref{sec:DSLHypothesis}). We focus on the role that runtime implementation effort plays in the adoption of eDSLs \S, which motivates the value of the savings provided by the proto-runtime approach. We then move on to the details of the proto-runtime approach (\S ), and tie them to how a runtime is modularized (\S ), covering how each claimed benefit is provided. +We then show overhead measurements (\S ) and implementation time measurements (\S ), which indicate that the proto-runtime approach is performance competitive while significantly reducing implementation and porting effort. +With that understanding in hand, we then discuss how the approach compares to related work (\S ), and finally, we highlight the main conclusions drawn from the research (\S ). + + + + +%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% +% +%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% +\section{Background: The eDSL Hypothesis} + +%[[Hypothesis: Embedded-style DSLs -\textgreater\ high productivity + low learning curve + low app-port + low disruption]] + +%[[Bridge: Few users-\textgreater\ must be quick time to create + low effort to lang-port + high perf across targets]] + +%[[Bridge: effort to create = runtime + effort port = runtime + perf on new target = runtime]] + +%[[Bridge: big picture = langs * runtimes -\textgreater runtime effort critical]] + +Domain Specific Languages have been around for a while [], and recently have been suggested as a good approach for parallel programming[][stanford PPL]. + +In essence, a DSL, or just Domain Language, captures patterns that are common in a particular domain of expertise, such as user interfaces, simulations of physical phenomena, bio-informatics, cosmology, and so on. Each domain has a particular set of mental models, common types of computation, and common kinds of data structures. A DSL captures these common elements in custom syntax. + + +\subsection{Embedding a DSL into a base language} + +A style of domain language, which we feel has good applicability to parallel software development, is the so-called \textit{embedded} style of DSL (eDSL) [] [metaborg][stanford ppl]. In this variation, a program is written in a mix of a base language plus domain language constructs. The syntax of the two is intermixed. A preprocessing step then translates the domain syntax into the base syntax, and includes calls to the domain language's runtime. + + +For example, use C (or Java) as the base language for an application, and mix-in custom syntax for constructs from a user-interface eDSL. To test the code, the developer modifies the build process to first perform the translation step, then pass the resulting source through the normal C (or Java) compiler. The resulting executable contains calls to a dynamic (or shared) library that becomes linked, at run time, to a runtime implementation that has been tuned to the hardware it is running on. + + +\subsection{Low learning curve, high productivity, and portability} +DSLs are generally quick to learn because the domain experts are already familiar with the concepts expressed by the custom syntax, especially for those who are \textit{not} expert programmers. Embedded style DSLs further reduce learning curve because they have relatively few constructs, and require no new development tools nor development procedures. Together, these should meet the goal of a low learning curve for switching to parallel software development. + +Productivity can be enhanced by a well designed syntax, which can simplify the application code, modularize it, and encapsulate performance aspects inside the language. Simplifying reduces the amount of code and the amount of mental effort. Modularizing separates concerns within the code and isolates aspects, which improves productivity. Encapsulating performance inside the DSL constructs removes them from the application programmer's concerns, which also improves productivity. + +Perhaps the most important productivity enhancement comes from hiding parallelism aspects inside the custom DSL constructs. The language takes advantage of the domain patterns to present a familar mental model, and then attaches synchronization, work-division, and communication implications to those constructs, without the programmer having to be aware of them. Combining the simplicity, modularization, performance encapsulation, and parallelism hiding, with congruence with the mental model of the domain, together work towards the goal of high productivity. + +Portability is aided by the encapsulation of performance aspects inside the DSL constructs. This means that the elements of the problem that require large amounts of computation are often pulled into the language, which isolates the application code from hardware performance concerns. Only the language implementation must adapt to new hardware in order to get high performance. Although such isolation cannot always be fully achieved, Domain Languages hold promise for making significant strides towards it. + +\subsection{Low disruption and easy adoption} + +Using an eDSL tends to have low disruption because the base language remains the same, along with most of the development tools and practices. + Constructs from the eDSL can be mixed into existing sequential code, incrementally replacing the high computation sections, while continuing with the same development practices.\subsection{ Few users means the effort of eDSLs must be low} + +What appears to be holding eDSLs back from addressing the challenges of parallel programming would be mainly the time, expertise, and cost needed to develop an eDSL. Because the number of users is small, the economic model of the past doesn't apply. For sequential languages, the potential user-base is in the millions, but for a parallel Domain Language, the user base may be only a few hundred developers who will use the language. + +As such, the effort to create a usable eDSL needs to be reduced to the point that it is viable for that size of user base. + +The effort to be reduced falls into three categories: + +\begin{enumerate} +\item effort to explore the design and create the eDSL syntax +\item effort to create the runtime that embodies the eDSL behavior +\item effort to performance tune the eDSL on particular hardware +\end{itemize} + + +\subsection{Critical areas of effort in the big picture} + +Across the industry as a whole, when eDSLs become successful, there will be hundreds of Domain Languages, and likewise hundreds of different hardware platforms that each language must run efficiently on. That multiplicative effect must be reduced in order to make the eDSL approach economically viable. + +The first category of eDSL effort is creating the front-end translation of custom syntax into the base language. This is a one-time effort that does not repeat when new hardware is added. + +The effort that has to be expended on each platform is the runtime implementation, which includes hardware-specific low-level tuning, and the tuning of the domain construct implementation. + +Luckily, hardware platforms cluster into groups with similar performance-related features. This opens the door to an approach that can present a common abstraction for all platforms in a cluster. Examples of clusters include: + +\begin{itemize} +\item shared coherent memory multi-core single-chip machine +\item shared coherent memory multi-core multi-chip machine +\item independent address space coprocessor (GPU) +\item a network of nodes of the above categories +\item a machine with a hierarchy of sub-networks +\end{itemize} + + +%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% +% +%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% +\section{Our Proposal} \label{sec:Proposal} + +We propose addressing the runtime effort by defining a modularization of runtimes, as seen in Fig X. The low-level hardware details are collected into one module, which presents a common interface. The language supplies +the top two modules, which plug in via the interface. The hardware specific module presents the same interface +for all platforms sharing similar performance related features. This module only has to be implement once for a given platform, then reused by the languages. + +\begin{figure}[ht] + \centering + \includegraphics[width = 1.5in, height = 1.1in]{../figures/proto-runtime__modules.pdf} + \caption{Shows how the proto-runtime approach modularizes the implementation of a runtime. The three pieces are the proto-runtime implementation, an implementation of the language construct behaviors, and an implementation of the portion of scheduling that chooses which work is assigned to which processor. } + \label{fig:PR_three_pieces} +\end{figure} + + +Thus, a given language doesn't have to re-implement its runtime for every platform. Instead, it has a much lower effort requirement, of implementing for each category. + +The language effort is further reduced because the language doesn't consider the low-level details of making the runtime itself run fast. It only has to consider the level of hardware feature that is exposed by the interface. This is a higher level of abstraction, which simplifies the task for the language implementer. + +One additional benefit is giving control to the language, to choose when and where it wishes work to execute. +This feature simplifies implementation of languages +that have features related to scheduling behavior. +It also enables the language implementor to use sophisticated +methods for choosing placement of virtual processors +(threads) and tasks, which can significantly impact +application performance. + +In this paper, we present work that applies to coherent +shared memory machines, both single chip and multiple chip. Extensions beyond this are currently in progress, to address multiple-address-space machines and hierarchical +heterogeneous collections of processors, which will appear in future papers. + +\subsection{Breakdown of the modules} + +The language is broken into two parts, as seen in Fig +X. One is a thin wrapper library that +invokes the runtime and the other is a set of modules that are part of the runtime. + + + +\begin{figure}[ht] + \centering + \includegraphics[width = 2.8in, height = 1.1in]{../figures/proto-runtime__modules_lang_breakdown.pdf} + \caption{Shows how the code of the language implementation + is broken into two pieces. The first is a thin wrapper + that invokes the runtime, the other is a dynamic + library that plugs into the runtime.} + \label{fig:langBreakdown} +\end{figure} + +The runtime itself consists of three modules connected via +an interface, as was seen back in Fig X. One encapsulates the low-level hardware details, and presents an interface to the language modules. We call +this the \textit{proto-runtime}. +It's job is to enforce the interface that the language modules see. + + +The language has two modules, both of which are collected in what we call the \textit{language plugin}. One module encodes the behavior of language +constructs, the other module provides logic for choosing which work to execute on +which hardware resource. + +The plugin collects the two language modules into a dynamic library that is implemented, compiled, and distributed separately from any application executables. This is how a non-changing application executable is able to invoke plugin code that can change between machines. The executable contains only symbols of plugin functions, and during the run those are linked to specific functions' implementations. + +In order to provide such modularization, we rely upon something we call a tie-point as the primitive upon which synchronization constructs are built. The low-level nature of a tie-point places them below the level of constructs such as a mutex. Instead, a mutex is implemented on top of tie-points. This places all parallel constructs on the same level in the software stack, be they complex like the AND-OR parallelism of Prolog, or the wild-card matching +channels in coordination languages, or ultra-simple acquire and release mutex constructs. All are implemented in terms of the same tie-point primitives provided by the proto-runtime. + + + + + +\subsection{The origin of tie-points.}\label{subsec:TiePoints} + + +A tie-point relates timelines, so we talk a bit, first, about timelines. A timeline is the primitive in parallelism. If you look at any parallel language, it establishes a number of independent timelines. It then controls which timelines are actively progressing relative to the others. + +For example, take a thread library. It provides a command to create a thread, and that thread represents an independent timeline. The library also provides the mutex acquire and release commands, which control which of those timelines advance relative to each other. When an acquire executes, it causes the thread to block, which means the associated timeline suspends; it stops +making forward progress. The release in a different thread clears the block, which resumes the timeline. That linkage between suspend and resume of different timelines is the control the language exerts over which timelines are actively progressing. + +To build up to tie-points, we look at the nature of points on +a single timeline, by reviewing mutex behavior in detail. We see the timeline shown in Fig X. Thread 1, which is timeline 1, tries to acquire the mutex, M, +by executing the acquire command. Timeline 1 stops, at point 1.S, then something external to it happens, and the timeline starts again at point 1.R. The gap between is not seen by the code executed within the thread. Rather, from the code-execution viewpoint, the acquire command is a single command, and hence the gap between 1.S and 1.R collapses to a single point on the timeline. + + +\begin{figure}[ht] + \centering + \includegraphics[width = 2.8in, height = 0.8in] + {../figures/PR__timeline_single.pdf} + \caption{The timeline suspends at 1.S and resumes + at 1.R. From the viewpoint of the timeline, the gap collapses into a single point.} + \label{fig:langBreakdown} +\end{figure} + + +Now, a tie-point is seen as the linkage between such collapsed points on +two timelines. In Fig X, timeline A is still there, suspends still at 1.S and resumes at 1.R. However, now there is a second timeline, timeline 2B. It executes the release command at point 2.S, which suspends timeline B, performs the behavior of the release command +inside the gap, then resumes timeline B at 2.R. The behavior of the release +command causes the end of suspend in the first timeline. That causality ties the two collapsed points in the two timelines together. + + +\begin{figure}[ht] + \centering + \includegraphics[width = 2.8in, height = 1.35in] + {../figures/PR__timeline_dual.pdf} + \caption{Two timelines with a causal relationship. +Activity that takes place during the gap in timeline +B causes resume of timeline A. This ties point 2 on +timeline B to point 1 on timeline A.} + \label{fig:langBreakdown} +\end{figure} + + + +We call this connection between the collapsed suspensions a tie point. What it provides is a guarantee about visibility of events between the tied timelines. The +guarantee makes both agree on the order of events,\textit{ +relative to the mutual tied point}. Any operation that executes before the point in the second timeline, 2.S, is visible immediately after the point in the first timeline, 1.R. In addition, nothing +in the first timeline happening after the tie-point is visible in the second +timeline before the tie-point. + +Just that guarantee defines it as a half tie-point. A full tie-point adds the dual guarantee from timeline +B to A. Namely, for a full tie-point, anything before the tie-point in timeline A is visible in timeline B after the tie-point, +and nothing in timeline B after the tie-point is visible in A before the tie-point. + +A tie-point is the primitive mechanism that the proto-runtime implements. It does not involve any notion of dependency nor constraint semantics. All it provides is the notion that the tied points are the same "instant" for both tied timelines. What that means is that both timelines see events ordered relative to that point in the same way. + +It is up to the language to supply the behavior that happens inside +the gaps. This behavior is what decides which timelines get tied together. It is that decision making, of which timelines to tie together, that implements the +semantics of a synchronization construct. + +A formal treatment of tie-points is beyond the scope of this paper. However, a formal framework has been substantially completed and +will be published in a future paper. + + + +\subsection{Tie-points within a proto-runtime} + + In Fig X we didn't say what entity executes the behavior that takes place in the gaps in the timelines. This is what the proto-runtime does. It provides +primitives that suspend a timeline and then cause behavior supplied by the language +plugin to execute in the gap. This plugin behavior chooses which timelines remain suspended versus which resume execution, or start execution. + +As such, the plugin behavior that runs in the proto-runtime when one timeline +suspends is what chooses another timeline to resume as a consequence. That +choice establishes causality between the suspensions of the two timelines, +and thus creates the tie between the two collapsed timeline points. The proto-runtime +code module provides the suspend and resume primitives, while the running proto-runtime instance +executes the plugin behavior. + +The running proto-runtime instance is also known as the Master, while the application timelines +are known as Slaves. The behavior of the language constructs executes within the Master's timeline, while the behavior of application code executes within Slave timelines. + +\subsection{Formal definition of Tie-Point} + + + +\subsection{More about the proto-runtime} + +The proto-runtime provides the following primitives, for use by language +plugins: +\begin{itemize} +\item create a virtual processor (which has a suspendible timeline) +\item create a task (which has an atomic timeline that runs to completion) +\item automatically convert a task to a virtual processor, as needed +\item trigger choosing which virtual processor or task to begin execution on an offered +core +\item suspend a timeline, then invoke a function to handle the suspension -- handler executes in the Master, with supplied parameters +\item end a timeline + +\end{itemize} + +Virtual processors and tasks, both, have associated timelines. The reason for having both is a practical one, as tasks are simpler, with less overhead, +and many languages have the semantics of short, atomic, units of work that +are not intended to suspend. Thus, tasks are treated differently inside the +proto-runtime, and incur less overhead to create and run. + +A special feature of the proto-runtime is that if a task happens to execute +a language command that causes suspension, then the proto-runtime automatically +converts that task to a virtual processor. This helps support the mixing of different +languages within the same program. + +The proto-runtime involves the language into the process of choosing which core a given task +or virtual processor executes on. The proto-runtime maintains control, but offers free cores to the plugin, which responds by then assigning a task or virtual processor to the core. The proto-runtime just offers, it is up to the language to decide what work that core should receive at that point in time. + +The proto-runtime provides a mechanism for communicating information from the application code to the plugin function that was invoked to handle suspension. For example, the identity of a particular mutex a thread wishes to acquire +can be communicated from the wrapper library to the plugin. + + +Because the proto-runtime tracks all the timelines, the end of a timeline has to be explicitly stated in the application code, by calling a wrapper library function. That then invokes the proto-runtime primitive that informs the proto-runtime instance. The proto-runtime performs internal bookkeeping related to the ending of the timeline, and notes that the core is now free and offers it to the plugin's Assigner function. + + + + + + +\subsection{What happens at different times within the +big picture} + +To get a handle on the big picture, we describe three different paths through time: +one for development of proto-runtime code, one for +development of language implementation, and one for +application development. + +The proto-runtime code is developed separately from +both language and application code, and packaged as a dynamic library. This library has multiple implementations. Each kind of hardware platform has a proto-runtime implemented specifically for it, and is tuned for low overhead on that hardware. The administrator of a particular machine chooses the proto-runtime implementation best suited to that hardware, and installs that. + +The language code is likewise developed separately from both proto-runtime and application code. Although multiple versions of a language may be implemented, there are significantly fewer versions than the number of proto-runtime versions. That is because most of the hardware details are abstracted away by the proto-runtime interface. + +However, the interface does expose hardware features related to placement of work onto cores, so some variations may exist for the same interface. Again, the administrator chooses which language implementation best suits their machine and installs the corresponding dynamic library. + +The wrapper library, however, is not +installed on the machine where code runs. Rather, it +is only used during development of an application, +and remains independent of hardware. + +The application, ideally, is developed only once. It makes calls to the wrapper library, which in turn invokes the dynamic libraries of the language and proto-runtime. +When an application is executed, the loader binds the +dynamic libraries, connecting them to the application. + In this way, a single, +unchanging, executable gains access to machine-specific implementations of language and proto-runtime. + +However, the success of the compile-once approach has +limits in practice. Each machine's characteristics determine the size of unit of work that gives the best performance. When too small, overhead in the runtime system required to create the work, manage constraints, and perform assignment becomes larger than the work +itself. When units become too large, not enough units exist to keep all the cores busy. Thankfully, the range between is large enough, for most applications, that neither limit is hit, on most machines. As machines evolve, though, this happy circumstance is likely to change, necessitating recompiling and possibly hand modifying the code. + +\end{document} + + diff -r 9b9a2497757d -r eb146c5c05a8 0__Papers/PRT/PRT__formal_def/latex/PRT__full_w_Farhad_derived_formal_def.tex --- /dev/null Thu Jan 01 00:00:00 1970 +0000 +++ b/0__Papers/PRT/PRT__formal_def/latex/PRT__full_w_Farhad_derived_formal_def.tex Sat Aug 03 19:24:22 2013 -0700 @@ -0,0 +1,2151 @@ +%----------------------------------------------------------------------------- +% +% Template for sigplanconf LaTeX Class +% +% Name: sigplanconf-template.tex +% +% Purpose: A template for sigplanconf.cls, which is a LaTeX 2e class +% file for SIGPLAN conference proceedings. +% +% Guide: Refer to "Author's Guide to the ACM SIGPLAN Class," +% sigplanconf-guide.pdf +% +% Author: Paul C. Anagnostopoulos +% Windfall Software +% 978 371-2316 +% paul@windfall.com +% +% Created: 15 February 2005 +% +%----------------------------------------------------------------------------- + + +\documentclass[preprint]{sigplanconf} + +% The following \documentclass options may be useful: +% +% 10pt To set in 10-point type instead of 9-point. +% 11pt To set in 11-point type instead of 9-point. +% authoryear To obtain author/year citation style instead of numeric. +\usepackage{amssymb,graphicx,calc,ifthen,subfig,dblfloatfix,fixltx2e} + + +% correct bad hyphenation here +\hyphenation{op-tical net-works semi-conduc-tor} + +\usepackage{wasysym} +\usepackage{amstext} + +\begin{document} + +\bibliographystyle{plain} +% + +\conferenceinfo{WXYZ '05}{date, City.} +\copyrightyear{2005} +\copyrightdata{[to be supplied]} + +\titlebanner{banner above paper title} % These are ignored unless +\preprintfooter{short description of paper} % 'preprint' option specified. + + +\title{A Proto-Runtime Approach to Domain Specific Languages} + + +\authorinfo{Sean Halle} + {Open Source Research Institute, INRIA, + and TU Berlin} + {seanhalle@opensourceresearchinstitute.org} +\authorinfo{Merten Sach} + {TU Berlin} + {msach@mailbox.tu-berlin.de} +\authorinfo{Albert Cohen} + {Ecole Normal Supereur, and INRIA} + {albert.cohen@inria.fr} + +\maketitle + + +\begin{abstract} + +? +replace lang-specific with interface, centralize services, minimize effort to create, give language control over hardware assignment.. side benefits: multi-lang, perf-tuning, debugging + +? + +Domain Specific Languages that are embedded into a base language have promise to provide productivity, performant-portability and wide adoption for parallel programming. However such languages have too few users to support the large effort required to create them and port them across hardware platforms, resulting in low adoption of the method. +To solve this, we introduce a proto-runtime approach, which reduces the effort to create and port domain specific languages. It modularizes the creation of runtime systems and the parallelism constructs they implement, by separating the language-construct and scheduling logic away from the low-level runtime details, including concurrency, memory consistency, and runtime-performance aspects. +As a result, new parallel constructs are written using sequential reasoning, and multiple languages can be mixed within +the same program. In addition, scheduling of work onto hardware is under language and application control, without interference from an underlying thread package scheduler. This enables higher quality scheduling decisions for higher application performance. +We present measurements of the time taken to develop runtimes for new languages, as well as time to re-implement existing ones, which average a few days each. In addition, we measure performance of proto-runtime based implementations going head-to-head with the standard distributions of Cilk, StarSs (OMPSs), and posix threads, showing that the proto-runtime matches or outperforms on large servers in all cases. +\end{abstract} + + + + + +%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% +\section{Background and Motivation} +\label{sec:intro} + +[Note to reviewers: this paper's style and structure follow the official PPoPP guide to writing style, which is linked to the PPoPP website. We are taking on faith that the approach has been communicated effectively to reviewers and that we won't be penalized for following it's recommended structure and approach.] + +Programming in the past has been overwhelmingly sequential, with the applications being run on sequential hardware. But the laws of physics have forced the hardware to become parallel, which will force nearly all future programming to become parallel programming. However, the transition from sequential to parallel programming has been slow due to the difficulty of the traditional parallel programming methods. + +The difficulties with parallel programming fall into three main categories: 1) difficult mental model, 2) extra effort to rewrite the code for each hardware target to get acceptable performance and 3) disruption to existing practices, including steep learning curve, changes to the tools used, and changes in design practices. + +Many believe that these can be overcome with the use of Domain-Specific Languages []. But such languages have been slow to adopt, we believe due to the cost to create them and to port them across hardware targets. The small number of users of each language, which is specific to a narrow domain, makes this cost impractical. + +We propose that a method that makes Domain Specific Languages (DSLs) low cost to produce as well as to port across hardware targets will allow them to fulfill their promise, and we introduce what we call a proto-runtime to help towards this goal. + +The proto-runtime approach is a normal, full, runtime, but with two key pieces replaced by an interface. One piece replaced is the logic of language constructs, and the other is logic for choosing which core to assign work onto. The remaining proto-runtime piece handles the low-level hardware details of the runtime. + +The decomposition into a proto-runtime plus plugged-in language behaviors modularizes the construction of runtimes. The proto-runtime is one module, which embodies runtime internals, which are hardware oriented and independent of language. The plugged-in portions form the two other modules, which are language specific. The interface between them occurs at a natural boundary, which separates the hardware oriented portion of a runtime from the language oriented portion. + +We claim the following benefits of the proto-runtime approach, each of which is supported in the indicated section of the paper: + +\begin{itemize} + +\item The proto-runtime approach should reliably apply to future languages and hardware. because the patterns underlying it appear to be fundamental and so should hold for future languages and architectures (\S\ref{subsec:TiePoints}, +\S\ref{subsec:Example}). + +\item The proto-runtime approach modularizes the runtime (\S\ref{sec:Proposal}). + +%\item The modularization is consistent with patterns that appear to be fundamental to parallel computation and runtimes (\S\ ). + +\item The modularization cleanly separates runtime internals from the language-specific logic (\S\ref{sec:Proposal}, +\S\ref{subsec:Example}). + +\item The modularization gives the language control +over timing and placement of executing work (\S\ref{sec:Proposal}). + +\item The modularization results in reduced time to implement a new language's behavior, and in reduced time to port a language to new hardware (\S\ref{sec:Proposal}, +\S\ref{subsec:ImplTimeMeas}). + +\begin{itemize} + + +\item Part of the time reduction is due to the proto-runtime providing a centralized location for services for all languages to use, so the language doesn't have to provide them separately. Such services include debugging facilities, automated verification, concurrency handling, hardware performance information gathering, and so on (\S\ ). + +\item Part of the time reduction is due to encapsulation of hardware aspects inside the hardware-oriented module (\S \ref{sec:intro}). + +\item Part of the time reduction is due to reuse of the performance-tuning effort for runtime internals (\S ). + +\item Part of the time reduction is due to using sequential thinking when implementing the language logic, enabled by the proto-runtime protecting shared internal runtime state and exporting an interface that presents a sequential model (\S\ref{subsec:Example}). + + +\end{itemize} + +\item + +The modularization also selectively exposes hardware aspects relevant to placement of work, giving the language control over placement of work onto the hardware. If the language takes advantage of this, it can result in reduced communication between cores and increased application performance (\S\ ). + +\begin{itemize} + +\item Similar control over hardware is not possible when the language is built on top of a package like Posix threads or TBB, which has its own work-to-hardware assignment (\S\ref{sec:Related}). + +\end{itemize} + +\item Modularization with similar benefits does not appear possible when using a package such as Posix threads or TBB, unless the package itself is modified and then used according to the proto-runtime pattern (\S\ref{sec:Related}). + +\end{itemize} + +The paper is organized as follows: We first expand on the value of embedded style DSLs (eDSL), and where the effort goes when creating one (\S\ref{subsec:eDSLEffort}). We focus on the role that runtime implementation effort plays in the adoption of eDSLs, which motivates the value of the savings provided by the proto-runtime approach. We then move on to the details of the proto-runtime approach (\S\ref{sec:Proposal}), and tie them to how a runtime is modularized (\S\ref{subsec:Modules}), covering how each claimed benefit is provided. +We then show overhead measurements (\S\ref{subsec:OverheadMeas}) and implementation time measurements (\S\ref{subsec:ImplTimeMeas} ), which indicate that the proto-runtime approach is performance competitive while significantly reducing implementation and porting effort. +With that understanding in hand, we then discuss how the approach compares to related work (\S\ref{sec:Related}), and finally, we highlight the main conclusions drawn from the research (\S\ref{sec:Conclusion}). + + + + +%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% +% +%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% +\section{Background: The eDSL Hypothesis} + +%[[Hypothesis: Embedded-style DSLs -\textgreater\ high productivity + low learning curve + low app-port + low disruption]] + +%[[Bridge: Few users-\textgreater\ must be quick time to create + low effort to lang-port + high perf across targets]] + +%[[Bridge: effort to create = runtime + effort port = runtime + perf on new target = runtime]] + +%[[Bridge: big picture = langs * runtimes -\textgreater runtime effort critical]] + +Domain Specific Languages have been around for a while [], and recently have been suggested as a good approach for parallel programming[][stanford PPL]. + +In essence, a DSL, or just Domain Language, captures patterns that are common in a particular domain of expertise, such as user interfaces, simulations of physical phenomena, bio-informatics, cosmology, and so on. Each domain has a particular set of mental models, common types of computation, and common kinds of data structures. A DSL captures these common elements in custom syntax. + + +\subsection{Embedding a DSL into a base language} + +A style of domain language, which we feel has good applicability to parallel software development, is the so-called \textit{embedded} style of DSL (eDSL) [] [metaborg][stanford ppl]. In this variation, a program is written in a mix of a base language plus domain language constructs. The syntax of the two is intermixed. A preprocessing step then translates the domain syntax into the base syntax, and includes calls to the domain language's runtime. + + +For example, use C (or Java) as the base language for an application, and mix-in custom syntax for constructs from a user-interface eDSL. To test the code, the developer modifies the build process to first perform the translation step, then pass the resulting source through the normal C (or Java) compiler. The resulting executable contains calls to a dynamic (or shared) library that becomes linked, at run time, to a runtime implementation that has been tuned to the hardware it is running on. + + +\subsection{Low learning curve, high productivity, and portability} +DSLs are generally quick to learn because the domain experts are already familiar with the concepts expressed by the custom syntax, especially for those who are \textit{not} expert programmers. Embedded style DSLs further reduce learning curve because they have relatively few constructs, and require no new development tools nor development procedures. Together, these should meet the goal of a low learning curve for switching to parallel software development. + +Productivity can be enhanced by a well designed syntax, which can simplify the application code, modularize it, and encapsulate performance aspects inside the language. Simplifying reduces the amount of code and the amount of mental effort. Modularizing separates concerns within the code and isolates aspects, which improves productivity. Encapsulating performance inside the DSL constructs removes them from the application programmer's concerns, which also improves productivity. + +Perhaps the most important productivity enhancement comes from hiding parallelism aspects inside the custom DSL constructs. The language takes advantage of the domain patterns to present a familar mental model, and then attaches synchronization, work-division, and communication implications to those constructs, without the programmer having to be aware of them. Combining the simplicity, modularization, performance encapsulation, and parallelism hiding, with congruence with the mental model of the domain, together work towards the goal of high productivity. + +Portability is aided by the encapsulation of performance aspects inside the DSL constructs. This means that the elements of the problem that require large amounts of computation are often pulled into the language, which isolates the application code from hardware performance concerns. Only the language implementation must adapt to new hardware in order to get high performance. Although such isolation cannot always be fully achieved, Domain Languages hold promise for making significant strides towards it. + +\subsection{Low disruption and easy adoption} + +Using an eDSL tends to have low disruption because the base language remains the same, along with most of the development tools and practices. + Constructs from the eDSL can be mixed into existing sequential code, incrementally replacing the high computation sections, while continuing with the same development practices. + + \subsection{ Few users means the effort of eDSLs must be low} \label{subsec:eDSLEffort} + +What appears to be holding eDSLs back from addressing the challenges of parallel programming would be mainly the time, expertise, and cost needed to develop an eDSL. Because the number of users is small, the economic model of the past doesn't apply. For sequential languages, the potential user-base is in the millions, but for a parallel Domain Language, the user base may be only a few hundred developers who will use the language. + +As such, the effort to create a usable eDSL needs to be reduced to the point that it is viable for that size of user base. + +The effort to be reduced falls into three categories: + +\begin{enumerate} +\item effort to explore language design and create the eDSL syntax +\item effort to create the runtime that produces the eDSL behavior +\item effort to performance tune the eDSL on particular hardware +\end{itemize} + + +\subsection{Critical areas of effort in the big picture} + +Across the industry as a whole, when eDSLs become successful, there will be hundreds of Domain Languages, and likewise hundreds of different hardware platforms that each language must run efficiently on. That multiplicative effect must be reduced in order to make the eDSL approach economically viable. + +The first category of eDSL effort is creating the front-end translation of custom syntax into the base language. This is a one-time effort that does not repeat when new hardware is added. + +The effort that has to be expended on each platform is the runtime implementation, which includes hardware-specific low-level tuning, and the tuning of the domain construct implementation. + +Luckily, hardware platforms cluster into groups with similar performance-related features. This opens the door to an approach that can present a common abstraction for all platforms in a cluster. Examples of clusters include: + +\begin{itemize} +\item shared coherent memory multi-core single-chip machine +\item shared coherent memory multi-core multi-chip machine +\item independent address space coprocessor (GPU) +\item a network of nodes of the above categories +\item a machine with a hierarchy of sub-networks +\end{itemize} + + +%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% +% +%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% +\section{Our Proposal} \label{sec:Proposal} + +We propose addressing the runtime effort by defining a modularization of runtimes, as seen in Fig X. The low-level hardware details are collected into one module, which presents a common interface. The language supplies +the top two modules, which plug in via the interface. The hardware specific module presents the same interface +for all platforms sharing similar performance related features. This module only has to be implement once for a given platform, then reused by the languages. + +\begin{figure}[ht] + \centering + \includegraphics[width = 1.5in, height = 1.1in]{../figures/proto-runtime__modules.pdf} + \caption{Shows how the proto-runtime approach modularizes the implementation of a runtime. The three pieces are the proto-runtime implementation, an implementation of the language construct behaviors, and an implementation of the portion of scheduling that chooses which work is assigned to which processor. } + \label{fig:PR_three_pieces} +\end{figure} + + +Thus, a given language doesn't have to re-implement its runtime for every platform. Instead, it has a much lower effort requirement, of implementing for each category. + +The language effort is further reduced because the language doesn't consider the low-level details of making the runtime itself run fast. It only has to consider the level of hardware feature that is exposed by the interface. This is a higher level of abstraction, which simplifies the task for the language implementer. + +One additional benefit is giving control to the language, to choose when and where it wishes work to execute. +This feature simplifies implementation of languages +that have features related to scheduling behavior. +It also enables the language implementor to use sophisticated +methods for choosing placement of virtual processors +(threads) and tasks, which can significantly impact +application performance. + +In this paper, we present work that applies to coherent +shared memory machines, both single chip and multiple chip. Extensions beyond this are currently in progress, to address multiple-address-space machines and hierarchical +heterogeneous collections of processors, which will appear in future papers. + +\subsection{Breakdown of the modules} \label{subsec:Modules} + +The language is broken into two parts, as seen in Fig +X. One is a thin wrapper library that +invokes the runtime and the other is a set of modules that are part of the runtime. + + + +\begin{figure}[ht] + \centering + \includegraphics[width = 2.8in, height = 1.1in]{../figures/proto-runtime__modules_lang_breakdown.pdf} + \caption{Shows how the code of the language implementation + is broken into two pieces. The first is a thin wrapper + that invokes the runtime, the other is a dynamic + library that plugs into the runtime.} + \label{fig:langBreakdown} +\end{figure} + +The runtime itself consists of three modules connected via +an interface, as was seen back in Fig X. One encapsulates the low-level hardware details, and presents an interface to the language modules. We call +this the \textit{proto-runtime}. +It's job is to enforce the interface that the language modules see. + + +The language has two modules, both of which are collected in what we call the \textit{language plugin}. One module encodes the behavior of language +constructs, the other module provides logic for choosing which work to execute on +which hardware resource. + +The plugin collects the two language modules into a dynamic library that is implemented, compiled, and distributed separately from any application executables. This is how a non-changing application executable is able to invoke plugin code that can change between machines. The executable contains only symbols of plugin functions, and during the run those are linked to specific functions' implementations. + +In order to provide such modularization, we rely upon a model for specifying synchronization constructs that we call the tie-point model. The low-level nature of a tie-point places them below the level of constructs such as a mutex. Instead, a mutex is specified in terms +of the primitives in the tie-point model. The proto-runtime +then implements the primitives of the tie-point model. + + This places all parallel constructs on the same level in the software stack, be they complex like the AND-OR parallelism of Prolog, or the wild-card matching +channels in coordination languages, or ultra-simple acquire and release mutex constructs. All are implemented in terms of the same tie-point primitives provided by the proto-runtime. + +We have reached a point in the paper, now, where the order of explanation can take one of two paths: either +start with the abstract model of tie-points and explain how this affects the modularization of the runtime, or start with implementation details and work upwards towards the abstract model of tie-points. We have chosen to start with the abstract tie-point model, but the reader is invited to skip to the section after it, which starts with code examples and ties code details to the abstract tie-point model. + + + +\section{The tie-point model.}\label{subsec:TiePoints} + + +\subsection{timelines} +A tie-point relates timelines, so we talk a bit, first, about timelines. A timeline is the primitive in parallelism. If you look at any parallel language, it involves a number of independent timelines. It then controls which timelines are actively progressing relative to the others. + +For example, take a thread library, which we consider +a parallel language. It provides a command to create a thread, where that thread represents an independent timeline. The library also provides the mutex acquire and release commands, which control which of those timelines advance relative to each other. When an acquire executes, it can cause the thread to block, which means the associated timeline suspends; it stops +making forward progress. The release in a different thread clears the block, which resumes the timeline. That linkage between suspend and resume of different timelines is the control the language exerts over which timelines are actively progressing. + +To build up to tie-points, we look at the nature of points on +a single timeline, by reviewing mutex behavior in detail. We see the timeline shown in Fig \ref{fig:singleTimeline}. Thread A, which is timeline A, tries to acquire the mutex, M, +by executing the acquire command. Timeline A stops, at point 1.S, then something external to it happens, and the timeline starts again at point 1.R. The gap between is not seen by the code executed within the thread. Rather, from the code-execution viewpoint, the acquire command is a single command, and hence the gap between 1.S and 1.R collapses to a single point on the timeline. + + +\begin{figure}[ht] + \centering + \includegraphics[width = 2.8in, height = 0.8in] + {../figures/PR__timeline_single.pdf} + \caption{The timeline suspends at 1.S and resumes + at 1.R. From the viewpoint of the timeline, the gap collapses into a single point.} + \label{fig:singleTimeline} +\end{figure} + + +Now, a tie-point is seen as the linkage between such collapsed points on +two timelines. In Fig \ref{fig:dualTimeline}, timeline A is still there, suspends still at 1.S and resumes at 1.R. However, now there is a second timeline, timeline B. It executes the release command at point 2.S, which suspends timeline B, performs the behavior of the release command +inside the gap, then resumes timeline B at 2.R. The behavior of the release +command causes the end of suspend in the first timeline. That causality ties the two collapsed points in the two timelines together. + + +\begin{figure}[ht] + \centering + \includegraphics[width = 2.8in, height = 1.35in] + {../figures/PR__timeline_dual.pdf} + \caption{Two timelines with a causal relationship. +Activity that takes place during the gap in timeline +B causes resume of timeline A. This ties point 2 on +timeline B to point 1 on timeline A.} + \label{fig:dualTimeline} +\end{figure} + + + +We call this connection between the collapsed suspensions a tie-point. What it provides is a guarantee about visibility of events between the tied timelines. The +guarantee makes both agree on the order of events,\textit{ +relative to the mutual tied point}. +The guarantees are what defines a tie-point. + +Fig \ref{fig:tie-pointGuarantees} shows the ordering guarantees in terms of visibility of operations between +the timelines. If these visibility constraints are +satisfied, then the timelines share a tie-point. Note that the ordering + guarantees are equivalent to the constraints on visibility of operations. Operations that execute in +the first timeline before the tie-point must be visible +in the second after the tie point, and vice versa. Likewise, operations that execute in one timeline after the tie-point must not be visible in the other timeline before the tie-point. + + + +\begin{figure}[ht] + \centering + \includegraphics[width = 2.8in, height = 1.25in] + {../figures/PR__timeline_tie_point_ordering.pdf} + \caption{The +guarantees that a tie-point enforces. Shows which + operations performed on one timeline are visible to the other +timeline. These visibilities must be true for a tie-point. +Note that all events are divided into two groups, those +before the tied points versus those after the tied +points. Both timelines see the same before group and +the same after group. } + \label{fig:tie-pointGuarantees} +\end{figure} + + +\subsection{Formal definition of tie-point} +In a moment we will show how any and all synchronization constructs +can be defined in terms of tie-points. Before getting +there, we provide a formal definition of tie-point, +which we will then use in showing that all synchronization +constructs can be implemented in terms of tie-points. + +In our formalization, we treat a tie-point as something +that exists in the code, and causes what we call an \textit{ordering-point} to +arise in every run of the code. We define ordering-point +formally, and use that to state the constraints that +a tie-point code-instance must enforce. + + +\subsubsection{Lifeline, Timeline, and Projection} +We define a formal entity that we call a lifeline, +where a timeline is a type of lifeline. +We define event-types and specific occurrences of event-types, and show how multiple lifelines can observe the same occurrence. A projection between +lifelines is defined as an event initiated upon one lifeline being observed on a different lifeline. The projection is from initiator to observer. + +\begin{description} +\item[event:] +\(E \) represents an event, which is something that +can be initiated or observed. +\item[occurrence:] +\(O\in E \times\mathbb{N}\) is the set of occurrences, where each occurrence associates a specific event with a unique identifier. A particular occurrence is denoted by subscripting with the value of the associated +integer, for example: \(O_{7}\) + +\item[clock:] +\(t:I\rightarrow\mathbb{R}^{+}\) maps each integer +onto a real number, such that \(I_{1} \) + is a lifeline, where \(\alpha\) +is a sequence over \(Dom(t)\) and each element of \(\alpha\) is either an initiation of an occurrence, or an observation +of one. A \textit{beat} of the lifeline is one tuple, denoted \(l(i)\), while the occurrence associated +to the beat is denoted\(\) \(O(l(i)) \) or equivalently \(O(\alpha(i)). \) The real value +associated with the beat is denoted \(t(l(i))\). For a given lifeline, not every element of \(t\) must have an associated +\(\alpha\), but every \(\alpha\) must have a unique associated +\(I\) from the clock \(t\). Note that \(\forall i , t(l(i)) < t(l(i+1))\). At most one beat from one +lifeline can initiate an occurrence. However, multiple +beats +from a given lifeline can observe the same occurrence, +including one initiated earlier in the sequence of +the lifeline, +and multiple lifelines may observe the same occurrence, +each multiple times. + +\item[projection:] +Given \(l_{1} = <\alpha , t_{1}> \), \(l_{2} = <\beta , t_{2}> \) then a projection from \(l_{1}\) to \(l_{2}\) + is denoted \(l_{1}(i) \uparrow l_{2}(j) \), where \(l_{1}(i) \uparrow l_{2}(j) +\equiv O(l_{1}(i)) = O(l_{2}(j))\). + This says that the occurrence initiated by the ith beat of the first lifeline is observed by the jth beat +of the second lifeline. + +\item[ordering tuple:] \(OT_{}\) is a tuple consisting +of a set of two beats from two different lifelines, which do +not participate in projections, plus a set of projections +that cross the two beats in the forward direction. +Given \(OT =<[l_{1}(x) , l_{2}(y)], [projections]> \) then \(OT\) is an +ordering tuple iff \( [projections] \neq0 \forall p(i,j) \in projections \nexists p(i,j) +|iy\ \) +\item[program run:] \(\mathcal{R} \) is a particular set of lifelines. +The program run begins with the creation of any lifeline, and +ends with the end of all lifelines. + +\item[equivalent positions in different sequences:] a partial ordering is defined. +Given two positions within different sequences, if +one or both both can be +validly rearranged, by using the partial ordering to +define valid rearrangements, so they occupy + the same position in their rearranged sequences, then +they are equivalent positions. + +\item[equivalent occurrences:] two occurrences are +equivalent if their event instances cannot be distinguished, given the observation +measurements of interest. If the observation measurement +involves sequences, then the two events must lie at +equivalent positions within their respective sequences. + +\item[equivalent lifelines:] two lifelines whose beats +can be paired, such that every beat in one lifeline +has an equivalent beat in the other. The beats do +not have to occur in the same order in both lifelines. +Beats associated to occurrences that are not of interest can be dropped. + +\item[equivalent program runs:] two runs such that +their lifelines can be paired one-to-one, with every lifeline in one paired to an equivalent +lifeline in the other. The projections between lifelines +in one run can be different from the projections in +the other run. + +\item[tie-point:] a set of beats, one from each of two lifelines, such that this set of beats forms a separation set in all equivalent program runs. +\end{description} + + +Some things to note: A particular occurrence +can be associated to at most one beat from a given +lifeline, but that same occurrence can also be associated +to beats from multiple other lifelines. Also, an occurrence may +be initiated by a lifeline but never observed by any. +Every \(O\) has a set of projections associated with it. + +For example, the event could +be writing a value into a variable. Two separate +write events are considered equivalent occurrences if +they both write the same particular value into whatever memory location +is associated to the same particular +variable, and happen within valid partial orderings +relative to the other occurrences. This is normally +compared across re-creations of the "universe" that +provides the context for the orderings of events instances. + +========= + + Okay, talked it over with Sung -- what about making distinguished beats +-- as Sung poked around for, make the PR\ "suspend" be the +distinguished beat. Then, as we worked out talking it +through, make the code that happens on the hidden timeline be the linkage between the beats -- so a tie-point is any number of distinguished beats such that the hidden calculation on one of the beats executed the resume for all of the other beats in the tie point. That establishes how a tie point gets created.. separately, need a universal statement of what is guaranteed by a tie point. + +So, one thing, is that the hidden calc is normally chosen such that every equivalent program run reproduces equivalent tie points -- but defining equivalent relies upon defining the "meaning"\ of the constructs.. but maybe that thing above about equivalent in terms of partial order can be used, by saying all constructs +are associated with a partial ordering -- but, still can have truly non-deterministic behavior being the correct behavior.. hmmm, but that should still have a partial ordering! + + What I\ really want to do is define tie-point in terms of the write-to-read. A half tie point says what's before the pre is visible after in the post timeline. And a full tie-point says that goes both ways. So, acquire-release is only a half tie-point, because what's after the release in its timeline can be seen before the acquire in its timeline. That makes it a half tie-point. Also, whats before the acquire in its timeline does not necessarily have to be seen after the release in its timeline.. that also makes it a half tie-point. + +So, use the project definition, and the crossing definition, to say which crossing projects are allowed by a half tie point, and which of those must be eliminated to make it a full tie-point. Then THAT\ defines the behaviors of a tie-point, independently from how it is created. + +The full definition of tie-point, in terms of proto-runtime value, has both those -- the hidden timeline "math" thing along with the causality, gives the "creation" aspect of tie-point, and the allowed projections gives the "behavior" aspect of tie-point. + +From the projection "behavior" I can simply state "this +defines what all synchronization constructs do" -- +the projection behavior is the whole purpose of a sync construct -- to ensure particular communication pattern when comm is via side-effect + +======= + +From first model, have the real-value constraints for slide of suspend and resume relative to each other.. + +The behavior of full tie-point is no back-cross projections, and there is a set of forward-crossing projections, which may be empty, and any of the tied timelines may +be the initiating timeline. For a half tie-point, have the origin lifeline. There is a set of forward-crossing projections with initiation on the origin lifeline, +and backward crossing are allowed whose initiation +is on non-origin lifeline. + +But a tie-point is more than just the behavior it defines. + In order for a pair of special beats to form a tie-point, +they must be causally linked on their internal lifelines. This means that a sequence of changes of the internal +state links the internal activity of one of the special beats to the internal activity of another special beat +that executes the resume that ends the second special beat. All special beats that are resumed inside the +same internal activity will have the behavior of a +full tie-point. Half tie-points can have both halves +resumed in different internal activities. + +A special beat has a variable-length span, as measured in the real-number of the clock. A special beat is associated to an isolated atomic span on a hidden lifeline. The only way to end the span of a special beat is via a "resume" beat on the hidden lifeline, which names the special beat to be ended. + +The internal activity on the hidden lifeline enforces some description. + +For +example, send-receive descriptions are: send = if paired +receiver is in shared context then resume both else place self into shared context. receive: if paired send is in shared context then resume both else place self into shared context. + +For acquire-release.. acquire: if lock-owner inside shared +context is empty then place self-name into lock-owner +and resume self else place self onto end of sequence +of special beats. release: remove self from lock-owner +and place the next in sequence of special beats into +lock-owner. If non-empty then resume the new lock-owner. +in every case, resume self. Note, acquire-release can +form either a half tie-point or a full tie-point. +? + +==== + +Note to the reader. This is a first pass at a formal description of tie-point. It likely contains more constraints than necessary. It should not be taken as the final formalism, nor is it implied to be elegant in any way, but simply an existence proof for a formal description +of a useful subset of what the intuition of tie-point associates to. + + + + + +\subsection{How a synchronization construct relates +to tie-points} + +To prepare for stating how the tie-point model can be used to +specify a synchronization construct, we first state +clearly what we mean by a ``synchronization construct''. + +The top of Fig \ref{fig:PRSyncConstrDef} shows two +independent timelines, both performing reads and writes +within a machine that has coherent shared memory. The +timelines have no relative ordering defined, so any +write on Timeline A can be received by any read of +the same address on +Timeline B, and vice versa. This means that, in general, +the use of a variable that is read and written by both will result in non-deterministic behavior. + + +\begin{figure}[ht] + \centering + \includegraphics[width = 2.0in, height = 2.8in] + {../figures/PR__timeline_sync_def.pdf} + \caption{Depicts the meaning we adopt for `synchronization construct'. One of them controls communications between timelines +by controlling the slide of timelines relative to each +other. They imply certain visibility between writes and reads on different timelines.} + \label{fig:PRSyncConstrDef} +\end{figure} + + + +To control the behavior of writes and reads to the +same addresses, a common point must be established, which +limits the ``sliding'' of the timelines relative to +each other. A synchronization construct is used for +this. +The net effect of such a construct is to establish +a common point that both timelines agree on. This +point separates reads and writes before it from reads +and writes after it. + +For example, consider a simple lock used to protect a critical section. The lock is acquired by one timeline +before entering the critical section. Any writes performed +on other timelines before the lock was granted must be complete before the critical section starts, so that reads performed inside the critical section see them. This is illustrated in the middle of Fig \ref{fig:PRSyncConstrDef}. + +The critical section ends by releasing the lock, which allows a different timeline to acquire and enter the critical section. As seen in the bottom of Fig \ref{fig:PRSyncConstrDef}, +any writes performed by that new +timeline after it acquires the lock must not be visible +to reads performed by the old timeline before it released +the lock. + +With this intuition, we define a synchronization construct +as an operation preformed on a timeline, which has +the property that it creates +a tie-point together with an operation performed on a different +timeline. Such operations that establish a tie-point +fit our definition of synchronization constructs. + + +\subsection{More on tie-points} + +Fig \ref{fig:dualTimeline} showed how a tie-point can be generated. The establishment was accomplished by +a combination of primitive mechanisms. These include: 1) suspend; 2) an `invisible' timeline that executes +behavior in the gaps; 3) resume +called from that invisible timeline; and 4) enforcement +of instruction completion relative to resume. + +What an established tie-point provides is the notion that the tied points are the same ``instant" for both tied timelines. What that means is that both timelines see events ordered relative to that point in the same way. + + +Notice that the primitives that establish a tie-point +do not involve any notion of dependency or constraint +on order of execution. It is the behavior code that runs on the invisible + timeline that embodies notions such as dependency + between units of work, mutual exclusion, + partial ordering of work, and so on. However, the + primitives do provide the notion of causality, the ordering implied by causality, and enforcing completion +of reads/writes. + +It is up to the language to supply the behavior that happens inside +the gaps, which executes on the invisible timeline. This behavior is what decides which timelines end up +sharing a tie point. It is that decision making, of which timelines to tie together, that implements the +semantics of a synchronization construct. + +A workshop paper also discusses tie points +[]. A formal treatment of tie-points is beyond the scope of this paper. However, a formal framework has been substantially completed and +will be published in a future paper. + + + +\subsection{Tie-points within a proto-runtime} + + Fig \ref{fig:dualTimeline} didn't say what entity owns the hidden timeline that executes the behavior that takes place in the gaps. This is what the proto-runtime does. An instance of the +proto-runtime executes the language plugin behavior. +It acts as the hidden timeline. + + The proto-runtime code module also supplies implementations +of the primitives that are used to establish a tie-point, including these: + + %It provides the primitive that suspends a timeline and then causes language plugin behavior to execute in the gap. + +%The plugin behavior that runs in the proto-runtime when one timeline suspends is what chooses another timeline to resume as a consequence. That choice establishes causality between the suspensions of the two timelines, and in the process ensures that a valid tie will exist between the two collapsed timeline points. The code of the primitives is provided as part of the proto-runtime code module, while the plugin behavior is executed by an instance of a running proto-runtime. + +%The running proto-runtime instance is also known as the Master, while the application timelines are known as Slaves. The behavior of the language constructs executes within the Master's timeline, while the behavior of application code executes within Slave timelines. + +%\subsection{More about the proto-runtime} + +\begin{itemize} +\item create a virtual processor (which has a suspendible timeline) +\item create a task (which has an atomic timeline that runs to completion) + +\item suspend a timeline, then invoke a function to handle the suspension -- handler is supplied with +parameters from application +\item resume a timeline, which makes it ready for execution +\item end a timeline +\item trigger choosing which virtual processor or task to begin execution on an offered +core + +\end{itemize} + +Virtual processors and tasks, both, have associated timelines. The reason for having both is a practical one, as tasks are simpler, with less overhead, +and many languages have the semantics of short, atomic, units of work that +are not intended to suspend. Thus, tasks are treated differently inside the +proto-runtime, and incur less overhead to create and run. + +A special feature of the proto-runtime is that if a task happens to execute +a language command that causes suspension, then the proto-runtime automatically +converts that task to a suspendible virtual processor. This helps support the mixing of different +languages within the same program. + + +The proto-runtime provides a mechanism for communicating information from the application code to the plugin function that was invoked to handle suspension. For example, the identity of a particular mutex a thread wishes to acquire +can be communicated from the wrapper library to the plugin. + + +Because the proto-runtime tracks all the timelines, the end of a timeline has to be explicitly stated in the application code, by calling a wrapper library function. That then invokes the proto-runtime primitive, +which informs the proto-runtime instance. The proto-runtime performs internal bookkeeping related to the ending of the timeline, and notes that the core is now free and offers it to the plugin's Assigner function. + +The proto-runtime involves the language into the process of choosing which core a given task +or virtual processor executes on. The proto-runtime maintains control, but offers free cores to the Assigner +portion of the plugin. It responds by then assigning a task or virtual processor to the core. The proto-runtime just offers, it is up to the language to decide what work that core should receive at that point in time. + + + +\subsection{Concrete Example}\label{subsec:Example} + +To make this concrete, consider the example of implementing +acquire mutex and release mutex. The semantics are: + +\begin{itemize} +\item Acquire Mutex: A thread calls the construct, +and +provides the name of the mutex. If no thread owns the +mutex, the calling thread is given ownership and it +continues to make progress. However, if a different thread +already owns the mutex, the calling thread is put into a queue +of waiting threads, and stops making progress. +\item Release Mutex: A thread calls the construct and +provides the name of the mutex. If the mutex has waiting threads in its queue, then the next thread is taken out and given ownership of the mutex. That thread is resumed, to once again make progress, as it the thread +that called the release construct.. +\end{itemize} + +This calls for a data structure that has two fields: +one holds the thread that currently owns the mutex, +the other holds a queue of threads waiting to acquire +the mutex. The semantics of a construct involve multiple +reads +and writes of the data structure. Hence, the + structure must be protected +from races between different threads. + +The protection +is where the difficulty comes into the implementation, +and where performance issues come into the picture. +It could be accomplished with a single global lock + that uses hardware primitives, or accomplished +with wait-free data structures that only rely upon the coherence +mechanism of the memory system, or even by message passing plus +quorum techniques. + +However, the implementation of the semantics is independent +of the implementation of the protection. They are orthogonal, +and an interface can be placed between them. One side +of the interface implements checking and updating the fields of +the data structure, while the other side implements +protecting the first side from interference. + +The side that provides protection requires fields, +for its use, to be placed into the data structure used +to represent a thread. To hide those details, +the protection side should also provide +primitives to create and destroy threads, as well as suspend +and resume them. + +This interface that separates the semantic side from +the protection +side is the proto-runtime interface. It is what enables +the modularization of runtime system implementations. + +The tie-point concept provides a model for thinking +about how the semantic side controls ordering among multiple threads, without exposing any details of the protection side. The tie-point model involves thinking only about actions taken during suspension of timelines (threads). It assumes that those actions are protected from interference, and that suspend and resume of timelines are primitive operations made available. The model remains constant regardless of implementation details. + That provides a cross-hardware way of specifying synchronization +behavior using just sequential thinking. The proto-runtime primitives implement the elements of the tie-point model. + + %Currently, these constructs are either implemented directly in terms of hardware level synchronization constructs such as the atomic Compare And Swap (CAS) instruction, or else are a thin wrapper that invokes operating system behavior. However, the behavior of the OS\ kernel's threading primitives are themselves implemented in terms of hardware level synchronization +%constructs. Either way, developing the behavior proves +%time consuming due to the difficulty of debugging hardware level synchronization behavior, and due to the difficulty of performance tuning such low level code across the full spectrum of patterns caused by applications. + + + + + +\section{Concrete Details} +Now that we have seen the concepts of how to modularize +a runtime system, using the tie-point model, it is +time to make the concepts concrete by showing code +segments that implement each of the concepts, and code +segments that use the concepts. We will start with +the big picture and work down. + +The first stop will be the development process, showing +how it is fractured into three separate and independent +development activities. Next, we will show examples +of how application +code invokes constructs, and follow the path of calls +down to the point it switches over to the runtime system. Lastly, +we will look at the flow of control inside the runtime, +where we will focus on the interaction between plugin +code and proto-runtime code. + +In this last portion, we will show how the +interface supplies the plugin with a consistent ``inside +the runtime" environment. Along with that, we will +show how providing +a consistent environment + is an implementation of the "single hidden timeline" portion + of the tie-point model. We will also show how it is + the existence of a \textit{single} hidden timeline + that allows the semantic portion of the language constructs +to be written in a sequential style, without regard to concurrency issues. + + +\subsection{Three independent development efforts} + +To get a handle on the big picture, we describe the +three independent paths that development takes: +one for development of proto-runtime code, one for +development of language implementation, and one for +application development. Each of these produces a separate +installable artifact. +The proto-runtime development produces a dynamic library, for each machine. The language development produces a dynamic library to plug into whichever proto-runtime library is installed on a given machine. It may also produce development tools that are used during compilation, distribution, and even installation and during the run. The application development produces a single source, which the language tools may then turn into multiple executables. + +The proto-runtime code is developed separately from +both language and application code, and packaged as a dynamic library. This library has multiple implementations. Each kind of hardware platform has a proto-runtime implemented specifically for it, and is tuned for low overhead on that hardware. The administrator of a particular machine chooses the proto-runtime implementation best suited to that hardware, and installs that. + +The language code is likewise developed separately from both proto-runtime and application code. Although multiple versions of a language may be implemented, there are significantly fewer versions than the number of proto-runtime versions. That is because most of the hardware details are abstracted away by the proto-runtime interface. + +However, the interface does expose hardware features related to placement of work onto cores, so some variations may exist for the same interface. Again, the administrator chooses which language implementation best suits their machine and installs the corresponding dynamic library. + +The wrapper library, however, is not +installed on the machine where code runs. Rather, it +is only used during development of an application, +and remains independent of hardware. + +Ideally the application is developed only once. It makes calls to the wrapper library, which in turn invokes the dynamic libraries of the language and proto-runtime. +When an application is executed, the loader binds the +dynamic libraries, connecting them to the application. + In this way, a single, +unchanging, executable gains access to machine-specific implementations of language and proto-runtime. + +However, the success of the compile-once approach has +limits in practice. Each machine's characteristics determine the size of unit of work that gives the best performance. When too small, the overhead in the runtime system that is required to create the work, manage constraints, and perform assignment becomes larger than the work +itself. When work-unit size is too large, then not enough units exist to keep all the cores busy. Thankfully, the range between is wide enough, for most applications, that neither limit is hit, on most machines. As machines evolve, though, this happy circumstance is likely to change, necessitating recompiling and possibly hand modifying the application code or some meta-form. + +\subsection{Walk through of activity during execution} + +At this point, we present a picture of the flow of control on each +of two cores, as the core is switched between application +code and runtime code. It is too early to understand +the details, but this figure can be referred back to +as each portion is discussed in the coming sub-sections. +Each portion of the figure is labelled with the sub-section that describes that portion of activity. + +At the top is the main program, which starts the proto-runtime, +and creates a proto-runtime process. Below that is +depicted the creation of proto-runtime virtual processors, +along with the animation of application code by those virtual +processors. + +? + +The application passes information to a wrapper library +call, +such as the ID of the mutex to acquire. The library function packages the +information into a request data structure, then invokes a proto-runtime +primitive. That suspends the virtual processor (timeline) that is executing +that code. The call to the primitive passes as arguments the request structure and a pointer +to the plugin function that will handle the request. +The handler runs inside the Master and chooses which +other timelines to resume as a consequence of the wrapper-library +call. Those timelines will then resume, returning from +whatever wrapper-library call caused them to suspend. In this way, the request handle implements the behavior of a +synchronization construct. + +However, there is one last step between the request +handler marking a timeline as ready to resume +and it becoming re-animated. That step is where the +assignment half of the language plugin comes into play. +The request handlers stack up work that is free to +be executed, but it is the assigner that chooses which +of those to place onto an offered core. + + + + + +\begin{figure*}[ht] + \centering + \includegraphics[width = 7.0in, height = 4.5in] + {../figures/Proto-Runtime__modules_plus_plugin_plus_code.pdf} + \caption{Illustration of the physical time sequence of the timelines of multiple virtual processors executing on multiple +cores. The timelines run top to bottom, while calls +between modules and returns run horizontally. The colors of Fn names indicate whether the +code is part of the application (green), the proto-runtime module (blue), or the language (red). The top two timelines are animated +by core 1, while the bottom 2 are animated by core +2. The boxes +represent virtual processors, each with its associated +timeline next to it. The timelines have no relative +ordering, except at tie-points established by the Request +Handlers. Gaps in the timelines are caused by suspension, +which is effected by primitives within the proto-runtime +code module.} + \label{fig:langBreakdown} +\end{figure*} + + + +\subsection{Using language constructs} +In the simple form of an eDSL, the language constructs +take the form of function calls. The reader familiar +with posix threads will have used function calls to +perform mutex acquire commands and mutex release commands. +Here, we illustrate invoking language commands in the +same way. + +We use posix threads for our example because it is +a familiar language that the reader already knows well. +It allows us to illustrate the concepts new to proto-runtime without introducing potential confusion about what the language semantics are. + +\subsubsection{Main and startup} +Before using a proto-runtime based language, the proto-runtime +system must be started, and a proto-runtime process +must be created. Fig X shows this. Notice that the +create process was given a pointer +to a function. This function is the seed of the proto-runtime +based application code. This seed must start all proto-runtime +based languages that will be used in the application, +and must create the virtual processors and tasks that +perform the work and may in turn create more VPs and/or tasks that perform work. + +==main, with PR\_\_start and PR\_\_create\_process == + +\subsubsection{Seed birth function and thread birth +function} +Fig X shows our example seed function. It first starts +the language that will be used, which is Vthread. It +is an implementation of posix threads that is on top of proto-runtime. +Next, the seed uses Vthread commands to create two +threads, and then uses Vthread join to wait for both +threads to die. Lastly it "dissipates", which is the +command that kills the virtual processor that is animating +the function. + +==seed\_birth\_Fn, with Vthread\_\_start(), Vthread\_\_create\_thread, +Vthread\_\_join, Vthread\_\_stop, and dissipate== + +Notice the signature +of the seed birth function. It returns void, and takes a pointer +to void plus a pointer to a SlaveVP struct. This is +the standard signature that must be used for all birth functions for +proto-runtime created virtual processors or tasks. + + +Also, notice that the standard signature includes a +pointer to a SlaveVP struct. This is a proto-runtime +defined structure, which holds the meta-information +about a virtual processor. The birth function is handed +the structure of the virtual processor that is animating +it. + +An illuminating aside is that the birth function for +a posix thread doesn't need +to be handed the structure representing the animating thread. +That is because the operating system tracks which thread +is assigned to which core. Posix thread constructs work by executing +an instruction that suspends the code executing on +the core and switches +the core over to animating the OS kernel code. The OS kernel +then looks up the data structure that is assigned to +the core. + +That lookup is how the OS kernel gains the +pointer to the thread that was animating the application +code that called the posix construct. But the implementation +of proto-runtime illustrated in this paper doesn't +have such a hardware based suspend instruction available, +and so proto-runtime-based application code must explicitly pass around the pointer to the data +structure of the virtual processor performing the animation. + +Fig X shows the birth function of the threads created +by the seed birth function. It uses the Vthread equivalent +of mutex acquire and release to protect access to +a critical section. Notice that the signature +is the same as the signature of the seed birth function. +Also notice that the SlaveVP structure is handed to +each invocation of a Vthread construct. In the next +several sub sections we will track how this SlaveVP structure +is used. + +==thread birth function.. uses Vthread acquire and +release to protect a counter plus print of count value== + + +\subsection{Language Wrapper Library} + +Looking at the implementation of the Vthread calls +reveals code such as in Fig X. + +==wrapper lib code for mutex acquire== + +There's nothing much to it. It just creates a data +structure, fills it, then hands it to a proto-runtime +call. This is a starnd form for wrapper library +calls. The data structure is used to carry information +into the proto-runtime (the proto-runtime that was +started by the PR\_\_start command). The PR call is +the equivalent of the hardware instruction that suspends +application code and switches to the kernel. For the +implementation of PR illustrated in this paper, this +call is implemented with assembly instructions. + +This wrapper library code is placed on the machine +used during development of the application, and is +compiled into the application executable. However, +the proto-runtime call is a link to a dynamic library, +and is not part of the application executable. + +Notice that the PR\ primitive is given a pointer to +a function. This is called the handler function, and +is part of the language plugin. The proto-runtime +will actually perform the call to the handler function, but in a carefully controlled +way. It will provide the handler function with a carefully controlled environment +to use while it handles this wrapper-library call. +We will see in a moment how proto-runtime invokes the +handler function, and what such a handler function +looks like. + +First, here's the assembly that suspends the application code and +switches to the proto-runtime code, as seen in Fig X + +==assembly of suspend and switch== + +All it does is save the program counter and stack pointer +into the SlaveVP structure, then load in the program +counter and stack pointer of the proto-runtime code, +which was previously saved in different fields of that same SlaveVP structure. + +\subsubsection{proto-runtime code that is switched +to} + +The PR assembly code switches the core to executing +the (psuedo) code seen in Fig X. + +==animation master code, which calls plugin fns== + +All this does is invoke the handler function named +in the wrapper library, and hands it an environmen. +This is the hidden environment referred to in the tie-point +model. It must be accessed in an isolated, atomic, +fashion. The proto-runtime code seen here happens +to use a global lock for each language's environment. + However other implementations are possible. In order + to keep overhead low, it uses the Compare And Swap + instruction to acquire the lock, and an exponential random + backoff scheme when contention for the lock arises. + + The handler function is the hidden behavior that executes + on the hidden timeline that is mentioned in the tie-point + model. The suspend primitive is what begins a special + beat on the lifeline of the virtual processor that + executed the wrapper library call. It is this handler + code that then establishes the causal connections + between such special beats, and so ties them together. + The causal connection is via the changes make to the + language environment. + + So, in summary, the proto-runtime is the hidden timeline. + The suspend primitive is what starts a special beat + and starts the behavior on the hidden timeline. The + lock is what isolates and sequentializes + the behavior on the hidden timeline. The language + environment is the hidden state used to establish + causal connection between special beats. + + + +This is not the plugin code, this is the library that the application executable includes. It's equivalent to the pthread library. When you look at the source of the pthread library, it's just a wrapper that invokes the OS. It doesn't do anything itself. The language libraries are the same thing, just wrappers that invoke the proto-runtime primitives. Those suspend the VP and send a message to the proto-runtime. When the message arrives, it invokes the plugin to handle the task. + +Here's how the wrapper library connects a request to the request handler: via this function pointer, right here Fig X, given to the proto-runtime "suspend and send" primitive. The pointed-to function is part of the plugin. That runs inside the proto-runtime, and is what handles the message created in the wrapper library. + + +If we go and look at that handler function, Fig X, we see that it has a standard prototype, so it takes a standard set of arguments. One of those, here in Fig X, is a language environment. This is the special sauce, it is the thing that is shared among all the cores. This language environment is where tasks are placed that are not yet ready to execute, and where suspended virtual processors are placed that are not yet ready to resume. + +Here, Fig X, you can see there's a hash table. The language environment contains that hash table. The tasks get parked in this hash table. Each time a task completes, it looks in the hash table, finds all tasks waiting for its completion, and updates the status of those waiting tasks. If this was the last task being waited for, the waiter is taken out of the hash table and put into the queue of ready to execute tasks. + +This is the semantics of the language. This is how the semantics of the language defines what dependencies are, and how it defines when a task's dependencies have been satisfied. The implementation is just a data structure in the shared language environment. It is the proto-runtime that takes care of creating the tasks, creating the virtual processors, execute those, suspend them and resume them. The proto-runtime handles the mechanics of all that stuff. The language just figures out what are the constraints on making it ready. + +? + +Separately, the proto-runtime calls the Assigner function, which is also part of the plugin dynamic library. Each time a task completes or a virtual processor suspends, the wrapper library invokes a proto-runtime primitive. Among other things, that primitive informs the proto-runtime about the completion of that work, which tells the proto-runtime that hardware resources have just been freed up. + +The proto-runtime then invokes the Assigner function, passing it information about the hardware that was just freed. The assigner is implemented by the language and uses some language-specific way to choose which of the ready work-units to execute on that hardware (a work-unit is either a ready-to-execute task or a ready-to-resume virtual processors). This is how the language is given control over placement of work onto cores. + +=================== + + +\subsection{not sure} +A task is an atomic unit of work. It runs to completion, without suspending. That characteristic allows the proto-runtime to internally treat a task differently than a virtual processor. The fact that it never suspends means it doesn't need a stack, and needs less bookkeeping, which makes a task faster to create and faster to assign, for lower overhead. + +However, a task may optionally choose at some point to execute a language command that causes it to suspend. At the point it does that, the proto-runtime internally converts the task to a virtual processor. That allows the task to suspend and later resume, at the cost of gaining the normal virtual processor overhead. However, the virtual processor the task is converted to comes from a recycle pool and returns when the task completes. + +As an application programmer, you can create processes directly with an OS-like language built on top of the proto-runtime. But you use a programming language to create tasks or virtual processors. For example, VSs has a way to create tasks. VSs internally then uses a proto-runtime command to have the proto-runtime create a task for it. Then VSs decorates the task with its own meta-data. It uses that meta-data to track when a task should be executed. + +? + +The only thing you're allowed to do outside a language is create the environment in which you start a language. + +? + +The implementation of the language behavior is the plugin. The plugin has two parts: request handlers, which handle the messages that come when a VP suspends, and an assigner, which picks where particular VP resumes onto or a task runs. With VSs, the plugin provides the behavior of "submit task". +The request handler plus plugin together provide the two halves of what people normally call a scheduler. + +================= + +\subsection{more on tie-points} +Any event visible before in one is visible in both after. The guarantee is between before in one and after in both. + +From the program point of view, that acquire statement is one instant. That entire gap in physical time is seen as a single instant to the code. + +However, the tie point is just one instant in the timelines. After the point, one of the timelines could perform an event that interferes with an event from before the tie-point, and no guarantees are given about what the other timeline sees. However, if another tie-point is created between them, then they are both guaranteed to see that second, interfering event, after the second tie-point. + +Take the example of a mutex, M. The purpose of the only-one semantics of a mutex is to isolate read and write operations done by the owning thread from those done by other threads, which own before or after it. + +The mutex behavior is illustrated in Fig X. Timeline 1 writes to variable A at point 1, then releases the M at point 2. Timeline 2 acquires M, at the tied point 2 and reads A at point 3. For M to provide isolation, it must guarantee that the A write operation at point 1 is seen by the other timeline's read operation, at point 3. Likewise, it has to guarantees that nothing that happens in timeline 2 after the acquire of M, at point 2, will be seen by timeline 1 before its release, also at point 2. + +That ordering guarantee is what we think of when we imagine the behavior of a mutex acquire-release pair. All writes done by the releasing thread are seen as completed, by reads performed in the acquiring thread, and no writes in the acquiring thread are seen before the release by the releasing thread. That is required in order to have value for the semantics of only one thread owns the mutex at any point. The purpose of only-one is to isolate read and write operations done by the owning thread from those done by the threads that own before or after it. + + +The behavior is implemented in terms of a data structure that lives inside the controlling entity's environment. The controlling entity looks up the data structure for the mutex being requested. This data structure has a field that contains the name of the thread that current owns the mutex, plus a queue of threads waiting to acquire it. So, the controlling entity first looks at the field that holds the current owner, sees that it is occupied, and then puts the thread's name into the queue of waiting threads. + +At some point later, the waiting thread reaches the top of the queue. At the point the owning thread executes the release operation, that owning thread also suspends, the controlling entity sees that suspend and that the thread wants to perform the release behavior. It looks up the release behavior and performs it. This behavior looks up the mutex data structure in the controlling entity's environment, removes the releasing thread from the owner field, takes the top thread off the waiters, writes its name into the current owner, then marks both those threads as ready to resume their timelines. + +The proto-runtime is the controlling entity, which looks up the behaviors and performs them. It also manages the environment that holds the data structures used by the behaviors. + +=========== + +The purpose of the M is to guarantee that what gets written to A here in this timeline is seen over here, in this other timeline. + +So, to turn this simple mechanism into a synchronization construct, you add semantics on top, which determine the end of suspend in the two timelines. The timelines voluntarily place themselves into suspend, and it is up to the controlling entity to decide at what point to end that suspension. It is this choice of ending suspension that ties events in one timeline to events in another. The semantics of deciding that end of suspension is the semantics of the synchronization construct. + +For example, take mutual exclusion within Threads. One thread executes a construct that asks to acquire the mutex. At the point of executing, that thread suspends, so that timeline ceases advancing. At some point later, the controlling entity sees that suspend, and sees that the timeline is attempting the acquire mutex activity. It looks up the behavior for acquire mutex, which is then performed inside that controlling entity. + +============ + + +\subsection{More on eDSLs} +%====================================== + +%We expand on the hypothesis that an embedded style Domain Specfic Language (eDSL) provides high programmer productivity, with a low learning curve. We also show (\S ) that when an application is written in a well designed eDSL, porting it to new hardware becomes simpler, because often only the language needs to be ported. That is because the elements of the problem being solved that require large amounts of computation are often pulled into the language. Lastly (\S ), we hypothesize that switching from sequential programming to using an eDSL is low disruption because the base language remains the same, along with most of the development tools and practices. + +%In \S \ref{sec:DSLHypothesis} we show that the small number of users of an eDSL means that the eDSL must be very low effort to create, and also low effort to port to new hardware. At the same time, the eDSL must remain very high performance across hardware targets. + +%In \S we analyze where the effort of creating an eDSL is expended. It turns out that in the traditional approach, it is mainly expended in creating the runtime, and in performance tuning the major domain-specific constructs. We use this to support the case that speeding up runtime creation makes eDSLs more viable. + +%In \S we take a step back and examine what the industry-wide picture would be if the eDSL approach were adopted. A large number of eDSLs will come into existence, each with its own set of runtimes, one runtime for each hardware target. That causes a multiplicative effect: the number of runtimes will equal the number of eDSLs times the number of hardware targets. Unless the effort of implementing runtimes reduces, this multiplicative effect could dominate, which would retard the uptake of eDSLs. + + +% ============== + +%Further, in \S we show that when an application is written in a well designed eDSL, porting it to new hardware becomes simpler because often only the language needs to be ported. That is because the elements of the problem being solved that require large amounts of computation are often pulled into the language. Lastly, in \S we hypothesize that switching from sequential programming to using an eDSL is low disruption because the base language remains the same, along with most of the development tools and practices. Hence, we cover how the three issues currently making parallel programming unattractive are addressed by embedded-style DSLs. + +%We next show what the blocks to eDSLs are, and where the main effort in implementing an eDSL lies. Specifically, in \S \ref{sec:DSLHypothesis} we show that the small number of users of an eDSL means that the eDSL must be very low effort to create, and also low effort to port to new hardware. At the same time, the eDSL must remain very high performance across hardware targets. + +%In \S we analyze where the effort of creating an eDSL is expended. It turns out that in the traditional approach, it is expended in creating the translator for the custom DSL syntax, in creating the runtime, and in performance tuning the major domain-specific constructs. We propose that the MetaBorg[] or Rose[] translation approaches cover creating translators for custom syntax, and that tuning constructs is inescapable, leaving the question of runtime implementation time. + +%In \S we explore the effects of runtime implementation time by taking a step back and examine what the industry-wide picture would be if the eDSL approach were adopted. A large number of eDSLs will come into existence, each with its own set of runtimes, one runtime for each hardware target. That causes a multiplicative effect: the number of runtimes will equal the number of eDSLs times the number of hardware targets. Unless the effort of implementing runtimes reduces, this multiplicative effect could dominate, which would retard the uptake of eDSLs. Thus, showing that an approach that mitigates this multiplicative effect is valuable, and is the role that the proto-runtime plays. + + + +%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% +\subsection{Details} +\label{subsec:Details} + + what responsibilities are encapsulated in which modules, and what the interfaces between them look like. + +modularization and its interface is what makes the proto-runtime reusable by all languages on given hardware, and the low-level tuning of the proto-runtime for specific hardware automatically benefits all the languages on that hardware. + +? + + + + overhead measurements + +implementation time measurements + + discuss why equivalent user-level M to N thread packages haven't been pursued, leaving no viable user-level libraries to compare against. + + give numbers that indicate that the proto-runtime approach is also competitive with Cilk, and OMPSs, on large multi-core servers. + + summary of development time of the various embedded languages created so far. Unfortunately, no control is available to compare against, but we provide estimates based on anecdotal evidence of the time taken to develop the versions compared against for overhead. In the +least, the same effort would have to be expended on +each and every language that we expended on performance +tuning our proto-runtime. + + We continue with a bigger picture discussion of the difference in design methods between traditional approaches and the proto-runtime implementations (\S ). We discuss OpenMP versus the equivalent proto-runtime version called VOMP (\S ). Then (\S ) we discuss Cilk 5.4 vs the proto-runtime VCilk. Next we discuss pthread vs Vthread (\S ), and OMPSs vs VSs (\S ). These discussions attempt to give the two design philosophies and paint a picture of the development process in the two competing approaches. The goal is to + +illustrate how the proto-runtime approach maintains many of the features, through its centralized services, while significantly reducing implementation time, through reuse of the services, elimination of concurrency concerns in design and debugging, and in the simplifications in design and implementation caused by the clean modularization of the proto-runtime approach, and the regularization of implementation from one language to another. + +Then, with the full understanding of the proto-runtime approach in hand, we discuss how it compares to related work (\S ). + +Finally, we highlight the main conclusions drawn from the work (\S ). + + + +? + + + + + The behavior module creates work and determines when work is free the execute, it tracks constraints on work imposed by language semantics, and constraints +due to data dependencies. + + a copy of the proto-runtime with language modules runs separately on each core and they communicate via shared variables in a shared language environment. The proto-runtime protects access to the shared language environment so that language modules can be written in sequential style. + +? + +The proto-runtime also implements "centralized" services that it makes available to all languages. Hardware specific functions include communicating between processors and protecting the internal state used by the language modules. + + + + this makes the proto-runtime be reused by all languages on given hardware, and the low-level tuning of the proto-runtime for specific hardware automatically benefits all the languages that run on that hardware. + + implementing language logic, + +show how the proto-runtime interface allows it to use sequential thinking. + +give similar detail on the implementation of the assigner, +we discuss how that has the potential to improve application performance by reducing communication between cores and reducing idle time of cores. + +support belief that the patterns we followed when modularizing are indeed fundamental and will remain valid for future languages and hardware. + + discuss some of the centralized services provided by the current proto-runtime implementation, as well as planned future ones. + +reusing language logic from one language implementation to another. + + +%%%%%%%%%%%%%%%%%%%%%%%% +%% +%%%%%%%%%%%%%%%%%%%%%%%% +\section{Measurements} +With the background on eDSLs and description of the proto-runtime approach behind us, we then provide overhead measurements in \S\ref{subsec:OverheadMeas} and implementation time measurements in \S\ref{subsec:ImplTimeMeas} + +\subsection{Overhead Measurements} \label{subsec:OverheadMeas} +For the following, we use a 4-core single socket 2.4Ghz laptop, and a 4 socket by 10 core each server. + +For runtime performance: + +-- Vthread vs pthread: laptop and server on exe vs task (and fibonacci?) + +-- VCilk vs Cilk: laptop and server on fibonacci (from Albert) + +-- VOMP vs OpenMP: laptop and server on exe vs task and fibonacci + +-- VSs vs OMPSs: laptop and server on fibonacci and jpeg + +\begin{tabular}{|c|c|c|c|c|c|c|}\hline +a & 2 & a & a & a & a & a \\\hline +a & 2 & a & a & a & a & a \\\hline +a & a & a & a & a & a & a \\\hline +a & a & a & a & a & a & a \\\hline +\end{tabular} +\caption{} +\label{tab} + +As seen, we didn't include application performance because we have not yet taken advantage of the opportunity to use language information to predict locality. That research is in progress and will be reported in future papers. + + +\subsubsection{Vthread Versus Highly Tuned Posix Threads} + +Measurements indicate that the proto-runtime approach has far lower overhead than even the current highly tuned Linux thread implementation, and discusses why equivalent user-level M to N thread packages haven't been pursued, leaving no viable user-level libraries to compare against. +\subsubsection{VCilk Versus Cilk 5.4} +In \S we give numbers that indicate that the proto-runtime approach is also competitive with Cilk +\subsubsection{VSs Versus StarSs (OMPSs)} +OMPSs +\subsubsection{VOMP Versus OpenMP} +VOMP + + +%%%%%%%%%%%%%%%%%%%%%%%% +%% +%%%%%%%%%%%%%%%%%%%%%%%% +\subsection{Development Time Measurements}\label{subsec:ImplTimeMeas} +Here we summarize the time to develop each of the eDSLs and copy-cat languages created so far. As a control, we estimate how long the equivalent functionality required, using the traditional approach, based on anecdotal evidence. + +Summarized in Table \ref{tabPersonHoursLang}, we measured the time we spent to design, code, and get an initial version working for each of the languages we created. The results are shown in the same order we created them, with SSR the first. As we gained experience, design and coding became more efficient. Not shown is the 7 hours required to take the send-receive code from SSR and adapt it to work with tasks in VSs. In addition, 11 hours was spent importing the DKU constructs into VSs. These are hours spent at the keyboard or with pen and paper, and don't include think time during other activities in the day. + + +\begin{centering} +\begin{tabular}{|l|r|r|r|r|r|r|} + \cline{2-7} + \multicolumn{1}{r|}{} & SSR & Vthread & VCilk & HWSim & VOMP & VSs\\ + \cline{2-7} + \noalign{\vskip2pt} + \hline + Design & 19 & 6 & 3 & 52 & 18& 6\\ + Code & 13 & 3 & 3& 32 & 9& 12\\ + Test & 7 & 2 & 2& 12 & 8& 5\\ + L.O.C. & 470 & 290 & 310& 3000 & 690 & 780\\ + \hline +\end{tabular} +\caption +{Hours to design, code, and test each embedded language. L.O.C. is lines of (original) C code, excluding libraries and comments. +} +\end{centering} +\label{tabPersonHoursLang} + +\subsubsection{Comparison of Design Approaches} +We give the bigger picture of the difference in design methods between traditional approaches and the proto-runtime implementations, discussing OpenMP versus VOMP, Cilk 5.4 vs VCilk, pthread vs Vthread, and OMPSs vs VSs. These discussions attempt to give the two design philosophies and paint a picture of the development process in the two competing approaches. The goal is to illustrate how the proto-runtime approach maintains many of the language features, through its centralized services, while significantly reducing implementation time, through reuse of the services, elimination of concurrency concerns in design and debugging, and in the simplifications in design and implementation caused by the clean modularization of the proto-runtime approach, and the regularization of implementation from one language to another. + + +%%%%%%%%%%%%%%%%%%%%%%%% +%% +%%%%%%%%%%%%%%%%%%%%%%%% +\section{Related Work} \label{sec:Related} + +With the full understanding of the proto-runtime approach in hand, we discuss how it compares to other approaches for implementing the runtimes of domain specific languages. The criteria are: level of effort to implement the runtime, effort to port the runtime, runtime performance, and support for application performance. The main alternative implementation approaches are: posix threads, user-level threads, TBB, modifying libGomp, and using hardware primitives to make a custom runtime. + +We first talk about each of these approaches, then summarize the conclusions in Table \ref{tab:CriteriaVsApproach}. + +The first three methods involve building the DSL runtime on top of OS threads, user threads, or TBB, all of which are languages in their own right. So the DSL runtime runs on top of the runtime for that lower-level language. This places control of work placement inside the lower-level runtime, blocking the DSL runtime, which hurts application-code performance, due to inability to use data locality. In addition, OS threads have operating system overhead and OS-imposed fairness requirements, which keeps runtime performance poor. + +All three also force the DSL implementation to manage concurrency explicitly, using language primitives such as locks. TBB may have a slight advantage due to its task-scheduling commands, but only for task-based languages. Hence, implementation effort is poor for these approaches. + +For the same reason, for these three, the runtime code needs to be rewritten and tuned for each hardware platform for each language, or else some form of hardware-abstraction placed into the runtime. But putting in a hardware abstraction is essentially an alternative way of implementing half of the proto-runtime approach, but without the centralization, reuse, and modularization benefits. + +Many language researchers use libGomp (based on informal discussions) because of its very simple structure, which makes it relatively easy to modify, especially for simple languages. However, it provides no services such as debugging or performance tuning, and it has no modularization or reuse across languages benefits. As the price of the simplicity, performance suffers, as seen in the experiments []. Also, re-writes of the DSL runtime are required for each platform in order to tune it to hardware characteristics. However, because the runtime is directly modified, the language gains control over placement of work, enabling good application performance. + +Lastly, we consider the alternative of writing a custom runtime from scratch, using hardware primitives such as the Compare And Swap (CAS) instruction, or similar atomic read-modify-write instructions. This approach requires the highest degree of implementation effort, and the worst portability across hardware. However, if sufficient effort is expended on tuning, it can achieve the best runtime performance and equal the best performance of application code. So far, the gap has proven small between highly tuned language-specific custom runtime performance and that of our proto-runtime, but we only have the CILK implementation as a comparison point. + +Putting this all together, Table \ref{tab:CriteriaVsApproach} shows that the proto-runtime approach is the only one that scores high in all the mesures. It makes initial language implementation fast, as well as reduces porting effort, while keeping runtime performance high and enabling high application performance. + +\begin{center} +\begin{tabular}{|c|c|c|c|c|}\hline +Runtime Creation & \textbf{impl.}& \textbf{porting} & \textbf{runtime} & \textbf{application} \\ +\textbf{} & \textbf{ease} & \textbf{ease} & \textbf{perf.} & \textbf{perf.}\\\hline +\textbf{OS Threads} & ++ & ++ & + & + \\\hline +\textbf{User Threads} & ++& ++ & ++ & + \\\hline +\textbf{TBB} & ++ & ++ & ++ & + \\\hline +\textbf{libGomp} & +++ & ++ & +++ & ++++ \\\hline +\textbf{HW primitives} & + & + & +++++ & +++++ \\\hline +\textbf{Proto-runtime} & +++++ & +++++ & ++++ & +++++\\\hline +\end{tabular} +\end{center} +\caption{The table shows how well each approach scores in each measure important to the implementor of a runtime for a DSL. On the left are the approaches that can be used to write the runtime. At the top are the measures an implementor may care about. For all measures, one plus is the lowest score, indicating the implementation approach is undesirable, 5 indicates the highest desirability. The scores are based on reasons discussed in the text. } +\label{tab:CriteriaVsApproach} + + + + +%%%%%%%%%%%%%%%%%%%%%%%% +%% +%%%%%%%%%%%%%%%%%%%%%%%% +\section{Conclusions and Future Work} +The main takeaways from the paper are first, the potential for embedded style Domain Specific Languages (eDSLs) to address the issues that are holding-back parallel programming, and second the role that the proto-runtime approach can play in making eDSLs practical, by simplifying the runtime aspect of implementing a large number of eDSLs across the many hardware targets. +%The proto-runtime approach does this by modularizing the runtimes, providing reuse of centralized services, and reuse of the hardware-specific performance tuning, which is performed once per hardware, on the proto-runtime, then enjoyed by all the eDSLs. Hence, the proto-runtime approach provides a significant piece of the puzzle of providing eDSLs, to bring parallel programming into the mainstream. + + +%[[Hypothesis: Embedded-style DSLs -> high productivity + low learning curve + low disruption + low app-port AND quick time to create + low effort to lang-port + high perf across targets]] + + +Specifically, we have shown how the approach modularizes runtime code, in a way that appears applicable to any language or execution model. It isolates the hardware-specific portion from language behavior as well as from the language-driven placement of work onto resources, providing interfaces between them. + + The modularization reduces the effort of implementing a new language, especially for an embedded-style one where runtime creation is a significant portion of total effort. It causes the low level hardware portion to be reused by each language. And, the behavior implementation is simplified, by handling shared state inside the proto-runtime and exporting a sequential interface for the behavior module to use. The simplification reduces effort, as does reuse of the hardware-specific portion, reuse of behavior code from one language to another, reuse of assignment code, and familiarity with the modular structure by implementors. Overall effort reduction was supported by measurements of implementation effort. + +The proto-runtime approach makes it practical to maintain high overall runtime performance, with low effort for the language implementor. It is practical because high effort is put into performance-tuning the hardware-specific proto-runtime, which is then reused by each language. In this way the performance derived from the high tuning effort is inherited without extra effort by the language creators, thus amortizing the cost. + +Centralized services were implemented inside the proto-runtime portion, such as debugging facilities, automated verification, concurrency handling, hardware performance information gathering, and so on. We showed how they are reused by the languages. + +Although we didn't measure it, we indicated how application performance can be increased due to giving the language direct control over placement of work, to take advantage of data affinity or application-generated communication patterns. This ability is due to the assignment module, which provides the language implementor with control over which core work is assigned to, and the order of executing each work unit. + +Work on the proto-runtime approach is in its infancy, and much remains to be done, including: +\begin{itemize} +\item Creating related interfaces for use with distributed memory hardware, and interfaces for hierarchical runtimes, to improve performance on many-level hardware such as high-performance computers, and to tie together runtimes for different types of architecture, to cover heterogeneous architectures and machines. +\item Extending the proto-runtime interface to present hardware information that a work-assigner will need, but in a generic way that remains constant across many hardware configurations yet exposes all relevant information. +\item Exploring work assignment implementations that take advantage of language and application knowledge to improve placement of work to gain higher application performance. +\item Applying the proto-runtime approach to support a portability software stack, and supply OS services to applications via the proto-runtime, to further increase application-code portability. +\end{itemize} + + +============================================= +== +== +== +== +== +============================================= + +\section{The Problem} + +[[Hypothesis: Embedded-style DSLs -\textgreater\ high productivity + low learning curve + low app-port + low disruption]] + +[[Bridge: Few users-\textgreater\ must be quick time to create + low effort to lang-port + high perf across targets]] + +[[Bridge: effort to create = runtime + effort port = runtime + perf on new target = runtime]] + +[[Bridge: big picture = langs * runtimes -\textgreater runtime effort critical]] + + +[[Claims: given big picture, runtime effort minimized -\textgreater modularize runtime, mod works across langs bec. fund patterns, mod sep lang logic from RT internals, mod makes internal reusable + lang inherit internal perf tune +inherit centralized serv, mod makes lang logic sequential, mod makes constructs reusable one lang to next, mod causes lang assigner to own HW]] + +While talking about the problems encountered by Domain Specific Languages (DSLs), we focus on implications for the runtime system, due to its central role in the claims. At the same time we will support the hypothesis that embedded-style DSLs are high-productivity for application programmers, have a low learning curve, and cause low disruption to current programming practices. While doing this we set the ground work for the next section, where we show that the main effort of implementing embedded-style DSLs is creating the runtime, and that when using the proto-runtime approach, embedded-style DSLs are low-effort to create and port and move the effort of porting for high performance out of the application and into the language. + +To give the needed depth, we'll first talk about a way to classify parallel languages according to the structure of their runtime (subsection \ref{subsec:ClassifyingLangs}). Then we'll talk about the sub-class of domain specific parallel languages, what sets them apart, and the implications for their runtime implementations (subsection \ref{subsec:DomSpecLangs}). That segues into the embedded style of language, and how the work of implementing them is mainly the work of implementing their runtime (subsection \ref{subsec:EmbeddedDSLs}). + +Once that reduction from parallel languages in general to embedded style domain specific ones in particular is done, we'll give more on what embedded style DSLs look like from an application programmer's view (subsection \ref{subsec:AppProgViewOfDSL}). We will include depth on a particular embedded-style language, showing sample code that uses the constructs, then delving into needs within the implementation of that language, and behavior of the constructs during a run (subsection []). + +The main implications for runtime systems, which were uncovered within the section, are summarized at the end (subsection []). + +\subsection{Classifying parallel languages by virtual processor based vs task based} +\label{subsec:ClassifyingLangs} +[[Hypothesis: Embedded-style DSLs -\textgreater\ high productivity + low learning curve + low app-port + low disruption]] + +[[Bridge: Few users-\textgreater\ must be quick time to create + low effort to lang-port + high perf across targets]] + +[[Bridge: effort to create = runtime + effort port = runtime + perf on new target = runtime]] + +[[Bridge: big picture = langs * runtimes -\textgreater runtime effort critical]] + + +[[Claims: given big picture, runtime effort minimized -\textgreater modularize runtime, mod works across langs bec. fund patterns, mod sep lang logic from RT internals, mod makes internal reusable + lang inherit internal perf tune +inherit centralized serv, mod makes lang logic sequential, mod makes constructs reusable one lang to next, mod causes lang assigner to own HW]] + +One major axis for classifying parallel languages is whether they are virtual processor based or task based, which has implications for the structure of the runtime. + +A virtual processor is long-lived, and has a context that persists across suspend and resume, while a task has no preceding context to fit into and leaves no implied context when done. Posix threads is a standard example of a virtual processor based parallel language, as are UPC, Charm, TBB, and so forth. All of these create virtual processors (aka threads), which suspend when they invoke synchronizations and other parallel-language constructs then resume after the construct completes. Such virtual processors have their own private stack to save the information that is needed upon resume. + +In contrast, dataflow is a standard example of a task based language, as is CnC. For these languages, a task is passed all the information it needs at the point of creation, and is expected to run to completion. If a task needs to invoke a parallelism construct, that invocation normally ends the task, while information needed by following tasks is saved explicitly in shared variables, or passed to the runtime as a continuation that is then handed to the task created when the construct completes. + +Hybrids of the two also exist, such as OpenMP which implies thread creation, via the parallel-pragma, but also creates tasks via the for-pragma. As well, StarSs (OMPSs) mixes the two, with a main thread that creates meta-tasks that have to resolve their dependencies before being turned into executable tasks. Those tasks are also able to invoke barriers and other synchronization constructs, then resume. + +The runtime implementations of the two different types of execution model differ markedly. Virtual processor (VP) based runtimes have to create a stack for each VP created, and manage the interleaving of the CPU's hardware stack. They also require a mechanism to suspend and resume the VPs, and save them in internal structures while suspended. + +In contrast, task based runtimes need ultra-fast creation of tasks, and fast linkage from the end of one to the start of the next. They tend to keep the task-structures in a queue and discard them when complete. + +Hence, VP based runtimes revolve around storing suspended VPs inside structures that embody the constraints on when the VP can resume. But task based runtimes revolve around the conditions upon which to create new tasks, and the organization of the inputs to them. The runtimes for hybrid languages have characteristics of both. + + +\subsection{Domain specific parallel languages} +\label{subsec:DomSpecLangs} +[[Hypothesis: Embedded-style DSLs -\textgreater\ high productivity + low learning curve + low app-port + low disruption]] + +[[Bridge: Few users-\textgreater\ must be quick time to create + low effort to lang-port + high perf across targets]] + +[[Bridge: effort to create = runtime + effort port = runtime + perf on new target = runtime]] + +[[Bridge: big picture = langs * runtimes -\textgreater runtime effort critical]] + + +[[Claims: given big picture, runtime effort minimized -\textgreater modularize runtime, mod works across langs bec. fund patterns, mod sep lang logic from RT internals, mod makes internal reusable + lang inherit internal perf tune +inherit centralized serv, mod makes lang logic sequential, mod makes constructs reusable one lang to next, mod causes lang assigner to own HW]] + +Now we'll talk about the sub-class of Domain Specific Languages (DSLs): what sets them apart from other parallel languages, how they potentially solve the issues with parallel programming, and the implications for their runtime implementations. + +DSLs can be any of the three basic language types (VP based, task-based or hybrid), but they are distinguished by having constructs that correspond to features of one narrow domain of applications. For example, we have implemented a DSL that is just for use in building hardware simulators [cite the HWSim wiki]. Its constructs embody the structure of simulators, and make building one fast and even simpler than when using a sequential language, as will be shown in Subsection []. The programmer doesn't think about concurrency, nor even about control flow, they simply define behavior of individual hardware elements and connect them to each other. + +It is this fit between language constructs and the mental model of the application that makes DSLs highly productive and easy to learn, at the same time, it is also what makes applications written in them more portable. Application patterns that have strong impact on parallel performance are captured as language constructs. The rest of the source code has less impact on parallel performance, so just porting the language is enough to get high performance on each hardware target. + +In practice, designing such a language is an art, and for some hardware targets, the language can become intrusive. For example, for porting to GPGPUs, their performance is driven by decomposition into many small, simple, kernels, which access memory in contiguous chunks. Fitting into this pattern forces rearrangement of the base sequential code, and even constrains choice of algorithm. Hence, a DSL that is portable to standard architectures as well as GPUs would place the GPU restrictions onto the code for all machines. However, much excellent work [polyhedral, others] is being done on automated tools to transform standard code to GPU form, which would lift the restrictions. Also, constructs such as the DKU pattern [] map well onto GPUs as well as standard hardware. + +\subsection{The embedded style of DSL} +\label{subsec:EmbeddedDSLs} +[[Hypothesis: Embedded-style DSLs -\textgreater\ high productivity + low learning curve + low app-port + low disruption]] + +[[Bridge: Few users-\textgreater\ must be quick time to create + low effort to lang-port + high perf across targets]] + +[[Bridge: effort to create = runtime + effort port = runtime + perf on new target = runtime]] + +[[Bridge: big picture = langs * runtimes -\textgreater runtime effort critical]] + + +[[Claims: given big picture, runtime effort minimized -\textgreater modularize runtime, mod works across langs bec. fund patterns, mod sep lang logic from RT internals, mod makes internal reusable + lang inherit internal perf tune +inherit centralized serv, mod makes lang logic sequential, mod makes constructs reusable one lang to next, mod causes lang assigner to own HW]] + +We segue now into the embedded style of language, and show how the work of implementing them is mainly the work of implementing their runtime plus their complex domain constructs. We focus on embedded style domain specific languages because it is the least effort-to-create form of DSL, and making DSLs practical requires it to be low effort to create them and port them to various hardware targets. + + +An embedded-style language is one that uses the syntax of a base language, like C or Java, and adds constructs that are specific to the domain. An added construct may be expressed in custom syntax that is translated to into a library call, or else directly invoked by making a library call, as illustrated in Figure \ref{fig:EmbeddedEx}. Inside the library call, a primitive is used to escape the base language and enter the embedded language's runtime, which then performs the behavior of the construct. + + +\begin{figure}[h!tb] +{\noindent +{\footnotesize +{\normalsize Creating a new virtual processor (VP):} +\begin{verbatim} +newVP = SSR__create_VP( &top_VP_fn, paramsPtr, animatingVP ); +\end{verbatim} + +{\noindent {\normalsize sending a message between VPs:}} +\begin{verbatim} +SSR__send_from_to( messagePtr, sendingVP, receivingVP ); +\end{verbatim} + +{\noindent {\normalsize receiving the message (executed in a different VP):}} +\begin{verbatim} +messagePtr = SSR__receive_from_to( sendingVP, receivingVP ); +\end{verbatim} +} +} + +\caption +{Examples of invoking embedded-style constructs. +} +\label{fig:EmbeddedEx} +\end{figure} +An embedded-style language differs from a library in that it has a runtime system, and a way to switch from the behavior of the base language to the behavior inside the runtime. In contrast, libraries never leave the base language. Notice that this means, for example, that a posix threads library is not a library at all, but an embedded language. + +As a practical matter, embedded-style constructs normally have a thin wrapper that invokes the runtime. However, some DSLs perform significant effort inside the library before switching to the runtime, or else after returning from the runtime. These look more like traditional libraries, but still involve an escape from the base language and more importantly are designed to work in concert with the parallel aspects of the language. They concentrate key performance-critical aspects of the application inside the language, such as dividing work up, or, for example, implementing a solver for differential equations that accepts structures created by the divider. + +It is the appearance of constructs being library calls that brings the low-disruption benefit of embedded-style DSLs. The syntax is that of the base language, so the existing development tools and work flows remain intact when moving to an embedded style DSL. In addition, the fit between domain concepts and language constructs minimizes mental-model disruption when switching and makes the learning curve to adopt the DSL very low. + +\subsection{Application programmer's view of embedded-style DSLs} +\label{subsec:AppProgViewOfDSL} +[[Hypothesis: Embedded-style DSLs -\textgreater\ high productivity + low learning curve + low app-port + low disruption]] + +[[Bridge: Few users-\textgreater\ must be quick time to create + low effort to lang-port + high perf across targets]] + +[[Bridge: effort to create = runtime + effort port = runtime + perf on new target = runtime]] + +[[Bridge: big picture = langs * runtimes -\textgreater runtime effort critical]] + + +[[Claims: given big picture, runtime effort minimized -\textgreater modularize runtime, mod works across langs bec. fund patterns, mod sep lang logic from RT internals, mod makes internal reusable + lang inherit internal perf tune +inherit centralized serv, mod makes lang logic sequential, mod makes constructs reusable one lang to next, mod causes lang assigner to own HW]] + +Well designed DSLs have very few constructs, yet capture the most performance-critical domain patterns, in a way that feels natural to the application programmer. This often means that data structures and usage patterns are part of the language. + +For example, a linear-equation-solving language would define a standard data structure for the coefficients of the equations, and supply a construct by which the language is asked to perform the work of solving them. This feels very much like a library, but the runtime system dynamically performs division of work according to the hardware, and implements communication between cores and a scheduler that load balances and tries to take advantage of data affinity and even computational accelerators. All of which puts performance in the hands of the runtime and is simple to use. + +An example of a DSL that we created using the proto-runtime approach is HWSim [], which is designed to be used for writing architectural simulators. + +When using HWSim, a simulator application is composed of just three things: netlist, behavior functions and timing functions. These are all sequential code that call HWSim constructs at boundaries, such as the end of behavior, and use HWSim supplied data structures. To use HWSim, one creates a netlist composed of elements and communication paths that connect them. A communication path connects an outport of the sending element to an inport of the receiving element. An action is then attached to the inport. The action is triggered when a communication arrives. The action has a behavior function, which changes the state of the element, and a timing function which calculates how much simulated time the behavior takes. + +The language itself consists of only a few standard data structures, such as \texttt{Netlist}, \texttt{Inport}, \texttt{Outport}, and a small number of constructs, such as \texttt{send\_comm} and \texttt{end\_behavior}. The advancement of simulated time is performed by a triggered action, and so is implied. The parallelism is also implied, by the only constraints on order of execution of actions being consistency. + +The only parallelism-related restriction is that a behavior function may only use data local to the element it is attached to. Parallel work is created within the system by outports that connect to multiple destination inports which means one output triggers multiple actions, and by behavior functions that generate multiple output communications each. + +Overall, simulator writers have fewer issues to deal with because time-related code has been brought inside the language, where it is reused across simulators, and because parallelism issues reduce to simply being restricted to data local to the attached element. Both these increase productivity of simulator writers, despite using a parallel language. The language has so few commands that it takes only a matter of days to become proficient (as demonstrated informally by new users of HWSim). Also, parallelism related constructs in the language are generic across hardware, eliminating the need to modify application code when porting to new hardware (if the language is used according to the recommended coding style). + +\subsection{Implementation of Embedded-style DSLs} +[[Hypothesis: Embedded-style DSLs -\textgreater\ high productivity + low learning curve + low app-port + low disruption]] + +[[Bridge: Few users-\textgreater\ must be quick time to create + low effort to lang-port + high perf across targets]] + +[[Bridge: effort to create = runtime + effort port = runtime + perf on new target = runtime]] + +[[Bridge: big picture = langs * runtimes -\textgreater runtime effort critical]] + + +[[Claims: given big picture, runtime effort minimized -\textgreater modularize runtime, mod works across langs bec. fund patterns, mod sep lang logic from RT internals, mod makes internal reusable + lang inherit internal perf tune +inherit centralized serv, mod makes lang logic sequential, mod makes constructs reusable one lang to next, mod causes lang assigner to own HW]] + +When it comes to implementing an embedded-style of DSL, the bulk of the effort is in the runtime and the more complex domain specific constructs. + +Examples of constructs implemented for DSLs include Abstract Data Types (ADTs), like linked lists, hash tables, and priority queues. Also, full algorithms, like solvers for systems of equations, or even linear algebra operations on matrices. It will be seen in subsection[] that the proto-runtime approach causes the implementation for such constructs to be reused, with high performance, across all the hardware targets in a hardware class such as the class of shared-memory multi-core platforms. + +In addition, embedded style DSLs rely heavily on data types that are part of the language. These are often domain-specific such as \texttt{Netlist}, \texttt{Inport}, and \texttt{Outport} in HWSim, or \texttt{Protein} in a bio-informatics DSL, but can also be common such as \texttt{SparseMatrix} in domains like data mining and scientific applications. + + + During language design, common patterns that consume significant development time or computation are placed into the language. Also, any patterns that expose hardware configuration, such as the number and size of pieces of work should be pulled into the language to aid portability. + +If such design is successful then porting the application reduces to just porting the language. When the language has successfully captured the main computational patterns of the domain, then the application code encapsulates only a small portion of the performance, so it does not need to be tuned. Further, when patterns that expose hardware-motivated choices or hardware-specific commands are in the language, then the application code has nothing that needs to change when the hardware changes. + +For example, HWSim pulls hardware-specific patterns inside the language by handling all inter-core communications inside the language, and also by aggregating multiple elements together on the same core to tune work-unit size. + +The advantage of placing these into the language, instead of application code, is portability and productivity. + + +\subsection{Implementation Details of Embedded-style DSLs} +[[Hypothesis: Embedded-style DSLs -\textgreater\ high productivity + low learning curve + low app-port + low disruption]] + +[[Bridge: Few users-\textgreater\ must be quick time to create + low effort to lang-port + high perf across targets]] + +[[Bridge: effort to create = runtime + effort port = runtime + perf on new target = runtime]] + +[[Bridge: big picture = langs * runtimes -\textgreater runtime effort critical]] + + +[[Claims: given big picture, runtime effort minimized -\textgreater modularize runtime, mod works across langs bec. fund patterns, mod sep lang logic from RT internals, mod makes internal reusable + lang inherit internal perf tune +inherit centralized serv, mod makes lang logic sequential, mod makes constructs reusable one lang to next, mod causes lang assigner to own HW]] + +? + +Figure [] shows\ the implementation of the wrapper library for HWSim's send\_and\_idle construct, which sends a communication on the specified outport, and then causes the sending element to go idle. Of note is the packaging of information for the runtime. It is placing into the HWSimSemReq data structure, and then the application work is ended by switching to the runtime. The switch is via the send\_and\_suspend call, which is a primitive implemented in assembly that jumps out of the base C language and into the runtime. + +The switch to the runtime can be done in multiple ways. Our proto-runtime uses assembly to manipulate the stack and registers. For posix threads language, when implemented in Linux, the hardware trap instruction is used to switch from application to the OS. The OS serves as the runtime that implements the thread behavior. + +The core is used by the construct implementation differently for VP based languages vs for task based languages. + +For VP based languages, once inside the runtime, a synchronization construct performs the behavior shown abstractly in Figure []. In essence, a synchronization construct is a variable length delay, which waits for activities outside the calling code to cause specific conditions to become true. These activities could be actions taken by other pieces of application code, such as releasing a lock, or they could be hardware related, such as waiting for a DMA transfer to complete. + +While one piece of application code (in a VP) is suspended, waiting, other pieces can use the core to perform their work, as long as the conditions for those other pieces are satisfied. Hence, the runtime's construct implementation checks if conditions are met, and if not stores the suspended piece (VP). If the construct can change conditions for others, it updates them. For example, the lock-release construct updates state for VPs waiting for the lock. Separately, for VPs whose conditions have been met, when a core becomes available, the runtime chooses which VP to assign to which core. + +These are the two behaviors a construct performs inside the runtime: managing conditions on which work is free, and managing assignment of free work onto cores. + +For task based languages, a task runs to completion then always switches to the runtime at the end. Hence, no suspend and resume exists. Once inside, the runtime's job is to track conditions on which tasks are ready to run, or which to create. For example, in dataflow, a task is created only once all conditions for starting it are met. Hence, the only language constructs are "instantiate a task-creator", "connect a task creator to others", and "end a task". During a run, all of the runtime behavior takes place inside the "end a task" construct, where the runtime sends outputs from the ending task to the inputs of connected task-creators. The "send" action modifies internal runtime state, which represents the order of inputs to a creator on all of its input ports. When all inputs are ready, it creates a new task, then when hardware is ready, assigns the task to a core. + + +One survey[] discusses DSLs for a variety of domains, and this list of DSLs was copied from their paper: +\begin{itemize} +\item In Software Engineering: Financial products [12, 22, 24], behavior control and coordination [9, 10], software architectures [54], and databases [39]. +\item Systems Software: Description and analysis of abstract syntax trees [77, 19, 51], video device driver specifications [76], cache coherence protocols [15], data structures in C [72], and operating system specialization [63]. +\item Multi-Media: Web computing [14, 35, 4, 33], image manipulation [73], 3D animation [29], and drawing [44]. +\item Telecommunications: String and tree languages for model checking [48], communication protocols [6], telecommunication switches [50], and signature computing [11]. +\item Miscellaneous: Simulation [2, 13], mobile agents [36], robot control [61], solving partial differential equations [26], and digital hardware design [41]. +\end{itemize} + +\subsection{Summary of Section} + [[Hypothesis: Embedded-style DSLs -\textgreater\ high productivity + low learning curve + low app-port + low disruption]] + +[[Bridge: Few users-\textgreater\ must be quick time to create + low effort to lang-port + high perf across targets]] + +[[Bridge: effort to create = runtime + effort port = runtime + perf on new target = runtime]] + +[[Bridge: big picture = langs * runtimes -\textgreater runtime effort critical]] + + +[[Claims: given big picture, runtime effort minimized -\textgreater modularize runtime, mod works across langs bec. fund patterns, mod sep lang logic from RT internals, mod makes internal reusable + lang inherit internal perf tune +inherit centralized serv, mod makes lang logic sequential, mod makes constructs reusable one lang to next, mod causes lang assigner to own HW]] + +This section illustrated the promise of DSLs for solving the issues with parallel programming. The HWSim example showed that well designed parallel DSLs can actually improve productivity, and have a low learning curve, as well as reduce the need for touching application code when moving to new target hardware. The section showed that the effort of implementing an embedded style DSL is mainly that of implementing its runtime and complex domain constructs, and that a well-designed DSL captures most of the performance-critical aspects of an application inside the DSL constructs. Hence, porting effort reduces to just performance-tuning the language (with caveats for some hardware). This effort is, in turn, reused by all the applications that use the DSL. + +The stumbling point of DSLs is the small number of users, after all, how many people write hardware simulators? Perhaps a few thousand people a year write or modify applications suitable for HWSim. That means the effort to implement HWSim has to be so low as to make it no more effort than writing a library, effectively a small percentage of a simulator project. + +The runtime is a major piece of the DSL implementation, so reducing the effort of implementing the runtime goes a long way to reducing the effort of implementing a new DSL. + +%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% +\section{Description} +\label{sec:idea} +[[Hypothesis: Embedded-style DSLs -\textgreater\ high productivity + low learning curve + low app-port + low disruption]] + +[[Bridge: Few users-\textgreater\ must be quick time to create + low effort to lang-port + high perf across targets]] + +[[Bridge: effort to create = runtime + effort port = runtime + perf on new target = runtime]] + +[[Bridge: big picture = langs * runtimes -\textgreater runtime effort critical]] + + +[[Claims: given big picture, runtime effort minimized -\textgreater modularize runtime, mod works across langs bec. fund patterns, mod sep lang logic from RT internals, mod makes internal reusable + lang inherit internal perf tune +inherit centralized serv, mod makes lang logic sequential, mod makes constructs reusable one lang to next, mod causes lang assigner to own HW]] + +? + + +Now that we have made the case that embedded style DSLs have potential to solve many parallel programming issues, and that a major obstacle to uptake of them is their implementation effort, we describe the proto-runtime concept and show how it addresses this obstacle to DSLs. As shown, embedded style DSL implementation effort and porting effort is mainly that of creating the runtime and implementing the more complex language constructs. We show here that the proto-runtime approach dramatically reduces the effort of creating a DSL runtime, through a number of features. + + +\begin{figure}[ht] + \centering + \includegraphics[width = 2in, height = 1.8in]{../figures/PR_three_pieces.pdf} + \caption{Shows how the proto-runtime approach modularizes the implementation of a runtime. The three pieces are the proto-runtime implementation, an implementation of the language construct behaviors, and an implementation of the portion of a scheduler that chooses which work is assigned to which processor. } + \label{fig:PR_three_pieces} +\end{figure} + + +The main feature is the proto-runtime's approach to modularizing the runtime code. As shown in Fig \ref{fig:PR_three_pieces}, it breaks the runtime into three pieces: a cross-language piece, which is the proto-runtime implementation, a piece that implements the language's constructs and plugs into the proto-runtime, and a piece that assigns work onto hardware and also plugs into the proto-runtime. + +The modularization appears to remain valid across parallel languages and execution models, and we present underlying patterns that support this observation. We analyze the basic structure of a synchronization construct, and point out how the proto-runtime modularization is consistent with it. + +\subsection{Creating an eDSL} + + +\begin{figure}[ht] + \centering + \includegraphics[width = 2in, height = 1.8in]{../figures/eDSL_two_pieces.pdf} + \caption{An embedded style DSL consists of two parts: a runtime and a wrapper library that invokes the runtime} + \label{fig:eDSL_two_pieces} +\end{figure} + +As shown in Fix \ref{fig:eDSL_two_pieces}, to create an embedded style DSL (eDSL), do two things: create the runtime and create a wrapper-library that invokes the runtime and also implements the more complex language constructs. + +As seen in Fig X, a library call that invokes a language construct is normally a thin wrapper that only communicates to the runtime. It places information to be sent to the runtime into a carrier, then invokes the runtime via a primitive. The primitive suspends the base language execution and switches the processor over to the runtime code. + +\subsection{The Proto-Runtime Modularization} + +\subsubsection{Dispatch pattern} +-- standardizes runtime code +-- makes familiar going from one lang to another +-- makes reuse realistic, as demonstrated by VSs taking SSR constructs + +-- show the enums, and the switch table + +-- point out how the handler receives critical info -- the semEnv, req struct and calling slave + +\subsubsection{The Request Handler} +-- cover what a request handler does.. connect it to the wrapper lib, and the info loaded into a request struct. + +-- give code of a request handler.. within on-going example of implementing pthreads, or possibly HWSim, or pick a new DSL + +\subsection{Exporting a performance-oriented machine view } +The proto-runtime interface exports a view of the machine that shows performance-critical aspects. Machines that share the same architectural approach have the same performance-critical aspects, and differ only in the values. + +For example, the interface models cache-coherent shared-memory architectures as a collection of memory pools connected by networks. The essential variations among processor-chips are the sizes of the pools, the connections between them, such as which cores share the same L2 cache, and the latency and bandwidth between them. + +Hence, a single plugin can be written that gathers this information from the proto-runtime and uses it when deciding which work to assign to which core. Such a plugin will then be efficient across all machines that share the same basic architecture. + +This saves significant effort by allowing the same plugin to be reused for all the machines in the category. + +\subsection{Services Provided by the Proto-runtime} + +-- Put services into the low-level piece.. plugins have those available, and inherit lang independent such as debugging, perf counters.. provides effort reduction because lang doesn't have to implement these services. + +-- -- examples of iherited lang services inside current proto-runtime: debugging and perf-tuning.. verification, playback have been started (?) + +-- -- examples of plugin services: creation of base VP, the switch primitives, the dispatch pattern (which reduces effort by cleanly separating code for each construct), handling consistency model (?), handling concurrency + +\subsection{eDSLs talking to each other} +-- show how VSs is example of three different DSLs, and H264 code is three different languages interacting (pthreads, OpenMP, StarSs) + +-- make case that proto-runtime is what makes this practical ! Their point of interaction is the common proto-runtime innards, which provides the interaction services.. they all use the same proto-runtime, and all have common proto-runtime objects, which is how the interaction becomes possible. + +\subsection{The Proto-runtime Approach Within the Big Picture} + +-- Give background on industry-wide, how have langs times machines.. +-- say that proto-runtime has synergistic advantages within this context. -- repeat that eDSLs talk to each other. +-- give subsubsection on MetaBorg for rewriting eDSL syntax into base lang syntax. +-- bring up the tools issue with custom syntax -- compiling is covered by metaborg re-writing.. can address debugging with eclipse.. should be possible in straight forward way that covers ALL eDSLs.. their custom syntax being stepped through in one window, and stepping through what they generate in separate window (by integrating generation step into eclipse).. even adding eclipse understanding of proto-runtime.. so tracks the sequence of scheduling units.. and shows the request handling in action in third window.. + +Preview idea that many players will contribute, and will get people that specialize in creating new eDSLs (such as one of authors).. +-- For them, code-reuse is reality, as supported by VSs example, +-- and the uniformity of the pattern becomes familiar, also speeding up development, as also supported by VSs, HWSim, VOMP, and DKU examples. +-- for those who only create a single eDSL, the pattern becomes a lowering of the learning curve, aiding adoption + +-- Restate and summarize the points below (covered above), showing how they combine to shrink the wide-spot where all the runtimes are. + +-- The low-level part implemented on each machine, exports a view of the machine that shows performance-critical aspects + +-- Collect machines into groups, based on performance critical aspects of hardware.. provides reduction in effort because only one plugin for entire group. + +-- Put services into the low-level piece.. plugins have those available, and inherit lang independent such as debugging.. provides effort reduction because lang doesn't have to implement these services. + + +\section{(outline and notes)} + +-- What a plugin looks like: + +-- -- pattern of parallel constructs.. ideas of Timeline, tie-point, animation, suspension, VP states, constraints, causality, work-units, meta-units, updates in constraint states attached to the meta-units + +-- -- a sych construct is something that creates a tie between two work-units. So, the logic of the construct simply establishes causality -- the ending of one work-unit causes the freedom to start animation of another. + +-- -- -- Examples: mutex is end of work-unit that frees lock causes freedom to start work-unit that gets the lock. They are causally tied. The semantics of the construct is the particular conditions existing inside the runtime (in this case ownership condition of a mutex), and what changes those conditions (in this case releasing lock removes one from owner, plus acquire-lock sets one as wanting the lock), and how freedom to be animated is affected by the changes in conditions (in this case, removal of ownership must precede gaining ownership) on what makes a work-unit free (in this case, being given ownership of the mutex), + +-- Hence, precisely, the parallelism model of the language defines constraints, which are implemented as state inside the runtime. Constructs provided do a number of things: signal bringing a set of constraints into existence (create a mutex), signal update to the state of those constraints (release mutex, state desire to acquire), and trigger the runtime to propagate those changes, which results in additional changes to states, including marking meta-units as free to be animated. cause creation of meta-units (explicitly as in VSs, or via creating entities that trigger creation as in dataflow, or via creating entities that consist of consecutive work-units as in pthreads). + + +-- Recipe for how to make the language plugin: time reduction is part due to simplifying the parallelism construct logic.. + + + + +\subsection{The Cross-language Patterns Behind the Proto-runtime} + +[[Hypothesis: Embedded-style DSLs -\textgreater\ high productivity + low learning curve + low app-port + low disruption]] + +[[Bridge: Few users-\textgreater\ must be quick time to create + low effort to lang-port + high perf across targets]] + +[[Bridge: effort to create = runtime + effort port = runtime + perf on new target = runtime]] + +[[Bridge: big picture = langs * runtimes -\textgreater runtime effort critical]] + + +[[Claims: given big picture, runtime effort minimized -\textgreater modularize runtime, mod works across langs bec. fund patterns, mod sep lang logic from RT internals, mod makes internal reusable + lang inherit internal perf tune +inherit centralized serv, mod makes lang logic sequential, mod makes constructs reusable one lang to next, mod causes lang assigner to own HW]] + +An application switches to the runtime, which does scheduling work then switches back to application code. + + +\subsection{Some Definitions} + +[[Hypothesis: Embedded-style DSLs -\textgreater\ high productivity + low learning curve + low app-port + low disruption]] + +[[Bridge: Few users-\textgreater\ must be quick time to create + low effort to lang-port + high perf across targets]] + +[[Bridge: effort to create = runtime + effort port = runtime + perf on new target = runtime]] + +[[Bridge: big picture = langs * runtimes -\textgreater runtime effort critical]] + + +[[Claims: given big picture, runtime effort minimized -\textgreater modularize runtime, mod works across langs bec. fund patterns, mod sep lang logic from RT internals, mod makes internal reusable + lang inherit internal perf tune +inherit centralized serv, mod makes lang logic sequential, mod makes constructs reusable one lang to next, mod causes lang assigner to own HW]] + +We adopt the concepts of work-unit, virtual processor (VP), animation, and tie-point as discussed in a previous paper []. A work-unit is the trace of instructions executed between two successive switches to the runtime, along with the data consumed and produced during that trace. A Virtual Processor is defined as being able to animate either the code of a work-unit or else another VP, and has state that it uses during animation, organized as a stack. Animation is definedd as causing time of a virtual processor to advance, which is equivalent to causing state changes according to instructions, while suspension halts animation, and consequently causes the end of a work-unit (a more complete definition of animation can be found in the dissertation of Halle[]). A tie-point connects the end of one work-unit to the beginning of one in a different VP, so a tie-point represents a causal relationship between two work-units, and establishes an ordering between those work-units, effectively tying the time-line of the VP animating one to the time-line of the VP animating the other work-unit. + +In addition, we introduce a definition of the word task, which is a single work-unit coupled to a virtual-processor that comes into existence to animate the work-unit and dissipates at completion of the work-unit. By definition of work-unit, a task cannot suspend, but rather runs to completion. If the language defines an entity that has a timeline that can be suspended by switching to the runtime, then such an entity is not a task. Pure Dataflow[] specifies tasks that fit our definition. + +\subsection{Handling Memory Consistency Models} + +[[Hypothesis: Embedded-style DSLs -\textgreater\ high productivity + low learning curve + low app-port + low disruption]] + +[[Bridge: Few users-\textgreater\ must be quick time to create + low effort to lang-port + high perf across targets]] + +[[Bridge: effort to create = runtime + effort port = runtime + perf on new target = runtime]] + +[[Bridge: big picture = langs * runtimes -\textgreater runtime effort critical]] + + +[[Claims: given big picture, runtime effort minimized -\textgreater modularize runtime, mod works across langs bec. fund patterns, mod sep lang logic from RT internals, mod makes internal reusable + lang inherit internal perf tune +inherit centralized serv, mod makes lang logic sequential, mod makes constructs reusable one lang to next, mod causes lang assigner to own HW]] + +Weak memory models can cause undesired behavior when work-units on different cores communicate through shared variables. Specifically, the receiving work-unit can see memory operations complete in a different order than the code of the sending work-unit specifies. + +For example, consider a proto-runtime implemented on shared memory hardware that has a weak consistency model, along with a language that implements a traditional mutex lock. All memory operations performed in the VP that releases the lock should be seen as complete by the VP that next acquires the lock. + +It is up to the proto-runtime to enforce this, using hardware primitives. It has to ensure that all memory operations performed, by a task or VP, before switching to the runtime are completed before any dependent task or VP is switched into from the runtime. More precisely, the proto-runtime has to ensure that all memory operations performed by a work-unit are visible in program order to any tied work-units. In some cases the language plugin has to alert the proto-runtime of the causality between work-units. + + +The proto-runtime does not, however, protect application code that attempts to communicate between VPs or tasks directly, without using a parallelism construct to protect the communication. + + + +======= + + I plan to explain VMS as a universal pattern that exists in all runtimes: that is, that the application switches to runtime, which does a scheduling decision and then switches back. I'll explain it first with just master and slaves, leaving out the core\_loop. Explain it as a normal runtime that has had two key pieces removed and replaced with interfaces. The language supplies the missing pieces. Then, introduce the core\_loop stuff as a performance enhancement used when lock acquisition dominates (as it does on the 4 socket 40 core machine). + Next, give HWSim as an example of a real domain specific (it's working, ref manual attached), and focus on how the modularity allowed pulling constructs from other languages (singleton and atomic), and a breakdown of implementation time vs design time, and so on. Highlight how VMS's features for productivity and encapsulation solve the practical problems for domain-specific languages. + Finally, show that VMS performance is good enough, by going head-to-head with pthreads and OpenMP (doing a VMS OpenMP implementation now). And also StarSs if I have time. I'll run overhead-measuring on them, and also regular benchmarks. + +================= + +\subsection{The patterns} +[[Hypothesis: Embedded-style DSLs -\textgreater\ high productivity + low learning curve + low app-port + low disruption]] + +[[Bridge: Few users-\textgreater\ must be quick time to create + low effort to lang-port + high perf across targets]] + +[[Bridge: effort to create = runtime + effort port = runtime + perf on new target = runtime]] + +[[Bridge: big picture = langs * runtimes -\textgreater runtime effort critical]] + + +[[Claims: given big picture, runtime effort minimized -\textgreater modularize runtime, mod works across langs bec. fund patterns, mod sep lang logic from RT internals, mod makes internal reusable + lang inherit internal perf tune +inherit centralized serv, mod makes lang logic sequential, mod makes constructs reusable one lang to next, mod causes lang assigner to own HW]] + + +Soln: modularize runtime, to reduce part have to mess with, hide part that has low-level details, reuse low-level tuning effort, and reuse lang-spec parts. + +Benefits: lang impl doesn't have to touch low-level details, inherit centralized services, can reuse code from other languages to add features. + +Performance must be high, or the labor savings don't matter. By isolating the low-level details inside the proto-runtime, they can be intensively tuned, then all the languages inherit the effort. + +Part of what makes this so easy is the dispatch pattern.. adding a construct reduces to adding into switch and writing handler.. borrow constructs by taking the handler from the other lang. + +By isolating the low-level details inside the proto-runtime, they can be intensively tuned, then all the languages inherit the effort. Compare that to current practices, where the runtime code is monolithic.. each language has to separately modify the runtime, understanding and dealing with the concurrency, and then on a new machine, each language has to re-tune the low-level details, worrying about the consistency model on that machine, how its particular fence and atomic instructions work, and so on. +We spent 2 months performance tuning the current version, but only 18 hours implementing VSs on top of it, and VSs inherited the benefit from all that effort. So did VOMP, and SSR, and VCilk, and so on.. each time we improved the proto-runtime, all the languages improved, with no effort on the part of the language creator. + + +\subsubsection{Views of synchronization constructs} +[[Hypothesis: Embedded-style DSLs -\textgreater\ high productivity + low learning curve + low app-port + low disruption]] + +[[Bridge: Few users-\textgreater\ must be quick time to create + low effort to lang-port + high perf across targets]] + +[[Bridge: effort to create = runtime + effort port = runtime + perf on new target = runtime]] + +[[Bridge: big picture = langs * runtimes -\textgreater runtime effort critical]] + + +[[Claims: given big picture, runtime effort minimized -\textgreater modularize runtime, mod works across langs bec. fund patterns, mod sep lang logic from RT internals, mod makes internal reusable + lang inherit internal perf tune +inherit centralized serv, mod makes lang logic sequential, mod makes constructs reusable one lang to next, mod causes lang assigner to own HW]] + +One view of sync constructs is that they are variable-length calls. The +basic hardware does this by stalling the pipeline. + +Another view is that they mark the boundary of a communication made via shared read/write. A load or store of a single location has a precise boundary enforced by the hardware, but if a pipeline desires to load, modify, then write a single location it has to have additional hardware. It has to make the multiple primitive load/store operations appear as a single operation. + +Moving up to the application level, the same pattern exists: an operation the application wants to do may involve many loads and stores, but it wants the collection to appear as a single indivisible operation. So the application-level equivalent of a load or store involves multiple memory locations but is to be treated as a single indivisible operation. This requires the application-level equivalent of the hardware that made the read-modify-write into a single indivisible operation. That equivalent is what a synchronization construct is. The reason a sync construct takes a variable amount of time is that it waits until all other indivisible operations that might conflict have completed. + +Another way to think of the sync construct is that it enforces sharp communication boundaries. The multiple read and write operations are treated as a single communication with the shared-state. If any other part of the application sees only part of the communication, it sees something inconsistent and thus wrong. So the sync constructs ensure that communications are complete, so the parts of the application only see complete communications from other parts. + +\subsubsection{Universal Runtime Patterns} +[[Hypothesis: Embedded-style DSLs -\textgreater\ high productivity + low learning curve + low app-port + low disruption]] + +[[Bridge: Few users-\textgreater\ must be quick time to create + low effort to lang-port + high perf across targets]] + +[[Bridge: effort to create = runtime + effort port = runtime + perf on new target = runtime]] + +[[Bridge: big picture = langs * runtimes -\textgreater runtime effort critical]] + + +[[Claims: given big picture, runtime effort minimized -\textgreater modularize runtime, mod works across langs bec. fund patterns, mod sep lang logic from RT internals, mod makes internal reusable + lang inherit internal perf tune +inherit centralized serv, mod makes lang logic sequential, mod makes constructs reusable one lang to next, mod causes lang assigner to own HW]] + +Unified pattern within parallel languages: create multiple timelines, then control relative progress of them, and control location each chunk of progress takes place. + +Another universal pattern: code runs, switches to runtime, some point later switches back to code, making application run be a collection of trace segments bounded by runtime calls. +The runtime tracks constraints (dependencies) among units, creates and destroys units, and assigns ready units to hardware. + +Units have a life-line, which is fundamental to parallel computation, as demonstrated in a paper by some of the authors []. + +Every unit has a meta-unit that represents it in the runtime. A unit is defined as the trace of application code that exists between two scheduling decisions. Looking at this in more detail, every runtime has some form of internal bookkeeping state for a unit, used to track constraints on it and make decisions about when and where to execute. This exists even if that state is just a pointer to a function that sits in a queue. We call this bookkeeping state for a unit the meta-unit. + +Each unit also has a life-line, which progresses so: creation of the meta-unit \pointer , state updates that affect constraints on the unit \pointer, the decision is made to animate the unit \pointer, movement of the meta-unit plus data to physical resources that do the animation \pointer , animation of the unit, which does the work \pointer, communication of state-update, that unit has completed, and hardware is free \pointer , constraint updates within runtime, possibly causing new meta-unit creations or freeing other meta-units to be chosen for animation. This repeats for each unit. Each step is part of the model. + +Note a few implications: first, many activities internal to the runtime are part of a unit's life-line, and take place when only the meta-unit exists, before or after the work of the actual unit; second, communication that is internal to the runtime is part of the unit life-line, such as state updates; third, creation may be implied, such as in pthreads, or triggered such as in dataflow, or be by explicit command such as in StarSs, and once created, a meta-unit may languish before the unit it represents is free to be animated. + +\subsubsection{Putting synchronization constructs together with universal runtime patterns} +[[Hypothesis: Embedded-style DSLs -\textgreater\ high productivity + low learning curve + low app-port + low disruption]] + +[[Bridge: Few users-\textgreater\ must be quick time to create + low effort to lang-port + high perf across targets]] + +[[Bridge: effort to create = runtime + effort port = runtime + perf on new target = runtime]] + +[[Bridge: big picture = langs * runtimes -\textgreater runtime effort critical]] + + +[[Claims: given big picture, runtime effort minimized -\textgreater modularize runtime, mod works across langs bec. fund patterns, mod sep lang logic from RT internals, mod makes internal reusable + lang inherit internal perf tune +inherit centralized serv, mod makes lang logic sequential, mod makes constructs reusable one lang to next, mod causes lang assigner to own HW]] + +Putting these together, gives us that any parallelism construct that has a synchronization behavior causes the end of a work-unit, and a switch to the runtime. The code following the construct is a different work-unit that will begin after the constraint implied by the construct is satisfied. + +The runtime is made up of the infrastructure for the constraints and assignment, such as communicating bookkeeping state between cores, and protecting internal runtime updates of shared information. Plus, the logic of the constructs and logic of choosing an assignment of work to cores. + +For large machines, the infrastructure dominates the time to execute a parallelism construct, while for smaller machines, like single-socket, the logic of constructs and assignments has a chance to be significant. + +\begin{figure}[ht] + \centering + \includegraphics[width = 2in, height = 1.8in]{../figures/SCG_stylized_for_expl.pdf} + \caption{Something to help understanding} + \label{fig:SCG_expl} +\end{figure} + + + + +%%%%%%%%%%%%%%%%%%%%% +\section{The Details} +[[Hypothesis: Embedded-style DSLs -> high productivity + low learning curve + low disruption + low app-port AND quick time to create + low effort to lang-port + high perf across targets]] +[[Claims: modularize runtime, mod is fund patterns, mod sep lang logic from RT internals, mod makes internal reusable & lang inherit internal perf tune & inherit centralized serv, mod makes lang logic sequential, mod makes constructs reusable one lang to next, mod causes lang assigner to own HW]] + +The interfaces between lang logic and proto-runtime. + +Demonstrate: modular runtime, how reduces part have to mess with, hides part that has low-level details, reuses low-level tuning effort, and reuses lang-spec parts. + +Demonstrate Benefits: lang impl doesn't touch low-level details, inherits centralized services (debug support), reuses code from other languages to add features. + +\subsection{Reuse of Language Logic} +[[Hypothesis: Embedded-style DSLs -\textgreater\ high productivity + low learning curve + low app-port + low disruption]] + +[[Bridge: Few users-\textgreater\ must be quick time to create + low effort to lang-port + high perf across targets]] + +[[Bridge: effort to create = runtime + effort port = runtime + perf on new target = runtime]] + +[[Bridge: big picture = langs * runtimes -\textgreater runtime effort critical]] + + +[[Claims: given big picture, runtime effort minimized -\textgreater modularize runtime, mod works across langs bec. fund patterns, mod sep lang logic from RT internals, mod makes internal reusable + lang inherit internal perf tune +inherit centralized serv, mod makes lang logic sequential, mod makes constructs reusable one lang to next, mod causes lang assigner to own HW]] + +Demonstrate reuse of language logic: +All the languages have copied singleton, atomic, critical section and transaction. In VOMP, took the task code from VSS, in VSS, took the send and receive code from SSR.. for DKU, took the code almost verbatim from earlier incarnation of these ideas, and welded it into SSR, and took VSs tasks and put into SSR. Thus, circle completes.. VSs took from SSR, now SSR takes from VSs.. pieces and parts are being borrowed all over the place and welded in where they're needed. + +Part of what makes this so easy is the dispatch pattern.. adding a construct reduces to adding into switch and writing handler.. borrow constructs by taking the handler from the other lang. + +Another part is that code for the constructs is isolated from concurrency details, which are inside the proto-runtime. All the dynamic system issues, and best way to impl locks, and need for fences, and so on is isolated from the construct logic. This isolation is also how porting effort is lowered (or in many cases eliminated), and is how runtime performance is kept high. + +? + +Performance must be high, or the labor savings don't matter. By isolating the low-level details inside the proto-runtime, they can be intensively tuned, then all the languages inherit the effort. Compare that to current practices, where the runtime code is monolithic.. each language has to separately modify the runtime, understanding and dealing with the concurrency, and then on a new machine, each language has to re-tune the low-level details, worrying about the consistency model on that machine, how its particular fence and atomic instructions work, and so on. +We spent 2 months performance tuning the current version, but only 18 hours implementing VSs on top of it, and VSs inherited the benefit from all that effort. So did VOMP, and SSR, and VCilk, and so on.. each time we improved the proto-runtime, all the languages improved, with no effort on the part of the language creator. + +? + +In addition to runtime performance, application level performance must be high. The runtime's performance only affects overhead, and so is only a factor for small work-unit (task) sizes. But data affinity affects performance for all work. + +The proto-runtime approach partially addresses this by giving the language the opportunity to directly control placement of work. This isn't possible when building on top of threads, because the scheduling is in a separate, lower-level, layer where assignment of work to core is made in isolation, blind to language constructs and +other application features. + + + + +%%%%%%%%%%%%%%%%%%%%% +\section{Measurements} + +\subsection{Implementation time} + + +\subsection{Runtime and Application Performance} + + +%%%%%%%%%%%%%%%%%%%%% +\section{Related Work} + + +%%%%%%%%%%%%%%%%%%%%% +\section{Conclusion and Future Work} +\label{sec:conclusion} + + + +\end{document} +%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% +Here is an example of netlist creation: + +The circuit has two elements, each with one input port, one output port, and a single activity-type. The elements are cross-coupled, so output port of one connects to input port of the other. The input port has the activity-type attached as its trigger. The activity is empty, and just sends a NULL message on the output port. The activity's duration in simulated time and the resulting communication's flight duration in simulated time are both constants. + + Note that HWSimElem data type is generic. An elem is specialized by declaring inports and outports, and by connecting activity types to in-ports. Behavior is attached to an element by attaching activity types to in-ports of the element. + +First, here is the top-level function that creates and returns the netlist structure: + +To use HWSim, one creates a netlist composed of elements and communication paths connecting them. An element has a number of in-ports and outports, and a communication path connects an outport of the source element to an inport of the destination elements. The inport has an action attached, which in turn has a behavior function and a timing function, both of which are triggered by the arrival of a communication. The behavior function has local persistent state of the element available to use, and can generate out-going communications. The timing function calculates how much Guest (simulated) time the behavior spanned. In addition, communication paths have an attached function that calculates time from being sent until arrival of the communication. Both the behavior and timing function are application-programmer provided. The entire simulator application is composed of those three things: netlist, behavior functions and timing functions, and all are sequential code. + +The embedded DSL consists of standard data structures, such as netlist, inport, outport, that the application must use in the language-defined way, and a small number of language calls, such as send_comm and end_behavior. The advancement of simulated time is implied, and the parallelism is implied. The only parallelism-related restriction is that a behavior function may only use data local to the element it is attached to. If state in the hardware is shared, such as registers or memory, then other elements access that state by sending communications to the element that contains the state. Parallelism is created within the system by outports that connect to muliple destination inports, and by behavior functions that generate multiple output communications each. + + +\begin{small}\begin{verbatim} +HWSimNetlist * +createPingPongNetlist() + { HWSimNetlist *netlist; + HWSimElem **elems; + HWSimActivityType **activityTypes; + HWSimCommPath **commPaths; + int32 numElems, numActivityTypes, numCommPaths; +\end{verbatim}\end{small} + +The first thing to do is create the netlist structure, which holds three things: element structs, activity type structs, and communication path structs. It also has two collections of pointers to the traces collected during the run, but these are handled internally by HWSim. +\begin{small}\begin{verbatim} + netlist = malloc( sizeof(HWSimNetlist) ); + + numElems = 2; + elems = malloc( numElems * sizeof(HWSimElem *) ); + + numCommPaths = 2; + commPaths = malloc( numCommPaths * sizeof(HWSimCommPath *) ); + + numActivityTypes = 1; + activityTypes = malloc( numActivityTypes * sizeof(HWSimActivityType *) ); + + netlist->numElems = numElems; + netlist->elems = elems; + netlist->numCommPaths = numCommPaths; + netlist->commPaths = commPaths; + netlist->numActivityTypes = numActivityTypes; + netlist->activityTypes = activityTypes; +\end{verbatim}\end{small} + +Now, create the activity types. During the run, an activity instance is created each time a communication arrives on an in-port. The activity instance is a data structure that points to the activity type. The activity type holds the pointers to the behavior and timing functions. +\begin{small}\begin{verbatim} + //have to create activity types before create elements + //PING_PONG_ACTIVITY is just a #define for readability + netlist->activityTypes[PING_PONG_ACTIVITY] = createPingPongActivityType(); +\end{verbatim}\end{small} + +Next, create the elements, and pass the netlist structure to the creator. It will take pointers to activity types out of the netlist and place them into the in-ports of the elements. +\begin{small}\begin{verbatim} + elems[0] = createAPingPongElem( netlist ); //use activity types from netlist + elems[1] = createAPingPongElem( netlist ); +\end{verbatim}\end{small} + +Now, the reset in-port of one of the elements has to be set up to trigger an activity. Every element has a reset in-port, but normally they are set to NULL activity type. Here, we want only one of the two elements to have an activity triggered when the reset signal is sent to start the simulation. + +Note that during initialization, all the elements become active, each with its own timeline, but unless an activity is triggered in them they remain idle, with their timeline suspended and not making progress. Only ones that have an activity type attached to their reset in-port will begin to do something in simulated time when simulation starts. +\begin{small}\begin{verbatim} + //make reset trigger an action on one of the elements + elems[1]->inPorts[-1].triggeredActivityType = + netlist->activityTypes[PING_PONG_ACTIVITY]; +\end{verbatim}\end{small} + +Now, connect the elements together by creating commPath structures. A comm path connects the out-port of one element to the in-port of another. A given port may have many comm paths attached. However, an in-port has only one kind of activity type attached, and all incoming communications fire that same activity. There are multiple kinds of activity, including kinds that have no timing, and so can act as a dispatcher. These end themselves with a continuation activity, which is chosen according to the code in the behavior function. So, a commPath only connects an out port to an in port. + +This code sets fixed timing on the comm paths. It also uses a macro for setting the connections. The format is: sending elem-index, out-port, dest elem-index, in-port: +\begin{small}\begin{verbatim} + //elem 0, out-port 0 to elem 1, in-port 0 + commPaths[0]= malloc(sizeof(HWSimCommPath)); + setCommPathValuesTo(commPaths[0],0,0,1,0); + commPaths[0]->hasFixedTiming = TRUE; + commPaths[0]->fixedFlightTime = 10; //all time is stated in (integer) units + + //elem 1, out-port 0 to elem 0, in-port 0 + commPaths[1]= malloc(sizeof(HWSimCommPath)); + setCommPathValuesTo(commPaths[1], 1,0,0,0); + commPaths[1]->hasFixedTiming = TRUE; + commPaths[1]->fixedFlightTime = 10; //all time is stated in (integer) units +\end{verbatim}\end{small} + +done building netlist, return it +\begin{small}\begin{verbatim} + return netlist; + } +\end{verbatim}\end{small} + +The macro that sets the connections inside a comm path struct +\begin{small}\begin{verbatim} +#define setCommPathValuesTo( commPath, fromElIdx, outPort, toElIdx, inPort)\ +do{\ + commPath->idxOfFromElem = fromElIdx; \ + commPath->idxOfFromOutPort = outPort; \ + commPath->idxOfToElem = toElIdx; \ + commPath->idxOfToInPort = inPort; \ + }while(0); //macro magic for namespace +\end{verbatim}\end{small} + +Creating an element involves creating arrays for the in-ports and out-ports, then configuring the in-ports. The out-ports are automatically filled in during simulation start-up, by HWSim. The most interesting feature is that each in-port is assigned an activity type, which all arriving communications trigger. During the simulation, each incoming communication creates an activity instance, which points to this triggered activity type. The behavior and timing of the instance are calculated by the behavior and timing functions in the activity type. Notice that the activity type pointers are taken from the netlist, so they have to be created before creating the elements. +\begin{small}\begin{verbatim} +HWSimElem * +createAPingPongElem( HWSimNetlist *netlist ) + { HWSimElem *elem; + elem = malloc( sizeof(HWSimElem) ); + elem->numInPorts = 1; + elem->numOutPorts = 1; + elem->inPorts = HWSim_ext__make_inPortsArray( elem->numInPorts ); + elem->inPorts[-1].triggeredActivityType = IDLE_SPAN; //reset port + elem->inPorts[0].triggeredActivityType = netlist->activityTypes[PING_PONG_ACTIVITY]; + return elem; + } +\end{verbatim}\end{small} + +Creating an activity type involves setting the pointers to the behavior and timing functions, which are defined inside a separate directory where all the behavior and timing functions are defined. An activity may have behavior set to NULL, or timing set to NULL, and may have fixed timing. The structure has flags to state the combination. +\begin{small}\begin{verbatim} +HWSimActivityType * +createPingPongActivityType( ) + { HWSimActivityType *pingPongActivityType; + pingPongActivityType = malloc( sizeof(HWSimActivityType) ); + + pingPongActivityType->hasBehavior = TRUE; + pingPongActivityType->hasTiming = TRUE; + pingPongActivityType->timingIsFixed = TRUE; + pingPongActivityType->fixedTime = 10; + pingPongActivityType->behaviorFn = &pingPongElem_PingActivity_behavior; + return pingPongActivityType; + } +\end{verbatim} \end{small} + + +========= + +All behavior functions take a ptr to the activity instance they are executing the behavior of. The instance contains a pointer to the elem, and most behaviors will use the element's elemState field. It holds all the persistent state of the element, which remains between activities. + +Here is the behavior function from the ping-pong example: +\begin{small}\begin{verbatim} +void +pingPongElem_PingActivity_behavior( HWSimActivityInst *activityInst ) + { //NO_MSG is #define'd to NULL, and PORT0 to 0 + HWSim__send_comm_on_port_and_idle( NO_MSG, PORT0, activityInst ); + } +\end{verbatim}\end{small} + +There are four ways a behavior can end: +\begin{description} +\item end, no continuation: +\begin{small}\begin{verbatim} HWSim__end_activity_then_idle( HWSimActivityInst *endingActivityInstance )\end{verbatim}\end{small} +\item end, with continuation: +\begin{small}\begin{verbatim} HWSim__end_activity_then_cont( HWSimActivityInst *endingActivityInstance, + HWSimActivityType *continuationActivityType)\end{verbatim}\end{small} +\item end by sending a communication, with no continuation: +\begin{small}\begin{verbatim} HWSim__send_comm_on_port_then_idle( void *msg, int32 outPort, + HWSimActivityInst *endingActivityInstance)\end{verbatim}\end{small} +\item end by sending a communication, with continuation: +\begin{small}\begin{verbatim} HWSim__send_comm_on_port_then_cont( void *msg, int32 outPort, + HWSimActivityInst *endingActivityInstance + HWSimActivityType *continuationActivityType)\end{verbatim}\end{small} + + +============= + + +\subsection{Activity Timing Functions} +All activity timing functions take a ptr to the activity instance they are calculating the timing of. The instance contains a pointer to the element the activity is in. The behavior function is free to communicate to the timing function by leaving special data inside the element state. The timing function might also simply depend on the current state of the element. + +Here's an example: +\begin{small}\begin{verbatim} +HWSimTimeSpan +sampleElem_sampleActivity_timing( HWSimActivityInst *activityInst ) + { + return doSomethingWithStateOfElem( sendingActivity->elem->elemState ); + } +\end{verbatim}\end{small} + +\subsection{Calculating the time-in-flight of a communication path} + +The timing function for a communication path is similar to that of an activity. Except, the timing might also depend on configuration data or state stored inside the comm path struct, so that is passed to the timing function as well. + +\begin{small}\begin{verbatim} +HWSimTimeSpan +commPath_TimeSpanCalc( HWSimCommPath *commPath, HWSimActivityInst *sendingActivity ) + { return doSomethingWithStateOfPathAndElem( commPath, sendingActivity->elem->elemState ); + } +\end{verbatim}\end{small} + + + + diff -r 9b9a2497757d -r eb146c5c05a8 0__Papers/PRT/PRT__formal_def/latex/PRT__full_w_Henning_derived_formal_def.tex --- /dev/null Thu Jan 01 00:00:00 1970 +0000 +++ b/0__Papers/PRT/PRT__formal_def/latex/PRT__full_w_Henning_derived_formal_def.tex Sat Aug 03 19:24:22 2013 -0700 @@ -0,0 +1,2440 @@ +%----------------------------------------------------------------------------- +% +% Template for sigplanconf LaTeX Class +% +% Name: sigplanconf-template.tex +% +% Purpose: A template for sigplanconf.cls, which is a LaTeX 2e class +% file for SIGPLAN conference proceedings. +% +% Guide: Refer to "Author's Guide to the ACM SIGPLAN Class," +% sigplanconf-guide.pdf +% +% Author: Paul C. Anagnostopoulos +% Windfall Software +% 978 371-2316 +% paul@windfall.com +% +% Created: 15 February 2005 +% +%----------------------------------------------------------------------------- + + +\documentclass[preprint]{sigplanconf} + +% The following \documentclass options may be useful: +% +% 10pt To set in 10-point type instead of 9-point. +% 11pt To set in 11-point type instead of 9-point. +% authoryear To obtain author/year citation style instead of numeric. +\usepackage{amssymb,graphicx,calc,ifthen,subfig,dblfloatfix,fixltx2e} + + +% correct bad hyphenation here +\hyphenation{op-tical net-works semi-conduc-tor} + +\usepackage{wasysym} +\usepackage{amstext} + +\begin{document} + +\bibliographystyle{plain} +% + +\conferenceinfo{WXYZ '05}{date, City.} +\copyrightyear{2005} +\copyrightdata{[to be supplied]} + +\titlebanner{banner above paper title} % These are ignored unless +\preprintfooter{short description of paper} % 'preprint' option specified. + + +\title{A Proto-Runtime Approach to Domain Specific Languages} + + +\authorinfo{Sean Halle} + {Open Source Research Institute, INRIA, + and TU Berlin} + {seanhalle@opensourceresearchinstitute.org} +\authorinfo{Merten Sach} + {TU Berlin} + {msach@mailbox.tu-berlin.de} +\authorinfo{Albert Cohen} + {Ecole Normal Supereur, and INRIA} + {albert.cohen@inria.fr} + +\maketitle + + +\begin{abstract} + +? +replace lang-specific with interface, centralize services, minimize effort to create, give language control over hardware assignment.. side benefits: multi-lang, perf-tuning, debugging + +? + +Domain Specific Languages that are embedded into a base language have promise to provide productivity, performant-portability and wide adoption for parallel programming. However such languages have too few users to support the large effort required to create them and port them across hardware platforms, resulting in low adoption of the method. +To solve this, we introduce a proto-runtime approach, which reduces the effort to create and port domain specific languages. It modularizes the creation of runtime systems and the parallelism constructs they implement, by separating the language-construct and scheduling logic away from the low-level runtime details, including concurrency, memory consistency, and runtime-performance aspects. +As a result, new parallel constructs are written using sequential reasoning, and multiple languages can be mixed within +the same program. In addition, scheduling of work onto hardware is under language and application control, without interference from an underlying thread package scheduler. This enables higher quality scheduling decisions for higher application performance. +We present measurements of the time taken to develop runtimes for new languages, as well as time to re-implement existing ones, which average a few days each. In addition, we measure performance of proto-runtime based implementations going head-to-head with the standard distributions of Cilk, StarSs (OMPSs), and posix threads, showing that the proto-runtime matches or outperforms on large servers in all cases. +\end{abstract} + + + + + +%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% +\section{Background and Motivation} +\label{sec:intro} + +[Note to reviewers: this paper's style and structure follow the official PPoPP guide to writing style, which is linked to the PPoPP website. We are taking on faith that the approach has been communicated effectively to reviewers and that we won't be penalized for following it's recommended structure and approach.] + +Programming in the past has been overwhelmingly sequential, with the applications being run on sequential hardware. But the laws of physics have forced the hardware to become parallel, which will force nearly all future programming to become parallel programming. However, the transition from sequential to parallel programming has been slow due to the difficulty of the traditional parallel programming methods. + +The difficulties with parallel programming fall into three main categories: 1) difficult mental model, 2) extra effort to rewrite the code for each hardware target to get acceptable performance and 3) disruption to existing practices, including steep learning curve, changes to the tools used, and changes in design practices. + +Many believe that these can be overcome with the use of embedded style Domain-Specific Languages (eDSLs) []. eDSL language +constructs match the mental model of the domain, while +they internally imply parallelism. For example, a simulation +eDSL called HWSim[] has only 10 constructs, which match +the actions taken during a simulation +of interacting objects. They are mixed into sequential C code and take +only a couple of hours to learn. Yet they encapsulate subtle +and complex dependencies that relate simulated time +to the physical time in the machine. They encapsulate the parallelism +present, while simultaneously making the implementation +simpler to think about than a purely sequential implementation. + + + + Despite this, such languages have been slow to adopt, we believe due to the cost to create them and to port them across hardware targets. The small number of users of each language, which is specific to a narrow domain, makes this cost impractical. + +We propose that a method that makes Domain Specific Languages (DSLs) low cost to produce as well as to port across hardware targets will allow them to fulfill their promise, and we introduce what we call a proto-runtime to help towards this goal. + +The proto-runtime approach is a normal, full, runtime, but with two key pieces replaced by an interface. One piece replaced is the logic of language constructs, and the other is logic for choosing which core to assign work onto. The remaining proto-runtime piece handles the low-level hardware details of the runtime. + +The decomposition into a proto-runtime, plus plugged-in language behaviors, modularizes the construction of runtimes. The proto-runtime is one module, which embodies runtime internals, which are hardware oriented and independent of language. The plugged-in portions form the two other modules, which are language specific. The interface between them occurs at a natural boundary, which separates the hardware oriented portion of a runtime from the language oriented portion. + +We claim the following benefits of the proto-runtime approach, each of which is supported in the indicated section of the paper: + +\begin{itemize} + +\item The proto-runtime approach should reliably apply to future languages and hardware. because the patterns underlying it appear to be fundamental and so should hold for future languages and architectures (\S\ref{subsec:TiePoints}, +\S\ref{subsec:Example}). + +\item The proto-runtime approach modularizes the runtime (\S\ref{sec:Proposal}). + +%\item The modularization is consistent with patterns that appear to be fundamental to parallel computation and runtimes (\S\ ). + +\item The modularization cleanly separates runtime internals from the language-specific logic (\S\ref{sec:Proposal}, +\S\ref{subsec:Example}). + +\item The modularization gives the language control +over timing and placement of executing work (\S\ref{sec:Proposal}). + +\item The modularization results in reduced time to implement a new language's behavior, and in reduced time to port a language to new hardware (\S\ref{sec:Proposal}, +\S\ref{subsec:ImplTimeMeas}). + +\begin{itemize} + + +\item Part of the time reduction is due to the proto-runtime providing a centralized location for services for all languages to use, so the language doesn't have to provide them separately. Such services include debugging facilities, automated verification, concurrency handling, hardware performance information gathering, and so on (\S\ ). + +\item Part of the time reduction is due to encapsulation of hardware aspects inside the hardware-oriented module (\S \ref{sec:intro}). + +\item Part of the time reduction is due to reuse of the performance-tuning effort for runtime internals (\S ). + +\item Part of the time reduction is due to using sequential thinking when implementing the language logic, enabled by the proto-runtime protecting shared internal runtime state and exporting an interface that presents a sequential model (\S\ref{subsec:Example}). + + +\end{itemize} + +\item + +The modularization also selectively exposes hardware aspects relevant to placement of work, giving the language control over placement of work onto the hardware. If the language takes advantage of this, it can result in reduced communication between cores and increased application performance (\S\ ). + +\begin{itemize} + +\item Similar control over hardware is not possible when the language is built on top of a package like Posix threads or TBB, which has its own work-to-hardware assignment (\S\ref{sec:Related}). + +\end{itemize} + +\item Modularization with similar benefits does not appear possible when using a package such as Posix threads or TBB, unless the package itself is modified and then used according to the proto-runtime pattern (\S\ref{sec:Related}). + +\end{itemize} + +The paper is organized as follows: We first expand on the value of embedded style DSLs (eDSL), and where the effort goes when creating one (\S\ref{subsec:eDSLEffort}). We focus on the role that runtime implementation effort plays in the adoption of eDSLs, which motivates the value of the savings provided by the proto-runtime approach. We then move on to the details of the proto-runtime approach (\S\ref{sec:Proposal}), and tie them to how a runtime is modularized (\S\ref{subsec:Modules}), covering how each claimed benefit is provided. +We then show overhead measurements (\S\ref{subsec:OverheadMeas}) and implementation time measurements (\S\ref{subsec:ImplTimeMeas} ), which indicate that the proto-runtime approach is performance competitive while significantly reducing implementation and porting effort. +With that understanding in hand, we then discuss how the approach compares to related work (\S\ref{sec:Related}), and finally, we highlight the main conclusions drawn from the research (\S\ref{sec:Conclusion}). + + + + +%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% +% +%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% +\section{Background: The eDSL Hypothesis} + +%[[Hypothesis: Embedded-style DSLs -\textgreater\ high productivity + low learning curve + low app-port + low disruption]] + +%[[Bridge: Few users-\textgreater\ must be quick time to create + low effort to lang-port + high perf across targets]] + +%[[Bridge: effort to create = runtime + effort port = runtime + perf on new target = runtime]] + +%[[Bridge: big picture = langs * runtimes -\textgreater runtime effort critical]] + +Domain Specific Languages have been around for a while [], and recently have been suggested as a good approach for parallel programming[][stanford PPL]. + +In essence, a DSL, or just Domain Language, captures patterns that are common in a particular domain of expertise, such as user interfaces, simulations of physical phenomena, bio-informatics, cosmology, and so on. Each domain has a particular set of mental models, common types of computation, and common kinds of data structures. A DSL captures these common elements in custom syntax. + + +The custom syntax can capture parallelism information while simultaneously being natural to think about. In practice, multiple aspects of domains provide opportunities for parallelism. For example, the custom data structures seen by the coder can be internally implemented with distributed algorithms; common operations in the domain can be internally implemented with parallel algorithms; and, the domain constructs often imply dependencies. All of these are gained without the programmer being aware of this implied parallelism. + + + +\subsection{Embedding a DSL into a base language} + +A style of domain language, which we feel has good adoption potential, is the so-called \textit{embedded} style of DSL (eDSL) [] [metaborg][stanford ppl]. In this variation, a program is written in a mix of a base sequential language plus domain language constructs. The syntax of the two is intermixed. A preprocessing step then translates the domain syntax into the base syntax, and includes calls to the domain language's runtime. + + +For example, use C (or Java) as the base language for an application, and mix-in custom syntax for constructs from a user-interface eDSL. To test the code, the developer modifies the build process to first perform the translation step, then pass the resulting source through the normal C (or Java) compiler. The resulting executable contains calls to a dynamic (or shared) runtime library that becomes linked, at run time, to an implementation that has been tuned to the hardware it is running on. + +As with HWSim, the number of such embedded +constructs tends to be low, easy to learn, and significantly +reduce the complexity of the code written. All while +implicitly specifying parallelism. + +Additionally, eDSLs have more than just a syntactic advantage over libraries. The language has a toolchain that provides build-time optimization and can take advantage of relationships among distinct constructs within the code. The relationship information allows derivation of communication patterns that inform the choice of placement of work, which is critical to performance on parallel hardware. +\subsection{Low learning curve, high productivity, and portability} +eDSLs are generally quick to learn because the domain experts are already familiar with the concepts expressed by the custom syntax, and the number of constructs +tends to be low for an embedded DSL. This is especially valuable for those who are \textit{not} expert programmers. Embedded style DSLs further reduce learning curve because they require no new development tools nor development procedures. Together, these address the goal of a low learning curve for switching to parallel software development. + +Productivity has been shown to be enhanced by a well designed DSL, with studies commonly measuring +10x reduction in development time []. Factors +include simplifying the application code, modularizing it, and encapsulating performance aspects inside the language. Simplifying reduces the amount of code and the amount of mental effort. Modularizing separates concerns within the code and isolates aspects, which improves productivity. Encapsulating performance inside the DSL constructs removes them from the application programmer's concerns, which also improves productivity. + +Perhaps the most important productivity enhancement comes from hiding parallelism aspects inside the DSL constructs. The language takes advantage of the domain patterns to present a familiar mental model, and then attaches synchronization, work-division, and communication implications to those constructs, without the programmer having to be aware of them. Combining the simplicity, modularization, performance encapsulation, and parallelism hiding, with congruence with the mental model of the domain, together work towards the goal of high productivity. + +Portability is aided by the encapsulation of performance aspects inside the DSL constructs. This means that the elements of the problem that require large amounts of computation are often pulled into the language, which isolates the application code from hardware performance concerns. Only the language implementation must adapt to new hardware in order to get high performance. Although such isolation cannot always be fully achieved, Domain Languages hold promise for making significant strides towards it. + +\subsection{Low disruption and easy adoption} + +Using an eDSL tends to have low disruption because the base language remains the same, along with most of the development tools and practices. + Constructs from the eDSL can be mixed into existing sequential code, incrementally replacing the high computation sections, while continuing with the same development practices. + + \subsection{ Few users means the effort of eDSLs must be low} \label{subsec:eDSLEffort} + +What appears to be holding eDSLs back from addressing the challenges of parallel programming would be mainly the time, expertise, and cost needed to develop an eDSL. Because the number of users is small, the economic model of the past doesn't apply. For sequential languages, the potential user-base is in the millions, but for a parallel Domain Language, the user base may be only a few hundred developers who will use the language. + +As such, the effort to create a usable eDSL needs to be reduced to the point that it is viable for that size of user base. + +The effort to be reduced falls into three categories: + +\begin{enumerate} +\item effort to explore language design and create the eDSL syntax +\item effort to create the runtime that produces the eDSL behavior +\item effort to performance tune the eDSL on particular hardware +\end{itemize} + + +\subsection{Critical areas of effort in the big picture} + +Across the industry as a whole, when eDSLs become successful, there will be hundreds of Domain Languages, and likewise hundreds of different hardware platforms that each language must run efficiently on. That multiplicative effect must be reduced in order to make the eDSL approach economically viable. + +The first category of eDSL effort is creating the front-end translation of custom syntax into the base language. This is a one-time effort that does not repeat when new hardware is added. + +The effort that has to be expended on each platform is the runtime implementation, which includes hardware-specific low-level tuning, and the tuning of the domain construct implementation. + +Luckily, hardware platforms cluster into groups with similar performance-related features. This opens the door to an approach that can present a common abstraction for all platforms in a cluster. Examples of clusters include: + +\begin{itemize} +\item shared coherent memory multi-core single-chip machine +\item shared coherent memory multi-core multi-chip machine +\item independent address space coprocessor (GPU) +\item a network of nodes of the above categories +\item a machine with a hierarchy of sub-networks +\end{itemize} + + +%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% +% +%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% +\section{Our Proposal} \label{sec:Proposal} + +We propose addressing the runtime effort by defining a modularization of runtimes, as seen in Fig X. The low-level hardware details are collected into one module, which presents a common interface. The language supplies +the top two modules, which plug in via the interface. The hardware specific module presents the same interface +for all platforms sharing similar performance related features. This module only has to be implement once for a given platform, then reused by the languages. + +\begin{figure}[ht] + \centering + \includegraphics[width = 1.5in, height = 1.1in]{../figures/proto-runtime__modules.pdf} + \caption{Shows how the proto-runtime approach modularizes the implementation of a runtime. The three pieces are the proto-runtime implementation, an implementation of the language construct behaviors, and an implementation of the portion of scheduling that chooses which work is assigned to which processor. } + \label{fig:PR_three_pieces} +\end{figure} + + +Thus, a given language doesn't have to re-implement its runtime for every platform. Instead, it has a much lower effort requirement, of implementing for each category. + +The language effort is further reduced because the language doesn't consider the low-level details of making the runtime itself run fast. It only has to consider the level of hardware feature that is exposed by the interface. This is a higher level of abstraction, which simplifies the task for the language implementer. + +One additional benefit is giving control to the language, to choose when and where it wishes work to execute. +This feature simplifies implementation of languages +that have features related to scheduling behavior. +It also enables the language implementor to use sophisticated +methods for choosing placement of virtual processors +(threads) and tasks, which can significantly impact +application performance. + +In this paper, we present work that applies to coherent +shared memory machines, both single chip and multiple chip. Extensions beyond this are currently in progress, to address multiple-address-space machines and hierarchical +heterogeneous collections of processors, which will appear in future papers. + +\subsection{Breakdown of the modules} \label{subsec:Modules} + +The language is broken into two parts, as seen in Fig +X. One is a thin wrapper library that +invokes the runtime and the other is a set of modules that are part of the runtime. + + + +\begin{figure}[ht] + \centering + \includegraphics[width = 2.8in, height = 1.1in]{../figures/proto-runtime__modules_lang_breakdown.pdf} + \caption{Shows how the code of the language implementation + is broken into two pieces. The first is a thin wrapper + that invokes the runtime, the other is a dynamic + library that plugs into the runtime.} + \label{fig:langBreakdown} +\end{figure} + +The runtime itself consists of three modules connected via +an interface, as was seen back in Fig X. One encapsulates the low-level hardware details, and presents an interface to the language modules. We call +this the \textit{proto-runtime}. +It's job is to enforce the interface that the language modules see. + + +The language has two modules, both of which are collected in what we call the \textit{language plugin}. One module encodes the behavior of language +constructs, the other module provides logic for choosing which work to execute on +which hardware resource. + +A non-changing application executable is able to invoke hardware specific plugin code, which changes between machines, because the plugin collects the two language modules into a dynamic library. The library is implemented, compiled, distributed and installed separately from applications. The application executable contains only symbols of plugin functions, and during the run those are dynamically linked to machine-specific implementations. + + +In order to provide such modularization, we rely upon a model for specifying synchronization constructs that we call the tie-point model. The low-level nature of a tie-point places them below the level of constructs such as a mutex. Instead, a mutex is specified in terms +of the primitives in the tie-point model. In turn, +the proto-runtime + implements the primitives of the tie-point model. + + This places all parallel constructs on the same level in the software stack, be they complex like the AND-OR parallelism of Prolog, or the wild-card matching +channels in coordination languages, or ultra-simple acquire and release mutex constructs. All are implemented in terms of the same tie-point primitives provided by the proto-runtime. + +We have reached a point in the paper, now, where the order of explanation can take one of two paths: either +start with the abstract model of tie-points and explain how this affects the modularization of the runtime, or start with implementation details and work upwards towards the abstract model of tie-points. We have chosen to start with the abstract tie-point model, but the reader is invited to skip to the section after it, which starts with code examples and ties code details to the abstract tie-point model. + + + +\section{The tie-point model.}\label{subsec:TiePoints} + + +\subsection{timelines} +A tie-point relates timelines, so we talk a bit, first, about timelines. A timeline is the primitive in parallelism. If you look at any parallel language, it involves a number of independent timelines. It then controls which timelines are actively progressing relative to the others. + +For example, take a thread library, which we consider +a parallel language. It provides a command to create a thread, where that thread represents an independent timeline. The library also provides the mutex acquire and release commands, which control which of those timelines advance relative to each other. When an acquire executes, it can cause the thread to block, which means the associated timeline suspends; it stops +making forward progress. The release in a different thread clears the block, which resumes the timeline. That linkage between suspend and resume of different timelines is the control the language exerts over which timelines are actively progressing. + +To build up to tie-points, we look at the nature of points on +a single timeline, by reviewing mutex behavior in detail. We see the timeline shown in Fig \ref{fig:singleTimeline}. Thread A, which is timeline A, tries to acquire the mutex, M, +by executing the acquire command. Timeline A stops, at point 1.S, then something external to it happens, and the timeline starts again at point 1.R. The gap between is not seen by the code executed within the thread. Rather, from the code-execution viewpoint, the acquire command is a single command, and hence the gap between 1.S and 1.R collapses to a single point on the timeline. + + +\begin{figure}[ht] + \centering + \includegraphics[width = 2.8in, height = 0.8in] + {../figures/PR__timeline_single.pdf} + \caption{The timeline suspends at 1.S and resumes + at 1.R. From the viewpoint of the timeline, the gap collapses into a single point.} + \label{fig:singleTimeline} +\end{figure} + + +Now, a tie-point is seen as the linkage between such collapsed points on +two timelines. In Fig \ref{fig:dualTimeline}, timeline A is still there, suspends still at 1.S and resumes at 1.R. However, now there is a second timeline, timeline B. It executes the release command at point 2.S, which suspends timeline B, performs the behavior of the release command +inside the gap, then resumes timeline B at 2.R. The behavior of the release +command causes the end of suspend in the first timeline. That causality ties the two collapsed points in the two timelines together. + + +\begin{figure}[ht] + \centering + \includegraphics[width = 2.8in, height = 1.35in] + {../figures/PR__timeline_dual.pdf} + \caption{Two timelines with a causal relationship. +Activity that takes place during the gap in timeline +B causes resume of timeline A. This ties point 2 on +timeline B to point 1 on timeline A.} + \label{fig:dualTimeline} +\end{figure} + + + +We call this connection between the collapsed suspensions a tie-point. What it provides is a guarantee about visibility of events between the tied timelines. The +guarantee makes both agree on the order of events,\textit{ +relative to the mutual tied point}. +The guarantees are what defines a tie-point. + +Fig \ref{fig:tie-pointGuarantees} shows the ordering guarantees in terms of visibility of operations between +the timelines. If these visibility constraints are +satisfied, then the timelines share a tie-point. Note that the ordering + guarantees are equivalent to the constraints on visibility of operations. Operations that execute in +the first timeline before the tie-point must be visible +in the second after the tie point, and vice versa. Likewise, operations that execute in one timeline after the tie-point must not be visible in the other timeline before the tie-point. + + + +\begin{figure}[ht] + \centering + \includegraphics[width = 2.8in, height = 1.25in] + {../figures/PR__timeline_tie_point_ordering.pdf} + \caption{The +guarantees that a tie-point enforces. Shows which + operations performed on one timeline are visible to the other +timeline. These visibilities must be true for a tie-point. +Note that all events are divided into two groups, those +before the tied points versus those after the tied +points. Both timelines see the same before group and +the same after group. } + \label{fig:tie-pointGuarantees} +\end{figure} + + +\subsection{Formal definition of tie-point} +In a moment we will show how any and all synchronization constructs +can be defined in terms of tie-points. Before getting +there, we provide a formal definition of tie-point, +which we will then use to show that a tie point +can satisfy the conditions of any synchronization +construct. + +Our formalism defines timelines, communication between +timelines, and suspend and resume of a timeline. It then shows a particular pattern, which is the characteristic pattern that defines a tie-point. We then show that when that characteristic pattern exists, then relations exist between timelines that have certain properties. +We conclude by showing a few classical definitions +of synchronization and show that those definitions +are upheld when a relation with the derived properties +exists among the timelines. Hence, those classical definitions can be satisfied via creation of a tie-point. + +\subsubsection{} + +\begin{description} +\item[timeline:] +\(T = E \times\mathbb{N}, (E, <)\). A timeline is an ordered +sequence of events. Given two events $e_\alpha, e_\beta \in E$ from a timeline, the events are ordered by the +subscripts, so: $e_\alpha < e_\beta$ iff $\alpha < \beta$, +and vice versa. + Any and all memory locations in a system are part + of, or local to, exactly one timeline. Only that +timeline can modify the locations (hence, side-effects require shared memory to have its own timeline that +is separate +from any timeline that code executes in). + +\item[event:] +\(E =\{c_{0,t},c_{1,t}, ..\} \cup \{s_{\alpha ,t}\} \cup \{r_{\beta , t}\} +\cup \{z_{\gamma ,t} \} \). There are four kinds of event +that can happen on a timeline, namely $c$, a step of computation, +which modifies the memory local to the timeline; $s$, a +send of a communication which pushes out contents from +the timeline's local memory; $r$, a receive of a communication +which modifies the timeline's local memory; and $z$, +a synchronization +construct which suspends then resumes the timeline in such a way +as to establish a relation between events on this timeline +versus events on a remote timeline. Suspend is denoted +$z\_s_{\gamma ,t}$ while resume is denoted $z\_r_{\gamma +,t}$ where $s$ +and $r$ are literal while $\gamma$ denotes the position +on the timeline and $t$ is the timeline the suspend +happens on. +\item[communication:] +\(C = \{s,r\}, s < r\). A communication is a set of +one send event from one timeline plus one or more receive events +from different timelines, with the send +event ordered before the receive event(s), denoted $s_{n,t}\mapsto +r_{n,t}$ where $n$ distinguishes the communication +set and $t$ denotes the timeline the event is on. A communication +orders events on one timeline relative to events on another. +However, the ordering is only between two points, in +particular for two sends from timeline 1 to timeline +2, if \(s_{1,1} < s_{2.1}\) on timeline 1, then on +timeline 2, both \(r_{1,2} < r_{2,2}\) and \(r_{2,2} < r_{1,2}\) are valid. However, $s_{1,1} \mapsto r_{1,2}$ +followed by $s_{2,2} \mapsto r_{2,1}$ where $r_{1,2} +< s_{2,2}$ + implies that $s_{1,1} < r_{2,1}$ always. + +\item[hidden timeline:] We define a special kind of "hidden" timeline that is not +seen by application code. It has an additional +kind of event available, which ends a synchronization +event on a different timeline. + We denote this $fro_{\delta,h}$ where $fro$ is literal, + standing for ``force resume other (timeline)", $\delta$ is the position + on the timeline and $h$ is the (hidden) timeline the +event is on. Additionally, a suspend event on an application +visible timeline implies a send from that timeline +to a hidden timeline. Hence $z\_s_{\gamma,t} \Rightarrow +s_{\gamma,h}$ + +\item[tie-point:] Now, we define a tie-point as a set of two or more +synchronization points from different timelines which +are related by a particular pattern of communications. +As a result of the pattern, the set satisfies particular criteria. The pattern is that communications from the suspend synchronization events must converge on a common hidden timeline and that timeline must then emit a subsequent resume event for each of the suspended timelines. + +\end{description} + +We now show that from these definitions it follows: +[math here] which says that any event that comes after a tie point on one timeline is ordered after any event on a different timeline that precedes the tie-point on that timeline (note that the same tie point is common to both timelines). The dual also holds true. + +We take the event immediately preceding and the event +immediately following two synchronization events on +two timelines. The synchronization events begin with +a suspend half-event and ends with a resume half-event. +The suspend half-event is accompanied by a send to +a hidden timeline. That hidden timeline has a receive, +and later in its sequence it has a receive for the +synchronization event from the second timeline. The +hidden timeline then performs resume of both timelines. + +From that, we get the following relations: + +Which shows that the event following on timeline 1 comes after the event preceding on timeline 2 and vice versa. + +This property of ordering events on two timelines in this way is the key requirement for several classical definitions of synchronization. Hence, any implementation that exhibits this pattern of synchronization communications converging on a common hidden timeline, which subsequently resumes the synchronizations, in turn satisfies the conditions for a synchronization. + +\subsubsection{What is different about tie-point?} +Many readers will be wondering "so, how is implementing +a synchronization construct this way any different +from how they're currently implemented?" The answer +is that currently, synchronization constructs are +implemented on top of other synchronization constructs, +where we consider an atomic Compare and Swap instruction +to be a synchronization construct. It is only in the +hardware that a synchronization construct is assembled +from pieces. We further claim that the hardware implements +according to the pattern described in our formal definition. + +What we consider to be a tie-point is any point that +has this pattern, independent of the semantics added. +For example, for the Compare And Swap (CAS) instruction, +the comparison and swap are the semantics of what the +instruction does, while the atomicity, or exclusive +access is the part that provides the ordering relations. +So, the presence of the ordering relations is the tie-point +portion, while the comparison and swap are the plugged-in +semantics portion associated with the tie point. + +In that way, tie-point can be considered to simply +say ``has the ordering relation of a synchronization +construct". Tie-point is nothing new, when viewed that way. However, a tie-point is not a given, but rather +has to be constructed. To get a tie-point, one must +create a construction from which the givens for a synchronization +can be derived. Further, tie points can be constructed +for things that most would not readily consider a synchronization +construct. For example, any asynchronous communication +establishes a half tie-point, because ordering can +be derived. This is useful, for example, in defining +memory consistency models. + +The key here is the elements of the model within which +tie-point is defined. In particular, memory does not +exist outside a timeline, the points on a timeline +have no ordering relative to points on another timeline, +ordering between timelines is only established by a communication, and timelines can suspend themselves +(or be suspended by a different timeline), +and be resumed by a different timeline. + +Within this model, the characteristics of a synchronization +can be derived. That is the key difference, as usually +one states as a \textit{given} that a construct exists that has the synchronization properties. Tie-point +is derived, versus synchronization is given. + +True, the two are equally powerful. + +More low level, less junk on top, more efficiency and +more control -- w/sync like threads, it has its own +scheduler, have no control over where and when work +happens. + +It is different because it only directly provides half +the behavior, the time half. in the sense that + +The claim is that from a theory standpoint, tie-point +is not more powerful -- proto-runtime can implement +synchronization constructs, and sync constructs can +implement other sync constructs.. + +But, sync constructs CANNOT implement all of proto-runtime! They can't do the communications nor the hidden timeline nor create VPs +nor scheduling.. also, proto-runtime can do distributed +memory things that sync constructs cannot. + +The sync constructs can be used together with shared +memory-based communication in order to make more complex +sync constructs.. but they can't be used in a distributed +memory system to make distributed memory things. + +Let's see.. the relation model said that something +with synchronization constraints can be created from +just communication plus hidden timeline.. as long +as get the convergence on that hidden timeline. + +What Henning was saying was that sync is defined as +the end-constraints. So, the end-constraints IS what +a synchronization construct is. It doesn't matter +how to implement one, it only matters the end constraints. + +So, what the relation thing showed was how to construct +a synchronization. What need to show is that the relation +thing can also construct stuff that cannot be constructed +with a synchronization construct. + +I guess the question would be: if one starts with a +synchronization construct existing within a distributed +system.. well, then one can construct other sync constructs +from that one.. + +For them, the question of "more primitive" is: can the more primitive +thing do stuff the "full" one cannot? + +For me, the question of "more primitive"\ is: can one +of them be constructed from the other, which ONLY\ +has simpler pieces? Constructing one from itself says nothing.. +but being able to construct one from something that +is NOT one, whose individual components all have less +than one.. that thing's pieces are all less powerful.. +then it is a particular combination that brings the extra +time-related behavior of a sync construct into existence. +It is recognizing the particular pattern that brings +that extra into existence that is of value. + +It is that pattern that tells you how to get one from +simpler pieces. + +So, the story is: using only pieces that lack the "special" +synchronization construct property, construct something +that does have the synchronization property. That, +is building something more powerful from pieces that +are less powerful. + +The other part of the story is: the proto-runtime cannot +be used by itself. It requires addition before it +can be used. That is, have to add the M->M, to arrive +at the TxM->M, then can use the TxM->M.. but can't +use just the Tx by itself -- that's non-sensical. +So, provides a (M->M, f) that is used to get the TxM->M, +but can't use the f inside an application.. it doesn't +do anything other than add the Tx.. so it doesn't +accomplish any steps of computation, nor does it provide +Tx to any application code.. the (M->M, f) is outside +of any language -- that's what CREATES a language. + +*****Can't define (M->M, f) as part of its own language, +because it doesn't do anything. No computation is +performed by it. **** (so, what's the definition of +computation, then?) + +The other part of the story is the HWSim time behavior +-- those aren't sync constructs.. rather that is a +particular set of constraints on time.. constructed +out of primitives none of which have sych nor time +behavior by themselves beyond "comes after" of comm. + +Another part of the story is the singleton thing, constructed +directly.. Q: can that be built from sync constructs +in distributed system? Does using sync constructs +do something that using primitives doesn't? Does it +add something, fundamentally? Well, it is in terms +of something that already has the property being constructed.. +that's the issue.. in one case, taking something that +has the property and building something else that has +it.. in other case taking something that doesn't and +building something that does. + +So.. in the consistency model, just using the comes-after +property of communication to derive compound communication, +of particular write to particular read, via memory +locations. + +So, what is a tie-point in that consistency model? It is the pattern that allows deriving an ordering, between different computation timelines. There, the +tie-point was tying a write on one to a read on the +other, and thereby establishing a half-ordering between +the two timelines. + +Right.. so that should be it.. that a chain of communications results in an ordering between the end-points. And that a synchronization is nothing more than two communication chains that are tied together.. where the tie equals the chains SHARING one link, on some intermediate timeline. + +Right.. thinking about mutex acquire and release.. +the release is asynch.. the sending timeline resumes before +the hidden timeline receives notice.. but that just +establishes a half tie-point, no? + +In the async case, operations after the construct can be seen BEFORE the construct in the other timeline. Right. So that's a half tie-point. A full tie-point is that nothing after in either can be seen before by the other. + +Right.. so one distinction is this: a half tie-point +cannot be created using sync constructs "directly". + A sync construct is a full tie-point. + + +======================================================== + + +\subsubsection{Lifeline, Timeline, and Projection} +We define a formal entity that we call a lifeline, +where a timeline is a type of lifeline. +We define event-types and specific occurrences of event-types, and show how multiple lifelines can observe the same occurrence. A projection between +lifelines is defined as an event initiated upon one lifeline being observed on a different lifeline. The projection is from initiator to observer. + +\begin{description} +\item[event:] +\(E \) represents an event, which is something that +can be initiated or observed. +\item[occurrence:] +\(O\in E \times\mathbb{N}\) is the set of occurrences, where each occurrence associates a specific event with a unique identifier. A particular occurrence is denoted by subscripting with the value of the associated +integer, for example: \(O_{7}\) + +\item[clock:] +\(t:I\rightarrow\mathbb{R}^{+}\) maps each integer +onto a real number, such that \(I_{1} \) + is a lifeline, where \(\alpha\) +is a sequence over \(Dom(t)\) and each element of \(\alpha\) is either an initiation of an occurrence, or an observation +of one. A \textit{beat} of the lifeline is one tuple, denoted \(l(i)\), while the occurrence associated +to the beat is denoted\(\) \(O(l(i)) \) or equivalently \(O(\alpha(i)). \) The real value +associated with the beat is denoted \(t(l(i))\). For a given lifeline, not every element of \(t\) must have an associated +\(\alpha\), but every \(\alpha\) must have a unique associated +\(I\) from the clock \(t\). Note that \(\forall i , t(l(i)) < t(l(i+1))\). At most one beat from one +lifeline can initiate an occurrence. However, multiple +beats +from a given lifeline can observe the same occurrence, +including one initiated earlier in the sequence of +the lifeline, +and multiple lifelines may observe the same occurrence, +each multiple times. + +\item[projection:] +Given \(l_{1} = <\alpha , t_{1}> \), \(l_{2} = <\beta , t_{2}> \) then a projection from \(l_{1}\) to \(l_{2}\) + is denoted \(l_{1}(i) \uparrow l_{2}(j) \), where \(l_{1}(i) \uparrow l_{2}(j) +\equiv O(l_{1}(i)) = O(l_{2}(j))\). + This says that the occurrence initiated by the ith beat of the first lifeline is observed by the jth beat +of the second lifeline. + +\item[ordering tuple:] \(OT_{}\) is a tuple consisting +of a set of two beats from two different lifelines, which do +not participate in projections, plus a set of projections +that cross the two beats in the forward direction. +Given \(OT =<[l_{1}(x) , l_{2}(y)], [projections]> \) then \(OT\) is an +ordering tuple iff \( [projections] \neq0 \forall p(i,j) \in projections \nexists p(i,j) +|iy\ \) +\item[program run:] \(\mathcal{R} \) is a particular set of lifelines. +The program run begins with the creation of any lifeline, and +ends with the end of all lifelines. + +\item[equivalent positions in different sequences:] a partial ordering is defined. +Given two positions within different sequences, if +one or both both can be +validly rearranged, by using the partial ordering to +define valid rearrangements, so they occupy + the same position in their rearranged sequences, then +they are equivalent positions. + +\item[equivalent occurrences:] two occurrences are +equivalent if their event instances cannot be distinguished, given the observation +measurements of interest. If the observation measurement +involves sequences, then the two events must lie at +equivalent positions within their respective sequences. + +\item[equivalent lifelines:] two lifelines whose beats +can be paired, such that every beat in one lifeline +has an equivalent beat in the other. The beats do +not have to occur in the same order in both lifelines. +Beats associated to occurrences that are not of interest can be dropped. + +\item[equivalent program runs:] two runs such that +their lifelines can be paired one-to-one, with every lifeline in one paired to an equivalent +lifeline in the other. The projections between lifelines +in one run can be different from the projections in +the other run. + +\item[tie-point:] a set of beats, one from each of two lifelines, such that this set of beats forms a separation set in all equivalent program runs. +\end{description} + + +Some things to note: A particular occurrence +can be associated to at most one beat from a given +lifeline, but that same occurrence can also be associated +to beats from multiple other lifelines. Also, an occurrence may +be initiated by a lifeline but never observed by any. +Every \(O\) has a set of projections associated with it. + +For example, the event could +be writing a value into a variable. Two separate +write events are considered equivalent occurrences if +they both write the same particular value into whatever memory location +is associated to the same particular +variable, and happen within valid partial orderings +relative to the other occurrences. This is normally +compared across re-creations of the "universe" that +provides the context for the orderings of events instances. + +========= + + Okay, talked it over with Sung -- what about making distinguished beats +-- as Sung poked around for, make the PR\ "suspend" be the +distinguished beat. Then, as we worked out talking it +through, make the code that happens on the hidden timeline be the linkage between the beats -- so a tie-point is any number of distinguished beats such that the hidden calculation on one of the beats executed the resume for all of the other beats in the tie point. That establishes how a tie point gets created.. separately, need a universal statement of what is guaranteed by a tie point. + +So, one thing, is that the hidden calc is normally chosen such that every equivalent program run reproduces equivalent tie points -- but defining equivalent relies upon defining the "meaning"\ of the constructs.. but maybe that thing above about equivalent in terms of partial order can be used, by saying all constructs +are associated with a partial ordering -- but, still can have truly non-deterministic behavior being the correct behavior.. hmmm, but that should still have a partial ordering! + + What I\ really want to do is define tie-point in terms of the write-to-read. A half tie point says what's before the pre is visible after in the post timeline. And a full tie-point says that goes both ways. So, acquire-release is only a half tie-point, because what's after the release in its timeline can be seen before the acquire in its timeline. That makes it a half tie-point. Also, whats before the acquire in its timeline does not necessarily have to be seen after the release in its timeline.. that also makes it a half tie-point. + +So, use the project definition, and the crossing definition, to say which crossing projects are allowed by a half tie point, and which of those must be eliminated to make it a full tie-point. Then THAT\ defines the behaviors of a tie-point, independently from how it is created. + +The full definition of tie-point, in terms of proto-runtime value, has both those -- the hidden timeline "math" thing along with the causality, gives the "creation" aspect of tie-point, and the allowed projections gives the "behavior" aspect of tie-point. + +From the projection "behavior" I can simply state "this +defines what all synchronization constructs do" -- +the projection behavior is the whole purpose of a sync construct -- to ensure particular communication pattern when comm is via side-effect + +======= + +From first model, have the real-value constraints for slide of suspend and resume relative to each other.. + +The behavior of full tie-point is no back-cross projections, and there is a set of forward-crossing projections, which may be empty, and any of the tied timelines may +be the initiating timeline. For a half tie-point, have the origin lifeline. There is a set of forward-crossing projections with initiation on the origin lifeline, +and backward crossing are allowed whose initiation +is on non-origin lifeline. + +But a tie-point is more than just the behavior it defines. + In order for a pair of special beats to form a tie-point, +they must be causally linked on their internal lifelines. This means that a sequence of changes of the internal +state links the internal activity of one of the special beats to the internal activity of another special beat +that executes the resume that ends the second special beat. All special beats that are resumed inside the +same internal activity will have the behavior of a +full tie-point. Half tie-points can have both halves +resumed in different internal activities. + +A special beat has a variable-length span, as measured in the real-number of the clock. A special beat is associated to an isolated atomic span on a hidden lifeline. The only way to end the span of a special beat is via a "resume" beat on the hidden lifeline, which names the special beat to be ended. + +The internal activity on the hidden lifeline enforces some description. + +For +example, send-receive descriptions are: send = if paired +receiver is in shared context then resume both else place self into shared context. receive: if paired send is in shared context then resume both else place self into shared context. + +For acquire-release.. acquire: if lock-owner inside shared +context is empty then place self-name into lock-owner +and resume self else place self onto end of sequence +of special beats. release: remove self from lock-owner +and place the next in sequence of special beats into +lock-owner. If non-empty then resume the new lock-owner. +in every case, resume self. Note, acquire-release can +form either a half tie-point or a full tie-point. +? + +==== + +Note to the reader. This is a first pass at a formal description of tie-point. It likely contains more constraints than necessary. It should not be taken as the final formalism, nor is it implied to be elegant in any way, but simply an existence proof for a formal description +of a useful subset of what the intuition of tie-point associates to. + + + + + +\subsection{How a synchronization construct relates +to tie-points} + +To prepare for stating how the tie-point model can be used to +specify a synchronization construct, we first state +clearly what we mean by a ``synchronization construct''. + +The top of Fig \ref{fig:PRSyncConstrDef} shows two +independent timelines, both performing reads and writes +within a machine that has coherent shared memory. The +timelines have no relative ordering defined, so any +write on Timeline A can be received by any read of +the same address on +Timeline B, and vice versa. This means that, in general, +the use of a variable that is read and written by both will result in non-deterministic behavior. + + +\begin{figure}[ht] + \centering + \includegraphics[width = 2.0in, height = 2.8in] + {../figures/PR__timeline_sync_def.pdf} + \caption{Depicts the meaning we adopt for `synchronization construct'. One of them controls communications between timelines +by controlling the slide of timelines relative to each +other. They imply certain visibility between writes and reads on different timelines.} + \label{fig:PRSyncConstrDef} +\end{figure} + + + +To control the behavior of writes and reads to the +same addresses, a common point must be established, which +limits the ``sliding'' of the timelines relative to +each other. A synchronization construct is used for +this. +The net effect of such a construct is to establish +a common point that both timelines agree on. This +point separates reads and writes before it from reads +and writes after it. + +For example, consider a simple lock used to protect a critical section. The lock is acquired by one timeline +before entering the critical section. Any writes performed +on other timelines before the lock was granted must be complete before the critical section starts, so that reads performed inside the critical section see them. This is illustrated in the middle of Fig \ref{fig:PRSyncConstrDef}. + +The critical section ends by releasing the lock, which allows a different timeline to acquire and enter the critical section. As seen in the bottom of Fig \ref{fig:PRSyncConstrDef}, +any writes performed by that new +timeline after it acquires the lock must not be visible +to reads performed by the old timeline before it released +the lock. + +With this intuition, we define a synchronization construct +as an operation preformed on a timeline, which has +the property that it creates +a tie-point together with an operation performed on a different +timeline. Such operations that establish a tie-point +fit our definition of synchronization constructs. + + +\subsection{More on tie-points} + +Fig \ref{fig:dualTimeline} showed how a tie-point can be generated. The establishment was accomplished by +a combination of primitive mechanisms. These include: 1) suspend; 2) an `invisible' timeline that executes +behavior in the gaps; 3) resume +called from that invisible timeline; and 4) enforcement +of instruction completion relative to resume. + +What an established tie-point provides is the notion that the tied points are the same ``instant" for both tied timelines. What that means is that both timelines see events ordered relative to that point in the same way. + + +Notice that the primitives that establish a tie-point +do not involve any notion of dependency or constraint +on order of execution. It is the behavior code that runs on the invisible + timeline that embodies notions such as dependency + between units of work, mutual exclusion, + partial ordering of work, and so on. However, the + primitives do provide the notion of causality, the ordering implied by causality, and enforcing completion +of reads/writes. + +It is up to the language to supply the behavior that happens inside +the gaps, which executes on the invisible timeline. This behavior is what decides which timelines end up +sharing a tie point. It is that decision making, of which timelines to tie together, that implements the +semantics of a synchronization construct. + +A workshop paper also discusses tie points +[]. A formal treatment of tie-points is beyond the scope of this paper. However, a formal framework has been substantially completed and +will be published in a future paper. + + + +\subsection{Tie-points within a proto-runtime} + + Fig \ref{fig:dualTimeline} didn't say what entity owns the hidden timeline that executes the behavior that takes place in the gaps. This is what the proto-runtime does. An instance of the +proto-runtime executes the language plugin behavior. +It acts as the hidden timeline. + + The proto-runtime code module also supplies implementations +of the primitives that are used to establish a tie-point, including these: + + %It provides the primitive that suspends a timeline and then causes language plugin behavior to execute in the gap. + +%The plugin behavior that runs in the proto-runtime when one timeline suspends is what chooses another timeline to resume as a consequence. That choice establishes causality between the suspensions of the two timelines, and in the process ensures that a valid tie will exist between the two collapsed timeline points. The code of the primitives is provided as part of the proto-runtime code module, while the plugin behavior is executed by an instance of a running proto-runtime. + +%The running proto-runtime instance is also known as the Master, while the application timelines are known as Slaves. The behavior of the language constructs executes within the Master's timeline, while the behavior of application code executes within Slave timelines. + +%\subsection{More about the proto-runtime} + +\begin{itemize} +\item create a virtual processor (which has a suspendible timeline) +\item create a task (which has an atomic timeline that runs to completion) + +\item suspend a timeline, then invoke a function to handle the suspension -- handler is supplied with +parameters from application +\item resume a timeline, which makes it ready for execution +\item end a timeline +\item trigger choosing which virtual processor or task to begin execution on an offered +core + +\end{itemize} + +Virtual processors and tasks, both, have associated timelines. The reason for having both is a practical one, as tasks are simpler, with less overhead, +and many languages have the semantics of short, atomic, units of work that +are not intended to suspend. Thus, tasks are treated differently inside the +proto-runtime, and incur less overhead to create and run. + +A special feature of the proto-runtime is that if a task happens to execute +a language command that causes suspension, then the proto-runtime automatically +converts that task to a suspendible virtual processor. This helps support the mixing of different +languages within the same program. + + +The proto-runtime provides a mechanism for communicating information from the application code to the plugin function that was invoked to handle suspension. For example, the identity of a particular mutex a thread wishes to acquire +can be communicated from the wrapper library to the plugin. + + +Because the proto-runtime tracks all the timelines, the end of a timeline has to be explicitly stated in the application code, by calling a wrapper library function. That then invokes the proto-runtime primitive, +which informs the proto-runtime instance. The proto-runtime performs internal bookkeeping related to the ending of the timeline, and notes that the core is now free and offers it to the plugin's Assigner function. + +The proto-runtime involves the language into the process of choosing which core a given task +or virtual processor executes on. The proto-runtime maintains control, but offers free cores to the Assigner +portion of the plugin. It responds by then assigning a task or virtual processor to the core. The proto-runtime just offers, it is up to the language to decide what work that core should receive at that point in time. + + + +\subsection{Concrete Example}\label{subsec:Example} + +To make this concrete, consider the example of implementing +acquire mutex and release mutex. The semantics are: + +\begin{itemize} +\item Acquire Mutex: A thread calls the construct, +and +provides the name of the mutex. If no thread owns the +mutex, the calling thread is given ownership and it +continues to make progress. However, if a different thread +already owns the mutex, the calling thread is put into a queue +of waiting threads, and stops making progress. +\item Release Mutex: A thread calls the construct and +provides the name of the mutex. If the mutex has waiting threads in its queue, then the next thread is taken out and given ownership of the mutex. That thread is resumed, to once again make progress, as it the thread +that called the release construct.. +\end{itemize} + +This calls for a data structure that has two fields: +one holds the thread that currently owns the mutex, +the other holds a queue of threads waiting to acquire +the mutex. The semantics of a construct involve multiple +reads +and writes of the data structure. Hence, the + structure must be protected +from races between different threads. + +The protection +is where the difficulty comes into the implementation, +and where performance issues come into the picture. +It could be accomplished with a single global lock + that uses hardware primitives, or accomplished +with wait-free data structures that only rely upon the coherence +mechanism of the memory system, or even by message passing plus +quorum techniques. + +However, the implementation of the semantics is independent +of the implementation of the protection. They are orthogonal, +and an interface can be placed between them. One side +of the interface implements checking and updating the fields of +the data structure, while the other side implements +protecting the first side from interference. + +The side that provides protection requires fields, +for its use, to be placed into the data structure used +to represent a thread. To hide those details, +the protection side should also provide +primitives to create and destroy threads, as well as suspend +and resume them. + +This interface that separates the semantic side from +the protection +side is the proto-runtime interface. It is what enables +the modularization of runtime system implementations. + +The tie-point concept provides a model for thinking +about how the semantic side controls ordering among multiple threads, without exposing any details of the protection side. The tie-point model involves thinking only about actions taken during suspension of timelines (threads). It assumes that those actions are protected from interference, and that suspend and resume of timelines are primitive operations made available. The model remains constant regardless of implementation details. + That provides a cross-hardware way of specifying synchronization +behavior using just sequential thinking. The proto-runtime primitives implement the elements of the tie-point model. + + %Currently, these constructs are either implemented directly in terms of hardware level synchronization constructs such as the atomic Compare And Swap (CAS) instruction, or else are a thin wrapper that invokes operating system behavior. However, the behavior of the OS\ kernel's threading primitives are themselves implemented in terms of hardware level synchronization +%constructs. Either way, developing the behavior proves +%time consuming due to the difficulty of debugging hardware level synchronization behavior, and due to the difficulty of performance tuning such low level code across the full spectrum of patterns caused by applications. + + + + + +\section{Concrete Details} +Now that we have seen the concepts of how to modularize +a runtime system, using the tie-point model, it is +time to make the concepts concrete by showing code +segments that implement each of the concepts, and code +segments that use the concepts. We will start with +the big picture and work down. + +The first stop will be the development process, showing +how it is fractured into three separate and independent +development activities. Next, we will show examples +of how application +code invokes constructs, and follow the path of calls +down to the point it switches over to the runtime system. Lastly, +we will look at the flow of control inside the runtime, +where we will focus on the interaction between plugin +code and proto-runtime code. + +In this last portion, we will show how the +interface supplies the plugin with a consistent ``inside +the runtime" environment. Along with that, we will +show how providing +a consistent environment + is an implementation of the "single hidden timeline" portion + of the tie-point model. We will also show how it is + the existence of a \textit{single} hidden timeline + that allows the semantic portion of the language constructs +to be written in a sequential style, without regard to concurrency issues. + + +\subsection{Three independent development efforts} + +To get a handle on the big picture, we describe the +three independent paths that development takes: +one for development of proto-runtime code, one for +development of language implementation, and one for +application development. Each of these produces a separate +installable artifact. +The proto-runtime development produces a dynamic library, for each machine. The language development produces a dynamic library to plug into whichever proto-runtime library is installed on a given machine. It may also produce development tools that are used during compilation, distribution, and even installation and during the run. The application development produces a single source, which the language tools may then turn into multiple executables. + +The proto-runtime code is developed separately from +both language and application code, and packaged as a dynamic library. This library has multiple implementations. Each kind of hardware platform has a proto-runtime implemented specifically for it, and is tuned for low overhead on that hardware. The administrator of a particular machine chooses the proto-runtime implementation best suited to that hardware, and installs that. + +The language code is likewise developed separately from both proto-runtime and application code. Although multiple versions of a language may be implemented, there are significantly fewer versions than the number of proto-runtime versions. That is because most of the hardware details are abstracted away by the proto-runtime interface. + +However, the interface does expose hardware features related to placement of work onto cores, so some variations may exist for the same interface. Again, the administrator chooses which language implementation best suits their machine and installs the corresponding dynamic library. + +The wrapper library, however, is not +installed on the machine where code runs. Rather, it +is only used during development of an application, +and remains independent of hardware. + +Ideally the application is developed only once. It makes calls to the wrapper library, which in turn invokes the dynamic libraries of the language and proto-runtime. +When an application is executed, the loader binds the +dynamic libraries, connecting them to the application. + In this way, a single, +unchanging, executable gains access to machine-specific implementations of language and proto-runtime. + +However, the success of the compile-once approach has +limits in practice. Each machine's characteristics determine the size of unit of work that gives the best performance. When too small, the overhead in the runtime system that is required to create the work, manage constraints, and perform assignment becomes larger than the work +itself. When work-unit size is too large, then not enough units exist to keep all the cores busy. Thankfully, the range between is wide enough, for most applications, that neither limit is hit, on most machines. As machines evolve, though, this happy circumstance is likely to change, necessitating recompiling and possibly hand modifying the application code or some meta-form. + +\subsection{Walk through of activity during execution} + +At this point, we present a picture of the flow of control on each +of two cores, as the core is switched between application +code and runtime code. It is too early to understand +the details, but this figure can be referred back to +as each portion is discussed in the coming sub-sections. +Each portion of the figure is labelled with the sub-section that describes that portion of activity. + +At the top is the main program, which starts the proto-runtime, +and creates a proto-runtime process. Below that is +depicted the creation of proto-runtime virtual processors, +along with the animation of application code by those virtual +processors. + +? + +The application passes information to a wrapper library +call, +such as the ID of the mutex to acquire. The library function packages the +information into a request data structure, then invokes a proto-runtime +primitive. That suspends the virtual processor (timeline) that is executing +that code. The call to the primitive passes as arguments the request structure and a pointer +to the plugin function that will handle the request. +The handler runs inside the Master and chooses which +other timelines to resume as a consequence of the wrapper-library +call. Those timelines will then resume, returning from +whatever wrapper-library call caused them to suspend. In this way, the request handle implements the behavior of a +synchronization construct. + +However, there is one last step between the request +handler marking a timeline as ready to resume +and it becoming re-animated. That step is where the +assignment half of the language plugin comes into play. +The request handlers stack up work that is free to +be executed, but it is the assigner that chooses which +of those to place onto an offered core. + + + + + +\begin{figure*}[ht] + \centering + \includegraphics[width = 7.0in, height = 4.5in] + {../figures/Proto-Runtime__modules_plus_plugin_plus_code.pdf} + \caption{Illustration of the physical time sequence of the timelines of multiple virtual processors executing on multiple +cores. The timelines run top to bottom, while calls +between modules and returns run horizontally. The colors of Fn names indicate whether the +code is part of the application (green), the proto-runtime module (blue), or the language (red). The top two timelines are animated +by core 1, while the bottom 2 are animated by core +2. The boxes +represent virtual processors, each with its associated +timeline next to it. The timelines have no relative +ordering, except at tie-points established by the Request +Handlers. Gaps in the timelines are caused by suspension, +which is effected by primitives within the proto-runtime +code module.} + \label{fig:langBreakdown} +\end{figure*} + + + +\subsection{Using language constructs} +In the simple form of an eDSL, the language constructs +take the form of function calls. The reader familiar +with posix threads will have used function calls to +perform mutex acquire commands and mutex release commands. +Here, we illustrate invoking language commands in the +same way. + +We use posix threads for our example because it is +a familiar language that the reader already knows well. +It allows us to illustrate the concepts new to proto-runtime without introducing potential confusion about what the language semantics are. + +\subsubsection{Main and startup} +Before using a proto-runtime based language, the proto-runtime +system must be started, and a proto-runtime process +must be created. Fig X shows this. Notice that the +create process was given a pointer +to a function. This function is the seed of the proto-runtime +based application code. This seed must start all proto-runtime +based languages that will be used in the application, +and must create the virtual processors and tasks that +perform the work and may in turn create more VPs and/or tasks that perform work. + +==main, with PR\_\_start and PR\_\_create\_process == + +\subsubsection{Seed birth function and thread birth +function} +Fig X shows our example seed function. It first starts +the language that will be used, which is Vthread. It +is an implementation of posix threads that is on top of proto-runtime. +Next, the seed uses Vthread commands to create two +threads, and then uses Vthread join to wait for both +threads to die. Lastly it "dissipates", which is the +command that kills the virtual processor that is animating +the function. + +==seed\_birth\_Fn, with Vthread\_\_start(), Vthread\_\_create\_thread, +Vthread\_\_join, Vthread\_\_stop, and dissipate== + +Notice the signature +of the seed birth function. It returns void, and takes a pointer +to void plus a pointer to a SlaveVP struct. This is +the standard signature that must be used for all birth functions for +proto-runtime created virtual processors or tasks. + + +Also, notice that the standard signature includes a +pointer to a SlaveVP struct. This is a proto-runtime +defined structure, which holds the meta-information +about a virtual processor. The birth function is handed +the structure of the virtual processor that is animating +it. + +An illuminating aside is that the birth function for +a posix thread doesn't need +to be handed the structure representing the animating thread. +That is because the operating system tracks which thread +is assigned to which core. Posix thread constructs work by executing +an instruction that suspends the code executing on +the core and switches +the core over to animating the OS kernel code. The OS kernel +then looks up the data structure that is assigned to +the core. + +That lookup is how the OS kernel gains the +pointer to the thread that was animating the application +code that called the posix construct. But the implementation +of proto-runtime illustrated in this paper doesn't +have such a hardware based suspend instruction available, +and so proto-runtime-based application code must explicitly pass around the pointer to the data +structure of the virtual processor performing the animation. + +Fig X shows the birth function of the threads created +by the seed birth function. It uses the Vthread equivalent +of mutex acquire and release to protect access to +a critical section. Notice that the signature +is the same as the signature of the seed birth function. +Also notice that the SlaveVP structure is handed to +each invocation of a Vthread construct. In the next +several sub sections we will track how this SlaveVP structure +is used. + +==thread birth function.. uses Vthread acquire and +release to protect a counter plus print of count value== + + +\subsection{Language Wrapper Library} + +Looking at the implementation of the Vthread calls +reveals code such as in Fig X. + +==wrapper lib code for mutex acquire== + +There's nothing much to it. It just creates a data +structure, fills it, then hands it to a proto-runtime +call. This is a starnd form for wrapper library +calls. The data structure is used to carry information +into the proto-runtime (the proto-runtime that was +started by the PR\_\_start command). The PR call is +the equivalent of the hardware instruction that suspends +application code and switches to the kernel. For the +implementation of PR illustrated in this paper, this +call is implemented with assembly instructions. + +This wrapper library code is placed on the machine +used during development of the application, and is +compiled into the application executable. However, +the proto-runtime call is a link to a dynamic library, +and is not part of the application executable. + +Notice that the PR\ primitive is given a pointer to +a function. This is called the handler function, and +is part of the language plugin. The proto-runtime +will actually perform the call to the handler function, but in a carefully controlled +way. It will provide the handler function with a carefully controlled environment +to use while it handles this wrapper-library call. +We will see in a moment how proto-runtime invokes the +handler function, and what such a handler function +looks like. + +First, here's the assembly that suspends the application code and +switches to the proto-runtime code, as seen in Fig X + +==assembly of suspend and switch== + +All it does is save the program counter and stack pointer +into the SlaveVP structure, then load in the program +counter and stack pointer of the proto-runtime code, +which was previously saved in different fields of that same SlaveVP structure. + +\subsubsection{proto-runtime code that is switched +to} + +The PR assembly code switches the core to executing +the (psuedo) code seen in Fig X. + +==animation master code, which calls plugin fns== + +All this does is invoke the handler function named +in the wrapper library, and hands it an environmen. +This is the hidden environment referred to in the tie-point +model. It must be accessed in an isolated, atomic, +fashion. The proto-runtime code seen here happens +to use a global lock for each language's environment. + However other implementations are possible. In order + to keep overhead low, it uses the Compare And Swap + instruction to acquire the lock, and an exponential random + backoff scheme when contention for the lock arises. + + The handler function is the hidden behavior that executes + on the hidden timeline that is mentioned in the tie-point + model. The suspend primitive is what begins a special + beat on the lifeline of the virtual processor that + executed the wrapper library call. It is this handler + code that then establishes the causal connections + between such special beats, and so ties them together. + The causal connection is via the changes make to the + language environment. + + So, in summary, the proto-runtime is the hidden timeline. + The suspend primitive is what starts a special beat + and starts the behavior on the hidden timeline. The + lock is what isolates and sequentializes + the behavior on the hidden timeline. The language + environment is the hidden state used to establish + causal connection between special beats. + + + +This is not the plugin code, this is the library that the application executable includes. It's equivalent to the pthread library. When you look at the source of the pthread library, it's just a wrapper that invokes the OS. It doesn't do anything itself. The language libraries are the same thing, just wrappers that invoke the proto-runtime primitives. Those suspend the VP and send a message to the proto-runtime. When the message arrives, it invokes the plugin to handle the task. + +Here's how the wrapper library connects a request to the request handler: via this function pointer, right here Fig X, given to the proto-runtime "suspend and send" primitive. The pointed-to function is part of the plugin. That runs inside the proto-runtime, and is what handles the message created in the wrapper library. + + +If we go and look at that handler function, Fig X, we see that it has a standard prototype, so it takes a standard set of arguments. One of those, here in Fig X, is a language environment. This is the special sauce, it is the thing that is shared among all the cores. This language environment is where tasks are placed that are not yet ready to execute, and where suspended virtual processors are placed that are not yet ready to resume. + +Here, Fig X, you can see there's a hash table. The language environment contains that hash table. The tasks get parked in this hash table. Each time a task completes, it looks in the hash table, finds all tasks waiting for its completion, and updates the status of those waiting tasks. If this was the last task being waited for, the waiter is taken out of the hash table and put into the queue of ready to execute tasks. + +This is the semantics of the language. This is how the semantics of the language defines what dependencies are, and how it defines when a task's dependencies have been satisfied. The implementation is just a data structure in the shared language environment. It is the proto-runtime that takes care of creating the tasks, creating the virtual processors, execute those, suspend them and resume them. The proto-runtime handles the mechanics of all that stuff. The language just figures out what are the constraints on making it ready. + +? + +Separately, the proto-runtime calls the Assigner function, which is also part of the plugin dynamic library. Each time a task completes or a virtual processor suspends, the wrapper library invokes a proto-runtime primitive. Among other things, that primitive informs the proto-runtime about the completion of that work, which tells the proto-runtime that hardware resources have just been freed up. + +The proto-runtime then invokes the Assigner function, passing it information about the hardware that was just freed. The assigner is implemented by the language and uses some language-specific way to choose which of the ready work-units to execute on that hardware (a work-unit is either a ready-to-execute task or a ready-to-resume virtual processors). This is how the language is given control over placement of work onto cores. + +=================== + + +\subsection{not sure} +A task is an atomic unit of work. It runs to completion, without suspending. That characteristic allows the proto-runtime to internally treat a task differently than a virtual processor. The fact that it never suspends means it doesn't need a stack, and needs less bookkeeping, which makes a task faster to create and faster to assign, for lower overhead. + +However, a task may optionally choose at some point to execute a language command that causes it to suspend. At the point it does that, the proto-runtime internally converts the task to a virtual processor. That allows the task to suspend and later resume, at the cost of gaining the normal virtual processor overhead. However, the virtual processor the task is converted to comes from a recycle pool and returns when the task completes. + +As an application programmer, you can create processes directly with an OS-like language built on top of the proto-runtime. But you use a programming language to create tasks or virtual processors. For example, VSs has a way to create tasks. VSs internally then uses a proto-runtime command to have the proto-runtime create a task for it. Then VSs decorates the task with its own meta-data. It uses that meta-data to track when a task should be executed. + +? + +The only thing you're allowed to do outside a language is create the environment in which you start a language. + +? + +The implementation of the language behavior is the plugin. The plugin has two parts: request handlers, which handle the messages that come when a VP suspends, and an assigner, which picks where particular VP resumes onto or a task runs. With VSs, the plugin provides the behavior of "submit task". +The request handler plus plugin together provide the two halves of what people normally call a scheduler. + +================= + +\subsection{more on tie-points} +Any event visible before in one is visible in both after. The guarantee is between before in one and after in both. + +From the program point of view, that acquire statement is one instant. That entire gap in physical time is seen as a single instant to the code. + +However, the tie point is just one instant in the timelines. After the point, one of the timelines could perform an event that interferes with an event from before the tie-point, and no guarantees are given about what the other timeline sees. However, if another tie-point is created between them, then they are both guaranteed to see that second, interfering event, after the second tie-point. + +Take the example of a mutex, M. The purpose of the only-one semantics of a mutex is to isolate read and write operations done by the owning thread from those done by other threads, which own before or after it. + +The mutex behavior is illustrated in Fig X. Timeline 1 writes to variable A at point 1, then releases the M at point 2. Timeline 2 acquires M, at the tied point 2 and reads A at point 3. For M to provide isolation, it must guarantee that the A write operation at point 1 is seen by the other timeline's read operation, at point 3. Likewise, it has to guarantees that nothing that happens in timeline 2 after the acquire of M, at point 2, will be seen by timeline 1 before its release, also at point 2. + +That ordering guarantee is what we think of when we imagine the behavior of a mutex acquire-release pair. All writes done by the releasing thread are seen as completed, by reads performed in the acquiring thread, and no writes in the acquiring thread are seen before the release by the releasing thread. That is required in order to have value for the semantics of only one thread owns the mutex at any point. The purpose of only-one is to isolate read and write operations done by the owning thread from those done by the threads that own before or after it. + + +The behavior is implemented in terms of a data structure that lives inside the controlling entity's environment. The controlling entity looks up the data structure for the mutex being requested. This data structure has a field that contains the name of the thread that current owns the mutex, plus a queue of threads waiting to acquire it. So, the controlling entity first looks at the field that holds the current owner, sees that it is occupied, and then puts the thread's name into the queue of waiting threads. + +At some point later, the waiting thread reaches the top of the queue. At the point the owning thread executes the release operation, that owning thread also suspends, the controlling entity sees that suspend and that the thread wants to perform the release behavior. It looks up the release behavior and performs it. This behavior looks up the mutex data structure in the controlling entity's environment, removes the releasing thread from the owner field, takes the top thread off the waiters, writes its name into the current owner, then marks both those threads as ready to resume their timelines. + +The proto-runtime is the controlling entity, which looks up the behaviors and performs them. It also manages the environment that holds the data structures used by the behaviors. + +=========== + +The purpose of the M is to guarantee that what gets written to A here in this timeline is seen over here, in this other timeline. + +So, to turn this simple mechanism into a synchronization construct, you add semantics on top, which determine the end of suspend in the two timelines. The timelines voluntarily place themselves into suspend, and it is up to the controlling entity to decide at what point to end that suspension. It is this choice of ending suspension that ties events in one timeline to events in another. The semantics of deciding that end of suspension is the semantics of the synchronization construct. + +For example, take mutual exclusion within Threads. One thread executes a construct that asks to acquire the mutex. At the point of executing, that thread suspends, so that timeline ceases advancing. At some point later, the controlling entity sees that suspend, and sees that the timeline is attempting the acquire mutex activity. It looks up the behavior for acquire mutex, which is then performed inside that controlling entity. + +============ + + +\subsection{More on eDSLs} +%====================================== + +%We expand on the hypothesis that an embedded style Domain Specfic Language (eDSL) provides high programmer productivity, with a low learning curve. We also show (\S ) that when an application is written in a well designed eDSL, porting it to new hardware becomes simpler, because often only the language needs to be ported. That is because the elements of the problem being solved that require large amounts of computation are often pulled into the language. Lastly (\S ), we hypothesize that switching from sequential programming to using an eDSL is low disruption because the base language remains the same, along with most of the development tools and practices. + +%In \S \ref{sec:DSLHypothesis} we show that the small number of users of an eDSL means that the eDSL must be very low effort to create, and also low effort to port to new hardware. At the same time, the eDSL must remain very high performance across hardware targets. + +%In \S we analyze where the effort of creating an eDSL is expended. It turns out that in the traditional approach, it is mainly expended in creating the runtime, and in performance tuning the major domain-specific constructs. We use this to support the case that speeding up runtime creation makes eDSLs more viable. + +%In \S we take a step back and examine what the industry-wide picture would be if the eDSL approach were adopted. A large number of eDSLs will come into existence, each with its own set of runtimes, one runtime for each hardware target. That causes a multiplicative effect: the number of runtimes will equal the number of eDSLs times the number of hardware targets. Unless the effort of implementing runtimes reduces, this multiplicative effect could dominate, which would retard the uptake of eDSLs. + + +% ============== + +%Further, in \S we show that when an application is written in a well designed eDSL, porting it to new hardware becomes simpler because often only the language needs to be ported. That is because the elements of the problem being solved that require large amounts of computation are often pulled into the language. Lastly, in \S we hypothesize that switching from sequential programming to using an eDSL is low disruption because the base language remains the same, along with most of the development tools and practices. Hence, we cover how the three issues currently making parallel programming unattractive are addressed by embedded-style DSLs. + +%We next show what the blocks to eDSLs are, and where the main effort in implementing an eDSL lies. Specifically, in \S \ref{sec:DSLHypothesis} we show that the small number of users of an eDSL means that the eDSL must be very low effort to create, and also low effort to port to new hardware. At the same time, the eDSL must remain very high performance across hardware targets. + +%In \S we analyze where the effort of creating an eDSL is expended. It turns out that in the traditional approach, it is expended in creating the translator for the custom DSL syntax, in creating the runtime, and in performance tuning the major domain-specific constructs. We propose that the MetaBorg[] or Rose[] translation approaches cover creating translators for custom syntax, and that tuning constructs is inescapable, leaving the question of runtime implementation time. + +%In \S we explore the effects of runtime implementation time by taking a step back and examine what the industry-wide picture would be if the eDSL approach were adopted. A large number of eDSLs will come into existence, each with its own set of runtimes, one runtime for each hardware target. That causes a multiplicative effect: the number of runtimes will equal the number of eDSLs times the number of hardware targets. Unless the effort of implementing runtimes reduces, this multiplicative effect could dominate, which would retard the uptake of eDSLs. Thus, showing that an approach that mitigates this multiplicative effect is valuable, and is the role that the proto-runtime plays. + + + +%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% +\subsection{Details} +\label{subsec:Details} + + what responsibilities are encapsulated in which modules, and what the interfaces between them look like. + +modularization and its interface is what makes the proto-runtime reusable by all languages on given hardware, and the low-level tuning of the proto-runtime for specific hardware automatically benefits all the languages on that hardware. + +? + + + + overhead measurements + +implementation time measurements + + discuss why equivalent user-level M to N thread packages haven't been pursued, leaving no viable user-level libraries to compare against. + + give numbers that indicate that the proto-runtime approach is also competitive with Cilk, and OMPSs, on large multi-core servers. + + summary of development time of the various embedded languages created so far. Unfortunately, no control is available to compare against, but we provide estimates based on anecdotal evidence of the time taken to develop the versions compared against for overhead. In the +least, the same effort would have to be expended on +each and every language that we expended on performance +tuning our proto-runtime. + + We continue with a bigger picture discussion of the difference in design methods between traditional approaches and the proto-runtime implementations (\S ). We discuss OpenMP versus the equivalent proto-runtime version called VOMP (\S ). Then (\S ) we discuss Cilk 5.4 vs the proto-runtime VCilk. Next we discuss pthread vs Vthread (\S ), and OMPSs vs VSs (\S ). These discussions attempt to give the two design philosophies and paint a picture of the development process in the two competing approaches. The goal is to + +illustrate how the proto-runtime approach maintains many of the features, through its centralized services, while significantly reducing implementation time, through reuse of the services, elimination of concurrency concerns in design and debugging, and in the simplifications in design and implementation caused by the clean modularization of the proto-runtime approach, and the regularization of implementation from one language to another. + +Then, with the full understanding of the proto-runtime approach in hand, we discuss how it compares to related work (\S ). + +Finally, we highlight the main conclusions drawn from the work (\S ). + + + +? + + + + + The behavior module creates work and determines when work is free the execute, it tracks constraints on work imposed by language semantics, and constraints +due to data dependencies. + + a copy of the proto-runtime with language modules runs separately on each core and they communicate via shared variables in a shared language environment. The proto-runtime protects access to the shared language environment so that language modules can be written in sequential style. + +? + +The proto-runtime also implements "centralized" services that it makes available to all languages. Hardware specific functions include communicating between processors and protecting the internal state used by the language modules. + + + + this makes the proto-runtime be reused by all languages on given hardware, and the low-level tuning of the proto-runtime for specific hardware automatically benefits all the languages that run on that hardware. + + implementing language logic, + +show how the proto-runtime interface allows it to use sequential thinking. + +give similar detail on the implementation of the assigner, +we discuss how that has the potential to improve application performance by reducing communication between cores and reducing idle time of cores. + +support belief that the patterns we followed when modularizing are indeed fundamental and will remain valid for future languages and hardware. + + discuss some of the centralized services provided by the current proto-runtime implementation, as well as planned future ones. + +reusing language logic from one language implementation to another. + + +%%%%%%%%%%%%%%%%%%%%%%%% +%% +%%%%%%%%%%%%%%%%%%%%%%%% +\section{Measurements} +With the background on eDSLs and description of the proto-runtime approach behind us, we then provide overhead measurements in \S\ref{subsec:OverheadMeas} and implementation time measurements in \S\ref{subsec:ImplTimeMeas} + +\subsection{Overhead Measurements} \label{subsec:OverheadMeas} +For the following, we use a 4-core single socket 2.4Ghz laptop, and a 4 socket by 10 core each server. + +For runtime performance: + +-- Vthread vs pthread: laptop and server on exe vs task (and fibonacci?) + +-- VCilk vs Cilk: laptop and server on fibonacci (from Albert) + +-- VOMP vs OpenMP: laptop and server on exe vs task and fibonacci + +-- VSs vs OMPSs: laptop and server on fibonacci and jpeg + +\begin{tabular}{|c|c|c|c|c|c|c|}\hline +a & 2 & a & a & a & a & a \\\hline +a & 2 & a & a & a & a & a \\\hline +a & a & a & a & a & a & a \\\hline +a & a & a & a & a & a & a \\\hline +\end{tabular} +\caption{} +\label{tab} + +As seen, we didn't include application performance because we have not yet taken advantage of the opportunity to use language information to predict locality. That research is in progress and will be reported in future papers. + + +\subsubsection{Vthread Versus Highly Tuned Posix Threads} + +Measurements indicate that the proto-runtime approach has far lower overhead than even the current highly tuned Linux thread implementation, and discusses why equivalent user-level M to N thread packages haven't been pursued, leaving no viable user-level libraries to compare against. +\subsubsection{VCilk Versus Cilk 5.4} +In \S we give numbers that indicate that the proto-runtime approach is also competitive with Cilk +\subsubsection{VSs Versus StarSs (OMPSs)} +OMPSs +\subsubsection{VOMP Versus OpenMP} +VOMP + + +%%%%%%%%%%%%%%%%%%%%%%%% +%% +%%%%%%%%%%%%%%%%%%%%%%%% +\subsection{Development Time Measurements}\label{subsec:ImplTimeMeas} +Here we summarize the time to develop each of the eDSLs and copy-cat languages created so far. As a control, we estimate how long the equivalent functionality required, using the traditional approach, based on anecdotal evidence. + +Summarized in Table \ref{tabPersonHoursLang}, we measured the time we spent to design, code, and get an initial version working for each of the languages we created. The results are shown in the same order we created them, with SSR the first. As we gained experience, design and coding became more efficient. Not shown is the 7 hours required to take the send-receive code from SSR and adapt it to work with tasks in VSs. In addition, 11 hours was spent importing the DKU constructs into VSs. These are hours spent at the keyboard or with pen and paper, and don't include think time during other activities in the day. + + +\begin{centering} +\begin{tabular}{|l|r|r|r|r|r|r|} + \cline{2-7} + \multicolumn{1}{r|}{} & SSR & Vthread & VCilk & HWSim & VOMP & VSs\\ + \cline{2-7} + \noalign{\vskip2pt} + \hline + Design & 19 & 6 & 3 & 52 & 18& 6\\ + Code & 13 & 3 & 3& 32 & 9& 12\\ + Test & 7 & 2 & 2& 12 & 8& 5\\ + L.O.C. & 470 & 290 & 310& 3000 & 690 & 780\\ + \hline +\end{tabular} +\caption +{Hours to design, code, and test each embedded language. L.O.C. is lines of (original) C code, excluding libraries and comments. +} +\end{centering} +\label{tabPersonHoursLang} + +\subsubsection{Comparison of Design Approaches} +We give the bigger picture of the difference in design methods between traditional approaches and the proto-runtime implementations, discussing OpenMP versus VOMP, Cilk 5.4 vs VCilk, pthread vs Vthread, and OMPSs vs VSs. These discussions attempt to give the two design philosophies and paint a picture of the development process in the two competing approaches. The goal is to illustrate how the proto-runtime approach maintains many of the language features, through its centralized services, while significantly reducing implementation time, through reuse of the services, elimination of concurrency concerns in design and debugging, and in the simplifications in design and implementation caused by the clean modularization of the proto-runtime approach, and the regularization of implementation from one language to another. + + +%%%%%%%%%%%%%%%%%%%%%%%% +%% +%%%%%%%%%%%%%%%%%%%%%%%% +\section{Related Work} \label{sec:Related} + +With the full understanding of the proto-runtime approach in hand, we discuss how it compares to other approaches for implementing the runtimes of domain specific languages. The criteria are: level of effort to implement the runtime, effort to port the runtime, runtime performance, and support for application performance. The main alternative implementation approaches are: posix threads, user-level threads, TBB, modifying libGomp, and using hardware primitives to make a custom runtime. + +We first talk about each of these approaches, then summarize the conclusions in Table \ref{tab:CriteriaVsApproach}. + +The first three methods involve building the DSL runtime on top of OS threads, user threads, or TBB, all of which are languages in their own right. So the DSL runtime runs on top of the runtime for that lower-level language. This places control of work placement inside the lower-level runtime, blocking the DSL runtime, which hurts application-code performance, due to inability to use data locality. In addition, OS threads have operating system overhead and OS-imposed fairness requirements, which keeps runtime performance poor. + +All three also force the DSL implementation to manage concurrency explicitly, using language primitives such as locks. TBB may have a slight advantage due to its task-scheduling commands, but only for task-based languages. Hence, implementation effort is poor for these approaches. + +For the same reason, for these three, the runtime code needs to be rewritten and tuned for each hardware platform for each language, or else some form of hardware-abstraction placed into the runtime. But putting in a hardware abstraction is essentially an alternative way of implementing half of the proto-runtime approach, but without the centralization, reuse, and modularization benefits. + +Many language researchers use libGomp (based on informal discussions) because of its very simple structure, which makes it relatively easy to modify, especially for simple languages. However, it provides no services such as debugging or performance tuning, and it has no modularization or reuse across languages benefits. As the price of the simplicity, performance suffers, as seen in the experiments []. Also, re-writes of the DSL runtime are required for each platform in order to tune it to hardware characteristics. However, because the runtime is directly modified, the language gains control over placement of work, enabling good application performance. + +Lastly, we consider the alternative of writing a custom runtime from scratch, using hardware primitives such as the Compare And Swap (CAS) instruction, or similar atomic read-modify-write instructions. This approach requires the highest degree of implementation effort, and the worst portability across hardware. However, if sufficient effort is expended on tuning, it can achieve the best runtime performance and equal the best performance of application code. So far, the gap has proven small between highly tuned language-specific custom runtime performance and that of our proto-runtime, but we only have the CILK implementation as a comparison point. + +Putting this all together, Table \ref{tab:CriteriaVsApproach} shows that the proto-runtime approach is the only one that scores high in all the mesures. It makes initial language implementation fast, as well as reduces porting effort, while keeping runtime performance high and enabling high application performance. + +\begin{center} +\begin{tabular}{|c|c|c|c|c|}\hline +Runtime Creation & \textbf{impl.}& \textbf{porting} & \textbf{runtime} & \textbf{application} \\ +\textbf{} & \textbf{ease} & \textbf{ease} & \textbf{perf.} & \textbf{perf.}\\\hline +\textbf{OS Threads} & ++ & ++ & + & + \\\hline +\textbf{User Threads} & ++& ++ & ++ & + \\\hline +\textbf{TBB} & ++ & ++ & ++ & + \\\hline +\textbf{libGomp} & +++ & ++ & +++ & ++++ \\\hline +\textbf{HW primitives} & + & + & +++++ & +++++ \\\hline +\textbf{Proto-runtime} & +++++ & +++++ & ++++ & +++++\\\hline +\end{tabular} +\end{center} +\caption{The table shows how well each approach scores in each measure important to the implementor of a runtime for a DSL. On the left are the approaches that can be used to write the runtime. At the top are the measures an implementor may care about. For all measures, one plus is the lowest score, indicating the implementation approach is undesirable, 5 indicates the highest desirability. The scores are based on reasons discussed in the text. } +\label{tab:CriteriaVsApproach} + + + + +%%%%%%%%%%%%%%%%%%%%%%%% +%% +%%%%%%%%%%%%%%%%%%%%%%%% +\section{Conclusions and Future Work} +The main takeaways from the paper are first, the potential for embedded style Domain Specific Languages (eDSLs) to address the issues that are holding-back parallel programming, and second the role that the proto-runtime approach can play in making eDSLs practical, by simplifying the runtime aspect of implementing a large number of eDSLs across the many hardware targets. +%The proto-runtime approach does this by modularizing the runtimes, providing reuse of centralized services, and reuse of the hardware-specific performance tuning, which is performed once per hardware, on the proto-runtime, then enjoyed by all the eDSLs. Hence, the proto-runtime approach provides a significant piece of the puzzle of providing eDSLs, to bring parallel programming into the mainstream. + + +%[[Hypothesis: Embedded-style DSLs -> high productivity + low learning curve + low disruption + low app-port AND quick time to create + low effort to lang-port + high perf across targets]] + + +Specifically, we have shown how the approach modularizes runtime code, in a way that appears applicable to any language or execution model. It isolates the hardware-specific portion from language behavior as well as from the language-driven placement of work onto resources, providing interfaces between them. + + The modularization reduces the effort of implementing a new language, especially for an embedded-style one where runtime creation is a significant portion of total effort. It causes the low level hardware portion to be reused by each language. And, the behavior implementation is simplified, by handling shared state inside the proto-runtime and exporting a sequential interface for the behavior module to use. The simplification reduces effort, as does reuse of the hardware-specific portion, reuse of behavior code from one language to another, reuse of assignment code, and familiarity with the modular structure by implementors. Overall effort reduction was supported by measurements of implementation effort. + +The proto-runtime approach makes it practical to maintain high overall runtime performance, with low effort for the language implementor. It is practical because high effort is put into performance-tuning the hardware-specific proto-runtime, which is then reused by each language. In this way the performance derived from the high tuning effort is inherited without extra effort by the language creators, thus amortizing the cost. + +Centralized services were implemented inside the proto-runtime portion, such as debugging facilities, automated verification, concurrency handling, hardware performance information gathering, and so on. We showed how they are reused by the languages. + +Although we didn't measure it, we indicated how application performance can be increased due to giving the language direct control over placement of work, to take advantage of data affinity or application-generated communication patterns. This ability is due to the assignment module, which provides the language implementor with control over which core work is assigned to, and the order of executing each work unit. + +Work on the proto-runtime approach is in its infancy, and much remains to be done, including: +\begin{itemize} +\item Creating related interfaces for use with distributed memory hardware, and interfaces for hierarchical runtimes, to improve performance on many-level hardware such as high-performance computers, and to tie together runtimes for different types of architecture, to cover heterogeneous architectures and machines. +\item Extending the proto-runtime interface to present hardware information that a work-assigner will need, but in a generic way that remains constant across many hardware configurations yet exposes all relevant information. +\item Exploring work assignment implementations that take advantage of language and application knowledge to improve placement of work to gain higher application performance. +\item Applying the proto-runtime approach to support a portability software stack, and supply OS services to applications via the proto-runtime, to further increase application-code portability. +\end{itemize} + + +============================================= +== +== +== +== +== +============================================= + +\section{The Problem} + +[[Hypothesis: Embedded-style DSLs -\textgreater\ high productivity + low learning curve + low app-port + low disruption]] + +[[Bridge: Few users-\textgreater\ must be quick time to create + low effort to lang-port + high perf across targets]] + +[[Bridge: effort to create = runtime + effort port = runtime + perf on new target = runtime]] + +[[Bridge: big picture = langs * runtimes -\textgreater runtime effort critical]] + + +[[Claims: given big picture, runtime effort minimized -\textgreater modularize runtime, mod works across langs bec. fund patterns, mod sep lang logic from RT internals, mod makes internal reusable + lang inherit internal perf tune +inherit centralized serv, mod makes lang logic sequential, mod makes constructs reusable one lang to next, mod causes lang assigner to own HW]] + +While talking about the problems encountered by Domain Specific Languages (DSLs), we focus on implications for the runtime system, due to its central role in the claims. At the same time we will support the hypothesis that embedded-style DSLs are high-productivity for application programmers, have a low learning curve, and cause low disruption to current programming practices. While doing this we set the ground work for the next section, where we show that the main effort of implementing embedded-style DSLs is creating the runtime, and that when using the proto-runtime approach, embedded-style DSLs are low-effort to create and port and move the effort of porting for high performance out of the application and into the language. + +To give the needed depth, we'll first talk about a way to classify parallel languages according to the structure of their runtime (subsection \ref{subsec:ClassifyingLangs}). Then we'll talk about the sub-class of domain specific parallel languages, what sets them apart, and the implications for their runtime implementations (subsection \ref{subsec:DomSpecLangs}). That segues into the embedded style of language, and how the work of implementing them is mainly the work of implementing their runtime (subsection \ref{subsec:EmbeddedDSLs}). + +Once that reduction from parallel languages in general to embedded style domain specific ones in particular is done, we'll give more on what embedded style DSLs look like from an application programmer's view (subsection \ref{subsec:AppProgViewOfDSL}). We will include depth on a particular embedded-style language, showing sample code that uses the constructs, then delving into needs within the implementation of that language, and behavior of the constructs during a run (subsection []). + +The main implications for runtime systems, which were uncovered within the section, are summarized at the end (subsection []). + +\subsection{Classifying parallel languages by virtual processor based vs task based} +\label{subsec:ClassifyingLangs} +[[Hypothesis: Embedded-style DSLs -\textgreater\ high productivity + low learning curve + low app-port + low disruption]] + +[[Bridge: Few users-\textgreater\ must be quick time to create + low effort to lang-port + high perf across targets]] + +[[Bridge: effort to create = runtime + effort port = runtime + perf on new target = runtime]] + +[[Bridge: big picture = langs * runtimes -\textgreater runtime effort critical]] + + +[[Claims: given big picture, runtime effort minimized -\textgreater modularize runtime, mod works across langs bec. fund patterns, mod sep lang logic from RT internals, mod makes internal reusable + lang inherit internal perf tune +inherit centralized serv, mod makes lang logic sequential, mod makes constructs reusable one lang to next, mod causes lang assigner to own HW]] + +One major axis for classifying parallel languages is whether they are virtual processor based or task based, which has implications for the structure of the runtime. + +A virtual processor is long-lived, and has a context that persists across suspend and resume, while a task has no preceding context to fit into and leaves no implied context when done. Posix threads is a standard example of a virtual processor based parallel language, as are UPC, Charm, TBB, and so forth. All of these create virtual processors (aka threads), which suspend when they invoke synchronizations and other parallel-language constructs then resume after the construct completes. Such virtual processors have their own private stack to save the information that is needed upon resume. + +In contrast, dataflow is a standard example of a task based language, as is CnC. For these languages, a task is passed all the information it needs at the point of creation, and is expected to run to completion. If a task needs to invoke a parallelism construct, that invocation normally ends the task, while information needed by following tasks is saved explicitly in shared variables, or passed to the runtime as a continuation that is then handed to the task created when the construct completes. + +Hybrids of the two also exist, such as OpenMP which implies thread creation, via the parallel-pragma, but also creates tasks via the for-pragma. As well, StarSs (OMPSs) mixes the two, with a main thread that creates meta-tasks that have to resolve their dependencies before being turned into executable tasks. Those tasks are also able to invoke barriers and other synchronization constructs, then resume. + +The runtime implementations of the two different types of execution model differ markedly. Virtual processor (VP) based runtimes have to create a stack for each VP created, and manage the interleaving of the CPU's hardware stack. They also require a mechanism to suspend and resume the VPs, and save them in internal structures while suspended. + +In contrast, task based runtimes need ultra-fast creation of tasks, and fast linkage from the end of one to the start of the next. They tend to keep the task-structures in a queue and discard them when complete. + +Hence, VP based runtimes revolve around storing suspended VPs inside structures that embody the constraints on when the VP can resume. But task based runtimes revolve around the conditions upon which to create new tasks, and the organization of the inputs to them. The runtimes for hybrid languages have characteristics of both. + + +\subsection{Domain specific parallel languages} +\label{subsec:DomSpecLangs} +[[Hypothesis: Embedded-style DSLs -\textgreater\ high productivity + low learning curve + low app-port + low disruption]] + +[[Bridge: Few users-\textgreater\ must be quick time to create + low effort to lang-port + high perf across targets]] + +[[Bridge: effort to create = runtime + effort port = runtime + perf on new target = runtime]] + +[[Bridge: big picture = langs * runtimes -\textgreater runtime effort critical]] + + +[[Claims: given big picture, runtime effort minimized -\textgreater modularize runtime, mod works across langs bec. fund patterns, mod sep lang logic from RT internals, mod makes internal reusable + lang inherit internal perf tune +inherit centralized serv, mod makes lang logic sequential, mod makes constructs reusable one lang to next, mod causes lang assigner to own HW]] + +Now we'll talk about the sub-class of Domain Specific Languages (DSLs): what sets them apart from other parallel languages, how they potentially solve the issues with parallel programming, and the implications for their runtime implementations. + +DSLs can be any of the three basic language types (VP based, task-based or hybrid), but they are distinguished by having constructs that correspond to features of one narrow domain of applications. For example, we have implemented a DSL that is just for use in building hardware simulators [cite the HWSim wiki]. Its constructs embody the structure of simulators, and make building one fast and even simpler than when using a sequential language, as will be shown in Subsection []. The programmer doesn't think about concurrency, nor even about control flow, they simply define behavior of individual hardware elements and connect them to each other. + +It is this fit between language constructs and the mental model of the application that makes DSLs highly productive and easy to learn, at the same time, it is also what makes applications written in them more portable. Application patterns that have strong impact on parallel performance are captured as language constructs. The rest of the source code has less impact on parallel performance, so just porting the language is enough to get high performance on each hardware target. + +In practice, designing such a language is an art, and for some hardware targets, the language can become intrusive. For example, for porting to GPGPUs, their performance is driven by decomposition into many small, simple, kernels, which access memory in contiguous chunks. Fitting into this pattern forces rearrangement of the base sequential code, and even constrains choice of algorithm. Hence, a DSL that is portable to standard architectures as well as GPUs would place the GPU restrictions onto the code for all machines. However, much excellent work [polyhedral, others] is being done on automated tools to transform standard code to GPU form, which would lift the restrictions. Also, constructs such as the DKU pattern [] map well onto GPUs as well as standard hardware. + +\subsection{The embedded style of DSL} +\label{subsec:EmbeddedDSLs} +[[Hypothesis: Embedded-style DSLs -\textgreater\ high productivity + low learning curve + low app-port + low disruption]] + +[[Bridge: Few users-\textgreater\ must be quick time to create + low effort to lang-port + high perf across targets]] + +[[Bridge: effort to create = runtime + effort port = runtime + perf on new target = runtime]] + +[[Bridge: big picture = langs * runtimes -\textgreater runtime effort critical]] + + +[[Claims: given big picture, runtime effort minimized -\textgreater modularize runtime, mod works across langs bec. fund patterns, mod sep lang logic from RT internals, mod makes internal reusable + lang inherit internal perf tune +inherit centralized serv, mod makes lang logic sequential, mod makes constructs reusable one lang to next, mod causes lang assigner to own HW]] + +We segue now into the embedded style of language, and show how the work of implementing them is mainly the work of implementing their runtime plus their complex domain constructs. We focus on embedded style domain specific languages because it is the least effort-to-create form of DSL, and making DSLs practical requires it to be low effort to create them and port them to various hardware targets. + + +An embedded-style language is one that uses the syntax of a base language, like C or Java, and adds constructs that are specific to the domain. An added construct may be expressed in custom syntax that is translated to into a library call, or else directly invoked by making a library call, as illustrated in Figure \ref{fig:EmbeddedEx}. Inside the library call, a primitive is used to escape the base language and enter the embedded language's runtime, which then performs the behavior of the construct. + + +\begin{figure}[h!tb] +{\noindent +{\footnotesize +{\normalsize Creating a new virtual processor (VP):} +\begin{verbatim} +newVP = SSR__create_VP( &top_VP_fn, paramsPtr, animatingVP ); +\end{verbatim} + +{\noindent {\normalsize sending a message between VPs:}} +\begin{verbatim} +SSR__send_from_to( messagePtr, sendingVP, receivingVP ); +\end{verbatim} + +{\noindent {\normalsize receiving the message (executed in a different VP):}} +\begin{verbatim} +messagePtr = SSR__receive_from_to( sendingVP, receivingVP ); +\end{verbatim} +} +} + +\caption +{Examples of invoking embedded-style constructs. +} +\label{fig:EmbeddedEx} +\end{figure} +An embedded-style language differs from a library in that it has a runtime system, and a way to switch from the behavior of the base language to the behavior inside the runtime. In contrast, libraries never leave the base language. Notice that this means, for example, that a posix threads library is not a library at all, but an embedded language. + +As a practical matter, embedded-style constructs normally have a thin wrapper that invokes the runtime. However, some DSLs perform significant effort inside the library before switching to the runtime, or else after returning from the runtime. These look more like traditional libraries, but still involve an escape from the base language and more importantly are designed to work in concert with the parallel aspects of the language. They concentrate key performance-critical aspects of the application inside the language, such as dividing work up, or, for example, implementing a solver for differential equations that accepts structures created by the divider. + +It is the appearance of constructs being library calls that brings the low-disruption benefit of embedded-style DSLs. The syntax is that of the base language, so the existing development tools and work flows remain intact when moving to an embedded style DSL. In addition, the fit between domain concepts and language constructs minimizes mental-model disruption when switching and makes the learning curve to adopt the DSL very low. + +\subsection{Application programmer's view of embedded-style DSLs} +\label{subsec:AppProgViewOfDSL} +[[Hypothesis: Embedded-style DSLs -\textgreater\ high productivity + low learning curve + low app-port + low disruption]] + +[[Bridge: Few users-\textgreater\ must be quick time to create + low effort to lang-port + high perf across targets]] + +[[Bridge: effort to create = runtime + effort port = runtime + perf on new target = runtime]] + +[[Bridge: big picture = langs * runtimes -\textgreater runtime effort critical]] + + +[[Claims: given big picture, runtime effort minimized -\textgreater modularize runtime, mod works across langs bec. fund patterns, mod sep lang logic from RT internals, mod makes internal reusable + lang inherit internal perf tune +inherit centralized serv, mod makes lang logic sequential, mod makes constructs reusable one lang to next, mod causes lang assigner to own HW]] + +Well designed DSLs have very few constructs, yet capture the most performance-critical domain patterns, in a way that feels natural to the application programmer. This often means that data structures and usage patterns are part of the language. + +For example, a linear-equation-solving language would define a standard data structure for the coefficients of the equations, and supply a construct by which the language is asked to perform the work of solving them. This feels very much like a library, but the runtime system dynamically performs division of work according to the hardware, and implements communication between cores and a scheduler that load balances and tries to take advantage of data affinity and even computational accelerators. All of which puts performance in the hands of the runtime and is simple to use. + +An example of a DSL that we created using the proto-runtime approach is HWSim [], which is designed to be used for writing architectural simulators. + +When using HWSim, a simulator application is composed of just three things: netlist, behavior functions and timing functions. These are all sequential code that call HWSim constructs at boundaries, such as the end of behavior, and use HWSim supplied data structures. To use HWSim, one creates a netlist composed of elements and communication paths that connect them. A communication path connects an outport of the sending element to an inport of the receiving element. An action is then attached to the inport. The action is triggered when a communication arrives. The action has a behavior function, which changes the state of the element, and a timing function which calculates how much simulated time the behavior takes. + +The language itself consists of only a few standard data structures, such as \texttt{Netlist}, \texttt{Inport}, \texttt{Outport}, and a small number of constructs, such as \texttt{send\_comm} and \texttt{end\_behavior}. The advancement of simulated time is performed by a triggered action, and so is implied. The parallelism is also implied, by the only constraints on order of execution of actions being consistency. + +The only parallelism-related restriction is that a behavior function may only use data local to the element it is attached to. Parallel work is created within the system by outports that connect to multiple destination inports which means one output triggers multiple actions, and by behavior functions that generate multiple output communications each. + +Overall, simulator writers have fewer issues to deal with because time-related code has been brought inside the language, where it is reused across simulators, and because parallelism issues reduce to simply being restricted to data local to the attached element. Both these increase productivity of simulator writers, despite using a parallel language. The language has so few commands that it takes only a matter of days to become proficient (as demonstrated informally by new users of HWSim). Also, parallelism related constructs in the language are generic across hardware, eliminating the need to modify application code when porting to new hardware (if the language is used according to the recommended coding style). + +\subsection{Implementation of Embedded-style DSLs} +[[Hypothesis: Embedded-style DSLs -\textgreater\ high productivity + low learning curve + low app-port + low disruption]] + +[[Bridge: Few users-\textgreater\ must be quick time to create + low effort to lang-port + high perf across targets]] + +[[Bridge: effort to create = runtime + effort port = runtime + perf on new target = runtime]] + +[[Bridge: big picture = langs * runtimes -\textgreater runtime effort critical]] + + +[[Claims: given big picture, runtime effort minimized -\textgreater modularize runtime, mod works across langs bec. fund patterns, mod sep lang logic from RT internals, mod makes internal reusable + lang inherit internal perf tune +inherit centralized serv, mod makes lang logic sequential, mod makes constructs reusable one lang to next, mod causes lang assigner to own HW]] + +When it comes to implementing an embedded-style of DSL, the bulk of the effort is in the runtime and the more complex domain specific constructs. + +Examples of constructs implemented for DSLs include Abstract Data Types (ADTs), like linked lists, hash tables, and priority queues. Also, full algorithms, like solvers for systems of equations, or even linear algebra operations on matrices. It will be seen in subsection[] that the proto-runtime approach causes the implementation for such constructs to be reused, with high performance, across all the hardware targets in a hardware class such as the class of shared-memory multi-core platforms. + +In addition, embedded style DSLs rely heavily on data types that are part of the language. These are often domain-specific such as \texttt{Netlist}, \texttt{Inport}, and \texttt{Outport} in HWSim, or \texttt{Protein} in a bio-informatics DSL, but can also be common such as \texttt{SparseMatrix} in domains like data mining and scientific applications. + + + During language design, common patterns that consume significant development time or computation are placed into the language. Also, any patterns that expose hardware configuration, such as the number and size of pieces of work should be pulled into the language to aid portability. + +If such design is successful then porting the application reduces to just porting the language. When the language has successfully captured the main computational patterns of the domain, then the application code encapsulates only a small portion of the performance, so it does not need to be tuned. Further, when patterns that expose hardware-motivated choices or hardware-specific commands are in the language, then the application code has nothing that needs to change when the hardware changes. + +For example, HWSim pulls hardware-specific patterns inside the language by handling all inter-core communications inside the language, and also by aggregating multiple elements together on the same core to tune work-unit size. + +The advantage of placing these into the language, instead of application code, is portability and productivity. + + +\subsection{Implementation Details of Embedded-style DSLs} +[[Hypothesis: Embedded-style DSLs -\textgreater\ high productivity + low learning curve + low app-port + low disruption]] + +[[Bridge: Few users-\textgreater\ must be quick time to create + low effort to lang-port + high perf across targets]] + +[[Bridge: effort to create = runtime + effort port = runtime + perf on new target = runtime]] + +[[Bridge: big picture = langs * runtimes -\textgreater runtime effort critical]] + + +[[Claims: given big picture, runtime effort minimized -\textgreater modularize runtime, mod works across langs bec. fund patterns, mod sep lang logic from RT internals, mod makes internal reusable + lang inherit internal perf tune +inherit centralized serv, mod makes lang logic sequential, mod makes constructs reusable one lang to next, mod causes lang assigner to own HW]] + +? + +Figure [] shows\ the implementation of the wrapper library for HWSim's send\_and\_idle construct, which sends a communication on the specified outport, and then causes the sending element to go idle. Of note is the packaging of information for the runtime. It is placing into the HWSimSemReq data structure, and then the application work is ended by switching to the runtime. The switch is via the send\_and\_suspend call, which is a primitive implemented in assembly that jumps out of the base C language and into the runtime. + +The switch to the runtime can be done in multiple ways. Our proto-runtime uses assembly to manipulate the stack and registers. For posix threads language, when implemented in Linux, the hardware trap instruction is used to switch from application to the OS. The OS serves as the runtime that implements the thread behavior. + +The core is used by the construct implementation differently for VP based languages vs for task based languages. + +For VP based languages, once inside the runtime, a synchronization construct performs the behavior shown abstractly in Figure []. In essence, a synchronization construct is a variable length delay, which waits for activities outside the calling code to cause specific conditions to become true. These activities could be actions taken by other pieces of application code, such as releasing a lock, or they could be hardware related, such as waiting for a DMA transfer to complete. + +While one piece of application code (in a VP) is suspended, waiting, other pieces can use the core to perform their work, as long as the conditions for those other pieces are satisfied. Hence, the runtime's construct implementation checks if conditions are met, and if not stores the suspended piece (VP). If the construct can change conditions for others, it updates them. For example, the lock-release construct updates state for VPs waiting for the lock. Separately, for VPs whose conditions have been met, when a core becomes available, the runtime chooses which VP to assign to which core. + +These are the two behaviors a construct performs inside the runtime: managing conditions on which work is free, and managing assignment of free work onto cores. + +For task based languages, a task runs to completion then always switches to the runtime at the end. Hence, no suspend and resume exists. Once inside, the runtime's job is to track conditions on which tasks are ready to run, or which to create. For example, in dataflow, a task is created only once all conditions for starting it are met. Hence, the only language constructs are "instantiate a task-creator", "connect a task creator to others", and "end a task". During a run, all of the runtime behavior takes place inside the "end a task" construct, where the runtime sends outputs from the ending task to the inputs of connected task-creators. The "send" action modifies internal runtime state, which represents the order of inputs to a creator on all of its input ports. When all inputs are ready, it creates a new task, then when hardware is ready, assigns the task to a core. + + +One survey[] discusses DSLs for a variety of domains, and this list of DSLs was copied from their paper: +\begin{itemize} +\item In Software Engineering: Financial products [12, 22, 24], behavior control and coordination [9, 10], software architectures [54], and databases [39]. +\item Systems Software: Description and analysis of abstract syntax trees [77, 19, 51], video device driver specifications [76], cache coherence protocols [15], data structures in C [72], and operating system specialization [63]. +\item Multi-Media: Web computing [14, 35, 4, 33], image manipulation [73], 3D animation [29], and drawing [44]. +\item Telecommunications: String and tree languages for model checking [48], communication protocols [6], telecommunication switches [50], and signature computing [11]. +\item Miscellaneous: Simulation [2, 13], mobile agents [36], robot control [61], solving partial differential equations [26], and digital hardware design [41]. +\end{itemize} + +\subsection{Summary of Section} + [[Hypothesis: Embedded-style DSLs -\textgreater\ high productivity + low learning curve + low app-port + low disruption]] + +[[Bridge: Few users-\textgreater\ must be quick time to create + low effort to lang-port + high perf across targets]] + +[[Bridge: effort to create = runtime + effort port = runtime + perf on new target = runtime]] + +[[Bridge: big picture = langs * runtimes -\textgreater runtime effort critical]] + + +[[Claims: given big picture, runtime effort minimized -\textgreater modularize runtime, mod works across langs bec. fund patterns, mod sep lang logic from RT internals, mod makes internal reusable + lang inherit internal perf tune +inherit centralized serv, mod makes lang logic sequential, mod makes constructs reusable one lang to next, mod causes lang assigner to own HW]] + +This section illustrated the promise of DSLs for solving the issues with parallel programming. The HWSim example showed that well designed parallel DSLs can actually improve productivity, and have a low learning curve, as well as reduce the need for touching application code when moving to new target hardware. The section showed that the effort of implementing an embedded style DSL is mainly that of implementing its runtime and complex domain constructs, and that a well-designed DSL captures most of the performance-critical aspects of an application inside the DSL constructs. Hence, porting effort reduces to just performance-tuning the language (with caveats for some hardware). This effort is, in turn, reused by all the applications that use the DSL. + +The stumbling point of DSLs is the small number of users, after all, how many people write hardware simulators? Perhaps a few thousand people a year write or modify applications suitable for HWSim. That means the effort to implement HWSim has to be so low as to make it no more effort than writing a library, effectively a small percentage of a simulator project. + +The runtime is a major piece of the DSL implementation, so reducing the effort of implementing the runtime goes a long way to reducing the effort of implementing a new DSL. + +%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% +\section{Description} +\label{sec:idea} +[[Hypothesis: Embedded-style DSLs -\textgreater\ high productivity + low learning curve + low app-port + low disruption]] + +[[Bridge: Few users-\textgreater\ must be quick time to create + low effort to lang-port + high perf across targets]] + +[[Bridge: effort to create = runtime + effort port = runtime + perf on new target = runtime]] + +[[Bridge: big picture = langs * runtimes -\textgreater runtime effort critical]] + + +[[Claims: given big picture, runtime effort minimized -\textgreater modularize runtime, mod works across langs bec. fund patterns, mod sep lang logic from RT internals, mod makes internal reusable + lang inherit internal perf tune +inherit centralized serv, mod makes lang logic sequential, mod makes constructs reusable one lang to next, mod causes lang assigner to own HW]] + +? + + +Now that we have made the case that embedded style DSLs have potential to solve many parallel programming issues, and that a major obstacle to uptake of them is their implementation effort, we describe the proto-runtime concept and show how it addresses this obstacle to DSLs. As shown, embedded style DSL implementation effort and porting effort is mainly that of creating the runtime and implementing the more complex language constructs. We show here that the proto-runtime approach dramatically reduces the effort of creating a DSL runtime, through a number of features. + + +\begin{figure}[ht] + \centering + \includegraphics[width = 2in, height = 1.8in]{../figures/PR_three_pieces.pdf} + \caption{Shows how the proto-runtime approach modularizes the implementation of a runtime. The three pieces are the proto-runtime implementation, an implementation of the language construct behaviors, and an implementation of the portion of a scheduler that chooses which work is assigned to which processor. } + \label{fig:PR_three_pieces} +\end{figure} + + +The main feature is the proto-runtime's approach to modularizing the runtime code. As shown in Fig \ref{fig:PR_three_pieces}, it breaks the runtime into three pieces: a cross-language piece, which is the proto-runtime implementation, a piece that implements the language's constructs and plugs into the proto-runtime, and a piece that assigns work onto hardware and also plugs into the proto-runtime. + +The modularization appears to remain valid across parallel languages and execution models, and we present underlying patterns that support this observation. We analyze the basic structure of a synchronization construct, and point out how the proto-runtime modularization is consistent with it. + +\subsection{Creating an eDSL} + + +\begin{figure}[ht] + \centering + \includegraphics[width = 2in, height = 1.8in]{../figures/eDSL_two_pieces.pdf} + \caption{An embedded style DSL consists of two parts: a runtime and a wrapper library that invokes the runtime} + \label{fig:eDSL_two_pieces} +\end{figure} + +As shown in Fix \ref{fig:eDSL_two_pieces}, to create an embedded style DSL (eDSL), do two things: create the runtime and create a wrapper-library that invokes the runtime and also implements the more complex language constructs. + +As seen in Fig X, a library call that invokes a language construct is normally a thin wrapper that only communicates to the runtime. It places information to be sent to the runtime into a carrier, then invokes the runtime via a primitive. The primitive suspends the base language execution and switches the processor over to the runtime code. + +\subsection{The Proto-Runtime Modularization} + +\subsubsection{Dispatch pattern} +-- standardizes runtime code +-- makes familiar going from one lang to another +-- makes reuse realistic, as demonstrated by VSs taking SSR constructs + +-- show the enums, and the switch table + +-- point out how the handler receives critical info -- the semEnv, req struct and calling slave + +\subsubsection{The Request Handler} +-- cover what a request handler does.. connect it to the wrapper lib, and the info loaded into a request struct. + +-- give code of a request handler.. within on-going example of implementing pthreads, or possibly HWSim, or pick a new DSL + +\subsection{Exporting a performance-oriented machine view } +The proto-runtime interface exports a view of the machine that shows performance-critical aspects. Machines that share the same architectural approach have the same performance-critical aspects, and differ only in the values. + +For example, the interface models cache-coherent shared-memory architectures as a collection of memory pools connected by networks. The essential variations among processor-chips are the sizes of the pools, the connections between them, such as which cores share the same L2 cache, and the latency and bandwidth between them. + +Hence, a single plugin can be written that gathers this information from the proto-runtime and uses it when deciding which work to assign to which core. Such a plugin will then be efficient across all machines that share the same basic architecture. + +This saves significant effort by allowing the same plugin to be reused for all the machines in the category. + +\subsection{Services Provided by the Proto-runtime} + +-- Put services into the low-level piece.. plugins have those available, and inherit lang independent such as debugging, perf counters.. provides effort reduction because lang doesn't have to implement these services. + +-- -- examples of iherited lang services inside current proto-runtime: debugging and perf-tuning.. verification, playback have been started (?) + +-- -- examples of plugin services: creation of base VP, the switch primitives, the dispatch pattern (which reduces effort by cleanly separating code for each construct), handling consistency model (?), handling concurrency + +\subsection{eDSLs talking to each other} +-- show how VSs is example of three different DSLs, and H264 code is three different languages interacting (pthreads, OpenMP, StarSs) + +-- make case that proto-runtime is what makes this practical ! Their point of interaction is the common proto-runtime innards, which provides the interaction services.. they all use the same proto-runtime, and all have common proto-runtime objects, which is how the interaction becomes possible. + +\subsection{The Proto-runtime Approach Within the Big Picture} + +-- Give background on industry-wide, how have langs times machines.. +-- say that proto-runtime has synergistic advantages within this context. -- repeat that eDSLs talk to each other. +-- give subsubsection on MetaBorg for rewriting eDSL syntax into base lang syntax. +-- bring up the tools issue with custom syntax -- compiling is covered by metaborg re-writing.. can address debugging with eclipse.. should be possible in straight forward way that covers ALL eDSLs.. their custom syntax being stepped through in one window, and stepping through what they generate in separate window (by integrating generation step into eclipse).. even adding eclipse understanding of proto-runtime.. so tracks the sequence of scheduling units.. and shows the request handling in action in third window.. + +Preview idea that many players will contribute, and will get people that specialize in creating new eDSLs (such as one of authors).. +-- For them, code-reuse is reality, as supported by VSs example, +-- and the uniformity of the pattern becomes familiar, also speeding up development, as also supported by VSs, HWSim, VOMP, and DKU examples. +-- for those who only create a single eDSL, the pattern becomes a lowering of the learning curve, aiding adoption + +-- Restate and summarize the points below (covered above), showing how they combine to shrink the wide-spot where all the runtimes are. + +-- The low-level part implemented on each machine, exports a view of the machine that shows performance-critical aspects + +-- Collect machines into groups, based on performance critical aspects of hardware.. provides reduction in effort because only one plugin for entire group. + +-- Put services into the low-level piece.. plugins have those available, and inherit lang independent such as debugging.. provides effort reduction because lang doesn't have to implement these services. + + +\section{(outline and notes)} + +-- What a plugin looks like: + +-- -- pattern of parallel constructs.. ideas of Timeline, tie-point, animation, suspension, VP states, constraints, causality, work-units, meta-units, updates in constraint states attached to the meta-units + +-- -- a sych construct is something that creates a tie between two work-units. So, the logic of the construct simply establishes causality -- the ending of one work-unit causes the freedom to start animation of another. + +-- -- -- Examples: mutex is end of work-unit that frees lock causes freedom to start work-unit that gets the lock. They are causally tied. The semantics of the construct is the particular conditions existing inside the runtime (in this case ownership condition of a mutex), and what changes those conditions (in this case releasing lock removes one from owner, plus acquire-lock sets one as wanting the lock), and how freedom to be animated is affected by the changes in conditions (in this case, removal of ownership must precede gaining ownership) on what makes a work-unit free (in this case, being given ownership of the mutex), + +-- Hence, precisely, the parallelism model of the language defines constraints, which are implemented as state inside the runtime. Constructs provided do a number of things: signal bringing a set of constraints into existence (create a mutex), signal update to the state of those constraints (release mutex, state desire to acquire), and trigger the runtime to propagate those changes, which results in additional changes to states, including marking meta-units as free to be animated. cause creation of meta-units (explicitly as in VSs, or via creating entities that trigger creation as in dataflow, or via creating entities that consist of consecutive work-units as in pthreads). + + +-- Recipe for how to make the language plugin: time reduction is part due to simplifying the parallelism construct logic.. + + + + +\subsection{The Cross-language Patterns Behind the Proto-runtime} + +[[Hypothesis: Embedded-style DSLs -\textgreater\ high productivity + low learning curve + low app-port + low disruption]] + +[[Bridge: Few users-\textgreater\ must be quick time to create + low effort to lang-port + high perf across targets]] + +[[Bridge: effort to create = runtime + effort port = runtime + perf on new target = runtime]] + +[[Bridge: big picture = langs * runtimes -\textgreater runtime effort critical]] + + +[[Claims: given big picture, runtime effort minimized -\textgreater modularize runtime, mod works across langs bec. fund patterns, mod sep lang logic from RT internals, mod makes internal reusable + lang inherit internal perf tune +inherit centralized serv, mod makes lang logic sequential, mod makes constructs reusable one lang to next, mod causes lang assigner to own HW]] + +An application switches to the runtime, which does scheduling work then switches back to application code. + + +\subsection{Some Definitions} + +[[Hypothesis: Embedded-style DSLs -\textgreater\ high productivity + low learning curve + low app-port + low disruption]] + +[[Bridge: Few users-\textgreater\ must be quick time to create + low effort to lang-port + high perf across targets]] + +[[Bridge: effort to create = runtime + effort port = runtime + perf on new target = runtime]] + +[[Bridge: big picture = langs * runtimes -\textgreater runtime effort critical]] + + +[[Claims: given big picture, runtime effort minimized -\textgreater modularize runtime, mod works across langs bec. fund patterns, mod sep lang logic from RT internals, mod makes internal reusable + lang inherit internal perf tune +inherit centralized serv, mod makes lang logic sequential, mod makes constructs reusable one lang to next, mod causes lang assigner to own HW]] + +We adopt the concepts of work-unit, virtual processor (VP), animation, and tie-point as discussed in a previous paper []. A work-unit is the trace of instructions executed between two successive switches to the runtime, along with the data consumed and produced during that trace. A Virtual Processor is defined as being able to animate either the code of a work-unit or else another VP, and has state that it uses during animation, organized as a stack. Animation is definedd as causing time of a virtual processor to advance, which is equivalent to causing state changes according to instructions, while suspension halts animation, and consequently causes the end of a work-unit (a more complete definition of animation can be found in the dissertation of Halle[]). A tie-point connects the end of one work-unit to the beginning of one in a different VP, so a tie-point represents a causal relationship between two work-units, and establishes an ordering between those work-units, effectively tying the time-line of the VP animating one to the time-line of the VP animating the other work-unit. + +In addition, we introduce a definition of the word task, which is a single work-unit coupled to a virtual-processor that comes into existence to animate the work-unit and dissipates at completion of the work-unit. By definition of work-unit, a task cannot suspend, but rather runs to completion. If the language defines an entity that has a timeline that can be suspended by switching to the runtime, then such an entity is not a task. Pure Dataflow[] specifies tasks that fit our definition. + +\subsection{Handling Memory Consistency Models} + +[[Hypothesis: Embedded-style DSLs -\textgreater\ high productivity + low learning curve + low app-port + low disruption]] + +[[Bridge: Few users-\textgreater\ must be quick time to create + low effort to lang-port + high perf across targets]] + +[[Bridge: effort to create = runtime + effort port = runtime + perf on new target = runtime]] + +[[Bridge: big picture = langs * runtimes -\textgreater runtime effort critical]] + + +[[Claims: given big picture, runtime effort minimized -\textgreater modularize runtime, mod works across langs bec. fund patterns, mod sep lang logic from RT internals, mod makes internal reusable + lang inherit internal perf tune +inherit centralized serv, mod makes lang logic sequential, mod makes constructs reusable one lang to next, mod causes lang assigner to own HW]] + +Weak memory models can cause undesired behavior when work-units on different cores communicate through shared variables. Specifically, the receiving work-unit can see memory operations complete in a different order than the code of the sending work-unit specifies. + +For example, consider a proto-runtime implemented on shared memory hardware that has a weak consistency model, along with a language that implements a traditional mutex lock. All memory operations performed in the VP that releases the lock should be seen as complete by the VP that next acquires the lock. + +It is up to the proto-runtime to enforce this, using hardware primitives. It has to ensure that all memory operations performed, by a task or VP, before switching to the runtime are completed before any dependent task or VP is switched into from the runtime. More precisely, the proto-runtime has to ensure that all memory operations performed by a work-unit are visible in program order to any tied work-units. In some cases the language plugin has to alert the proto-runtime of the causality between work-units. + + +The proto-runtime does not, however, protect application code that attempts to communicate between VPs or tasks directly, without using a parallelism construct to protect the communication. + + + +======= + + I plan to explain VMS as a universal pattern that exists in all runtimes: that is, that the application switches to runtime, which does a scheduling decision and then switches back. I'll explain it first with just master and slaves, leaving out the core\_loop. Explain it as a normal runtime that has had two key pieces removed and replaced with interfaces. The language supplies the missing pieces. Then, introduce the core\_loop stuff as a performance enhancement used when lock acquisition dominates (as it does on the 4 socket 40 core machine). + Next, give HWSim as an example of a real domain specific (it's working, ref manual attached), and focus on how the modularity allowed pulling constructs from other languages (singleton and atomic), and a breakdown of implementation time vs design time, and so on. Highlight how VMS's features for productivity and encapsulation solve the practical problems for domain-specific languages. + Finally, show that VMS performance is good enough, by going head-to-head with pthreads and OpenMP (doing a VMS OpenMP implementation now). And also StarSs if I have time. I'll run overhead-measuring on them, and also regular benchmarks. + +================= + +\subsection{The patterns} +[[Hypothesis: Embedded-style DSLs -\textgreater\ high productivity + low learning curve + low app-port + low disruption]] + +[[Bridge: Few users-\textgreater\ must be quick time to create + low effort to lang-port + high perf across targets]] + +[[Bridge: effort to create = runtime + effort port = runtime + perf on new target = runtime]] + +[[Bridge: big picture = langs * runtimes -\textgreater runtime effort critical]] + + +[[Claims: given big picture, runtime effort minimized -\textgreater modularize runtime, mod works across langs bec. fund patterns, mod sep lang logic from RT internals, mod makes internal reusable + lang inherit internal perf tune +inherit centralized serv, mod makes lang logic sequential, mod makes constructs reusable one lang to next, mod causes lang assigner to own HW]] + + +Soln: modularize runtime, to reduce part have to mess with, hide part that has low-level details, reuse low-level tuning effort, and reuse lang-spec parts. + +Benefits: lang impl doesn't have to touch low-level details, inherit centralized services, can reuse code from other languages to add features. + +Performance must be high, or the labor savings don't matter. By isolating the low-level details inside the proto-runtime, they can be intensively tuned, then all the languages inherit the effort. + +Part of what makes this so easy is the dispatch pattern.. adding a construct reduces to adding into switch and writing handler.. borrow constructs by taking the handler from the other lang. + +By isolating the low-level details inside the proto-runtime, they can be intensively tuned, then all the languages inherit the effort. Compare that to current practices, where the runtime code is monolithic.. each language has to separately modify the runtime, understanding and dealing with the concurrency, and then on a new machine, each language has to re-tune the low-level details, worrying about the consistency model on that machine, how its particular fence and atomic instructions work, and so on. +We spent 2 months performance tuning the current version, but only 18 hours implementing VSs on top of it, and VSs inherited the benefit from all that effort. So did VOMP, and SSR, and VCilk, and so on.. each time we improved the proto-runtime, all the languages improved, with no effort on the part of the language creator. + + +\subsubsection{Views of synchronization constructs} +[[Hypothesis: Embedded-style DSLs -\textgreater\ high productivity + low learning curve + low app-port + low disruption]] + +[[Bridge: Few users-\textgreater\ must be quick time to create + low effort to lang-port + high perf across targets]] + +[[Bridge: effort to create = runtime + effort port = runtime + perf on new target = runtime]] + +[[Bridge: big picture = langs * runtimes -\textgreater runtime effort critical]] + + +[[Claims: given big picture, runtime effort minimized -\textgreater modularize runtime, mod works across langs bec. fund patterns, mod sep lang logic from RT internals, mod makes internal reusable + lang inherit internal perf tune +inherit centralized serv, mod makes lang logic sequential, mod makes constructs reusable one lang to next, mod causes lang assigner to own HW]] + +One view of sync constructs is that they are variable-length calls. The +basic hardware does this by stalling the pipeline. + +Another view is that they mark the boundary of a communication made via shared read/write. A load or store of a single location has a precise boundary enforced by the hardware, but if a pipeline desires to load, modify, then write a single location it has to have additional hardware. It has to make the multiple primitive load/store operations appear as a single operation. + +Moving up to the application level, the same pattern exists: an operation the application wants to do may involve many loads and stores, but it wants the collection to appear as a single indivisible operation. So the application-level equivalent of a load or store involves multiple memory locations but is to be treated as a single indivisible operation. This requires the application-level equivalent of the hardware that made the read-modify-write into a single indivisible operation. That equivalent is what a synchronization construct is. The reason a sync construct takes a variable amount of time is that it waits until all other indivisible operations that might conflict have completed. + +Another way to think of the sync construct is that it enforces sharp communication boundaries. The multiple read and write operations are treated as a single communication with the shared-state. If any other part of the application sees only part of the communication, it sees something inconsistent and thus wrong. So the sync constructs ensure that communications are complete, so the parts of the application only see complete communications from other parts. + +\subsubsection{Universal Runtime Patterns} +[[Hypothesis: Embedded-style DSLs -\textgreater\ high productivity + low learning curve + low app-port + low disruption]] + +[[Bridge: Few users-\textgreater\ must be quick time to create + low effort to lang-port + high perf across targets]] + +[[Bridge: effort to create = runtime + effort port = runtime + perf on new target = runtime]] + +[[Bridge: big picture = langs * runtimes -\textgreater runtime effort critical]] + + +[[Claims: given big picture, runtime effort minimized -\textgreater modularize runtime, mod works across langs bec. fund patterns, mod sep lang logic from RT internals, mod makes internal reusable + lang inherit internal perf tune +inherit centralized serv, mod makes lang logic sequential, mod makes constructs reusable one lang to next, mod causes lang assigner to own HW]] + +Unified pattern within parallel languages: create multiple timelines, then control relative progress of them, and control location each chunk of progress takes place. + +Another universal pattern: code runs, switches to runtime, some point later switches back to code, making application run be a collection of trace segments bounded by runtime calls. +The runtime tracks constraints (dependencies) among units, creates and destroys units, and assigns ready units to hardware. + +Units have a life-line, which is fundamental to parallel computation, as demonstrated in a paper by some of the authors []. + +Every unit has a meta-unit that represents it in the runtime. A unit is defined as the trace of application code that exists between two scheduling decisions. Looking at this in more detail, every runtime has some form of internal bookkeeping state for a unit, used to track constraints on it and make decisions about when and where to execute. This exists even if that state is just a pointer to a function that sits in a queue. We call this bookkeeping state for a unit the meta-unit. + +Each unit also has a life-line, which progresses so: creation of the meta-unit \pointer , state updates that affect constraints on the unit \pointer, the decision is made to animate the unit \pointer, movement of the meta-unit plus data to physical resources that do the animation \pointer , animation of the unit, which does the work \pointer, communication of state-update, that unit has completed, and hardware is free \pointer , constraint updates within runtime, possibly causing new meta-unit creations or freeing other meta-units to be chosen for animation. This repeats for each unit. Each step is part of the model. + +Note a few implications: first, many activities internal to the runtime are part of a unit's life-line, and take place when only the meta-unit exists, before or after the work of the actual unit; second, communication that is internal to the runtime is part of the unit life-line, such as state updates; third, creation may be implied, such as in pthreads, or triggered such as in dataflow, or be by explicit command such as in StarSs, and once created, a meta-unit may languish before the unit it represents is free to be animated. + +\subsubsection{Putting synchronization constructs together with universal runtime patterns} +[[Hypothesis: Embedded-style DSLs -\textgreater\ high productivity + low learning curve + low app-port + low disruption]] + +[[Bridge: Few users-\textgreater\ must be quick time to create + low effort to lang-port + high perf across targets]] + +[[Bridge: effort to create = runtime + effort port = runtime + perf on new target = runtime]] + +[[Bridge: big picture = langs * runtimes -\textgreater runtime effort critical]] + + +[[Claims: given big picture, runtime effort minimized -\textgreater modularize runtime, mod works across langs bec. fund patterns, mod sep lang logic from RT internals, mod makes internal reusable + lang inherit internal perf tune +inherit centralized serv, mod makes lang logic sequential, mod makes constructs reusable one lang to next, mod causes lang assigner to own HW]] + +Putting these together, gives us that any parallelism construct that has a synchronization behavior causes the end of a work-unit, and a switch to the runtime. The code following the construct is a different work-unit that will begin after the constraint implied by the construct is satisfied. + +The runtime is made up of the infrastructure for the constraints and assignment, such as communicating bookkeeping state between cores, and protecting internal runtime updates of shared information. Plus, the logic of the constructs and logic of choosing an assignment of work to cores. + +For large machines, the infrastructure dominates the time to execute a parallelism construct, while for smaller machines, like single-socket, the logic of constructs and assignments has a chance to be significant. + +\begin{figure}[ht] + \centering + \includegraphics[width = 2in, height = 1.8in]{../figures/SCG_stylized_for_expl.pdf} + \caption{Something to help understanding} + \label{fig:SCG_expl} +\end{figure} + + + + +%%%%%%%%%%%%%%%%%%%%% +\section{The Details} +[[Hypothesis: Embedded-style DSLs -> high productivity + low learning curve + low disruption + low app-port AND quick time to create + low effort to lang-port + high perf across targets]] +[[Claims: modularize runtime, mod is fund patterns, mod sep lang logic from RT internals, mod makes internal reusable & lang inherit internal perf tune & inherit centralized serv, mod makes lang logic sequential, mod makes constructs reusable one lang to next, mod causes lang assigner to own HW]] + +The interfaces between lang logic and proto-runtime. + +Demonstrate: modular runtime, how reduces part have to mess with, hides part that has low-level details, reuses low-level tuning effort, and reuses lang-spec parts. + +Demonstrate Benefits: lang impl doesn't touch low-level details, inherits centralized services (debug support), reuses code from other languages to add features. + +\subsection{Reuse of Language Logic} +[[Hypothesis: Embedded-style DSLs -\textgreater\ high productivity + low learning curve + low app-port + low disruption]] + +[[Bridge: Few users-\textgreater\ must be quick time to create + low effort to lang-port + high perf across targets]] + +[[Bridge: effort to create = runtime + effort port = runtime + perf on new target = runtime]] + +[[Bridge: big picture = langs * runtimes -\textgreater runtime effort critical]] + + +[[Claims: given big picture, runtime effort minimized -\textgreater modularize runtime, mod works across langs bec. fund patterns, mod sep lang logic from RT internals, mod makes internal reusable + lang inherit internal perf tune +inherit centralized serv, mod makes lang logic sequential, mod makes constructs reusable one lang to next, mod causes lang assigner to own HW]] + +Demonstrate reuse of language logic: +All the languages have copied singleton, atomic, critical section and transaction. In VOMP, took the task code from VSS, in VSS, took the send and receive code from SSR.. for DKU, took the code almost verbatim from earlier incarnation of these ideas, and welded it into SSR, and took VSs tasks and put into SSR. Thus, circle completes.. VSs took from SSR, now SSR takes from VSs.. pieces and parts are being borrowed all over the place and welded in where they're needed. + +Part of what makes this so easy is the dispatch pattern.. adding a construct reduces to adding into switch and writing handler.. borrow constructs by taking the handler from the other lang. + +Another part is that code for the constructs is isolated from concurrency details, which are inside the proto-runtime. All the dynamic system issues, and best way to impl locks, and need for fences, and so on is isolated from the construct logic. This isolation is also how porting effort is lowered (or in many cases eliminated), and is how runtime performance is kept high. + +? + +Performance must be high, or the labor savings don't matter. By isolating the low-level details inside the proto-runtime, they can be intensively tuned, then all the languages inherit the effort. Compare that to current practices, where the runtime code is monolithic.. each language has to separately modify the runtime, understanding and dealing with the concurrency, and then on a new machine, each language has to re-tune the low-level details, worrying about the consistency model on that machine, how its particular fence and atomic instructions work, and so on. +We spent 2 months performance tuning the current version, but only 18 hours implementing VSs on top of it, and VSs inherited the benefit from all that effort. So did VOMP, and SSR, and VCilk, and so on.. each time we improved the proto-runtime, all the languages improved, with no effort on the part of the language creator. + +? + +In addition to runtime performance, application level performance must be high. The runtime's performance only affects overhead, and so is only a factor for small work-unit (task) sizes. But data affinity affects performance for all work. + +The proto-runtime approach partially addresses this by giving the language the opportunity to directly control placement of work. This isn't possible when building on top of threads, because the scheduling is in a separate, lower-level, layer where assignment of work to core is made in isolation, blind to language constructs and +other application features. + + + + +%%%%%%%%%%%%%%%%%%%%% +\section{Measurements} + +\subsection{Implementation time} + + +\subsection{Runtime and Application Performance} + + +%%%%%%%%%%%%%%%%%%%%% +\section{Related Work} + + +%%%%%%%%%%%%%%%%%%%%% +\section{Conclusion and Future Work} +\label{sec:conclusion} + + + +\end{document} +%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% +Here is an example of netlist creation: + +The circuit has two elements, each with one input port, one output port, and a single activity-type. The elements are cross-coupled, so output port of one connects to input port of the other. The input port has the activity-type attached as its trigger. The activity is empty, and just sends a NULL message on the output port. The activity's duration in simulated time and the resulting communication's flight duration in simulated time are both constants. + + Note that HWSimElem data type is generic. An elem is specialized by declaring inports and outports, and by connecting activity types to in-ports. Behavior is attached to an element by attaching activity types to in-ports of the element. + +First, here is the top-level function that creates and returns the netlist structure: + +To use HWSim, one creates a netlist composed of elements and communication paths connecting them. An element has a number of in-ports and outports, and a communication path connects an outport of the source element to an inport of the destination elements. The inport has an action attached, which in turn has a behavior function and a timing function, both of which are triggered by the arrival of a communication. The behavior function has local persistent state of the element available to use, and can generate out-going communications. The timing function calculates how much Guest (simulated) time the behavior spanned. In addition, communication paths have an attached function that calculates time from being sent until arrival of the communication. Both the behavior and timing function are application-programmer provided. The entire simulator application is composed of those three things: netlist, behavior functions and timing functions, and all are sequential code. + +The embedded DSL consists of standard data structures, such as netlist, inport, outport, that the application must use in the language-defined way, and a small number of language calls, such as send_comm and end_behavior. The advancement of simulated time is implied, and the parallelism is implied. The only parallelism-related restriction is that a behavior function may only use data local to the element it is attached to. If state in the hardware is shared, such as registers or memory, then other elements access that state by sending communications to the element that contains the state. Parallelism is created within the system by outports that connect to muliple destination inports, and by behavior functions that generate multiple output communications each. + + +\begin{small}\begin{verbatim} +HWSimNetlist * +createPingPongNetlist() + { HWSimNetlist *netlist; + HWSimElem **elems; + HWSimActivityType **activityTypes; + HWSimCommPath **commPaths; + int32 numElems, numActivityTypes, numCommPaths; +\end{verbatim}\end{small} + +The first thing to do is create the netlist structure, which holds three things: element structs, activity type structs, and communication path structs. It also has two collections of pointers to the traces collected during the run, but these are handled internally by HWSim. +\begin{small}\begin{verbatim} + netlist = malloc( sizeof(HWSimNetlist) ); + + numElems = 2; + elems = malloc( numElems * sizeof(HWSimElem *) ); + + numCommPaths = 2; + commPaths = malloc( numCommPaths * sizeof(HWSimCommPath *) ); + + numActivityTypes = 1; + activityTypes = malloc( numActivityTypes * sizeof(HWSimActivityType *) ); + + netlist->numElems = numElems; + netlist->elems = elems; + netlist->numCommPaths = numCommPaths; + netlist->commPaths = commPaths; + netlist->numActivityTypes = numActivityTypes; + netlist->activityTypes = activityTypes; +\end{verbatim}\end{small} + +Now, create the activity types. During the run, an activity instance is created each time a communication arrives on an in-port. The activity instance is a data structure that points to the activity type. The activity type holds the pointers to the behavior and timing functions. +\begin{small}\begin{verbatim} + //have to create activity types before create elements + //PING_PONG_ACTIVITY is just a #define for readability + netlist->activityTypes[PING_PONG_ACTIVITY] = createPingPongActivityType(); +\end{verbatim}\end{small} + +Next, create the elements, and pass the netlist structure to the creator. It will take pointers to activity types out of the netlist and place them into the in-ports of the elements. +\begin{small}\begin{verbatim} + elems[0] = createAPingPongElem( netlist ); //use activity types from netlist + elems[1] = createAPingPongElem( netlist ); +\end{verbatim}\end{small} + +Now, the reset in-port of one of the elements has to be set up to trigger an activity. Every element has a reset in-port, but normally they are set to NULL activity type. Here, we want only one of the two elements to have an activity triggered when the reset signal is sent to start the simulation. + +Note that during initialization, all the elements become active, each with its own timeline, but unless an activity is triggered in them they remain idle, with their timeline suspended and not making progress. Only ones that have an activity type attached to their reset in-port will begin to do something in simulated time when simulation starts. +\begin{small}\begin{verbatim} + //make reset trigger an action on one of the elements + elems[1]->inPorts[-1].triggeredActivityType = + netlist->activityTypes[PING_PONG_ACTIVITY]; +\end{verbatim}\end{small} + +Now, connect the elements together by creating commPath structures. A comm path connects the out-port of one element to the in-port of another. A given port may have many comm paths attached. However, an in-port has only one kind of activity type attached, and all incoming communications fire that same activity. There are multiple kinds of activity, including kinds that have no timing, and so can act as a dispatcher. These end themselves with a continuation activity, which is chosen according to the code in the behavior function. So, a commPath only connects an out port to an in port. + +This code sets fixed timing on the comm paths. It also uses a macro for setting the connections. The format is: sending elem-index, out-port, dest elem-index, in-port: +\begin{small}\begin{verbatim} + //elem 0, out-port 0 to elem 1, in-port 0 + commPaths[0]= malloc(sizeof(HWSimCommPath)); + setCommPathValuesTo(commPaths[0],0,0,1,0); + commPaths[0]->hasFixedTiming = TRUE; + commPaths[0]->fixedFlightTime = 10; //all time is stated in (integer) units + + //elem 1, out-port 0 to elem 0, in-port 0 + commPaths[1]= malloc(sizeof(HWSimCommPath)); + setCommPathValuesTo(commPaths[1], 1,0,0,0); + commPaths[1]->hasFixedTiming = TRUE; + commPaths[1]->fixedFlightTime = 10; //all time is stated in (integer) units +\end{verbatim}\end{small} + +done building netlist, return it +\begin{small}\begin{verbatim} + return netlist; + } +\end{verbatim}\end{small} + +The macro that sets the connections inside a comm path struct +\begin{small}\begin{verbatim} +#define setCommPathValuesTo( commPath, fromElIdx, outPort, toElIdx, inPort)\ +do{\ + commPath->idxOfFromElem = fromElIdx; \ + commPath->idxOfFromOutPort = outPort; \ + commPath->idxOfToElem = toElIdx; \ + commPath->idxOfToInPort = inPort; \ + }while(0); //macro magic for namespace +\end{verbatim}\end{small} + +Creating an element involves creating arrays for the in-ports and out-ports, then configuring the in-ports. The out-ports are automatically filled in during simulation start-up, by HWSim. The most interesting feature is that each in-port is assigned an activity type, which all arriving communications trigger. During the simulation, each incoming communication creates an activity instance, which points to this triggered activity type. The behavior and timing of the instance are calculated by the behavior and timing functions in the activity type. Notice that the activity type pointers are taken from the netlist, so they have to be created before creating the elements. +\begin{small}\begin{verbatim} +HWSimElem * +createAPingPongElem( HWSimNetlist *netlist ) + { HWSimElem *elem; + elem = malloc( sizeof(HWSimElem) ); + elem->numInPorts = 1; + elem->numOutPorts = 1; + elem->inPorts = HWSim_ext__make_inPortsArray( elem->numInPorts ); + elem->inPorts[-1].triggeredActivityType = IDLE_SPAN; //reset port + elem->inPorts[0].triggeredActivityType = netlist->activityTypes[PING_PONG_ACTIVITY]; + return elem; + } +\end{verbatim}\end{small} + +Creating an activity type involves setting the pointers to the behavior and timing functions, which are defined inside a separate directory where all the behavior and timing functions are defined. An activity may have behavior set to NULL, or timing set to NULL, and may have fixed timing. The structure has flags to state the combination. +\begin{small}\begin{verbatim} +HWSimActivityType * +createPingPongActivityType( ) + { HWSimActivityType *pingPongActivityType; + pingPongActivityType = malloc( sizeof(HWSimActivityType) ); + + pingPongActivityType->hasBehavior = TRUE; + pingPongActivityType->hasTiming = TRUE; + pingPongActivityType->timingIsFixed = TRUE; + pingPongActivityType->fixedTime = 10; + pingPongActivityType->behaviorFn = &pingPongElem_PingActivity_behavior; + return pingPongActivityType; + } +\end{verbatim} \end{small} + + +========= + +All behavior functions take a ptr to the activity instance they are executing the behavior of. The instance contains a pointer to the elem, and most behaviors will use the element's elemState field. It holds all the persistent state of the element, which remains between activities. + +Here is the behavior function from the ping-pong example: +\begin{small}\begin{verbatim} +void +pingPongElem_PingActivity_behavior( HWSimActivityInst *activityInst ) + { //NO_MSG is #define'd to NULL, and PORT0 to 0 + HWSim__send_comm_on_port_and_idle( NO_MSG, PORT0, activityInst ); + } +\end{verbatim}\end{small} + +There are four ways a behavior can end: +\begin{description} +\item end, no continuation: +\begin{small}\begin{verbatim} HWSim__end_activity_then_idle( HWSimActivityInst *endingActivityInstance )\end{verbatim}\end{small} +\item end, with continuation: +\begin{small}\begin{verbatim} HWSim__end_activity_then_cont( HWSimActivityInst *endingActivityInstance, + HWSimActivityType *continuationActivityType)\end{verbatim}\end{small} +\item end by sending a communication, with no continuation: +\begin{small}\begin{verbatim} HWSim__send_comm_on_port_then_idle( void *msg, int32 outPort, + HWSimActivityInst *endingActivityInstance)\end{verbatim}\end{small} +\item end by sending a communication, with continuation: +\begin{small}\begin{verbatim} HWSim__send_comm_on_port_then_cont( void *msg, int32 outPort, + HWSimActivityInst *endingActivityInstance + HWSimActivityType *continuationActivityType)\end{verbatim}\end{small} + + +============= + + +\subsection{Activity Timing Functions} +All activity timing functions take a ptr to the activity instance they are calculating the timing of. The instance contains a pointer to the element the activity is in. The behavior function is free to communicate to the timing function by leaving special data inside the element state. The timing function might also simply depend on the current state of the element. + +Here's an example: +\begin{small}\begin{verbatim} +HWSimTimeSpan +sampleElem_sampleActivity_timing( HWSimActivityInst *activityInst ) + { + return doSomethingWithStateOfElem( sendingActivity->elem->elemState ); + } +\end{verbatim}\end{small} + +\subsection{Calculating the time-in-flight of a communication path} + +The timing function for a communication path is similar to that of an activity. Except, the timing might also depend on configuration data or state stored inside the comm path struct, so that is passed to the timing function as well. + +\begin{small}\begin{verbatim} +HWSimTimeSpan +commPath_TimeSpanCalc( HWSimCommPath *commPath, HWSimActivityInst *sendingActivity ) + { return doSomethingWithStateOfPathAndElem( commPath, sendingActivity->elem->elemState ); + } +\end{verbatim}\end{small} + + + + diff -r 9b9a2497757d -r eb146c5c05a8 0__Papers/PRT/PRT__formal_def/latex/Paper_Design_2.txt --- /dev/null Thu Jan 01 00:00:00 1970 +0000 +++ b/0__Papers/PRT/PRT__formal_def/latex/Paper_Design_2.txt Sat Aug 03 19:24:22 2013 -0700 @@ -0,0 +1,32 @@ + +====== + +Details of VMS interface, details of its impl on multi-core, details of differences on different machines. + +wrapper-lib calls VMS-supplied primitive that suspends the virtual-processor calling the lib, and sends a request to VMS. VMS calls lang-supplied plugin to handle requests -- this is the part of the scheduler that handles constraints -- it determines which virt-processors must remain suspended, and which are free to be re-animated. + +The language is implemented as either a collection of wrapper-lib calls embedded into the base language, or as custom syntax that uses uses the VMS-supplied primitive to suspend virtual processors and send requests to VMS. + + +VMS is invisible to the application, only language constructs are visible. From the application-programmer point of view, the embedded version looks like a function call, albeit the data-struc of the virtual-processor animating the code has to be passed as a parameter to the wrapper-lib call. + +Hence, VMS is invisible to the application, only language constructs are visible. + +The wrapper-lib call is standard library code that is loaded along with the application executable. + +However, VMS primitives may be hardware-implemented, or loaded as OS modules, or dynamic or static libraries. Rhey are naturally custom instructions, but may be emulated by software. + +The interface between application-executable and language-runtime is the VMS-primitive that sends a request to VMS. The language-runtime receives the request under control of VMS, which calls a language-supplied request-handling function and passes the request as a parameter. This passive behavior of the request handler leaves control-flow inside VMS, which is part of hiding concurrency from the language-runtime implementation. + +The interface between the runtime and VMS is VMS's plugin API. The runtime is implemented as two functions, whose pointers are handed to VMS. VMS then controls the flow of execution. When a request is ready for the runtime, VMS cIalls the request-handler function, and when a spot on hardware is free for work, VMS calls the scheduler-assign function. Hence, the language implements its runtime as two isolated functions. By keeping control-flow inside VMS, the language-specific portion of the runtiem is simplified. + +This structure is also the reason VMS encourages reuse of scheduler code. The VMS API separates out control flow from scheduling, so scheduling code is isolated, with well-defined interfaces. Scheduling is then further sub-divided into modules: constraint-management (IE enforcing dependencies); and choosing physical location to place work. Each has its own well-defined interface, and they communicate to each other via VMS-managed shared state. + +The greatest application performance impact due to the scheduler is communication it causes. + +, management of the memory hierarchy, and the match between work-characteristics and hardware-characteristics (IE, assigning to accelerator vs CPU). Hence, significant work goes into implementing strategies and mechanisms for finding the best assignment-choices. Such implementations are only loosely coupled to language, through the shared state by which the request-handler informs the assigner of what work is ready to be animated. + +Hence, it is straight-forward to reuse the code that assigns work to physical locations. The only language-specific influence on the assigner is the shared constraint-state. + + + diff -r 9b9a2497757d -r eb146c5c05a8 0__Papers/PRT/PRT__formal_def/latex/bib_for_papers_jun_2012.bib --- /dev/null Thu Jan 01 00:00:00 1970 +0000 +++ b/0__Papers/PRT/PRT__formal_def/latex/bib_for_papers_jun_2012.bib Sat Aug 03 19:24:22 2013 -0700 @@ -0,0 +1,942 @@ + +@inbook{PerfToolPoem, +title = {The Poems of John Godfrey Saxe, Complete edition}, +chapter = {The Blind Men and the Elephant}, +author = {John Godfrey Saxe}, +publisher = {Boston: James R. Osgood and Company}, +year = {1873}, +pages = {77-78} +} +@article{PerfToolTau, +author = {Shende, Sameer S. and Malony, Allen D.}, +title = {The Tau Parallel Performance System}, +volume = {20}, +number = {2}, +pages = {287-311}, +year = {Summer 2006}, +journal = {International Journal of High Performance Computing Applications} +} +@ARTICLE{PerfToolParadyn, +author={Miller, B.P. and Callaghan, M.D. and Cargille, J.M. and Hollingsworth, J.K. and Irvin, R.B. and Karavanic, K.L. and Kunchithapadam, K. and Newhall, T.}, +journal={Computer}, +title={The Paradyn parallel performance measurement tool}, +year={1995}, +month={nov}, +volume={28}, +number={11}, +pages={37 -46}, +} +@ARTICLE{PerfToolParagraph, +author={Heath, M.T. and Etheridge, J.A.}, +journal={Software, IEEE}, +title={Visualizing the performance of parallel programs}, +year={1991}, +month={sept. }, +volume={8}, +number={5}, +pages={29 -39}, +} +@article{PerfToolStarSs, + author = {Steffen Brinkmann and + Jos{\'e} Gracia and + Christoph Niethammer and + Rainer Keller}, + title = {TEMANEJO - a debugger for task based parallel programming + models}, + journal = {CoRR}, + volume = {abs/1112.4604}, + year = {2011}, +} +@techrep{SyncConstr_impl_w_distr_coherence_HW_Utah_96, + author = {Carter, J. B. and Kuo, C.-C. and Kuramkote, R.}, + title = { A comparison of software and hardware synchronization mechanisms for distributed shared memory multiprocessors}, + institution = {University of Utah, Salt Lake City, UT}, + year = 1996, + url = {http://www.cs.utah.edu/research/techreports/1996/pdf/UUCS-96-011.pdf}, + number = {UUCS-96-011} +} +@Article{SWCoherence_Hill_SW_for_shared_coherence_w_HW_support_93, + author = {Hill, Mark D. and Larus, James R. and Reinhardt, Steven K. and Wood, David A.}, + title = {Cooperative shared memory: software and hardware for scalable multiprocessors}, + journal = {ACM Trans. Comput. Syst.}, + volume = 11, + number = 4, + year = 1993, + pages = {300--318} +} +@InProceedings{SWCache_MIT_embedSW_manages_cache_w_HW_supp, + author = {Chiou, Derek and Jain, Prabhat and Rudolph, Larry and Devadas, Srinivas}, + title = {Application-specific memory management for embedded systems using software-controlled caches}, + booktitle = {DAC}, + year = 2000, + pages = {416--419} +} +@InProceedings{SWCache_instr_trig_HW_supp_04, + author = {Janapsatya, Andhi and Parameswaran, Sri and Ignjatovic, A.}, + title = {Hardware/software managed scratchpad memory for embedded system}, + booktitle = {Proceedings of the 2004 IEEE/ACM International conference on Computer-aided design}, + series = {ICCAD '04}, + year = 2004, + pages = {370--377} +} +@InProceedings{SWCache_arch_supp_OS_policy_06, + author = {Rafique, Nauman and Lim, Won-Taek and Thottethodi, Mithuna}, + title = {Architectural support for operating system-driven CMP cache management}, + booktitle = {Proceedings of the 15th international conference on Parallel architectures and compilation techniques}, + series = {PACT '06}, + year = 2006, + pages = {2--12} +} +@InProceedings{SWCoherence_on_Distr_Mem_90, + author = {Bennett, J.K. and Carter, J.B. and Zwaenepoel, W.}, + booktitle = {Computer Architecture, 1990. Proceedings., 17th Annual International Symposium on}, + title = {Adaptive software cache management for distributed shared memory architectures}, + year = 1990, + pages = {125 -134} +} +@InProceedings{Charm_runtime_opt_10, + author = {Mei, Chao and Zheng, Gengbin and Gioachin, Filippo and Kal{\'e}, Laxmikant V.}, + title = {Optimizing a parallel runtime system for multicore clusters: a case study}, + booktitle = {The 2010 TeraGrid Conference}, + year = 2010, + pages = {12:1--12:8} +} +@InProceedings{TCC_Hammond_ISCA_04, + author = {Hammond, Lance and al, et}, + title = {Transactional Memory Coherence and Consistency}, + series = {ISCA '04}, + pages = {102--}, + booktitle = {}, + year = {} +} +@Misc{WorkTableHome, + author = {Halle, Sean}, + note = {http://musictwodotoh.com/worktable/content/refman.pdf}, + title = {The WorkTable Language Reference Manual}, + year = 2012 +} +@Misc{HWSimHome, + author = {Halle, Sean and Hausers, Stefan}, + note = {http://musictwodotoh.com/hwsim/content/refman.pdf}, + title = {The HWSim Language Reference Manual}, + year = 2012 +} +@Article{Lamport78, + author = {Lamport, Leslie}, + title = {Time, clocks, and the ordering of events in a distributed system}, + journal = {Commun. ACM}, + volume = 21, + issue = 7, + year = 1978, + pages = {558--565} +} +@Article{Lamport87, + author = {Lamport, Leslie}, + title = {A fast mutual exclusion algorithm}, + journal = {ACM Trans. Comput. Syst.}, + volume = 5, + issue = 1, + year = 1987, + pages = {1--11} +} +@InProceedings{Dijkstra67, + author = {Dijkstra, Edsger W.}, + title = {The structure of the "{THE}"-multiprogramming system}, + booktitle = {Proceedings of the first ACM symposium on Operating System Principles}, + series = {SOSP '67}, + year = 1967, + pages = {10.1--10.6} +} +@Article{Conway63, + author = {Conway, Melvin E.}, + title = {Design of a separable transition-diagram compiler}, + journal = {Commun. ACM}, + volume = 6, + issue = 7, + year = 1963, + pages = {396--408} +} +@Book{ComponentModel00, + author = {G Leavens and M Sitaraman (eds)}, + title = {Foundations of Component-Based Systems}, + publisher = {Cambridge University Press}, + year = 2000 +} +@Misc{Hewitt10, + author = {Carl Hewitt}, + title = {Actor Model of Computation}, + year = 2010, + note = {http://arxiv.org/abs/1008.1459} +} +@Article{Actors97, + author = {Agha,G. and Mason,I. and Smith,S. and Talcott,C.}, + title = {A foundation for actor computation}, + journal = {Journal of Functional Programming}, + volume = 7, + number = 01, + pages = {1-72}, + year = 1997 +} +@Article{SchedActivations, + author = {Anderson, Thomas E. and Bershad, Brian N. and Lazowska, Edward D. and Levy, Henry M.}, + title = {Scheduler activations: effective kernel support for the user-level management of parallelism}, + journal = {ACM Trans. Comput. Syst.}, + volume = 10, + issue = 1, + month = {February}, + year = 1992, + pages = {53--79} +} +@InProceedings{BOMinManticore, + author = {Fluet, Matthew and Rainey, Mike and Reppy, John and Shaw, Adam and Xiao, Yingqi}, + title = {Manticore: a heterogeneous parallel language}, + booktitle = {Proceedings of the 2007 workshop on Declarative aspects of multicore programming}, + series = {DAMP '07}, + year = 2007, + pages = {37--44}, + numpages = 8 +} +@TechReport{GainFromChaos_Halle_92, + author = {Halle, K.S. and Chua, Leon O. and Anishchenko, V.S. and Safonova, M.A.}, + title = {Signal Amplification via Chaos: Experimental Evidence}, + institution = {EECS Department, University of California, Berkeley}, + year = 1992, + url = {http://www.eecs.berkeley.edu/Pubs/TechRpts/1992/2223.html}, + number = {UCB/ERL M92/130} +} +@InProceedings{HotPar10_w_BLIS, + author = {Sean Halle and Albert Cohen}, + booktitle = {HOTPAR '10: USENIX Workshop on Hot Topics in Parallelism}, + month = {June}, + title = {Leveraging Semantics Attached to Function Calls to Isolate Applications from Hardware}, + year = 2010 +} +@InProceedings{HotPar11_w_Stack, + author = {Sean Halle and Albert Cohen}, + booktitle = {HOTPAR '11: USENIX Workshop on Hot Topics in Parallelism}, + month = {May}, + title = {}, + year = 2011 +} +@Article{VMS_LCPC_11, + author = {Sean Halle and Albert Cohen}, + title = {A Mutable Hardware Abstraction to Replace Threads}, + journal = {24th International Workshop on Languages and Compilers for Parallel Languages (LCPC11)}, + year = 2011 +} +@Misc{StackTechRep_10, + author = {Halle, Sean and Nadezhkin, Dmitry and Cohen, Albert}, + note = {http://www.soe.ucsc.edu/share/technical-reports/2010/ucsc-soe-10-02.pdf}, + title = {A Framework to Support Research on Portable High Performance Parallelism}, + year = 2010 +} +@Misc{CTBigStepSemTechRep_06, + author = {Halle, Sean}, + note = {http://www.soe.ucsc.edu/share/technical-reports/2006/ucsc-crl-06-11.pdf}, + title = {The Big-Step Operational Semantics of CodeTime Circuits}, + year = 2006 +} +@Misc{MentalFrameworkTechRep_06, + author = {Halle, Sean}, + note = {http://www.soe.ucsc.edu/share/technical-reports/2006/ucsc-crl-06-12.pdf}, + title = {A Mental Framework for use in Creating Hardware Independent Parallel Languages}, + year = 2006 +} +@Misc{DKUTechRep_09, + author = {Halle, Sean and Cohen, Albert}, + note = {http://www.soe.ucsc.edu/share/technical-reports/2009/ucsc-soe-09-06.pdf}, + title = {DKU Pattern for Performance Portable Parallel Software}, + year = 2009 +} +@Misc{EQNLangTechRep, + author = {Halle, Sean}, + note = {http://www.soe.ucsc.edu/share/technical-reports/2009/ucsc-soe-09-16.pdf}, + title = {An Extensible Parallel Language}, + year = 2009 +} +@Misc{CTOSTechRep, + author = {Halle, Sean}, + note = {http://www.soe.ucsc.edu/share/technical-reports/2009/ucsc-soe-09-15.pdf}, + title = {A Hardware-Independent Parallel Operating System Abstraction LayerParallelism}, + year = 2009 +} +@Misc{SideEffectsTechRep, + author = {Halle, Sean and Cohen, Albert}, + note = {http://www.soe.ucsc.edu/share/technical-reports/2009/ucsc-soe-09-14.pdf}, + title = {Parallel Language Extensions for Side Effects}, + year = 2009 +} +@Misc{BaCTiLTechRep, + author = {Halle, Sean}, + note = {http://www.soe.ucsc.edu/share/technical-reports/2006/ucsc-crl-06-08.pdf}, + title = {BaCTiL: Base CodeTime Language}, + year = 2006 +} +@Misc{CTPlatformTechRep, + author = {Halle, Sean}, + note = {http://www.soe.ucsc.edu/share/technical-reports/2006/ucsc-crl-06-09.pdf}, + title = {The Elements of the CodeTime Software Platform}, + year = 2006 +} +@Misc{CTRTTechRep, + author = {Halle, Sean}, + note = {http://www.soe.ucsc.edu/share/technical-reports/2006/ucsc-crl-06-10.pdf}, + title = {A Scalable and Efficient Peer-to-Peer Run-Time System for a Hardware Independent Software Platform}, + year = 2006 +} +@Misc{CIPTechRep, + author = {Halle, Sean}, + note = {http://www.soe.ucsc.edu/share/technical-reports/2005/ucsc-crl-05-05.pdf}, + title = {The Case for an Integrated Software Platform for HEC Illustrated Using the CodeTime Platform}, + year = 2005 +} +@Misc{Halle2008, + author = {Sean Halle and Albert Cohen}, + note = {http://omp.musictwodotoh.com}, + title = {{DKU} infrastructure server} +} +@Misc{DKUSourceForge, + author = {Sean Halle and Albert Cohen}, + month = {November}, + note = {http://dku.sourceforge.net}, + title = {{DKU} website}, + year = 2008 +} +@Misc{BLISHome, + author = {Sean Halle and Albert Cohen}, + month = {November}, + note = {http://blisplatform.sourceforge.net}, + title = {{BLIS} website}, + year = 2008 +} +@Misc{VMSHome, + author = {Sean Halle and Merten Sach and Ben Juurlink and Albert Cohen}, + note = {http://virtualizedmasterslave.org}, + title = {{VMS} Home Page}, + year = 2010 +} +@Misc{PStackHome, + author = {Sean Halle}, + note = {http://pstack.sourceforge.net}, + title = {{PStack} Home Page}, + year = 2012 +} +@Misc{DeblockingCode, + note = {http://dku.svn.sourceforge.net/viewvc/dku/branches/DKU\_C\_\_Deblocking\_\_orig/}, + title = {{DKU-ized Deblocking Filter} code} +} +@Misc{SampleBLISCode, + note = {http://dku.sourceforge.net/SampleCode.htm}, + title = {{Sample BLIS Code}} +} +@Misc{OMPHome, + note = {http://www.openmediaplatform.eu/}, + title = {{Open Media Platform} homepage} +} +@Misc{MapReduceHome, + author = {Google Corp.}, + note = {http://labs.google.com/papers/mapreduce.html}, + title = {{MapReduce} Home page} +} +@Misc{TBBHome, + author = {Intel Corp.}, + note = {http://www.threadingbuildingblocks.org}, + title = {{TBB} Home page} +} +@Misc{HPFWikipedia, + author = {Wikipedia}, + note = {http://en.wikipedia.org/wiki/High_Performance_Fortran}, + title = {{HPF} wikipedia page} +} +@Misc{OpenMPHome, + author = {{OpenMP} organization}, + note = {http://www.openmp.org}, + title = {{OpenMP} Home page} +} +@Misc{MPIHome, + author = {open-mpi organization}, + note = {http://www.open-mpi.org}, + title = {{Open MPI} Home page} +} +@Misc{OpenCLHome, + author = {Kronos Group}, + note = {http://www.khronos.org/opencl}, + title = {{OpenCL} Home page} +} +@Misc{CILKHome, + author = {Cilk group at MIT}, + note = {http://supertech.csail.mit.edu/cilk/}, + title = {{CILK} homepage} +} +@InProceedings{Fri98, + author = {M. Frigo and C. E. Leiserson and K. H. Randall}, + title = {The Implementation of the Cilk-5 Multithreaded Language}, + booktitle = {PLDI '98: Proceedings of the 1998 ACM SIGPLAN conference on Programming language design and implementation}, + pages = {212--223}, + year = 1998, + address = {Montreal, Quebec}, + month = jun +} +@Misc{TitaniumHome, + note = {http://titanium.cs.berkeley.edu}, + title = {{Titanium} homepage} +} +@InProceedings{CnCInHotPar, + author = {Knobe, Kathleen}, + booktitle = {HOTPAR '09: USENIX Workshop on Hot Topics in Parallelism}, + title = {Ease of Use with Concurrent Collections {(CnC)}}, + year = 2009 +} +@Misc{CnCHome, + author = {Intel Corp.}, + note = {http://software.intel.com/en-us/articles/intel-concurrent-collections-for-cc/}, + title = {{CnC} homepage} +} +@Misc{SpiralHome, + author = {Spiral Group at CMU}, + note = {http://www.spiral.net}, + title = {{Spiral} homepage} +} +@Misc{ScalaHome, + author = {Scala organization}, + note = {http://www.scala-lang.org/}, + title = {{Scala} homepage} +} +@Misc{UPCHome, + author = {UPC group at UC Berkeley}, + note = {http://upc.lbl.gov/}, + title = {{Unified Parallel C} homepage} +} +@Misc{SuifHome, + note = {http://suif.stanford.edu}, + title = {{Suif} Parallelizing compiler homepage} +} +@Article{SEJITS, + author = {B. Catanzaro and S. Kamil and Y. Lee and K. Asanovic and J. Demmel and K. Keutzer and J. Shalf and K. Yelick and A. Fox}, + title = {SEJITS: Getting Productivity AND Performance With Selective Embedded JIT Specialization}, + journal = {First Workshop on Programmable Models for Emerging Architecture at the 18th International Conference on Parallel Architectures and Compilation Techniques }, + year = 2009 +} +@InProceedings{Arnaldo3D, + author = {Azevedo, Arnaldo and Meenderinck, Cor and Juurlink, Ben and Terechko, Andrei and Hoogerbrugge, Jan and Alvarez, Mauricio and Ramirez, Alex}, + title = {Parallel H.264 Decoding on an Embedded Multicore Processor}, + booktitle = {HiPEAC '09: Proceedings of the 4th International Conference on High Performance Embedded Architectures and Compilers}, + year = 2009, + pages = {404--418} +} +@Article{NarayananGPUSched, + author = {Narayanan Sundaram and Anand Raghunathan and Srimat T. Chakradhar}, + title = {A framework for efficient and scalable execution of domain-specific templates on GPUs}, + journal = {International Parallel and Distributed Processing Symposium {(IPDPS)}}, + year = 2009, + pages = {1-12} +} +@InProceedings{PolyForGPU, + author = {Baskaran, Muthu Manikandan and Bondhugula, Uday and Krishnamoorthy, Sriram and Ramanujam, J. and Rountev, Atanas and Sadayappan, P.}, + title = {A compiler framework for optimization of affine loop nests for gpgpus}, + booktitle = {ICS '08: Proceedings of the 22nd annual international conference on Supercomputing}, + year = 2008, + pages = {225--234} +} +@InProceedings{Loulou08, + author = {Pouchet, Louis-No\"{e}l and Bastoul, C\'{e}dric and Cohen, Albert and Cavazos, John}, + title = {Iterative optimization in the polyhedral model: part ii, multidimensional time}, + booktitle = {ACM SIGPLAN conference on Programming language design and implementation {(PLDI)} }, + year = 2008, + pages = {90--100} +} +@InProceedings{MergeInHotPar, + author = {Michael D. Linderman and James Balfour and Teresa H. Meng and William J. Dally}, + booktitle = {HOTPAR '09: USENIX Workshop on Hot Topics in Parallelism}, + month = {March}, + title = {Embracing Heterogeneity \- Parallel Programming for Changing Hardware}, + year = 2009 +} +@InProceedings{GaloisRef, + author = {Kulkarni, Milind and Pingali, Keshav and Walter, Bruce and Ramanarayanan, Ganesh and Bala, Kavita and Chew, L. Paul}, + title = {Optimistic parallelism requires abstractions}, + booktitle = {PLDI '07: Proceedings of the 2007 ACM SIGPLAN conference on Programming language design and implementation}, + year = 2007, + pages = {211--222} +} +@Book{Allen2002, + author = {Kennedy, Ken and Allen, John R.}, + title = {Optimizing compilers for modern architectures: a dependence-based approach}, + year = 2002, + publisher = {Morgan Kaufmann Publishers Inc.} +} +@Misc{Stephens95, + author = {R. Stephens}, + title = {A Survey Of Stream Processing}, + year = 1995 +} +@InProceedings{Palatin06, + author = {P Palatin and Y Lhuillier and O Temam}, + title = {CAPSULE: Hardware-assisted parallel execution of componentbased programs}, + booktitle = {In Proceedings of the 39th Annual International Symposium on Microarchitecture}, + year = 2006, + pages = {247--258} +} +@InProceedings{Sequioa06, + author = {Fatahalian,, Kayvon and Horn,, Daniel Reiter and Knight,, Timothy J. and Leem,, Larkhoon and Houston,, Mike and Park,, Ji Young and Erez,, Mattan and Ren,, Manman and Aiken,, Alex and Dally,, William J. and Hanrahan,, Pat}, + title = {Sequoia: programming the memory hierarchy}, + booktitle = {SC '06: Proceedings of the 2006 ACM/IEEE conference on Supercomputing}, + year = 2006, + pages = 83 +} +@Book{Cole89, + author = {M Cole}, + title = {Algorithmic skeletons: Structured management of parallel computation}, + publisher = {Pitman}, + year = 1989 +} +@InProceedings{Ginhac98, + author = {Dominique Ginhac and Jocelyn Serot and Jean Pierre Derutin}, + title = {Fast prototyping of image processing applications using functional skeletons on a MIMD-DM architecture}, + booktitle = {In IAPR Workshop on Machine Vision and Applications}, + year = 1998, + pages = {468--471} +} +@InProceedings{Serot08MetaParallel, + author = {Serot, Jocelyn and Falcou, Joel}, + title = {Functional Meta-programming for Parallel Skeletons}, + booktitle = {ICCS '08: Proceedings of the 8th international conference on Computational Science, Part I}, + year = 2008, + pages = {154--163} +} +@InProceedings{Darlington93, + author = {J. Darlington and A. J. Field and P. G. Harrison and P. H. J. Kelly and D. W. N. Sharp and Q. Wu}, + title = {Parallel programming using skeleton functions}, + booktitle = {}, + year = 1993, + pages = {146--160}, + publisher = {Springer-Verlag} +} +@Article{Asanovic06BerkeleyView, + title = {{The landscape of parallel computing research: A view from berkeley}}, + author = {Asanovic, K. and Bodik, R. and Catanzaro, B.C. and Gebis, J.J. and Husbands, P. and Keutzer, K. and Patterson, D.A. and Plishker, W.L. and Shalf, J. and Williams, S.W. and others}, + journal = {Electrical Engineering and Computer Sciences, University of California at Berkeley, Technical Report No. UCB/EECS-2006-183, December}, + volume = 18, + number = {2006-183}, + pages = 19, + year = 2006 +} +@Misc{BerkeleyPattLang, + note = {http://parlab.eecs.berkeley.edu/wiki/patterns}, + title = {{Berkeley Pattern Language}} +} +@Book{Mattson04Patterns, + title = {{Patterns for parallel programming}}, + author = {Mattson, T. and Sanders, B. and Massingill, B.}, + year = 2004, + publisher = {Addison-Wesley Professional} +} +@Article{Skillicorn98, + title = {{Models and languages for parallel computation}}, + author = {Skillicorn, D.B. and Talia, D.}, + journal = {ACM Computing Surveys (CSUR)}, + volume = 30, + number = 2, + pages = {123--169}, + year = 1998 +} +@Conference{Blelloch93NESL, + title = {{Implementation of a portable nested data-parallel language}}, + author = {Blelloch, G.E. and Hardwick, J.C. and Chatterjee, S. and Sipelstein, J. and Zagha, M.}, + booktitle = {Proceedings of the fourth ACM SIGPLAN symposium on Principles and practice of parallel programming}, + pages = {102--111}, + year = 1993, + organization = {ACM New York, NY, USA} +} +@Article{McgrawSisal, + title = {{SISAL: Streams and iteration in a single assignment language: Reference manual version 1.2}}, + author = {McGraw, J. and Skedzielewski, SK and Allan, SJ and Oldehoeft, RR and Glauert, J. and Kirkham, C. and Noyce, B. and Thomas, R.}, + journal = {Manual M-146, Rev}, + volume = 1 +} +@Article{Gelernter85Linda, + title = {{Generative communication in Linda}}, + author = {Gelernter, D.}, + journal = {ACM Transactions on Programming Languages and Systems (TOPLAS)}, + volume = 7, + number = 1, + pages = {80--112}, + year = 1985 +} +@Article{Lin94ZPL, + title = {{ZPL: An array sublanguage}}, + author = {Lin, C. and Snyder, L.}, + journal = {Lecture Notes in Computer Science}, + volume = 768, + pages = {96--114}, + year = 1994 +} +@Article{baecker97, + author = {Ron Baecker and Chris DiGiano and Aaron Marcus}, + title = {Software visualization for debugging}, + journal = {Communications of the ACM}, + volume = 40, + number = 4, + year = 1997, + issn = {0001-0782}, + pages = {44--54}, + publisher = {ACM Press} +} +@Article{ball96, + author = {T. A. Ball and S. G. Eick}, + title = {Software Visualization in the Large}, + journal = {IEEE Computer}, + volume = 29, + number = 4, + year = 1996, + month = {apr}, + pages = {33--43} +} +@Book{berry89, + title = {{The chemical abstract machine}}, + author = {Berry, G. and Boudol, G.}, + year = 1989, + publisher = {ACM Press} +} +@Article{blumofe95, + author = {Robert D. Blumofe and Christopher F. Joerg and Bradley C. Kuszmaul and Charles E. Leiserson and Keith H. Randall and Yuli Zhou}, + title = {Cilk: an efficient multithreaded runtime system}, + journal = {SIGPLAN Not.}, + volume = 30, + number = 8, + year = 1995, + pages = {207--216} +} +@Article{burch90, + title = {{Symbolic model checking: 10^{20} states and beyond}}, + author = {Burch, JR and Clarke, EM and McMillan, KL and Dill, DL and Hwang, LJ}, + journal = {Logic in Computer Science, 1990. LICS'90, Proceedings}, + pages = {428--439}, + year = 1990 +} +@Article{chamberlain98, + author = {B. Chamberlain and S. Choi and E. Lewis and C. Lin and L. Snyder and W. Weathersby}, + title = {ZPL's WYSIWYG Performance Model}, + journal = {hips}, + volume = 00, + year = 1998, + isbn = {0-8186-8412-7}, + pages = 50 +} +@Article{church41, + author = {A. Church}, + title = {The Calculi of Lambda-Conversion}, + journal = {Annals of Mathematics Studies}, + number = 6, + year = 1941, + publisher = {Princeton University} +} +@Misc{CodeTimeSite, + author = {Sean Halle}, + key = {CodeTime}, + title = {Homepage for The CodeTime Parallel Software Platform}, + note = {{\ttfamily http://codetime.sourceforge.net}} +} +@Misc{CodeTimePlatform, + author = {Sean Halle}, + key = {CodeTime}, + title = {The CodeTime Parallel Software Platform}, + note = {{\ttfamily http://codetime.sourceforge.net/content/CodeTime\_Platform.pdf}} +} +@Misc{CodeTimeVS, + author = {Sean Halle}, + key = {CodeTime}, + title = {The Specification of the CodeTime Platform's Virtual Server}, + note = {{\ttfamily http://codetime.sourceforge.net/content/CodeTime\_Virtual\_Server.pdf}} +} +@Misc{CodeTimeOS, + author = {Sean Halle}, + key = {CodeTime}, + title = {A Hardware Independent OS}, + note = {{\ttfamily http://codetime.sourceforge.net/content/CodeTime\_OS.pdf}} +} +@Misc{CodeTimeSem, + author = {Sean Halle}, + key = {CodeTime}, + title = {The Big-Step Operational Semantics of the CodeTime Computational Model}, + note = {{\ttfamily http://codetime.sourceforge.net/content/CodeTime\_Semantics.pdf}} +} +@Misc{CodeTimeTh, + author = {Sean Halle}, + key = {CodeTime}, + title = {A Mental Framework for Use in Creating Hardware-Independent Parallel Languages}, + note = {{\ttfamily http://codetime.sourceforge.net/content/CodeTiime\_Theoretical\_Framework.pdf}} +} +@Misc{CodeTimeTh1, + author = {Sean Halle}, + key = {CodeTime}, + title = {The CodeTime Parallel Software Platform}, + note = {{\ttfamily http://codetime.sourceforge.net}} +} +@Misc{CodeTimeTh2, + author = {Sean Halle}, + key = {CodeTime}, + title = {The CodeTime Parallel Software Platform}, + note = {{\ttfamily http://codetime.sourceforge.net}} +} +@Misc{CodeTimeRT, + author = {Sean Halle}, + key = {CodeTime}, + title = {The CodeTime Parallel Software Platform}, + note = {{\ttfamily http://codetime.sourceforge.net}} +} +@Misc{CodeTimeWebSite, + author = {Sean Halle}, + key = {CodeTime}, + title = {The CodeTime Parallel Software Platform}, + note = {{\ttfamily http://codetime.sourceforge.net}} +} +@Misc{CodeTimeBaCTiL, + author = {Sean Halle}, + key = {CodeTime}, + title = {The Base CodeTime Language}, + note = {{\ttfamily http://codetime.sourceforge.net/content/CodeTime\_BaCTiL.pdf}} +} +@Misc{CodeTimeCert, + author = {Sean Halle}, + key = {CodeTime}, + title = {The CodeTime Certification Strategy}, + note = {{\ttfamily http://codetime.sourceforge.net/content/CodeTime\_Certification.pdf}} +} +@InProceedings{ducournau94, + author = {R. Ducournau and M. Habib and M. Huchard and M. L. Mugnier}, + title = {Proposal for a monotonic multiple inheritance linearization}, + booktitle = {OOPSLA '94: Proceedings of the ninth annual conference on Object-oriented programming systems, language, and applications}, + year = 1994, + pages = {164--175}, + publisher = {ACM Press} +} +@Article{emerson91, + title = {{Tree automata, mu-calculus and determinacy}}, + author = {Emerson, EA and Jutla, CS}, + journal = {Proceedings of the 32nd Symposium on Foundations of Computer Science}, + pages = {368--377}, + year = 1991 +} +@Article{fortune78, + title = {{Parallelism in random access machines}}, + author = {Fortune, S. and Wyllie, J.}, + journal = {STOC '78: Proceedings of the tenth annual ACM symposium on Theory of computing}, + pages = {114--118}, + year = 1978, + publisher = {ACM Press New York, NY, USA} +} +@Book{goldberg83, + title = {{Smalltalk-80: the language and its implementation}}, + author = {Goldberg, A. and Robson, D.}, + year = 1983, + publisher = {Addison-Wesley} +} +@InProceedings{goldschlager78, + author = {Leslie M. Goldschlager}, + title = {A unified approach to models of synchronous parallel machines}, + booktitle = {STOC '78: Proceedings of the tenth annual ACM symposium on Theory of computing}, + year = 1978, + pages = {89--94}, + location = {San Diego, California, United States}, + doi = {http://doi.acm.org/10.1145/800133.804336}, + publisher = {ACM Press} +} +@Book{gosling96, + author = {J. Gosling and B. Joy and G. Steele and G. Bracha}, + title = {The Java Language Specification}, + publisher = {Addison-Wesley}, + year = 1996 +} +@Article{hasselbring00, + author = {Wilhelm Hasselbring}, + title = {Programming languages and systems for prototyping concurrent applications}, + journal = {ACM Comput. Surv.}, + volume = 32, + number = 1, + year = 2000, + issn = {0360-0300}, + pages = {43--79}, + doi = {http://doi.acm.org/10.1145/349194.349199}, + publisher = {ACM Press}, + address = {New York, NY, USA} +} +@Article{hoare78, + author = {C. A. R. Hoare}, + title = {Communicating Sequential Processes}, + journal = {Communications of the ACM}, + year = 1978, + volume = 21, + number = 8, + pages = {666-677} +} +@Article{huth, + title = {{A Unifying Framework for Model Checking Labeled Kripke Structures, Modal Transition Systems, and Interval Transition Systems}}, + author = {Huth, M.}, + journal = {Proceedings of the 19th International Conference on the Foundations of Software Technology \& Theoretical Computer Science, Lecture Notes in Computer Science}, + pages = {369--380}, + publisher = {Springer-Verlag} +} +@Article{johnston04, + author = {Wesley M. Johnston and J. R. Paul Hanna and Richard J. Millar}, + title = {Advances in dataflow programming languages}, + journal = {ACM Comput. Surv.}, + volume = 36, + number = 1, + year = 2004, + issn = {0360-0300}, + pages = {1--34}, + doi = {http://doi.acm.org/10.1145/1013208.1013209}, + publisher = {ACM Press}, + address = {New York, NY, USA} +} +@Book{koelbel93, + author = {C. H. Koelbel and D. Loveman and R. Schreiber and G. Steele Jr}, + title = {High Performance Fortran Handbook}, + year = 1993, + publisher = {MIT Press} +} +@Article{kozen83, + title = {{Results on the Propositional mu-Calculus}}, + author = {Kozen, D.}, + journal = {TCS}, + volume = 27, + pages = {333--354}, + year = 1983 +} +@Article{kripke63, + title = {{Semantical analysis of modal logic}}, + author = {Kripke, S.}, + journal = {Zeitschrift fur Mathematische Logik und Grundlagen der Mathematik}, + volume = 9, + pages = {67--96}, + year = 1963 +} +@Book{mcGraw85, + author = {J McGraw and S. Skedzielewski and S. Allan and R Odefoeft}, + title = {SISAL: Streams and Iteration in a Single-Assignment Language: Reference Manual Version 1.2}, + note = {Manual M-146 Rev. 1}, + publisher = {Lawrence Livermore National Laboratory}, + year = 1985 +} +@Book{milner80, + title = {{A Calculus of Communicating Systems, volume 92 of Lecture Notes in Computer Science}}, + author = {Milner, R.}, + year = 1980, + publisher = {Springer-Verlag} +} +@Article{milner92, + title = {{A calculus of mobile processes, parts I and II}}, + author = {Milner, R. and Parrow, J. and Walker, D.}, + journal = {Information and Computation}, + volume = 100, + number = 1, + pages = {1--40 and 41--77}, + year = 1992, + publisher = {Academic Press} +} +@Book{milner99, + author = {Robin Milner}, + title = {Communicating and Mobile Systems: The pi-Calculus}, + publisher = {Cambridge University Press}, + year = 1999 +} +@Book{MPIForum94, + author = {M. P. I. Forum}, + title = {MPI: A Message-Passing Interface Standard}, + year = 1994 +} +@Article{petri62, + title = {{Fundamentals of a theory of asynchronous information flow}}, + author = {Petri, C.A.}, + journal = {Proc. IFIP Congress}, + volume = 62, + pages = {386--390}, + year = 1962 +} +@Book{pierce02, + title = {Types and Programming Languages}, + author = {Pierce, B. C.}, + year = 2002, + publisher = {MIT Press} +} +@Article{price, + author = {B. A. Price and R. M. Baecker and L. S. Small}, + title = {A Principled Taxonomy of Software Visualization}, + journal = {Journal of Visual Languages and Computing}, + volume = 4, + number = 3, + pages = {211--266} +} +@Misc{pythonWebSite, + key = {Python}, + title = {The Python Software Foundation Mission Statement}, + note = {{\ttfamily http://www.python.org/psf/mission.html}} +} +@Unpublished{reed03, + editor = {Daniel A. Reed}, + title = {Workshop on The Roadmap for the Revitalization of High-End Computing}, + day = {16--18}, + month = {jun}, + year = 2003, + note = {Available at {\ttfamily http://www.cra.org/reports/supercomputing.web.pdf}} +} +@Article{reeves84, + author = {A. P. Reeves}, + title = {Parallel Pascal -- An Extended Pascal for Parallel Computers}, + journal = {Journal of Parallel and Distributed Computing}, + volume = 1, + number = {}, + year = 1984, + month = {aug}, + pages = {64--80} +} +@Article{skillicorn98, + author = {David B. Skillicorn and Domenico Talia}, + title = {Models and languages for parallel computation}, + journal = {ACM Comput. Surv.}, + volume = 30, + number = 2, + year = 1998, + issn = {0360-0300}, + pages = {123--169}, + doi = {http://doi.acm.org/10.1145/280277.280278}, + publisher = {ACM Press}, + address = {New York, NY, USA} +} +@Article{stefik86, + title = {Object Oriented Programming: Themes and Variations}, + author = {Stefik, M. and Bobrow, D. G.}, + journal = {The AI Magazine}, + volume = 6, + number = 4, + year = 1986 +} +@Book{stirling92, + title = {{Modal and Temporal Logics}}, + author = {Stirling, C.}, + year = 1992, + publisher = {University of Edinburgh, Department of Computer Science} +} +@Misc{TitaniumWebSite, + author = {Paul Hilfinger and et. al.}, + title = {The Titanium Project Home Page}, + note = {{\ttfamily http://www.cs.berkeley.edu/projects/titanium}} +} +@Misc{turing38, + author = {A. Turing}, + note = {http://www.turingarchive.org/intro/, and http://www.turing.org.uk/sources/biblio4.html, and http://web.comlab.ox.ac.uk/oucl/research/areas/ieg/e-library/sources/tp2-ie.pdf}, + year = 1938 +} +@Book{vonNeumann45, + title = {First Draft of a Report on the EDVAC}, + author = {J. von Neumann}, + year = 1945, + publisher = {United States Army Ordnance Department} +} +@Book{winskel93, + title = {{The Formal Semantics of Programming Languages}}, + author = {Winskel, G.}, + year = 1993, + publisher = {MIT Press} +} diff -r 9b9a2497757d -r eb146c5c05a8 0__Papers/PRT/PRT__formal_def/latex/sigplanconf.cls --- /dev/null Thu Jan 01 00:00:00 1970 +0000 +++ b/0__Papers/PRT/PRT__formal_def/latex/sigplanconf.cls Sat Aug 03 19:24:22 2013 -0700 @@ -0,0 +1,1273 @@ +%----------------------------------------------------------------------------- +% +% LaTeX Class/Style File +% +% Name: sigplanconf.cls +% +% Purpose: A LaTeX 2e class file for SIGPLAN conference proceedings. +% This class file supercedes acm_proc_article-sp, +% sig-alternate, and sigplan-proc. +% +% Author: Paul C. Anagnostopoulos +% Windfall Software +% 978 371-2316 +% paul [atsign] windfall.com +% +% Created: 12 September 2004 +% +% Revisions: See end of file. +% +% This work is licensed under the Creative Commons Attribution License. +% To view a copy of this license, visit +% http://creativecommons.org/licenses/by/3.0/ +% or send a letter to Creative Commons, 171 2nd Street, Suite 300, +% San Francisco, California, 94105, U.S.A. +% +%----------------------------------------------------------------------------- + + +\NeedsTeXFormat{LaTeX2e}[1995/12/01] +\ProvidesClass{sigplanconf}[2011/11/08 v2.5 ACM SIGPLAN Proceedings] + +% The following few pages contain LaTeX programming extensions adapted +% from the ZzTeX macro package. + +% Token Hackery +% ----- ------- + + +\def \@expandaftertwice {\expandafter\expandafter\expandafter} +\def \@expandafterthrice {\expandafter\expandafter\expandafter\expandafter + \expandafter\expandafter\expandafter} + +% This macro discards the next token. + +\def \@discardtok #1{}% token + +% This macro removes the `pt' following a dimension. + +{\catcode `\p = 12 \catcode `\t = 12 + +\gdef \@remover #1pt{#1} + +} % \catcode + +% This macro extracts the contents of a macro and returns it as plain text. +% Usage: \expandafter\@defof \meaning\macro\@mark + +\def \@defof #1:->#2\@mark{#2} + +% Control Sequence Names +% ------- -------- ----- + + +\def \@name #1{% {\tokens} + \csname \expandafter\@discardtok \string#1\endcsname} + +\def \@withname #1#2{% {\command}{\tokens} + \expandafter#1\csname \expandafter\@discardtok \string#2\endcsname} + +% Flags (Booleans) +% ----- ---------- + +% The boolean literals \@true and \@false are appropriate for use with +% the \if command, which tests the codes of the next two characters. + +\def \@true {TT} +\def \@false {FL} + +\def \@setflag #1=#2{\edef #1{#2}}% \flag = boolean + +% IF and Predicates +% -- --- ---------- + +% A "predicate" is a macro that returns \@true or \@false as its value. +% Such values are suitable for use with the \if conditional. For example: +% +% \if \@oddp{\x} \else \fi + +% A predicate can be used with \@setflag as follows: +% +% \@setflag \flag = {} + +% Here are the predicates for TeX's repertoire of conditional +% commands. These might be more appropriately interspersed with +% other definitions in this module, but what the heck. +% Some additional "obvious" predicates are defined. + +\def \@eqlp #1#2{\ifnum #1 = #2\@true \else \@false \fi} +\def \@neqlp #1#2{\ifnum #1 = #2\@false \else \@true \fi} +\def \@lssp #1#2{\ifnum #1 < #2\@true \else \@false \fi} +\def \@gtrp #1#2{\ifnum #1 > #2\@true \else \@false \fi} +\def \@zerop #1{\ifnum #1 = 0\@true \else \@false \fi} +\def \@onep #1{\ifnum #1 = 1\@true \else \@false \fi} +\def \@posp #1{\ifnum #1 > 0\@true \else \@false \fi} +\def \@negp #1{\ifnum #1 < 0\@true \else \@false \fi} +\def \@oddp #1{\ifodd #1\@true \else \@false \fi} +\def \@evenp #1{\ifodd #1\@false \else \@true \fi} +\def \@rangep #1#2#3{\if \@orp{\@lssp{#1}{#2}}{\@gtrp{#1}{#3}}\@false \else + \@true \fi} +\def \@tensp #1{\@rangep{#1}{10}{19}} + +\def \@dimeqlp #1#2{\ifdim #1 = #2\@true \else \@false \fi} +\def \@dimneqlp #1#2{\ifdim #1 = #2\@false \else \@true \fi} +\def \@dimlssp #1#2{\ifdim #1 < #2\@true \else \@false \fi} +\def \@dimgtrp #1#2{\ifdim #1 > #2\@true \else \@false \fi} +\def \@dimzerop #1{\ifdim #1 = 0pt\@true \else \@false \fi} +\def \@dimposp #1{\ifdim #1 > 0pt\@true \else \@false \fi} +\def \@dimnegp #1{\ifdim #1 < 0pt\@true \else \@false \fi} + +\def \@vmodep {\ifvmode \@true \else \@false \fi} +\def \@hmodep {\ifhmode \@true \else \@false \fi} +\def \@mathmodep {\ifmmode \@true \else \@false \fi} +\def \@textmodep {\ifmmode \@false \else \@true \fi} +\def \@innermodep {\ifinner \@true \else \@false \fi} + +\long\def \@codeeqlp #1#2{\if #1#2\@true \else \@false \fi} + +\long\def \@cateqlp #1#2{\ifcat #1#2\@true \else \@false \fi} + +\long\def \@tokeqlp #1#2{\ifx #1#2\@true \else \@false \fi} +\long\def \@xtokeqlp #1#2{\expandafter\ifx #1#2\@true \else \@false \fi} + +\long\def \@definedp #1{% + \expandafter\ifx \csname \expandafter\@discardtok \string#1\endcsname + \relax \@false \else \@true \fi} + +\long\def \@undefinedp #1{% + \expandafter\ifx \csname \expandafter\@discardtok \string#1\endcsname + \relax \@true \else \@false \fi} + +\def \@emptydefp #1{\ifx #1\@empty \@true \else \@false \fi}% {\name} + +\let \@emptylistp = \@emptydefp + +\long\def \@emptyargp #1{% {#n} + \@empargp #1\@empargq\@mark} +\long\def \@empargp #1#2\@mark{% + \ifx #1\@empargq \@true \else \@false \fi} +\def \@empargq {\@empargq} + +\def \@emptytoksp #1{% {\tokenreg} + \expandafter\@emptoksp \the#1\@mark} + +\long\def \@emptoksp #1\@mark{\@emptyargp{#1}} + +\def \@voidboxp #1{\ifvoid #1\@true \else \@false \fi} +\def \@hboxp #1{\ifhbox #1\@true \else \@false \fi} +\def \@vboxp #1{\ifvbox #1\@true \else \@false \fi} + +\def \@eofp #1{\ifeof #1\@true \else \@false \fi} + + +% Flags can also be used as predicates, as in: +% +% \if \flaga \else \fi + + +% Now here we have predicates for the common logical operators. + +\def \@notp #1{\if #1\@false \else \@true \fi} + +\def \@andp #1#2{\if #1% + \if #2\@true \else \@false \fi + \else + \@false + \fi} + +\def \@orp #1#2{\if #1% + \@true + \else + \if #2\@true \else \@false \fi + \fi} + +\def \@xorp #1#2{\if #1% + \if #2\@false \else \@true \fi + \else + \if #2\@true \else \@false \fi + \fi} + +% Arithmetic +% ---------- + +\def \@increment #1{\advance #1 by 1\relax}% {\count} + +\def \@decrement #1{\advance #1 by -1\relax}% {\count} + +% Options +% ------- + + +\@setflag \@authoryear = \@false +\@setflag \@blockstyle = \@false +\@setflag \@copyrightwanted = \@true +\@setflag \@explicitsize = \@false +\@setflag \@mathtime = \@false +\@setflag \@natbib = \@true +\@setflag \@ninepoint = \@true +\newcount{\@numheaddepth} \@numheaddepth = 3 +\@setflag \@onecolumn = \@false +\@setflag \@preprint = \@false +\@setflag \@reprint = \@false +\@setflag \@tenpoint = \@false +\@setflag \@times = \@false + +% Note that all the dangerous article class options are trapped. + +\DeclareOption{9pt}{\@setflag \@ninepoint = \@true + \@setflag \@explicitsize = \@true} + +\DeclareOption{10pt}{\PassOptionsToClass{10pt}{article}% + \@setflag \@ninepoint = \@false + \@setflag \@tenpoint = \@true + \@setflag \@explicitsize = \@true} + +\DeclareOption{11pt}{\PassOptionsToClass{11pt}{article}% + \@setflag \@ninepoint = \@false + \@setflag \@explicitsize = \@true} + +\DeclareOption{12pt}{\@unsupportedoption{12pt}} + +\DeclareOption{a4paper}{\@unsupportedoption{a4paper}} + +\DeclareOption{a5paper}{\@unsupportedoption{a5paper}} + +\DeclareOption{authoryear}{\@setflag \@authoryear = \@true} + +\DeclareOption{b5paper}{\@unsupportedoption{b5paper}} + +\DeclareOption{blockstyle}{\@setflag \@blockstyle = \@true} + +\DeclareOption{cm}{\@setflag \@times = \@false} + +\DeclareOption{computermodern}{\@setflag \@times = \@false} + +\DeclareOption{executivepaper}{\@unsupportedoption{executivepaper}} + +\DeclareOption{indentedstyle}{\@setflag \@blockstyle = \@false} + +\DeclareOption{landscape}{\@unsupportedoption{landscape}} + +\DeclareOption{legalpaper}{\@unsupportedoption{legalpaper}} + +\DeclareOption{letterpaper}{\@unsupportedoption{letterpaper}} + +\DeclareOption{mathtime}{\@setflag \@mathtime = \@true} + +\DeclareOption{natbib}{\@setflag \@natbib = \@true} + +\DeclareOption{nonatbib}{\@setflag \@natbib = \@false} + +\DeclareOption{nocopyrightspace}{\@setflag \@copyrightwanted = \@false} + +\DeclareOption{notitlepage}{\@unsupportedoption{notitlepage}} + +\DeclareOption{numberedpars}{\@numheaddepth = 4} + +\DeclareOption{numbers}{\@setflag \@authoryear = \@false} + +%%%\DeclareOption{onecolumn}{\@setflag \@onecolumn = \@true} + +\DeclareOption{preprint}{\@setflag \@preprint = \@true} + +\DeclareOption{reprint}{\@setflag \@reprint = \@true} + +\DeclareOption{times}{\@setflag \@times = \@true} + +\DeclareOption{titlepage}{\@unsupportedoption{titlepage}} + +\DeclareOption{twocolumn}{\@setflag \@onecolumn = \@false} + +\DeclareOption*{\PassOptionsToClass{\CurrentOption}{article}} + +\ExecuteOptions{9pt,indentedstyle,times} +\@setflag \@explicitsize = \@false +\ProcessOptions + +\if \@onecolumn + \if \@notp{\@explicitsize}% + \@setflag \@ninepoint = \@false + \PassOptionsToClass{11pt}{article}% + \fi + \PassOptionsToClass{twoside,onecolumn}{article} +\else + \PassOptionsToClass{twoside,twocolumn}{article} +\fi +\LoadClass{article} + +\def \@unsupportedoption #1{% + \ClassError{proc}{The standard '#1' option is not supported.}} + +% This can be used with the 'reprint' option to get the final folios. + +\def \setpagenumber #1{% + \setcounter{page}{#1}} + +\AtEndDocument{\label{sigplanconf@finalpage}} + +% Utilities +% --------- + + +\newcommand{\setvspace}[2]{% + #1 = #2 + \advance #1 by -1\parskip} + +% Document Parameters +% -------- ---------- + + +% Page: + +\setlength{\hoffset}{-1in} +\setlength{\voffset}{-1in} + +\setlength{\topmargin}{1in} +\setlength{\headheight}{0pt} +\setlength{\headsep}{0pt} + +\if \@onecolumn + \setlength{\evensidemargin}{.75in} + \setlength{\oddsidemargin}{.75in} +\else + \setlength{\evensidemargin}{.75in} + \setlength{\oddsidemargin}{.75in} +\fi + +% Text area: + +\newdimen{\standardtextwidth} +\setlength{\standardtextwidth}{42pc} + +\if \@onecolumn + \setlength{\textwidth}{40.5pc} +\else + \setlength{\textwidth}{\standardtextwidth} +\fi + +\setlength{\topskip}{8pt} +\setlength{\columnsep}{2pc} +\setlength{\textheight}{54.5pc} + +% Running foot: + +\setlength{\footskip}{30pt} + +% Paragraphs: + +\if \@blockstyle + \setlength{\parskip}{5pt plus .1pt minus .5pt} + \setlength{\parindent}{0pt} +\else + \setlength{\parskip}{0pt} + \setlength{\parindent}{12pt} +\fi + +\setlength{\lineskip}{.5pt} +\setlength{\lineskiplimit}{\lineskip} + +\frenchspacing +\pretolerance = 400 +\tolerance = \pretolerance +\setlength{\emergencystretch}{5pt} +\clubpenalty = 10000 +\widowpenalty = 10000 +\setlength{\hfuzz}{.5pt} + +% Standard vertical spaces: + +\newskip{\standardvspace} +\setvspace{\standardvspace}{5pt plus 1pt minus .5pt} + +% Margin paragraphs: + +\setlength{\marginparwidth}{36pt} +\setlength{\marginparsep}{2pt} +\setlength{\marginparpush}{8pt} + + +\setlength{\skip\footins}{8pt plus 3pt minus 1pt} +\setlength{\footnotesep}{9pt} + +\renewcommand{\footnoterule}{% + \hrule width .5\columnwidth height .33pt depth 0pt} + +\renewcommand{\@makefntext}[1]{% + \noindent \@makefnmark \hspace{1pt}#1} + +% Floats: + +\setcounter{topnumber}{4} +\setcounter{bottomnumber}{1} +\setcounter{totalnumber}{4} + +\renewcommand{\fps@figure}{tp} +\renewcommand{\fps@table}{tp} +\renewcommand{\topfraction}{0.90} +\renewcommand{\bottomfraction}{0.30} +\renewcommand{\textfraction}{0.10} +\renewcommand{\floatpagefraction}{0.75} + +\setcounter{dbltopnumber}{4} + +\renewcommand{\dbltopfraction}{\topfraction} +\renewcommand{\dblfloatpagefraction}{\floatpagefraction} + +\setlength{\floatsep}{18pt plus 4pt minus 2pt} +\setlength{\textfloatsep}{18pt plus 4pt minus 3pt} +\setlength{\intextsep}{10pt plus 4pt minus 3pt} + +\setlength{\dblfloatsep}{18pt plus 4pt minus 2pt} +\setlength{\dbltextfloatsep}{20pt plus 4pt minus 3pt} + +% Miscellaneous: + +\errorcontextlines = 5 + +% Fonts +% ----- + + +\if \@times + \renewcommand{\rmdefault}{ptm}% + \if \@mathtime + \usepackage[mtbold,noTS1]{mathtime}% + \else +%%% \usepackage{mathptm}% + \fi +\else + \relax +\fi + +\if \@ninepoint + +\renewcommand{\normalsize}{% + \@setfontsize{\normalsize}{9pt}{10pt}% + \setlength{\abovedisplayskip}{5pt plus 1pt minus .5pt}% + \setlength{\belowdisplayskip}{\abovedisplayskip}% + \setlength{\abovedisplayshortskip}{3pt plus 1pt minus 2pt}% + \setlength{\belowdisplayshortskip}{\abovedisplayshortskip}} + +\renewcommand{\tiny}{\@setfontsize{\tiny}{5pt}{6pt}} + +\renewcommand{\scriptsize}{\@setfontsize{\scriptsize}{7pt}{8pt}} + +\renewcommand{\small}{% + \@setfontsize{\small}{8pt}{9pt}% + \setlength{\abovedisplayskip}{4pt plus 1pt minus 1pt}% + \setlength{\belowdisplayskip}{\abovedisplayskip}% + \setlength{\abovedisplayshortskip}{2pt plus 1pt}% + \setlength{\belowdisplayshortskip}{\abovedisplayshortskip}} + +\renewcommand{\footnotesize}{% + \@setfontsize{\footnotesize}{8pt}{9pt}% + \setlength{\abovedisplayskip}{4pt plus 1pt minus .5pt}% + \setlength{\belowdisplayskip}{\abovedisplayskip}% + \setlength{\abovedisplayshortskip}{2pt plus 1pt}% + \setlength{\belowdisplayshortskip}{\abovedisplayshortskip}} + +\renewcommand{\large}{\@setfontsize{\large}{11pt}{13pt}} + +\renewcommand{\Large}{\@setfontsize{\Large}{14pt}{18pt}} + +\renewcommand{\LARGE}{\@setfontsize{\LARGE}{18pt}{20pt}} + +\renewcommand{\huge}{\@setfontsize{\huge}{20pt}{25pt}} + +\renewcommand{\Huge}{\@setfontsize{\Huge}{25pt}{30pt}} + +\else\if \@tenpoint + +\relax + +\else + +\relax + +\fi\fi + +% Abstract +% -------- + + +\renewenvironment{abstract}{% + \section*{Abstract}% + \normalsize}{% + } + +% Bibliography +% ------------ + + +\renewenvironment{thebibliography}[1] + {\section*{\refname + \@mkboth{\MakeUppercase\refname}{\MakeUppercase\refname}}% + \list{\@biblabel{\@arabic\c@enumiv}}% + {\settowidth\labelwidth{\@biblabel{#1}}% + \leftmargin\labelwidth + \advance\leftmargin\labelsep + \@openbib@code + \usecounter{enumiv}% + \let\p@enumiv\@empty + \renewcommand\theenumiv{\@arabic\c@enumiv}}% + \bibfont + \clubpenalty4000 + \@clubpenalty \clubpenalty + \widowpenalty4000% + \sfcode`\.\@m} + {\def\@noitemerr + {\@latex@warning{Empty `thebibliography' environment}}% + \endlist} + +\if \@natbib + +\if \@authoryear + \typeout{Using natbib package with 'authoryear' citation style.} + \usepackage[authoryear,square]{natbib} + \bibpunct{[}{]}{;}{a}{}{,} % Change citation separator to semicolon, + % eliminate comma between author and year. + \let \cite = \citep +\else + \typeout{Using natbib package with 'numbers' citation style.} + \usepackage[numbers,sort&compress,square]{natbib} +\fi +\setlength{\bibsep}{3pt plus .5pt minus .25pt} + +\fi + +\def \bibfont {\small} + +% Categories +% ---------- + + +\@setflag \@firstcategory = \@true + +\newcommand{\category}[3]{% + \if \@firstcategory + \paragraph*{Categories and Subject Descriptors}% + \@setflag \@firstcategory = \@false + \else + \unskip ;\hspace{.75em}% + \fi + \@ifnextchar [{\@category{#1}{#2}{#3}}{\@category{#1}{#2}{#3}[]}} + +\def \@category #1#2#3[#4]{% + {\let \and = \relax + #1 [\textit{#2}]% + \if \@emptyargp{#4}% + \if \@notp{\@emptyargp{#3}}: #3\fi + \else + :\space + \if \@notp{\@emptyargp{#3}}#3---\fi + \textrm{#4}% + \fi}} + +% Copyright Notice +% --------- ------ + + +\def \ftype@copyrightbox {8} +\def \@toappear {} +\def \@permission {} +\def \@reprintprice {} + +\def \@copyrightspace {% + \@float{copyrightbox}[b]% + \vbox to 1in{% + \vfill + \parbox[b]{20pc}{% + \scriptsize + \if \@preprint + [Copyright notice will appear here + once 'preprint' option is removed.]\par + \else + \@toappear + \fi + \if \@reprint + \noindent Reprinted from \@conferencename, + \@proceedings, + \@conferenceinfo, + pp.~\number\thepage--\pageref{sigplanconf@finalpage}.\par + \fi}}% + \end@float} + +\long\def \toappear #1{% + \def \@toappear {#1}} + +\toappear{% + \noindent \@permission \par + \vspace{2pt} + \noindent \textsl{\@conferencename}\quad \@conferenceinfo \par + \noindent Copyright \copyright\ \@copyrightyear\ ACM \@copyrightdata + \dots \@reprintprice\par} + +\newcommand{\permission}[1]{% + \gdef \@permission {#1}} + +\permission{% + Permission to make digital or hard copies of all or + part of this work for personal or classroom use is granted without + fee provided that copies are not made or distributed for profit or + commercial advantage and that copies bear this notice and the full + citation on the first page. To copy otherwise, to republish, to + post on servers or to redistribute to lists, requires prior specific + permission and/or a fee.} + +% Here we have some alternate permission statements and copyright lines: + +\newcommand{\ACMCanadapermission}{% + \permission{% + Copyright \@copyrightyear\ Association for Computing Machinery. + ACM acknowledges that + this contribution was authored or co-authored by an affiliate of the + National Research Council of Canada (NRC). + As such, the Crown in Right of + Canada retains an equal interest in the copyright, however granting + nonexclusive, royalty-free right to publish or reproduce this article, + or to allow others to do so, provided that clear attribution + is also given to the authors and the NRC.}} + +\newcommand{\ACMUSpermission}{% + \permission{% + Copyright \@copyrightyear\ Association for + Computing Machinery. ACM acknowledges that + this contribution was authored or co-authored + by a contractor or affiliate + of the U.S. Government. As such, the Government retains a nonexclusive, + royalty-free right to publish or reproduce this article, + or to allow others to do so, for Government purposes only.}} + +\newcommand{\authorpermission}{% + \permission{% + Copyright is held by the author/owner(s).} + \toappear{% + \noindent \@permission \par + \vspace{2pt} + \noindent \textsl{\@conferencename}\quad \@conferenceinfo \par + ACM \@copyrightdata.}} + +\newcommand{\Sunpermission}{% + \permission{% + Copyright is held by Sun Microsystems, Inc.}% + \toappear{% + \noindent \@permission \par + \vspace{2pt} + \noindent \textsl{\@conferencename}\quad \@conferenceinfo \par + ACM \@copyrightdata.}} + +\newcommand{\USpublicpermission}{% + \permission{% + This paper is authored by an employee(s) of the United States + Government and is in the public domain.}% + \toappear{% + \noindent \@permission \par + \vspace{2pt} + \noindent \textsl{\@conferencename}\quad \@conferenceinfo \par + ACM \@copyrightdata.}} + +\newcommand{\reprintprice}[1]{% + \gdef \@reprintprice {#1}} + +\reprintprice{\$10.00} + +\newcommand{\authorversion}[4]{% + \permission{% + Copyright \copyright\ ACM, #1. This is the author's version of the work. + It is posted here by permission of ACM for your personal use. + Not for redistribution. The definitive version was published in + #2, #3, http://doi.acm.org/10.1145/#4.}} + +% Enunciations +% ------------ + + +\def \@begintheorem #1#2{% {name}{number} + \trivlist + \item[\hskip \labelsep \textsc{#1 #2.}]% + \itshape\selectfont + \ignorespaces} + +\def \@opargbegintheorem #1#2#3{% {name}{number}{title} + \trivlist + \item[% + \hskip\labelsep \textsc{#1\ #2}% + \if \@notp{\@emptyargp{#3}}\nut (#3).\fi]% + \itshape\selectfont + \ignorespaces} + +% Figures +% ------- + + +\@setflag \@caprule = \@true + +\long\def \@makecaption #1#2{% + \addvspace{4pt} + \if \@caprule + \hrule width \hsize height .33pt + \vspace{4pt} + \fi + \setbox \@tempboxa = \hbox{\@setfigurenumber{#1.}\nut #2}% + \if \@dimgtrp{\wd\@tempboxa}{\hsize}% + \noindent \@setfigurenumber{#1.}\nut #2\par + \else + \centerline{\box\@tempboxa}% + \fi} + +\newcommand{\nocaptionrule}{% + \@setflag \@caprule = \@false} + +\def \@setfigurenumber #1{% + {\rmfamily \bfseries \selectfont #1}} + +% Hierarchy +% --------- + + +\setcounter{secnumdepth}{\@numheaddepth} + +\newskip{\@sectionaboveskip} +\setvspace{\@sectionaboveskip}{10pt plus 3pt minus 2pt} + +\newskip{\@sectionbelowskip} +\if \@blockstyle + \setlength{\@sectionbelowskip}{0.1pt}% +\else + \setlength{\@sectionbelowskip}{4pt}% +\fi + +\renewcommand{\section}{% + \@startsection + {section}% + {1}% + {0pt}% + {-\@sectionaboveskip}% + {\@sectionbelowskip}% + {\large \bfseries \raggedright}} + +\newskip{\@subsectionaboveskip} +\setvspace{\@subsectionaboveskip}{8pt plus 2pt minus 2pt} + +\newskip{\@subsectionbelowskip} +\if \@blockstyle + \setlength{\@subsectionbelowskip}{0.1pt}% +\else + \setlength{\@subsectionbelowskip}{4pt}% +\fi + +\renewcommand{\subsection}{% + \@startsection% + {subsection}% + {2}% + {0pt}% + {-\@subsectionaboveskip}% + {\@subsectionbelowskip}% + {\normalsize \bfseries \raggedright}} + +\renewcommand{\subsubsection}{% + \@startsection% + {subsubsection}% + {3}% + {0pt}% + {-\@subsectionaboveskip} + {\@subsectionbelowskip}% + {\normalsize \bfseries \raggedright}} + +\newskip{\@paragraphaboveskip} +\setvspace{\@paragraphaboveskip}{6pt plus 2pt minus 2pt} + +\renewcommand{\paragraph}{% + \@startsection% + {paragraph}% + {4}% + {0pt}% + {\@paragraphaboveskip} + {-1em}% + {\normalsize \bfseries \if \@times \itshape \fi}} + +\renewcommand{\subparagraph}{% + \@startsection% + {subparagraph}% + {4}% + {0pt}% + {\@paragraphaboveskip} + {-1em}% + {\normalsize \itshape}} + +% Standard headings: + +\newcommand{\acks}{\section*{Acknowledgments}} + +\newcommand{\keywords}{\paragraph*{Keywords}} + +\newcommand{\terms}{\paragraph*{General Terms}} + +% Identification +% -------------- + + +\def \@conferencename {} +\def \@conferenceinfo {} +\def \@copyrightyear {} +\def \@copyrightdata {[to be supplied]} +\def \@proceedings {[Unknown Proceedings]} + + +\newcommand{\conferenceinfo}[2]{% + \gdef \@conferencename {#1}% + \gdef \@conferenceinfo {#2}} + +\newcommand{\copyrightyear}[1]{% + \gdef \@copyrightyear {#1}} + +\let \CopyrightYear = \copyrightyear + +\newcommand{\copyrightdata}[1]{% + \gdef \@copyrightdata {#1}} + +\let \crdata = \copyrightdata + +\newcommand{\proceedings}[1]{% + \gdef \@proceedings {#1}} + +% Lists +% ----- + + +\setlength{\leftmargini}{13pt} +\setlength\leftmarginii{13pt} +\setlength\leftmarginiii{13pt} +\setlength\leftmarginiv{13pt} +\setlength{\labelsep}{3.5pt} + +\setlength{\topsep}{\standardvspace} +\if \@blockstyle + \setlength{\itemsep}{1pt} + \setlength{\parsep}{3pt} +\else + \setlength{\itemsep}{1pt} + \setlength{\parsep}{3pt} +\fi + +\renewcommand{\labelitemi}{{\small \centeroncapheight{\textbullet}}} +\renewcommand{\labelitemii}{\centeroncapheight{\rule{2.5pt}{2.5pt}}} +\renewcommand{\labelitemiii}{$-$} +\renewcommand{\labelitemiv}{{\Large \textperiodcentered}} + +\renewcommand{\@listi}{% + \leftmargin = \leftmargini + \listparindent = 0pt} +%%% \itemsep = 1pt +%%% \parsep = 3pt} +%%% \listparindent = \parindent} + +\let \@listI = \@listi + +\renewcommand{\@listii}{% + \leftmargin = \leftmarginii + \topsep = 1pt + \labelwidth = \leftmarginii + \advance \labelwidth by -\labelsep + \listparindent = \parindent} + +\renewcommand{\@listiii}{% + \leftmargin = \leftmarginiii + \labelwidth = \leftmarginiii + \advance \labelwidth by -\labelsep + \listparindent = \parindent} + +\renewcommand{\@listiv}{% + \leftmargin = \leftmarginiv + \labelwidth = \leftmarginiv + \advance \labelwidth by -\labelsep + \listparindent = \parindent} + +% Mathematics +% ----------- + + +\def \theequation {\arabic{equation}} + +% Miscellaneous +% ------------- + + +\newcommand{\balancecolumns}{% + \vfill\eject + \global\@colht = \textheight + \global\ht\@cclv = \textheight} + +\newcommand{\nut}{\hspace{.5em}} + +\newcommand{\softraggedright}{% + \let \\ = \@centercr + \leftskip = 0pt + \rightskip = 0pt plus 10pt} + +% Program Code +% ------- ---- + + +\newcommand{\mono}[1]{% + {\@tempdima = \fontdimen2\font + \texttt{\spaceskip = 1.1\@tempdima #1}}} + +% Running Heads and Feet +% ------- ----- --- ---- + + +\def \@preprintfooter {} + +\newcommand{\preprintfooter}[1]{% + \gdef \@preprintfooter {#1}} + +\if \@preprint + +\def \ps@plain {% + \let \@mkboth = \@gobbletwo + \let \@evenhead = \@empty + \def \@evenfoot {\scriptsize + \rlap{\textit{\@preprintfooter}}\hfil + \thepage \hfil + \llap{\textit{\@formatyear}}}% + \let \@oddhead = \@empty + \let \@oddfoot = \@evenfoot} + +\else\if \@reprint + +\def \ps@plain {% + \let \@mkboth = \@gobbletwo + \let \@evenhead = \@empty + \def \@evenfoot {\scriptsize \hfil \thepage \hfil}% + \let \@oddhead = \@empty + \let \@oddfoot = \@evenfoot} + +\else + +\let \ps@plain = \ps@empty +\let \ps@headings = \ps@empty +\let \ps@myheadings = \ps@empty + +\fi\fi + +\def \@formatyear {% + \number\year/\number\month/\number\day} + +% Special Characters +% ------- ---------- + + +\DeclareRobustCommand{\euro}{% + \protect{\rlap{=}}{\sf \kern .1em C}} + +% Title Page +% ----- ---- + + +\@setflag \@addauthorsdone = \@false + +\def \@titletext {\@latex@error{No title was provided}{}} +\def \@subtitletext {} + +\newcount{\@authorcount} + +\newcount{\@titlenotecount} +\newtoks{\@titlenotetext} + +\def \@titlebanner {} + +\renewcommand{\title}[1]{% + \gdef \@titletext {#1}} + +\newcommand{\subtitle}[1]{% + \gdef \@subtitletext {#1}} + +\newcommand{\authorinfo}[3]{% {names}{affiliation}{email/URL} + \global\@increment \@authorcount + \@withname\gdef {\@authorname\romannumeral\@authorcount}{#1}% + \@withname\gdef {\@authoraffil\romannumeral\@authorcount}{#2}% + \@withname\gdef {\@authoremail\romannumeral\@authorcount}{#3}} + +\renewcommand{\author}[1]{% + \@latex@error{The \string\author\space command is obsolete; + use \string\authorinfo}{}} + +\newcommand{\titlebanner}[1]{% + \gdef \@titlebanner {#1}} + +\renewcommand{\maketitle}{% + \pagestyle{plain}% + \if \@onecolumn + {\hsize = \standardtextwidth + \@maketitle}% + \else + \twocolumn[\@maketitle]% + \fi + \@placetitlenotes + \if \@copyrightwanted \@copyrightspace \fi} + +\def \@maketitle {% + \begin{center} + \@settitlebanner + \let \thanks = \titlenote + {\leftskip = 0pt plus 0.25\linewidth + \rightskip = 0pt plus 0.25 \linewidth + \parfillskip = 0pt + \spaceskip = .7em + \noindent \LARGE \bfseries \@titletext \par} + \vskip 6pt + \noindent \Large \@subtitletext \par + \vskip 12pt + \ifcase \@authorcount + \@latex@error{No authors were specified for this paper}{}\or + \@titleauthors{i}{}{}\or + \@titleauthors{i}{ii}{}\or + \@titleauthors{i}{ii}{iii}\or + \@titleauthors{i}{ii}{iii}\@titleauthors{iv}{}{}\or + \@titleauthors{i}{ii}{iii}\@titleauthors{iv}{v}{}\or + \@titleauthors{i}{ii}{iii}\@titleauthors{iv}{v}{vi}\or + \@titleauthors{i}{ii}{iii}\@titleauthors{iv}{v}{vi}% + \@titleauthors{vii}{}{}\or + \@titleauthors{i}{ii}{iii}\@titleauthors{iv}{v}{vi}% + \@titleauthors{vii}{viii}{}\or + \@titleauthors{i}{ii}{iii}\@titleauthors{iv}{v}{vi}% + \@titleauthors{vii}{viii}{ix}\or + \@titleauthors{i}{ii}{iii}\@titleauthors{iv}{v}{vi}% + \@titleauthors{vii}{viii}{ix}\@titleauthors{x}{}{}\or + \@titleauthors{i}{ii}{iii}\@titleauthors{iv}{v}{vi}% + \@titleauthors{vii}{viii}{ix}\@titleauthors{x}{xi}{}\or + \@titleauthors{i}{ii}{iii}\@titleauthors{iv}{v}{vi}% + \@titleauthors{vii}{viii}{ix}\@titleauthors{x}{xi}{xii}% + \else + \@latex@error{Cannot handle more than 12 authors}{}% + \fi + \vspace{1.75pc} + \end{center}} + +\def \@settitlebanner {% + \if \@andp{\@preprint}{\@notp{\@emptydefp{\@titlebanner}}}% + \vbox to 0pt{% + \vskip -32pt + \noindent \textbf{\@titlebanner}\par + \vss}% + \nointerlineskip + \fi} + +\def \@titleauthors #1#2#3{% + \if \@andp{\@emptyargp{#2}}{\@emptyargp{#3}}% + \noindent \@setauthor{40pc}{#1}{\@false}\par + \else\if \@emptyargp{#3}% + \noindent \@setauthor{17pc}{#1}{\@false}\hspace{3pc}% + \@setauthor{17pc}{#2}{\@false}\par + \else + \noindent \@setauthor{12.5pc}{#1}{\@false}\hspace{2pc}% + \@setauthor{12.5pc}{#2}{\@false}\hspace{2pc}% + \@setauthor{12.5pc}{#3}{\@true}\par + \relax + \fi\fi + \vspace{20pt}} + +\def \@setauthor #1#2#3{% {width}{text}{unused} + \vtop{% + \def \and {% + \hspace{16pt}} + \hsize = #1 + \normalfont + \centering + \large \@name{\@authorname#2}\par + \vspace{5pt} + \normalsize \@name{\@authoraffil#2}\par + \vspace{2pt} + \textsf{\@name{\@authoremail#2}}\par}} + +\def \@maybetitlenote #1{% + \if \@andp{#1}{\@gtrp{\@authorcount}{3}}% + \titlenote{See page~\pageref{@addauthors} for additional authors.}% + \fi} + +\newtoks{\@fnmark} + +\newcommand{\titlenote}[1]{% + \global\@increment \@titlenotecount + \ifcase \@titlenotecount \relax \or + \@fnmark = {\ast}\or + \@fnmark = {\dagger}\or + \@fnmark = {\ddagger}\or + \@fnmark = {\S}\or + \@fnmark = {\P}\or + \@fnmark = {\ast\ast}% + \fi + \,$^{\the\@fnmark}$% + \edef \reserved@a {\noexpand\@appendtotext{% + \noexpand\@titlefootnote{\the\@fnmark}}}% + \reserved@a{#1}} + +\def \@appendtotext #1#2{% + \global\@titlenotetext = \expandafter{\the\@titlenotetext #1{#2}}} + +\newcount{\@authori} + +\iffalse +\def \additionalauthors {% + \if \@gtrp{\@authorcount}{3}% + \section{Additional Authors}% + \label{@addauthors}% + \noindent + \@authori = 4 + {\let \\ = ,% + \loop + \textbf{\@name{\@authorname\romannumeral\@authori}}, + \@name{\@authoraffil\romannumeral\@authori}, + email: \@name{\@authoremail\romannumeral\@authori}.% + \@increment \@authori + \if \@notp{\@gtrp{\@authori}{\@authorcount}} \repeat}% + \par + \fi + \global\@setflag \@addauthorsdone = \@true} +\fi + +\let \addauthorsection = \additionalauthors + +\def \@placetitlenotes { + \the\@titlenotetext} + +% Utilities +% --------- + + +\newcommand{\centeroncapheight}[1]{% + {\setbox\@tempboxa = \hbox{#1}% + \@measurecapheight{\@tempdima}% % Calculate ht(CAP) - ht(text) + \advance \@tempdima by -\ht\@tempboxa % ------------------ + \divide \@tempdima by 2 % 2 + \raise \@tempdima \box\@tempboxa}} + +\newbox{\@measbox} + +\def \@measurecapheight #1{% {\dimen} + \setbox\@measbox = \hbox{ABCDEFGHIJKLMNOPQRSTUVWXYZ}% + #1 = \ht\@measbox} + +\long\def \@titlefootnote #1#2{% + \insert\footins{% + \reset@font\footnotesize + \interlinepenalty\interfootnotelinepenalty + \splittopskip\footnotesep + \splitmaxdepth \dp\strutbox \floatingpenalty \@MM + \hsize\columnwidth \@parboxrestore +%%% \protected@edef\@currentlabel{% +%%% \csname p@footnote\endcsname\@thefnmark}% + \color@begingroup + \def \@makefnmark {$^{#1}$}% + \@makefntext{% + \rule\z@\footnotesep\ignorespaces#2\@finalstrut\strutbox}% + \color@endgroup}} + +% LaTeX Modifications +% ----- ------------- + +\def \@seccntformat #1{% + \@name{\the#1}% + \@expandaftertwice\@seccntformata \csname the#1\endcsname.\@mark + \quad} + +\def \@seccntformata #1.#2\@mark{% + \if \@emptyargp{#2}.\fi} + +% Revision History +% -------- ------- + + +% Date Person Ver. Change +% ---- ------ ---- ------ + +% 2004.09.12 PCA 0.1--5 Preliminary development. + +% 2004.11.18 PCA 0.5 Start beta testing. + +% 2004.11.19 PCA 0.6 Obsolete \author and replace with +% \authorinfo. +% Add 'nocopyrightspace' option. +% Compress article opener spacing. +% Add 'mathtime' option. +% Increase text height by 6 points. + +% 2004.11.28 PCA 0.7 Add 'cm/computermodern' options. +% Change default to Times text. + +% 2004.12.14 PCA 0.8 Remove use of mathptm.sty; it cannot +% coexist with latexsym or amssymb. + +% 2005.01.20 PCA 0.9 Rename class file to sigplanconf.cls. + +% 2005.03.05 PCA 0.91 Change default copyright data. + +% 2005.03.06 PCA 0.92 Add at-signs to some macro names. + +% 2005.03.07 PCA 0.93 The 'onecolumn' option defaults to '11pt', +% and it uses the full type width. + +% 2005.03.15 PCA 0.94 Add at-signs to more macro names. +% Allow margin paragraphs during review. + +% 2005.03.22 PCA 0.95 Implement \euro. +% Remove proof and newdef environments. + +% 2005.05.06 PCA 1.0 Eliminate 'onecolumn' option. +% Change footer to small italic and eliminate +% left portion if no \preprintfooter. +% Eliminate copyright notice if preprint. +% Clean up and shrink copyright box. + +% 2005.05.30 PCA 1.1 Add alternate permission statements. + +% 2005.06.29 PCA 1.1 Publish final first edition of guide. + +% 2005.07.14 PCA 1.2 Add \subparagraph. +% Use block paragraphs in lists, and adjust +% spacing between items and paragraphs. + +% 2006.06.22 PCA 1.3 Add 'reprint' option and associated +% commands. + +% 2006.08.24 PCA 1.4 Fix bug in \maketitle case command. + +% 2007.03.13 PCA 1.5 The title banner only displays with the +% 'preprint' option. + +% 2007.06.06 PCA 1.6 Use \bibfont in \thebibliography. +% Add 'natbib' option to load and configure +% the natbib package. + +% 2007.11.20 PCA 1.7 Balance line lengths in centered article +% title (thanks to Norman Ramsey). + +% 2009.01.26 PCA 1.8 Change natbib \bibpunct values. + +% 2009.03.24 PCA 1.9 Change natbib to use the 'numbers' option. +% Change templates to use 'natbib' option. + +% 2009.09.01 PCA 2.0 Add \reprintprice command (suggested by +% Stephen Chong). + +% 2009.09.08 PCA 2.1 Make 'natbib' the default; add 'nonatbib'. +% SB Add 'authoryear' and 'numbers' (default) to +% control citation style when using natbib. +% Add \bibpunct to change punctuation for +% 'authoryear' style. + +% 2009.09.21 PCA 2.2 Add \softraggedright to the thebibliography +% environment. Also add to template so it will +% happen with natbib. + +% 2009.09.30 PCA 2.3 Remove \softraggedright from thebibliography. +% Just include in the template. + +% 2010.05.24 PCA 2.4 Obfuscate author's email address. + +% 2011.11.08 PCA 2.5 Add copyright notice to this file. +% Remove 'sort' option from natbib when using +% 'authoryear' style. +% Add the \authorversion command. + diff -r 9b9a2497757d -r eb146c5c05a8 0__Papers/PRT/PRT__formal_def/latex/url.sty --- /dev/null Thu Jan 01 00:00:00 1970 +0000 +++ b/0__Papers/PRT/PRT__formal_def/latex/url.sty Sat Aug 03 19:24:22 2013 -0700 @@ -0,0 +1,325 @@ +% url.sty ver 1.4 02-Mar-1999 Donald Arseneau asnd@triumf.ca +% Copyright 1996-1999 Donald Arseneau, Vancouver, Canada. +% This program can be used, distributed, and modified under the terms +% of the LaTeX Project Public License. +% +% A form of \verb that allows linebreaks at certain characters or +% combinations of characters, accepts reconfiguration, and can usually +% be used in the argument to another command. It is intended for email +% addresses, hypertext links, directories/paths, etc., which normally +% have no spaces. The font may be selected using the \urlstyle command, +% and new url-like commands can be defined using \urldef. +% +% Usage: Conditions: +% \url{ } If the argument contains any "%", "#", or "^^", or ends with +% "\", it can't be used in the argument to another command. +% The argument must not contain unbalanced braces. +% \url| | ...where "|" is any character not used in the argument and not +% "{" or a space. The same restrictions as above except that the +% argument may contain unbalanced braces. +% \xyz for "\xyz" a defined-url; this can be used anywhere, no matter +% what characters it contains. +% +% See further instructions after "\endinput" +% +\def\Url@ttdo{% style assignments for tt fonts or T1 encoding +\def\UrlBreaks{\do\.\do\@\do\\\do\/\do\!\do\_\do\|\do\%\do\;\do\>\do\]% + \do\)\do\,\do\?\do\'\do\+\do\=}% +\def\UrlBigBreaks{\do\:\do@url@hyp}% +\def\UrlNoBreaks{\do\(\do\[\do\{\do\<}% (unnecessary) +\def\UrlSpecials{\do\ {\ }}% +\def\UrlOrds{\do\*\do\-\do\~}% any ordinary characters that aren't usually +} +\def\Url@do{% style assignments for OT1 fonts except tt +\def\UrlBreaks{\do\.\do\@\do\/\do\!\do\%\do\;\do\]\do\)\do\,\do\?\do\+\do\=}% +\def\UrlBigBreaks{\do\:\do@url@hyp}% +\def\UrlNoBreaks{\do\(\do\[\do\{}% prevents breaks after *next* character +\def\UrlSpecials{\do\<{\langle}\do\>{\mathbin{\rangle}}\do\_{\_% + \penalty\@m}\do\|{\mid}\do\{{\lbrace}\do\}{\mathbin{\rbrace}}\do + \\{\mathbin{\backslash}}\do\~{\raise.6ex\hbox{\m@th$\scriptstyle\sim$}}\do + \ {\ }}% +\def\UrlOrds{\do\'\do\"\do\-}% +} +\def\url@ttstyle{% +\@ifundefined{selectfont}{\def\UrlFont{\tt}}{\def\UrlFont{\ttfamily}}\Url@ttdo +} +\def\url@rmstyle{% +\@ifundefined{selectfont}{\def\UrlFont{\rm}}{\def\UrlFont{\rmfamily}}\Url@do +} +\def\url@sfstyle{% +\@ifundefined{selectfont}{\def\UrlFont{\sf}}{\def\UrlFont{\sffamily}}\Url@do +} +\def\url@samestyle{\ifdim\fontdimen\thr@@\font=\z@ \url@ttstyle \else + \url@rmstyle \fi \def\UrlFont{}} + +\@ifundefined{strip@prefix}{\def\strip@prefix#1>{}}{} +\@ifundefined{verbatim@nolig@list}{\def\verbatim@nolig@list{\do\`}}{} + +\def\Url{% + \begingroup \let\url@moving\relax\relax \endgroup + \ifmmode\@nomatherr$\fi + \UrlFont $\fam\z@ \textfont\z@\font + \let\do\@makeother \dospecials % verbatim catcodes + \catcode`{\@ne \catcode`}\tw@ \catcode`\ 10 % except braces and spaces + \medmuskip0mu \thickmuskip\medmuskip \thinmuskip\medmuskip + \@tempcnta\fam\multiply\@tempcnta\@cclvi + \let\do\set@mathcode \UrlOrds % ordinary characters that were special + \advance\@tempcnta 8192 \UrlBreaks % bin + \advance\@tempcnta 4096 \UrlBigBreaks % rel + \advance\@tempcnta 4096 \UrlNoBreaks % open + \let\do\set@mathact \UrlSpecials % active + \let\do\set@mathnolig \verbatim@nolig@list % prevent ligatures + \@ifnextchar\bgroup\Url@z\Url@y} + +\def\Url@y#1{\catcode`{11 \catcode`}11 + \def\@tempa##1#1{\Url@z{##1}}\@tempa} +\def\Url@z#1{\def\@tempa{#1}\expandafter\expandafter\expandafter\Url@Hook + \expandafter\strip@prefix\meaning\@tempa\UrlRight\m@th$\endgroup} +\def\Url@Hook{\UrlLeft} +\let\UrlRight\@empty +\let\UrlLeft\@empty + +\def\set@mathcode#1{\count@`#1\advance\count@\@tempcnta\mathcode`#1\count@} +\def\set@mathact#1#2{\mathcode`#132768 \lccode`\~`#1\lowercase{\def~{#2}}} +\def\set@mathnolig#1{\ifnum\mathcode`#1<32768 + \lccode`\~`#1\lowercase{\edef~{\mathchar\number\mathcode`#1_{\/}}}% + \mathcode`#132768 \fi} + +\def\urldef#1#2{\begingroup \setbox\z@\hbox\bgroup + \def\Url@z{\Url@def{#1}{#2}}#2} +\expandafter\ifx\csname DeclareRobustCommand\endcsname\relax + \def\Url@def#1#2#3{\m@th$\endgroup\egroup\endgroup + \def#1{#2{#3}}} +\else + \def\Url@def#1#2#3{\m@th$\endgroup\egroup\endgroup + \DeclareRobustCommand{#1}{#2{#3}}} +\fi + +\def\urlstyle#1{\csname url@#1style\endcsname} + +% Sample (and default) configuration: +% +\newcommand\url{\begingroup \Url} +% +% picTeX defines \path, so declare it optionally: +\@ifundefined{path}{\newcommand\path{\begingroup \urlstyle{tt}\Url}}{} +% +% too many styles define \email like \address, so I will not define it. +% \newcommand\email{\begingroup \urlstyle{rm}\Url} + +% Process LaTeX \package options +% +\urlstyle{tt} +\let\Url@sppen\@M +\def\do@url@hyp{}% by default, no breaks after hyphens + +\@ifundefined{ProvidesPackage}{}{ + \ProvidesPackage{url}[1999/03/02 \space ver 1.4 \space + Verb mode for urls, email addresses, and file names] + \DeclareOption{hyphens}{\def\do@url@hyp{\do\-}}% allow breaks after hyphens + \DeclareOption{obeyspaces}{\let\Url@Hook\relax}% a flag for later + \DeclareOption{spaces}{\let\Url@sppen\relpenalty} + \DeclareOption{T1}{\let\Url@do\Url@ttdo} + \ProcessOptions +\ifx\Url@Hook\relax % [obeyspaces] was declared + \def\Url@Hook#1\UrlRight\m@th{\edef\@tempa{\noexpand\UrlLeft + \Url@retain#1\Url@nosp\, }\@tempa\UrlRight\m@th} + \def\Url@retain#1 {#1\penalty\Url@sppen\ \Url@retain} + \def\Url@nosp\,#1\Url@retain{} +\fi +} + +\edef\url@moving{\csname Url Error\endcsname} +\expandafter\edef\url@moving + {\csname url used in a moving argument.\endcsname} +\expandafter\expandafter\expandafter \let \url@moving\undefined + +\endinput +% +% url.sty ver 1.4 02-Mar-1999 Donald Arseneau asnd@reg.triumf.ca +% +% This package defines "\url", a form of "\verb" that allows linebreaks, +% and can often be used in the argument to another command. It can be +% configured to print in different formats, and is particularly useful for +% hypertext links, email addresses, directories/paths, etc. The font may +% be selected using the "\urlstyle" command and pre-defined text can be +% stored with the "\urldef" command. New url-like commands can be defined, +% and a "\path" command is provided this way. +% +% Usage: Conditions: +% \url{ } If the argument contains any "%", "#", or "^^", or ends with +% "\", it can't be used in the argument to another command. +% The argument must not contain unbalanced braces. +% \url| | ...where "|" is any character not used in the argument and not +% "{" or a space. The same restrictions as above except that the +% argument may contain unbalanced braces. +% \xyz for "\xyz" a defined-url; this can be used anywhere, no matter +% what characters it contains. +% +% The "\url" command is fragile, and its argument is likely to be very +% fragile, but a defined-url is robust. +% +% Package Option: obeyspaces +% Ordinarily, all spaces are ignored in the url-text. The "[obeyspaces]" +% option allows spaces, but may introduce spurious spaces when a url +% containing "\" characters is given in the argument to another command. +% So if you need to obey spaces you can say "\usepackage[obeyspaces]{url}", +% and if you need both spaces and backslashes, use a `defined-url' for +% anything with "\". +% +% Package Option: hyphens +% Ordinarily, breaks are not allowed after "-" characters because this +% leads to confusion. (Is the "-" part of the address or just a hyphen?) +% The package option "[hyphens]" allows breaks after explicit hyphen +% characters. The "\url" command will *never ever* hyphenate words. +% +% Package Option: spaces +% Likewise, breaks are not usually allowed after spaces under the +% "[obeyspaces]" option, but giving the options "[obeyspaces,spaces]" +% will allow breaks at those spaces. +% +% Package Option: T1 +% This signifies that you will be using T1-encoded fonts which contain +% some characters missing from most older (OT1) encoded TeX fonts. This +% changes the default definition for "\urlstyle{rm}". +% +% Defining a defined-url: +% Take for example the email address "myself%node@gateway.net" which could +% not be given (using "\url" or "\verb") in a caption or parbox due to the +% percent sign. This address can be predefined with +% \urldef{\myself}\url{myself%node@gateway.net} or +% \urldef{\myself}\url|myself%node@gateway.net| +% and then you may use "\myself" instead of "\url{myself%node@gateway.net}" +% in an argument, and even in a moving argument like a caption because a +% defined-url is robust. +% +% Style: +% You can switch the style of printing using "\urlstyle{tt}", where "tt" +% can be any defined style. The pre-defined styles are "tt", "rm", "sf", +% and "same" which all allow the same linebreaks but different fonts -- +% the first three select a specific font and the "same" style uses the +% current text font. You can define your own styles with different fonts +% and/or line-breaking by following the explanations below. The "\url" +% command follows whatever the currently-set style dictates. +% +% Alternate commands: +% It may be desireable to have different things treated differently, each +% in a predefined style; e.g., if you want directory paths to always be +% in tt and email addresses to be rm, then you would define new url-like +% commands as follows: +% +% \newcommand\email{\begingroup \urlstyle{rm}\Url} +% \newcommand\directory{\begingroup \urlstyle{tt}\Url} +% +% You must follow this format closely, and NOTE that the final command is +% "\Url", not "\url". In fact, the "\directory" example is exactly the +% "\path" definition which is pre-defined in the package. If you look +% above, you will see that "\url" is defined with +% \newcommand\url{\begingroup \Url} +% I.e., using whatever url-style has been selected. +% +% You can make a defined-url for these other styles, using the usual +% "\urldef" command as in this example: +% +% \urldef{\myself}{\email}{myself%node.domain@gateway.net} +% +% which makes "\myself" act like "\email{myself%node.domain@gateway.net}", +% if the "\email" command is defined as above. The "\myself" command +% would then be robust. +% +% Defining styles: +% Before describing how to customize the printing style, it is best to +% mention something about the unusual implementation of "\url". Although +% the material is textual in nature, and the font specification required +% is a text-font command, the text is actually typeset in *math* mode. +% This allows the context-sensitive linebreaking, but also accounts for +% the default behavior of ignoring spaces. Now on to defining styles. +% +% To change the font or the list of characters that allow linebreaks, you +% could redefine the commands "\UrlFont", "\UrlBreaks", "\UrlSpecials" etc. +% directly in the document, but it is better to define a new `url-style' +% (following the example of "\url@ttstyle" and "\url@rmstyle") which defines +% all of "\UrlBigbreaks", "\UrlNoBreaks", "\UrlBreaks", "\UrlSpecials", and +% "\UrlFont". +% +% Changing font: +% The "\UrlFont" command selects the font. The definition of "\UrlFont" +% done by the pre-defined styles varies to cope with a variety of LaTeX +% font selection schemes, but it could be as simple as "\def\UrlFont{\tt}". +% Depending on the font selected, some characters may need to be defined +% in the "\UrlSpecials" list because many fonts don't contain all the +% standard input characters. +% +% Changing linebreaks: +% The list of characters that allow line-breaks is given by "\UrlBreaks" +% and "\UrlBigBreaks", which have the format "\do\c" for character "c". +% The differences are that `BigBreaks' have a lower penalty and have +% different breakpoints when in sequence (as in "http://"): `BigBreaks' +% are treated as mathrels while `Breaks' are mathbins (see The TeXbook, +% p.170). In particular, a series of `BigBreak' characters will break at +% the end and only at the end; a series of `Break' characters will break +% after the first and after every following *pair*; there will be no +% break after a `Break' character if a `BigBreak' follows. In the case +% of "http://" it doesn't matter whether ":" is a `Break' or `BigBreak' -- +% the breaks are the same in either case; but for DECnet nodes with "::" +% it is important to prevent breaks *between* the colons, and that is why +% colons are `BigBreaks'. +% +% It is possible for characters to prevent breaks after the next following +% character (I use this for parentheses). Specify these in "\UrlNoBreaks". +% +% You can do arbitrarily complex things with characters by making them +% active in math mode (mathcode hex-8000) and specifying the definition(s) +% in "\UrlSpecials". This is used in the rm and sf styles for OT1 font +% encoding to handle several characters that are not present in those +% computer-modern style fonts. See the definition of "\Url@do", which +% is used by both "\url@rmstyle" and "\url@sfstyle"; it handles missing +% characters via "\UrlSpecials". The nominal format for setting each +% special character "c" is: "\do\c{}", but you can include +% other definitions too. +% +% +% If all this sounds confusing ... well, it is! But I hope you won't need +% to redefine breakpoints -- the default assignments seem to work well for +% a wide variety of applications. If you do need to make changes, you can +% test for breakpoints using regular math mode and the characters "+=(a". +% +% Yet more flexibility: +% You can also customize the verbatim text by defining "\UrlRight" and/or +% "\UrlLeft", e.g., for ISO formatting of urls surrounded by "< >", define +% +% \renewcommand\url{\begingroup \def\UrlLeft{}% +% \urlstyle{tt}\Url} +% +% The meanings of "\UrlLeft" and "\UrlRight" are *not* reproduced verbatim. +% This lets you use formatting commands there, but you must be careful not +% to use TeX's special characters ("\^_%~#$&{}" etc.) improperly. +% You can also define "\UrlLeft" to reprocess the verbatim text, but the +% format of the definition is special: +% +% \def\UrlLeft#1\UrlRight{ ... do things with #1 ... } +% +% Yes, that is "#1" followed by "\UrlRight" then the definition. For +% example, to put a hyperTeX hypertext link in the DVI file: +% +% \def\UrlLeft#1\UrlRight{\special{html:}#1\special{html:}} +% +% Using this technique, url.sty can provide a convenient interface for +% performing various operations on verbatim text. You don't even need +% to print out the argument! For greatest efficiency in such obscure +% applications, you can define a null url-style where all the lists like +% "\UrlBreaks" are empty. +% +% Revision History: +% ver 1.1 6-Feb-1996: +% Fix hyphens that wouldn't break and ligatures that weren't suppressed. +% ver 1.2 19-Oct-1996: +% Package option for T1 encoding; Hooks: "\UrlLeft" and "\UrlRight". +% ver 1.3 21-Jul-1997: +% Prohibit spaces as delimiter characters; change ascii tilde in OT1. +% ver 1.4 02-Mar-1999 +% LaTeX license; moving-argument-error +% The End + +Test file integrity: ASCII 32-57, 58-126: !"#$%&'()*+,-./0123456789 +:;<=>?@ABCDEFGHIJKLMNOPQRSTUVWXYZ[\]^_`abcdefghijklmnopqrstuvwxyz{|}~ diff -r 9b9a2497757d -r eb146c5c05a8 0__Papers/PRT/PRT__formal_def/latex/usetex-v1-anon.cls --- /dev/null Thu Jan 01 00:00:00 1970 +0000 +++ b/0__Papers/PRT/PRT__formal_def/latex/usetex-v1-anon.cls Sat Aug 03 19:24:22 2013 -0700 @@ -0,0 +1,363 @@ +\NeedsTeXFormat{LaTeX2e} +\ProvidesClass{usetex-v1-anon}[2002/10/31 v1.2 usetex Usenix article class] + +% usetex-v1.cls - to be used with LaTeX2e for Usenix articles +% +% To use this style file, do this: +% +% \documentclass{usetex-v1} +% +% The following definitions are modifications of standard article.cls +% definitions, arranged to do a better job of matching the Usenix +% guidelines. and make for convenient Usenix paper writing +% +% Choose the appropriate option: +% +% 1. workingdraft: +% +% For initial submission and shepherding. Features prominent +% date, notice of draft status, page numbers, and annotation +% facilities. +% +% 2. proof: +% +% A galley proof identical to the final copy except for page +% numbering and proof date on the bottom. Annotations are +% removed. +% +% 3. webversion: +% +% A web-publishable version, uses \docstatus{} to indicate +% publication information (where and when paper was published), +% and page numbers. +% +% 4. finalversion: +% +% The final camera-ready-copy (CRC) version of the paper. +% Published in conference proceedings. This doesn't include +% page numbers, annotations, or draft status (Usenix adds +% headers, footers, and page numbers onto the CRC). +% +% If several are used, the last one in this list wins +% + +% +% In addition, the option "endnotes" permits the use of the +% otherwise-disabled, Usenix-deprecated footnote{} command in +% documents. In this case, be sure to include a +% \makeendnotes command at the end of your document or +% the endnotes will not actually appear. +% + +\newif\if@draftcopy \newif\ifworkingdraft +\DeclareOption{workingdraft}{\workingdrafttrue\@draftcopytrue} +\newif\ifproof \DeclareOption{proof}{\prooftrue\@draftcopytrue} +\newif\ifwebversion +\DeclareOption{webversion}{\prooftrue\webversiontrue\@draftcopytrue} +\DeclareOption{finalversion}{} +\newif\ifhasendnotes +\DeclareOption{endnotes}{\hasendnotestrue} + +% pass all other options to the article class +\DeclareOption*{% + \PassOptionsToClass{\CurrentOption}{article}% +} + +% actually process the options +\ProcessOptions + +% usetex is based on article +\LoadClass[twocolumn]{article} + +% Footnotes are not currently allowed, but +% endnotes (while a bad idea) are. +\ifhasendnotes + \RequirePackage{endnotes} +\fi + +% save any provided document status information +\def\@docstatus{} +\def\docstatus#1{\gdef\@docstatus{#1}} + +\ifworkingdraft + + % formatting helper for draft notes + \newcommand{\@noteleader[1]}{% + {\marginpar{\framebox{\scriptsize\textbf{#1}}}}% + \bfseries\itshape + } + + % put a small anonymous editing note in the draft copy + \newcommand{\edannote}[1]{{\@noteleader[note] (#1)}} + + % put a small attributed editing note in the draft copy + \newcommand{\edatnote}[2]{{\@noteleader[#1] #2}} + + % put an attributed editing note paragraph in the draft copy + \newenvironment{ednote}[1] + {\newcommand{\who}{#1}\@noteleader[\who]} + + % mark a spot where work has been left off for later + \newcommand{\HERE}{% + {\mbox{}\marginpar{\framebox{\textbf{here}}}}{\bf\ldots}} + +\else + + % dummy versions of editing commands to produce warnings + + \newcommand{\edannote}[1]{\@latex@warning + {Leftover edannote command in final version ignored}} + + \newcommand{\edatnote}[1]{\@latex@warning + {Leftover edatnote command in final version ignored}} + + \newsavebox{\@discard} + \newenvironment{ednote}[1]{\@latex@warning + {Leftover ednote environment in final version ignored}% + \begin{lrbox}{\@discard}}{\end{lrbox}} + + \newcommand{\HERE}{\@latex@warning + {Leftover HERE command in final version ignored}} + +\fi + +% set up the footers appropriately +\def\@setfoot{% + \ifwebversion + % webversions get whatever status the author says + \gdef\@evenfoot{\@docstatus \hfil \thepage}% + \else + % all other drafts get the standard draft footer + \gdef\@evenfoot{\textbf{Draft:} \@draftdate\hfil \textbf{Page:} \thepage}% + \fi + \gdef\@oddfoot{\@evenfoot}% +} + +% +% Usenix wants no page numbers for submitted papers, so that +% they can number them themselves. Drafts should have +% numbered pages, so they can be edited. +% +\if@draftcopy + % Compute a date and time for the draft for use + % either in \@setfoot (proof) or in \maketitle (workingdraft) + % + % Time code adapted from custom-bib/makebst.tex + % Copyright 1993-1999 Patrick W Daly + % Max-Planck-Institut f\"ur Aeronomie + % E-mail: daly@linmp.mpg.de + \newcount\hour + \hour=\time + \divide\hour by 60 + \newcount\minute + \minute=\hour + \multiply\minute by 60 + \advance\minute by -\time + \multiply\minute by -1 + \newcommand{\@draftdate} + {{\the\year/\/\two@digits{\the\month}/\/\two@digits{\the\day}% + ~\two@digits{\the\hour}:\two@digits{\the\minute}}} + \pagestyle{plain} + \@setfoot +\else + \pagestyle{empty} +\fi + +% Times-Roman font is nice if you can get it (requires NFSS, +% which is in latex2e). +\usepackage{times} + +% endnote support, as described at +% http://www.lyx.org/help/footnotes.php +\ifhasendnotes + \typeout + {Warning: endnotes support is deprecated (see documentation for details)} + \let\footnote=\endnote + \def\enoteformat{\rightskip\z@ \leftskip\z@ + \parindent=0pt\parskip=\baselineskip + \@theenmark. } + \newcommand{\makeendnotes}{ + \begingroup + \def\enotesize{\normalsize} + \theendnotes + \endgroup + } +\else + \long\gdef\footnote{\@latex@error + {Deprecated footnote command (see documentation for details)}} + \long\gdef\endnote{\@latex@error + {Deprecated endnote command (see documentation for details)}} +\fi + +% +% Usenix margins +% Gives active areas of 6.45" x 9.0" +% +\setlength{\textheight}{9.0in} +\setlength{\columnsep}{0.25in} +\setlength{\textwidth}{6.45in} +%\setlength{\footskip}{0.0in} +%\setlength{\footheight}{0.0in} +\setlength{\topmargin}{0.0in} +\setlength{\headheight}{0.0in} +\setlength{\headsep}{0.0in} +\setlength{\evensidemargin}{0.0in} +\setlength{\oddsidemargin}{0.0in} +\setlength{\marginparsep}{1.5em} +\setlength{\marginparwidth}{0.35in} + +% The standard maketitle insists on +% messing with the style of the first page. +% Thus, we will wrap maketitle with code to put +% things right again. +\let \save@maketitle=\maketitle +\def\maketitle{ + \save@maketitle + \if@draftcopy + \@specialpagefalse + \else + \thispagestyle{empty} + \fi +} + +% +% Usenix titles are in 14-point bold type, with no date, and with no +% change in the empty page headers. The author section is +% 12 point roman and italic: see below. +% +\def\@maketitle{% + \newpage + \null +% \vskip 3ex% + \begin{center}% +% \let \footnote \thanks + {\Large \bf \@title \par}% % use 14 pt bold +% \vskip 2ex% + {\large +% \lineskip .5ex% +% \begin{tabular}[t]{c}% +% \@author +% \end{tabular}\par + }% + \ifworkingdraft + \vskip 0.5ex + \textbf{Draft of \@draftdate} + \vskip 0.5ex + \fi + \ifwebversion + \vskip 0.5ex + \textit{Authors and affiliation elided for review.} + \vskip 0.5ex + \fi + \end{center}% + \par +% \vskip 2ex +} + +% +% The author section +% should have names in Roman, address in +% italic, e-mail/http in typewriter. +% This is enforced by use of these macros +% +\def\authname#1{{#1}\\} +\def\authaddr#1{\itshape{#1}\\} +\def\authurl#1{{\normalsize #1}\\} + +% +% The abstract is preceded by a 12-pt bold centered heading +% +\def\abstract{\begin{center}% + {\large\bf \abstractname\vspace{-.5ex}\vspace{\z@}}% + \end{center}} +\def\endabstract{} + +% +% Main section titles are 12-pt bold. Lower divisions can +% be same size or smaller: we choose same. +% Main section leading is tight. Subsection leading is even +% slightly tighter. All lower divisions are formatted like subsections. +% +\newcommand\@sectionfont{\reset@font\large\bf} +\newlength\@sectionaboveskip +\setlength\@sectionaboveskip{-0.7\baselineskip + plus -0.1\baselineskip + minus -0.1\baselineskip} +\newlength\@sectionbelowskip +\setlength\@sectionbelowskip{0.3\baselineskip + plus 0.1\baselineskip} +\newlength\@subsectionaboveskip +\setlength\@subsectionaboveskip{-0.5\baselineskip + plus -0.1\baselineskip} +\renewcommand\section{\@startsection {section}{1}{\z@}% + {\@sectionaboveskip}{\@sectionbelowskip}{\@sectionfont}} +\newcommand\@gensubsection[2]{\@startsection {#1}{#2}{\z@}% + {\@subsectionaboveskip}{\@sectionbelowskip}{\@sectionfont}} +\renewcommand\subsection{\@gensubsection{subsection}{2}} +\renewcommand\subsubsection{\@gensubsection{subsubsection}{3}} +%\renewcommand\paragraph{\@gensubsection{paragraph}{4}} +%\renewcommand\subparagraph{\@gensubsection{subparagaph}{5}} +\renewcommand\paragraph{\@startsection{paragraph}{4}{\z@}% + {1.25ex \@plus 0.2ex \@minus 0.2ex}% + {-1.0em}% + {\normalfont\normalsize\bfseries}} +\renewcommand\subparagraph{\@startsection{subparagraph}{5}{\parindent}% + {1.25ex \@plus 0.2ex \@minus 0.2ex}% + {-1.0em}% + {\normalfont\normalsize\bfseries}} + +% List items need to be tightened up. +% There must be a better way than copying +% the definitions to modify the list environment... +\def\@itemspacings{\listparindent=\parindent + \parsep=0pt\topsep=0.3\baselineskip\partopsep=0pt\itemsep=0pt} +% now make envs use itemspacings +\def\itemize{% + \ifnum \@itemdepth >\thr@@\@toodeep\else + \advance\@itemdepth\@ne + \edef\@itemitem{labelitem\romannumeral\the\@itemdepth}% + \expandafter + \list + \csname\@itemitem\endcsname + {\@itemspacings\def\makelabel##1{\hss\llap{##1}}}% + \fi} +\def\enumerate{% + \ifnum \@enumdepth >\thr@@\@toodeep\else + \advance\@enumdepth\@ne + \edef\@enumctr{enum\romannumeral\the\@enumdepth}% + \expandafter + \list + \csname label\@enumctr\endcsname + {\@itemspacings\usecounter\@enumctr\def\makelabel##1{\hss\llap{##1}}}% + \fi} +\def\description{% + \list{}{\labelwidth\z@ \itemindent-\leftmargin + \@itemspacings\let\makelabel\descriptionlabel}} + +% Bibliography items need to be tightened up. +% Again, there must be a better way than copying +% the definitions to modify the list environment... +\def\thebibliography#1% + {\section*{\refname}% + \@mkboth{\MakeUppercase\refname}{\MakeUppercase\refname}% + \list{\@biblabel{\@arabic\c@enumiv}}% + {\settowidth\labelwidth{\@biblabel{#1}}% + \leftmargin\labelwidth + \advance\leftmargin\labelsep + \@openbib@code + \usecounter{enumiv}% + \let\p@enumiv\@empty + \renewcommand\theenumiv{\@arabic\c@enumiv}% + \parsep=0pt}% pack entries + \sloppy + \hbadness=8000% mostly don't whine about bibliography fmt + \clubpenalty=4000% + \@clubpenalty=\clubpenalty + \widowpenalty=4000% + \sfcode`\.\@m} + +% Floating bodies need to be tightened up. +\setlength\textfloatsep{14pt plus 2pt} +\setlength\dbltextfloatsep{\textfloatsep} +\setlength\intextsep{0.8\textfloatsep} +\setlength\abovecaptionskip{8pt minus 2pt} diff -r 9b9a2497757d -r eb146c5c05a8 0__Papers/PRT/PRT__formal_def/latex/usetex-v1.cls --- /dev/null Thu Jan 01 00:00:00 1970 +0000 +++ b/0__Papers/PRT/PRT__formal_def/latex/usetex-v1.cls Sat Aug 03 19:24:22 2013 -0700 @@ -0,0 +1,357 @@ +\NeedsTeXFormat{LaTeX2e} +\ProvidesClass{usetex-v1}[2002/10/31 v1.2 usetex Usenix article class] + +% usetex-v1.cls - to be used with LaTeX2e for Usenix articles +% +% To use this style file, do this: +% +% \documentclass{usetex-v1} +% +% The following definitions are modifications of standard article.cls +% definitions, arranged to do a better job of matching the Usenix +% guidelines. and make for convenient Usenix paper writing +% +% Choose the appropriate option: +% +% 1. workingdraft: +% +% For initial submission and shepherding. Features prominent +% date, notice of draft status, page numbers, and annotation +% facilities. +% +% 2. proof: +% +% A galley proof identical to the final copy except for page +% numbering and proof date on the bottom. Annotations are +% removed. +% +% 3. webversion: +% +% A web-publishable version, uses \docstatus{} to indicate +% publication information (where and when paper was published), +% and page numbers. +% +% 4. finalversion: +% +% The final camera-ready-copy (CRC) version of the paper. +% Published in conference proceedings. This doesn't include +% page numbers, annotations, or draft status (Usenix adds +% headers, footers, and page numbers onto the CRC). +% +% If several are used, the last one in this list wins +% + +% +% In addition, the option "endnotes" permits the use of the +% otherwise-disabled, Usenix-deprecated footnote{} command in +% documents. In this case, be sure to include a +% \makeendnotes command at the end of your document or +% the endnotes will not actually appear. +% + +\newif\if@draftcopy \newif\ifworkingdraft +\DeclareOption{workingdraft}{\workingdrafttrue\@draftcopytrue} +\newif\ifproof \DeclareOption{proof}{\prooftrue\@draftcopytrue} +\newif\ifwebversion +\DeclareOption{webversion}{\prooftrue\webversiontrue\@draftcopytrue} +\DeclareOption{finalversion}{} +\newif\ifhasendnotes +\DeclareOption{endnotes}{\hasendnotestrue} + +% pass all other options to the article class +\DeclareOption*{% + \PassOptionsToClass{\CurrentOption}{article}% +} + +% actually process the options +\ProcessOptions + +% usetex is based on article +\LoadClass[twocolumn]{article} + +% Footnotes are not currently allowed, but +% endnotes (while a bad idea) are. +\ifhasendnotes + \RequirePackage{endnotes} +\fi + +% save any provided document status information +\def\@docstatus{} +\def\docstatus#1{\gdef\@docstatus{#1}} + +\ifworkingdraft + + % formatting helper for draft notes + \newcommand{\@noteleader[1]}{% + {\marginpar{\framebox{\scriptsize\textbf{#1}}}}% + \bfseries\itshape + } + + % put a small anonymous editing note in the draft copy + \newcommand{\edannote}[1]{{\@noteleader[note] (#1)}} + + % put a small attributed editing note in the draft copy + \newcommand{\edatnote}[2]{{\@noteleader[#1] #2}} + + % put an attributed editing note paragraph in the draft copy + \newenvironment{ednote}[1] + {\newcommand{\who}{#1}\@noteleader[\who]} + + % mark a spot where work has been left off for later + \newcommand{\HERE}{% + {\mbox{}\marginpar{\framebox{\textbf{here}}}}{\bf\ldots}} + +\else + + % dummy versions of editing commands to produce warnings + + \newcommand{\edannote}[1]{\@latex@warning + {Leftover edannote command in final version ignored}} + + \newcommand{\edatnote}[1]{\@latex@warning + {Leftover edatnote command in final version ignored}} + + \newsavebox{\@discard} + \newenvironment{ednote}[1]{\@latex@warning + {Leftover ednote environment in final version ignored}% + \begin{lrbox}{\@discard}}{\end{lrbox}} + + \newcommand{\HERE}{\@latex@warning + {Leftover HERE command in final version ignored}} + +\fi + +% set up the footers appropriately +\def\@setfoot{% + \ifwebversion + % webversions get whatever status the author says + \gdef\@evenfoot{\@docstatus \hfil \thepage}% + \else + % all other drafts get the standard draft footer + \gdef\@evenfoot{\textbf{Draft:} \@draftdate\hfil \textbf{Page:} \thepage}% + \fi + \gdef\@oddfoot{\@evenfoot}% +} + +% +% Usenix wants no page numbers for submitted papers, so that +% they can number them themselves. Drafts should have +% numbered pages, so they can be edited. +% +\if@draftcopy + % Compute a date and time for the draft for use + % either in \@setfoot (proof) or in \maketitle (workingdraft) + % + % Time code adapted from custom-bib/makebst.tex + % Copyright 1993-1999 Patrick W Daly + % Max-Planck-Institut f\"ur Aeronomie + % E-mail: daly@linmp.mpg.de + \newcount\hour + \hour=\time + \divide\hour by 60 + \newcount\minute + \minute=\hour + \multiply\minute by 60 + \advance\minute by -\time + \multiply\minute by -1 + \newcommand{\@draftdate} + {{\the\year/\/\two@digits{\the\month}/\/\two@digits{\the\day}% + ~\two@digits{\the\hour}:\two@digits{\the\minute}}} + \pagestyle{plain} + \@setfoot +\else + \pagestyle{empty} +\fi + +% Times-Roman font is nice if you can get it (requires NFSS, +% which is in latex2e). +\usepackage{times} + +% endnote support, as described at +% http://www.lyx.org/help/footnotes.php +\ifhasendnotes + \typeout + {Warning: endnotes support is deprecated (see documentation for details)} + \let\footnote=\endnote + \def\enoteformat{\rightskip\z@ \leftskip\z@ + \parindent=0pt\parskip=\baselineskip + \@theenmark. } + \newcommand{\makeendnotes}{ + \begingroup + \def\enotesize{\normalsize} + \theendnotes + \endgroup + } +\else + \long\gdef\footnote{\@latex@error + {Deprecated footnote command (see documentation for details)}} + \long\gdef\endnote{\@latex@error + {Deprecated endnote command (see documentation for details)}} +\fi + +% +% Usenix margins +% Gives active areas of 6.45" x 9.0" +% +\setlength{\textheight}{9.0in} +\setlength{\columnsep}{0.25in} +\setlength{\textwidth}{6.45in} +%\setlength{\footskip}{0.0in} +%\setlength{\footheight}{0.0in} +\setlength{\topmargin}{0.0in} +\setlength{\headheight}{0.0in} +\setlength{\headsep}{0.0in} +\setlength{\evensidemargin}{0.0in} +\setlength{\oddsidemargin}{0.0in} +\setlength{\marginparsep}{1.5em} +\setlength{\marginparwidth}{0.35in} + +% The standard maketitle insists on +% messing with the style of the first page. +% Thus, we will wrap maketitle with code to put +% things right again. +\let \save@maketitle=\maketitle +\def\maketitle{ + \save@maketitle + \if@draftcopy + \@specialpagefalse + \else + \thispagestyle{empty} + \fi +} + +% +% Usenix titles are in 14-point bold type, with no date, and with no +% change in the empty page headers. The author section is +% 12 point roman and italic: see below. +% +\def\@maketitle{% + \newpage + \null + \vskip 3ex% + \begin{center}% + \let \footnote \thanks + {\Large \bf \@title \par}% % use 14 pt bold + \vskip 2ex% + {\large + \lineskip .5ex% + \begin{tabular}[t]{c}% + \@author + \end{tabular}\par}% + \ifworkingdraft + \vskip 3ex \textbf{Draft of \@draftdate} \vskip 3ex + \fi + \ifwebversion + \vskip 3ex \textbf{\@docstatus} \vskip 3ex + \fi + \end{center}% + \par + \vskip 2ex} + +% +% The author section +% should have names in Roman, address in +% italic, e-mail/http in typewriter. +% This is enforced by use of these macros +% +\def\authname#1{{#1}\\} +\def\authaddr#1{\itshape{#1}\\} +\def\authurl#1{{\normalsize #1}\\} + +% +% The abstract is preceded by a 12-pt bold centered heading +% +\def\abstract{\begin{center}% + {\large\bf \abstractname\vspace{-.5ex}\vspace{\z@}}% + \end{center}} +\def\endabstract{} + +% +% Main section titles are 12-pt bold. Lower divisions can +% be same size or smaller: we choose same. +% Main section leading is tight. Subsection leading is even +% slightly tighter. All lower divisions are formatted like subsections. +% +\newcommand\@sectionfont{\reset@font\large\bf} +\newlength\@sectionaboveskip +\setlength\@sectionaboveskip{-0.7\baselineskip + plus -0.1\baselineskip + minus -0.1\baselineskip} +\newlength\@sectionbelowskip +\setlength\@sectionbelowskip{0.3\baselineskip + plus 0.1\baselineskip} +\newlength\@subsectionaboveskip +\setlength\@subsectionaboveskip{-0.5\baselineskip + plus -0.1\baselineskip} +\renewcommand\section{\@startsection {section}{1}{\z@}% + {\@sectionaboveskip}{\@sectionbelowskip}{\@sectionfont}} +\newcommand\@gensubsection[2]{\@startsection {#1}{#2}{\z@}% + {\@subsectionaboveskip}{\@sectionbelowskip}{\@sectionfont}} +\renewcommand\subsection{\@gensubsection{subsection}{2}} +\renewcommand\subsubsection{\@gensubsection{subsubsection}{3}} +%\renewcommand\paragraph{\@gensubsection{paragraph}{4}} +%\renewcommand\subparagraph{\@gensubsection{subparagaph}{5}} +\renewcommand\paragraph{\@startsection{paragraph}{4}{\z@}% + {1.25ex \@plus 0.2ex \@minus 0.2ex}% + {-1.0em}% + {\normalfont\normalsize\bfseries}} +\renewcommand\subparagraph{\@startsection{subparagraph}{5}{\parindent}% + {1.25ex \@plus 0.2ex \@minus 0.2ex}% + {-1.0em}% + {\normalfont\normalsize\bfseries}} + +% List items need to be tightened up. +% There must be a better way than copying +% the definitions to modify the list environment... +\def\@itemspacings{\listparindent=\parindent + \parsep=0pt\topsep=0.3\baselineskip\partopsep=0pt\itemsep=0pt} +% now make envs use itemspacings +\def\itemize{% + \ifnum \@itemdepth >\thr@@\@toodeep\else + \advance\@itemdepth\@ne + \edef\@itemitem{labelitem\romannumeral\the\@itemdepth}% + \expandafter + \list + \csname\@itemitem\endcsname + {\@itemspacings\def\makelabel##1{\hss\llap{##1}}}% + \fi} +\def\enumerate{% + \ifnum \@enumdepth >\thr@@\@toodeep\else + \advance\@enumdepth\@ne + \edef\@enumctr{enum\romannumeral\the\@enumdepth}% + \expandafter + \list + \csname label\@enumctr\endcsname + {\@itemspacings\usecounter\@enumctr\def\makelabel##1{\hss\llap{##1}}}% + \fi} +\def\description{% + \list{}{\labelwidth\z@ \itemindent-\leftmargin + \@itemspacings\let\makelabel\descriptionlabel}} + +% Bibliography items need to be tightened up. +% Again, there must be a better way than copying +% the definitions to modify the list environment... +\def\thebibliography#1% + {\section*{\refname}% + \@mkboth{\MakeUppercase\refname}{\MakeUppercase\refname}% + \list{\@biblabel{\@arabic\c@enumiv}}% + {\settowidth\labelwidth{\@biblabel{#1}}% + \leftmargin\labelwidth + \advance\leftmargin\labelsep + \@openbib@code + \usecounter{enumiv}% + \let\p@enumiv\@empty + \renewcommand\theenumiv{\@arabic\c@enumiv}% + \parsep=0pt}% pack entries + \sloppy + \hbadness=8000% mostly don't whine about bibliography fmt + \clubpenalty=4000% + \@clubpenalty=\clubpenalty + \widowpenalty=4000% + \sfcode`\.\@m} + +% Floating bodies need to be tightened up. +\setlength\textfloatsep{14pt plus 2pt} +\setlength\dbltextfloatsep{\textfloatsep} +\setlength\intextsep{0.8\textfloatsep} +\setlength\abovecaptionskip{8pt minus 2pt} diff -r 9b9a2497757d -r eb146c5c05a8 0__Papers/VMS/Pics_from_talks/13_Ap_12__Arbab_proto_runtime__whiteboard.jpg Binary file 0__Papers/VMS/Pics_from_talks/13_Ap_12__Arbab_proto_runtime__whiteboard.jpg has changed diff -r 9b9a2497757d -r eb146c5c05a8 0__Papers/VMS/Pics_from_talks/13_Ap_12__Arbab_whiteboard_timelines_tie_points.jpg Binary file 0__Papers/VMS/Pics_from_talks/13_Ap_12__Arbab_whiteboard_timelines_tie_points.jpg has changed diff -r 9b9a2497757d -r eb146c5c05a8 0__Papers/VMS/VMS__Foundation_Paper/VMS__Full_conference_version/figures/PR__system_level_activity.svg --- /dev/null Thu Jan 01 00:00:00 1970 +0000 +++ b/0__Papers/VMS/VMS__Foundation_Paper/VMS__Full_conference_version/figures/PR__system_level_activity.svg Sat Aug 03 19:24:22 2013 -0700 @@ -0,0 +1,2923 @@ + + + + + + + + + + + + + + + + + image/svg+xml + + + + + + + Master(runtime system)on core 1 + + + Seed VP(created atapp startup,on core 1) + + Application Code + Seed_Fn + Work_Fn + Language Wrapper-LibCode + Proto-RuntimePrimitiveCode + Lang Handlerfor create VP + Assigner Fn + Instances of runtime system(data structson heap) + Instances ofVirtual Processors(data structson heap) + + create VPwrapper Fn + Call to dyn lib + + Top Level Fn + Top Level Fn + Top Level Fn + + + + + + + end VPwrapper Fn + + + + + + + + + + + suspendand switchto runtime + + returnfromsuspend + PR primitive Fnto send request + normal call + + suspendand switchto runtime + Mutex Acquirewrapper Fn + + + end VPwrapper Fn + + + + + + + + + suspendand switchto runtime + returnfromsuspend + normal call + + suspendand switchto runtime + + + normal call + normal call + + + + + + + + + + Timeline of SeedVP + suspend + resume + end + Proto-RuntimePrimitiveCode + PR primitive Fnto create VP + + + + VP 1(created byapplication,on core 2) + + + Master Fn + + + + + + suspendand switchto app VP + + + + start + + + + Timeline of VP 1 + suspend + resume + + start + + + + Timeline of Master on core 1 + suspend + resume + + start + + + Call to dyn lib + Call to dyn lib + Call to dyn lib + call to dyn lib + + + Master(runtime system)on core 2 + + + + + Master Fn + + + + Timeline of Master on core 2 + + + + + return fromsuspend + + PR primitive Fnto send request + PR primitive Fnto send request + PR primitive Fnto send request + + + end + + + + resume + resume + suspend + start + resume + Language PluginCode + Proto-RuntimeMasterCode + + + + + + + + call via Ptr to Dyn Lib Fn + + call via Ptr to Dyn Lib Fn + Lang Handlerfor acq Mutex + + + + + + + Assigner Fn + + + + + suspendand switchto app VP + + + return fromsuspend + + + + + + call via Ptr to Dyn Lib Fn + + call via Ptr to Dyn Lib Fn + core 1 + core 2 + + + + return fromsuspend + + + + return fromsuspend + + + PR OS thread(core1) + + + Main OS thread + + main + Lang Handlerfor create VP + Assigner Fn + + PR_start() + Call to dyn lib + + Top Level Fn + birth Fn + + + + + + end VPwrapper Fn + + + + + + + + + suspendand switchto runtime + + returnfromsuspend + PR__start() + normal call + + suspendand switchto runtime + normal call + + + + + + + + + + Timeline of SeedVP + suspend + resume + end + PR primitive Fnto create VP + Master Fn + + + + + + suspendand switchto app VP + + + + start + + + + Timeline of Master on core 1 + suspend + resume + + start + + + Call to dyn lib + call to dyn lib + + + + return fromsuspend + + PR primitive Fnto send request + resume + + + + + + + + call via Ptr to Dyn Lib Fn + + call via Ptr to Dyn Lib Fn + + + core 1 + + + + return fromsuspend + + PR OS thread(core 2) + + + + + diff -r 9b9a2497757d -r eb146c5c05a8 0__Papers/VMS/VMS__Foundation_Paper/VMS__Full_conference_version/figures/PR__timeline_dual.pdf Binary file 0__Papers/VMS/VMS__Foundation_Paper/VMS__Full_conference_version/figures/PR__timeline_dual.pdf has changed diff -r 9b9a2497757d -r eb146c5c05a8 0__Papers/VMS/VMS__Foundation_Paper/VMS__Full_conference_version/figures/PR__timeline_dual.svg --- /dev/null Thu Jan 01 00:00:00 1970 +0000 +++ b/0__Papers/VMS/VMS__Foundation_Paper/VMS__Full_conference_version/figures/PR__timeline_dual.svg Sat Aug 03 19:24:22 2013 -0700 @@ -0,0 +1,446 @@ + + + + + + + + + + + + + + + + image/svg+xml + + + + + + + + + + Suspend(Point 2.S) + + + + Resume (Point 2.R) + + Timeline B + + + Physical time + + + + Suspend(Point 1.S) + + + + Resume (Point 1.R) + + Timeline A + + + + + + + Suspend(Point 2.S) + + + + Resume (Point 2.R) + + Timeline B + + + Physical time + + + + Suspend(Point 1.S) + + + + Resume (Point 1.R) + + Timeline A + + + + diff -r 9b9a2497757d -r eb146c5c05a8 0__Papers/VMS/VMS__Foundation_Paper/VMS__Full_conference_version/figures/PR__timeline_dual_2nd.pdf Binary file 0__Papers/VMS/VMS__Foundation_Paper/VMS__Full_conference_version/figures/PR__timeline_dual_2nd.pdf has changed diff -r 9b9a2497757d -r eb146c5c05a8 0__Papers/VMS/VMS__Foundation_Paper/VMS__Full_conference_version/figures/PR__timeline_dual_2nd.svg --- /dev/null Thu Jan 01 00:00:00 1970 +0000 +++ b/0__Papers/VMS/VMS__Foundation_Paper/VMS__Full_conference_version/figures/PR__timeline_dual_2nd.svg Sat Aug 03 19:24:22 2013 -0700 @@ -0,0 +1,545 @@ + + + + + + + + + + + + + + + + image/svg+xml + + + + + + + + + + Suspend(Point 2.S) + + + + Resume (Point 2.R) + + Timeline B + + + Physical time + + + + Suspend(Point 1.S) + + + + Resume (Point 1.R) + + Timeline A + + + + + + Tied Point + + Timeline B + + + + + Tied Point + + Timeline A + + + + + + + + + + Timeline B + + + + + Suspend(Point 1.S) + + + + Resume (Point 1.R) + + Timeline A + + + + visible + NOT visible + + + visible + NOT visible + + diff -r 9b9a2497757d -r eb146c5c05a8 0__Papers/VMS/VMS__Foundation_Paper/VMS__Full_conference_version/figures/PR__timeline_dual_three_versions.svg --- /dev/null Thu Jan 01 00:00:00 1970 +0000 +++ b/0__Papers/VMS/VMS__Foundation_Paper/VMS__Full_conference_version/figures/PR__timeline_dual_three_versions.svg Sat Aug 03 19:24:22 2013 -0700 @@ -0,0 +1,754 @@ + + + + + + + + + + + + + + + + + + + + + + image/svg+xml + + + + + + + + + + Suspend(Point 2.S) + + + + Resume (Point 2.R) + + Timeline B + + + Physical time + + + + Suspend(Point 1.S) + + + + Resume (Point 1.R) + + Timeline A + + + + + Suspend(Point 2.S) + + Resume (Point 2.R) + Timeline B + + + Physical time + + + + Suspend(Point 1.S) + + + + Resume (Point 1.R) + + Timeline A + + + + + + + + + Suspend(Point 2.S) + + Resume (Point 2.R) + Timeline B + + + Physical time + + + + Suspend(Point 1.S) + + + + Resume (Point 1.R) + + Timeline A + + + + + + + + + + + + HiddenTimeline + comm + comm + control + control + + diff -r 9b9a2497757d -r eb146c5c05a8 0__Papers/VMS/VMS__Foundation_Paper/VMS__Full_conference_version/figures/PR__timeline_dual_w_hidden.pdf Binary file 0__Papers/VMS/VMS__Foundation_Paper/VMS__Full_conference_version/figures/PR__timeline_dual_w_hidden.pdf has changed diff -r 9b9a2497757d -r eb146c5c05a8 0__Papers/VMS/VMS__Foundation_Paper/VMS__Full_conference_version/figures/PR__timeline_dual_w_hidden.svg --- /dev/null Thu Jan 01 00:00:00 1970 +0000 +++ b/0__Papers/VMS/VMS__Foundation_Paper/VMS__Full_conference_version/figures/PR__timeline_dual_w_hidden.svg Sat Aug 03 19:24:22 2013 -0700 @@ -0,0 +1,366 @@ + + + + + + + + + + + + + + + + + + + + + + image/svg+xml + + + + + + + + + Suspend(Point 2.S) + + Resume (Point 2.R) + Timeline B + + + Physical time + + + + Suspend(Point 1.S) + + + + Resume (Point 1.R) + + Timeline A + + + + + + + HiddenTimeline + comm + comm + control + control + + diff -r 9b9a2497757d -r eb146c5c05a8 0__Papers/VMS/VMS__Foundation_Paper/VMS__Full_conference_version/figures/PR__timeline_single.pdf Binary file 0__Papers/VMS/VMS__Foundation_Paper/VMS__Full_conference_version/figures/PR__timeline_single.pdf has changed diff -r 9b9a2497757d -r eb146c5c05a8 0__Papers/VMS/VMS__Foundation_Paper/VMS__Full_conference_version/figures/PR__timeline_single.svg --- /dev/null Thu Jan 01 00:00:00 1970 +0000 +++ b/0__Papers/VMS/VMS__Foundation_Paper/VMS__Full_conference_version/figures/PR__timeline_single.svg Sat Aug 03 19:24:22 2013 -0700 @@ -0,0 +1,306 @@ + + + + + + + + + + + + + + + + image/svg+xml + + + + + + + + Physical time + + + + Suspend(Point 1.S) + + + + Resume (Point 1.R) + + Timeline A + + + Physical time + + + + Suspend(Point 1.S) + + + + Resume (Point 1.R) + + Timeline A + + + + + Hiddenmeta-comm + + diff -r 9b9a2497757d -r eb146c5c05a8 0__Papers/VMS/VMS__Foundation_Paper/VMS__Full_conference_version/figures/PR__timeline_sync_def.pdf Binary file 0__Papers/VMS/VMS__Foundation_Paper/VMS__Full_conference_version/figures/PR__timeline_sync_def.pdf has changed diff -r 9b9a2497757d -r eb146c5c05a8 0__Papers/VMS/VMS__Foundation_Paper/VMS__Full_conference_version/figures/PR__timeline_sync_def.svg --- /dev/null Thu Jan 01 00:00:00 1970 +0000 +++ b/0__Papers/VMS/VMS__Foundation_Paper/VMS__Full_conference_version/figures/PR__timeline_sync_def.svg Sat Aug 03 19:24:22 2013 -0700 @@ -0,0 +1,498 @@ + + + + + + + + + + + + + + + + + + + image/svg+xml + + + + + + + + + + Timeline B + + + + + SyncPoint + + Timeline A + + + + write + read + + + + Timeline B + + + + + SyncPoint + + Timeline A + + + + write + read + + + SyncPoint + + write + + X + + + + + + + Timeline B + + Timeline A + + write + read + read + write + + shift relative to each other + + diff -r 9b9a2497757d -r eb146c5c05a8 0__Papers/VMS/VMS__Foundation_Paper/VMS__Full_conference_version/figures/PR__timeline_tie_point_ordering.pdf Binary file 0__Papers/VMS/VMS__Foundation_Paper/VMS__Full_conference_version/figures/PR__timeline_tie_point_ordering.pdf has changed diff -r 9b9a2497757d -r eb146c5c05a8 0__Papers/VMS/VMS__Foundation_Paper/VMS__Full_conference_version/figures/PR__timeline_tie_point_ordering.svg --- /dev/null Thu Jan 01 00:00:00 1970 +0000 +++ b/0__Papers/VMS/VMS__Foundation_Paper/VMS__Full_conference_version/figures/PR__timeline_tie_point_ordering.svg Sat Aug 03 19:24:22 2013 -0700 @@ -0,0 +1,369 @@ + + + + + + + + + + + + + + + + image/svg+xml + + + + + + + + + + Tied Point + + Timeline B + + + + + Tied Point + + Timeline A + + + + + + + + + + Timeline B + + + + + Suspend(Point 1.S) + + + + Resume (Point 1.R) + + Timeline A + + + + visible + NOT visible + + + visible + NOT visible + + diff -r 9b9a2497757d -r eb146c5c05a8 0__Papers/VMS/VMS__Foundation_Paper/VMS__Full_conference_version/figures/PR__timeline_tie_point_ordering_2.svg --- /dev/null Thu Jan 01 00:00:00 1970 +0000 +++ b/0__Papers/VMS/VMS__Foundation_Paper/VMS__Full_conference_version/figures/PR__timeline_tie_point_ordering_2.svg Sat Aug 03 19:24:22 2013 -0700 @@ -0,0 +1,324 @@ + + + + + + + + + + + + + + + + image/svg+xml + + + + + + + + + + + + + + Timeline B + + + + + Suspend(Point A1.S) + + + + Resume (Point A1.R) + + Timeline A + + + + visible + NOT visible + + + visible + NOT visible + + Suspend(Point B1.S) + + + Resume (Point B1.R) + + + diff -r 9b9a2497757d -r eb146c5c05a8 0__Papers/VMS/VMS__Foundation_Paper/VMS__Full_conference_version/figures/PR__what_runtime_does.svg --- /dev/null Thu Jan 01 00:00:00 1970 +0000 +++ b/0__Papers/VMS/VMS__Foundation_Paper/VMS__Full_conference_version/figures/PR__what_runtime_does.svg Sat Aug 03 19:24:22 2013 -0700 @@ -0,0 +1,2211 @@ + + + + + + + + + + + + + + + + + + + + image/svg+xml + + + + + + + Master(runtime system)on core 1 + + + Seed VP(created atapp startup,on core 1) + + Application Code + Seed_Fn + Work_Fn + Language Wrapper-LibCode + Proto-RuntimePrimitiveCode + Lang Handlerfor create VP + Assigner Fn + Instances of runtime system(data structson heap) + Instances ofVirtual Processors(data structson heap) + + create VPwrapper Fn + Call to dyn lib + + Top Level Fn + Top Level Fn + Top Level Fn + + + + + + + end VPwrapper Fn + + + + + + + + + + + suspendand switchto runtime + + returnfromsuspend + PR primitive Fnto send request + normal call + + suspendand switchto runtime + Mutex Acquirewrapper Fn + + + end VPwrapper Fn + + + + + + + + + suspendand switchto runtime + returnfromsuspend + normal call + + suspendand switchto runtime + + + normal call + normal call + + + + + + + + + + Timeline of SeedVP + suspend + resume + end + Proto-RuntimePrimitiveCode + PR primitive Fnto create VP + + + + VP 1(created byapplication,on core 2) + + + Master Fn + + + + + + suspendand switchto app VP + + + + start + + + + Timeline of VP 1 + suspend + resume + + start + + + + Timeline of Master on core 1 + suspend + resume + + start + + + Call to dyn lib + Call to dyn lib + Call to dyn lib + call to dyn lib + + + Master(runtime system)on core 2 + + + + + Master Fn + + + + Timeline of Master on core 2 + + + + + return fromsuspend + + PR primitive Fnto send request + PR primitive Fnto send request + PR primitive Fnto send request + + + end + + + + resume + resume + suspend + start + resume + Language PluginCode + Proto-RuntimeMasterCode + + + + + + + + call via Ptr to Dyn Lib Fn + + call via Ptr to Dyn Lib Fn + Lang Handlerfor acq Mutex + + + + + + + Assigner Fn + + + + + suspendand switchto app VP + + + return fromsuspend + + + + + + call via Ptr to Dyn Lib Fn + + call via Ptr to Dyn Lib Fn + core 1 + core 2 + + + + return fromsuspend + + + + return fromsuspend + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + diff -r 9b9a2497757d -r eb146c5c05a8 0__Papers/VMS/VMS__Foundation_Paper/VMS__Full_conference_version/figures/Proto-Runtime__modules.pdf Binary file 0__Papers/VMS/VMS__Foundation_Paper/VMS__Full_conference_version/figures/Proto-Runtime__modules.pdf has changed diff -r 9b9a2497757d -r eb146c5c05a8 0__Papers/VMS/VMS__Foundation_Paper/VMS__Full_conference_version/figures/Proto-Runtime__modules.svg --- /dev/null Thu Jan 01 00:00:00 1970 +0000 +++ b/0__Papers/VMS/VMS__Foundation_Paper/VMS__Full_conference_version/figures/Proto-Runtime__modules.svg Sat Aug 03 19:24:22 2013 -0700 @@ -0,0 +1,219 @@ + + + + + + + + + + + + + + + + + image/svg+xml + + + + + + + ParallelismConstructModule + + Hardware Specific Module(Proto-Runtime) + Assignmentof Workonto CoresModule + Hardware Abstraction Interface + + + + Code Stack for Runtime System + + diff -r 9b9a2497757d -r eb146c5c05a8 0__Papers/VMS/VMS__Foundation_Paper/VMS__Full_conference_version/figures/Proto-Runtime__modules_lang_breakdown.pdf Binary file 0__Papers/VMS/VMS__Foundation_Paper/VMS__Full_conference_version/figures/Proto-Runtime__modules_lang_breakdown.pdf has changed diff -r 9b9a2497757d -r eb146c5c05a8 0__Papers/VMS/VMS__Foundation_Paper/VMS__Full_conference_version/figures/Proto-Runtime__modules_lang_breakdown.svg --- /dev/null Thu Jan 01 00:00:00 1970 +0000 +++ b/0__Papers/VMS/VMS__Foundation_Paper/VMS__Full_conference_version/figures/Proto-Runtime__modules_lang_breakdown.svg Sat Aug 03 19:24:22 2013 -0700 @@ -0,0 +1,243 @@ + + + + + + + + + + + + + + + + + image/svg+xml + + + + + + + Code ofparallelismconstructmodule + Code ofassignmentonto coresmodule + + + Code Breakdown of a Language Implementation + Code ofwrapperlibrary + + Compiled intoapplicationexecutable + Compiled separatelyas a dynamic library + + diff -r 9b9a2497757d -r eb146c5c05a8 0__Papers/VMS/VMS__Foundation_Paper/VMS__Full_conference_version/figures/Proto-Runtime__modules_plus_plugin.svg --- /dev/null Thu Jan 01 00:00:00 1970 +0000 +++ b/0__Papers/VMS/VMS__Foundation_Paper/VMS__Full_conference_version/figures/Proto-Runtime__modules_plus_plugin.svg Sat Aug 03 19:24:22 2013 -0700 @@ -0,0 +1,618 @@ + + + + + + + + + + + + + + + + + image/svg+xml + + + + + + + + Master(runtime system) + ConstructSemanticsModule + + Hardware Specific Module(Proto-Runtime) + Assignmentof Workonto CoresModule + Language Plug-in + Hardware Abstraction Interface + + + + + + + Seed VP + + + + VP createdby Application + + + + VP createdby Application + + Application Code + Seed_Fn + Work_Fn + prallelism_construct2_Fn + Language Wrapper LibCode + Proto-Runtime PrimitiveCode + Language PluginCode + Proto-RuntimeCode + Handlerfor LanguageConstruct1 + Handlerfor LanguageConstruct2 + Master Fn + Assigner Fn + Instance of runtime system + Instances ofVirtual Processors + + + + + + + + prallelism_construct1_Fn + + + + + diff -r 9b9a2497757d -r eb146c5c05a8 0__Papers/VMS/VMS__Foundation_Paper/VMS__Full_conference_version/figures/Proto-Runtime__modules_plus_plugin_plus_code.pdf Binary file 0__Papers/VMS/VMS__Foundation_Paper/VMS__Full_conference_version/figures/Proto-Runtime__modules_plus_plugin_plus_code.pdf has changed diff -r 9b9a2497757d -r eb146c5c05a8 0__Papers/VMS/VMS__Foundation_Paper/VMS__Full_conference_version/figures/Proto-Runtime__modules_plus_plugin_plus_code.svg --- /dev/null Thu Jan 01 00:00:00 1970 +0000 +++ b/0__Papers/VMS/VMS__Foundation_Paper/VMS__Full_conference_version/figures/Proto-Runtime__modules_plus_plugin_plus_code.svg Sat Aug 03 19:24:22 2013 -0700 @@ -0,0 +1,2026 @@ + + + + + + + + + + + + + + + + + image/svg+xml + + + + + + + Master(runtime system)on core 1 + + + Seed VP(created atapp startup,on core 1) + + Application Code + Seed_Fn + Work_Fn + Language Wrapper-LibCode + Proto-RuntimePrimitiveCode + Lang Handlerfor create VP + Assigner Fn + Instances of runtime system(data structson heap) + Instances ofVirtual Processors(data structson heap) + + create VPwrapper Fn + Call to dyn lib + + Top Level Fn + Top Level Fn + Top Level Fn + + + + + + + end VPwrapper Fn + + + + + + + + + + + suspendand switchto runtime + + returnfromsuspend + PR primitive Fnto send request + normal call + + suspendand switchto runtime + Mutex Acquirewrapper Fn + + + end VPwrapper Fn + + + + + + + + + suspendand switchto runtime + returnfromsuspend + normal call + + suspendand switchto runtime + + + normal call + normal call + + + + + + + + + + Timeline of SeedVP + suspend + resume + end + Proto-RuntimePrimitiveCode + PR primitive Fnto create VP + + + + VP 1(created byapplication,on core 2) + + + Master Fn + + + + + + suspendand switchto app VP + + + + start + + + + Timeline of VP 1 + suspend + resume + + start + + + + Timeline of Master on core 1 + suspend + resume + + start + + + Call to dyn lib + Call to dyn lib + Call to dyn lib + call to dyn lib + + + Master(runtime system)on core 2 + + + + + Master Fn + + + + Timeline of Master on core 2 + + + + + return fromsuspend + + PR primitive Fnto send request + PR primitive Fnto send request + PR primitive Fnto send request + + + end + + + + resume + resume + suspend + start + resume + Language PluginCode + Proto-RuntimeMasterCode + + + + + + + + call via Ptr to Dyn Lib Fn + + call via Ptr to Dyn Lib Fn + Lang Handlerfor acq Mutex + + + + + + + Assigner Fn + + + + + suspendand switchto app VP + + + return fromsuspend + + + + + + call via Ptr to Dyn Lib Fn + + call via Ptr to Dyn Lib Fn + core 1 + core 2 + + + + return fromsuspend + + + + return fromsuspend + + + + diff -r 9b9a2497757d -r eb146c5c05a8 0__Papers/VMS/VMS__Foundation_Paper/VMS__Full_conference_version/figures/Proto-Runtime__modules_plus_plugin_plus_code_back.svg --- /dev/null Thu Jan 01 00:00:00 1970 +0000 +++ b/0__Papers/VMS/VMS__Foundation_Paper/VMS__Full_conference_version/figures/Proto-Runtime__modules_plus_plugin_plus_code_back.svg Sat Aug 03 19:24:22 2013 -0700 @@ -0,0 +1,1678 @@ + + + + + + + + + + + + + + + + + image/svg+xml + + + + + + + + Master(runtime system)on core 1 + ConstructSemanticsModule + + Hardware Specific Module(Proto-Runtime) + Assignmentof Workonto CoresModule + Language Plug-in + Hardware Abstraction Interface + + + + + + Seed VP + + + + VP createdby Application1 + + + + VP createdby Application2 + + Application Code + Seed_Fn + Work_Fn + Language Wrapper-LibCode + Proto-RuntimePrimitiveCode + Language PluginCode + Proto-RuntimeCode + Handlerfor create VP + Handlerfor LanguageConstruct2 + Master Fn + Assigner Fn + Instances of runtime system + Instances ofVirtual Processors + + create VPwrapper Fn + + + + + Handlerfor LanguageConstruct1 + + + + + + + + + + + + + Call via Ptr + + Top Level Fn + Top Level Fn + Top Level Fn + + + + + + Top Level Fn + Work_Fn + + + end VPwrapper Fn + + End VPPrimitive Fn + + + + + + + + + normal call + + + suspendand switchto runtime + + returnfromsuspend + create VPprimitive Fn + normal call + + + suspendand switchto runtime + Mutex Acquirewrapper Fn + + + + end VPwrapper Fn + + end VPPrimitive Fn + + + + + + + normal call + + + suspendand switchto runtime + + returnfromsuspend + send requestprimitive Fn + normal call + + + suspendand switchto runtime + + + normal call + normal call + normal call + normal call + Call via Ptr + Call via Ptr + Call via Ptr + + + + Master(runtime system)on core 2 + + + + Handlerfor LanguageConstruct1 + Handlerfor LanguageConstruct2 + Master Fn + Assigner Fn + + + + + Handlerfor LanguageConstruct1 + + + + + + + + + + + + + Call via Ptr + + Top Level Fn + Call via Ptr + Call via Ptr + Call via Ptr + + diff -r 9b9a2497757d -r eb146c5c05a8 0__Papers/VMS/VMS__Foundation_Paper/VMS__Full_conference_version/figures/Proto-Runtime__modules_plus_plugin_plus_code_back_2.svg --- /dev/null Thu Jan 01 00:00:00 1970 +0000 +++ b/0__Papers/VMS/VMS__Foundation_Paper/VMS__Full_conference_version/figures/Proto-Runtime__modules_plus_plugin_plus_code_back_2.svg Sat Aug 03 19:24:22 2013 -0700 @@ -0,0 +1,2231 @@ + + + + + + + + + + + + + + + + + image/svg+xml + + + + + + + Master(runtime system)on core 1 + + + Seed VP(created atapp startup,on core 1) + + Application Code + Seed_Fn + Work_Fn + Language Wrapper-LibCode + Proto-RuntimePrimitiveCode + Lang Handlerfor create VP + Assigner Fn + Instances of runtime system(data structson heap) + Instances ofVirtual Processors(data structson heap) + + create VPwrapper Fn + Call to dyn lib + + Top Level Fn + Top Level Fn + Top Level Fn + + + + + + Top Level Fn + Work_Fn + + + end VPwrapper Fn + + + + + + + + + + + + suspendand switchto runtime + + returnfromsuspend + PR primitive Fnto send request + normal call + + + suspendand switchto runtime + Mutex Acquirewrapper Fn + + + end VPwrapper Fn + + + + + + + + + + suspendand switchto runtime + + returnfromsuspend + normal call + + + suspendand switchto runtime + + + normal call + normal call + + + + Master(runtime system)on core 2 + + + + Handlerfor LanguageConstruct1 + Handlerfor LanguageConstruct2 + Assigner Fn + Handlerfor LanguageConstruct1 + + Top Level Fn + + + + + + + Timeline of SeedVP + suspend + resume + end + Proto-RuntimePrimitiveCode + PR primitive Fnto create VP + + + + VP 1(created byapplication,on core 2) + + + + VP 2(created byapplication,on core 3) + + Master Fn + + + + + + end VPwrapper Fn + + send requestprimitive Fn + + + + + + + + + suspendand switchto app VP + + returnfromsuspend + + + suspendand switchto runtime + normal call + normal call + + + + + start + + + + Timeline of VP 1 + suspend + resume + + start + + + + Timeline of Master on core 1 + suspend + resume + + start + + + Call via Ptr + Call to dyn lib + Call to dyn lib + Call to dyn lib + Call to dyn lib + + + Master(runtime system)on core 2 + Lang Handlerfor Acq Mutex + + + + + PR primitive Fnto create VP + Master Fn + + + + + + + suspendand switchto app VP + + + + + + Timeline of Master on core 2 + + Call via Ptr + Call to dyn lib + + + + + + return fromsuspend + + PR primitive Fnto send request + PR primitive Fnto send request + PR primitive Fnto send request + + + end + + + + resume + resume + suspend + start + resume + + return fromsuspend + Language PluginCode + Proto-RuntimeMasterCode + + + diff -r 9b9a2497757d -r eb146c5c05a8 0__Papers/VMS/VMS__Foundation_Paper/VMS__Full_conference_version/figures/Scheduling_states_2.eps --- /dev/null Thu Jan 01 00:00:00 1970 +0000 +++ b/0__Papers/VMS/VMS__Foundation_Paper/VMS__Full_conference_version/figures/Scheduling_states_2.eps Sat Aug 03 19:24:22 2013 -0700 @@ -0,0 +1,460 @@ +%!PS-Adobe-3.0 EPSF-3.0 +%%Creator: cairo 1.8.6 (http://cairographics.org) +%%CreationDate: Sat Nov 13 08:19:40 2010 +%%Pages: 1 +%%BoundingBox: 0 0 196 77 +%%DocumentData: Clean7Bit +%%LanguageLevel: 2 +%%EndComments +%%BeginProlog +/cairo_eps_state save def +/dict_count countdictstack def +/op_count count 1 sub def +userdict begin +/q { gsave } bind def +/Q { grestore } bind def +/cm { 6 array astore concat } bind def +/w { setlinewidth } bind def +/J { setlinecap } bind def +/j { setlinejoin } bind def +/M { setmiterlimit } bind def +/d { setdash } bind def +/m { moveto } bind def +/l { lineto } bind def +/c { curveto } bind def +/h { closepath } bind def +/re { exch dup neg 3 1 roll 5 3 roll moveto 0 rlineto + 0 exch rlineto 0 rlineto closepath } bind def +/S { stroke } bind def +/f { fill } bind def +/f* { eofill } bind def +/B { fill stroke } bind def +/B* { eofill stroke } bind def +/n { newpath } bind def +/W { clip } bind def +/W* { eoclip } bind def +/BT { } bind def +/ET { } bind def +/pdfmark where { pop globaldict /?pdfmark /exec load put } + { globaldict begin /?pdfmark /pop load def /pdfmark + /cleartomark load def end } ifelse +/BDC { mark 3 1 roll /BDC pdfmark } bind def +/EMC { mark /EMC pdfmark } bind def +/cairo_store_point { /cairo_point_y exch def /cairo_point_x exch def } def +/Tj { show currentpoint cairo_store_point } bind def +/TJ { + { + dup + type /stringtype eq + { show } { -0.001 mul 0 cairo_font_matrix dtransform rmoveto } ifelse + } forall + currentpoint cairo_store_point +} bind def +/cairo_selectfont { cairo_font_matrix aload pop pop pop 0 0 6 array astore + cairo_font exch selectfont cairo_point_x cairo_point_y moveto } bind def +/Tf { pop /cairo_font exch def /cairo_font_matrix where + { pop cairo_selectfont } if } bind def +/Td { matrix translate cairo_font_matrix matrix concatmatrix dup + /cairo_font_matrix exch def dup 4 get exch 5 get cairo_store_point + /cairo_font where { pop cairo_selectfont } if } bind def +/Tm { 2 copy 8 2 roll 6 array astore /cairo_font_matrix exch def + cairo_store_point /cairo_font where { pop cairo_selectfont } if } bind def +/g { setgray } bind def +/rg { setrgbcolor } bind def +/d1 { setcachedevice } bind def +%%EndProlog +%%Page: 1 1 +%%BeginPageSetup +%%PageBoundingBox: 0 0 196 77 +%%EndPageSetup +q +Q q +q 0 0 197 77 rectclip +% Fallback Image: x=0, y=0, w=196, h=76 res=300dpi size=776967 +[ 0.24 0 0 0.24 0 0.916468 ] concat +/DeviceRGB setcolorspace +8 dict dup begin + /ImageType 1 def + /Width 817 def + /Height 317 def + /BitsPerComponent 8 def + /Decode [ 0 1 0 1 0 1 ] def + /DataSource currentfile /ASCII85Decode filter /LZWDecode filter def + /ImageMatrix [ 1 0 0 -1 0 317 ] def +end +image +J3I@:GU(oO"FIqV0;rCK*=mro@So+\<\5,H7Uo<*jE<[.O@Wn[3@'nb-^757;Rp>H>q_R=Al + C^cenm@9:1mM9jS"!dTMT<$3[GQ$8#0$s<4ZX!SPQ1`A'g"%ioWjnAY&^gM+`4=1jRLW!YA=M/6)*KS9PE`kN%="Tc + _Aoh+fk'&t\ctI:h]"?)EVlIDd]!t-Xh$Ve"[JLu9_eZN2gNOTbQKrP([VkioDBB7=[,UR, + Hi@$GNQ^C&p\W4]93o[!Fh+rPIlj(Jn9-kkY-14!k3ht)5*"HoRH + ;haXA))8C?"dI7ot,?P2T;S5?2%pJG?hVRcZ<)f7H[>"\)m@0?8V'$JR>njlZch42=GEj[T + 4&n?hf?XIq!P\.u@^0VDF-?GfCPQA,''qCLT7E23?\J*`H"p).jbLiOLj8QXgt7CRShB%EX + iFq6k?EkOj:*SRe,%AVXodSr'0))J4\okLfL'T'%#7D6$`!`A)dSfo@#OBmIG1V.mMqX0?E + InfEH^'PuKNd`;(C\aGrimCVg+cLnm>S*p6in/MrB_=3sJ%E%]U:DLk=S8TFgnf3]:amtt* + /^*`*cS`u=SF8VeoGnH2dI`t_:"/bU:K>sq+ssgKcl$loZ@-jp`9s"i + V8utNT9gU:R1&;So:1_qAt]ol2%!TXm>j*caE0;T'sA]r#ZHgnbf"4c1ClU:Y#.:T5WQ[rZ + @3_q>R"imJHo*ch78:TC;^Xhuj(2:F3QNPpBD[Js(>X@KF9s*])p%>.#(RD)FIVD%H55cLJ[C[6eHetiWMQ';%=d + <=H*&a;#Q*#g(u1n*:KUa;2S4G.RdIA(#m/7Mc"@E7G,9iirieH&L<&FZF9n0Hjks2Xu8c% + h&GC-EK3oA3_*<>*TP(`Kb5XX`7SK>U]c71;@Z#a=UcP87#@%(/k/Ca#i)(-?%E3_1_7*i, + G`8GP>Z9n5GAiRV$*J3dYr(d=\L[65g5KkXC+ZJG:Vd.YSC']>"`"1.ODluQW!6X9;*jh`' + hG/;\!2k3K,!@7*1iq+?3'AbqnL8d@&s:C'@bB2000r7jpRT!C,"4V.\*0fki + b*c3_l3+=,<=W20!C\WZNCfL(#,Y(^RN*^]>cL_9,h6&9%B@A6"EeMm7;8l(Y-qBbh-93!ENWt#)=5*U[lihV72@ctm.h,Qr5U$At/p.8#*B + 8Y!Odbn>/'njfA`cO0ZW&>F=kRsGXTZ!HQB#&URnPW?7&CrIY#))IDen`oZ%;POHon**5pQ + ?6[oVqR7`OU>7kMQAd]?p5=^Wa45btqglpb7-$$56"CV!G0/6uD]&h_,[#5<"X!dhUi!4Cd + e5T92q)pNZs7HqKeY4c2Vh0\UEn\/)MqHm&!"7O#=^K)Hkhq?O?_=ZUlQk&D8M4bf,7*1h5 + %Uf[&*%,]Y[&@HV=A#j'L$@7N*Z/eOiS6R?Xe_.Y1r;mTX?VR37O`bkKQ,quWJebc0pY_]: + ub]&;X/)>%2eFcA(e!snc1qr=*F$5r/Fg/5"WKA0.(5`rI+`p@]WTX.Th3oQ045b]3sKBKL + tc"B"ZV$ZjLLOr67O+0S7PK.lM"ph*Rt5Q(cmW3bM^b/ugcAU/`-okM5HooEKjWq@>Dr=d* + F7NarR7MagLt"r/oW1t#=<'5:^P@K=-1b$&]!J=N1.o`e*kJ2e!Q>q-/Y:d`c66mm]%>T*3 + fagpCB88D'_XlZ4df2iYqN?*ErV$UMJ>7Y1/X@#Xc*)=GZb@9hoSKj+Rn\[=kC^e"Z/-TqE + `hJ45M*VZ]k"'7B=bnJD>uVBuf&jOYE:'ShX,hCDD,*3^5aY) + *Jq>qX(10qgo1RS8h/c0,Y?$ZfQ%F4nOI!Q=9EC3$?!L.qZ\bm")"nLT$=LM#ANR$04VrC?a?KBC[PKR'.K'sh8\W'Q$CMQ$*O1 + MHiSH]=R7kP>_!FWha7L[/-pLWQ/h2O!V06K;Ltk[%(sA:o2C.="Yd@Ik(\\[2)%;>+XQC7 + hKbDrcdk`!;(D*\ePW#U_b%jg0XY@k_(5uEi90al$hgc;"c=H'Fh_[Ij> + +5&4+Tr,$$GOK8!hX93IGZ4/2eWU%T8XQb>QLl,s66N^PLG@9ED6G:G8OV + *\+7UcdhY2]IX"TW2B;62Ob;UB,h\bUsk(FL@jT!0DU6kW0mO66":-)GlA + 0d#d?tFI%k.'<73.0!q$"#c^/#!_L,IJ56#M3:WXb"&&"'%8QL[F:$=8d=B1)5k5N6e>U3# + %BZ]L@Dr^#[g3Q/LX+V4lq%12lORcUg*o_j+_qW=N"PRc&!7800bEr[Wr/Mnnu_'_bNdQW_ + ?.lg"DQB^TUQTJU=K=iek;VAmuE]j@-g\Q`M(/50_lG<<5ZUGU`m,\kuJV*A/6n5W6h+I&T + IQldL5Qc$.)'FWtkl#ZiP0'&dndYJ/8:R[L$rA(N'QiDj:MM55kSD)QrWMK2WM)[!tj)O31 + rOEPRSC2BDn.*3R6TNOK?_*"R&B'97AG5^sh0K&'fi!3to.bKf@&0cse#+/!ZslDb.DU>/# + `ZU"-pEY.]U1mW]4+g$"@_4q9e]Ta]o*&9)inh>HC']WWKg6&BPnCeZ']G/TLeo@;H^rIJ[ + kQi;>-(mOMmZARulI2Ct-D5W2lR;SF'dmE[-a@1uTrf^ta!3?qH',]*lZ4J[P_92k*:fX+_ + 5,[KEi?en.^>Sh:C[QV[2si)/$`]hE4I:Q5jA>Z-#qfN^u[.!(86:+\Nrd]NHkG[6On.'0! + ajsk\=$>f.UR90B$Se8* + O5VQ%2`[mN1WsV8$r&mKRSlt()t2i)JQ"cf#SHTuk=s8>0dcHV"#fGn47oO0!`,?;Tci=Q>k + d437^P.9&rtX#P=G$ImbuhK&HW`PRhl)*RK/aHo++8h#qMYT*g7*W1U-0FkpiAG1=Ds9oW\ + (QkspuK9=2B",/3f8V*m)l7"G.9&d&`.-Lq^-!O78Ji0cmHfenV"pbFj&kbUd*i7X@aVSX' + 3ZgU+%;a58o4L'AKYIX`HnK,IQo!6?/0m8s>eLeU_;Qp`!_:(D$qbqVt;me`6_A*d6V++88 + *J!lG$iqnYR,.-jk])srC7a1dM&Pq8;s6LHJb&iX\IULVID+m@NHL(`#(AQgMG@N:s@_cC'9Y?aj&u*2. + 'B74"=*%;cUROM',_&b5]uc?KeCe&*ZV9igD;FkRm%L'U^Zu2ToL'@B:"LXhGA3N@4CN;76 + @3p+^&81q%#WrmU=>NXucL38a9&"V!N7OcZ,0U=O+A'p'",(,gP>oiICRAgfoB:L_1]fbs6 + >Z+t)U[XdTo7p4B9"SGJ@O_>LRQ"b1(%p!O]p7Z4ZUk=gipaKod1/T)8Iii&P^9j:1m9(RR + E"rmmm1uRE(1utLHYhm;/+';1Pc55pdl&m5=\V+G:FdOFF$-,cDm3RQP;?\!fl2-AE46726 + W6VYSeZGeCC[I^V=2eW!@HbM*DbU^0hi>*CaVeF@TMG./,RG6aC"d$3jI/C> + 2=h_c7bTEfg!`G8DW64p%AktQ!GSU>Y'I(.=XJe\3M>1RI<=kA2;0>e3!*r,:L%S-5]]j(NG(UlN95A4IYjj3 + `j92QpB>HqB62,)6/Z"==hP:jPJ:6%+ZYCJQF]0TgKZ:Mn$HYpqW)f&F<5#KqQT:5\XN)!> + u?loSH`g'Xom+nfP:5N7U'M8k9unIkm52A@JiECYn:$X#JC3jUk@K3>%B6'p39>;GP1;n"U + MrbitHo+OYaoD4?A@OVLiD#*qU'lO^c%g<3mGPdC(L&tBs;)3oJMQ+:/;os,T6M+lD7#h7S + 3o=lD&eH$(UP?-97,/3h*gBs$+]oJL3Nc^Xi0*bMEQ2-u=q4X6.4AsP`*DKZ"b5YmH+;FX^ + O"4S(enWmam;-^3Dc7Fb&%2P'@rJ%1:ednKq5'ZCjdpb]fS8Pi%D&j2J-)bH;2N$AZn/$IP + d]Q>Ik,kh0Uil(,eX^=2tWOe + Y"m@Pb)'m5Q#m>j0Fk=Z3b>/r/&<<\JL)`l`Xq[p(p'\K0Z1=?8\$KG:9T."Bd%e'F0LuFXY + V'UI2Y0hj#n):M*(USN\[(B#N'enCH`N2\n)$uuTkd.=G\ON:Hf&8VI3i]A%ro[33PrhdNq + gl7=KZ!>`%2`!G1mn]3k_a^tMF,'G0es'EY-/S2"^#uJH\]3p[C^dqVM-=cJPNufk?1[=pZ + RI,F$Y)=P_d_jSW>;$cR")U@$KEX^:WdHqs^JDl#'ZaXn2cZ\cRZ!dB?)_DK"KYHW[Gh.$b`0`E[i3r.2p;fVC4GDT^i_%AJO0nR%b>KL-chg5)n2%u'kfaBYji + r3=En`=;6cXqJ^5kXWa>mE):bDKrEsWoaJ4e\h0Cb?WlJr8GpLMJdF1-7[VM:J$tQ1WG4tp + [N^8G's(Tp!-hLd(Kn8k]&r<@]gF(S)!auB_s4q6@p$JDHr.&cA,uE#LOPPe%IonkWEa$gL + TU&?$hlhg]u&Z"E&R'YNk)&:QM(f6.UHuf"GmO[hPn$6ER9+jTm6c\L^^e>]TChdN1Q>X?3Zh8.l0`S>+];_ZS#\Gl9e*SSQm'\gR + .lOaG/akhI1hS&9'1>0,dd90^=eU8R:Y2)TR-@RfUJ4eLUo3I9Fn)8^5iP$:WGd36#c]@`% + J,I7r(=ep&e0,H$Xq?9\4s/iL7HAng+7s-UC=(gbA:K$[HunTE!+`4="ba\H+Wa;=rc.*ak + A5S=XR)XV-h$/p^Bn&IXc;]n5'?*RQ0E^c_8.h-[F_Mclf^jJ7NQlX.DJXWRHo=4lb,G=b1 + eg;2LV-I]j,l0jYHYgAF`0Rf"7j2uoY4,4:fsj'g3p[ + gZMlV*[!h'DgOL:bo`&e%s)G;1*uHKX$_F/B)_G-@?@!hhoEs7fqaL6DQ2,otWR\'dg_-^W + S:+a*GN'@iWn?,+(&>VTqnKh=Dka@.41E8TnRgqH9%qI<\,63YrP.0RZ6cdc&bDRm[]=8t5 + 0eC0+K_mdb.ldU&,6hK#mGrIi=MAU/f>+R6fJ[pPYNYBMacYOE:HQ-SW:]3XkAS(6s&ID9.WD;5[9$!j4%E>4:117Ip + W<,&a1h-(HBb6%8P?iV]:bg0ZR)BBTS8YsmMobsB%Y?A!ZC\A\fQHs9QJWr)2Tt]t0ri9#' + cYS;1X%S(/GlnOWC:4.AF8"E2QVXU2lZN(FT%@nkh=#Rc*Zl(ZC$!T9YYEds-[eYK5'T1.Q + :iY13dpqu'9DV&rVo+O"9SZiE$Pen5k%/T"[R!OX:<#4d2NBTCg$W/^+=?fii;2SLCZDHct + *ePn750*7.EZD'h*+Q>8K`uKOYlD6VM7>#Vj7Gp7JJi*iHnLR[2&!Z6M3O!Cj_c)9Ho0RjU + euKVKtgEho`d7*d;qblG'.i@cH0@t)G'fF/8+`:@lE'0-1* + -qTTfJ"MkGF8qVl?*HXOe75I\8@*)2$Kd0/eFJUK\;Y7pa9dClF3mA3n"U,pnPUYmEeEi:c + AY/fDuF1B:W9/(o'qRqGmtKqi?cG,;6D& + 9brK:5&E;W3>`Gp9; + p1j-k[a\+C]Vd:'ErM!bI:L_`k4f$S@pA4u;V + ^^XZHHc^:"/Z=uF'":[GlC3sj`u;fS*,(rLSO*[I]'74HN(skmrq_"WNP+8c + e(OB)`TGVKD1e/*KV=n0pe-RS + .k]AFR#%j%B&U^h*,=Hd=&n4g5I*d$I`)rEA@['fKOW"qNZ%j''e6@inFpc,S817s\7PfsF + h%,'p)H0JeNKFfi.FUF"A!D%pOk)TaGjuhbe9d7=p-2(C!?bneK92636V)J7,%OZ2OchUm8 + GO1bP>k:\YEChrGp+MFe=2YbG#(^*5q$:YUQLD5/%(`1IR>*UP`iIV9)2mHAX'NeP/L\MFO + _3;(k.g+BGJ_cb^7;[_d&+aWCGnV(8b$*R=r\HN@?4LUoY[e;^a4ke`?lAe>I'pV";]"Ye( + S(\U[//AVG1^'W4oB.RG>')5&iL:T;a)djAYO)=U71I*mSq:+/h>mljf`g+^uqX3KZ^3%,E + iS7gti)B_C89[JWjPH^p?.PPIboc'K7g3T%;X[;7a,+iN1Ke4c=5UO/h>r3+qct9CH$oKE/ + M`uleH6-G6&'=ATi + LCYXQp1IXC_*HcC*6SlX<[)(030jWoe-`odd:*FG*_qB4!)Ue>ZIIcRWc6!%]?nYf-gb>'2 + ]3b3b0A,JMn4RrDu7&>;Te#[(C(eCkCtS$j+IJQ`DmBU4Xr\BCBs+R_\J?7J/IRtmeW%n(P+i^iCYsN(V:R+SA@`L`;1M?e + =hodaX"f1l^efn%\9=%8?E<`tDf)Yl.m!Ia'f17]0idTj?/Uma(r[qZT'.0DuMJt<<3 + Ue[JW&TQ=Z0Y=16J"ZJ. + \oD)Ei_R[R-d7ip&%qH']5*5Jrlo0e")2M$nad&uhg0B(Ard(ARU3_n67fF#8<_VHKPbQHj + )g(RMDX@*;Y>5UUBi2fHB+_tkB8AspeI.G3q2i'Sh:9/C+C)nSq?X%ucBd)@QeL!TTVE9Jk + mB_1X&e@M&/kaE$Vle\Vkai?q_@d,q*Q0!b][lGp8l8:I4I/lqMJt"=/X]j#KM<8S*m%iaE + .?:^@3n%agI;W<.k1`U/S=!q8qO'rj]F2ld!2op9Cc5&?C:c6ND!_\D'"65hHW&ql@qm5If + )#ccp#GMfS%e:bZFEH=2/S;/6aV\e)>l?:R@l:Q7o'fQqJSBa1;Z$CWLW$](gC'L4FJsq-Uak?\>YIp + @$-N31;GI?kr#1;msI^"_*RT8LHUH4#k^m]o-@j]a4"7b^p@\DJ3_)s0m8Kl + sXl6 + gi^h^)48t7kCS0iQAJFPJtoFjF`S\GIQ]1TVtgDL&92&e4O(;N5#G_2W^T`D_G-ZDHYN#rE + hqMeF)MA)A8_gk"qI_Z'r$d8X;Hm">@$O@FCWUcXW\;!>+f0[Bq6lEgP"2$.#C4,C1"q,3J;H]Oi[#XHKgn227K!.dC:6l:KBk[tQ*#fKC>" + 5uWQ=Iqj(e3Z-f^sjSfnA@Yf'VH^?NO1O#4=7;>!fN"4L_Il736aRY1d\i-%\ut=bZ0S.#a + tl&ZlBFlG_j=Q4h)J#P>cnK.#jlEkJWIb`C&h-n;`^eX9C^c76AX]9+_G'?&UT<#eUQS1ej + "322Q'+#1t4kl/RD$E&'\-$To.e4?X86L8ujnJ;N`+C!=IK(i^0FjZ.#LOibso4" + _AVT&nY6A3JHBQM\--N%S15S-K8_L;THMKK8;p+_Y/W0\7`^cGpcZaqg]0o'$6TPTfXAgL1 + IKfN8&RCh=lhVgk!>-dK.(V0W0g*-dCsl`5*:rJ\@p&SSOd6W2-X_7I"a`e9>X5Rb5fo4A; + X#>\OahS]blsSgbK;bMS&)i.I`0`8a]+tKhKhZ`5%/Ona?`oR",0q7TdPh39a#mO2&9""6u + kEcl1-@D2X(C6"HetWNh.Z'$UaOU&o*WGa1n:d2l/I95qMf@%0e$)&T'8K!=El1\lkIe-dO + &bV63A['e)-M8_$^%+BXJi/gCMhp*(V7I/&\<8\$=RLD%1#b9rZP\?+?jp!f+7RO7NA7Y0,\gb^bS0OBg0-.a\PT!%HsN#X_HNg'?!8]/ + (4a`2(F=N!te@d?kNnWUGj\-W/+r#mB%AoMWsZI14XHQsA5NXWiUtfFhH*+!<=:BOK89\d5 + tjM@tM<25MJ'#:[8Lo8:E.YlR"cDX'LnpO^KTcUjMU8'Z9MC+8*%re + c0Gd]+Jl&.,*6FO,NR)EA*q_4CEnNDSbD;E:67@Oad"tR!Th,fKbY79E7#qUOfgS/_;eViQ + 1nDGQYsAAEO(+M"%=GkSWK.he<oD\Xd#(`:O$^d7`_F)e=G5,A[n_'=LgqsLMkLDfZ&/u_Nl,)X8a<40%8$= + XLAgrX-*#!FPM^BR4S6jRNQ[6^R7V8QM@E$^'I6`tlYp&Zm + MXNn:dgkd2Ri#`8=Lp]G0OeIH-W@*$1<(J>bA8W]5eTk`1S[i#&WUrZ.VEL.D1q*h + FWb7667K/7.`J=d@NEAg"4E!8l2aZDgtN`U2$7)CoAD3Rgu\\Lb\(4SJ_f*2L$O?O\6d>6o>s:melX9G*`*+ + X;c#k4ANL + gT2&gp"6,gLaA^+aG8NH7gL]7?EfPSI@suhKis]]#`^N>`LVM_SqsgaM2isLFqY%YmK$(2@ + iNE\^.nr&LtT:%#c[Q2NGTa9$>/-JMX;s7o + FS>_k>`Dj7,3-P#7T>T&j7?W&0CQ200Ja)$@gHbAn6*2 + '`r9>te>Gd75AoNQ\GM'ogjfI`WI7.NeM;g3l@k=).=Gc4.QFB6.Jtc0cQnrMAZtiFECL4G + bDRXD1\8.,8CS&+QY.JJ`\B9Br!fk!,SqRG=[Gj^W@"'ra@)HB#oJiE"?Mu"*2E'_L%VH`/ + #fZ-9lc7le@;%"&Md$W6VS$aEcts9?D'%,B0%4Y=a.IlPm9Y9U@#%ENS*HRd#u2=u4+JdR` + *J%M8?=Z/J0p(1g;50]NqEkm%K!mWO:&:fJRRbSE!n?B/AlA\M&)NfIXpHAa](q + "7#l&miM^@?Rj$4CBZlhi+Em#:lF\=NblGLMXI;HCMZZ*L8o4LN9D<6B<8-RmBE;7o!`tSLY!JipWnn + joh7k8ZEJ+UKLnqS(7?8ot?@<U8pec.Y;1OW203`=8._Tu$Bb:sc2X63++7) + 2sLgOQ3cCXXJ;Y31M>R&IA-S+Q?0j^R=od;D9;>5$q_/nLFMgT&da);Vj5f%qiG9:jL06;> + %FE^N'G@,N;Dg-DTG^"#dT6@pMNk]bp.pkM>D_E0F>WV7u3ma56RSQ?oai + MdNOtSjVHKHf6,!iBVnkOI8YC@cdnWpb1a_#'G`?9nb`jq/tHl(Ja_EE+Mi7IjSD,=&F=2# + ^G[qHihiG&U!Ztk$jpC@^uu_9F;%-rWNCU6"&&a6m`WVL-oCr0Eaik&r4>&;0\U"HQ.a4,L + Mn^L.*8DVP,T07#k7tOiH"WQV>D%1R^a@ET?,?EAjCaB@H\[n_litSg`),74+9mMSH.:g4S + C\p8U8jeL/9&[8;>$/(OLk5/eWr=_nk#6H[h8[S!Yp-qoY`EedpE[qXs`D0giVA-gB^rqUP + r;C<(`Ml+l.-KAVH*/2]HMonb_=a:oi23lI"F4KlBL=cOT%eRl671J2aYlj?YD#Snh2TRjt + UtGpd#pGNk@Je^^hc13*aS2p0XGrpsT;hY5c(#jd);;tfZ7]?K4k\q<-f#f'E*M@a%m8\j8 + #Oo'KoCH2^d#c8o2pEJ?[,3SopO)%5Ko9WV7,TOKV>+*HJ4Xmm`HAV_9beFMnogj'\^?AJg + 1Z=.T@Bt]<9W_&@.9nMPJ*e4#j,[b2TY+7E;F4XWM<=;&Z-&CL/S^c&=Lg5qT]lO?aEklO" + g(!Z*+*;H/nE8CC2'T"2g$5q0GsnhVdE12M-*1?Oeq91uT2aFU@HYTl!#@3!oa9uc8PT>q5 + [b8j9ZqF';9CeM)`Ui7hbKK!]?0nZD#:?JF8UIB"cc + WiN.%&u!)m)<)m5EC_suM-MN*(5Zs3c/?EQ]YoW[-#9C2<.9^_h-J + 3WDib9rcIAWkk7p2M$GrDYLU:pd3;ANTqR72O[>V5M[?e7BTCntV52KtVjcX=P=_1i(KJV) + 1*4*#U:p&[Ms,i&b.g4EqU^6+`]"j^D)+/NC%U?#cage8\_7?'>I#U2eS&SPlS[Jm(ZglP( + KH#taW)T*t46/8O5,YljC15%?WLgs81Na.5ipjEV(,KV2a/e^YdR.]=ZBRYke;n@R4G"F/% + -g5^FY*/j@91%DXmf>h0eKl(G/2JHroDh:2)JYi-3[;gZqih90l!k9`?"FWq0:2Z+i!`MFb + eaTQp`UgAA;r`JJKRMD3!SZ?Ss6?.P002!6_=BqKqpb85,[biLh$6>&!d,]QPC0j"Ak%>E1Xa'8TTX9"iE>XMZd:GBU + /!$*OAnOm7)*Y$b25\mYT?WND2X/1DDC=iWVCI!jhI158FV6^U"mUrE5mrl/&:6_m4$D[&q + 1T4u;:O=-eDI,:L:1.t\k=4nEZil9!)Dh*;ocg"E5 + cEb:9)EAXMFjNaBbL=Q*S+WiTe2`]83JnG2$7 + pV0(XdYp)*Ol671BG&HEZ[r;]BaD69JmLA-fenX4uHKAidh"G,u=P#m-Vg7a-oj8M;!*tNL + BC=UQ^Xa1hhtSLBn'0t0=<=X%RdGGONISLiVYJ]"kCPCb'fJ#1rF'0QC7K.B_cVA^?lVGfn + 0T$kGb/n_X4C5)*IYW/:A+Oa-cj&@P!&HE@s>oGodH)WoH3SSF + dlS\pS!=,AQ_>8BTS;*E4SnO)^[ibB\OEj=J*M1+lbSH(F).X-&;_rD9)q_^NdRI@;sgeB9 + l%L?C\hT%HeIc\U1.kPYP-F&dS3P%t9UC`bY.eq;B$59'GS + /Wa&AY05M;03m'[G)PpFcd^WD%cpug[cXa2dT[Z.DA!Vg[hV,1<\&4YOrq&GmL7Tkq^H=je + \'sThU24QH>Y=V^.[!hY>@>-0cIUU3X3PgDJCmG!?+iq*'FWnLqh*T,$A`B8uH<5KJ*l-04uu)!kQ: + ZM@ibk5=D5oA4uDH65T:XVSM:K6D`r$,pKmmXH + ln(3r[52I]1]hBY>`)^?`j.FgXkWX^\#CHeb\01m!YM6pAX72qqlnmINQQ(s!Qq+hk0OiT@ + Nf5<$C&AnoQ`mDY)`NN,H:AkFeaTF63%?THW&E=6l5moA1j=.1l0]qB!h%*?Z&((=f#(G9:> + h?2e#LL!m0*`#M'+p?G&^_X_0^@L,%gFa2jq/CBd5)G52\Uc^&lB)EYgt6H`tXQs'[]\k&Q + 9EA + &p&JGIBkm:D-.6,Y;$LCs*>`Z;b(@AR+sS@B#,MAf2X47c; + /A<=DLH5TR^,^3&^)L6QRS)dgQH+OdVB%"DCa.U!"sI@LmD"bp_/eT6V.N14EH;> + dq'2jT6J=A0JT.`Nt09ZDm'/MF;bo1TT&onX+nU3+.74oo60d`,nZSmDe73D*>+>["U'4Wp + n__\$d)RA$7n_l<66SteULeB^+1M2Nn=X%n\,tie8PD)"qQT9s?0N!*P1)DlY5rYe^8^jc= + _V[+fM*"9"18:$ho:%j@a#o3j3V%"@13#?a1HMIXL<:DfMC]2@nfm(;s5LDClX+t-`GT^_N@%D-6jaQ,dXp&1aY1,)a`cZL53X*V)Dl6)A + Yq'$)1%dP!Cc9r1`E';H*i\@re?n&gS,p37>h0Zcbja=2'NE-U_?`"%OH6X6F,rk-X;J7c@2!A,#n.r'_]>Lq + bT.s=4Mb;Zd1+Bdjh]U+gVbUob`'BdV29S;.%f04k7 + n)APZT@">s3:7RH'<_0]Df:L$o@3PnrEL-[e^;+C.a=;F,3(.)@CKi$`p'jRD + KHq;d+dGJj+q&%L1*X/U+t7s`PJ/J%_dlfkCt?l`(.g=t%l@c& + (NAYa5eTd-q_!D:>J%#^oIA_eMLcBXG]4pDbO%rW!_ME$U3X(?QkY?;`TLEgLcdLu:2c$ms + SZ0t2rf2^"ePqe>_pUBJ&Hei,$5a`FqlHIo;K2Us%W6n&h,FXUB]U,")14"/]23sIWhGBJ* + Qs&umn+ZArm(:.g9dsc3p+Yt99jJlH$A0JGP@WrW:(XHhSS>DqpIC?\)28=N2"+FiSfOBpP0SWKD6C2[f:R7Af;F4@\R@dJi/)r?\.r+Jh2n5\>+p^d=V"C2`BDf2jo2k_h + :"WL)5Ds+qKH>0n*2A.9O/4p)5/r]k/I:NBqoNP45.^"b).gN+=)\="Ym[1Q$GSO40RpEbQ + [5[inhb=OKWjfS22Lcl_NJ?:&u^R*&Z9'PV=IF4\`=FYk:CE(=N6DZY?NajYc"7uY<8@X+% + f\Li*ZRu_fd=.'#R).Q1(WgXWTU"Kr(=VH`=4cu!uKu+RBq*^UF+\QkEI#85pLVI<_ckPT0 + B`c&;oL"E/7@JEJQY5iUQ"a7j:*TE;M3Ein<,ieDAXo13:YBELq.q2*]hqdnRe[bKJd6POM + (ujdG(M#X62uVTE&Y9-R2N"Jg$U%E]Kc30Mq2I1q+I@U'Hl*&,MDsDRMT$#_,iY9-$db1)D + dHd3q&D*=EdD?\2d[egS!3^R3HuGe$`,Zm?0dAL#Z[=U&RdD!F]"./]W/\K2bf:>bZjN:3^ + @mqK,XsH%291,8Ib_(q--,:R^"%+^/2j(Ss";Q(qN`Wm`[\Y!3r5Tl$!iUfe;*RH'*,&gu. + (Ap)N0IT!n;mrbTe6-!rmpNY)-7 + 5Fk>/b0t6V4j9-\Q`j;5u)k2)nMaL0fuXURs6=8ICM + B9^X3"jBeQuj$(["bP+$q,4:aD3^LN\LA)%%#*$Z60!kGR%OHZH$g:rt7g;*SDq;UeV:hc3 + M-,c5j&K9[Jl5Zpjh1hA`jsI/Xhg@%7m-Ck*?tj&pV + f6JX1U78$X6#i#+u;LIs5#urAW+bi3V6*[+scZ\gtVq-.SPj"T6?']Za=PO'*K./0%!]*:$ + [SD:b>*"$L%hI/VM6>M%Q%W`D3]SVu0,QK>bVX*7,Aie,JrRC9m3a.%Frh5T.7[c'=t1]8o + EGd5nl\Y;D8gACX!4iuMcf%L"POSrbEIG(hFcbs+3JmIKq*V.VVglU@Nesp%'=]`mo>Me#+ + i'%\1%):\UV;L&b,%*k!*[BZN-fU^Jinc?K*])h_2rgJkj5*#]*^f!p8*$77jPE\o*`M0,= + 66#Xin\Q/h:(=HBBGd#F6oA7SL]=/\_:8K)ub?N*eWZ_LZSXg^Rf6**g4-!(5b9pkanF3*i + &!tMr("GeUEeL*jWU'R"X:+0d)>>*lI>Na6]D@m,$(U*n0L_fBo0amG?ag*olZpkO+r-mb[ + F$*mOj/p&TX>mlpd@*s;"=fFgCVdFlS+?PDs'"m^t)ek:$$+!^.2l10cs*a^N#?SWfkS+DS + 7kl2Ik+%#EMbfujN\Q&rtIWpmT-l/FZAUPE3!AX:ICZ'"@oD_8R+*+?q)M7u1[i\chT3b>F + /-Fde,QJ5J"D#FMDtdV.q9!:CLaVr?DtkE-_P+gC"%WD97M^Kcq0loNs24bA7UM2Lh>Akt> + VYoD>qs*K^u5V!!a'akXo&)*Q2eo)+7cV'2$&(_)OP"Y=+VBPtQB + =uH?83:A7cJF?oR9(LO\"D>Bf'F!(^*Ieo%>;&@540Di6<^XVD+=,9dc.Xo_sD-Thss;=u@ + @`8Yo>LPhL7DTi%dglBPP\?EmY8;_E0qmBO5[G#"Pi@-?`mFPN`[.&`3HqWl0 + em8XaA@a,n$3e"KHB4E:q*u.9d?I:QYSh6cr'oS3N,m1N^`DVr(/5%bJ[k:=ZoY3"K%7@ZI/M@1[+?"6 + S0eapE1/T;kW);/-!7SBA`9j/Alb:t@mh@71_Xp_N + 2kr0g%S>-U`:,Q^1qEuX,;]Qo<)keU=&r>/F^E>5%rq0H/Fi)Pp/6^c/Qa.&au#,ViN7l2a + e4?K#TiXZ8t.187qC2;eL:!6u='\f9\sMjQ\VI+4DuZ> + H+l/5_ + 3j%[:/-XpG'jFf!k2eo%/mF?ghu;L'>0AFhY;brSe49J#lZapM"+T>-0BKeGG")F0,?W)C7 + Mrbo$h1T[t\0WT>)sQLKYeVpYk*RZ^o?X%ASFl:Smi85F:R0I]CGf7pjfeYr1$VOPN*N"n& + !*/HK3^LjZ"l^-6\8qd4^DJe1BX5r^:s87VElm"'&[2R(;,dY\:6L&me5i<`L(#pV,UBu&m + J"eg#kL(M?B2"e)T(=Lu9:iX^qk;K&fe3AUu&X3^f:>VXB^k&X7.`0hN'4Q&ZM@i9W6&5*_ + TAp#R7IZRmLk8(sA7&>5TSu49P4E'dbDK/o2+G+/)c<$t0.4^LU(g(R4SW["LU?&umV->?auGsrocKju8mBP/ + T/ER<-`%NSPqeWpXf'so3jLe;.e1hZA>fSa?uhf6`E,AS<@+4e2MY2AM,A"F7o^5elc1s\[ + "5&L0QSp.XU9JJ(%!?I'kXRJ]"",>ni9ROAs^T]@koL%]apC(_2QOi<@JXhWli2[s#$.DRJ*.(M<&?1M(atp#!CuL@JS3a`lFk.>rD9oj58`HZ$oQ^')Hd + gcObKDmf0(h8Pfb6RLB0o($%[%R#Jh6)"^nt\K5buE_AGcFL7B]?XW-]8\)Rp+] + K(_Md^?C/ZDNf_"?:@d-cHq#'k4gYMfEnn`XAgS#+R8`0ZCcD\E=lB]1m9Zjo2@6!0?,BC'K.1kq@ + G)J2?M@I#DG2BoIEP=Capn0.GP7+,53M/%HAX*&M]c564Cj;f%uobf4.]"JtrSLL"Mf"]iV + "o + \p1+>!q@:h8_Tp&M<-dGH&^=`05.X:&2PJo(Bom\u"["Of5NCNmu*.G@4.D/;X#DhBkmBOT + $SI\?=F:=eB$c^&Q,tpE*Q8RcEgf@Ch:b\N*"NPo)\a03$dS0I%Z`1dTPX[YRX(-;TP]c?= + 1&l(d,]O+$R/M:$W)J`L&LP&On9apq2T,ojjtF7Qll#Y.qZ"m^GRSGTeerYaquLTu"ZB@:S + h`[#r!N:c.med7CT.ilEWG9]?.%,X>r>n=5b^A6Y_7\%r]+R*RAe#iF0m-!2o&g$`']XO7!#@"Nd;&J\U$oE8c;i+*>#9mA-+,R.<8pqOiomKAkq!SnibNB?"" + QO-A05O+s5JQmj]@$NG:1$,?Qh"[>b5%Zto6t\fo6JO)OrlkVr<^+2KVsWicVQt%B'[+QPF + gq)s(j^f1Sr'GuYcj(;@-lN`-S-^qr+E+GfpTLbmSkH?4p1m>+FZ\ + ]BTB0T!+F?K^kB[Ri]YD*\`?4LFDD.U#/s-#2nWu5bUUP9+ulq][8H$T"EVUOFGNl2/)sF + A;hDhr:,cER&.Bci`,J$WC^BB/`$.<5XDnMu\M7cM6pL_Y,\OWOE]Diq7oY5aFC6rd'YNJ5 + 4S3,Q5laEZN&Gb`6gPc0`!o5\J4SaHk_Mc;fF/Sq1b1+3<'ZgX)4%\A + D7=;R<*5bKuZV=sY^G)0PBSSU@_8j?_7A,mignb:p%>dI_\eG\!m,QAYJ',"Y9#SHg.-Ea? + LmXF&,3#\$X@IKJ-(p"OL(Sc<05SCl6F.!R3=Q8BO%gTSLeV@`o%/7= + ,;9!.n%G_?a]a]#mQEr<^gWOEdGt-M*@/]<@q\$]k<1eAJ + =Gb@k7tFgp+Z\ + <\_N8qjNS/\BcRVUg_G3`R.+Gh/Mc^t][@ga0hm28e3<`8"A3gh"L\FiW9kaP<'&gni0K[E + I@EbhUanguZh`["Y8<]\O=MRYo4OCOn'SC"T!)%/$,rA_5ahr$ + @@auIFaM+csdN4n"Q-0*iJ/_Gd,^[p^H:#"F1kMDKghGrF$SS;DIC0mRJhDO]Wp$\s+hO+! + &7*GVf!6AL6oAEhkg10A\H::d4L(L$FT]ejo=6=cel]th,WFl#cZ_T + "5m2`N0X,H%JX==U0p_%i2-j=ecuWg#[jm/i1:D9p(*$t)W/dYhqenO/e6hu']Dl]?_%,N^CQ:L"j8E?(.jJAY/[RF`H+66hSA9LT+p.sc + S:urHij@2i)2BZFD_+#>RAL:I>G$!d[=P>Z+jZZl,8K8L;h&XmRQ'pS9i6p`l@-/55jsFR" + 2Ikl=AEHp(T1F.fG%]rlB]bUpk,)nU[VP$FD!';ck2pRDp2B*uE9A!Vk9b642KS%NFQZ\Ik + @So#G&EU@A`oA)kGERg[X72WI-9(/kN76Vp4)91JERc"kU(oF2M:3_K]lHjk[oS5G),:9M! + 1.]kba7$[Ys@hN9JiPkiRogkdG'mA;?b=LR++(&[;Sl?YNBr$YG]_%[H:5Q"bE-l&M4op6k + 0RRq\IUC!N,\fRE)QR-DV`l!C"I#,2@bUM<8jBr7`kAtS?pV.t1Ll#s&kVOd"4W+qotl?9. + A-Eh10VX!TOCAtMS%\@GWXD15/CL4%+hQpqa[VIM#CHf4CSuuk3U[([fCQ>o?^6e/7[;5cQ + CMq"**jfYl\SP$QCX0k6m_N\aX)(h*m%0a5k/6Nib\PeNljh5'f"Z$-_efn0Co5QqI`H9U` + pD!rCYm'J51aTla_`r0D4])@(>%rfg2)M\m7,LjL>-PlbAI76D=5j>hUq2_iU,4SmKV5/k2 + g<3b3j/lmXEsZNnWnZipITBm[if`T%S#Dm-]VuDPkqOY4$9Un8;j4m`+AVG4TX,ennIYl%% + ?@#Q~>Q +Q +showpage +%%Trailer +count op_count sub {pop} repeat +countdictstack dict_count sub {end} repeat +cairo_eps_state restore +%%EOF diff -r 9b9a2497757d -r eb146c5c05a8 0__Papers/VMS/VMS__Foundation_Paper/VMS__Full_conference_version/figures/Scheduling_states_2.svg --- /dev/null Thu Jan 01 00:00:00 1970 +0000 +++ b/0__Papers/VMS/VMS__Foundation_Paper/VMS__Full_conference_version/figures/Scheduling_states_2.svg Sat Aug 03 19:24:22 2013 -0700 @@ -0,0 +1,210 @@ + + + + + + + + + + + + + + + image/svg+xml + + + + + + + + + + Blocked + + + + Ready + + + + + + Progressing + + Stalled + + + + Animated + + + + diff -r 9b9a2497757d -r eb146c5c05a8 0__Papers/VMS/VMS__Foundation_Paper/VMS__Full_conference_version/figures/Time_in_VMS_1.eps --- /dev/null Thu Jan 01 00:00:00 1970 +0000 +++ b/0__Papers/VMS/VMS__Foundation_Paper/VMS__Full_conference_version/figures/Time_in_VMS_1.eps Sat Aug 03 19:24:22 2013 -0700 @@ -0,0 +1,943 @@ +%!PS-Adobe-3.0 EPSF-3.0 +%%Creator: cairo 1.8.6 (http://cairographics.org) +%%CreationDate: Sun Nov 21 13:32:58 2010 +%%Pages: 1 +%%BoundingBox: 0 0 330 127 +%%DocumentData: Clean7Bit +%%LanguageLevel: 2 +%%EndComments +%%BeginProlog +/cairo_eps_state save def +/dict_count countdictstack def +/op_count count 1 sub def +userdict begin +/q { gsave } bind def +/Q { grestore } bind def +/cm { 6 array astore concat } bind def +/w { setlinewidth } bind def +/J { setlinecap } bind def +/j { setlinejoin } bind def +/M { setmiterlimit } bind def +/d { setdash } bind def +/m { moveto } bind def +/l { lineto } bind def +/c { curveto } bind def +/h { closepath } bind def +/re { exch dup neg 3 1 roll 5 3 roll moveto 0 rlineto + 0 exch rlineto 0 rlineto closepath } bind def +/S { stroke } bind def +/f { fill } bind def +/f* { eofill } bind def +/B { fill stroke } bind def +/B* { eofill stroke } bind def +/n { newpath } bind def +/W { clip } bind def +/W* { eoclip } bind def +/BT { } bind def +/ET { } bind def +/pdfmark where { pop globaldict /?pdfmark /exec load put } + { globaldict begin /?pdfmark /pop load def /pdfmark + /cleartomark load def end } ifelse +/BDC { mark 3 1 roll /BDC pdfmark } bind def +/EMC { mark /EMC pdfmark } bind def +/cairo_store_point { /cairo_point_y exch def /cairo_point_x exch def } def +/Tj { show currentpoint cairo_store_point } bind def +/TJ { + { + dup + type /stringtype eq + { show } { -0.001 mul 0 cairo_font_matrix dtransform rmoveto } ifelse + } forall + currentpoint cairo_store_point +} bind def +/cairo_selectfont { cairo_font_matrix aload pop pop pop 0 0 6 array astore + cairo_font exch selectfont cairo_point_x cairo_point_y moveto } bind def +/Tf { pop /cairo_font exch def /cairo_font_matrix where + { pop cairo_selectfont } if } bind def +/Td { matrix translate cairo_font_matrix matrix concatmatrix dup + /cairo_font_matrix exch def dup 4 get exch 5 get cairo_store_point + /cairo_font where { pop cairo_selectfont } if } bind def +/Tm { 2 copy 8 2 roll 6 array astore /cairo_font_matrix exch def + cairo_store_point /cairo_font where { pop cairo_selectfont } if } bind def +/g { setgray } bind def +/rg { setrgbcolor } bind def +/d1 { setcachedevice } bind def +%%EndProlog +%%Page: 1 1 +%%BeginPageSetup +%%PageBoundingBox: 0 0 330 127 +%%EndPageSetup +q +Q q +q 0 0 331 127 rectclip +% Fallback Image: x=0, y=0, w=329, h=125 res=300dpi size=2165625 +[ 0.24 0 0 0.24 0 0.991089 ] concat +/DeviceRGB setcolorspace +8 dict dup begin + /ImageType 1 def + /Width 1375 def + /Height 525 def + /BitsPerComponent 8 def + /Decode [ 0 1 0 1 0 1 ] def + /DataSource currentfile /ASCII85Decode filter /LZWDecode filter def + /ImageMatrix [ 1 0 0 -1 0 525 ] def +end +image +J3I@:BHu(:pOk^R:T.dk*=mro@So+\<\5,H7Uo<*jE<[.O@Wn[3@'nb-^757;Rp>H>q_R=Al + C^cenm@9:1mM9jS"!dTMT<$3[GQ$8#0$s<4ZX!SPQ1`C/mioWjnAY&^gM+`4=1jRLW!YA=M/6)*KS9PE`kN%="Tc + _Aoh+fk'&t\ctIN)4XQLiVpoI(>.nOW?*DmsG$@,,f58"PDKfeAJlo*B]ZT!'31_l[h@F?.u;GBO/Fms$q.0(\8JhnaScr]a26g[)`OH[c!ea5-IbHN.>J^ + &uma4O=2qs$*R]rqo%N,N/ekE&6SU_%/pY#XOP%r<0s`>VcdTn?Vp$6h#Hs$,(:o3t4UJ1d + _,U&KE;87<)6$&4UXR>8tG!P4okbE:do]7$5Dp*BCCsHPf9CjGP9SnfmZ1_NaKPr2cC;DiIe + =]UeUj&Ji3AS5+DoHeiff@<$:=41&B!EIOt*KsUYFo?So=&oL$B%e#sM.tF26Ti%akKdi"uq-J`)nJ%>3UV:)/KAQu + 3q"iY[\%M;jo*/W8X+c8CUAR-m+uj;AFrOfAd`n:WD!U$%]D85^LXAf6I&RHBp?D4'K(L2E + LD\^#SOB:9<[SS1%?LS/=k^5o"&3Mqk7kIM_.VeLHHVl/fmm]ihX]$@^_CHC=GWp8=[_6.G + Ip;s^Yq_lp-laqo/ZtJ-*Qb..IQLh\)\o,L%Dn8]q]k9FI$c6e.G5&spqr\X.EVpUTU@"*&ft'F*r`Zd<%L:n'Gma-U5juI-3<;Bq:#`eTLhgA(u0T2b2\G]Va`?F5=$Fa + S4O8:_*l/+/6J1*a["QO0C67#A/A.DtpsrS[;CL9X2j^,VAoU1@>\O]jA*LoV*Hll_7l3\Wu. + gD$Cs0o&V8,=2&86dB[m3_Z@5(7&DoU]c71;@Z#a=UcP87#@%(/k/Cb*@'WuOciU;8kE/;- + 03"4P>Z9n8_H6SjTM9A;N=XI=\U@,7&cGLY#\0J>q>#iZ'J;5>"`"8/`jp]QW!6X9A+_Hjo + iMf;\!81=cG/u7*1iq/nRf1SMTD]d@+!/C/%j52>"qTQ74G'4Y*Mu>>ta@_(SC?:RT!C,:$KVWVc<)U + ;qcXq.?sn2oa[]q>)b^V#nJY"XQ^N]^s)#qefFn8WWn?_:hT!NX&Vu!<@X&2lNHIQ!!9CU> + 0U497.@3VEiTD%a&[k)>cZDP\l7n7?#.E)Y>t#)=5*U[lihs1AJXkWg1lP=kXU#XS&9oSCt.A%#>0[b2c/k!c>9P%:Sc29EC10'6EnSTF&'^:4sdZ.r!GF03^=]2rn.IY7?\Q>6u?ebNCn"ApZf*_E_HiJ";jp/_) + 0*Yh>*J:"UUdF'/u,,^LU,UTdM1:S+rF + &a`=N!.M\a&neM@SD'.mTqlm]"8]`]>&!!l3j_R?R2r;9E$:ULYi-N9tdG3nW=,A? + ;b9Ectg6=cW_tC&aJ'L0>W9Eua5Qa]Yq[DpD>F'G.:4C2\Y"[?O"_NZA"fm$;Y<)@j+:h#F + '&mE!Zn01KX2*MW0[iR.>i6"rJ6Vjnj+ep"BqTFWRC*F?akt$TUM_D_N:.#Gp6La#Y^mD8+P@HL2\:7IeDpUA,N+pNcX + lB:e_`f#t7A>!L\e4h0lag6p5mfm#1mDk-dHaC5)44Zg-*!$13Edk:HF4@6Ca-,nun5[n?E?T[0mODj:G@bOBW(]?H+Y8^rab(OC\L=M#_Fp + S<.jo&?GjC'aMPLT?r0+Y_L1pTWSjUWt:L90UN^HS=MA.":X)nN-,8b[h3TsSM7Y>OM7B,_ + XXVO"onZ'OO4K_K*LhtbqC(;d,=dMr=3d.%^:Jl&0CMl&0!>2&Wljf0`M\=#+Z?1$>INfYs + f'u)YHk@[1,[Q0#jU-V!YDT&l57j:[fImSA6jr#n`>kN$R!%<1M8i\.CFjd#+IB#cqtNSM1 + cQ;)Js35n'aM)DRj#ER:5#f,kTI*ASWYnfZ4tf,#P1*NAWNl2)4ci?%OP&Fq\'.H;S.rrNMI++Th&d-.?) + !iRjYSFR#Zn7j'9&LJsO,Z6QF12un!-JDE+V + K*kDRUQ_W1FE_"7]Y$dbQ.,"QKik.uZUB;[V\#Ik1#p/II*>'%\aS)(+r&,RMQIo-H+i!hE + 6V#H>m".JkEjfe9I;#kK](EBc-u&.K9^2+d`Bdb?Af))cPM2QRoRc)!0KSt7\l/'nA?1Nt4 + q2]P+YVGciP;a:A4 + ''gNOs#B!;3AZtl;jumUT.Vp1S[(ZS;suFsYr*3'dF,nFo#T>/bbL=4XE3&Hnf$^JlOqJ)T + 5GH*0_h0D&OF^m2lY6+P+`Q?))e1@.)0V + \0r4B+C3oPmAORmZIn6o"!pPXuLEbs]AC6Bm$WoMmonbsg*85."dhP\-Q[CFI[G7oZS;P^, + 7;4Z5-t5no"]@5Oi\)b'Bh8HH^^e<`mXH(J`>b:XU[g'.Z1_)!t<4 + ,1RQ/ePe-:j$nam!i)oYpP=H8b-W1Q&#aRI7r+-=Z$^eaidQsRi+)rS5lH@[? + 4Z%`D73=rY,R4nuYBEpK@1J<=`]UQ.9.4a&hro>a:!knVdG^M@e6p7'nKgPUVR@jI<,H0Rb5et0p0\B407YB9mm*p4$h!WD_<&:"G9@PQ*1U + pna'27h%-l,`r)SefXWg!#&c!F5qDMLCBIt:3RA)!?RR,K20+53%KJMnV"DJEO\pS1JF5<*pnNQ\N1 + CfdCDa4GGdE2Zo7`Km]&2pb@VmQ[VNd+V&skbC* + )%m>=eo:,$0S3;%IipsJk0J#UnZ(?^a'07B6FSG=/[Y\(;r,h6#I@ehT!3AH9!2jS`':>%^ + \$."hR1OE6IE1$BamX^WHTp9Q`P*Fn)Ohl/8CRJs*QMCu;\0ZOr\!NG$P\Jm>)'P8Gc'!?V + -M_"QQa;<)R(HFTO@gXq:$1X,Nj*#qH$R4=fcH^3/LKuE=P*A8)6BAh,ESnX$5pZC)3%7gV + &Pf6RX)lBCc.amLRh24SUoajeU<@#kb#EFS[mokq.@nS&q&0:9;^FIEFaG[ + 6ZI&Z'eV-UY#,/SCV_ri0-FQ8n&$.PINqfqS4*UGs?k(j)?14a_R,>$=@\)G,k_8LF:0-(5 + 4.fh80QUnsLo&"4?kWQ1m&mot)_Sf(D'H7*1uI@g:nWHo)B9r4JnO.Z&ATJ\=#Znmh*VS)` + J(_>W"fj=/h@%>kubo6Bg>*#'0ANijIg_lSOd%udYnB]C0D7LONGVaV[ + \Zp+1'\GpYCWWb4rNC0.a%`B1RlaWlb=X8CYc`+C>">h0@l6=eZ;lYi4!Md\d+>l[E-_%rf + )_peKT + 7YogW5o>Gh.3nYo/fLRtRYCM%CVc$5ohRS+*1WSGKasSGN*'P4u@A,t;%"Fh>&nPJt0R+1t + fcTDKX=:><6,e%K1N]t0oOqn5ms1od$*]!g_8.iDZPV0+ + I#Hu80WjQ%-qDjd#9>>C<`!eH@lbg[ZV3Kb9]KBCrgjlh<@sQjB^`$+AS8D.dEMtfN@N9Xa + >^adX[*"o&`XR^B11eP-WQ=`]bGqhhGP0(NRu!N>V>HABr25JhAV3+Jn9h^jmgm@\-cfBj3 + 0+i!!;9?oTCO^'QbS-rk4n@:YL4"OMcW[d2si9dPu`uNa&DQu7OFj + <9Z)-hJ2!M>8PeXjISM:^E#;iC[ipg-GeM3&Y4@[*Bg + Cu3jmUNkc6\\*K&O=Fk(=,e[G_5$TH.TQK,++:[oPJ(cLJ&Y5hi+9C9cb2.PUT5B/6^]E$/[FZ@UdJY)pl,h`Ze(?Ge + WEn?>pib5:2\%u3`Z775rBiGj8)/sQhjmX%h,WAS"_QTtgHB)=ILfBU^YBuZgjCog4E@!!- + 0(Qdh0q&b>3gFEm`GAkkPgFCSr;h3Q0EabV`p=/^7gsDTB\:RkVgH'?Dm([[&3i/l[HP5rk + Y(q/aP[CM8$UgZaVJ7^$=sZm/GE"lPk_1iU20Zm_/_ihXQQ]h=!*BO4aQPN1o]hq=&W9m!f + ?2rt4N\"n=ep/,pFUYdf5YS0L?Us_f;>!. + VosVX.IpMb#&b[;Wi?(^;heVsNFn^B2pV2.Ns+0quQ.!&4m@T+-s,m+AQ2,otq7iKrrd^(; + Pg7[)n/nA#s0;Gc[JPHaqnKiAl0J'BL8A,AbjC/E>es4JKj\\U*8eQ?hojAp_:9]ir@1;`s + 4FUg(&gC#X1bk_&,6hK#mGrIi=MAU/f>+R6fJ[pPYNYBMacY;oE5BO$IqjiDb+\'%'aTf5':Nd`Ufd[b^BgS(6rrrkCYd%u_1V#kc)CT,7gfpDJ= + fj73jp5#32=XOA1K7?O?*BZq-3'^OnB8YsmMoajfWY.p0!j_O[QtQ%Pb_&9.WS_Xh + *$,n,M8eLpq&GqXl^.\(Cb+6kc-pI"VJ$:I/luu%h=#Rc*%l-pT6eQM[[Gftj0RdLD]0Z=Q + d=on^H\u!T@O\Np;A[Z@J]1Nb_gMT/P2t&XM!i9i9WKXX8K`uKOYlhEMB9;[?/Pc%E#3Y5-$uob&83>E[6Pf8Ef\`e]01.G.' + c^Zut_c`5&Tn.h9B\$u=*9U().V-;_+5=Y;V8AU.unD@N%ef + dY'V8m9SIO(qnn"iG=bG9a_;+L]/'D,PR=;.m5$NQZTRGGJMfTQa"FA^iX2N7d!s"aOGsF! + ZGpfQ0cE]\`;7JVG941L4ZA%BEbe,$0`f'ZF`!iCC0='l&KF8]"HIeu\ME3065jaj[;BYRT;]&?RW#3jqRl^,k]kmpSsgPn^S&;&`lDuY4(ep>?u/6U1EQI* + M#gu<7PU[308>;-DTue4&N.e&DXsK**lsSCc*"7*nD-ONe"Bc\/!=r:G&i6dguga,oC04UX + %SnVe^X?m#D:u[DI4dDprG[*-$C.In'EF&WDChqSY(&PVS+U#ebGa!]9[elCO+)USAas5b+ + .XlfD<,mX57HJ\%VT!Hp\(V=A2I'a5MJ6':4o8YX9/92`hJ%JL,uHJl6qtE.eqUW:M]/M]n + .!YFUi@olBpLMt;RYS[Uid5ld$%?@]-a/#$\iLEKg_K'thC5m!GWM=_KomV32seacF?`#XV + pp)cZsGmE7Q+X(e5RmL0W$-(1<?linBnp9k\a':b8Pr:!\["8FV(906m5DE + R`'de!XYP[M6UM*`<*dgU81h*:\:_UPFV:j"FDeurEkV=b5NB$CHFpI^6<6=6;l2hJgnY)@d*tLn//Ns=.p\2PZ]K>DE^Y`kelIA23B..7t:ma6Y/BBM:*.K'8\8,:tt2tEP/E>Bh + nnD"M:"`p0T6t7+[^@M'8%R<6ScltD^U]K'1Y&=4:$? + &/AS"W52L(ihm4J6g7+Oj-\93NB;A&6]j + FOlp[H>mgOm2r,L-4/%^,tZ*>.>ZJ.$[qIo4'?eUU6>ON*,(ZA-bnmYGV[a\H").'>K>I&o?f@q4'B'r5*Za?s7g@B)rD=++#kO,l^8cW/ + ar1tQ7T$uKV%.YJDi3Ua9h-E+hfkbfdO]0j"hKN*lD]QF%UnUfEbL:oYebb]bDK&4KgdTh3 + c+XtM_U?((gM[8n_3d.\.1+(BBo*G;GKU0JMfEu\8OC/crs%:Mr4s-Kp.X(HrQl2;.II5*R + .^mo^s"S\0,>A.R(_;6Z=A<%r]@*ASpKD%l&05`0t(2qg0Yh>N3B*8;%j9[K\;]Q16tk]NM + snWU2!f8AE1ZH+"lSi0pf1H7)7K.%;&9KP&d^@W]=E.jcXnTigpk+R>3S14N3I>7WulKT0/ + @;7KTKT0Q>4FMpH3&)-_L%A*fSWqP\H+ + SWc_4he8n[FBtYsL[,qM;Giqe9]l>GXDIq;M(Er&q*N_-n0[uoPYNq_gLg3UI`6o<#OpesR + T`@fn3qI"Mr9p5c*KAYI,5uA`%CA[5,`J&?j^[,mSMFNA,k@LSmHrlFGEOi=";c&_c)7sn7 + ekeceT54[IjI3g=rN[Q#5="g%OSqKMBd5B!N4tpYqqSG'qcKQU'XV5?76fZ2,k.EpZo8^+G]8p9brVfJI6u,%?`bl)2DpT3(=k+,H#,W=AYA$fcHf9qSrX2o@jBD#=gap&@q&q`%79OO(Q9r1 + ?O;T9_?uIt*5$YLEGho@FN5B"6TM#he;Ud$_YiJeA.l$*n_:UXD#PS0r9H,tT^P!1#ajrh/ + ;^^aPY.e-$$s"V5p\56J4%//#NtG,jm2"69e$+bd#_O9ka1$F(]F6Qjg^FGc2ieq<]!Odj)rA??-+K%t5 + iU\;4?g]282?Do`!GMD*$IPAb/?8'%V.^b`'-SJ:_@M8]^[:9ZqNk17aL9"]JXD;()4IB(5nU"VENu!9ZuF8LLd!K1:IAr#U%DS,BQtGYMFIRRu,Q + 2W@GmiqR-N8a)JUZ1jOnaD_&JIQQ0/AK<`L&Le*J]8=YQ.XG]W^N(D0P+.S(m98uKtO@]kC + 8KGg"U + _Ko%`N)I#9W(L1W(N#J8t;nRXK+t'LWWgi6X6]bm&s%ZYY,D09,t61/$D<$\I\>09/O(MCq + !&b\4_dk9:WR7%'<*S]$&=29AI6Sm(Z3k^e>$kbIcEN'Z3U,`(WkD9O,S2Cq`RgLWjk^9Us + 7!XNO;MbY66-a_A^cI)=+WcqOqr9cVSU/CRo?MQ*)Xs$;;E9cI1RRd/cr-u;B6p9>pE54#))q$!M(Q8BI2)T,Z9 + T#K\\+U,p6I#57Zf(Fe.\pC(*Ls`%6:5U/r.aZh]K[XL6e5VSPgdXNiPYc4C$+5+ + _N7uq*Rb6?B=`bY&m#+s`mo_F*=?W-#h/nLUFkLPJ`usIPe5KO%PZaBBfr_2INLTtPSLkdO + 7/7YQF=We[TH"%`;D@Tq$R3\F!]Gk:In/:#4i+nOA&m>CU + 0E-J83@G$nO1*Qc4kW64K5BEiCCmC2Q>_NP^RUW0rEZd!*Z5B9gu,:b0aF'=JG2lgYKBDJ; + @F(iN.9q>I]Ppc,!A!YRcGZ]0n?igP9&SF:#Xt)r8QLh8GOP`NoH^O]C8YJ@PuWaHR.`^.l + aS."g7\mTUUD??OMfjg85kOWN3UZ?p?9qn`N#p^1TK%UeX((kk84)kPI6PDU+3WO6!Mc!U+k>jY;>gIGT)gg9>8)`??*36Y_Hh-V]^Ln4/L^%FX5 + p;)1POM1J#jnde<'b;/J?e,C@D:Ssj;c$b!;_9fV7I"7n04)>X>?aTFEo]/J\r2RE7jrUQ8 + IO=PJR@(<[l,4`rZ0uMq*+[s6TMVFF7R6#R^)Wu@NkhqI=L/>q;rKhP+%AYXjrYaC?BV`mi=4UIQ91L + 8.+QmMbml5Tjuuo?j('BhjLtqV*aK$m6Oa5f8--Eb>.*F/7uX$1MIoHA7O=YF@:eYRAbj$Q + `_PYC*b>D!iAfB.<%;H82i57W`h%#.@ROdHJ_kt;?BWFj[TTV/j!SESAJ2)`-:#%0I:j[]?.n;pS9T\G_chBM$*C,'FuEuYH=`+q9a4eRk'?.BJS + 2-4`&$K,$GU6A*FSI=BFV0/*WCk1`oLY]Z@7uCL5#sj7R_,R^h'^*2MlqgMWJH.L_b+S*d2 + "9NLh29fPW$C2OWgkBaC.i=TX<=A7SsJ0.H2Ah$_],'J4&k?0KkD9YQPH]l31YgKJiTlCEa + rY"'fZdqX7l6^0Xs#+gZu@7I\rl^9u)ETC7:[94[ql96q<*i2t=Q/gF6/9VE>b&_5mMBP`j + #V5?-QG(4Y+PjJpLqtVOFu!gpYK";sCrX@-k-8bSam1O\/Oman/s#@LMp8p\7d9:eq$8=ASef + 1UG4V:8k%n:KLs#S`C#h^/Bn\`^LJ@[,VX?lrLI?%M5pl@l*s7bAo5OWGDbA#>-O3+>nLAG + _-[uHlY%M[oMK)mTEJFL4hZ9;Z!q?ljn4i9'k1=QYgW*M_k%Pe!f+dYMPD9WpMEQ#;No7u# + +E>dhnII'B%h_&J+)*)&DQaPb%jDS",B='Jl2F&--RQMbd-SM"].Q(j[8cQWK6"-4fi;YCT + -!Mm22Ks#kPlgENef,BEt9<2`BK!]Eo;#anaPEgF-0DlVaa>J/$!S%6g$VsGL'jkY@'rL52QS%a*;"a + Q[o%-m,f11!8]_%&uMt$]WO'(t/J+]D"]2r3UO%]/mcunLFoM3g)'?bEGE-3[B0c\`e`oCR + +jD[%g)IHOEYq?'tGRG('pR(GnIl)sC;Wp`K.k%UY2OqXGD![c(4-cYG-K00^VKZ/1p-47( + QXpdH13eU2GaMn6W;Do?/B(BZUIl-,T$<')mYSE&E6Jh)2h?'PNH"Ulp(qWBDF + [pNG=,*/VG,`8Dq:M/:+.iU1TEQ^:G&!%^cMr^k'VdpH$RB3fH\3pE'Hp#2jA0>')GFWqIFG2;K/iGPV95>$(n4)B<, + *gh7_tsFVPG_KXC/!@rm?fqY-Lr7lp!7W/#lE!+3kWGR+/V0RV3(L(B3%:O@?Cg1A.5i9ND + >+fgMYe0tM@B&l-=9&KS[.!S7kHsmM8S$7p7&Es7Q:kf;q1Qb!1R_$Mds8lZdlWGMkL5k'#),F=;/"I*74+9mVGh3YqLq + D8,!R][2`].@o`:`-H&oi/SrbV7;ahfUY@+JRt3KZ@(JY,7,*?k7]3t+Dq@A=#!6^ + gf3%eEX9g`e=^`L6knZTQP(gZVcb.0U2"o3XF4mJ2@J9ZJ>.!".]1Z.3E9hWbrJ&@(ZeB8> + gO7!t&%d^S\(dJZ"]<1U?cP9Na!KK`e7C$Jl%U&ne$*rAQt^.%:2'&]mes$/L*LuZT-C>n7 + R"RBf!o^#%kh_Q&bI`'L5=Zhf-TWgs)&5G!5MDN#m.oh3W>S/.I)Bc6-t!&#f9E..13r=&u + n&DlHClK1l(9>&@eb@/J='u3M@.tYPO(SV9Y:'YI`#ro@/:TKN"#tW`a/_JQ6h'HXKf)>`=P$5&4OH"1;d@tR2e5!rhp&K + r6?5iK*:O'V9-C6::WLud3`&BSiBj9B]a$sQ<*^A2dF:i)"poC".8&%<]eN408Sg0lKs]P\ + ,h,c27]ZchD,>9'<A28Woa^8.Z + %9\QP>del,87Qf_GBBpu.n;'J.>6\(r&kIK`'T]d:8J"l.12Mn3n>#(K]C"cmcVWo(kV5if + A^7Zg,_$VY2KHS:6XD6K"ag(3e(=BGT4$M3'm@/RV\F&%:iOSC2Y49)A>JBjEn!j=T_!eoX + !Q&e\0+l+l>W3P=n[r3LaRU=BXt0dN1+EieJ9N<[oA&d/-O&HE9p1$7&-=#1@DPUfb;lpYR + .^hlB[!e\gpVS(BffGa/l8A4_W_/gj()TbQL65A8JNE0>`"T+5"A0^)^OKtP`epF9M'Le(P7/_!_2edJ9`psV'Mgt@8IU<3)_(NUiA/cMD-peX:J^B$G + V/2J2%&S'u7nc.Tomk7m$J1S/V^M9P^eX;<&LAe!%bjZ7%Ml^lER!eB*/-96< + K%r/XMp[qc,%D$k+VC"rdAeojkp7RMe;BJg>#S#W + <@t&3^6R.c>th5O1T&[QS5W%&:$LGHPHoRkJa#NsC#qdD+\#7'`_$8H?r*c=[\t)O-;Z*>% + mKV0Kb2rT?V:8-Waqu69E_`*%1L0VA4UHp&_\RbJCCWc]!g2dj]lStE3@a:]@U6V?L--iY; + Qt>8(4.pidIlJ4'Y4F^hGKLU+?@bZT9MAZY!]ZaObt=rTb@m/_4D96 + V!W]5t@&\Yr*.qXd/hZ*r+-h5KSm/6JMj<55f:MU`@CRnC0[UR90)&]\hgB@=o=ii!r*N\" + IIG_b^R+rui#DWFYQb3FfG=Zu9GN)pYX/R?<$$Y\;h=FE$,W':$XoPUL@E2&_cV*o@JiQLY + pLX4\;q;4S5G164tX`U],"lRAW1W+0ZMbk)rk1CNq([`a#O)?A.3mJE[F/pfI/HWY_#;0-l + `=L(Em?0To6dL56gk@\cTZ8#=M+4%qDq"?BU"eZGC^s\VQF"'l@(8'kK4ET/74'`gK=,ER* + 7p4>UO)S3Zdn2BuEkAVNSQJd-oBqApH64T&%+ERq*Z>--r$-)C11Pr?cQLQggIV6oBUe(T6 + &.FK9:RA`9ufjN\&UcAtUJS2&OK\+JEpt$CAZn>U>W?QYSCjetecqQ1U9Dp*Rc2`CE)@ + ']lUB318IJX;#L`$+0CIbU1KB`b=Fl?r)qtg=q*rDB1m;#Y(9<>G$"TS^^O0&I?mF][-Y]#e"*+Id&(,]QVfFtRMO$"Y^SbhoV5i="9`CP$N^-,fNVaWVS#MA%\)`m + ,tFj2&'`6V]GYq'RKLg/E#'IEfn0B.`6!K6E?)hQ2q1YW03&,'/lhi/cA*#sf",]^q?#L'OD + MpR(D?0Fd)0/E"6qB&,Lq\T>"^5pciT2]V'=9.`gA79g(U]=7?((K-VQAj-AjlKVco3Q5[q + ;$pj#SD98jiGDg,R_GZ_4Gj3uX8:^Yds-rTiql:!qo>%(%sHok0-,O'4l"VD#8p)e1\f0_P/Y` + ;D=P0UDBf'RMmnP]3\!9iqV(\+ + *[nREI>AJhRt4p(j>0rl44[e*FB)j.lT%7:(hh$jo[)c&sDiggTt'*tcB!jS-^ELe((k1t$ + R*eLd?+t4,"V#$(`pjk:4j2sQh1. + u]:'%0&956[4=,;Jm:d\7>:VI\,T26sAQEj?t=[jm!k'>mNY!Y5er7S:u$q5ibh'@"9#7:2\U)K`/0/)=S/^l"&%:(OV6St!!.rs;P1.!88.kWV1WDbPqP;^X + k3\"!E+S*B-cm!ZET.r&"'la=$d31BarA;T@1,Fe7PK^>a[Bh'd'4n(C#PW]1:4tICAX$^)^YhU + JP[033c7?g_>_AbrUn0!=\8oqs1147>eJN'jk2tBU.[!+n0H;kS99TrOA1.=nm`COH0'6Kj + @U+\0O%51%@$SllZ6D$e*cVKTmr_:QE<;J1G`CtCWlnj1o<;%F*k=oK>;7$[,eC.0#!D]@\ + :?!?CJtGq`.jqY1QgE;TESCPXLE7')3&0Sn<=DWebuI`";=^D\nsrN3/IRg!9eos"ohn#>@ + o]p_G'%_*_f&UVK&h%d"#UfjPm]tpPpDW4eg'`3Q%gOu80IR\q/Jt?d?@O+rCbWh,5%d7KY + ^ZR_BMs)3L+k\2;MQtPn*El5a3 + EH'I=W=^E,7.*&GYk7$]p/+$0NN0[fG5j/au"Yu8KV0iY%n7"?QJ&2@'\%un20d@XZdo20Y + j27;($da`GeV/$%]5iSPB@eU_(5#!K![,qkDh + RY"AI),A3%gOa,52F?(CtQgAS^c%Cc,j;2doju*DMgLD"hI*'e^7Ze3Xr0>BD5-OtgkF*]e + L=+]9^1n/+45k<$Wj8WjTuZh@5"mP.`N+\E=^pJ`>W*%pjR*WdPo1@R?U<&]f%&GK7GGA1) + ZD-;(&AbXt'Eq+Io&RQ>UI`$)Ep[9Pt-S>(K&XSFupQ-PBPWF#V;?>a%nm3qMU*&K&H@c3)!q1n23A2)+&_@\&f@,E)+,#s#=qtafJh]/M%m + e,UI^hIu"&XP-_C4"m//XZtdMO6S'8RhY0,TQk(lfbAOtKk`,5@X!=NDbT55lBdM`,4*GXm + iSDhM%GX+CqAUN:::@r9.3GLD+CD:^Le>8C:p,.Q>S&[PCMnfh.X@lQFp25tZ,ng%@$Bj!_ + <32'Z'V3&/rQ+6p\pePO*2+4uG5e+Ri=`Pu/a-T,FN7`]DU5>2%Z4DO?Pe[Q#bU8],MAK8(.LA>DBG$Bj5f8o^3MW,qL@NV#4[m?)%6b+:3[7Q+=l")TaP/8<$_JVCP( + R^\-4#mh@o[0.I]9QCXQ'o74q.#]D!Hrap;L(Gb"LD + o1qG\a2)0HR`,':"S6=3?(6Pm<1>abVg)@*9&@AmA/Wd'1ZcS(;[pRca^X4YBemT!(E^G:) + E8pg6VfNaPcU%g@cf'>m+>0Wo@#Feo;I/SQn4LZ1*HgRigADmK>5dNu1;l*Z,.U75=4g + +Tbk8$p91YM-%Q;qJ?[?m0j_q\o"33`i\59<\,i\7-8_Udoq:AM?1.9/Sj[oHOXm(T6ffW& + nXKR"n*T%:b$a\.b"2Q&2j%K71@iLE!M.gWUj^BtI@7AE*E[e&SkCH+nl_[JT584(YbX7kX + r4]:+qjQef<$n0]0&qYS%;>Lg6QEO5dG]pc7b2RF1qi[*(co(rqj:AYQgJ%D*iW#On<\.ba + N"/o&a-EuriP*`gD$,rE=(VB.Te^q>./\baZ`*#+(S4fb!a-/*Ge\`pto2oU0"b1s0.ggSADZ,'X_]c,^A3SDDT>KQ_N-(Lg>4LQM?L!eRK@RK + +93%:iD+*>b/42#hPOdnWW^p(P_O]>NC*a]\A?i^)"^0+RoW,SKX01=OU`5LuB?m6)35qt8 + 8:8_#O[caIuH][A(]?n\'fY.:FsRB+ubq8fjqP#g`o[d+iYYL4UB`o-ZA@e61C.q>!6Mj+I + #=.10;&3RJM"VTq>!Z!r-0?4ZSepWnA*TH2:ERS38,sAHd,2q9c+5=/b5XA1pF:9'.bM49Z + gu9E$I*G4@_qg`=b1t\,9l&Fm,2HBLg/4QtSTZ9*$8E_/+JKrVSeo8^8'k]uE#[Mb4Y7;;h + r6h(jj!VXSJU/"=6"nr0i^/C=r'!07QA+Tgfjh7*`]V>+m&)QYo=F_SOq+r+3rWidJ\G0o' + ej6@q!rDdC96.\r&-#X?O3N+uZPG*-[dA\31nH&cPqs^=2IDNTNA9k$nd5*`)hXVBAVYlJ8 + H`KO>CD_?N+RRFTD$)4*P7nt.T,%2\EH1\6E + FnUEUF4t#naT:LD*S\II3+"d.-=7qDao7(!<"Z>oO@]TMtGTN4FQRh`9F8);Q;ZC+uhh"[3 + BD>&4e39)e>tat#kP'Imq;7c;5CrYQVF&%SqM/M/1O5n4PtW:'=J))[ho#@ZKDJrqr58^6h + p,5oD8X,.rD`Uj+5d')kEgM3m$buoTCP;*e,MierIP%LJO&.T=>V'2$&(_)OP"Y=+VBQ!i@ + QI^!\kRO\7:XloR9(LO\"Pr=Yu^I.@!NeP1ark@540Dk)sgKhDH,\:?Jn9o_sD-Thss;=u@ + @`8Yo>LPhL7DTi%dglBDrV??-#lf'9ZsomX_cYup@Y>;`#".Qgo#,277;iGlD5m[%$[qXFB + q4tht4p&=a]]ft>`>IGS;(26fZESO#J+d'lWnsNW;h%*YZLU,Ugp4#B%d:i0@>rJOD + 26pPd@BnL%p7#?q`n#CCg\1O#pA\uSIph.r>Q+^"K>PBJ(/.aa0cY0(HC\BO?a1ZrAuD2kp + OC$nf`+N%YOSj$Y*uOcZXt(Ip4/Y5+ + tGF6ajf1(t`-YACdMLE7F6ic;iO<#$g8d`e= + 8gLb@ohH_84[2WCd#CAa9W61];H5SS=&r>/Ego%`1S%kC;fqC!:R(OHdo"_8"U^48p%=):d + >SKt,bF^/"Qi^kZ?&]ALg`/U.l5-1K0o1;W(e3hoq\hD[f\7Q6dG)>FBph*f60\bMD88iXo + 5eG9(p+0D+_7u]PQFsV8[pB[K80l?oTu?@n>diP9mGtSQBI!gXAm%YrQUe^' + 7d3>P,JA?<2qXZ^qc;i7j)2DJ$)GhuKK?sj0HRV+9c&pupnK*=hL[:UW&\p-DNQs4a0n>q\ + >F`WHak!#]@%uSSB>gN8H1CBh5ap_VC0p\<,CT'_>?L)=NX*^W<;)P4fH@8#VTle"S\&ON$ + g4\&KekM2*'h3>_E4e+?`$Q?jj2A:86=74i.+YGtA]XSBA*lhb65u$^Z + QT-81lUgbW_(:T*Bu'L+hPL)]Xe]Xq7CRncPjCWfuJ['2nA(!,uQ^GKnprB5:qA$C!:O_`k + Cs]DB\skY)HQ_IsR)@^>1g<:ApLWN1rMF\;bh`EjK$&5@=NaT`:UuP41RUMuJ4@oD`?=/X8 + R'*qY9;e0WGCqnD&4ptiXEFAISp^uVlu>`uRFUe1eT3#MiibOJO"c4#eimc`RPAU$]8'>h( + DUCJ^J39BsjUt)",P)I[n:W_(Kf/0'<6jOoNnaWAP'):E&s+a&u5EPO0g'BJ3K&l#U3J%[1 + U5/enKH;22G^b8(HJXHk9s5k>\Iut6QtE?gtS2K9;Ma>>0Xd$`@-KhW*Z1us&7S>7KJ*=9)>k2@2Go6gqe=i-NHPm&;O7W^[W + HTK^,e1m0JYY.#W91nid@;PmS9A"(Jfc#@'PP&2%+r*MeeKZ5Qnq;h9#=Bo=$E-jgKgn+$6 + sP!B6L.pPGTV_?JA + &6KAJ>P6U[OYZjc$/JO`h6aV7f)$oNG")c1e%b;di*K(pK5buE+BKWj'^O^^T`+I)QjWr(q + k\m_jh/M+)ZO#GAT+frVSdWl%cU+dLTP_H_IU[V@iT/LY;PKtCctckhuMS<1MERb.ho%2.< + ii2hSn+]!"g`jOOMaEUcBe6jLhBPf.(Blpt%*/]X]#dQAo,bcZS!rM\\foZ!aUcVk$>=#ae7*UgC<7c`1l=%N9#B:0rWbcW8o;FBWE/CF2jN + l=9B4ICKI9GeoK(4B*Djh:R6)$Vpu]_!0r4=!;02Zd3qX[l,#_mfBmu*2.^7;:,B + ?S?=YBFHBL0Oq7(O\9$*I4PuUS096k^fgYEsBOFA(sm(X'c*(J97V,NF0o8(sHie-R"K->7 + Z&"n9%4R=-@\qh.!Z*jaToaO.-HB+_=SBIsW^A6Y^DY3D9Vm*"Ha0nR@'[FCiF7Od>hDm:s + mM]$7Eo#!F]=+F#ScjZ + T:i]NnkJ_0c8>%kB8g::$6saa8#q;^jMbFe%IRtob4:fHK#+r8WU)'.*L<7Nhtb3:C6m9X/ + Gc6#l+B0Sb&I#H27HK`;8p;BWQ1\igc]Q;Z'Tc^RTkG-SX(a,N""RI#0B-^E^oY]!dgF^VA + -H5N/V&)biG92n[>-SN97NOjocY]g#I*^uQ!+9:Q`\SNg'KYhT#149R,R"c*![SBM5Qqpl% + s!A;jW[Nkpfj2O]M;Gj\m'h"!#5_MM;G_j=48t'j&Rg[2(RfgL#$DP)2`,U&iN(h + 5ZAB%H?6bE"[&IHE"#K8Kb#b5.[KN8YS="*ZF6ZKk,80j29oT.'uKh29_8CWc_N/:+\P,Wum8&MJE,HjKc=-9R7La'qgm$*C+B + ?ALoalK%I/>(&&TZRs0aV:G+>a`LfKh8KK3u"G%-tLJRT#p1rb+tpT/$'nMHUFL00E?57-jbb,it[*-\'F3N+&7X.Bl)7bG`?VGjpbp:`Md*,2%b6*. + BbqPj8m*C=CXN+;kc(pTJN-pn(FU'mQ#M=GhFP;Q?^PCn/c33.P1uk)cGR!qZLVS->AE6L= + kg#9G7,%9$m)]ue+b>/EJe/`PAF>.Z8-C>RcBs=gK_(#@#>\/E:Ls%BFSF+42i#1nLM0]iO + ;;*WXF`kMd' + XA1oad-TIZ)_T;'c)EJ56;B&.F\j!L4GJ<>WDP]TP"@V9H',FU6:jmf\_>3c,%PI34?f/CG + 7M;C*O80^DRerQii&"J@s,3T,g(+!FW3d\6\;CuoW-B$IA)%idBQ`(+;iDc/Pbdr"#s^f + rC>@k8CW`tLJV^i>rYX,E!>H,e=B@ao0:[6?%P<\"a(de&1Ie5:XrHFeR_d;QtuqN:Xm/n# + CpateQ5bi>cnN4Q(TW/0Nul>,Cudp#LIkH`EcM5ACaa)L$1RL]d/;6-im.oMoB8Y[;2Uu?5 + 7]E!t\j;`:*sj@0\r3=!_n=1ujA6Wq=B;pP,#-@n.&LJW$E%@>b!%ORpNNTRn_aX+AHhj/!cSk(Qs'S'+]/f!>Q)RsE:R4@j4Kc$"9:H:4` + >n*N6_Z+L!Y,NS]4o_d+oGaQ6:7'E+.(s(L%mX#7+]@Q-rrlfT!SC'mNmcBQ$b`,QYDVfYB + M"-t(.hBh0D4k!\%.:#pOhOr$ITiVIiF5!Ik:B33QaBhua6A*? + j9V%IKk$l"?lNX88SNd:uJQ8i?]RtGY6p[DIHQRiF&Na[ + (?/@@Q#M&)=E=Z@4Tb$^?= + a!=0LQ"kkhio/!<+Um/gb'.Ol!WP#=*>8W$0YZ*!Q+BLDY&e&:+E),_`Xb"0G%JW-V_PdM] + 9JLNYlA%R9"T2$WPU"^"h-YSgoH,lo]+".1QniL\u3?t>B*Kr.K'%SMY=0pV5fK,A"D^bu8 + X?O.Kk#=*Vij?GLR<,f!+:HS1#u%SKs3@b + 4Q_E:(5HL5KSF*_\-hAKI:edNk+Ip[=rC]#FQ6JCfYD0T@!.8BGDC-b"'@/Zoo&r[*"Git1`LX:>PLhHqT6s2BMg`R;2Qs9_q-&9!SB*MW'>j(:AKS]TJa^ojcPi7De/- + 8!qg9s`\#_NB'HjARuKD9%\`9d_98d%t($fHJI&I=bR\q!rsEWO=#ND=b?\qgDuO`OAQ./U24_pk,u4[OBD``D + V2t%hl)7an9kF.0&*$NJll7/%<:b^h!NWV#Inu5?%ms)=G#`WA4TpW5U6MH/*'/LjA8nZ\/ + GSh@Kjd-m\X7JI-]%nFkQ0]hu/Lc=<*$L*/C2BL(IYr+=Mg9=kfeqL,J=QY3PJ1ps42/#2! + Yp84NcjZ.EmUBD=B:G(9X*p]^.KK$\h!:3Q)m"QEb:(DpijBQ`PC*!;ii"r6]bE-DOpHis. + (>e[,ga@=+od/L7igIQ9=Y<'_,/0#M=BYW,ICJ;``RBg\7Z"O-A?+_JW<.O8 + /)7F6%_F7KWm`+I[KZf70V$t!fm*]V_3&0qf4]=A%6r=cm<_'X)'1uL44d]Ss"d%9*VM,C3 + IGGcTd,n?%nqji*fIGQr4'C=9@+pA5.9"?ugug@d;%n!T1bF8&L''`;9I=H4bF/%Gt^j%g4";##@j + J/Sa`&EW\!Gmd7Su86CPL7>?gXmsK`9^Vf7(jWRfD9+j"COKLDp)b#T + *?]NLG1Q:csHQ^<`D%Zp/kj@mmBQ?TDkbae:;iM3,o/\>6Q]i";itLBRgg%$Beec#mQ!tiD + >mkW1#,@SP'EgP(i>kF["[NKU]/^TLE/>j"G]P@F=Y&,$q>C8[9P.3`Ut0BAS5*]q\`E + I45G1hd<&u<@NCTdBBiMZT2P!X2O=EL&V,TrdHIcgG]&e+K?a*XK<]_Unc"FCeD-"8[[bYl + 3>\fMcoBtu?]N/rH>JoIeqgRI@=?IoG@-VhsMWA?J#[XUQA239mX!.35Ib37(2`]7/_T:q\ + qCIf6bZ8%$Ptfl:eb=gNCj'#GVUo[oghq=?^#o';^Yj'U>WsMONQ:*Y?VaamQ'B!pV@ZC!. + 2GG*L.PdQ_N;0[JMXc:$CAB`%7&HJ$n`23Vlt]*+Q%QTp@@lYg?Ef + o2_;7QjL00BQ(!S"Oa,,Ap?q:j+EO]hV&KI&^ac^J2-d!'\V('QMXK="r&u#)J*lg:2@@AJ + C(mBiR:nAB8;bODu$Xpl77h3QWMHloHZ=8/$Vb+$kP=<:<--]5R=t57REAU!'LH3=)d?JJf + j;^"9+%anFXY!2p'[-Lb0'gG6euLLqm1<2oC!^oBUA1ln"E2J6,"_1G + D^_MWUm58tDj,UmFIsqj)Mt"n>u.%tap''O;3jFuY@T&Q4T0[a#VAiL"L'LZ0/2-&J_1iV% + ZZ'`C6n0FS^FruL9:n2#t+j]X?q-.0eQSng[^IMX;m_,luRr)h$s+gG??O![_mA0!&fqNp7 + =.^iu($E,&CN>cN]Vs)ipV5`aKY-"bj$PG(7*(Cf`B9QjY"tTZJ0 + jI0s6Q1A%EA/NZnMBQTUK>$63Qq@n0EO]b!4AQ^2nXOMj\n`7=\P?ZIUT%o^#^cHSq%b1DG%6Y%Q4/&/`r^.+Sk"(??5:Ht"hjB=oB?&g6hn + `A(ZgeS5"E60J5?^W5ZeHri'[cYaCu,6'(C\/oEd,0jEqKVE&,sW6O!Ur9ShZ'oGSlhF+`[ + YMNPIg!m&&u$FDYoZ$\&*+PRohWW9j]T_&KI3JUB1WWni=%AEtkLf"X+6rX.L7p+mn@h;lS + !BMDnn957,Zml.Om%@9b3'RGND2V7`4@]t;-V>Y(%?Y$G`V=]dLXe4EptU89aDD7$A64WKn + 2b#8H&khj5"F9(+3gkp;p[A85kRVMA-$0t6ZaQ*<-lg5H_2-/c5N#m]JbOqQ4[Up.YL*%$I + N6L"sUE7L/EOSKlGoj6cE5"Pc?McJ7b*75$CSCD(Xkf\X-&\4-!a60?15q'#P8I#,,QDJ`K + mljG[:IE/ZQ*Lj:5>Y^$^E]M=7HQQ8FeA;qa!,?+/`R<+=M$]s!S7]<6uZW:kb\_T@1K^kX + 4c,[mKn6Y$mIZWmHH5+c22$\3/(7f-I,ab3+l&H3NcLg:6a.C5S/\-lAK:([SiA.-6C49oR`*^bm(O + [2;fKEu1IKFW#N&TShBI-I2C>*@E>X]=Z*=fY%*HV]4X4mN4^T9X5c%ftNN"0cGUDSS>gTn + YTu3sdf;aF&nC=uV(qA/HI";9Au5&V6=PXWn9`NTNPk.j@n*egqnFd1'UIT[0l$:TqB%6+Bs;$7-%l?dWH?O0"OKq#68R7(UMO*@7H-/$atkDTi-::@`%ZnHcjq>A0E^W36W5t + [%q0p^%oLd>XM)`d="`W?gFYRQqAk[AG-Ti^C=%b*V%[?E*RR5Fkf&pi)l1!ua[&rU`mAE- + :o]F8#t-:ZaMAVnTPb75cCM,D!t#k4*WQ1YJ+(Y`^fV*K+9pgf7nD&G0pkcGOWGP'Le_3JW + o)9'81]Af4ZhVnG6pR\1BnEd*b3-]9p,(W#"7;[Xc7hh;.(/j\Af+(^i55EB8Ef>"ij+R"U + hU.O7D'maB8sHP2nDAeHCSu=&U:V3A*E;7I6bGQ'r.ZUJO\>.ir/Y9au'c("kJ3bXRk\$c, + (S`i.Q/UUp#,dqE)RAoYS[$T_ndm@EjgGp^kAGE/Aq1IuuF<%WSOW!!e$=PtR!^f#$0Pj&\JWj=hOhHT=cr:>AZ[.>l)Tm3t`J[es1PS`E* + =u%rCZHA!Gd?hK>2Y#X.cg]C8ZB]3Q343)#,_F;r)UCu@RJ7YI$8+U9^E(^qX8E`1[D\OHHHTb!G*://q-L:hPCB40 + OS1TsY(nn*ouS;QhtY)R;(2u>oY%C"\+7Kr7a`f\i1!;[YS0Wu2NESS1?@T4iXpZCR"CA#t + Cf>fOQlMZdLG#Y8#7o8;?_[\^6k1Ca,@'9qi/_@-##]8m!.2P,BZ.)`\N%D;fm + /Q:DN]FD29S7ETdR._P1TO,kFH(!;YKc.(m$_oN*\RA=\EsH':T2!i0];&:Q1dJ + 5lkacrsLl0Bs#9miB=)R#V1G*/6[Pl#^#ZKX#I)`ZVu8Wu5Go1>X)OL&D6`:Zm.5XnBkHpM + e#JPtVcCK7gc<$>KtdpKe*("jh2q046hU_(e^hk@hC0.i``I]\Z"GG6YgL'2oHa(nhEKX;F + )DW7DKa!91R0E"iFO(_Y19!>$CU.HL-%UrdM_jIt]W61bfK)B(-;Fo\fS!GmF_](Y0Ggl9/ + k%DLT#L<SE&[(d[@++ikt.67F5K`!$d!\`I%H=rP:uMn'k + _O1+T.7eMY,W#JiY]qM0oi%KNQB27rlmaabCQi$6%K3u>6Ucm=+Oln5jT?q&0'X@iUH+["@ + */'3:idE.^0m*d5)JV8AHV*Vua1B+i5&sAAbV',iGcCi,9%J/0o-$#0p#l9A^E_1@[[JEE8mNlA1=i+s_VJER@*F<%!9(TfD+Z*bNj\JqLDX/YUS0_5%UTG_1 + fgC!kBTkNYmJjHT-(kI,UXhG0nQko33U;4bUJTd5CU)@Bu*ig;@CYR\N;-;Rb\Od!^qLWHEmO:U*O;1`JPRn6qEY)i*`DM\1A*;2Rj, + $`(rc%]"l'`nh^'MG#d$rLD?c)OBFJ:%d)4KHmb8YrHAhm7ZRS'iB;%*'<#S%j&]`rA!GDm + ,K/#VbmQbI4bZ%>'Ek'HY09]g&1M&IV)(H.m#a,$*!8It`J?R,j'sbnnkjUpBDAj[c*FUo? + 6)G)>;`F771pIl,@(7#o3Z:;E(dZICP@u9Cf/p&0"V\^6F2^7O?t_k$r^jO9;Ze^hFOVGGn + P^)KO_A#fW!Is+&&?+$Te6m-(mi3NR`nGVUWOTo.N"8G'0H/Gd<=QC2^q^9XEYRIp)[Rob@DnF'll3bL%mcHaPuC+`:_uj + ?(L^ts/uqi8WFW/2.Y34`2>:ZsYtf3Em<%\0N&onTpo+8;S1jP@'ZuF&;-N?T[o3Mc27i02 + bUq"J1;V$K_0#Xoh@@lN63(S064Ypf-4>I#&4R)e@@lPG=[U'u$Wb'o^]kR_a_S?0Cu]SDZ + DB"RDARk=*&5iN@9C5$ndT#`(]e^uE<]%/c5_E!(BItb'QP(!ZjBUsDF\(A5_'VXp^Q2>'T + 9F?U"".DKeJ!;EpNQ%QSfs&d;u6!?A>m/_7CPkr#;>M'g\c4Td7*GmL2f.$!*a7"g(U?%CM6$n$3`9Yt4W%=jf_i>)o6p(L1f(^Q3Cf0*5 + fkQ\N/^S[:tiO+&W[sY[//U#X9F2\^,,S8q+$0?L;VabLOG@u/*s-+BUTS41@U^gh+'>YB]ergh8gD).*GJ`>cdOcla3YcC4!!(^h5hl\_@s + 3*'4"nZkDqOs,hXIlSK@\B`34-Gn08lNbMtjQ935d99^b9]HI8i:X2Xh]0l55PHDFt6O2[9 + L47T%-@*oVPa!QIZ]SOK5pNV4$I-!Pg!A.LrX(mYIQ-@n6Yo`q4lF$L$-!;DFt-oS4K?;18 + 7C/c-<@MCb\Bq^+hTZ!?TAU0:oVVu7u^l)s.<2Gap168m#_p4>eqB(:P*iEg)1h)%7@E+\0[,O\,)8d7ZF0<&GaGI,3, + :ig[MH[*#n'7[fn:W8rWW-<#nHV*!N$Q>+XNgU3Pg(`iOg)pBH>!8`s8CYcf((=6K@cV)3a + *;qIDc`-FFYOV3';aTqZG9"fJ)2;spuig4cH6d`IeW)[t:2#X&;?#Cp5b#s`GF&GR*qjrqt7ZpS-)BjGsqQ_/e)_$!N)aG@F/,C,El)8egc]]qD/gMBE + Ae])Ghk:"9eHE8jaeE_K4lC$soA';%FH"%#'k(Z%eI>8`IVu_b)Z!O!Y!*\R"q<+-E'"Ii1 + `58VnBd>7*9!>'B@%VU^TQ4WDZ + ]k?"15Oq@#^h0_ToM4PHi(^47QZ-*D'4@&O7=$/[.*'S(TUmegKHTg9jUTHUY'Gr=HNJ(UW + m$Ad-.].]a,Ik&.S4n&_:HU..>?M.FPm]`LL:53O>-3a;[FH*T9J]a3s2P--!Ej2m3[$p(K"aL94H + uq+Jt\WR1bSM`5!XY9,'3#4V*?,6=>E[^\XU0n_i`,BMKM!:nZFi>LIRh=d]R+DoJ][\m=( + 'RE"c!Q#dDle(%lhu3Yq]4k/hm,%j1]HOis(@9]t?TJ"T(4+9h-67,jNRd@BI[1`c4`/6$> + 3W2M(]c)u6(nq)4<=7B'WVu_^r,8]Zitfj'4SJ,!C>jVXlccli&cnSlT(eMA/&9:&QidQ5d + Q2KA'LC36&Tsmh$LmC_9agh0KW)JBA=F1\'JTT-.&q;OKUqCBbrNng8le?rTFg.g)8j/&F, + 8#iSY[6Za-0BmG`jQSmE.\l0]V[M]N+Q>M$CDL30@H$/g,2g728(!#u\`@Q,adU"8G9/f@t + Oj*J^%OVqZ&"qKUU\5KuNM]l0L.0e%JC?84 + ;A)^uLN/9DRWq`V"#@mR.$9Z&I0e>m37O:d$(FP'511a+fBo\#oO"7?iNN)cHhsJ:!l(r[T + =+M[\Rh24%iE^^"\1OH^E$-TNZg:n+f69VDJIILnNg?5+V##kQ".?*ngZ5QM+SUK65gcB+: + XX;\aoNE5N*0@<%]$tLI:&5(mIcE'oPN@&X_'c3?=/Nj%7?(!_F[>8`%m`"KklZQV6HS)3i + E\24I>'&LZo/o($f[SBSt\D.o_Y-W(:?.BRW--S%fa'hL)R;l\@teXFHpY?e83X-NPsEEH* + SXNVpniQSC@6(/[*1ZM2#O_q2LDDj!+f%"A.S+!hueoQP_8$Gcj>?RKN>,cBe`S&2+AJWqb + )4\]aW2_3PU]pVXi#LYH\?)kGRKH+i*Rp`(=k%uJ8n/3+>L< + 04r@j)b&;*g][%ea%AT*M1l$\_Z^rhqf1,NUc+Vq>ChR=,lqPpNQTY+.(8hrdMVN/B:p.o# + `54`H[%PQ&l[d!PkofNZ+2$=TE%R7eu-A6>1r:HCnf;S9:*n+gscLL02GF(Lf(1=$[B[;Zf + I.6s16iU*sPQMunQN5n:n#9MV&]3J;IE7lfrD89,r\502Y%P*1Q?A;_g,nqF8*u.+U:sLji%,3[7lM4g>#3EqY-CA] + ELWlRkm9sWgLbW"#'l#?Q%[hN71MbrdNl089\3'7b5#?p#)2:+/"'q0p1tJ^l-?:F9F'Vjija,pD2?HJ^=CnUm?Wd"jP@[m?AXd=8p4IVZT?h#iHmLJQcYG\)EVjG(pB + >kh*bWl.<1AM*ZR.,eGE4UhXoR<9A\_^SW7fb53RNnKL@1#=%B6M8HAf$ + /XiULG]6)9U"k!da5-3H46N2-?tABE;O`Kq@"jpX3J!TdA9k%ehk*E-BU\dR%u^q>Rc9n==Jsrr8CIdo6FXnL:T@3@1XY"9,nC"RRq4`c'qpZ + >V;F;4rSZ9o-l:rk-)OZ.35`VuZ6+bg/.Zm:sTd+De@,]TVb(+0;GG93ZZ6f@o[l1=WM++o + jZ&tc)TqcN:nk]E>M3LjN;Tk#QMfRG`/H+g\QSH;L#XpX+6>mBem0gm^4)?P.P3&+,,7MtY + 86Z@K+GOB>RW9G;!Zrsm>"tmfT<#&h,'gRMBdXc[Z$E[u+%Dcp2c%+/F9;,3.K:.BE(LKtd/'KI3+!p&D + @M`d/qo\O'+]aWL2hk\_@m98;>'1opTF3rfQ[jDIIN/'?H1XaBoR*QR1.-s8S!4.P(jg'&& + J&H#2%oP6I`RQ&W@o$J@Q-*4L0S&@+6*.WX7g<1'BN3(^=*,B0M4qjA`NqWEAFt+<;J. + ;riJSSU`OUm<\dkQ1$#2`V=H*nV,,$h5)i*'ubR(O4B%5S)PBLk=q8#%'';C?$mIq-YUD/b + =gkrFuG:UMf43,.-&n=`aK99R6K!7ZZUBk098`!0sE9nYK0Op-*;CESbbRC[<&u'XKoVdp& + HU?@HL7sAC7[/]Jj'6;Yfbm%X)jD=o16VlF:^O+#k9bh-QOV)G8=\sE*GRiK2\D2tKRHe80o)Fc*-2IT&dbZn#/I>S@g##N0j5:mKgAG[0H + &F!`\doRP8p>??B7t53GQ6KY*ISM=*jCCCXmd8Nj`u1B25n5>H47%p;7o;Hp,E(Kc0MGkm* + m80h44b0U<]E\tQbpa,%MI6]=ft@B(G;TZBTSk/U=<;'42!=:"P&N%cEM7g?3GU]\tl=_Bo + :mEm3^(A'T@qf&;LA@rkukZ/,^2BbNiHOJiK/VAr&!fH!3#(l>*"`mE[A[%UCK,e1*@L>Hee(Uj$7)`P6#_ + LD`L/EOI`$!>?@Z5.4Tnk`RaRhX5q[fg4A!12\A'(,YkX3l)1+LqG(r@CSe521'07-MoK%) + Q/,AUOqb\]mK#U7JP"sJLA":38G,@k9m#dQDpS=%CQN0fS8O=e%?Hg-04V\;Nl4NCN%^l=k + 36aDLs')6\f!N7=+WE%SEaK#XjZCV4,EZLX/2Q!#^J&B[R0a5U%(*R^0FsA\PN?DM"JlZ>e + *o5b%(P/8Ug$Z:_IuauK7HgtH\AP73m]^;#`Y%"ekK._)JmH)3#(r'<[lnp=EaTQ$6r5AM%$00^/+ + Y+S[]`Upa9] + Ca:@uCBo*&#.V:!)+t'nZiU?u$L7>X.]%f&\:qct-j0Gg89LTB!kSNu$L4jHJdDNmDM?/34 + )?(XHoNs=oL"Qu6``@!]EL!)#HTIL4Ek@<'H/LeH[%e"s@9.-r_TnSH + `ad!ru^s,T/b^5FokJJm_gcb!N4\=bU7%2!B'1)rs87%E2KG5)LkL8Os%94ba5+K+OsgPPC + eE1QrA%L3QGr3,jTP=U1H=L\hWJ17AVj;S1^>+@;fS1NTRQ=tRBT`iNrF]PL']D+<1QV^cb + c8:*_Z#KGd,&?pS8pc/O=Kq6:dKfEs?+P\k/I"nS5LM?:6"(4VaA$KEI2:P=?q#Q(\*JK;+ + K$[hW3'E!m;?YWf\O^a-!S'8PP!2uE!o/\<'T=4K%u7B1L1k#4bBcC"E45R9Jl5a(k\l15= + $JZn^8)#C8Y60EpC-m82Yu_@\86kD:DJ\)7tdL+r1HXjTh6`*cooEWe8"lNR>#YtSr + C,LTtL"hTlN8u5][]sYXbDa!QJG-]LP6>9VJ/%<6p`>4?m14g>_JG`qo.\CY>dk@/S!d90k + psCLCb($V]B_*O+p9QU;M)dX"UjWjbkt8YAV<2F2IHTL=XMJF!Djd<%c#UIXJE5B!j07TL; + 8"bUpLtB63\ToY8%5$/.!kpHCcO,"`RBEil-XtJqageJiHrW;qoT">r@;5#.S,rpi?["E]? + ^I!W)`ji]*FU?IHj@=emF/n3e'[[6jZcL69Zi/D!ao6?oXG+4*eu;JLSUrS.!4'39@m9ef4a"GfR! + k"-&jlI;A/2i3`r5_9S[:tL5UN'=gnT<9*:+?]+Ug;5W"6=A-M&eb,^K$J$]rYD^X]jP==OYG\jfTs&G + lo`Nem[j[:h&,6Y`b)mLOac,BOh?=`OOY@lc3Lh(<'53GI;,eQlGY7e- + 4C"c_>IDVJiPc7+I#J3o!5fbNi%3B1B"^i>%[8;h=OVZ!/%uY/a*THmJ($_q-T[TM_TB#g-70_#[9$X'%%WEr1]2:L33nV[U)hZjF-#7,UQ#^?RSD'\uRJm+h28 + cmG#,Z%_uL1j55$5jatm/i-:"b+T,iMlVg!%?fl*F[_6g@YT]^)eP8bs]A_,R + @_1Y]4+YDq9V2(GK_0=?hOJ1BOde6&#R\?mlkO$*ca1L.&2Y3[0?`G)&d?g6JEtGY\Cn++k + CPJUi"pXXj^eG)&n+KYTlW.Km43=Q3@F:X%2gj2;6`ETA0)j=WeZ[NAFK6_^nr>N$@Pi]!_ + 57@=^Y#OU`1F[LoMZ!LgEa7_$N?#GA+63G#6gR)id-0^qAQkIbRKCCTbD1ao"ouTa+#KV1G + NA1b'GG]mZ,rmidM4t)e?=]X:9_5.dp]KYL.HX`=Ao6&[/nejT5uoP4A6*Cg7<,QR'a!#6K + t)D4G&*UVeJI.fKof:=mCL@!W8#]$Yh3&?id(g)Xp7+N9iRFtLh$X%3mSKqTp.CR#[&%b$] + XXgkUC=54j>KR8[GoE'3haC@8m?a@S-!,kcCL>7S.:%NG.&Jk+M=p7Vc\s+jL@.(g&kP87B + <"OW968L3R87;q6W<5(eAq=`/C!EHjA&g]h_'KqNCj)(A?mn:crW!Ta$>8m(2J`/Z+_("_^egfP^u@GZQlo8SE.!:gXmO1Za2kR]/l3hD#7+lNLV;;W%OeBO3e=_ + Zijl'70H%+?AYW[r!'Y=%IFdIaeD4eH,BpD'mkOHNWRk"`8ha8!\#r]XB]#9C8G#3[*-Pn8 + 8@?3eg,;l*sbRkZP=cG)#.pllFL`f#Xnec&dOH6$#E`4/V9WfTu0UOfD,aX2\6I40N=]:\7;QITL`YaW)V^-#(H\oHN^], + ru[=fnZNdL^DnMqf-a#bgAGs\aj%n/CYc\ZncBoco,n9':P>Z]duD!b%(4"kKS0=d"uodP2 + %9hmBq#0%!dXtQQn\XBeHE<@6q+0#KP-KTlQJ.5ni&K\kU,n\7tf2LBZE('^H4MW;QOZq2??l4E,Wu]O#"WlN+>nc/?XQ\ZJY5Vg0HgLj<.\IU+@o0-80A%k15'%?" + b:IIl6HDfN3*WFfOpL!]#<*.gm(T2LkX1X&:g#[=#-TP+R<:+*0L>;o"_0.2D)2 + [1[7Kn+*tU!4j-K>3>(mI!^&;BDjoR]:NP"=Wo6&N + &3ARMRgmDtLF+Z#Q]B%)%Dk&ibW:M8/Q"U9ZJSN0g\eT"]%W?qqNPj3#)]KC9lfX+8iB!kj + G=)6@`"bt!+Z<;"pHUXg^CURGaf)(-Vl#Tm29UB_sjkY9nhf%-E"pYrb%YtOI7C,7=]qdEdTI3fGd_U,p=k#8kB2f5^##kK) + F7P+(fU4Zg3k5X^dpd5(0A]Q6PO7r4aj + $?tkjYM=Pq`/.o[8Sg>72CQ/D;HLEaJ&jeG`Aareu)bH!CTq&H7aZ.3e6/H"1_\AWkNpj=DjCQZbLdI) + 6OiVIM7sWg9g]0=WLm8,g`[Zk!@h71C]'/Y+(HbT$_mp"ZE^;/7T*7)T/)lAaT'jcDVVuDkQ/]Sn>UedmjssasS/-Ak#K^d`)rmU8@9L/T?mURSJJ(/7Ar2mtj" + ZB:hLJo0+9VC/#DiSQ`R.gOKiPsX9Ft)Nq9""iT;h+M(^Y\m63ap0l[.Lg_=7A0+0!$tEBa + b*T,^Qt6]bU6mQCciV+NXY=FB(Z25\g_#0Ijqq/;7j*B*k7;5)5g%: + ns\)%oH.O#0:9]K'h22oqX*D@)<`>jDgsU4H#:EQ5P9N5:_:e'S15`(o$.C8=:2:c-SJ5^] + m=2fd%skUl:Jb?;*qY2%S\%SV[lVp.;e_OO&eB7g?an#8)qDj^F5l,D^3J!36)c0Y@mH>^) + 1TXJlEFeK)M#6k&R\&4N+/2Bbm?Ma97#O.Tm_B:e?d\]-^( + u:lBhOHO`*DY=m#cGquSCAI2;!K>qMX30JcY;f1U/ZN=eNCr1iV!ocd2b=.KM0M"TiT6]A0 + #.W4U((`0LPVF*lG4(1,a)8'1ggbiB1Ah@RA,SC<.HkdASHZiEj]4d:OQ(>RN7(&-nlk2RR + SD=HuQ9/7[C"iu6!@X!MR=q9@R'r(4GnP + _=]@"Ua0q#Je0"0([R5_m"Lq;)gH8cq,#%)M*\UkV=IL!CQt+&2diCLrT-7/+5;\?%C'08% + @q,=9f[Q'$E7):nPbE[i?/]pP6#>4ic4T+?/UAqJ>3X@X/2('2[sqBaKcd"$)9)K\YS*omMfY4=_EWo(]jK=)0%KM + NH*eu_q<+EpB@5q&B$7l:rTOb/9'p:Vlnkf#9+TZXptJ]/>ff,*Wq(4C!Dp%7,H1'g'i)j* + LF/,VUaDB[e\UglTY$UmPEnm-Nh1oC_^Rd,=cfp)a9b3/2WT&__ + ?"aS^e^lG8^$,HiM4-(X18E69mZ6Lq!fspq.?K + ,^^,Bq#eXp + VYVuWf3s3hnfl+Ucan5cCqA=d2MBcT?#>B$^8k*aS*bfEtj_u"9ed5dO*MLoo%u;;n4;*4D + G"SjG6!+RA^ssVC5cbe_6h6s:BH;Z@)iq350W%8->meP#1S?$%7][$F]*e&B$kU:g&4FUA, + n*AVmihH3i+ggE4r;%QYjfq*623kWWljfM#"+or.LI65#S-s!Ju$>X@58G2V%"Ym1L@I&6;+D=WjO)!RdLaY;WAN1"a?/>t&2. + f6A.K0$m&U2uW*Nf0O5dUh`DAiPAi$28A6"CZuE;>%ZlQOIQEMdKdCDt% + ^)\H^%6o$SR[i<`0*!iSRNlN+g()2@M>bl2)q + C_bpC$1Ipg8EUP8V"B_d0riM>"J@t*e-Joq(SUi[iNNN,.KP\b)fd_TZ8X"k4!W0;^bNk,1 + -gi6>dYrWiop(-H]X(`10$MdMbE7-B[.&;TC+^at/,$/IZ>Edap(6g3V + 18aO!L1a1T&mYqEk^0*2t[TUH+&`]NGaVS[?jo*,I6$4ep'/n,SPXa17O)B%!F.j;D\8'I^(/p(qPNG1@"ppL]'_Cn+P*dT4dMcPY&E&!?+Jo:C7K + FV;'4@74U#6mKZK8p`*[1,'L4g.HrY^?_+-&5t"<[fr3Y/S^0O^!i!cA>Z8jX"=ct"7/oN! + ;o//KG_$,JS,^d\c`@KQUH"+VQqe94-arS[8JI@[70tRY + -:bi$$#$_-:!oP7'^dnU8\u3=U"!eulFN6H#q+T;T61-9,eCFp?g'Y4D$8g`HDDD6c%KM6b + #iJ#N+jq8PNpVI2*)M5\5g0SoGU>!N#5"le5XSD0YQ^:5c2]"^#IFRJ.L4KVcV\[9$>8>?03[W8pQi.l?=kb2i5'D\V1<2()Iid7%I33oP3`P$ils'.RrmCC(T>4&s\AZnt + dF<1?q]e7>7m?5:"T9,JP1Y&J&p!4CoiJ>3p%;aYZj8Q + 20N:PJcm]=1-XtX[@fm5Uk6D_ZgLDQE7DM?&_%mq7 + _unpM$$K<]:buDYE%g/bBE2CQH:omZQjs2&l!FSiB[R_)k.PLGJ#mRMMiIu?=pN+qNF;I:)2Y1Xl6sc + -IApTnf7lU$RdsNR^+u>gpQdV + EOa5QNH3+sF@IgC4R3[!N + GNLUr[-Dk>ZjXkbGP?%:+:_KQIi&9<Z!2&H%[^Sno@."Z%n]m(%i-IJ=Jq%?TnTcaMPUZNPeU=f,?tkbD7+\[i6* + +GPTCqo!PhoAQkgj4O][qKig@%BE%ViF`Yhn?Nu7I?esBFgooDN_$[DhVR-e07.L(#C8jEW + :E]+A7a:Yh:6f@eaJUN]HM0NFAO81Sq=Z;P$h2dj`O4cQj+bu;I-3P2^D)H<_i8mjE`_k/H + 77$>B!"K&f-]!d*+_4@mi#)VL/=f)-PZ`X+=biB#Bo;_D:d@,FTM#A5`"$r;()`l>L8`%e> + 9n`p$,Fpj1qEh,BF/(,#d?&i@!i2i2gMrrSJfnI=k5=@^g[K*>XJd7#9&2/d5RnJ7B"q + $W>[^GZ`AEKP!c&a$m[!aer)I4+:MGW3.YA96m53r8gd%?"U#q_3lXN$6Q0>JC>+7E(o=4N + 0o!M%Xr?&t>3>4?h6)Db)&i'4)Y6*-5H@(UFlBs:;i!7Q2mC*lYl]%]G!lI2S3o;-(gnGk= + ssRl6*B;qOK"?S,JO;A + ,Zl,o-QOHHj:\[i9t09`)2$L-WT.\JF>ue"aD3HI<8K'JsR\*[^eh`Va-(K*0 + Ce+AuJ9dBfCiSO+p`s3NXRct"BJZ_>b,,LIh&(>WF%4_EVhPLQ.@;B`Bu>q<'%Z-h^9f2N_ + I4[;mCM:WBpe:!?/4\]\H$J.BNPaiAiHl$X2ms*Gj64;,JrKZ,k"4O%fZGM%?]]_5$N)8?T + gTjD7qn\L[dOeal%iq/[4eVb$3SJjDg84.O)76Zb+lD,2-jY&1bFf8j*T.$@abHq(U47XIO + i]t-h$",E4qAl_q1/Gm/H+Pa?0U'/iS&ir?L,T;IRcquXqH1;-_'ZB35PY:7L=F8jTAH#,o + >HJJ_tiIg-TFSJpZ;)mH3LHd_[#@U2T%#Fm,Q46X:egk,rJ?+3EMrkl,'2I?Wq_\`6pLg&* + _]4mh:cn`0lF.fL7LU25SXh?(^!FoKAH@o($TX`6[MeNE7H^31lp61)&,aatVu@VtBoM9;Q + 0dhk#P]NrJ4H11aa*58EB!f?4?H0[S@l[49?r.X#m(2Xq=F\XJ%T/Z>Y;on&:59WcL?UMra + #Og2gnAhrJ@2W1>$g:Wro]E5'I\ZRZbM8\KnGbT8D`^"MZUs%r.pj7>59J+!,L!nMbl93g# + "lmd4o+!%gnbh\ibdphJa^?\9Ki.&+s6(/EVf^KpEG+P4X`Vo>spim+eHSu?C1%cq>2ZsGI)NCMrjf^s + VY+d#=VP$'W5;(7c&jc\;=^0raa9]hIJeD('bSMV^URH$VV3h*"@Zl1bnNBno>hA"Vu-?W+ + _!$`4>UcO8GT@-N#fR6q=@Bir$QCC![*`N.RU%hD;5r)\opX][^L=C+2KkA.o + HLkoV!T*X>+Hk85EAnk>Y)=B:WS7\[Tq[55G?KhFS_(lMu*M]#PrTa1USmO=l'J + 7=7]`-f39.JoDk'd8:[*(\-dJa*;ht-jJ5VNlW!^N^\Q6rR^q?HkrcpFbiU+3McNk(/?Ta4 + !kUNf_TXidaW-S#$="%9CN:D?5P;@;a%/$$8L]Bbs('umMcDO.sh=RdA$Z+K#kQuVbQpHbg + 36s<-E<0nq'Z?2]e8h2&r.Od-HA:_no[&FJ5/d+"l_T8OkLeNU\GVi,L%+d0VP;K*q:,A-t + -H3$]?Pji^]_:hK';YXn51.f;`lF;Q%bO;ZRkZ'`'QXX,.5F=68lE%(02,;$dT1J=W_=Ib5 + mg=IFN^[H,n`1[8hW,s[;*0/<]+%q^>4c`\(+@T]Zg#,'>O23tRG8q + e-p=t(11UJc9#YA@E$e[KEO0`$b=PjP^MWD0=6CGFCZ]Y.?O8/7[kWFbJZps%E2%s2$beb= + MaQ0!D]=:=2&5@:oY%Y@gieWkerW3tQY=r;DpC+)!JQ?csb2E"e"\=PpHA2tBlA)t%`8n6Y + cABT>LapqEM\G*RhUlh(Qf9kFH2Fj?O\as6ZY0Pbi))'VpJ#$"&;KIS,3?B<9i`^K$MPjRi + FC/f,#.C')Rdo4<,6uN7WG6cPA*4,^&7hI + ->l&K7[3Q%i6PV?j<+??Wr&(ZLTilmJq"paZ7Wrf\"E*]&O;j7s)DQ:5msTVcVAjY)2u,&c + Iiig-#2*VQ@YFDY)]H8qVAI9d;ugH'bIp^UG=imIB&+C:AcGH9R[lTUu_LA&N'9=/YIO*-W + Rof\Dp:b5=&n1!Nc0\bM8%sST`6Oo]'3:Q>LV3>]#2W/8Zi9JBk+4L-$0'p1e:,UH>YoKsXj8H + 49>&k*J484&muClK&s8L\>#YKlam7ZpM@)H_ljUtUW]0eQ7r\=A^b!:#gMr`)2P&ljVWYEW + mom=r_s(r-_E%J&X`bHbM$-1\>C;Zno#0o[n^>$<:&>`cV.pdAO)KQom?5=h_l2H=N@O_#B + 'b_ZfqVKsAOPD4'%GH.65dX6$jNcc-54$(iLTg"[N'1u8H1+0<&7`:/kO>%8!FgT[ + M?p;;/I.kA,\>?,R6sK@&"tgJNXg@a2G+6$UB1d^6IRe7aik;A'/D]_Jq"5k6nt)t3;BWn: + /R"o-m6^opq(R>DH@8e+E&$]Q#\!CarH/1<4V + c)2"a+@Ob/u88W&UWRQ%lP'$8;d$ksbY1U`WXB5?h?oA$-Qd\Kb:8p*rIuY&#tsMs080C\< + 1]('_TW3sf>322AFOp^^K4Oq]HiM6[mda]U\SASec@ZPI/t=h?\,D"XF-(%s)AC,@'8%B$T + LVU\k^=_hksYHu)tfbJ'+Cb<'([h\g4>Heo^CH?8A[g(XC4,Irp2936D-KSLER<*7gcajo^ + l!6BM?pVc`\*9sr?*J["CAY4WQ0.UC432]JX?`=8Q%"A/flh:Vn%KUXq-Q5JI;cOf^DH&2? + b?,`DtX.G(^C(L4:-RX2@%&8-O!nj)1umO&&K/R$"5qFKlFI:_\d"q@D"Q(Yk>gBUIu2*X@ + \7g0r8i+NPc9=MdA,!g:`%.%V%V8NH)Bc`u*t[A%[)JEV;W<)$_f)2BqY4NX"42J:8PV_r)!fpd&+DpB6@3G1GCf"h? + EcNBLsA_d*RF7D$/=LFpeqo:d?+mu@6*7iYOZJdFG35+m@7;4n5J:]\G^7\\)#9>gh`dX3& + )M_0%4Td#f*i#_R)cRgu'<9:=N*Be]=Z,+tDtK?uf,E`#Se*!ID>^IBqZL*h42J).2TO6eP + rttLn!>q$'%L2Kf';(e@C:^C)-^VTD7V9;[]\NC"r_gsM%s2Z%;Q3f%_(jHft2/XuCSY&)n<3;V-=m`+&0.il3'fnWL + f)([`E.>R-91GcSpF4VSn0oECGO,Kj?i`>IBsPB/p%,e0Gkk-4H9F->:tq;EpcbOY-*Y)'0 + 7#=mt?4RIb"R@XO`oBI>Bl%T\H'=tT"NeW`%PN$h=&4YOA?&,[%N)JV>2Y-3Qn"'08aj7S- + ,j6crc[npURd%k22)N[N!C$;V7fR^Of7K)&cF-%b1`Ilm"3#Mj_qB$:B^q+l[J:GDgUs4!m + OTJtH+eM+b-9mt*aHu[W7Xsu2lH:OYJQBN%itRDWV.CONq7VHm$n$=p;ETHH]f];=E>Juq) + e\NW+k]/1"R/T-LQN7F=;T^`nf*#L6MVL;Yp^Gq]B@"qb!(GR\.+e`-^>>&ej`$s%`?A_t" + Z7RJU5:le2;2pjYNl6+;Pkk9&69ILl'>IiJC%0p%"R!K#3_LQaoTg]XU/rkMpe5ElAfKBth + 4]XD>J^km\.j9qq`b7n-)^sISH$'5YL)o3ac'Ou1b6kl:269Dgj_/Q\FHl'V_`P1@K6()UU + bSu?os1d%pR1OAT"%fG)-6j-XJcm=!BMZ3iH,7uWM+ebXEEJD!SLEKcM7_>h!8OA`K->f8( + PjDq*#=@/c]YjY$.9[+>UMm:*fH.BT!D!OKJf(6*5c#&5HGqoOQqup=X@H-_sgo!"(K0l6& + ;$Z*`OR'69lEo8#FB2%u`:ZN%KjCDCDipMt7WHk + 0F2>ji)+BFMW>n9f!H>MMJ%hSPP?Hn7W6`CiW#a#N(RV6>$u#tYcc52PMO\P'S9U3M)Ruko + 'RX@VCh#\_*sKG^LB(J2?uJR=JOg3#a>ALi7"Rs/K?.;NaCL(IFGS"SM9(@-8LPf[I#8T^6>I$Vm-RE:\M!iROM;Z%aV!J-m]!WYdpJ5 + ;3\HU$k3LanMoKO"j],g&r:`uDquC\!@!0?(/MWS!aj9VP/,Im[pVRM)A`m&cLoHpQ815?o + 93BH;e_+TZgg94YM)Cq%TP\BC\X9=27Q]Xl;)^!"p>bKR`EjM4F\^s"(?bV[.07)I/A_ou* + "b[ec<>fb-2a\7B0bd>O:`6(d'bKSbcbiI*ooY1DT%0H\4]]mas%+MhPYs$=+,M[(RP&?:b + fGq\[`1WX=OGTc(TT.1H:%9:FUgVIC3_L_;b;8]^7(#_lcH]t^c?.FYD!4WAkg$!gcEuh2` + 9PXlld"#JcK+H>gq&%r%KeKg2_Z7J5[@/biOuVM6B'S=AG@,!fM?e'#U1,3Z'PfVp.sW\^m + ]>QCYI,!3R0/nc9(O3n19/V>69$jKp;khI0WT&$.+qEd#AF[V$p2.%++)Fd.IiF"V/oh&() + +)d3TIR*>HmY'i@C7d<-5PKbdON(X\cjdA7f0[2dSr*RVhI;:Q`9"Wu+d'`e:f0CT@"YRZ< + Q-(jC=$(:qB)e2ZcCer:.c]R'^]_KpVfWYf5dd[?5%53p1!l:-(^@Yr7&B#lf2D;,VK-`J$ + 879\ER]GXDe$V2lCHVnNM$JGmdn5GESLu%i=&5YB<#H:D3rl.;5La*8;[l3ZI54*:1Hs>G< + .Me-?l?*DiC6pJ<:llB@!5N`i;ocQKmcn9Y_!88#$#/e!?,3qHd.;nn3-gmeZ`o@`Cm+/5f + uMIRsdYs]gU@%>ui*Ke9teh,tUCF8j:Km<^="s?"gqb71W(*23;kfK6.Gk%+aN!K-V_,@bC + nbWrei4f&-sndPq;VB;ZJN9nV\3JU=)tF]W.#O;qUG*3e&"("Q=pemn&IFa]/]oFV?;=>N\ + SN)ko(r%HPb"iZ$=*HtE*qUPg:=Ic.Q]NbcbE7fl)O7d#8nJ#'k%9NGj=:L@KE4pf3Q&3pi + -kIpf(g=iheCD?OYJN/JB5\Mp6[U=J;(;>hd1n7NgoJO,PiR]s$1P_:ho"O7fBcNM + jJOW8"P=,)C7M3C9p2#[AW$gZfs:%CAR#TN`GV=oGT2/4_Dc&ru]08MYp7FE@@`6[8YgkDEU2+(VFLYGd#^9s_AfW%kYFZL![N@dG== + 2NsH-M78:(8Wno2Uh-ms%FkO]-a&:I>b)gjPJDCR$Rh4q`hJM_<4hBMNl.uOIh@nRK-1R*l + D_:p1?WHjXKn3SGpl94^^h*,NNV),%!o9kC"o\JYh>lIK1tTZ@7KrmRIJZ7rr&oc4?pOaPg + Qa$_V?),Ni3j$j"qZHke3lObeEL$N(,A5L+U&u0&pp(=S3,DN'B\B.s\U6hd;fHj/4m1scV45\B2FEb + D7qM"XU,Ya&htmq3$@B-)GZ..F@k8L!B4[b(a8q"05?L""V'BQf0G[R!9.Y\*$R&^Ec_Ajo + -@I_1&Ykchm5l5g!JOfsu-!^;gWn5<]_O6L7\kJigE#(=5:N]Ubn#"V7:\75Y,2egj7C#5H + H#+t/rT5#^Gl7Sdq2PfV-VTZg1Z#lXmWl?F]3DRS + ft^?Y.+mI&Qnm`t:hk4!9^nF%^om6E(N+:0_G`IRV-KC)fXY5$uTQg^#pm(;V#bH^EjcL3C + UDta2"#4ld5!H8PMn2CF<7fmX2"7TY#n7N!qG6m\V$1N]WE0gq$`s_<[-uV`[!RD:0Y7QJ- + &aun9iElA#0T,>2k\nYLBssOJ#/9Vo)"FK=nXgb?Y8d#`*:`23EVCLDruU_9+n?Enndcu9- + R<^k,k>RolW1jg.fB@W#QSO!"%Y1OD\Vcn'(JIDLlW:b2\s"8O)jh\,6/ghPKof.39^r/o6 + (/se_]nI'kkG(kgWCL'<-%#3O6K<-m/X@[8&b0Pj)O=F>aYMmmDn$0KnS]\kbK];\R(&6<: + )6k\j#a`YS2B9Sac[4jQVYs%%7ko#=e4=$;3@O&Yco7tgY8E_>T54F_nU07geQK"3gmpg8sSa,H)ZH?@2a4MQb6+,bBqOngAfNh;>RO,lE$O> + uEcGrM)cLR=&kCZY#)q,>B1@uU5-R(&^&U\62kZC8C9g*lBao#V%L0PT]2p-N:^&0h7 + r:eO-(Tuu"^AS;brAW4(8(QN#r>%_C-f4h=i + Vk4ar\pKuqXf4Ij8N]RrcdQ)J?NKVKjF_@>;/$k7i6b0?r-PC((CM%6=E^#A2YG=LdY]L32B + S,(Q:gn;7P\14WfbVA5YE5Q;&`k8nCo2A@>bsQqV*j3Mb5C2k3WU;n:u_I6XB$BN.#=(6(h + [;J>OaA+#l^W'..V>,=OT:49lm<3#&']jJ!0=r&l1PQ>F(>&@N6P + M2u.X&^`Hh*0G-T60L@>I?ZhDnhUuGPd_%mhNN7n2XCl(G<>>k]C^(fFmo*e`V+&?,#KG^# + /=(HsT#bQd+^cH@9,0Ni,rTfB_;n4dBs=p\[ID?b9V+mXuVm$L[kV7a);=]P_M%!^E_9re& + !6KEhCj`lo"b_,._$%)Yp.4V,IC$q1cHOXs3?`=YdD'uc!`go%jsMdWJIXe]/?\*N"j*QJ[ + )37CApjEh$5EZ/^8aO3bI--;'r]Nl#>To!OOC%.bVclWj(e/9#(m2\D-t0Y>_oBU]'!;_pj89 + X6-"+3oR&m'T]SJWDfEFR;9!c#as!N_d"XeNf1\1^2j+n*.ee + .u7@!4tdOp^5!a\MmOQ9bA4-5>#(^gi8h!7,OP20e.'mEe>K)IL^G`D$9U=[[!!+1[oeUP' + <2?o(I\D$+dU3LDh@j60K%?BNfNb+X@RBCCrk8DQfSZ@pqo:NFmD8NC0H01'@i"f/bF]2<^ + RY4O>o6c1nlcr"X/ot)L_.d0mh7`$%e9['?;Cl34n<."94BTNaGb[*UUFh6sQbHZQ^B)k&"`!# + ridKC=&jeYDW&HNi)?]^!he(VJ0&c4?H8);'0T%u'!;ShH)`q&W2"T4f,Lm@h`F$(&R.HOD%L,c26'47]Jdb1FHIhTWm + '?ijMo\4\G[9Y2FP:,u"F*AD&HhBSsZAk@7k$mh)V\@Y-W]WlSk[M);T^Hgd-F+/1`l + ,IFm)G=#[U%EYadZVdAbA@tT<+^5Lg1s18/M!^"hK;M\92$"11--*RU/YVMH5\ + GPNBa=>%^@!f#jc8:Dm*)g^rGXnat$DMKQZqCfD;CTm"LS-<_ge?>:a&minoOA9$=[W^qA>HN&9`S%k)D"b!L[4(##s+hJ2.n&-i?nOap+B#M#&=]%jBTWO