text:
Robert J. Safranek and Michelle J. Moravan are Xeon architects at Intel. This article is based on material in the book Weaving High Performance Multiprocessor Fabric by Robert A. Maddox, Gurbir Singh and Robert J. Safranek. Courtesy Intel Corporation. All rights reserved.
In early generation Intel systems traffic was broadcast across the shared, bi-directional "Front Side" Bus. With many sources driving the bus, electrical constraints made improving Intel FSB performance a challenge. Techniques included increasing the bus clock frequency and transferring requests at two and four times the bus clock rate, called double- and quad-pumping respectively. As systems grew to include many sockets, more busses were added, first two per system, called dual independent buses (DIB), and then eventually at a one to one ratio, creating a dedicated high-speed interconnect (DHSI) between each socket and the chipset.
With ever-increasing numbers of cores, the system demand for memory bandwidth exceeded the capabilities of a single memory controller. At this point, additional transistors provided by smaller process technologies made it economical to integrate the memory controller on-die, implying at least one per socket. The Intel FSB changes required to support multiple memory controllers would have relinquished full backwards compatibility. Without the need to maintain full backwards hardware compatibility, the system architects had an opportunity to introduce an entirely new interconnect paradigm: the inception of the Intel QuickPath Interconnect.
When defining the new interconnect architecture, the architects had several goals in mind. They wanted a complete system-level solution that could also accommodate future growth in terms of:
- Scalability: adding nodes to the system with a proportional impact on performance and power,
- Performance: lower latency and higher bandwidth,
- New features: reliability, availability, and serviceability (RAS) for servers, and power management for energy efficiency across all market segments.
However, the initial implementation still had to provide a substantial performance improvement over the FSB. Finally, business realities made low system and silicon costs, including pin reduction, a primary concern.
At the same time, the design space was sharply bound by compatibility requirements with other aspects of Intel architectural legacy. Broadly speaking, architects use legacy to refer to features and characteristics which primarily exist to ensure backward compatibility. While the introduction of Intel QPI involved a deliberate choice to forego backward compatibility from the hardware perspective, preservation from a software perspective was mandatory: software that runs on old hardware must have the same outcome when migrated to new hardware. This is especially important for compatibility with most operating systems.
Legacy requirements can occur when widespread usage of platform conventions results in a de facto future requirement. The combination of these customer expectations with the business drive for profit and increasing platform integration makes for some unique attributes in modern systems. We will explore a few examples in detail later. For now, let'soverview the key properities of the new architecture.
The architecture of the Intel QuickPath Interconnect defines a set of high-speed, packetized, point-to-point link pairs (two uni-directional links). From a physical standpoint, each link is implemented as a uni-directional narrow parallel bus that sends information (such as addresses, data, and data status) sequentially in time across multiple lanes. These narrow links connect one or more microprocessor sockets (sockets) in a distributed shared memory platform architecture. These sockets all view memory and the IO subsystem via a common address space. A socket comprises multiple microprocessor cores (cores), a last level cache, and one or more memory controllers. Sockets, memory controller(s), and the IO interface act as nodes in an Intel QPI topology.
Figure 1 portrays an example four-socket link based system, with each socket labeled "CPU". The red arrows represent Intel QPI link pairs. The figure shows that Intel QPI can provide both CPU-to-CPU and CPU-to-IO Hub (IOH) connections. Note that the system need not be fully connected, though doing so may provide a latency and bandwidth advantage. Since a physical link is uni-directional, a connection is implemented as a pair of links running in opposite directions.
Layered Architecture
The architecture of the Intel QuickPath Interconnect specifies a layered model, influenced by the success of the seven-layer Open Systems Interconnection (OSI) network model. The five layers, bottom up, are the:
- Physical layer: the actual wires carrying the signals and the associated circuitry and logic to support transmission, including both an analog and a digital aspect;
- Link layer, which guarantees reliable transmission and flow control on a single link;
- Routing layer, which directs packets through the fabric;
- Transport layer (reserved for future use);
- Protocol layer, which enforces a set of rules for exchanging packets.
The remainder of the article discusses the physical, link, routing, and protocol layers in detail. The physical layer works with data in granularities dubbed phits. The link layer works with flits, and all higher layers work with packets. Each section will explore its quantum of data in detail; for now only familiarity with the terms is needed to understand the relationships among the layers as we progress.
The initial Intel QPI products do not implement the transport layer. Therefore we offer a brief description here, but will not treat it further in this paper. The transport layer provides advanced routing and reliable end-to-end transmission in large-scale systems, and also includes other features such as encapsulation, which allows transmission of non-Intel QPI protocols across the Intel QPI fabric. The initial Intel QPI products did not require these features and thus do not implement the transport layer. Nevertheless, the architecture of the Intel QPI Interconnect specifies the transport layer to allow extensibility to, and define compatibility with, future products which might benefit from these sophisticated capabilities.
Note that the layered architecture allows modularity; for example, an Intel Core™ i7 processori is a single socket device that uses the Intel QPI protocols to pass information among internal uncore modules (the part of the processor excluding the cores) and the chipset (Intel X58). However implementation of the underlying layers is unique to that application. Implementing a common set of protocols among devices provides seamless integration into multi-socket systems, where a core on one socket can target a message to a core on another socket, all using Intel QPI messaging, while inter-core communication on a single socket may occur at a higher bandwidth using more signals than the Intel QPI physical layer specifies.
In the following sections, we will describe each of the layers in turn, beginning with the physical layer, continuing with the link and routing layers, and finally coming to the protocol layer. In the protocol layer section, we will detail both coherent and non-coherent flows, and sketch the impact of various legacy features in the final architecture of the protocol layer. At the end of the article, we provide an overview of Intel QuickPath Interconnect performance in its first generation of commercially available products.


text:
Dieselpunk + Steampunk Culture
Join Dieselpunks
Welcome, Mat. Great to have you with us.
Welcome toDieselpunks
Sign Upor Sign In
Or sign in with:
© 2020 Created by Tome Wilson.
Powered by
Badges |
Report an Issue |
Terms of Service
Please check your browser settings or contact your system administrator.

subset: commoncrawl


text:
Monday, October 18, 2010
Household size heterogeneity and the representative agent
Christos Koulovatianos, Carsten Schröder and Ulrich Schmidt address the question from a different angle. They ask whether differences in household size matter. They show it does not, theoretically, if the utility functions exhibit household-size economies (beyond subsistence consumption) that are invariant with income. I think that what the authors want to say here is that household size does not matter as long as preferences are such that consumption demand is linear in household size, which in fact does not imply that preferences are heterogeneous. Household size is just an argument in the household utility function. Or: household utility can be aggregated for individual utilities if the decisions rules can be aggregated, which is the case when they are linear.
Anyway, beyond these semantic issues, Koulovatianos, Schröder and Schmidt then provide survey evidence documenting that preferences have indeed the required property, namely that households perceived that the income necessary to maintain a given standard of living is linear in the number of its members. What is interesting here is that the survey covers many countries, possibly preempting the criticism I mentioned the other day.
On a separate note, this paper is particularly painful to read. It runs for 89 pages, and it is very confusing (even more than my post) because the authors do not use the right terminology. Also, they need to learn the virtues of conciseness and precision. I hope they did not send it to a journal in such bad shape. And of course they assume that all households have the same time preference, against which there is ample evidence and which matters much more as it has strong implications for savings.
9 comments:
- Christos Koulovatianos said...
This paper analyzes multi-dimensional heterogeneity. The dimensions of heterogeneity are two: (a) heterogeneity with respect to available resources (rich vs. poor), and (b) heterogeneity with respect to household size.
The theoretical analysis regarding household-size economies answers a particular question: "How can we control for one dimension in order to examine the role of the other dimension if aggregation is present?" This is an important question given the conceptual complexity two dimensions of heterogeneity bring to the table.
Household size economies are easy to define conceptually: give a one-member household a certain level of permanent income forever; then identify the permanent income of a multimember household that makes the material comfort (utility) of individuals in that household equal to this of the one-member household (assume that individuals in multimember households have a common utility function within the household); these two permanent incomes are called equivalent incomes.
Ratios of equivalent incomes capture household-size economies. In practice, multi-member households need lower per-capita income compared to one-member households because more than one people can share goods within the household (e.g. common space in a house, furniture, etc.).
Now, the requirement of exact aggregation implies that equivalent incomes are linearly related to each other. This is a property describing a necessary pattern that captures both dimensions of heterogeneity, i.e. rich vs. poor and household size: it says that if family-type subsistence needs are subtracted from household income, the resulting discretionary incomes entail household-size economies that are the same across the rich and the poor.
That demand functions (expressed as decision rules of household wealth) are linear parallel in wealth across different households (the intercepts can differ) is an additional property of aggregation.
Corollary 1 says that falsifying the whole theoretical construct of a representative consumer for an economy with underlying household-size heterogeneity collapses into empirically rejecting a single equation: this linear relationship across equivalent incomes given by equation (16) in the paper.
But equivalent incomes have a lot of controlling inside their definition. They are permanent incomes. So, how can one identify real-world objective data where different households always consume their permanent income? This is a very difficult task, so the paper proposes that the controlling can be done by survey respondents who think about hypothetical households in terms of permanent incomes.
Figure 1 is the key result of the paper. In each panel of Figure 1, five distinct groups of respondents (totally independent groups of about 400 respondents each) evaluate a multi-member household's equivalent income in relation to a fixed predetermined one-member-household income that has been given to them. The survey provides five income levels for rich vs. poor spanning a wide income range from the real-world one-member-household income distribution.
Corollary 1 says: if I take the answers of these five independent respondent groups and I join them together in one picture, then the five averages of the equivalent incomes stated by the five groups should all be on a straight line. Each panel of Figure 1 shows exactly this, a statement validated by specification tests appearing in Table 1. These are 7 tests (7 panels each corresponding to one multi-member family type), all unable to falsify the representative consumer (at least strongly).
- October 18, 2010 at 10:10 AM
- Christos Koulovatianos said...
Figures 2 and 3 show 42 more tests, but these refer to pilot studies where each respondent evaluates equivalent incomes referring to all five one-member household incomes given to them by the survey. These 42 tests are not the perfect thing to do for testing the validity of equation (16), but they lend support to the findings of Figure 1 (evidence from very different countries).
A comment about the importance of aggregation: aggregation implies that agents following simple rules of thumb for forecasting (such as tracking macroeconomic variables alone) may end up with perfectly informed forecasts about economic behavior in each and every corner of a complex economy of substantially heterogeneous agents. In brief, economic systems and economic forecasts are not as chaotic as we might think sometimes.
I wrote these two comments because I know that all this is a rather long and complicated stream of theoretical verifications and tests in the paper. My co-authors and I are still struggling with communicating this work...
Slides of the paper can also be found through this link:
- October 18, 2010 at 10:14 AM
- Christos Koulovatianos said...
Two clarification issues regarding the economic logician's posting:
1. The key null hypothesis of the paper tested is not that "income necessary to maintain a given standard of living is linear in the number of its members". Instead, the right thing to say is "If family-type subsistence needs are subtracted from household income, the resulting family-type permanent discretionary incomes entail household-size economies that are the same across the rich and the poor."
2. The model behind Theorem 2 of the paper does not imply "that all households have the same time preference". It assumes that all households have the same *choice-independent* rate of time preference.
To see this distinction think of a momentary utility function with respect to both consumption and time, denoted by v(c,t). Then,
rate of time preference = -v_12/v_1
where v_1 is the partial derivative with respect to the first argument (c), and v_12 is the cross derivative with respect to c and t.
Now, the multiplicatively separable form between c and t
v(c,t) = exp(rho(t))*u(c)
is the only way to make the rate of time preference choice-independent (it is easy to verify that rate of time preference = -v_12/v_1 = rho'(t)) in this case, and a bit more involved to verify that this multiplicatively separable form is is also necessary (there is an argument in a proof in the paper for this).
In Theorem 2 the functions we obtain are of the form
v(c,t) = exp(rho(t))*u(c,t)
where the rate of time preference is not choice-independent:
rate of time preference = rho'(t) - u_12/u_1
Now in the expression v(c,t) = exp(rho(t))*u(c,t) v's and u's are different across individuals, but rho(t) is common across all households. So, the rate of time preference is heterogeneous across households in the underlying model. In the thought experiment that respondents of the survey we drop this heterogeneity, but heterogeneous rates of time preference are consistent with aggregation.
- October 18, 2010 at 11:03 AM
I have seen this paper presented twice, several years apart (I think it was the same paper...). After neither of the presentations I understood what the paper is about. And I still do not. EL is making an honest effort here to do what the authors apparently cannot: give a statement in a few paragraphs of what the research question is, why it matters, what the method is and what the result is.
EL tries that, obviously being confused about the paper as well. An author responds with very long answers that do not address the concerns, just as it happened in those two presentations, and we are none the wiser.
Folks: rewrite this paper. Force yourself to not exceed 25 pages. Even if you think everything is important, loose some weight and put the extra stuff in an appendix.
- October 18, 2010 at 11:04 AM
Christos: EL raises broad questions, you respond at lengths about details. This is the problem with your paper.
- October 18, 2010 at 11:12 AM
- Christos Koulovatianos said...
Dear VIlfredo:
Yes, point taken, and many thanks! We'll try to do our best...
In a nutshell though: what you must have seen years ago was the comprehensive theoretical work that reveals the structure of aggregation; now it is the evidence part. The point of the paper as it stands now is that we find evidence of a world which possesses smiple structure where individual consumer behavior shows up on the aggregate. It was not clear whether such evidence would be out there.
Thanks again!
- October 18, 2010 at 11:55 AM
Christos, this is very good advice from Vilfredo you got here. I saw you present this Summer, I presume this paper, but I must confess I did not understand what it was about. With EL's summary I have a better picture, but it is still not clear.
Imagine you were to write a short piece like on VoxEU. What you would write there is what you need to focus on. The rest goes in the appendix, or another paper.
- October 18, 2010 at 3:36 PM
I have seen this paper presented in front of a theory audience and I must say that it is a very difficult topic even for theorists. It is easier to present such a paper in front of theorists though, rather than in front of empirical people. I saw the paper as it is now and I am a bit surprised by the comments: it is no longer than 28 pages and technical matters appear in the appendix. And there is an enormous amount of work and evidence put in this paper. I wonder why you are being so negative.
- October 18, 2010 at 4:48 PM
@Anonymous: perhaps because you're posting this comment under the veil of anonymity ...
- April 15, 2011 at 9:40 AM


text:
✕ Moltafet Team ✕
moltafet, team, mohamad~kf, source, soft, anti, addlist, chatroom, nimbuzz, programming, mobile, room, #flooder, cracker, trick, advertiser, block, back, maker, flood, info
welcome be forume khodet khosh umadi hatman ozv sho va baraye hemayat az ma bar roye g +1 click kon
nimbuzz-iranian, nimbuzz, bombus, mafia, cracker, crcker, bombusmod, flood, #flooder, user, cobra, idmm, opera, mini, tarfande
Forum : Best Soft For Nimbuzz
nimbuzz, forum, nimbuzzcat, software, #flooder, cracker, floo, flood, hacking, tools, chat, mobile
nimbuzz pc tricks|flooders|web flooder|all bombuzz|nibuzz applications
tricks, tips, mobile, applications, flood, tools, nimbuzz, flooding, application, flooders
Free forum : wel come to mamaz gang community
mig33, kicking, tools, admin, roll, #flooder, combo, kick, mamaz, gang, community
: nimbuzz flooder and pc tools
๑۩۞۩๑BlackbuzZ๑۩۞۩๑ ๑۩۞۩๑ nimbuzz ۩ flooder ۩ cracker ۩ tip & trick ۩ bot ۩ mobile ۩ pc ۩ dc ۩ vps ๑۩۞۩๑
nimbuzz, tools, cracker, flood, room, nimbuzz mobile, flooder, vps, private vertual server, free vps, facebook, crackers,
nimbuzz, stlylish, best, flood, site, facebook, tips, softw, tools, cracker, room, mobile, #flooder, freevps, crackers, dangerteam, hacki
¡^¡Nimbuzz¡^¡ tips & tricks,software,flooder,latest bombus,wapflood,webflood,add rooster,anti kick trickz,room hacking trick,id hacking trick,stylish nick creater,antiDc bombus,latest symbian dc bombus,xml script,mobile software,application,game,them
world, nimbuzz, anti, kick, trick, room, hacking, fastest, flood, tool, tips, tricks, software, #flooder, latest, bombus, wapflood, webflood, rooster, trickz, styli
discus about nimbuzz tricks, tools, mig33 tricks, tools, yahoo tips, youtube tips, mobile tools, mobile tips, pc tools, pc tips plus all IM, job, and how to make money, online earning tips, share video, software et
earning, shoping, tricks, nimbuzz, games, sports, tips, hang, antikick, bombus, #flooder, mig33, yahoo, mobile
this is a forum for nimbuzz users to interact with other users & share tricks with them . In this forum u will find nimbuzz pc software, tips, tricks, pc softwares and entertainment.
nimbuzz, flood, #flooder, mobile, forum, users, interact, with, other, share, tricks, them, this
This is a forum for nimbuzz users to interact withother users & share tricks with them . In this forum u will find nimbuzz software, tips, tricks, pc softwares and entertainment
#flooder, world, this, forum, nimbuzz, users, interact, withother, share, tricks, with, them, will, find, software, tips
nimbuzz tips and tricks|nimbuzz flooders|nimbuzz applications
mobile, #flooder, nimbuzz, flood, trick, tips, tricks, tools
Free forum : bombus, nimbuzz, flooder, bot, robat, nimbuzz69, dc, add flood, tarfand, tricks, tips, amuzesh, software, nimbuzz tools
free, forum, nimbuzz69, bombus, nimbuzz, #flooder, بوت, نیمباز, flood, ترفند, tricks, tips, آموزش, software, tools
This is a forum for nimbuzz users to interact with other users & share tricks with them. In this forum u will find nimbuzz software, tips, tricks, PC software's, android apks and entertainment.
nimbuzz, 2016, #flooder, blackcops, team, tool, tips, server, bots, disconnector, addlist, hanger, captcha, auto, flood
NImbuzzer Warriors Forum. . . Get the nimbuzz Flooders and tips and tricks
برنامه, نویسی, دانلود, موبایل, آهنگ, بازیهای, ویدئویی, bombus, anti, tabligh, bote, #flooder, gava, symbian, android, اطلاعيه, ها, اخبار, انجمن, nimbuzz, advertiser, maker, full, tarfand, ترفند
Download Pc and Mobile jabbers, Bombusmod xmls, avalon scripts, Chat room flooder softwares, Private flood, dc and anti dc tricks , baby engiler, Java Pc emulators, Also mobile, pc tricks , games & softwares , movie arena etc
free, nimbuzzmania, about, nimbuzz, tricks, softwares, games, tips, movie, video, wallpaper, flooding, tools


text:
Hello everyone
In short I have an ATL Dialog, which contains a listview created at runtime as a contained window. I have added an editing option to it by creating an edit box over the cell user selects (again created at runtime as a contained window). Up to this point everything works well.
What I need next is the to use tab to move to the "next cell" (ie. terminate editing and move it over the next cell in the list view). This however falls to a simple, yet vexing, problem where I can not trap the TAB key. I can catch the ENTER for example, which I use to terminate the editing and save the value, but TAB does not even enter WM_NOTIFY, WM_CHAR nor WM_KEYDOWN.
I have studied this quite a bit and found some juicy looking examples but every one of them falls to some small problem which I can not solve. I am not really an expert on WIN API programming, so it may well be that the answer is simple and I just can't see it.
The most vexing part is that many who ask about catching TAB want to move between EXISTING components thus their solutions end up having nothing to do with actually catching the TAB, which is what I really need as I am working with a single dynamically created CEdit box.
I have been trying to get a Hook to do this for me as on article I found suggested that in ATL it is the only way to catch the TAB. However while I can make the hook work, it apparently needs to be a static function and thus I can not access the few non static methods I need to move the edit box to it's new location.
So help? Please?
Thankful regards,