??xml version="1.0" encoding="utf-8" standalone="yes"?>
PS: 译能很好的训练一个h的英语和汉语句子l织能力Q时不时的让学英语的娃尝试一下翻译英语课文也是某种ȝ吧?/span>
׃安娜U普?/span>(出生?/span>1954q?/span>10?/span>10?/span>)Q婚后名字朱丽安娜_拉,是一个d?/span>-U鲁Z^动物学家。她?/span>1971q兰?/span>508航班I难的唯一q存者,I难发生后独自一人在亚马逊热带雨林生zM11天。他?/span>3000c?/span>(9843英尺)坠落Q落地时仍然被安全带捆在座椅上?br />
事前
׃安娜?/span>1954q出生于U鲁利马Q父母都是在利马自然历史博物馆工作的德国人。她是生物学家汉斯威廉科普克和鸟cd家玛丽亚U普克的唯一孩子。在׃安娜14岁时Q其父母带她M马逊雨林徏造研I基?/span>--潘古那。在q里Ҏ了一?#8220;丛林孩子”Q学了野外生存技能。教育当局不同意这样做Q要求朱莉安娜回到利马亚历山大冯z堡h志学校参加考试。她?/span>1971q?/span>12?/span>23日在此校毕业?br />
I难
׃安娜U普克在l历难上有双重生存故事可供讲述。在1971q圣诞节前夕Q朱丽安娜搭乘了兰萨508航班。那时她刚从高中毕业Q她的母亲玛丽亚本打在1971q?/span>12?/span>19-20日带着奛_L古那Q但是朱丽安娜希望能?/span>12?/span>23日去利马参加毕业典礼。玛丽亚同意Q打圣诞节前夕再飞往潘古那,可是除了里尼思君Ҏ航空(兰萨)q有IZ其余所有航班的席位均已售罄。尽丈夫汉斯威廉强烈要求妻子不要乘坐那家航I公司的航班Q因航空公司早已臭名昭著Q但最l她们还是预定了机票。飞v飞不久遭遇闪电,在空中开始解体ƈ一头冲向地面。朱丽安娜发现自׃直被捆在座椅上,下落近2英里最l落入秘鲁热带雨林?/span>
在朱丽安娜科普克的此ơ事件上Q专家指出由于在下降中她被安攑ֈ座椅上才DҎ了下来,只是断了锁骨而已。她是该航班的唯一q存者,着溪流在雨林里生活?/span>11天?/span>
在她醒过来后丛林里的昆虫不再叮咬她,可是蛆已l感染了她的背Q?/span>9天后Q她扑ֈ了一处露营地。在此,她给自己q行了初U治疗,例如用汽Ҏ到蛆感染的部位。蛆x汽油就d了伤口。几个小时候后Q运木工人发C她,l与基本ȝq把她带到更宜居的区域,然后她被I到医院?/span>
伤口恢复后,׃安娜帮助搜救队定位失事地点和搜救死难者尸体。她妈妈的尸体于1972q?/span>1?/span>12日被发现。朱丽安娜回到d国后伤口完全恢复了正常。跟父母cMQ朱丽安娜获得生物学学位后返回秘鲁l深入研I蝙蝠。她的双重生存故事成了书和电qMQ其中包括了她的自传和他传,“当我从天而降”Q以及导演沃U佐格的U录?#8220;膀上的希望”。他(沃纳赫尔佐格)?/span>1971q也预定了她(׃安娜)的那ơ航班,飞机起飞前最后一分钟改变计划Q从而躲q一劫?br />
事后
׃安娜的oq存zL了各U瞎猜推断的主题?很明昑֥被安全带捆在座椅上有了某U程度的盄和缓Ԍ而且理论上外围整排的座椅Q就是朱丽安娜两边的那些QvC降落伞的作用Q减~了她下落的速度..."?#8220;风暴漂移以及落地点厚厚的枝叶可以q一步降低里冲击?..”?/span>
׃安娜回到德国d康复q来Q走了父母一L路,在基大学学习生物,1980q毕业。在慕尼黑麦克西c_大学获得博士学位后返回到U鲁展开Z^动物研究Q专注于蝙蝠Q在1987q发表论文,“U鲁热带雨林里一个蝙蝠生物王国的研究”?/span>1989q朱莉安娜科普克和一个专注于研究寄生黄蜂的昆虫学家艾力克q拉l婚?/span>2000q朱丽安娜接了潘古那当上了MQQ父亲去世了?/span>
现在׃安娜q拉在慕黑巴伐利亚动物学蒐藏研I中心当理员。她的自传和他传”当我从天而降”(徯: Als ich vom Himmel fie)?/span>2011q?/span>3?/span>10日由z林格出版Qؓ此她获得?/span>2011柯琳文学奖?/span>2019q秘鲁政府授予她高军官的杰出服务奖?br />
Stride is an important concept in digital image processing. It allows performing several operations with an image in a very fast manner (in constant time) by simple modification of image metadata. If you are interested in finding out what stride is and how to use it stick with us.
Pixel representation in a computer memory
Before we dive into the concept of stride we first need to revise how digital images are stored in a computer memory. We will start from a pixel.
An image pixel is represented in a computer memory by a fixed number of bits. Typical pixel bit depth (amount of bits per pixel) is 32, 16, 8 or, for binary images, 1 bit. In typical RGB images, 8 bits are often used to store the color value of a single channel. Thus, the total bit depth of one pixel is 24. Processing 32 and 16-bit chunks of data is simple and effective on a typical 32 and 64-bit processors. Therefore, the pixels are stored in the format of 32 bits, where the older (or younger, depending on the implementation) 8 bits remain unused. Such an approach to storing pixels requires more memory, but it allows speeding up image processing by using the standard size of the machine word. Thus, a standard RGB image occupies 32 bits in memory and has a depth of 24 bits. We will call another 8 bits necessary to supplement the size of the memory occupied by a pixel to the value of a multiple of degree 2, pixel padding. The total number of bytes occupied by a pixel in memory is called pixel stride (See Image 1).
Image representation in a computer memory
Images are stored in computer memory pixel-by-pixel, line by line. The upper left corner of the image is usually chosen as a coordinate origin (the upper left pixel of the image has the index [0, 0]). The image is stored in memory as a one-dimensional array. Pixels of the first line of the image are first written to the memory, then pixels of the second line and so on up to the last line. Each line in addition to the pixel bytes may also contain additional bytes — line padding. Additional bytes usually do not contain useful information and do not affect the visualization of an image when, for example, displayed on the screen. These additional bytes serve to complement a line, which is necessary for more efficient image processing and is caused by the specificity of the hardware used. For example, Cairo (a popular open source vector graphics software library) requires alignment of rows to multiple 4 bytes, which allows for more efficient image processing algorithms using vectorized processor operations and processing several image pixels simultaneously.
Introducing the term of line padding requires to introduce another closely coupled term — line stride.
Line stride (increment, pitch or step size) is the number of bytes that one needs to add to the address in the first pixel of a row in order to go to the address of the first pixel of the next row. It is important to note that an image width is measured in pixels and describes an image itself (and doesn’t depend on how an image is stored in a computer memory). In contrast, a line stride depends on how an image is represented in memory and is measured in bytes.
In program source code, an image is usually represented by a data structure containing metadata (image width and height, line stride, number of channels, encoding type, etc.), as well as a pointer to the address of the first image pixel in memory (further we will refer to this address as data_begin). This information allows us to unambiguously read and decode an image from memory, as well as to perform a series of fast image operations by changing only a metadata associated with an image.
An image representation in a computer memory. Lines of an image are stored one by one in one-dimensional array.
Image operations:
Let’s summarize all the terms which we introduced to this moment:
pixel_address — a pixel address in memory
pixel depth —the number of bits per pixel (containing valuable information)
pixel_stride — the number of bytes occupied in memory by a pixel of an image
data_begin — the address of the first image pixel in memory
channels — the number of image channels (3 for an RGB-image)
channel_address — the address of a particular pixel channel in memory
height — the image height in pixels
width — the image width in pixels
line_stride — the number of bytes occupied in memory by a line of an image
Operations:
1. Computing pixel address in memory
The equation relating pixel memory address to its coordinates [y, x] in the image coordinate system can be represented as:
pixel_address = data_begin + y * line_stride + x * pixel_stride, (1)
where data_begin — the address of the first image pixel in memory.
Equation (1) is used whenever you access an image in memory. In the rest of operations, presented in this post, we will only change a metadata associated with an image and assume, that the equation (1) is applied after in order to access image.
2. Pixel decoding (for RGB image with an equal amount of bits per channel):
channel_address = pixel_address + n * depth / channels, (2)
where n is a channel index: n = 0, 1, …, channels — 1. Thus, for instance, for the typical RGB-image with an equal amount of bits per channel, a channel address in memory can be computed as follows:
R = pixel_address,
G = pixel_address + depth / channels,
B = pixel_address + 2 * depth / channels.
It is important to note that these equations depend on the type of the image stored. There are formats in which different number of bytes is used to store different channels.
3. Image flip
3.1 Vertical flip
data_begin = data_begin + (height- 1) * line_stride ,
line_stride = -line_stride.
Pointer to the first image pixel for the vertical flip
The negative line stride being inserted into equation (1) allows us to move upwards reading (or visualizing) an image from the last row to the first, thus, realizing vertical flip.
3.2 Horizontal flip
data_begin = data_begin + (width — 1) * pixel_stride ,
pixel_stride = -pixel_stride.
Pointer to the first image pixel for the horizontal flip
In the same manner as with negative line stride in the previous example, the negative pixel stride here allows us to move from right to left and to read (or visualize) an image flipped horizontally.
3.3 Vertical and horizontal flip
The combination of previous two approaches allows to flip an image in both directions at once:
data_begin = data_begin + (height-1) * line_stride + (width-1) * pixel_stride,
line_stride = -line_stride,
pixel_stride = -pixel_stride.
Pointer to the first image pixel for the simultaneous vertical and horizontal flip
4. Extracting image subwindow
data_begin = new_data_begin,
width = new_width,
height = new_height.
With this approach we set a new origin of our image (inside a boundary of the original image) and set a width and height which basically tell us how many time we should apply an equation (1) to read all pixels (width x height) and after which amount of pixels read we should increase the y coordinate (to start reading pixels of the next row). Note that such parameters as line stride remain unchanged.
5. Extracting single image channel
To extract a single image channel we can use a combination of equations (1) and (2):
pixel_address = data_begin + y * line_stride + x * pixel_stride + n * depth / channels,
where n — channel index, n = 0, 1, …, channels — 1.
REFERENCES
1. A programmer’s view on digital images: the essentials: https://www.collabora.com/news-and-blog/blog/2016/02/16/a-programmers-view-on-digital-images-the-essentials/
2. Microsoft Media Foundation Programming Guide: Image Stride:Image Stride When a video image is stored in memory, the memory buffer might contain extra padding bytes after each row of pixels…docs.microsoft.com
3. Wikipedia: Stride of an array: https://en.wikipedia.org/wiki/Stride_of_an_array
4. Cairo library: https://cairographics.org/
A PDF describes the content and appearance of one or more pages. It also contains a definition of the physical size of those pages. That page size definition is not as straightforward as you might think. There can in fact be up to 5 different definitions in a PDF that relate to the size of its pages. These are called the boundary boxes or page boxes:
· The MediaBox is used to specify the width and height of the page. For the average user, this probably equals the actual page size. For prepress use, this is not the case as we prefer our pages to be defined slightly oversized so that we can see the bleed (Images or other elements touching an outer edge of a printed page need to extend beyond the edge of the paper to compensate for inaccuracies in trimming the page), the crop marks and useful information such as the file name or the date and time when the file was created. This means that PDF files used in graphic arts usually have a MediaBox which is larger than the trimmed page size.
· The CropBox defines the region that the PDF viewer application is expected to display or print. So if a PDF contains a CropBox definition, Acrobat uses it for screen display and printing. For prepress use, the CropBox is pretty irrelevant. The GWG industry association recommends not to use it at all.
· The TrimBox defines the intended dimensions of the finished page. Contrary to the CropBox, the TrimBox is very important because it defines the actual page size that gets printed. The imposition programs and workflows that I know all use the TrimBox as the basis for positioning pages on a press sheet. By default the TrimBox equals the CropBox.
· The BleedBox determines the region to which the page contents needs to be clipped when output in a production environment. Usually the BleedBox is 3 to 5 millimeters larger than the TrimBox. It is nice to know the size of the BleedBox but it isn’t that important in graphic arts. Most prepress systems allow you to define the amount of bleed yourself and ignore the BleedBox. By default the BleedBox equals the CropBox.
· The ArtBox is a bit of a special case. It was originally added to indicate the area covered by the artwork of the page. It is never used for that but can be handy in a few cases:
· On a PDF page that contains an advertisement, the ArtBox can be used to define the location of that ad. This allows you to place that PDF on another page but only use the area covered by the advert.
· A more common use of the ArtBox is as a means to indicate the safety zone. When creating a poster that will be placed in a lightbox, the designer must make sure text and logo’s aren’t positioned too close to the edge. If the poster is not mounted properly, this could cause that text or logo to disappear behind the frame of the lightbox. In book design, there is also a margin where you cannot put text because the binding might make it difficult to read text that is too close to the spine. The area where it is safe to place graphic elements is called the safety zone or text safe area. The ArtBox can be used to indicate the dimensions of this part of the page.
General rules regarding page boxes
· Each page in a PDF can have different sizes for the various page boxes.
· The page boxes are always rectangular. That may seem logical but artwork is not always rectangular: a PDF can represent an oval label or the foldout of a cardboard box.
· A PDF always has a MediaBox definition. All the other page boxes do not necessarily have to be present in regular PDF files.
· The above rule is not true for the PDF/X file formats:
· PDF/X-1a and PDF/X-3 compliant files need to include the MediaBox, TrimBox, and BleedBox.
· PDF/X-4 files need, next to the MediaBox, a TrimBox or an ArtBox, but not both. The ArtBox or TrimBox cannot be larger that the BleedBox. If a CropBox is present, the ArtBox, TrimBox, and BleedBox need to extend beyond its boundaries.
· The MediaBox is the largest page box in a PDF. The other page boxes can equal the size of the MediaBox but they are not expected to be larger (The latter is explicitly required in the PDF/X-4 requirements). If they are larger, the PDF viewer will use the values of the MediaBox.
BBox
Within PDF files there is another box, the bounding box or BBox, that is used. The bounding box is a rectangular frame that determines the dimensions of an object (such as a graphic, font or pattern) that is placed inside a PDF document. As such, this box has nothing to do with the page boxes.
Please send updates/corrections to predef-contribute.
Type | Macro | Description |
---|---|---|
Identification | __alpha__ | Defined by GNU C |
Version | __alpha_ev'V'__ | V = Version |
Identification | __alpha | Defined by DEC C |
Identification | _M_ALPHA | Defined by Visual Studio |
CPU | Macro |
---|---|
Alpha EV4 | __alpha_ev4__ |
Alpha EV5 | __alpha_ev5__ |
Alpha EV6 | __alpha_ev6__ |
Type | Macro | Description |
---|---|---|
Identification | __amd64__ __amd64 __x86_64__ __x86_64 | Defined by GNU C and Sun Studio |
Identification | _M_X64_M_AMD64 | Defined by Visual Studio |
Notice that x32 can be detected by checking if the CPU uses the ILP32 data model.
Type | Macro | Description |
---|---|---|
Identification | __arm__ | Defined by GNU C and RealView |
Identification | __thumb__ | Defined by GNU C and RealView in Thumb mode |
Version | __ARM_ARCH_'V'__ | V = Version Defined by GNU C 1 |
Identification | __TARGET_ARCH_ARM __TARGET_ARCH_THUMB | Defined by RealView |
Version | __TARGET_ARCH_ARM = V__TARGET_ARCH_THUMB = V | V = Version |
Version | __TARGET_ARCH_'VR' | VR = Version and Revision |
Identification | _ARM | Defined by ImageCraft C |
Identification | _M_ARM | Defined by Visual Studio |
Identification | _M_ARMT | Defined by Visual Studio in Thumb mode |
Version | _M_ARM = V | V = Version |
Identification | __arm | Defined by Diab |
CPU | Macro | _M_ARM |
---|---|---|
ARM 2 | __ARM_ARCH_2__ | |
ARM 3 | __ARM_ARCH_3__ __ARM_ARCH_3M__ | |
ARM 4T | __ARM_ARCH_4T__ __TARGET_ARM_4T | |
ARM 5 | __ARM_ARCH_5__ __ARM_ARCH_5E__ | 5 |
ARM 5T | __ARM_ARCH_5T__ __ARM_ARCH_5TE__ __ARM_ARCH_5TEJ__ | |
ARM 6 | __ARM_ARCH_6__ __ARM_ARCH_6J__ __ARM_ARCH_6K__ __ARM_ARCH_6Z__ __ARM_ARCH_6ZK__ | 6 |
ARM 6T2 | __ARM_ARCH_6T2__ | |
ARM 7 | __ARM_ARCH_7__ __ARM_ARCH_7A__ __ARM_ARCH_7R__ __ARM_ARCH_7M__ __ARM_ARCH_7S__ | 7 |
Type | Macro | Description |
---|---|---|
Identification | __aarch64__ | Defined by GNU C 1 |
Type | Macro | Description |
---|---|---|
Identification | __bfin __BFIN__ | Defined by GNU C |
Type | Macro | Description |
---|---|---|
Identification | __convex__ | Defined by GNU C |
Version | __convex_'V'__ | V = Version |
CPU | Macro |
---|---|
Convex C1 | __convex_c1__ |
Convex C2 | __convex_c2__ |
Convex C32xx series | __convex_c32__ |
Convex C34xx series | __convex_c34__ |
Convex C38xx series | __convex_c38__ |
Type | Macro | |
---|---|---|
Identification | __epiphany__ |
Type | Macro | Description |
---|---|---|
Identification | __hppa__ | Defined by GNU C |
Identification | __HPPA__ | Defined by Stratus VOS C |
Identification | __hppa | |
Version | _PA_RISC'V'_'R' | V = Version R = Revision |
See also OpenPA.net.
CPU | Macro |
---|---|
PA RISC 1.0 | _PA_RISC1_0 |
PA RISC 1.1 | _PA_RISC1_1 __HPPA11__ __PA7100__ |
PA RISC 2.0 | _PA_RISC2_0 __RISC2_0__ __HPPA20__ __PA8000__ |
Type | Macro | Format | Description |
---|---|---|---|
Identification | i386 __i386 __i386__ | Defined by GNU C | |
Version | __i386__ __i486__ __i586__ __i686__ | Defined by GNU C | |
Identification | __i386 | Defined by Sun Studio | |
Identification | __i386 __IA32__ | Defined by Stratus VOS C | |
Identification | _M_I86 | Only defined for 16-bits architectures Defined by Visual Studio, Digital Mars, and Watcom C/C++ (see note below) | |
Identification | _M_IX86 | Only defined for 32-bits architectures Defined by Visual Studio, Intel C/C++, Digital Mars, and Watcom C/C++ | |
Version | _M_IX86 | V00 | V = Version |
Identification | __X86__ | Defined by Watcom C/C++ | |
Identification | _X86_ | Defined by MinGW32 | |
Identification | __THW_INTEL__ | Defined by XL C/C++ | |
Identification | __I86__ | Defined by Digital Mars | |
Version | __I86__ | V | V = Version |
Identification | __INTEL__ | Defined by CodeWarrior | |
Identification | __386 | Defined by Diab |
Notice that Watcom C/C++ defines _M_IX86
for both 16-bits and 32-bits architectures. Use __386__
or _M_I386
to detect 32-bits architectures in this case.
Notice that the Stratus VOS is big-endian on IA32, so these macros cannot be used to detect endianness if __VOS__
is set.
CPU | _M_IX86 | __I86__ |
---|---|---|
80386 | 300 | 3 |
80486 | 400 | 4 |
Pentium | 500 | 5 |
Pentium Pro/II | 600 | 6 |
Type | Macro | Format | Description |
---|---|---|---|
Identification | __ia64__ _IA64 __IA64__ | Defined by GNU C | |
Identification | __ia64 | Defined by HP aCC | |
Identification | _M_IA64 | Defined by Visual Studio | |
Identification | _M_IA64 | Defined by Intel C/C++ | |
Version | _M_IA64 | ? | |
Identification | __itanium__ | Defined by Intel C/C++ |
CPU | _M_IA64 (Intel C/C++) |
---|---|
64100 |
Type | Macro | Description |
---|---|---|
Identification | __m68k__ | Defined by GNU C |
Version | __mc'V'__ __mc'V' mc'V' | V = Version |
Identification | M68000 | Defined by SAS/C |
Identification | __MC68K__ | Defined by Stratus VOS C |
Version | __MC'V'__ | V = Version |
CPU | Macro |
---|---|
68000 | __mc68000__ __MC68000__ |
68010 | __mc68010__ |
68020 | __mc68020__ __MC68020__ |
68030 | __mc68030__ __MC68030__ |
68040 | __mc68040__ |
68060 | __mc68060__ |
Type | Macro | Description |
---|---|---|
Identification | __mips__ mips | Defined by GNU C |
Version | _MIPS_ISA = _MIPS_ISA_MIPS'V' | V = MIPS ISA level |
Version | _R3000 _R4000 _R5900 | |
Identification | __mips | Defined by MIPSpro and GNU C |
Version | __mips | The value indicates the MIPS ISA (Instruction Set Architecture) level |
Version | __MIPS_ISA'V'__ | V = MIPS ISA level |
Identification | __MIPS__ | Defined by Metrowerks |
CPU | _MIPS_ISA | GNU C Macro | __mips | MIPSpro Macro |
---|---|---|---|---|
R2000 | _MIPS_ISA_MIPS1 | 1 | ||
R3000 | _MIPS_ISA_MIPS1 | _R3000 | 1 | |
R6000 | _MIPS_ISA_MIPS2 | 2 | __MIPS_ISA2__ | |
R4000 | _R4000 | |||
R4400 | _MIPS_ISA_MIPS3 | 3 | __MIPS_ISA3__ | |
R8000 | _MIPS_ISA_MIPS4 | 4 | __MIPS_ISA4__ | |
R10000 | _MIPS_ISA_MIPS4 | 4 | __MIPS_ISA4__ |
Type | Macro | Description |
---|---|---|
Identification | __powerpc __powerpc__ __powerpc64__ __POWERPC__ __ppc__ __ppc64__ __PPC__ __PPC64__ _ARCH_PPC _ARCH_PPC64 | Defined by GNU C |
Version | __ppc'V'__ | V = Version |
Identification | _M_PPC | Defined by Visual Studio |
Version | _M_PPC | ? |
Identification | _ARCH_PPC _ARCH_PPC64 | Defined by XL C/C++ |
Version | _ARCH_'V' | V = Version |
Version | __PPCGECKO__ | Gekko Defined by CodeWarrior |
Version | __PPCBROADWAY__ | Broadway Defined by CodeWarrior |
Version | _XENON | Xenon |
Identification | __ppc | Defined by Diab |
CPU | _M_PPC | Macro | XL Macro |
---|---|---|---|
PowerPC 440 | _ARCH_440 | ||
PowerPC 450 | _ARCH_450 | ||
PowerPC 601 | 601 | __ppc601__ | _ARCH_601 |
PowerPC 603 | 603 | __ppc603__ | _ARCH_603 |
PowerPC 604 | 604 | __ppc604__ | _ARCH_604 |
PowerPC 620 | 620 |
Type | Macro |
---|---|
Identification | pyr |
Type | Macro | Description |
---|---|---|
Identification | __THW_RS6000 | Defined by XL C/C++ |
Identification | _IBMR2 | |
Identification | _POWER | |
Identification | _ARCH_PWR _ARCH_PWR2 _ARCH_PWR3 _ARCH_PWR4 |
Type | Macro | Description |
---|---|---|
Identification | __sparc__ | Defined by GNU C |
Identification | __sparc | Defined by Sun Studio |
Version | __sparc_v8__ __sparc_v9__ | Defined by GNU C |
Version | __sparcv8 __sparcv9 | Defined by Sun Studio |
CPU | Sun Studio Macro | GNU C Macro |
---|---|---|
SPARC v8 (SuperSPARC) | __sparcv8 | __sparc_v8__ |
SPARC v9 (UltraSPARC) | __sparcv9 | __sparc_v9__ |
Type | Macro | Description |
---|---|---|
Identification | __sh__ | Defined by GNU C |
Version | __sh1__ __sh2__ __sh3__ __SH3__ __SH4__ __SH5__ |
Type | Macro | Description |
---|---|---|
Identification | __370__ __THW_370__ | Identifies System/370 Defined by XL C/C++ |
Identification | __s390__ | Identifies System/390 Defined by GNU C |
Identification | __s390x__ | Identifies z/Architecture Defined by GNU C |
Identification | __zarch__ | Identifies z/Architecture Defined by clang |
Identification | __SYSC_ZARCH__ | Identifies z/Architecture Defined by Systems/C |
Type | Macro | Description |
---|---|---|
Identification | _TMS320C2XX __TMS320C2000__ | C2000 series |
Identification | _TMS320C5X __TMS320C55X__ | C5000 series |
Identification | _TMS320C6X __TMS320C6X__ | C6000 series |
DSP | Macro |
---|---|
C28xx | _TMS320C28X |
C54x | _TMS320C5XX |
C55x | __TMS320C55X__ |
C6200 | _TMS320C6200 |
C6400 | _TMS320C6400 |
C6400+ | _TMS320C6400_PLUS |
C6600 | _TMS320C6600 |
C6700 | _TMS320C6700 |
C6700+ | _TMS320C6700_PLUS |
C6740 | _TMS320C6740 |
Type | Macro |
---|---|
Identification | __TMS470__ |
今天看老外写的文章提到?/span>C#国际标准…
什么,C#q有国际标准Q不会吧Q谷歌一下,果然如此Q?/span>06q就有了ISO标准…居然q能?/span>ISO官网下蝲到电子版?/span>
看来金钱是好东西啊Q有p佉K推磨道理在地球上哪里都好?/span>…
l箋hQ在MSDN上发C下面的文字?/span>
q接Q?/span>http://msdn.microsoft.com/en-us/netframework/aa569283
In June 2005, the General Assembly of the international standardization organization Ecma approved edition 3 of the C# Language and the Common Language Infrastructure (CLI) specifications, as updated Ecma-334 and Ecma-335, respectively (see press release). The updated technical report on the CLI, Ecma TR-84, and a new technical report on the CLI, Ecma TR-89, were also ratified.
In July 2005, Ecma submitted the Standards and TRs to ISO/IEC JTC 1 via the ISO Fast-Track process. The Standards were adopted in April 2006 as ISO/IEC 23270:2006 (C#), ISO/IEC 23270:2006 (CLI), ISO/IEC TR 23272:2006 (CLI, XML Libraries) and ISO ISO/IEC TR 25438:2006 (CLI, Common Generics).
In July 2006 the General Assembly of Ecma approved edition 4 of the Standards which correspond to the ISO 2006 versions.
The following official Ecma documents are available for C# and the CLI (TR-84, TR-89). These links are direct from Ecma:
| File name |
| Size (Bytes) |
| Content |
|
| 2 614 003 |
| C# Language Specification | |
|
| 3 219 107 |
| Common Language Infrastructure | |
|
| 754 982 |
| XML-based Library Specification | |
|
| 187 450 |
| Information Derived from Partition IV XML File | |
|
| 19 329 610 |
| XML Tool, Libraries in Microsoft© Word and PDF | |
|
| 589 400 |
| Common Generics Library | |
|
| 461 074 |
| Common Generics Library Reference Implementation |
Reference implementation for TR-89
Reference implementation for the Parallel API
The official ISO/IEC documents are available from the ISO/IEC Freely Available Standards page. These links are direct from that page:
| File name |
| Content |
|
| Information technology -- Programming languages -- C# | |
|
| Information technology -- Common Language Infrastructure (CLI) | |
| ISO/IEC TR 23272:2006 |
| Information technology -- Common Language Infrastructure (CLI) |
|
| Information technology -- Common Language Infrastructure (CLI) |
Work on the 5th edition of Ecma-335 CLI standard began in mid-2009. The TC49-TG3 task group is working on extending both the virtual machine and class libraries of the CLI specification. In addition, improvements are being made to clarify existing elements of the specification. Many of these improvements are the result of feedback received from outside the task group, for which the task group is grateful.
Posted below is a snapshot of the committee's work as of 27 March 2010.
The participants in TC49/TG3 are providing these working documents to the public for informational purposes only. The contents are subject to change as often as once a month. To participate in the standardization process, contact your organization's Ecma representative. If your company does not currently participate in Ecma and wishes to do so, please contact ECMA directly.
The following organizations and contributors are actively participating in the work of TC49/TG3:
Eiffel Software, Microsoft Corporation, Novell Corporation, Kahu Research, and Twin Roots.
Many of the organizations that are currently participating in the TC49/TG3 work have volunteered to mirror this site. The URLs for the mirror sites are:
- Eiffel Software
- Microsoft Corporation
- Novell Corporation
- Kahu Research
- Twin Roots
Available Documents (Documents current as of 27 March 2010)
The following working draft documents are available:
- CLI Partition I - Architecture (word/pdf zip)
- CLI Partition II - Metadata and File Format (word/pdf zip)
- CLI Partition III - CIL (word/pdf zip)
- CLI Partition IV - Library (word/pdf zip)
- CLI Partition V - Binary Formats (word/pdf zip)
- CLI Partition VI - Annexes (word/pdf zip)
- Class Library XML (xml zip)
- Class Library Detailed Specifications (word/pdf zip)
Members of the Standard committees and others have combined to produce annotated versions of the Standards. These are:
The following documents are versions of the Standards with Microsoft implementation-specific notes added. These notes provide extra information about Microsoft's Common Language Runtime (CLR) implementation of the CLI.
| File name |
| Size (Bytes) |
| Content |
|
| 815 983 |
| Common Language Infrastructure, Partition I: Concepts and Architecture | |
|
| 1 758 195 |
| Common Language Infrastructure, Partition II: Metadata Definition and Semantics | |
|
| 661 414 |
| Common Language Infrastructure, Partition III: CIL Instruction Set | |
|
|
|
| Common Language Infrastructure, Partition IV: Profiles and Libraries | |
|
|
|
| Common Language Infrastructure, Partition V: Binary Formats | |
|
|
|
| Common Language Infrastructure, Partition VI: Annexes |
Aside from bug fixes, major enhancements from previous editions include:
In August, 2000, Microsoft Corporation, Hewlett-Packard and Intel Corporation co-sponsored the submission of specifications for the Common Language Infrastructure (CLI) and C# programming language to the international standardization organization Ecma. As a result, Ecma formed two task groups (TG3 and TG2, respectively) within TC39, its technical committee responsible for programming languages and application development.
During the next year, the co-sponsor companies, in conjunction with other Ecma members and guests (including IBM, Fujitsu Software, Plum Hall, Monash University and ISE), refined these specifications into standards. In December, 2001, the Ecma General Assembly ratified the 1st edition of the C# and CLI standards as Ecma-334 and Ecma-335, respectively. A technical report on the CLI, Ecma TR-84, was also ratified.
In late December, 2001, Ecma submitted the standards and TR to ISO/IEC JTC 1 via the latter's Fast-Track process. The subsequent 6-month evaluation and comment period resulted in two NO votes (Japan and UK) on the draft standards, and one NO vote (Japan) on the draft TR. All comments resulting from this review were considered at a ballot resolution meeting held in October, 2002. The two NO votes on the standards were resolved, making acceptance unanimous. However, Japan did not change its NO vote on the draft TR (Japan would like to see a formatted/readable rendering of the CLI class library as part of the standard, not as a TR; this will be considered for a future edition).
The ISO/IEC standards and TR were published in April, 2003, and are known formally as ISO/IEC 23270 (C#), ISO/IEC 23271 (CLI) and ISO/IEC 23272 (CLI TR). Equivalent specifications were adopted as 2nd edition standards and TR by Ecma at its December, 2002, General Assembly.
To participate in the standardization process, contact your organization’s Ecma representative. If your company does not currently participate in Ecma and wishes to do so, please contact Ecma directly.
The following organizations have participated in the work of Ecma TC39/TG2 and TC39/TG3 and their contributions are gratefully acknowledged: Borland, Fujitsu, Hewlett-Packard, Intel Corporation, International Business Machines, ISE, IT University Copenhagen, JSL (UK), Kahu Research (New Zealand), Microsoft Corporation, Monash University, Netscape, Novell Corporation, OpenWave, Plum Hall, Sun Microsystems.
Many of the organizations that have participated in the TC39/TG2 and TC39/TG3 work have volunteered to mirror this site. The links for the mirror sites are:
转脓Q已l记不清出处Q抱歉?/p>
1、儿Ӟ男孩家很穷Q吃饭时Q饭常常不够吃,母亲把自己里的饭分给孩子吃。母亲说Q孩子们Q快吃吧Q我不饿Q?#8212;—母亲撒的W一个谎
2、男孩长w体的时候,勤劳的母亲常用周日休息时间去厉K农村x里捞些鱼来给孩子们补钙。鱼 很好吃,鱼汤也很鲜。孩子们吃鱼的时候,母亲在一旁啃鱼骨_用舌头舔鱼骨头上的肉渍。男孩心|把自己里的鱼夹到母亲里Q请母亲吃鱼。母亲不 吃,母亲又用{子把鱼夹回男孩的碗里。母亲说Q孩子,快吃吧,我不爱吃|——母亲撒的W二个谎
3、上初中了,Z~够男孩和哥姐的学费Q当~n工的母亲去居委会领些火柴盒拿回家来Q晚?p了挣点分分p点家用。有个冬天,男孩半夜醒来Q看到母亲还w着w子在a灯下p火柴盒。男孩说Q母Ԍ睡了吧,明早您还要上班呢。母亲笑W,_孩子Q?快睡吧,我不囎ͼ——母亲撒的W三个谎
4、高考那q_母亲请了假天天站在考点门口为参加高考的男孩助阵。时逢盛夏,烈日当头Q固执的 母亲在烈日下一站就是几个小时。考试l束的铃声响了,母亲q上去递过一杯用|头瓶好的茶叮嘱孩子喝了Q茶亦浓Q情更浓。望着母亲q裂的嘴唇和满头的汗 珠,男孩手中的|头瓶反递过去请母亲喝。母亲说Q孩子,快喝吧,我不_——母亲撒的四个?
5、父亲病逝之后,母亲又当爹又当娘Q靠着自己在缝U社里那点微薄收入含辛茹苦拉扯着几个?子,供他们念书,日子q得苦不堪言。胡同\口电U杆下修表的李叔叔知道后Q大事小事就扑ֲq来打个帮手Q搬搬煤Q挑挑水Q送些q来帮补男孩的安。h?草木Q孰能无情。左d舍对此看在眼里,记在心里Q都劝母亲再嫁,何必苦了自己。然而母亲多q来却守w如玉,始终不嫁Q别人再劝,母亲也断然不听,母亲 _我不爱!——撒的五个?
6、男孩和她的哥姐大学毕业参加工作后,下了岗的母亲在附近农N市场摆了个小摊维持生zRn在外地工作的孩子们知道后常常寄钱回来补贴母Ԍ母亲坚决不要Qƈ钱退了回厅R母亲说Q我有钱Q?#8212;—撒的六个?
7、男孩留校Q教两q_后又考取了美国一所名牌大学的博士生Q毕业后留在国一家科研机构工作,待遇相当丰厚Q条件好了,w在异国的男孩想把母亲接来n享清却被老h回绝了。母亲说Q我不习惯!——撒的七个?
8、晚q_母亲患了胃癌Q住q了医院Q远在大西洋彼岸的男孩乘飞机赶回来时Q术后的母亲已是奄奄一息了。母亲老了Q望着被病折得dzL的母Ԍ男孩悲痛Ʋ绝Q潸然泪下。母亲却_孩子Q别哭,我不疹{?#8212;—撒的最后一个谎
有时候用Cq算。需要快速找C个整数的二进制第一?/span>1?/span>0在哪个位(下标)Q例如:十进制数100的二q制?/span>1100100Q那么它的第一?/span>1在下?/span> ?/span>2的位|?/span>(bsf, bit scan forward)?/span>6的位|?/span>(bsr, bit scan in reverse order)Q由于只用于存储一个状态,至于?/span>bsfq是bsr则无所谓?/span>
解决q个问题的第一个想法就是用内联汇编的做法,使用特别?/span>CPU指oLQ但汇编的可UL性比较差Q不同的CPU型号使用的指令可能不一P执行速度也不一栗?/span>
假设找一?/span>64位无W号整数二进制的W一?/span>1Q用bsf, AT& T汇编(gcc汇编)可以q样做:
1 // bit scan forward for 64 bit integral number
2 /* ============================================ */
3 inline int bsf_asm (uint64_t w)
4 {
5 int x1, x2;
6 asm ("bsf %0,%0\n" "jnz 1f\n" "bsf %1,%0\n" "jz 1f\n" "addl $32,%0\n"
7 "1:": "=&q" (x1), "=&q" (x2):"1" ((int) (w >> 32)),
8 "0" ((int) w));
9 return x1;
10 }
如果?/span>C来实现的话,那就有点ȝ了,在此不讲复杂的数学原理,仅仅l出代码?/span>
1 // bit scan forward for 64 bit integral number
2 /* ============================================ */
3 inline int bsf_folded (uint64_t bb)
4 {
5 static const int lsb_64_table[64] =
6 {
7 63, 30, 3, 32, 59, 14, 11, 33,
8 60, 24, 50, 9, 55, 19, 21, 34,
9 61, 29, 2, 53, 51, 23, 41, 18,
10 56, 28, 1, 43, 46, 27, 0, 35,
11 62, 31, 58, 4, 5, 49, 54, 6,
12 15, 52, 12, 40, 7, 42, 45, 16,
13 25, 57, 48, 13, 10, 39, 8, 44,
14 20, 47, 38, 22, 17, 37, 36, 26
15 };
16 unsigned int folded;
17 bb ^= bb - 1;
18 folded = (int) bb ^ (bb >> 32);
19 return lsb_64_table[folded * 0x78291ACF >> 26];
20 }
如果想从后往前搜索一个整数的二进制第一?/span>1的下标,用汇~可以这样做?/span>
1 // bit scan in reverse order for 64 bit integral number
2 /* ============================================ */
3 inline int bsr_asm (uint64_t w)
4 {
5 int x1, x2;
6 asm ("bsr %1,%0\n" "jnz 1f\n" "bsr %0,%0\n" "subl $32,%0\n"
7 "1: addl $32,%0\n": "=&q" (x1), "=&q" (x2):"1" ((int) (w >> 32)),
8 "0" ((int) w));
9 return x1;
10 }
如果?/span>C来实现的话,也比较简单,?/span>divide and conquer 的原理就不会太慢?/span>
1 // a logn (n == 32)algorithm for bit scan in reverse order
2 /* ============================================ */
3 inline int bsr32(uint32_t bb)
4 {
5 static const char msb_256_table[256] =
6 {
7 0, 0, 1, 1, 2, 2, 2, 2, 3, 3, 3, 3, 3, 3, 3, 3,
8 4, 4, 4, 4, 4, 4, 4, 4,4, 4, 4, 4,4, 4, 4, 4,
9 5, 5, 5, 5, 5, 5, 5, 5, 5, 5, 5, 5, 5, 5, 5, 5, 5, 5, 5, 5, 5, 5, 5, 5, 5, 5, 5, 5, 5, 5, 5, 5,
10 6, 6, 6, 6, 6, 6, 6, 6, 6, 6, 6, 6, 6, 6, 6, 6, 6, 6, 6, 6, 6, 6, 6, 6, 6, 6, 6, 6, 6, 6, 6, 6,
11 6, 6, 6, 6, 6, 6, 6, 6, 6, 6, 6, 6, 6, 6, 6, 6, 6, 6, 6, 6, 6, 6, 6, 6, 6, 6, 6, 6, 6, 6, 6, 6,
12 7, 7, 7, 7, 7, 7, 7, 7, 7, 7, 7, 7, 7, 7, 7, 7, 7, 7, 7, 7, 7, 7, 7, 7, 7, 7, 7, 7, 7, 7, 7, 7,
13 7, 7, 7, 7, 7, 7, 7, 7, 7, 7, 7, 7, 7, 7, 7, 7, 7, 7, 7, 7, 7, 7, 7, 7, 7, 7, 7, 7, 7, 7, 7, 7,
14 7, 7, 7, 7, 7, 7, 7, 7, 7, 7, 7, 7, 7, 7, 7, 7, 7, 7, 7, 7, 7, 7, 7, 7, 7, 7, 7, 7, 7, 7, 7, 7,
15 7, 7, 7, 7, 7, 7, 7, 7, 7, 7, 7, 7, 7, 7, 7, 7, 7, 7, 7, 7, 7, 7, 7, 7, 7, 7, 7, 7, 7, 7, 7, 7,
16 };
17 int result = 0;
18
19 if (bb > 0xFFFF)
20 {
21 bb >>= 16;
22 result += 16;
23 }
24 if (bb > 0xFF)
25 {
26 bb >>= 8;
27 result += 8;
28 }
29
30 return (result + msb_256_table[bb]);
31 }
32
33 /* ============================================ */
34 inline int bsr_in_C(uint64_t bb)
35 {
36 const uint32_t hb = bb >> 32;
37 return hb ? 32 + bsr32((uint32_t)hb) : bsr32((uint32_t)bb);
38
39 }
40
下面q个g也可以,p|时返?/span>-1023Q至于速度快慢p看编译器的嗜好了?/span>
1 // bit scan in reverse order for 64 bit integral number
2 /* ============================================ */
3 inline int bsr_double (uint64_t bb)
4 {
5 union
6 {
7 double d;
8 struct
9 {
10 unsigned int mantissal : 32;
11 unsigned int mantissah : 20;
12 unsigned int exponent : 11;
13 unsigned int sign : 1;
14 };
15 } ud;
16 ud.d = (double)(bb & ~(bb >> 32));
17 return ud.exponent - 1023;
18 }
19
2007q初Q刚刚卸ȝ联合国秘书长安南Q在德克萨斯州的一个庄园里举行了一场慈善晚_旨在为非z困儿童募捐。应邀参加晚宴的都是富商和C会名流。在晚宴要开始的时候,一位老妇人领着一个小奛_来到了庄园的入口处,女孩手里捧着一个看上去很精致的L?/span>
守在庄园入口处的保安安东拦住了q一老一?#8220;Ƣ迎你们Q请出示hQ谢谢?#8221;?/span>
“hQ对不vQ我们没有接到邀P是她要来Q我陪她来的?#8221;老妇人抚摸着女孩的头?/span>
“很抱歉,除了工作人员Q没有请柬的Z能进厅R?#8221;安东D?/span>
“Z么?q里不是举行慈善晚宴吗?我们是来表示我们的心意的Q难道不可以吗?”老妇人的表情很严肃,“可爱的小露西Q从电视上知道了q里要ؓ非洲的孩子们举行慈善zdQ她很想为那些可怜的孩子做点事,军_把自己储q里所有的钱都拿出来,我可以不q去Q真的不能让她进dQ?#8221;
“是的Q这里将要D行一场慈善晚_应邀参加的都是很重要的h士,他们ؓ非洲的孩子慷慨解囊。很高兴你们带着爱心来到q里Q但是,我想q场合不适合你们q去?#8221;安东D释说?/span>
“叔叔Q慈善的不是钱,是心Q对吗?”一直没有说话的女孩问安东|她的话让安东愣住了?#8220;我知道收到邀L人有很多钱,他们会拿出很多钱Q我没有那么多,但这是我所有的钱啊Q如果我真的不能q去Q请帮我把这个带q去吧!”女孩露西说完,手中的储钱|递给安东{?/span>
安东g知道是接q是不接Q正在他不知所措的时候,H然有h_“不用了,孩子Q你说得对,慈善的不是钱Q是心,你可以进去,所有有爱心的h都可以进厅R?#8221;说话的是一位老头Q他面带微笑Q站在小露西w旁。他wn和小露西交谈了几句,然后直nhQ拿Z份请柬递给安东|“我可以带她进dQ?#8221;
安东接q请柬,打开一看,忙向老头敬了个礼Q?#8220;当然可以了,沃u·巴菲特先生?#8221;
当天慈善晚宴的主角不是倡议者的安南Q不是捐?00万美元的巴菲特,也不是捐?00万美元的比尔·盖茨Q而是仅仅捐出30元?5分的小露西Q她赢得了最多最热烈的掌声。而晚宴的主题标语也变成了q样一句话“慈善的不是钱Q是心?#8221;W二天,国各大媒体UL以这句话作ؓ标题Q报道了q次慈善晚宴。看到报道后Q许多普普通通的国人纷UC为非z那些IL孩子捐赠?/span>
2006q的职场出奇的冷清,相比前几q_历的数量和质量都大ؓ不如Q很隑־扑ֈ三年工作l验以上的hQ有一?/span> 不是特别W,是特别怪。就是么Q干得好谁没事换工作啊!Simon是一家外企Y件公司的ȝ理,最q给q个问题愁坏了。项目一个接一个的接下来,人手?/span> 来越紧张。虽?/span>Simon是个极限~程的粉丝,但也不得不批准了一份又一份的加班甌?/span>HRl理把这个问题归l到房h上,他的妙论?/span>“怕失业了q不上房 ƾ,不敢x”?/span>
q天Q?/span>K目l长Allenl于忍不住了Q带了一个只有一q工作经验的伙子要Simon面试Q?/span>“很聪明!l验了炏V?/span>”
Simon׃q毛,_“你不知道q个职位最低要求是三年工作l验吗?”
Allen_“q已l是三个月里通过技术考试中最好的一个了Q老大Q试试吧?/span>”Allen?/span>Simon多年的哥们,比较随便?/span>
抵到面子上来Q?/span>Simon只好?/span>Allen把小伙子带进来?/span>
Simon的面试通常是三步曲Q?/span>
问题一Q你能说说毕业后的主要工作经历吗Q?/span>
问题二:再说说你在公司的CQ?/span>
问题三:你的发展目标是什么?{回{后Q比如说架构师,他就跟着问:惌一下你当架构师的一天,说给我听听?
伙子回{第一问题很快很清楚,一q工作当然没什么东ѝ?/span>Simon觉得伙子挺聪明。所以在伙子回{了W二个问题后Q问了一个发散性的问题Q?/span>“你刚才说你在公司里处于中{水qI那比你差的hZ么会比你差呢Q?/span>”
q个问题是个陷阱?/span>
伙子冒冒失失回{说Q?/span>“我觉得他们每天工作是为工作而工作,工作没有责Q感?/span>”
Simon点点头说Q?/span>“是吗Q那真是p糕的员工。那你刚好比p糕的员工好一点了Q?/span>”
伙子的怸下子U了Q?/span>“我不是这个意?/span>……”
“好了Q那你说说比你好的hZ么比你强Q?/span>”
“我觉得他非常努力Q工作很多年了还在学习各U构Ӟ水^很高?/span>”于是Simon问那最后一个问题。果Ӟ伙子回{的是要成ؓ架构师。大?/span>70Q的人想成ؓ架构师。但是架构师是什么呢Q?/span>
Simon问道Q?/span>“那你Z么要成ؓ架构师呢Q?/span>”
伙子一愣,大概q没有hq么|疑q他?/span>“q纪大了Q不能老写E序吧?/span>”q个回答Q让Simon惌v关于他对什么是老的定义Q当你希望做q轻人做的事情时Q你pq轻Q如果你希望做老年人做的事情,你就老了。这和你出生了多长时间是没有关系的?/span>
Simon接着问:“好吧Q那你说说你成ؓ架构师以后,每天都会做什么?”
伙子说Q?/span>“我还没想q,不过Q我惛_该主要是需求分析,设计构架?/span>……”q大概是现在q轻人的通病Q年Mh很容易追逐一些自׃不清楚的目标?/span>
Simon问:“那设计构架具体都做些什么呢Q?/span>”
伙子这ơ的回答是:“比如Q选择E序框架Q决定用Spring?/span>Struts{等?/span>”
“哦,那我问你Q你怎么说服别h是用Springq是Struts呢?”
“如果我有l验Q我会知道哪个更?/span>……”
“是吗Q但关于Spring?/span>Struts的知识Q谁都可以很容易得到。如果别Z同意你的Q你怎么说服他?如果同意你的Q那你不q是作出了和别h一L认识Q别人又凭什么认可你呢?”
伙子没惌架构师日子里q有一个说服h的工作,_“我是架构师,我应该有权力做决定吧Q?/span>”
Simon惌v权力的三U层ơ,W一层,dQ第二层Q专业;W三层,品d?/span>
Simon问:“如果在一个成熟的软g企业里没有你所惌的架构师呢?或者说Q架构师q种职业已经M或消׃呢?你会怎么定位你的职业Q?/span>”
伙子显得很震惊?/span>
SimonM一个系l构Ӟ然后又给伙子看了一D代码?/span>
“那一个更难懂Q?/span>”Simon问?/span>
伙子指着代码_“代码难懂?/span>”
Simon的解释是Q?/span>“q就是ؓ什么实际上所谓的架构师不存在的原因。一个更单的东西怎么会更有h值呢Q每个h都能够画U构架图Q但不是每个人都能写出好的代码?/span>”
送走了小伙子Q?/span>Simon有点隑֏。他有点喜欢q个伙子,但是Q这又是一个被愚蠢的教育和误h子弟的技术杂志污染的家伙?/span>Simon在自qW记本中加了一句话Q中国程序员最愚蠢的认识之三:我想当架构师。前面两个赫然是Q?/span>
35岁后写不动程序了Q?/span>
我只要做JavaQ?/span>CQ+Q;
试名称 |
~译?/span>/解译?/span> |
~译/q行选项 |
VC++ |
Visual C++ 2008 (32-bit) |
/Ox /Ob2 /Oi /Ot /GL /FD /MD /GS- /Gy /arch:SSE /fp:fast |
VC++_OpenMP |
Visual C++ 2008 (32-bit) |
/Ox /Ob2 /Oi /Ot /GL /FD /MD /GS- /Gy /arch:SSE /fp:fast /openmp |
IC++ |
Intel C++ Compiler (32-bit) |
/Ox /Og /Ob2 /Oi /Ot /Qipo /GA /MD /GS- /Gy /arch:SSE2 /fp:fast /Zi /QxHost |
IC++_OpenMP |
Intel C++ Compiler (32-bit) |
/Ox /Og /Ob2 /Oi /Ot /Qipo /GA /MD /GS- /Gy /arch:SSE2 /fp:fast /Zi /QxHost /Qopenmp |
GCC |
GCC 4.3.4 in Cygwin (32-bit) |
-O3 -march=native -ffast-math |
GCC_OpenMP |
GCC 4.3.4 in Cygwin (32-bit) |
-O3 -march=native -ffast-math -fopenmp |
C++/CLI |
Visual C++ 2008 (32-bit), .Net Framework 3.5 |
/Ox /Ob2 /Oi /Ot /GL /FD /MD /GS- /fp:fast /Zi /clr /TP |
C++/CLI_OpenMP |
Visual C++ 2008 (32-bit), .Net Framework 3.5 |
/Ox /Ob2 /Oi /Ot /GL /FD /MD /GS- /fp:fast /Zi /clr /TP /openmp |
C# |
Visual C# 2008 (32-bit), .Net Framework 3.5 |
|
*C#_outref |
Visual C# 2008 (32-bit), .Net Framework 3.5 |
|
F# |
F# 2.0 (32-bit), .Net Framework 3.5 |
|
Java |
Java SE 1.6.0_17 |
-server |
JsChrome |
Chrome 5.0.375.86 |
|
JsFirefox |
Firefox 3.6 |
|
LuaJIT |
LuaJIT 2.0.0-beta4 (32-bit) |
|
Lua |
LuaJIT (32-bit) |
-joff |
Python |
Python 3.1.2 (32-bit) |
|
*IronPython |
IronPython 2.6 for .Net 4 |
|
*Jython |
Jython 2.5.1 |
|
Ruby |
Ruby 1.9.1p378 |
|
渲染的解像度?/span>256x256Q每象素?/span>100ơ采栗?/span>
下表中预讄相对旉以最快的单线E测?/span>(IC++)作基准,用鼠标按列可改变基准。由?/span>Rubyq行旉太长Q只每象素作4ơ采P把时间乘?/span>25。另 外,因ؓ各测试的渲染旉相差很远Q所以用了两个棒形图LC数据,分别昄旉于4000U和于60U的试(Ruby?/span>4000U以外,不予?/span> C?/span>)?/span>
Test |
Time(sec) |
Relative time |
IC++_OpenMP |
2.861 |
0.19x |
VC++_OpenMP |
3.140 |
0.21x |
GCC_OpenMP |
3.359 |
0.23x |
C++/CLI_OpenMP |
5.147 |
0.35x |
IC++ |
14.761 |
1.00x |
VC++ |
17.632 |
1.19x |
GCC |
19.500 |
1.32x |
C++/CLI |
27.634 |
1.87x |
Java |
30.527 |
2.07x |
C#_outref |
44.220 |
3.00x |
F# |
47.172 |
3.20x |
C# |
48.194 |
3.26x |
JsChrome |
237.880 |
16.12x |
LuaJIT |
829.777 |
56.21x |
Lua |
1,227.656 |
83.17x |
IronPython |
2,921.573 |
197.93x |
JsFirefox |
3,588.778 |
243.13x |
Python |
3,920.556 |
265.60x |
Jython |
6,211.550 |
420.81x |
Ruby |
77,859.653 |
5,274.69x |
静态语a和动态语a在此试下的性能不在同一数量U。先比较静态语a?/span>
C++?/span>.Net的测试结果和上一博文相若,?/span>C#?/span>F#无显著区别。但是,C++/CLI虽然同样产生ILQ于括管?/span>.Netq_上执行,其渲染时?/span> 却只?/span>C#/F#?/span>55%左右。ؓ什么呢Q?/span>ildasmd汇编C++/CLI?/span>C#的可执行文g后,可以发现Q程序的热点函数 Sphere.Intersect()在两个版本中Q?/span>C++/CLI版本的代码大?/span>(code size)?/span>201字节Q?/span> C#则ؓ125字节Q?/span> C++/CLI版本在编译时Q已把函数内所?/span>VeccȝҎ调用全部内联Q?/span>C#版本则?/span>callvirt调用Vec的方法。估?/span>JIT没有把这函数q?/span> 行内联,做成q个性能差异。另外,C++/CLI版本使用了值类型,q用指?/span>(代码中ؓ引用)托管代码(C++/CLI)的渲染时_仅ؓ原生非括代?/span>(IC++)?/span>1.91倍,个h觉得.Net?/span>JIT已经非常不错?/span>
另一斚wQ?/span>Java的性能表现非常H出Q只?/span>C++/CLIE慢一点,Java版本的渲染时间ؓC#/F#?/span>65%左右。以前一直认为,C#不少设计会其性能高于JavaQ例?/span>C#的方法预设ؓ非虚Q?/span>Java则预设ؓ虚;又例?/span>C#支持struct作值类?/span>(value type)Q?/span>Java则只?/span>class引用cd(reference type)Q后者必M?/span>GC。但是,q个试昄Q?/span>Java VM应该?/span>JIT中做了大量优化,估计也应用了内联Q才能其性能DC++/CLI?/span>
U?/span>C++斚wQ?/span>Intel C++~译器最快,Visual C++慢一点点(1.19x)Q?/span>GCC再慢一点点(1.32x)。这l果W合本h预期?/span> Intel C++?/span>OpenMP版本和单U程比较Q达5.16加速比(speedup)Q对?/span>4?/span>Hyper Threading来说是不错的结果。读者若有兴,也可以自行测?/span>C# 4.0的ƈ行新Ҏ?/span>
首先Q要说一句,Google太强了,难以惛_JsChome的渲染时间仅?/span>IC++?/span>16.12倍,C#?/span>4.94倍?/span>
以下比较各动态语a的相Ҏ_?/span>JsChrome为基准?/span> Chrome?/span>V8 JavaScript引擎(1.00x)大幅抛离Firefox?/span>SpiderMonkey引擎(15.09x)。?/span>LuaJIT(3.49x)?/span>Lua(5.16x)则排W二和第三名?/span> Lua?/span>JIT版本是没?/span>JIT?/span>68%Qƈ没有惛_中的快,但是也比Python(16.48x)快得多。曾听说q?/span>Ruby有效能问题,没想到问题竟然如此严?/span>(327.31x)Q其渲染旉差不多是Python?/span>20?
B?/span>
即二叉搜索树Q?/span>
1.所有非叶子l点臛_拥有两个儿子Q?/span>Left?/span>RightQ;
2.所有结点存储一个关键字Q?/span>
3.非叶子结点的左指针指向小于其关键字的子树Q右指针指向大于其关键字的子树;
如:
B树的搜烦Q从根结点开始,如果查询的关键字与结点的关键字相{,那么命中;否则Q如果查询关键字比结点关键字,p入左儿子Q如果比l点关键字大Q就q入叛_子;如果左儿子或叛_子的指针为空Q则报告找不到相应的关键字;
如果B树的所有非叶子l点的左叛_树的l点数目均保持差不多Q^衡)Q那?/span>B树的搜烦性能D二分查找Q但它比q箋内存I间的二分查扄优点是,改变B树结构(插入与删除结点)不需要移动大D늚内存数据Q甚至通常是常数开销Q?/span>
?/span>B树在l过多次插入与删除后Q有可能D不同的结构:
双也是一?/span>B树,但它的搜索性能已经是线性的了;同样的关键字集合有可能导致不同的树结构烦引;所以,使用B树还要考虑可能让B树保持左囄l构Q和避免叛_的结构,也就是所谓的“q”问题Q?/span>
实际使用?/span>B树都是在?/span>B树的基础上加上^衡算法,?#8220;q二叉?#8221;Q如何保?/span>B树结点分布均匀的^衡算法是q二叉树的关键Q^衡算法是一U在B树中插入和删除结点的{略Q?/span>
B-?/span>
是一U多路搜索树Qƈ不是二叉的)Q?/span>
1.定义L非叶子结Ҏ多只?/span>M个儿子;?/span>M>2Q?/span>
2.根结点的儿子Cؓ[2, M]Q?/span>
3.除根l点以外的非叶子l点的儿子数?/span>[M/2, M]Q?/span>
4.每个l点存放臛_M/2-1Q取上整Q和臛_M-1个关键字Q(臛_2个关键字Q?/span>
5.非叶子结点的关键字个?/span>=指向儿子的指针个?/span>-1Q?/span>
6.非叶子结点的关键字:K[1], K[2], …, K[M-1]Q且K[i] < K[i+1]Q?/span>
7.非叶子结点的指针Q?/span>P[1], P[2], …, P[M]Q其?/span>P[1]指向关键字小?/span>K[1]的子树,P[M]指向关键字大?/span>K[M-1]的子树,其它P[i]指向关键字属?/span>(K[i-1], K[i])的子树;
8.所有叶子结点位于同一层;
如:Q?/span>M=3Q?/span>
B-树的搜烦Q从根结点开始,对结点内的关键字Q有序)序列q行二分查找Q如果命中则l束Q否则进入查询关键字所属范围的儿子l点Q重复,直到所对应的儿子指针ؓI,或已l是叶子l点Q?/span>
B-树的Ҏ:
1.关键字集合分布在整颗树中Q?/span>
2.M一个关键字出现且只出现在一个结点中Q?/span>
3.搜烦有可能在非叶子结点结束;
4.其搜索性能{h于在关键字全集内做一ơ二分查找;
5.自动层次控制Q?/span>
׃限制了除根结点以外的非叶子结点,臛_含有M/2个儿子,保了结点的臛_利用率,其最底搜索性能为:
其中Q?/span>M定的非叶子结Ҏ多子树个敎ͼN为关键字LQ?/span>
所?/span>B-树的性能L{h于二分查找(?/span>M值无养IQ也没?/span>B树^衡的问题Q?/span>
׃M/2的限Ӟ在插入结ҎQ如果结点已满,需要将l点分裂Z个各?/span>M/2的结点;删除l点Ӟ需两个不?/span>M/2的兄弟结点合qӞ
B+?/span>
B+树是B-树的变体Q也是一U多路搜索树Q?/span>
1.其定义基本与B-树同Q除了:
2.非叶子结点的子树指针与关键字个数相同Q?/span>
3.非叶子结点的子树指针P[i]Q指向关键字值属?/span>[K[i], K[i+1])的子树(B-树是开区间Q;
5.为所有叶子结点增加一个链指针Q?/span>
6.所有关键字都在叶子l点出现Q?/span>
如:Q?/span>M=3Q?/span>
B+的搜索与B-树也基本相同Q区别是B+树只有达到叶子结Ҏ命中Q?/span>B-树可以在非叶子结点命中)Q其性能也等价于在关键字全集做一ơ二分查找;
B+的特性:
1.所有关键字都出现在叶子l点的链表中Q稠密烦引)Q且链表中的关键字恰好是有序的;
2.不可能在非叶子结点命中;
3.非叶子结点相当于是叶子结点的索引Q稀疏烦引)Q叶子结点相当于是存储(关键字)数据的数据层Q?/span>
4.更适合文g索引pȝQ?/span>
B*?/span>
?/span>B+树的变体Q在B+树的非根和非叶子l点再增加指向兄弟的指针Q?/span>
B*树定义了非叶子结点关键字个数臛_?/span>(2/3)*MQ即块的最低用率?/span>2/3Q代?/span>B+树的1/2Q;
B+树的分裂Q当一个结ҎӞ分配一个新的结点,q将原结点中1/2的数据复制到新结点,最后在父结点中增加新结点的指针Q?/span>B+树的分裂只媄响原l点和父l点Q而不会媄响兄弟结点,所以它不需要指向兄弟的指针Q?/span>
B*树的分裂Q当一个结ҎӞ如果它的下一个兄弟结Ҏ满,那么一部分数据Ud兄弟l点中,再在原结Ҏ入关键字Q最后修改父l点中兄弟结点的关键字(因ؓ兄弟l点的关键字范围改变了)Q如果兄弟也满了Q则在原l点与兄弟结点之间增加新l点Qƈ各复?/span>1/3的数据到新结点,最后在父结点增加新l点的指针;
所以,B*树分配新l点的概率比B+树要低,I间使用率更高;
结
B树:二叉树,每个l点只存储一个关键字Q等于则命中Q小于走左结点,大于走右l点Q?/span>
B-树:多\搜烦树,每个l点存储M/2?/span>M个关键字Q非叶子l点存储指向关键字范围的子结点;
所有关键字在整颗树中出玎ͼ且只出现一ơ,非叶子结点可以命中;
B+树:?/span>B-树基上,为叶子结点增加链表指针,所有关键字都在叶子l点中出玎ͼ非叶子结点作为叶子结点的索引Q?/span>B+树L到叶子结Ҏ命中Q?/span>
B*树:?/span>B+树基上,为非叶子l点也增加链表指针,结点的最低利用率?/span>1/2提高?/span>2/3?/span>
转自: http://blog.csdn.net/manesking/archive/2007/02/09/1505979.aspx