朱丽安娜科普克(出生于1954年10月10日)，婚后名字朱丽安娜迪拉，是一个德国-秘鲁哺乳动物学家。她是1971年兰萨508航班空难的唯一幸存者，空难发生后独自一人在亚马逊热带雨林生活了11天。他从3000米(9843英尺)坠落，落地时仍然被安全带捆在座椅上。

事前

朱丽安娜于1954年出生于秘鲁利马，父母都是在利马自然历史博物馆工作的德国人。她是生物学家汉斯威廉科普克和鸟类学家玛丽亚科普克的唯一孩子。在朱丽安娜14岁时，其父母带她去亚马逊雨林建造研究基地--潘古那。在这里她成了一个“丛林孩子”，学了野外生存技能。教育当局不同意这样做，要求朱莉安娜回到利马亚历山大冯洪堡德意志学校参加考试。她于1971年12月23日在此校毕业。

空难

朱丽安娜科普克在经历磨难上有双重生存故事可供讲述。在1971年圣诞节前夕，朱丽安娜搭乘了兰萨508航班。那时她刚从高中毕业，她的母亲玛丽亚本打算在1971年12月19-20日带着女儿去潘古那，但是朱丽安娜希望能在12月23日去利马参加毕业典礼。玛丽亚同意，打算圣诞节前夕再飞往潘古那，可是除了里尼思君特欧航空(兰萨)还有空余其余所有航班的席位均已售罄。尽管丈夫汉斯威廉强烈要求妻子不要乘坐那家航空公司的航班，因为该航空公司早已臭名昭著，但最终她们还是预定了机票。飞机起飞不久遭遇闪电，在空中开始解体并一头冲向地面。朱丽安娜发现自己一直被捆在座椅上，下落将近2英里最终落入秘鲁热带雨林。

在朱丽安娜科普克的此次事件上，专家指出由于在下降中她被安放到座椅上才导致她活了下来，只是断了锁骨而已。她是该航班的唯一幸存者，顺着溪流在雨林里生活了11天。

在她醒过来后丛林里的昆虫不再叮咬她，可是蛆已经感染了她的胳膊，9天后，她找到了一处露营地。在此，她给自己进行了初级治疗，例如用汽油浇到蛆感染的部位。蛆害怕汽油就离开了伤口。几个小时候后，运木工人发现了她，给与基本医疗并把她带到更宜居的区域，然后她被空运到医院。

伤口恢复后，朱丽安娜帮助搜救队定位失事地点和搜救死难者尸体。她妈妈的尸体于1972年1月12日被发现。朱丽安娜回到德国后伤口完全恢复了正常。跟父母类似，朱丽安娜获得生物学学位后返回秘鲁继续深入研究蝙蝠。她的双重生存故事成了书和电影的主体，其中包括了她的自传和他传，“当我从天而降”，以及导演沃纳赫尔佐格的纪录片“翅膀上的希望”。他(沃纳赫尔佐格)在1971年也预定了她(朱丽安娜)的那次航班，飞机起飞前最后一分钟改变计划，从而躲过一劫。

事后

朱丽安娜的侥幸存活成了各种瞎猜推断的主题。"很明显她被安全带捆在座椅上有了某种程度的盾牌和缓冲，而且理论上外围整排的座椅，就是朱丽安娜两边的那些，起到了降落伞的作用，减缓了她下落的速度..."。“风暴漂移以及落地点厚厚的枝叶可以进一步降低里冲击力...”。

朱丽安娜回到德国彻底康复过来，走了父母一样的路，在基尔大学学习生物，1980年毕业。在慕尼黑麦克西米兰大学获得博士学位后返回到秘鲁展开哺乳动物研究，专注于蝙蝠，在1987年发表论文，“秘鲁热带雨林里一个蝙蝠生物王国的研究”。1989年朱莉安娜科普克和一个专注于研究寄生黄蜂的昆虫学家艾力克迪拉结婚。2000年朱丽安娜接管了潘古那当上了主任，父亲去世了。

现在朱丽安娜迪拉在慕尼黑巴伐利亚动物学蒐藏研究中心当管理员。她的自传和他传”当我从天而降”(德语: Als ich vom Himmel fie)于2011年3月10日由派珀林格出版，为此她获得了2011柯琳文学奖。2019年秘鲁政府授予她高级军官的杰出服务奖。

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.

Architectures

Please send updates/corrections to predef-contribute.

Alpha

Example

AMD64

Notice that x32 can be detected by checking if the CPU uses the ILP32 data model.

ARM

Example

ARM64

Blackfin

Convex

Example

Epiphany

HP/PA RISC

See also OpenPA.net.

Example

Intel x86

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.

Example

Intel Itanium (IA-64)

Example

Motorola 68k

Example

MIPS

Example

PowerPC

Example

Pyramid 9810

RS/6000

SPARC

Example

SuperH

SystemZ

TMS320

Example

TMS470

今天看老外写的文章提到了C#国际标准…

什么，C#还有国际标准？不会吧？谷歌一下，果然如此，06年就有了ISO标准…居然还能从ISO官网下载到电子版。

看来金钱就是好东西啊，有钱能使鬼推磨道理在地球上哪里都好用…

继续谷歌，在MSDN上发现了下面的文字。

连接：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.

Latest Standards

The following official Ecma documents are available for C# and the CLI (TR-84, TR-89). These links are direct from Ecma:

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:

Current Working Draft

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)

Annotated Standards

Members of the Standard committees and others have combined to produce annotated versions of the Standards. These are:

• The Common Language Infrastructure Annotated Standard, James S. Miller & Susann Ragsdale, Addison-Wesley, 2004, ISBN 0-321-15493-2 (based on Edition 2 of Ecma-335)
• C# Annotated Standard, Jon Jagger, Nigel Perry & Peter Sestoft, Morgan Kaufmann, 2007, ISBN 978-0-12-372511-0 (based on Edition 4 of Ecma-334)

Microsoft Implementation Specific Versions

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.

The Ecma 4^th and ISO 2^nd Editions

Aside from bug fixes, major enhancements from previous editions include:

CLI

• First-class support for generics at the runtime and class library level
• An API to help developers begin multithreaded and parallel programming
• Enhancements to the Common Intermediate Language (CIL) and Common Language Specification (CLS)
• An interchangeable debug format

C#

• First-class language support for generics
• Anonymous methods
• Iterators
• Nullable Types

Previous Editions Background

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 1^st 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 2^nd edition standards and TR by Ecma at its December, 2002, General Assembly.

Joining Ecma

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.

Acknowledgements

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:

• Intel Corporation
• ISE (Eiffel)
• IT University, Copenhagen
• Kahu Research, New Zealand
• Microsoft Corporation
• Novell (Mono)

转贴，已经记不清出处，抱歉。

1、儿时，小男孩家很穷，吃饭时，饭常常不够吃，母亲就把自己碗里的饭分给孩子吃。母亲说，孩子们，快吃吧，我不饿！——母亲撒的第一个谎

2、男孩长身体的时候，勤劳的母亲常用周日休息时间去县郊农村河沟里捞些鱼来给孩子们补钙。鱼 很好吃，鱼汤也很鲜。孩子们吃鱼的时候，母亲就在一旁啃鱼骨头，用舌头舔鱼骨头上的肉渍。男孩心疼，就把自己碗里的鱼夹到母亲碗里，请母亲吃鱼。母亲不 吃，母亲又用筷子把鱼夹回男孩的碗里。母亲说，孩子，快吃吧，我不爱吃鱼！——母亲撒的第二个谎

3、上初中了，为了缴够男孩和哥姐的学费，当缝纫工的母亲就去居委会领些火柴盒拿回家来，晚上 糊了挣点分分钱补点家用。有个冬天，男孩半夜醒来，看到母亲还躬着身子在油灯下糊火柴盒。男孩说，母亲，睡了吧，明早您还要上班呢。母亲笑笑，说，孩子， 快睡吧，我不困！——母亲撒的第三个谎

4、高考那年，母亲请了假天天站在考点门口为参加高考的男孩助阵。时逢盛夏，烈日当头，固执的 母亲在烈日下一站就是几个小时。考试结束的铃声响了，母亲迎上去递过一杯用罐头瓶泡好的浓茶叮嘱孩子喝了，茶亦浓，情更浓。望着母亲干裂的嘴唇和满头的汗 珠，男孩将手中的罐头瓶反递过去请母亲喝。母亲说，孩子，快喝吧，我不渴！——母亲撒的四个谎

5、父亲病逝之后，母亲又当爹又当娘，靠着自己在缝纫社里那点微薄收入含辛茹苦拉扯着几个孩 子，供他们念书，日子过得苦不堪言。胡同路口电线杆下修表的李叔叔知道后，大事小事就找岔过来打个帮手，搬搬煤，挑挑水，送些钱粮来帮补男孩的家里。人非 草木，孰能无情。左邻右舍对此看在眼里，记在心里，都劝母亲再嫁，何必苦了自己。然而母亲多年来却守身如玉，始终不嫁，别人再劝，母亲也断然不听，母亲 说，我不爱！——撒的五个谎

6、男孩和她的哥姐大学毕业参加工作后，下了岗的母亲就在附近农贸市场摆了个小摊维持生活。身在外地工作的孩子们知道后就常常寄钱回来补贴母亲，母亲坚决不要，并将钱退了回去。母亲说，我有钱！——撒的六个谎

7、男孩留校任教两年，后又考取了美国一所名牌大学的博士生，毕业后留在美国一家科研机构工作，待遇相当丰厚，条件好了，身在异国的男孩想把母亲接来享享清福却被老人回绝了。母亲说，我不习惯！——撒的七个谎

8、晚年，母亲患了胃癌，住进了医院，远在大西洋彼岸的男孩乘飞机赶回来时，术后的母亲已是奄奄一息了。母亲老了，望着被病魔折磨得死去活来的母亲，男孩悲痛欲绝，潸然泪下。母亲却说，孩子，别哭，我不疼。——撒的最后一个谎

2007年初，刚刚卸任的联合国秘书长安南，在德克萨斯州的一个庄园里举行了一场慈善晚宴，旨在为非洲贫困儿童募捐。应邀参加晚宴的都是富商和社会名流。在晚宴将要开始的时候，一位老妇人领着一个小女孩来到了庄园的入口处，小女孩手里捧着一个看上去很精致的瓷罐。

 守在庄园入口处的保安安东尼拦住了这一老一小。“欢迎你们，请出示请柬，谢谢。”。

“请柬，对不起，我们没有接到邀请，是她要来，我陪她来的。”老妇人抚摸着小女孩的头。

 “很抱歉，除了工作人员，没有请柬的人不能进去。”安东尼说。

“为什么？这里不是举行慈善晚宴吗？我们是来表示我们的心意的，难道不可以吗？”老妇人的表情很严肃，“可爱的小露西，从电视上知道了这里要为非洲的孩子们举行慈善活动，她很想为那些可怜的孩子做点事，决定把自己储钱罐里所有的钱都拿出来，我可以不进去，真的不能让她进去吗？”

“是的，这里将要举行一场慈善晚宴，应邀参加的都是很重要的人士，他们将为非洲的孩子慷慨解囊。很高兴你们带着爱心来到这里，但是，我想这场合不适合你们进去。”安东尼解释说。

“叔叔，慈善的不是钱，是心，对吗？”一直没有说话的小女孩问安东尼，她的话让安东尼愣住了。“我知道收到邀请的人有很多钱，他们会拿出很多钱，我没有那么多，但这是我所有的钱啊，如果我真的不能进去，请帮我把这个带进去吧！”小女孩露西说完，将手中的储钱罐递给安东尼。

安东尼不知道是接还是不接，正在他不知所措的时候，突然有人说：“不用了，孩子，你说得对，慈善的不是钱，是心，你可以进去，所有有爱心的人都可以进去。”说话的是一位老头，他面带微笑，站在小露西身旁。他躬身和小露西交谈了几句，然后直身起来，拿出一份请柬递给安东尼：“我可以带她进去吗？”

安东尼接过请柬，打开一看，忙向老头敬了个礼：“当然可以了，沃伦·巴菲特先生。”

当天慈善晚宴的主角不是倡议者的安南，不是捐出300万美元的巴菲特，也不是捐出800万美元的比尔·盖茨，而是仅仅捐出30美元零25美分的小露西，她赢得了最多最热烈的掌声。而晚宴的主题标语也变成了这样一句话“慈善的不是钱，是心。”第二天，美国各大媒体纷纷以这句话作为标题，报道了这次慈善晚宴。看到报道后，许多普普通通的美国人纷纷表示要为非洲那些贫穷的孩子捐赠。

2006年的职场出奇的冷清，相比前几年，简历的数量和质量都大为不如，很难得找到三年工作经验以上的人，有一个 不是特别笨，就是特别怪。就是么，干得好谁没事换工作啊！Simon是一家外企软件公司的总经理，最近给这个问题愁坏了。项目一个接一个的接下来，人手越 来越紧张。虽然Simon是个极限编程的粉丝，但也不得不批准了一份又一份的加班申请。HR经理把这个问题归结到房价上，他的妙论是“怕失业了还不上房 款，不敢跳槽”。

这天，K项目组长Allen终于忍不住了，带了一个只有一年工作经验的小伙子要Simon面试，“很聪明！经验少了点。”

Simon皱了皱眉毛，说：“你不知道这个职位最低要求是三年工作经验吗？”

Allen说：“这已经是三个月里通过技术考试中最好的一个了，老大，试试吧。”Allen是Simon多年的哥们，比较随便。

抵到面子上来，Simon只好让Allen把小伙子带进来。

Simon的面试通常是三步曲：

问题一：你能说说毕业后的主要工作经历吗？

问题二：再说说你在公司的地位？

问题三：你的发展目标是什么？等回答后，比如说架构师，他就跟着问：想象一下你当架构师的一天，说给我听听？

小伙子回答第一问题很快很清楚，一年工作当然没什么东西。Simon觉得小伙子挺聪明。所以在小伙子回答了第二个问题后，问了一个发散性的问题：“你刚才说你在公司里处于中等水平，那比你差的人为什么会比你差呢？”

这个问题是个陷阱。

小伙子冒冒失失回答说：“我觉得他们每天工作是为工作而工作，工作没有责任感。”

Simon点点头说：“是吗？那真是糟糕的员工。那你刚好比糟糕的员工好一点了？”

小伙子的脸一下子红了，“我不是这个意思……”

“好了，那你说说比你好的人为什么比你强？”

“我觉得他非常努力，工作很多年了还在学习各种构架，水平很高。”于是Simon就问那最后一个问题。果然，小伙子回答的是要成为架构师。大概70％的人想成为架构师。但是架构师是什么呢？

Simon问道：“那你为什么要成为架构师呢？”

小伙子一愣，大概还没有人这么置疑过他。“年纪大了，不能老写程序吧。”这个回答，让Simon想起关于他对什么是老的定义：当你希望做年轻人做的事情时，你就还年轻；如果你希望做老年人做的事情，你就老了。这和你出生了多长时间是没有关系的。

Simon接着问：“好吧，那你说说你成为架构师以后，每天都会做什么？”

小伙子说：“我还没想过，不过，我想应该主要是需求分析，设计构架吧……”这大概是现在年轻人的通病，年轻人很容易追逐一些自己也不清楚的目标。

Simon问：“那设计构架具体都做些什么呢？”

小伙子这次的回答是：“比如，选择程序框架，决定用Spring或Struts等等。”

“哦，那我问你，你怎么说服别人是用Spring还是Struts呢？”

“如果我有经验，我会知道哪个更好……”

“是吗，但关于Spring或Struts的知识任谁都可以很容易得到。如果别人不同意你的建议，你怎么说服他？如果同意你的建议，那你不过是作出了和别人一样的认识，别人又凭什么认可你呢？”

小伙子没想过架构师日子里还有一个说服人的工作，说：“我是架构师，我应该有权力做决定吧？”

Simon想起权力的三种层次，第一层，任命；第二层，专业；第三层，品德。

Simon问：“如果在一个成熟的软件企业里没有你所想象的架构师呢？或者说，架构师这种职业已经死亡或消失了呢？你会怎么定位你的职业？”

小伙子显得很震惊。

Simon画了一个系统构架，然后又给小伙子看了一段代码。

“那一个更难懂？”Simon问。

小伙子指着代码说：“代码难懂。”

Simon的解释是：“这就是为什么实际上所谓的架构师不存在的原因。一个更简单的东西怎么会更有价值呢？每个人都能够画出这种构架图，但不是每个人都能写出好的代码。”

送走了小伙子，Simon有点难受。他有点喜欢这个小伙子，但是，这又是一个被愚蠢的教育和误人子弟的技术杂志污染的家伙。Simon在自己的笔记本中加了一句话：中国程序员最愚蠢的认识之三：我想当架构师。前面两个赫然是：

35岁后写不动程序了；

我只要做Java（C＋＋）；

测试配置

• 硬件: Intel Core i7 920@2.67Ghz(4 core, HyperThread), 12GB RAM
• 操作系统: Microsoft Windows 7 64-bit

渲染的解像度为256x256，每象素作100次采样。

结果及分析

下表中预设的相对时间以最快的单线程测试(IC++)作基准，用鼠标按列可改变基准。由于Ruby运行时间太长，只每象素作4次采样，把时间乘上25。另 外，因为各测试的渲染时间相差很远，所以用了两个棒形图去显示数据，分别显示时间少于4000秒和少于60秒的测试(Ruby是4000秒以外，不予显 示)。

C++/.Net/Java组别

静态语言和动态语言在此测试下的性能不在同一数量级。先比较静态语言。

C++和.Net的测试结果和上一篇博文相若，而C#和F#无显著区别。但是，C++/CLI虽然同样产生IL，于括管的.Net平台上执行，其渲染时间 却只是C#/F#的55%左右。为什么呢？使用ildasm去反汇编C++/CLI和C#的可执行文件后，可以发现，程序的热点函数 Sphere.Intersect()在两个版本中，C++/CLI版本的代码大小(code size)为201字节， C#则为125字节！ C++/CLI版本在编译时，已把函数内所有Vec类的方法调用全部内联，而C#版本则使用callvirt调用Vec的方法。估计JIT没有把这函数进 行内联，做成这个性能差异。另外，C++/CLI版本使用了值类型，并使用指针(代码中为引用)托管代码(C++/CLI)的渲染时间，仅为原生非括管代码(IC++)的1.91倍，个人觉得.Net的JIT已经非常不错。

另一方面，Java的性能表现非常突出，只比C++/CLI稍慢一点，Java版本的渲染时间为C#/F#的65%左右。以前一直认为，C#不少设计会使其性能高于Java，例如C#的方法预设为非虚，Java则预设为虚；又例如C#支持struct作值类型(value type)，Java则只有class引用类型(reference type)，后者必须使用GC。但是，这个测试显示，Java VM应该在JIT中做了大量优化，估计也应用了内联，才能使其性能逼近C++/CLI。

纯C++方面，Intel C++编译器最快，Visual C++慢一点点(1.19x)，GCC再慢一点点(1.32x)。这结果符合本人预期。 Intel C++的OpenMP版本和单线程比较，达5.16加速比(speedup)，对于4核Hyper Threading来说算是不错的结果。读者若有兴趣，也可以自行测试C# 4.0的并行新特性。

动态语言组别

首先，要说一句，Google太强了，难以想像JsChome的渲染时间仅是IC++的16.12倍，C#的4.94倍。

以下比较各动态语言的相对时间，以JsChrome为基准。 Chrome的V8 JavaScript引擎(1.00x)大幅抛离Firefox的SpiderMonkey引擎(15.09x)。而LuaJIT(3.49x)和Lua(5.16x)则排第二和第三名。 Lua的JIT版本是没有JIT的68%，并没有想像中的快，但是也比Python(16.48x)快得多。曾听说过Ruby有效能问题，没想到问题竟然如此严重(327.31x)，其渲染时间差不多是Python的20倍.