Skip navigation

Intel® first added support for simultaneous multithreading in the Pentium® 4 family of products, calling the technique Intel® Hyper-Threading (HT) technology. HT allows multiple-threaded applications to run simultaneously on a processor that has multiple parallel execution engines. The technology was not present in the Intel® Core™ microarchitecture but reappeared in the Nehalem microarchitecture that is the basis for the newest Xeon® and Core i7, i5, and i3 families. The Nehalem microarchitecture includes four separate instruction decoders that operate in parallel enabling a high degree of parallel instruction execution on a single core and maximizing performance of threaded applications.


Nehalem-based processors include three identical instruction decoders for simple instructions, and one for complex instructions. The processors can use the four decoders to support two threads on each core. And Intel offers Nehalem-based processors with two to six cores. That means the high end of the family, the new Xeon 5600 series, can handle 12 threads simultaneously.


Embedded design teams can leverage HT technology in several ways. For example, you can use HT for virtualization and run multiple operating systems on one core. Early  Atom™ family members included HT support although the microarchitecture only included two parallel instruction paths. I posted a blog last year about how you can use that HT support for virtualization even though the early Atom processors lacked Intel® Virtualization Technology (VT).


In the case of the Xeon family, the more likely use of HT is for performance since the processors integrate VT support. With HT, design teams can gain performance in compute-intensive application through threaded applications.


Radisys*, for example, performed a case study in conjunction with the Georgia Institute of Technology (Georgia Tech) on a medical imaging application hosted on a Xeon 5500 series system. Applications such as CT, MRI, and ultrasound are capturing an increasing amount of data that must be processed immediately. For example, CT scans now have sub-millimeter resolution. But doctors want to process the data in seconds. The case study set out to evaluate how parallel processing could accelerate such imaging applications.


Engineers ran benchmark tests on a dual-processor server, with quad-core-based CPUs. The implementation provided eight cores and the ability to process 16 threads simultaneously. The application was a Katsevich algorithm that is used for 3D CT reconstruction. As the below figure illustrates, execution time improved with the number of threads. Although as you might expect the biggest gain came going from one to two threads and the benefit diminished as the number grew to 16. Still, the performance gain essentially comes for free, so even the relatively small gains that come moving from 8 to 16 threads are worthwhile.




RadiSys offers a range of HT-enabled platforms based on Intel processors. Back in March, for example, the company announced the Procelerant RMS420-5520DT embedded server based on the new Xeon 5600 series. The product supports as many as 12 cores in a dual-processor configuration. Medical imaging is a target market for the product along with video streaming, and high-performance test & measurement.


Have you experimented with threaded applications and a HT-enabled processor? If so, what kind of performance gain did you measure? If not, what are the obstacles to using HT? Please share you experience with fellow followers of the Intel® Embedded Community.


Maury Wright

Roving Reporter (Intel Contractor)

Intel® Embedded Alliance


*RadiSys is a Premier Member of the Intel® Embedded Alliance

These monopolists were controlling the nascent automotive industry with the fear of lawsuits based on the Selden patent. Ford won his suit and formed a new automobile manufacturers’ association. The next step started technology “open source” as a concept. The association instituted a cross-licensing agreement among all US auto manufacturers. Under the terms of the association, each company would develop technology and file patents. Patents were shared openly and without any payments between all the manufacturers. For the next thirty years 92 Ford patents were used freely by other manufacturers. In return, Ford Motor Company used 515 patents from other companies - all without lawsuits or payments.


Skip forward nearly a century and the principles have remained, but now the technology has dramatically changed. Open Source is a seductive concept, but there’s a lot more to developing products based on Open Source:


  • Find a candidate Open Source package
  • Evaluate the source, how it’s maintained, development standards, license terms, and who owns your “proprietary” software
  • Evaluate the trade
  • Select an Open Source package
  • Create a development team and adopt compatible software development standards
  • Develop your product(s)


Open Source based code means finding it first. Source Forge is one of the larger collections of general Open Source software, some of which is appropriate for embedded applications.    Other general sources include and Open Office. More than 100,000 individual web sites also offer embedded “open source” software. Chances are that there are a small number of Open Source packages that are both accepted by your industry and meet your individual programming methodology. Articles in trade publications can provide a starting point to research Open Source offerings when combined with informational web sites like voip-info. 


Evaluation can be a time consuming process or a straight forward simple exercise. Practically, the chief difference in evaluation approaches is based on the size of your organization and the risk perceived in the software choice. Base criteria that should be considered when evaluating software include: industry acceptance, programming language used, Operating System requirements if any, coding standards used, code base maturity/stability, and how the coding standards fit with your organization. 


Evaluating the tradeoffs transcends the technology questions. Some of the issues center on business risk associated with the developers of the Open Source package. Most Open Source has a relatively small number of key contributors. Many companies have concerns over the relatively small number of people involved directly in many Open Source packages. This concern may be offset by a large installed base of the package, reducing the perceived risk by ensuring that there are programmers who understand the software.


Selecting an Open Source package is more than a technical decision. But making the decision often comes down to selecting between small numbers of alternatives. For example, there are perhaps a half dozen Voice over Internet Protocol (VoIP) packages available to develop Private Branch eXchange (PBX) products. To select a VoIP package, installed Open Source packages make one package stand out for having close to a 100 to 1 installed base as compared to the closest competitive VoIP Open Source package. Large numbers of installations often provide a strong indicator of technical competency. Even though the software may meet technical objectives, there are still the license terms to deal with.


For many people, Open Source is really about the initial acquisition cost – free. Today there are 68 separate licenses approved under the Open Source Initiative , each of which must follow the  OSI guidelines. Whether you select an approved OSI software project to use as part of your product, it’s important to keep in mind that this software code is licensed. As with any licensed product, it’s important to have a competent legal review of the license before deciding to base a project on the source.  Ideally the lawyer reviewing the proposed license agreement has significant experience with Open Source Software. This is particularly important because many business contract attorneys lack experience in dealing with Open Source issues.


Technical decisions drive the remainder of adopting Open Source.  Selecting an Open Source package makes a number of decisions for you and your company. One of the most significant decisions may be that of programming standards. Most Open Source is developed in a collaboration environment which may not match with your internal development standards. But if there is no requirements to significantly modify the source code, the development methodology need not be a significant factor. In these cases, it’s easiest to use the same development tools to generate the needed binaries employed by the developers. If those tools are not compatible with your product development environment, there will be source code modifications necessary to retarget the Open Source package. Retargeting source was the subject of another blog. There are a number of tool suites available for Intel embedded processors discussed in earlier blogs including Green Hills Software (1), Intel’s tool chain, Wind River Systems (2), QNX (3) and ironically - open source-based tools.


One of the fundamental bases of Open Source is the idea that additions or modifications to the Open Source code itself generally carries with it an obligation to make the modified software freely available under the terms of the open source license. The obligation of source ownership may be a significant issue in embedded applications, and is a question of licensing terms, the type of software to be developed, and how your development team is organized.  Assuring proprietary software ownership may cause companies to separate their development activities: source code derived from Open Source software in one team, and a second, segregated team developing proprietary software for inclusion in a commercial product. Other possible solutions to the ownership dilemma of Open Source include segregating personnel who have access to the Open Source, contracting with an outside company to deal with the Open Source software and producing only binaries for use in developing proprietary products, and other “clean room” software development methods.


The situation becomes more complex when multiple Open Source code bases are combined into one commercial product. Even with this potential complication, the problems can be managed to permit developers freedom to create new technical solutions for commercial products. The GENIVI consortium seeks to minimize potential for conflict by stops development before the application layer. By agreement, cooperative software development stops at the APIs below the application layer, minimizing the risk to proprietary software ownership. This is one way to deal with the very real issues facing commercial products based on Open Source.


Open Source can save development time and minimize the amount of knowledge required by developers to make ground breaking new products. Where can you see opportunities to use Open Source in your next project?    


(1) Green Hills Software is an Affiliate Member of the Intel Embedded Allaince

(2) Wind River Systems is an Associate Member of the Intel Embedded Alliance

(3) QNX Software Systems is an Associate Member of the Intel Embedded Alliance




Henry Davis
Roving Reporter (Intel Contractor)
Intel(r) Embedded Alliance