Wow, DDJ just posted the previous one a few days ago, and already the next Effective Concurrency column is available: “Understanding Parallel Performance” just went live, and will also appear in the print magazine.
From the article:
Let’s say that we’ve slickly written our code to apply divide-and-conquer algorithms and concurrent data structures and parallel traversals and all our other cool tricks that make our code wonderfully scalable in theory. Question: How do we know how well we’ve actually succeeded? Do we really know, or did we just try a couple of tests on a quad-core that looked reasonable and call it good? What key factors must we measure to understand our code’s performance, and answer not only whether our code scales, but quantify how well under different circumstances and workloads? What costs of concurrency do we have to take into account?
This month, I’ll summarize some key issues we need to keep in mind to accurately analyze the real performance of our parallel code. I’ll list some basic considerations, and then some common costs. Next month, I have a treat in store: We’ll take some real code and apply these techniques to analyze its performance in detail as we successively apply a number of optimizations and measure how much each one actually buys us, under what conditions and in what directions, and why.
I hope you enjoy it. Finally, here are links to previous Effective Concurrency columns (based on the magazine print issue dates):
Posted in Concurrency, Software DevelopmentAugust 2007: The Pillars of Concurrency
September 2007: How Much Scalability Do You Have or Need?
October 2007: Use Critical Sections (Preferably Locks) to Eliminate Races
November 2007: Apply Critical Sections Consistently
December 2007: Avoid Calling Unknown Code While Inside a Critical Section
January 2007: Use Lock Hierarchies to Avoid Deadlock
February 2008: Break Amdahl’s Law!
March 2008: Going Superlinear
April 2008: Super Linearity and the Bigger Machine
May 2008: Interrupt Politely
June 2008: Maximize Locality, Minimize Contention
July 2008: Choose Concurrency-Friendly Data Structures
August 2008: The Many Faces of Deadlock
September 2008: Lock-Free Code: A False Sense of Security
October 2008: Writing Lock-Free Code: A Corrected Queue
November 2008: Writing a Generalized Concurrent Queue
December 2008: Understanding Parallel Performance
Oops, I just noticed that I forgot to blog about one recent Effective Concurrency column: “Writing Lock-Free Code: A Corrected Queue” which also appeared in the October 2008 print issue of Dr. Dobb’s Journal.
From the article:
As we saw last month [1], lock-free coding is hard even for experts. There, I dissected a published lock-free queue implementation [2] and examined why the code was quite broken. This month, let’s see how to do it right.
Here is the complete-as-of-this-writing set of links to the published Effective Concurrency columns. As always, the months reflect the magazine print issue dates; they usually hit the web a bit sooner:
Posted in Concurrency, Software DevelopmentAugust 2007: The Pillars of Concurrency
September 2007: How Much Scalability Do You Have or Need?
October 2007: Use Critical Sections (Preferably Locks) to Eliminate Races
November 2007: Apply Critical Sections Consistently
December 2007: Avoid Calling Unknown Code While Inside a Critical Section
January 2007: Use Lock Hierarchies to Avoid Deadlock
February 2008: Break Amdahl’s Law!
March 2008: Going Superlinear
April 2008: Super Linearity and the Bigger Machine
May 2008: Interrupt Politely
June 2008: Maximize Locality, Minimize Contention
July 2008: Choose Concurrency-Friendly Data Structures
August 2008: The Many Faces of Deadlock
September 2008: Lock-Free Code: A False Sense of Security
October 2008: Writing Lock-Free Code: A Corrected Queue
November 2008: Writing a Generalized Concurrent Queue
December 2008: Understanding Parallel Performance
The next Effective Concurrency column, “Writing a Generalized Concurrent Queue”, just went live on DDJ’s site, and also appears in the print magazine.
From the article:
Last month [1], I showed code for a lock-free queue that supported the limited case of exactly two threads—one producer, and one consumer. That’s useful, but maybe not as exciting now that our first rush of lock-free coding glee has worn off. This month, let’s tackle the general problem of supporting multiple producers and multiple consumers with as much concurrency as possible. The code in this article uses four main design techniques: …
I hope you enjoy it. Finally, here are links to previous Effective Concurrency columns (based on the magazine print issue dates):
Posted in Concurrency, Software DevelopmentAugust 2007: The Pillars of Concurrency
September 2007: How Much Scalability Do You Have or Need?
October 2007: Use Critical Sections (Preferably Locks) to Eliminate Races
November 2007: Apply Critical Sections Consistently
December 2007: Avoid Calling Unknown Code While Inside a Critical Section
January 2007: Use Lock Hierarchies to Avoid Deadlock
February 2008: Break Amdahl’s Law!
March 2008: Going Superlinear
April 2008: Super Linearity and the Bigger Machine
May 2008: Interrupt Politely
June 2008: Maximize Locality, Minimize Contention
July 2008: Choose Concurrency-Friendly Data Structures
August 2008: The Many Faces of Deadlock
September 2008: Lock-Free Code: A False Sense of Security
October 2008: Writing Lock-Free Code: A Corrected Queue
November 2008: Writing a Generalized Concurrent Queue
![《猫和老鼠传奇2008》(Tom and Jerry Tales 2008)英文字幕[RMVB]](http://image-2.verycd.com/bdf034ef6f6d0a9eef349935fd136b9964797(280x)/thumb.jpg)
中文名称：猫和老鼠传奇2008Hi, this is Matt from the Windows Performance team. Sometimes we are presented with problems that defy our usual troubleshooting and require a creative approach. In a recent case, we needed a way to test the responsiveness of an application as text was typed into its fields. Initially, we tested the program using a script that used the SendKeys method to time entry time. Unfortunately, these tests aren’t completely realistic, since the script can be affected by the processor utilization on the system, and the script can’t create hardware interrupts like a keyboard does. Realizing that only real keyboard input would be a valid test, and that the rate of typing needed to be reproduced exactly for each test, I set about building an automated keyboard.
First, I found an old PS/2 style keyboard that hadn’t been used in years and opened it up. Luckily, it was old enough to use all through-hole components, which made it easier to modify. The main component I cared about was the keyboard encoder, which was a COP943C. A search online turned up a datasheet for the keyboard encoder with a sample circuit design that looked very similar to this keyboard. The document shows there are a couple of steps to determining which pins need to be shorted to generate a particular key.
Each key has an ID number that is shown in figure one of the PDF (figure one below). After finding the proper ID, a table is consulted to determine the row and column pins used to create that key code (figure two below). Finally, those row and column numbers are translated into physical pins on the encoder using the schematic diagram (figure three below). For example, the letter ‘a’ is number 31. The matrix shows 31 is made with the L5 (column 6) pin and C6 (row 3) pin. The pin out shows this to be physical pins 14 and 19. When tested, shorting these pins creates an ‘a’.
See the video:
Figure 1: Key Codes
Figure 2: Key Code Matrix
Figure 3: Encoder Pin Out
Now that we know how the keyboard circuit works, we need a method to generate key “presses.” For this, I found a board I assembled a year or two ago using a PCB and components from moderndevice.com. The board is an Arduino clone that is based on Atmel’s ATmega168 microcontroller. One of the great things about using an Arduino is their IDE, which allows for C programming with a number of pre-defined functions to make development quick. Also, the boot loader is already taken care of, which makes the work easier.
Wiring the board to the keyboard was straightforward. Figure 4 shows how to control a relay with an Arduino, and triggering a keyboard is rather similar. A resistor is placed between a digital out pin of the Arduino and the base pin of a transistor. The collector then goes to one pin of the keyboard encoder needed to type the letter desired, and the emitter goes to the other pin.
Figure 4: Arduino-controlled Relay[ii]
In order to save on solder joints, I decided to chain together the transistors, which affected the key selection. Additionally, because I wanted to leave the encoder in the original circuit and some of the pins were blocked by other components (resistors, capacitors), specific pins were selected. Figure 5 shows the layout of the transistors. These were soldered to a prototyping board with hook up wire to connect back to a breadboard with resistors and the Arduino and hook up wire soldered directly to the pins of the keyboard encoder.
Figure 5: Transistor Layout
These pins selected allowed characters a, s, z, space, and enter to be typed. All that remained was to write some software to trigger the transistors. The code first sets the digital pins to output and logic low, turns on a LED to show it is working, then waits 3 minutes to allow time for the PC to boot and application in question to be launched. The LED then goes out for a five-second warning, and then the loop sequence begins. The loop turns on the LED, types “as z” followed by enter, then turns off the LED and sleeps for 2.5 seconds before starting again.
|
// Sample code to drive keyboard encoder
// Matt Burrough
// September, 2008
int ledPin = 13; // Use digital pin 13 for a status LED
int sPin = 3; // Connect pin 3 to the transistor connected to the s leads
int aPin = 4; // Pin 4 is for a
int zPin = 5; // Pin 5 is z
int enterPin = 6; // Pin 6 is enter
int spacePin = 7; // Pin 7 is space
int holdKey = 30; // Milliseconds to "hold" each key down
int betweenKeys = 50; // Milliseconds to wait between key presses
void setup() { // Initial setup code (runs at power-on)
setupPin(ledPin); // Set up each pin with function below
setupPin(sPin);
setupPin(aPin);
setupPin(zPin);
setupPin(enterPin);
setupPin(spacePin);
digitalWrite(ledPin, HIGH); // Turn on the LED to show the board is on
delay(180000); // Wait 3 minutes to allow time for PC to boot
digitalWrite(ledPin, LOW); // Turn off the LED
delay(5000); // Wait 5 seconds
}
void loop() {
digitalWrite(ledPin, HIGH); // Turn the LED on
typeKey(aPin); // Type keys
typeKey(sPin);
typeKey(spacePin);
typeKey(zPin);
typeKey(enterPin);
digitalWrite(ledPin, LOW); // Turn the LED off
delay(2500); //Pause 2.5 seconds
}
void setupPin(int pin) { // Used to set up pins...
pinMode(pin, OUTPUT); // Set the digital pin as output
digitalWrite(pin, LOW); // Turn off the pin
}
void typeKey(int pin) { // Type a key...
digitalWrite(pin, HIGH); // "Press down" on a key
delay(holdKey); // Hold down the key
digitalWrite(pin, LOW); // "Release" the key
delay(betweenKeys); // Pause between keys
}
|
Figure 6: Code Sample
That’s how I made an automated keyboard. I hope that you’ve found this post interesting; I’ll leave you with a photo of the finished product.
One of the current pain points in our build system is the xpidl compiler. This is a binary tool which is used to generate C++ headers and XPT files from XPIDL input files. The code depends on libIDL, which in turn depends on glib. Because this tool is a build-time requirement, we have to build a host version, and in most cases we also build a target version to put in the SDK package.
Getting glib and libidl on linux systems is not very difficult: all the major distros have developer packages for them. But getting libidl and glib on Windows and mac can be quite painful. On Windows, we have had to create our own custom static library versions of this code which are compatible with all the different versions of Microsoft Visual C++. On Mac you can get them from macports, but as far as I know they are not available in universal binaries, which means that you can’t cross-compile a target xpidl.
Parsing IDL, while not trivial, is not so complicated that it requires huge binary code libraries. So a while back I reimplemented the XPIDL parser using python and the PLY (python lex-yacc) parsing library. The core parsing grammar and object model is only 1200 lines of code.
Because we don’t have any unit tests for xpidl, I chose to use A-B testing against the output of the binary xpidl: the header output of the python xpidl should match byte-for-byte the header output of the binary xpidl. I wrote a myrules.mk file which would automatically build and compare both versions during a buld. This turned out to be a royal pain, because the libIDL parser is not very consistent and has bugs:
I had to add some temporary nasty hacks in order to work around these issues. And finally, reproducing the wacky whitespace of the binary tool wasn’t worthwhile, so I starting comparing the results using diff -w -B. But with these hacks and changes, both xpidl compilers produce identical C++ headers.
I completed the code to produce C++ headers during a couple of not-quite-vacation days, but I didn’t write any code to produce XPT files. I shelved the project as an attractive waste of time, until jorendorff needed an IDL parser to produce quick stub C++ code. Jason managed to take my existing code and hook up a quick-stub generator to it. The python xpidl parser and quick-stub generator are both used in the codebase.
Currently, we’re still using the old binary xpidl to produce C++ headers and XPT files. If somebody is interested, I’d really like help adding code to produce XPT files from the new parser, so that we can ditch the old binary code completely.
If you ever need to use python to parse some interesting grammar, I highly recommend PLY. If you turn on optimization it performs very well, and it has very good support for detailed error reporting.
反光条是一种很常见的安全设备，可以在夜间反射周围的光线，从而对路人和司机起到一定的警示作用。但是要在普通的衣服外侧加上反光条似乎有些影响美观，所以就有公司设计出了这样一款反光裤。
它将反光条设计在了裤腿和裤兜内侧。夜间骑车的时候只要将裤腿挽起、裤兜外翻即可达到与传统反光条相同的效果。更重要的是，平时不用的时候也丝毫不会影响到衣物的美观。
以下是该产品的一段演示视频：
感谢HiGPhone中文网的投递
Android的最大特色就是他的开源和对软件的支持，凭借着开放的Web API接口，可以让软件有效地与手机中的数据相结合，从而达到意想不到的功效，你手机上的摄像头，GPS，重力加速器，指南针不再是摆设，而变成了帮你在互联网的茫茫信息海洋中准确定位你所需要信息的有力助手。
斑马线（Zebra Crossing）是一个利用摄像头的应用，他采用了开源图书馆的数据库和照相机拍下的内容相比较判断你说阅读的书籍详细信息。你只需要用你的照相机对准书籍背面的条形码部分拍照，软件会自动识别条形码所对应的号码，并且在互联网上搜索书目的价格评价等信息。
（扫描书籍的条形码）
（扫描结果7228601006）
（在Google上搜索条形码为7228601006的产品信息）
斑马线（Zebra Crossing）同样支持二维码的扫描，如果你的名片中有二维码的图形（谷歌名片的背面就印有二维码），你可以通过扫描二维码，来获得名片信息，扫描以后，会显示该名片的姓名，电话，Email信息，在扫描结束，你可以选择是否保存这个名片信息到你的通讯薄里，或者直接拨打电话给这个号码，大大节省了手动录入信息的时间。而这个应用也是开源的，这意味着开发者不必重新编写代码就可以直接利用这部分的功能，开发出类似的产品供消费者使用。你也可以扫描一本书背后的条形码来让手机告诉你这本书是否还有库存之类的信息。
（嗯……一个可能很多人梦寐以求的名片）
（谷歌名片的背面印有二维码）
（用手机拍下二维码）
（会自动识别出姓名，邮箱，电话号码）
（按拨打可以直接拨出电话）
（直接给对方发送电子邮件）
（将对方加入通讯录）
Panoramio是一个利用GPS的应用，他可以通过定位系统里了解你现在的地址位置，并且通过网络找到这个区域的热门照片，比如某个商场或者书店，这些照片都带有自己的地理信息，你可以直接在地图上显示这个商店的位置，如果你没有方向感，Panoramio已经为你准备好的一个迷你指南针，一个类似雷达的小功能，他可以告诉你往那个方向走，距离目标还有多少米以及还需多少时间才可以到达等等相关信息。
（通过GPS定位你的位置）
（列出你周围的热门照片）
（这里选择了T-Rex)
(雷达会根据数据信息告诉T-Rex在你的5点钟位置，举例你有200码）
手机的诞生让通讯从只能在固定位置打电话到随心所欲的打电话，在任何地方你都可以通过手机与外界沟通，而谷歌的目的就是可以更加强化手机的移动便携性可以给人们生活带来的帮助，你不能在去超市或书店的时候还携带一部相机和可上网的笔记本，但是完全可以携带一个只有手掌大小的Android手机，有了他，你会发现你的生活会简单很多。
供稿：HiGPhone中文网
Tip: Managing Your Reading ListBefore you get started, we want to let you know about an important feature of Google Reader. As you view items in your reading list, they will be automatically marked as read as you scroll down (when in the "Expanded" view). If you'd prefer to disable this feature, you can turn it off in Settings. Dismiss this message (it will not appear again) |
||
Sharing interesting items with your friends is easy: simply click on the sharing icon.
The item will then instantly appear on your public page at:
This page is accessible to anyone who knows its address, so all that's left to do is to let your friends know about it.
Additionally, all your friends in Gmail Chat and Google Talk that use Google Reader will then be able to see your shared items. Learn more about friends.
Find out more about sharingSort by oldest only shows items from the last 30 days. Learn more Dismiss |
||
You are not subscribed to this recommended feed yet.
If you'd like to automatically receive updates to this feed, you can subscribe now.
« Back to my recommended feeds |
||||||
