European Union Wine Label Information
PDO (Protected Designation of Origin)
According to the EU definition, PDO products are "produced, processed and prepared in a given geographical area, using recognized know-how".
Their quality and properties are significantly or exclusively determined by their environment, in both natural and human factors.
The category is named Appellation d&Origine Prot&g&e (AOP) in French,
Denominazione di Origine Protetta (DOP) in Italian and
Denominaci&n de Origen Protegida (DOP) in Spanish.
Each EU country has its own quality categories which correspond to PDO. The most significant are:
France: AOC (Appellation d'Origine Contr&l&e)
Italy: DOC (Denominazione di Origine Controllata) and DOCG (Denominazione di Origine Controllata e Garantita)
Spain: DO (Denominaci&n de Origen) and DOCa (Denominaci&n de Origen Calificada)
Portugal: IPR (Indica&&o de Proveni&ncia Regulamentada) and DOC (Denominac&o de Origem Controlada)
Germany: QbA (Qualit&tswein bestimmter Anbaugebiete) and 'Pr&dikatswein' (formerly known as 'QmP' or Qualit&tswein mit Pr&dikat)
Austria: Qualit&tswein and Pr&dikatswein, including DAC (Districtus Austriae Controllatus).
PGI (Protected Geographical Indication)
The EU definition of a PGI product is one closely linked to the geographical area in which it is produced, processed or prepared,
and which has specific qualities attributable to that geographical area.
The category is named Indication G&ographique Prot&g&e (IGP) in French,
Indicazione Geografica Protetta (IGP) in Italian and
Indicaci&n Geogr&fica Protegida (IGP) in Spanish.
Each EU country has its own quality categories which correspond to PGI. The most significant are:
France: VDP (Vin de Pays)
Italy: IGT (Indicazione Geografica Tipica)
Spain: VT (Vino de la Tierra)
Portugal: VR (Vinho Regional)
Germany: Landwein
Austria: Landwein.
Although the PGI production rules are not as stringent as those applied to PDO wines,
there are famous examples of PGI wines commanding more respect (and higher prices) than their PDO counterparts.
This is particularly prevalent in Tuscany (see ).
Below is a wine label from France's Rhone Valley, with annotations
highlighting the information required by EU wine labeling laws. Below that is an overview of the EU wine classifications prior to 2011.
Prior to 2011, all wine produced commercially within the EU fell into one of two categories:
'QWPSR' (Quality Wine Produced in a Specified Region) and the more basic 'Table Wine' (including 'Table Wine with a Geographical Indication').
QWPSR (Quality Wine Produced in a Specified Region) covered the same wine quality levels and types as PDO now does.
The difference is that PDO covers all foodstuffs and beverages, rather than just wine.
As clearly stated by its long title, QWPSR covered quality wines (i.e. those which met legally defined production standards) produced in officially delimited geographical areas.
Its French translation was VQPRD (Vin de Qualit& Produit dans une R&gion D&termin&e).
As is now the case with PDO, each EU country had its own classification/s (e.g. AOC in France, DOC and DOCG in Italy) which corresponded to QWPSR.
Table Wine and Table Wine with a Geographical Indication were collectively replaced by PGI in 2011.
The aim of this was to remove the word 'Table', along with its connotations of low quality, from the EU wine nomenclature.
An additional benefit was that it solved the disparity between the European use of 'Table Wine' (basic, low-quality wine) and the American use (wine with an alcohol content below 14% ABV).
Thus the phrases Vin de Table (France), Vino da Tavola (Italy), Vino de Mesa (Spain),
Vinho de Mesa (Portugal) and Tafelwein (Germany and Austria) are now legally obsolete.
For more information on this, see
For country-specific information, see our pages about wine labels from ,pgo【多图】_价格_图片- 天猫精选
搜索 天猫 商品/品牌/店铺
共10件相关商品
好友佳办公用品专营店
月成交 26笔
电装旗舰店
月成交 0笔
居尚灵保专卖店
月成交 0笔
东哲办公专营店
月成交 0笔
伦软数码专营店
月成交 0笔
您是不是想找下次自动登录
现在的位置:
& 综合 & 正文
MSDN 关于编译优化的一篇文章 PGO in VS 2005
写得真心不错，内容如下，其中图没办法copy过来，请链接到原文查看。
Profile-Guided Optimization with Microsoft Visual C++ 2005
Kang Su Gatlin
Microsoft Corporation
March 2004
Applies to:
Microsoft(R) Visual C++(R) 2005
Summary: Discussesprofile-guided optimization in Microsoft Visual C++ 2005 (formerly known asVisual C++ "Whidbey"), a powerful new feature that will allowapplications to be tuned
for actual customer scenarios. Real-world performancegains of over 20% are not uncommon. (13 printed pages)
Introduction
There areseveral reasons to program in C++, and one of the most important ones is theincredible performance that one can obtain. With the release of Microsoft(R)Visual C++(R) 2005, you will not only get great performance from all
of thetraditional methods of optimization, but we've added a new technique, whichallows users to get even more out of their application. In this article we showthe user how to use profile-guided optimization (PGO) to achieve thisincredible performance.
How Traditional C++ Compilers Work
To get a fullappreciation of profile-guided optimization, let's start with a discussion ofhow traditional compilers decide which optimizations to do.
Traditionalcompilers perform optimizations based on static source files. That is, theyanalyze the text of the source file, but use no knowledge about potential userinput that is not directly obtainable from the source code. For
example,consider the following function in a .cpp file:
setArray( a,
( x = 0; x & ++x)
array[x] = 0;
From this filethe compiler knows nothing about the potential values for "a"(besides they must be of type int), nor does it know anything about the typicalalignment of array.
Thiscompiler/linker model is not particularly bad, but it misses two majoropportunities for optimization: First, it doesn't exploit information that itcould gain from analyzing all s secondly it does not makeany
optimizations based upon expected/profiled behavior of the application.With WPO and PGO, we'll do both of these things.
Whole Program Optimization with Link-Time Code Generation
With VisualC++ 7.0 and beyond, including all recent versions of the Itanium(R) compiler,Visual C++ has supported a mechanism known as link-time code generation (LTCG).I won't spend too much time in this section, as Matt Pietrek
wrote a goodarticle on LTCG in his
(May 2002), which is freelyavailable from MSDN. But here are the basics...
LTCG is atechnology that allows the compiler to effectively compile all the source filesas a single translation unit. This is done in a two-step process:
The compilercompiles the source file and emits the result as an intermediate language (IL)into the generated .obj file rather than a standard object file. It's worthnoting that this
IL is not the same thing as MSIL (which is used by theMicrosoft(R) .NET Framework).
When thelinker is invoked with /LTCG, the linker actually invokes the backend tocompile all the code compiled with WPO. All of the IL from the WPO .obj filesare aggregated and a call
graph of the complete program can be generated. Fromthis the compiler backend and linker compiles the whole-program and links itinto an executable image.
With WPO thecompiler now has more information about the structure of the entire program.Thus it can be more effective in performing certain types of optimizations. Forexample, when doing traditional compilation/linking, the compiler
could notinline a function from source file foo.cpp to source file bar.cpp. Whencompiling bar.cpp, the compiler does not have any info about foo.cpp. With WPOthe compiler now has both bar.cpp and foo.cpp (in IL form) available to it, andcan make optimizations
that ordinarily would not be possible (like crosstranslation unit inlining).
How do youcompile an application to make use of LTCG? There are two steps:
First compilethe source code with the Whole Program Optimization compiler switch (/GL):
cl.exe /GL /O2 /c test.cpp foo.cpp
Then link allof the object files in the program with the /LTCG switch.
link /LTCG test.obj foo.obj /:test.exe
That's it. Youcan now run the generated executable and usually it will be faster. We've seena lot of benefit with LTCG, but it does not come for free. There are increasedmemory requirements at compile/link time. This is because
all of the IL must beaddressable, which potentially can be tens or hundreds of compilation units.This can increase the memory requirements needed to build a project, andfurther can increase the total time to build.
Profile Guided Optimization
LTCG canobviously give you some performance benefit, but we have only just begunimproving the performance of your application. Another new technology used inconjunction with LTCG can give an additional performance boost, and in
manycases this boost can be very significant. This technology is calledprofile-guided optimization (PGO).
The ideabehind PGO is simple: Generate profiles from running the executable/dll onreal-world inputs, which are then used to assist the compiler in generatingoptimized code for the particular executable. (Note that PGO can be applied
tooptimizing unmanaged executables or DLLs, but not to .NET/managed images. Forthe rest of the article, I'll simply refer to the optimized image as anexecutable or application, although the information applies equally to DLLs.)Really that's about all there
is to it, but there are details worthinvestigating.
There arethree general phases to creating a PGO application:
Compile intoinstrumented code.
Traininstrumented code.
Re-compileinto optimized code.
We explaineach of these three phases in more depth below. See Figure 1 for a graphicalrepresentation of the process.
Figure 1. ThePGO build process
Compile Instrumented Code
The firstphase is instrumenting the executable. To do this, you first compile the sourcefiles with WPO (/GL). After this take all of the source files from theapplication and link them with the /LTCG:PGINSTRUMENT switch (this canabbreviated
as /LTCG:PGI). Note that not all files need be compiled /GL for PGOto work on the application as a whole. PGO will instrument those files compiledwith /GL and won't instrument those that aren't.
Theinstrumentation is done by strategically placing different types of probes inthe code. You can break the types of probes up into two very rough types: thosethat are collecting flow information and those that are collecting
valueinformation. I won't go into detail as to how we decide what to use and whereto use it, but we do go through painstaking effort to make efficient use of theprobes. It's also worth noting that the instrumented code may not be asoptimized with /O2 as the
same un-instrumented /O2 code. (Although we do asmany optimizations as we can without interfering with the probes we are placingin the instrumented code.) So with the combination of the instrumentation andun-optimized code, expect your application to run slower.
(Of course theoptimized code will be optimized without the probes in the code.)
The result oflinking /LTCG:PGI will be an executable or DLL and a PGO database file (.PGD).By default the PGD file takes the name of the generated executable, but theuser can specify the name of the PGD file when linking with
the /PGD:filename linkeroption.
Table 1 belowlists the files that will be generated after each step given in the leftcolumn. Note that no files are removed.
Table 1.Generated files after each step
File Generated
At the start of compilation
MyApp.cpp foo.cpp
After compiling with /c /GL
MyApp.obj foo.obj
After linking with /LTCG:PGI /PGD:MyApp.pgd /out:MyApp.inst.exe
MyApp.inst.exe MyApp.pgd
After training the instrumented application with three scenarios.
MyApp1.pgc MyApp2.pgc MyApp3.pgc
After relinking with /LTCG:PGO./PGD:MyApp.pgd
MyApp.opt.exe
Train Instrumented Code
After creatingthe instrumented executable, the next step is to train the executable. You dothis by running the executable with scenarios that reflect how they'll be usedin real life. The output of each scenario run is a PGO count
file (.PGC). Thesefiles take on the same name as the .PGD file with the a number appended on theend (starting with "1" and increasing with subsequent runs). A given.PGC file can be removed if the user decides that the particular scenariowasn't useful.
CompileOptimized Code
The last stepis to relink the executable with the profile information collected from runningthe scenarios. This time when you link the application, you use the linkerswitch /LTCG:PGOPTIMIZE (or /LTCG:PGO). This will use the generated
profiledata to create an optimized executable. Prior to this optimization the linkerwill automatically invoke pgomgr. pgomgr will, by default, merge all of the.PGC files in the current directory whose name matches the .PGD file into the.PGD file.
Updating source code. It's important to note that if the sourcecode of the compiled application changed after the .PGD files were generated,then /LTCG:PGO will revert to simply doing
an /LTCG build, and not use any ofthe profile information. So what do you do if you've spent considerablegenerating profile from your instrumented code, and then realize that you needto make a small change to the code, but would like to reuse the profiles
thatyou've generated? In this case you can specify /LTCG:PGUPDATE (or /LTCG:PGU).PGUPDATE allows the linker to compile modified source code, while using theoriginal .PGD file
What PGO Can Do
We now have an understanding of how to generate PGOapplications, so now the question is, what does PGO do for us? Whatoptimizations does it enable? Here we give a partial list and we
expect the setof optimizations we currently do to expand as we find new optimizations andlearn better heuristics.
Inlining. As described earlier, WPO givesthe application the ability to find more inlining opportunities. With PGO thisis supplemented
with additional information to help make this determination.For example, examine the call graph in Figures 2, 3, and 4 below.
In Figure 2.we see that a, foo, and bat all call bar, which in turn calls baz.
Figure 2. Theoriginal call graph of a program
Figure 3. Themeasured call frequencies, obtained with PGO
Figure 4. Theoptimized call-graph based on the profile obtained in Figure 3
Partial Inlining. Next is an optimizationthat is at least partially familiar to most programmers. In many hot functions,there exist
paths of code within the function some aredownright cold. In Figure 5 below, we will inline the purple sections of code,but not the blue.
Figure 5. Acontrol flow graph, where the purple nodes get inlined, while the blue nodedoes not
Cold Code Separation. Codeblocks that are not called during profiling, cold code, are moved to the end ofthe set of sections. Thus
pages in the working set usually consist ofinstructions that will be executed, according to the profile information.
Figure 6.Control flow graph showing how the optimized layout moves basic blocks togetherthat are used more often, and cold basic blocks further away.
Size/Speed Optimization. Functionsthat are called more often can be optimized for speed while those that arecalled less frequently
get optimized for size. This tends to be the righttradeoff.
Block Layout. In this optimization, weform the hottest paths through a function, and lay them out such that hot pathsare spatially
located closer together. This can increase the utilization of theinstruction cache and decrease the working set size and number of pages used.
Virtual Call Speculation. Virtualcalls can be expensive due to the jumping through the vtable to invoke method.With PGO, the compiler
can speculate at the call site of a virtual call andinline the method of the speculated object into t the datato make this decision is gathered with the instrumented application. In theoptimized code, the guard around the inlined function
is a check to ensure thatthe type of the speculated object matches the derived object.
The followingpseudocode shows a base class, two derived classes, and a function invoking avirtual function.
// This is the Func function before PGO has optimized it.
Func(Base *A){
A-&call();
The code belowshows the result of optimizing the above code, given that the dynamic type of"A" is almost always Foo.
// This is the Func function call after PGO has optimized it.
Func(Base *A){
(type(A) == Foo:Base) {
// inline of A-&call();
A-&call();
A short noteon PGO and DLLs: You train/profile the DLLs by running the executable, whichlinks the DLL on a set of representative scenarios. You can further use differentexecutables for different scenarios and merge all of the
scenarios into asingle .PGD file. It is important to know that PGO technology currently doesnot support static libraries.
General Effectiveness
The currentimplementation of PGO has proven to be extremely effective in gettingreal-world performance. For example, we've seen 30%+ improvement on largereal-world applications such as Microsoft(R) SQL Server, and 4-15% gains on
theSPEC benchmarks (depending on the architecture). See Figure 7 for performancespeedup of PGO over the best static compilation setting (Link Time CodeGeneration) using the SPEC benchmarks.
Figure 7. SPECperformance improvement with PGO over that of Link Time Code Generation, forall three platforms
More PGO Tools
PGO support inMicrosoft(R) Visual C++ comes with a couple of tools to help the user doprecisely what they need to do. This section describes each of these includedtools.
pgomgr. pgomgr is a tool to dopost-processing on .pgd files generated by PGO. (Note that for PSDK Itaniumcompiler users, pgomgr in
Whidbey replaces pgmerge and part of pgopt from theold PSDK compiler. These two tools are no longer available, as theirfunctionality has been subsumed.) The .PGC files need to be merged into the.PGD to be used for the optimize phase of PGO. The pgomgr tool
does thismerging. The syntax for this statement is:
pgomgr [options] [Profile-Count paths] &Profile-Database&
By default, if/LTCG:PGI is run in a directory with .PGC files, those .PGC files will bemerged if they match the .PGD file for the program being linked (so you needn'talways use pgomgr). The list of options is given here:
/?Gets help
/helpSame as /?
/clear Remove all merge data from the specified pgd
/detail Display verbose program statistics
/merge[:n] Merge the given PGC file(s), with optionalinteger weight
/summary Display program statistics
/unique Display decorated function names
pgosweep. The pgosweep tools interruptsa running program that was built with PGO instrumentation, writes the currentcounts to a new
.PGC file, and then clears the counts from the runtime datastructures. This program has two main intended uses: First, if PGO is being usedon code that never ends. (For instance, things like the OS kernel.) Second, toobtain precise profile information about
a certain part of the program. Forexample, you may not want to profile the night-time scenarios of anapplication, so you use pogosweep in those situation and then delete the .PGCfiles from that part of the scenario.
The usage forpogosweep is:
pogosweep &instrumented image& &.PGC file to be created&
PGO and the Visual Studio IDE
Command-linetools are great to use, but if you're working within the Microsoft(R) VisualStudio(R) Integrated Development Environment (IDE), then you may want to fullyleverage functionality, such as PGO, from within the Visual Studio
IDE. VisualStudio 2005 (formerly known as Visual Studio "Whidbey") offers supportfor PGO through a set of menu items, which allow the programmer to do aninstrumented build, run scenarios, do an optimized build, or do an updatebuild. The instrumented build,
optimized build, and update build all produce an.exe or .dll file as the output. The optimized builds and the update buildrequire a .pgd file to be available. This .pgd file can be generated by runningthe Run Profiling Scenario menu item.
Figure 8. Ascreen shot of PGO support in the Visual Studio 2005 IDE
Some Tips for PGO Use
Here are somebasic tips that can improve your PGO experience.
The scenariosused to generate the profile data should resemble the real-world scenarios theapplication will see when deployed. The scenarios are NOT and attempt at doingcode coverage.
Usingscenarios to train with that are not representative of real-world use canresult in code that performs worse than if PGO was not used.
Name theoptimized code something different from the instrumented code, for example,app.opt.exe and app.inst.exe. This way you can rerun the instrumentedapplication to supplement your
set of scenario profiles without rerunningeverything again.
To tweakresults, use the /clear option of pgomgr to clear out a .PGD files.
If you havetwo scenarios that run for different amounts of time, but would like them to beweighted equally, you can use the weight switch (/merge:weight in pgomgr) on.PGC files to adjust
You can usethe speed switch to change the speed/size thresholds.
Use the inlinethreshold switch with great caution. The values from 0-100 aren't linear.
Conclusion
In closing,the basic steps for generating a PGO application are:
Compile withWhole Program Optimization (/GL) on the files that you would like PGO to workon. The user can selectively choose files that don't get optimized with wholeprogram optimization
and PGO, by not compiling them with /GL.
Link theapplication with Link Time Code Generation using /LTCG:PGINSTRUMENT. Thisgenerates an instrumented executable.
Train theapplication with scenarios generating .pgc files.
Re-compile theapplication (although you're invoking the linker) with /LTCG:PGOPTIMIZE. Thiswill optimize the executable based on the profile data.
The end resultis a program or library that is optimized for the real-world situations thatyour program or library will run under.
About the Author
Kang Su Gatlin is a ProgramManager at Microsoft in the Visual C++ group. He received his PhD from UC SanDiego. His focus is on high-performance computation andoptimization—essentially
he enjoys making code run fast.
转自：http://msdn.microsoft.com/zh-cn/aa289170(VS.90).aspx#profileguidedoptimization_topic1
【上篇】【下篇】}