Slashdot Mirror

A 30-pin SIMM, like our TM4100GAD8, can only spit out 8 bits of data at a time.

I think work on a properly optimizing compiler is important, since the speed gains attained through those optimizations may be the deciding factor in a close fight between Itanium and AMD's chip.

You understate the case. Every modern general purpose CPU implementation is "design symbiotic" with a targeted modern compiler(s). The primary distinction between RISC/CISC/VLIW/etc. architectures is the tradeoff of work between the CPU and the compiler. (Go dig around in the technical documentation at the TI 'C6x DSP web site for a fascinating view of how a modern VLIW architecture impacts processor and compiler design.)

The architectural decisions in hardware must be borne out by a compiler that leverages these features to the fullest. Likewise, the implementation of a CPU must actively enable the compiler to take maximum advantage of hardware bandwidth. Once the chips tape out, both Intel and AMD MUST ensure that the compilers measure up -- or else they've run half the race and given up.

Nope, it was 1280x1024

See http://www.ti.com/dlp/pr oducts/cinema/specs_dinosaur.shtml

First off, the first actual live presentation (non trade show, non test environment) of a digital projection in a theatre was on June 18, 1999, Star Wars Episode 1. When I saw that show, (which wasnt that great, too pixelized at times) we spoke with the DLP projection guy to see how much info we could squeeze out of him. He said that the movie itself was around 500 Gigs, and was stretched across 15 or so hard drives. He went on about it's true XGA resolution, millions of mirrors, and whatnot. If you're really interested you can find all of the white papers here:
http://www.ti.com/dlp/ resources/whitepapers/tech/index.shtml

and all of the press releases here:
http://www.ti.com/dlp/ Sharkey
www.badassmofo.com

First off, the first actual live presentation (non trade show, non test environment) of a digital projection in a theatre was on June 18, 1999, Star Wars Episode 1. When I saw that show, (which wasnt that great, too pixelized at times) we spoke with the DLP projection guy to see how much info we could squeeze out of him. He said that the movie itself was around 500 Gigs, and was stretched across 15 or so hard drives. He went on about it's true XGA resolution, millions of mirrors, and whatnot. If you're really interested you can find all of the white papers here:
http://www.ti.com/dlp/ resources/whitepapers/tech/index.shtml

and all of the press releases here:
http://www.ti.com/dlp/ Sharkey
www.badassmofo.com

Here's some more stuff: http://www.ti.com/dlp/products/cinema/


Don't criticise someone who is attempting to use free software for not using enough free software.

It uses TI's Digital Light Processors. here's TI's press release: http://www.ti.com/dlp/resources/spotlight/


Don't criticise someone who is attempting to use free software for not using enough free software.

i've looked at love from both sides now. from win and lose, and still somehow...

I think Compaq has the smallest version at 4.5, XGA, 800 lumens...

Plus corporation just announced the world's smallest projector: 2.9 lbs., 7 x 9 x 1.9", XGA, 800 lumens, no price yet.

I'm not sure how much this pertains to what you are doing, but a couple of years ago I wrote a little piece on the role of calculators in math classrooms from kindergarten through college. Yes, it was written for a company that makes calculators, so yes, it sings the praise of calculators, but you will find its claims are backed up by credible research. The document may assist you in your quest to understand the ever-changing role of the mathematics education (with regard to problem-solving, number-crunching, abstract conceptualization and reasoning, rote memorization, and myriad other topics). You may find the reference list to include some resources that might be of use to you. (You might also want to contact the National Council of Teachers of Mathematics or other math/education-related organizations.) Hope this helps a bit.

If you need really a fast floating point real time, why not use a DSP? Although DSPs are primarily built for signal processing, the new processors handle other operations like interrupts pretty well. Many of these DSPs can perform floating point inversions in one cycle. A lot of them are Harvard Architecture machines and are primarily built for fast Multiply and Accumulates. But, these processors run real time OSes and are capable of doing multithreaded operations. Some newer processors have really fast ports that can talk to other processors and can be easily scaled to a multiprocessor system. And - manufacturers like TI and Analog Devices have been making really fast DSPs lately (TI just announced its 1GHz DSP). They are not that expensive either (They are comparable to the embedded processors made by Motorola). And, the best part is that the new processors really little power. So, why use Intel or AMD for real time processing when you can use a really fast DSP which costs less.

You'll find them doing things such as encryption, compression, audio/video processing, yada, yada. All in real time.

See this for more. (a bit dated but still relevant).

The only origional design to the iMac is the rounded translucent design. All-in-the-screen designs have existed for a long time (The origional Macs, Compaq made some PCs, etc)

Maybe they should sue HP and TI. The HP49 is rounded and has a translucent cover. And look the these covers that TI sells for some of their calculators.

The only origional design to the iMac is the rounded translucent design. All-in-the-screen designs have existed for a long time (The origional Macs, Compaq made some PCs, etc)

Maybe they should sue HP and TI. The HP49 is rounded and has a translucent cover. And look the these covers that TI sells for some of their calculators.

There are a huge number of FireWire devices.
Here's a short list (not for 28K modems).

Some related articles/sites:

The GNU/Linux IEEE 1394 Development Project
FireWire: The Fast, Easy to Use, Multimedia Interconnect Standard
IEEE 1394, the A/V Digital Interface of Choice
FireWire -- For Footage That Flies
Papers on IEEE 1394 Technology
Texas Instruments Interface Products

The Haifa scheduler and other "interesting" pieces in the backend should really help alot. From what I recall, Haifa includes a software pipeliner as well as some other block-scheduling pieces which will be very necessary to get parallelism out of this beast.

One thing I wonder is whether they're actually generating bundles, or if they're just issuing a serial code stream. For the uninitiated, a bundle is Intel's term for a group of instructions that have been marked for parallel execution. An early compiler port that's striving for correctness need not know about bundles by simply issuing bundles which contain a single instruction each. The peephole optimizer might do trivial pairing of instructions after-the-fact, but you really don't get alot of parallelism that way, trust me.

The compiler won't truly shine until the full IA-64 pipeline model, complete with instruction latencies, numbers and mixes of functional units, etc. is described in minute detail to the compiler, and the compiler has the infrastructure for stitching together tightly packed bundles. There are many techniques and optimizations that will need to be implemented in order to stitch those bundles together.

It'll be even more interesting if the compiler can tune for different EPIC iterations, since different chips will have different numbers of functional units. Although the EPIC encoding is scalable, the best performance will be reached if the code provides parallelism which matches the available hardware, rather than exceeding it, since overly parallel code may tie up more registers than is necessary and will trash the instruction cache if it's unrolled too much.

I'm willing to wager that this early GNU C port is available now because the IA64 offers a protected pipeline. IMHO, the single biggest difference between EPIC and VLIW is that EPIC provides pipeline interlocks, whereas traditional VLIW exposes all delay slots and requires the programmer to get it right. While the protected pipeline allows early compilers to ramp up quickly, it also lowers the performance ceiling for a given transistor count.

If anyone here wants to see really hairy VLIW code, go check out TI's C6000 benchmarks page. The C6000 can issue 8 instructions every cycle, and has a fully exposed pipeline. (For those of you crazy enough to click the link, the '||' are used to denote parallel instructions, and branches occur 5 cycles after they're issued.) It's an absolute blast to program by hand (it's my day job), but you don't want to program anything larger than a function in scope. You get a very strong appreciation for compiler technology too. :-) Let me tell you, I've seen some of these "interesting" optimizations coming from the C6000 compiler, and they're pretty mind-bending. I wonder how long they'll take to get these into the IA64 compilers...

--

Texas Instruments recently announced cheap projection chipsets that will eventually make this technology less than $1000 for home entertainment centers. Currently this technology is used for business PC projectors which has fallen from $15,000 to $4,000 the past two years.

TI's DLP page has a lot of info. We've got a DLP(Digital Light Processing) projector at work and I am very impressed with the image it produces. Much cleaner than an LCD projector.

Check this out!

TIRIS

something Texas Instruments is working on

> I know of a company still using a Z80-based machine [...]
Watch it!
My TI-83 calculator is based on a Z80! And I bought it less than a year ago!

First, before everyone jumps in and says "Intel will never get there because the compiler will never get there," please don't forget that some shipping devices are already there.

Quite simply, EPIC allows a compiler to tell the hardware ahead of time where it knows parallelism exists, so that the silicon (which is finite) doesn't have to hunt for it. Compared to the rate at which silicon must make scheduling decisions (at 800MHz, that's 1.25 nanoseconds), compiler time seems infinite.

Granted, compiler time is not infinite, but for performance-critical applications, it is quite large. The Texas Instruments TMS320C6000-family of DSPs, for instance, rely on compilers and assembly optimizers in order to eek out that last bit of performance, and as any DSP engineer will likely tell you, its usually worth it. Cycles saved in one loop are cycles that can be spent elsewhere on value-added features, leading to a more valuable product.

This points to the real fundamental problem as I see it, which is that the current VLIW darling in the industry is in the embedded world. Why should that make a difference, you ask? Because the embedded developer is the one most likely to take advantage of the raw capability that an exposed parallelism architecture can provide.

Merced's biggest problem lying ahead is the fact that workstation-class code does not naturally exhibit large amounts of parallelism. While I was attending MICRO-31, I heard someone remark about how most code looks like a series of 5-10 instruction bursts followed by a jump. ICK!!

Embedded programmers generally seem willing to learn whatever it takes to get their product running in the fewest MIPS (so that they can either use cheaper parts or provide more features), and so are often willing to jump through a few hoops to help out the compiler in order to get the parallelism they desire.

Workstation programmers, on the other hand, are interested in the much bigger picture (since their applications are much larger and tend to have larger life expectancies), and so code tends to be human-friendly and not compiler friendly. (Certain heavily-traveled code paths in the Linux kernel being a noteworthy exception.)

The point is that the Merced compiler will ship with alot of amazing compiler transformations, but very few of them will be effective at translating the hopping, skipping, and jumping nature of your typical general-purpose database-ish looking code into highly parallel performance-oozing EPIC instructions, at least straight out of the gate.

Merced will inherently provide big performance wins to the compute-farm customers (your big engineering shops that currently use networks full of Sun or HP workstations to crunch VHDL, Spice, or whatever simulations around the clock), as these applications end up reducing to huge matrix manipulations and numeric crunching galore -- oozing with parallelism. But Merced will be hard pressed to feed up web pages or database queries much faster than any other architecture, unless it's able to massively crank its clock rate due to losing the shackles of the instruction scheduling hardware.

Anyway, those compiler nuts in the crowd might find the following links useful and informative.

• The Rocket Project -- ILP research at Michigan Tech University
• VLIW Architectures -- a description of VLIW that's part of a larger presentation about VLIW compiler techniques.
• The Trimaran Research Compiler -- HP's research compiler that was supposedly used in development of the architecture that begat Merced.
• EE Times -- article which describes the release of Trimaran and includes a diagram showing the relationship of architectures from Superscalar to VLIW/EPIC to TTA.

I knew I'd seen this name before, TI has a copyright C++ development library called COOL. Hmm... I guess Microsoft will handing out some $$$ again.

ftp://ftp.ti.com/pub/COOL.tar.Z