Byte order fallacy and optimization

In Rob Pike's The byte order fallacy, he advocates portability and simplicity, but failed to address the performance issue (wrong to modern processors).
"byte order doesn't matter" - for you local machine; but, should be taken care when handling IO.

The optimization is more interesting: that code block could be optimized by CLang, but not GCC.

Comments from Chris Lattner:

In general, optimizing the original code to a single 32-bit load on little endian targets is not safe: the pointer may not be aligned. However, even after marking the pointer aligned, clang still misses the optimization.

Clang can successfully forward loads and stores when the accessed object is known.
Finally, Clang also optimizes the opposite: turning this code into a "bswapl" on x86.

You won't missing ntohl/htonl, right?
And there is network types support!

WOW64

Some time ago, I happened to know WOW64 is short for "Win 32 On Win 64" - WOW!

This time for a bug, I looked deeper.

• Changes to file system are more visible

File System Redirector
only system32 and most sub-folders are taken care of;
"Program Files" is not covered here, but by using environment variables;
for 32-bit and 64-bit programs, they use their own copies - redirected to different folders; the shared are bit regardless, like logfiles, hosts are plain text files;

• Changes to Registry are more error prone

Registry Reflection - it was used, now deprecated; using the share model;
Registry Redirector - copy model, in most recently versions of OSs
Registry Keys Affected by WOW64 - finally, copy model and share model co-exist

And even worse, Wow6432Node could generate recursive path; regedit handles this correctly;

But, most of us developers are not going to learn all this, or read the Best Practices for WOW64. We'd rather write our own functions, like check the OS's version, and make up the file/registry path by hand, instead of OS APIs, like IsWow64Process(), or environment variables.

Time related issues

* NTP was not designed to run inside of a virtual machine
* For long running applications, using 32-bit for timing could overflow; but, 64-bit could fail in another way

My calculation on Yahoo's job cutting

Yahoo! Statement

Yahoo! expects to realize approximately $375 million of annualized savings upon completion of all employee transitions. The company currently expects to recognize the majority of an estimated $125 to $145 million pretax cash charge relating to employee severance...

Based on these numbers:
* Average yearly salary: 375*1000/2000 = 187.5 K$/year (so an average employee, to be cut, gets half of that in hand or paid - 93.75K$/year?).
* Average years in Yahoo: (375/145, 375/125) = (2.586206896551724, 3.0) Year, if all/most of them get a n+1 compensation.

The first average number maybe meaningless;
The second average number might be the common evaluation of employees from a company's business view.

As mentioned here (in Chinese): Yahoo has 14000 employees in total.
Then, this is a 14% cut off, and most of employees are serving Yahoo less than 2 years.
So, Yahoo has/had pretty much fresh blood?

两个估算——雅虎将裁员2000人

雅虎将裁员2000人，每年节省3.75亿美元，裁员成本约为1.25亿至1.45亿美元。

据此估算：

• 平均年薪：3.75*10000/2000 = 18.75万 USD。
• 平均工龄：(3.75/1.45, 3.75/1.25) = (2.586206896551724, 3.0) Year。
• 员工分布：至少14%的员工，加入雅虎不超过2年。
  

第一个估算值，意义不大。
第二个估算值，如果高管也是按照 n+1 赔偿，还是有点参考意义——工龄对公司的意义，至少是财务上的。
第三个估算值，也没什么意义。或者说，雅虎（曾经）"生机勃勃"，有很多新员工可裁？