Maybe this is a silly question.. but why would you want to compile a kernel in 23 seconds? I mean, ok, it's cool and everything, but is there some hidden application of this that I'm not seeing?
I'll give you the benefit of the doubt and assume you're not just a trolling karma whore here. The answer is as obvious as always: faster is always better. If there's nothing which needed that speed, it's because it wasn't previously viable and nothing got written with it in mind. If every computer were this fast, it makes compiling huge projects viable on small workstations.
And here's a great example - where I work there are three things that reduce productivity because of technical bottlenecks:
Internet speed (both ways).
Waiting for CVS (we've got this down to less than a minute for the whole tree).
Compiling.
Of these, the major bottleneck is compiling. If it takes 30 seconds just to recompile a single source file and link everything, you end up writing and debugging code in "batch" fashion rather than in tiny increments. And it's 30 seconds where you're not doing anything except waiting for the results.
If I had a machine like this on my desk, I'd probably get twice as much work done.
Hmm, forgot about that one. Depending on the hardware, the multiply will end up single cycle because it'll early out after the first 8 bits of coefficient. I know recent ARM processors perform 12 bits per cycle, so you tune coefficients to be less than 4096. I think recent x86 processors are single cycle regardless of coefficient, possibly with some result latency.
This gets the job done in nearly the same time. It depends on the architecture and context I suppose. On ARM you get or+shift in one cycle so the above looks pretty much like the C code:
On x86 it takes a ton more instructions, so the multiply ends up better. It's a shame compilers can't spot these kinds of optimisations.
Of course, you shouldn't be storing to memory one byte at a time if you can pack the bytes into words and store words at a time. Modern x86's will merge writes for you but I'd guess at it not making the instruction scheduling any easier for the processor.
Besides, 64 bit operations are higher latency than 32 bit operations, and the cost of all of the shifting and masking to separate the results would be very high. It would be much faster to just do two separate 32 bit operations.
Is this actually true of the x86-64 instruction set? It would strike me as a very poor design if simple operations (add/sub/bitwise) took more than a single cycle, otherwise having 64 bit words would be rather pointless as you could do 64 bit operations just as fast in 32 bit. The only advantage would be larger register space.
I can't actually find any documentation of instruction timings on AMD's site or x86-64.org. I would guess that most instructions take the same time in 64 bit as 32 bit. The exceptions would be things like multiply/divide etc.
Ignore the other replies - it is possible to do this, and it definitely is a speed increase. See the example code below. You just have to be careful about the packing arrangement of data in each word, and the overlap when performing operations on them.
Multiplication is a bad example, but it is possible to multiply several numbers at the same time by one or more coefficients. This usually isn't worth it unless the numbers are very small compared to the word size - e.g 4 bits vs 32 bits.
However - there are a lot of operations which can be dramatically improved by packing data without any extra SIMD hardware. For example, you can perform some tricks with bit shifting to do pixel masking 32 bits (or 64!) at a time. You can do addition/subtraction trivially with the only thing to watch out for being the carry.
Whether it's worth it is a case-by-case decision. Sometimes the packing/unpacking/carry correction takes longer than the performance gain.
And here's an example where there's definitely a performance increase! I've used the code below to do motion blur in the past. It's slower than using MMX, but not by much. I wrote it so long ago I don't have any comparitive figures though.
unsigned in = *bufin++;
unsigned out = *bufout;
in &= mask1;
in >>= 2;
out &= mask2;
out >>= 1;
out += (out & mask2) >> 1;
*bufout++ = in + out;
}
The idea here is that the framebuffer persists the image. The input and output buffers are 8 bits per primary. Now, you could do this a single byte at a time, but that would suck for speed. Instead, 4 bytes are computed at once. The formula for each output byte is based on:
out = (out * 3 + in) / 4
This is actually performed here slightly less accurately:
out = out / 2 + out / 4 + in / 4
I remove some of the visible artifacts in practise by a post-processing stage where 1 bit of noise is added.
The bit masks are applied to prevent the shifts "leaking" into the next byte in the word. Now, on the topic of 64bit - the above can be performed on 64bit words with no performance loss. This means it goes twice as fast. Although you'd be silly to do this on an architecture with SIMD instructions designed to do exactly this job.
On architectures without SIMD, tricks like this can give you several times speed increase. If anyone's interested in any other tricks I can pull some code onto a web page somewhere.
In cases of exhaustive search, it is well known that parallelism reduces the total amount of work done, as poor solutions are abandoned with less processing.
But parallel machines can be simulated by sequential ones with the same amount of work done. Therefore any parallel algorithm can be done with the same amount of work on a sequential machine by simulating a parallel one.
But in terms of clock cycles, it's at most P (processors) times faster on a real parallel machine. Or am I missing something here?
It'll be a while. Not only is there a lack of demand for that level of power (at least in the mass market), but massively parallel programming is a bitch and a half.
There's always a demand for a higher level of power than before (insert 640k remark). Massively parallel programming is a bitch to program. Symmetric small scale parallel programming isn't a bitch to program. By symmetric I mean having an even load across processors, probably running the same section of algorithm. By small scale I mean 2-16 way or something.
CPU designers are already pushing for more complexity at programming or compile time because quite frankly there's far more improvement that can be done there than in the silicon. The advantage of symmetric multi-processors is that all (I say naively) the chip designer has to do is make a copy of the entire core. To the programmer, the architecture and means of optimization are very obvious. This is unlike the recently mentioned SMT where and architecture and hence optimization route isn't obvious at all.
Why do you need 2 procs to do parallel programming? That's what threads and preemptive multitasking are for. I know it's not 'true' multithreaded. Since only one thread is being executed at once, but it fairly close.
It's the "fairly close" bit which doesn't work. Take a parallel algorithm running on two threads on a single processor. It may take almost the same execution time as a sequential one. However, it's very difficult to tell whether it'll actually be any good on two processors.
Programming the compiler to automatically generate parallel code is a slightly questionable thing to do, seeing as it'll have to analyse your code on an algorithmic level to work out whether it's worth it. Sections of code would have to be rather small to work out inter-dependencies, which would then make the parallelism too fine grained to be efficient. Still, I've seen a few passable attempts at it - but most fail to get any increase in performance because of overhead associated with communication.
I'd advocate a "function level parallism" approach. Statement level is too fine grained and hence has too much overhead. Program level (forking/threading) splits execution very asymmetrically (e.g - one thread decodes mp3, one handles mouse movement). But writing whole functions in a parallel manner is "just right" in terms of processing symmetry, and matches all those algorithms in your text book.
Almost makes you wonder if we'll move away from the 'big CPU, big whack of RAM' model to the 'bunch of little bitty CPUs, each with their own whack of RAM, and they do their own thing' model.
Yeah, I've been wondering how long it'll take before increase in frequency becomes so difficult that people finally realise that fine grained parallelism is the only way to go. The vast majority of time consuming tasks could be made parallel. It's not as if parallel algorithms are a black art or anything - there's a lot of material on the subject available.
It's a shame dual processor systems cost so much more - otherwise people like me would grab one to try out ideas and write some parallel code. But because there's hardly any parallel code out there, nobody buys dual processor systems, and so no parallel code gets written:)
Music will eventually end up on DVD or DVD-like media - not that I'm implying video. There's already a lot of a music-with-video albums out on DVD. Take for example, Orbital: The Altogether. It's available in Region 2 only. This is ridiculous because it only limits sales and I believe they have a huge number of US fans. Although realistically I suspect all that's achieved is an increase in UK->US file sharing traffic.
I get the feeling that CD will be the last un-superficially-encrypted format. It still puzzles me why the content business is being so bloody minded here. Surely they are no worse off with a new format as unprotected as CD? Surely the problem (in both meanings) of copy protection is orthogonal to the problem of media capacity? Perhaps the media manufacturers should just create a simple format like CD only bigger, let everyone use it as they wish - and let the content business worry about how to pervert it in their own time.
And who would have thought that you can only buy Monty Python in Region 1 (US)? I think that fact alone negates any arguments for region coding:)
No, you are wrong. The instruction set is irrelevant. IA-32 is dynamically converted to a RISC-like language.
In theory. In real life no such compiler or dynamic translator exists that does a good job of this. In real life even an O(n^n) algorithmic time translator does not exist which does a job as perfect as you suggest, or at least hasn't been written yet.
If code translation in IA-32 is as good you say, then why do "Optimisation Guides" exist? Simple: because code translation is nowhere even near perfect. You still need a million and one hints and compile-time optimisations to get your code "near the metal" as far as efficiency goes.
What I suggest is that all that instead of piling an immense - and algorithmically intractable - amount of work into the hardware translator, it should be done at compile time, or perhaps even a software JIT. Adding SMT just makes optimisation even harder than before. In fact, it makes writing code with pipeline effects in mind completely impossible - so you will never be able to know if your hand crafted assembler will run well.
Whatever the solution, IA-32 is such a poor match for:
Recognising indepedent code sequences.
Optimising.
Translating.
Code density.
Parallelism.
... that it's a stupidly uphill battle to get it running efficiently. Especially in hardware.
DSP instruction sets are VLIW-like. So is the MMX extensions (sort of).
MMX is different to a lot of DSP instruction sets in that it's SIMD and not MIMD. In IA-64 the approach that's taken is specifying many explicitly independent instructions on independent data in a bundle. In MMX the approach is to specify a single (ordered) instruction with many explicity independent data words. One could argue that MIMD is far more expressive. But in practise SIMD takes far less silicon and therefore usually ends up far more efficient.
When it comes down to it, software dynamic code translators (or JIT) is pretty much the equaliser as far as instruction sets go. In theory. In practise, the input and output instruction sets are extremely important. A really crap architecture like x86 makes for a really hard job for the translator - and therefore your code runs slowly. Especially in a purely hardware translator. Theory makes the fatal flaw of assuming you have an unbounded amount of time in which to translate your arbitrary code to theoretically perfect target machine code. Hardware implementations have a few clocks before they stall the pipeline. Software implementation have a small ratio of execution to translation time before it impacts.
And then we have real-world P3 and P4 architectures:
Dynamic register renaming and memory reference renaming is by no means perfect. In fact, you have to "hint" to the processor about free registers by writing zeros.
Memory writes still go out in order and analysis is not very comprehensive.
Branches are not analysed on the algorithmic level, they are translated wholesale. A simple loop will not be loop unrolled, for instance.
You could probably ditch 25% of an Athlon/P4 if you got rid of IA-32 and invented an input instruction set which was a better match for the target processor.
And yes, this is a very good idea. A modern superscaler out-of-order processor, like the Athlon and Pentium Pro (and later), can issue and retire multiple instructions per clock cycle. However, it can *only* do this if there is enough instruction-level parallelism (ILP).
The solution to a lack of ILP is to fix the instruction set. Personally I think of SMT as an extremely inefficient way to keep execution units filled. The x86 instruction set has very little in the way of implicit parallelism - or at least it's very hard to work out what's interdependent. You get your ILP in SMT basically because the two threads of execution have few dependencies on each other.
The bottleneck in x86 is definitely issuing instructions to execution units. But SMT only helps because the instruction set is poor to begin with. I'd go as far as say that SMT wouldn't be worth the effort on any decent architecture. Not that DSPs are decent - but some DSPs have parallelism built into every instruction to the extent that you basically specify what to do with every execution unit.
SMT makes more efficient use of execution units, but that's only because the number of execution units per thread has now been halved. In essense, it's artificially made the execution units the bottleneck instead of instruction issue. You have to ask yourself whether unfilled execution units is actually a bad thing when there's so many other areas in a processor which could be "optimised". I get the feeling that "unfilled execution units" is the next Intel marketing tool rather like clock speed is. It's questionable whether this slight increase in efficiency outweighs the loss in cache, memory bandwidth per thread and branch prediction. And there's the question of whether the amount of silicon this takes could have been better used in another way.
Turns out, there is not enough ILP in current programs to take full advantage of the chips processing capabilities.
And this is where it all falls down, really. It is very hard to write efficient parallel algorithms on real world processors. It's even harder to make a parallel algorithm efficient on SMT because the two threads of execution aren't really 100% independent. I suspect most people will decide not to bother writing for SMT because the development effort far outweighs the potential gains.
TI recognises that ARM does a much better job as a GPP (General Purpose Processor) than any DSP, and also that its customers want ARM. Bundling the two means that there is less memory and power required to run the devices.
Well, bundling just one core which is efficient at both (not unreasonable) would be more efficient on memory and power. Being good at DSP doesn't mean you can't be good at being a GPP (and vice versa). Most DSPs are bad at being GPPs because they have weird word sizes (like 24 bit) or weird memory architecture (program/X/Y RAM, no byte access), or blatant limitations (fixed size hardware stacks).
I suspect the reason for going with ARM is to do with development effort. There's already tons of software written for ARM processors. And if you run Linux (or Windows CE) on it, you've got support for pretty much every device you can think of out-of-the-box. And all that code you wrote one day for a PC or other similar architecture in C will "just work" on it too. I guess there must also be a ton of software already written for existing TI DSPs - and that can all get reused.
The thing which is different about OMAP and XScale, among others, is not that they have "DSP Features," but that they have a complete DSP on-chip
From what I've read the XScale doesn't have a "DSP" as such on-chip. It implements ARM9 style 2x16bit SIMD operations, but they also bolted on a separate multiply-accumulate unit which can run concurrently to everything else. However, execution is issued from the same pipeline as everything else so it's not exactly concurrent and it's also (strangely) not single cycle. As far as I can tell it's only just faster than doing MACs without it. Perhaps I'm missing something:)
hmm, and i thought that intel owns all ARM's patents. So ARM = intel infact.
The StrongARM was actually designed by Digital, not Intel. Intel bought up StrongARM along with Digital, but they didn't get the core patents with it. ARM is making quite a mint out of licensing their cores.
TI has been one of ARM's rivals in the DSP business. I suppose this means TI has given up, now. The fun thing about ARM cores is they're pretty much as powerful as DSPs at an equivalent cost, even though they implement an easy to program architecture. I guess the DSP manufacturers are learning the hard way about how important ease of development is these days.
They'll produce an IE-less Windows, and an installer for IE. They'll demonstrate it in court. It'll work fine. It will turn out to not be all that hard.
It'll probably take (very optimistically) months to get anywhere near completion. And there are so many ways in which Microsoft can delay progress here still - like making the source distribution somehow "incomplete" or lacking polish to the build process. It reminds me of the ISO distributions of MPEG decoders, which are rather like token efforts and either don't work or just don't even build.
Even given an easily buildable distribution (which I'm sure they must have internally), it's still going to take ages to untangle everything. The fact of the matter is that this kind of module mingling is a demonstration of very poor programming practice. In the end it boils down to one of these possibilities:
IE is mingled because MS have an incompetent team of engineers. But of course, MS proclaims that it has the best engineering team in the world.
IE is mingled because it was written that way to start with and it's too difficult to untangle. Disproof: 98lite.
IE is mingled deliberately because it's easier to code. Fair enough, but it's bad programming practice. See first point.
IE is mingled deliberately to prevent untangling. If Microsoft hold that their engineering team is without equal, then logically it follows that this is the only possibility.
But back to my original point - the states being handed all this source code is all very well, but it's going to take a significant amount of time for them to get it working. And if it does take them a long time... then perhaps Microsoft will claim (proof by one statistic) that it wasn't actually easy.
This is not quite accurate. The original signal is not "required" to be band-limited. Rather, it is accepted that frequencies outside of your design bandwidth will not be captured.
Two of the other replies point out that this isn't quite right - the frequencies outside of nyquist just alias. However, this can actually be used to your advantage if you know that a signal lies within a narrow band of frequencies centered around a high frequency.
For example, you can perfectly sample a signal confined to 1.0-1.1MHz using a sampling rate of just 200kHz, instead of 2.2MHz. What's even more interesting is that you can play this 200kHz sample back and get the same signal in the 1.0-1.1MHz band you had originally, but along with aliases all over the rest of the spectrum. In this case, you need bandpass anti-aliasing filters and not lowpass bandlimiting ones.
The implication here is that given current capability to sample, if you apply the new technique, you can get a better image/audio recording using their technique, than you can using the current fixed sampling interval technique, making the image more vivid, or the musical recording more lifelike than current sampling provides.
48kHz 24 bit is all you need to generate a perfect reproduction of audio as far as the human ear is concerned. These days, audio in the pre-amplified stage is about as good as it's going to get, because it's already as good as the human ear.
Non-uniform sampling, if it really improves matters (which I doubt in the case of audio), can't improve on what's already perfect.
Just to emphasise: by perfect I mean the theory says that none of the distortions generated are even close to what a human ear can hear. This is also true in practice.
The StrongARM is just an ARM core, only built by Intel so that it runs at 200+ MHz. There might be some modifications or extensions to it, but I don't think so.
As another reply points out, the StrongARM core design was actually done by Digital. It's a far better core than, say, an ARM7TDMI, and faster in some ways than newer ARM9 cores.
It's basically an ARM7TDMI with a few improvements:
The pipeline depth is 5 instead of 4, so it can run at a somewhat higher lock (220MHz instead of 74MHz).
Digital managed to make branches take only 2 clock cycles instead of 3 - without the need for branch prediction.
The cache is a split code/data cache so data loads don't stall instruction loads.
You can perform arithmetic simultaneously to loads and multiplies (unlike ARM7).
If only desktop CPUs (read: Intel/AMD) were this simple and elegant in design.
The new X-Scale CPUs from Intel are ARM instruction set based, but bare little resemblence to any other ARM cores. They run potentially up to something like 700MHz with very little in the way of penalties for the extended pipeline. I get the impression sometimes that Intel/AMD CPUs would have an elegant design if it weren't for the shoddy instruction set.
Floating point is not a magic bullet which removes all requirement to actually look at the range/truncation issues.
Typically during an FFT, you need 16 bits plus an extra bit every stage, which is log2(points) stages. So a 1024 point fft would require 26 bits of accuracy, which would fit within a 32 bit integer.
On the other hand, a single precision float is 32 bits, but only 24 bits are used for mantissa.
Hands up everyone who can tell me where the rounding errors occur in the floating point algorithm. Now, hands up everyone who can tell me where the rounding errors are in the integer algorithm.
The point is, there are integer-only MP3 players, which happen to run extremely efficiently and with the same accuracy (or better) as the floating point ones.
It's one of the biggest myths that's going around today that floating point somehow has greater accuracy than fixed point. It only does in some very specific cases, which doesn't include pretty much any DSP algorithm. I blame Intel's marketing, personally:)
You may need the input from 1000+ cameras and 90MB/sec storage speed, but that doesn't mean that everything has to flow through just the one final system.
Why not instead split it into many mostly independent segments? If you have, say, 10 machines running 100+ cameras each, then you've instantly reduced the data rates by 10 times - 9MB/sec storage speed. And why not have each segment with its own tape rack backup system? You can get somebody to go around all the racks and collect the tapes at the end of the day. Much cheaper than a monster tape silo - and you can repair/replace a broken one without taking out every single camera.
The issue doesn't seem to be the viability of recording the input from 1000+ cameras, it's really about plowing all that data through one single device. My (admittedly amateur) advice would be: don't. You may even see an increase in the overall system's uptime if you nicely segment everything anyway. After all, a single point through which all data flows means that you have a single point through which everything can fail.
The Taleban decided to eradicate the poppy crop in Afghanistan because it was "inconsistent with Islamic principles." This year's poppy crop was, in fact, destroyed. The US Government, recognizing that there were plenty of already-poor poppy farmers who would be left with no livelihood, allocated ~40 Million USD in humanitarian aid, _specifically bypassing the Taleban._ Check out Sec. Powell's statement on the aid shipments, if you like; it's been posted on Everything2, and should be pretty easy to find if you poke around a bit.
It was very difficult to find any information regarding this last I looked (about a week ago). For a start, none of it was linked in any way from discussion of "supporters of terrorism".
The facts you bring here are from the "official" version of events. Officially, the US gave aid directly to the farmers who had their livelihood cut off. Officially, the Taleban destroyed their crops.
Unofficially, it's impossible to make sure that funds go to the people you intend. They get intercepted, extorted or otherwise leached out from the actual victims and taken away. This is what happens in Iraq when relief funds and food arrives - shortly after everyone from the UN leaves, all their supplies get snatched by the army, or even while they're still there.
And as for the crops, there were one or two fields which were destroyed for the cameras (cameras are illegal in Afghanistan strangely enough). They kept enough for state sanctioned sales. There's evidence of just how much opium is still grown in Afghanistan in the massive drug problems reported in the cities. The possibility that this is used as a means to control the population makes it all the more worrying.
Gee isn't sugar a drug? How come that isn't outlawed?
At least you see the point I'm making, then. Where's the arbitrary line drawn? The list of banned substances has more to do with unrelated historical acts than social issues. For example, hemp was banned primarily because it was competing with the production of paper using pulp - this has translated to a social issue pretty much through misinformation.
And why isn't alcohol banned? Again, it's to do with political agendas - which was the point I was trying to make to emphasise "the war on some terrorism". If it were truely the "war on terrorism" then the US should be cutting links with the IRA and sending troops into Ireland as well as bombing their own country.
As it stands, the "war on terrorism" is yet another example of politicians trampling over graves to further their own agendas. The lack of definitions of "terrorists" and "supporters" means it's pretty much a handy excuse to kick around anyone they don't like for a while.
I prefer calling it the "war on some drugs" - the drugs the current administration doesn't like for whatever reason. Tea, coffee, beer and cigarettes don't contain drugs apparently.
You could also more accurately call "the war on terrorism and supporters of terrorism" instead "the war on some terrorism and some supporters of terrorism". The US has been and still is a supporter of terrorism. Example 1: funding terrorists in Ireland. Example 2: giving the Taleban (about) $60m to "stop producing opium", which of course they didn't.
So, "the war on some drugs" is partially responsible for "the war on some terrorism and some supporters of terrorism". Evidently the US understands irony better than anyone else.
'If approved, the law would be enforceable under federal regulations and could dramatically alter the way system OEMs design and develop PCs, TVs, set-tops or other digital appliances with embedded microprocessors, according to industry sources familiar with the Hollings proposal. The motion-picture industry, with the Disney and Fox studios in the lead, backs the legislation.
From dictionary.com:
"greed (grd)
n. An excessive desire to acquire or possess more than what one needs or deserves, especially with respect to material wealth: "Many... attach to competition the stigma of selfish greed" (Henry Fawcett)."
The industry neither needs nor deserves such a wide sweeping and damaging act. Perhaps we need to remind our respective governments just how little the entertainment industry makes to the GDP of a country. Such small corporations should not be destroying the freedoms of everyone else.
"From our standpoint, we are designing the software for the 99 percent of the people who don't want to steal the music but instead (want to) use it for whatever means--for whatever personal use that's allowed by the artist and the record label."
This is like saying that a CCTV system is for monitoring the 99 percent of people that don't commit crimes. Utter nonsense.
There's only two explanations for repeated use of such obviously flawed logic - the CEO of SunnComm is either an idiot or a liar. I say both for thinking that it would pass anyone by without ringing alarm bells.
That's a pretty unusual situation, but maybe the answer is to make the OOM killer a configure option. I still think that for the general case the OOM killer is a good idea.
I agree that in the general case of a multi-process environment (your typical desktop), some sort of OOM killer is a good idea - even better would be quota controls and non-overcommit, with OOM as absolute last resort (root processes with priority). Having a configure option would end this subject of much debate:)
Slashdot Mirror
I'll give you the benefit of the doubt and assume you're not just a trolling karma whore here. The answer is as obvious as always: faster is always better. If there's nothing which needed that speed, it's because it wasn't previously viable and nothing got written with it in mind. If every computer were this fast, it makes compiling huge projects viable on small workstations.
And here's a great example - where I work there are three things that reduce productivity because of technical bottlenecks:
Of these, the major bottleneck is compiling. If it takes 30 seconds just to recompile a single source file and link everything, you end up writing and debugging code in "batch" fashion rather than in tiny increments. And it's 30 seconds where you're not doing anything except waiting for the results.
If I had a machine like this on my desk, I'd probably get twice as much work done.
Hmm, forgot about that one. Depending on the hardware, the multiply will end up single cycle because it'll early out after the first 8 bits of coefficient. I know recent ARM processors perform 12 bits per cycle, so you tune coefficients to be less than 4096. I think recent x86 processors are single cycle regardless of coefficient, possibly with some result latency.
...
Alternatively you could do:
unsigned inw; unsigned char *in;
inw = *in++;
inw |= inw << 8;
inw |= inw << 16;
This gets the job done in nearly the same time. It depends on the architecture and context I suppose. On ARM you get or+shift in one cycle so the above looks pretty much like the C code:
ldrb r0, [r1]
add r1, r1, #1
orr r0, r0, lsl#8
orr r0, r0, lsl#16
On x86 it takes a ton more instructions, so the multiply ends up better. It's a shame compilers can't spot these kinds of optimisations.
Of course, you shouldn't be storing to memory one byte at a time if you can pack the bytes into words and store words at a time. Modern x86's will merge writes for you but I'd guess at it not making the instruction scheduling any easier for the processor.
Is this actually true of the x86-64 instruction set? It would strike me as a very poor design if simple operations (add/sub/bitwise) took more than a single cycle, otherwise having 64 bit words would be rather pointless as you could do 64 bit operations just as fast in 32 bit. The only advantage would be larger register space.
I can't actually find any documentation of instruction timings on AMD's site or x86-64.org. I would guess that most instructions take the same time in 64 bit as 32 bit. The exceptions would be things like multiply/divide etc.
Multiplication is a bad example, but it is possible to multiply several numbers at the same time by one or more coefficients. This usually isn't worth it unless the numbers are very small compared to the word size - e.g 4 bits vs 32 bits.
However - there are a lot of operations which can be dramatically improved by packing data without any extra SIMD hardware. For example, you can perform some tricks with bit shifting to do pixel masking 32 bits (or 64!) at a time. You can do addition/subtraction trivially with the only thing to watch out for being the carry.
Whether it's worth it is a case-by-case decision. Sometimes the packing/unpacking/carry correction takes longer than the performance gain.
And here's an example where there's definitely a performance increase! I've used the code below to do motion blur in the past. It's slower than using MMX, but not by much. I wrote it so long ago I don't have any comparitive figures though.
The idea here is that the framebuffer persists the image. The input and output buffers are 8 bits per primary. Now, you could do this a single byte at a time, but that would suck for speed. Instead, 4 bytes are computed at once. The formula for each output byte is based on:
out = (out * 3 + in) / 4
This is actually performed here slightly less accurately:
out = out / 2 + out / 4 + in / 4
I remove some of the visible artifacts in practise by a post-processing stage where 1 bit of noise is added.
The bit masks are applied to prevent the shifts "leaking" into the next byte in the word. Now, on the topic of 64bit - the above can be performed on 64bit words with no performance loss. This means it goes twice as fast. Although you'd be silly to do this on an architecture with SIMD instructions designed to do exactly this job.
On architectures without SIMD, tricks like this can give you several times speed increase. If anyone's interested in any other tricks I can pull some code onto a web page somewhere.
But parallel machines can be simulated by sequential ones with the same amount of work done. Therefore any parallel algorithm can be done with the same amount of work on a sequential machine by simulating a parallel one.
But in terms of clock cycles, it's at most P (processors) times faster on a real parallel machine. Or am I missing something here?
There's always a demand for a higher level of power than before (insert 640k remark). Massively parallel programming is a bitch to program. Symmetric small scale parallel programming isn't a bitch to program. By symmetric I mean having an even load across processors, probably running the same section of algorithm. By small scale I mean 2-16 way or something.
CPU designers are already pushing for more complexity at programming or compile time because quite frankly there's far more improvement that can be done there than in the silicon. The advantage of symmetric multi-processors is that all (I say naively) the chip designer has to do is make a copy of the entire core. To the programmer, the architecture and means of optimization are very obvious. This is unlike the recently mentioned SMT where and architecture and hence optimization route isn't obvious at all.
It's the "fairly close" bit which doesn't work. Take a parallel algorithm running on two threads on a single processor. It may take almost the same execution time as a sequential one. However, it's very difficult to tell whether it'll actually be any good on two processors.
Programming the compiler to automatically generate parallel code is a slightly questionable thing to do, seeing as it'll have to analyse your code on an algorithmic level to work out whether it's worth it. Sections of code would have to be rather small to work out inter-dependencies, which would then make the parallelism too fine grained to be efficient. Still, I've seen a few passable attempts at it - but most fail to get any increase in performance because of overhead associated with communication.
I'd advocate a "function level parallism" approach. Statement level is too fine grained and hence has too much overhead. Program level (forking/threading) splits execution very asymmetrically (e.g - one thread decodes mp3, one handles mouse movement). But writing whole functions in a parallel manner is "just right" in terms of processing symmetry, and matches all those algorithms in your text book.
Yeah, I've been wondering how long it'll take before increase in frequency becomes so difficult that people finally realise that fine grained parallelism is the only way to go. The vast majority of time consuming tasks could be made parallel. It's not as if parallel algorithms are a black art or anything - there's a lot of material on the subject available.
It's a shame dual processor systems cost so much more - otherwise people like me would grab one to try out ideas and write some parallel code. But because there's hardly any parallel code out there, nobody buys dual processor systems, and so no parallel code gets written :)
Maybe I'll save up some more...
I get the feeling that CD will be the last un-superficially-encrypted format. It still puzzles me why the content business is being so bloody minded here. Surely they are no worse off with a new format as unprotected as CD? Surely the problem (in both meanings) of copy protection is orthogonal to the problem of media capacity? Perhaps the media manufacturers should just create a simple format like CD only bigger, let everyone use it as they wish - and let the content business worry about how to pervert it in their own time.
And who would have thought that you can only buy Monty Python in Region 1 (US)? I think that fact alone negates any arguments for region coding :)
In theory. In real life no such compiler or dynamic translator exists that does a good job of this. In real life even an O(n^n) algorithmic time translator does not exist which does a job as perfect as you suggest, or at least hasn't been written yet.
If code translation in IA-32 is as good you say, then why do "Optimisation Guides" exist? Simple: because code translation is nowhere even near perfect. You still need a million and one hints and compile-time optimisations to get your code "near the metal" as far as efficiency goes.
What I suggest is that all that instead of piling an immense - and algorithmically intractable - amount of work into the hardware translator, it should be done at compile time, or perhaps even a software JIT. Adding SMT just makes optimisation even harder than before. In fact, it makes writing code with pipeline effects in mind completely impossible - so you will never be able to know if your hand crafted assembler will run well.
Whatever the solution, IA-32 is such a poor match for:
DSP instruction sets are VLIW-like. So is the MMX extensions (sort of).
MMX is different to a lot of DSP instruction sets in that it's SIMD and not MIMD. In IA-64 the approach that's taken is specifying many explicitly independent instructions on independent data in a bundle. In MMX the approach is to specify a single (ordered) instruction with many explicity independent data words. One could argue that MIMD is far more expressive. But in practise SIMD takes far less silicon and therefore usually ends up far more efficient.
When it comes down to it, software dynamic code translators (or JIT) is pretty much the equaliser as far as instruction sets go. In theory. In practise, the input and output instruction sets are extremely important. A really crap architecture like x86 makes for a really hard job for the translator - and therefore your code runs slowly. Especially in a purely hardware translator. Theory makes the fatal flaw of assuming you have an unbounded amount of time in which to translate your arbitrary code to theoretically perfect target machine code. Hardware implementations have a few clocks before they stall the pipeline. Software implementation have a small ratio of execution to translation time before it impacts.
And then we have real-world P3 and P4 architectures:
You could probably ditch 25% of an Athlon/P4 if you got rid of IA-32 and invented an input instruction set which was a better match for the target processor.
The solution to a lack of ILP is to fix the instruction set. Personally I think of SMT as an extremely inefficient way to keep execution units filled. The x86 instruction set has very little in the way of implicit parallelism - or at least it's very hard to work out what's interdependent. You get your ILP in SMT basically because the two threads of execution have few dependencies on each other.
The bottleneck in x86 is definitely issuing instructions to execution units. But SMT only helps because the instruction set is poor to begin with. I'd go as far as say that SMT wouldn't be worth the effort on any decent architecture. Not that DSPs are decent - but some DSPs have parallelism built into every instruction to the extent that you basically specify what to do with every execution unit.
SMT makes more efficient use of execution units, but that's only because the number of execution units per thread has now been halved. In essense, it's artificially made the execution units the bottleneck instead of instruction issue. You have to ask yourself whether unfilled execution units is actually a bad thing when there's so many other areas in a processor which could be "optimised". I get the feeling that "unfilled execution units" is the next Intel marketing tool rather like clock speed is. It's questionable whether this slight increase in efficiency outweighs the loss in cache, memory bandwidth per thread and branch prediction. And there's the question of whether the amount of silicon this takes could have been better used in another way.
Turns out, there is not enough ILP in current programs to take full advantage of the chips processing capabilities.
And this is where it all falls down, really. It is very hard to write efficient parallel algorithms on real world processors. It's even harder to make a parallel algorithm efficient on SMT because the two threads of execution aren't really 100% independent. I suspect most people will decide not to bother writing for SMT because the development effort far outweighs the potential gains.
Well, bundling just one core which is efficient at both (not unreasonable) would be more efficient on memory and power. Being good at DSP doesn't mean you can't be good at being a GPP (and vice versa). Most DSPs are bad at being GPPs because they have weird word sizes (like 24 bit) or weird memory architecture (program/X/Y RAM, no byte access), or blatant limitations (fixed size hardware stacks).
I suspect the reason for going with ARM is to do with development effort. There's already tons of software written for ARM processors. And if you run Linux (or Windows CE) on it, you've got support for pretty much every device you can think of out-of-the-box. And all that code you wrote one day for a PC or other similar architecture in C will "just work" on it too. I guess there must also be a ton of software already written for existing TI DSPs - and that can all get reused.
The thing which is different about OMAP and XScale, among others, is not that they have "DSP Features," but that they have a complete DSP on-chip
From what I've read the XScale doesn't have a "DSP" as such on-chip. It implements ARM9 style 2x16bit SIMD operations, but they also bolted on a separate multiply-accumulate unit which can run concurrently to everything else. However, execution is issued from the same pipeline as everything else so it's not exactly concurrent and it's also (strangely) not single cycle. As far as I can tell it's only just faster than doing MACs without it. Perhaps I'm missing something :)
The StrongARM was actually designed by Digital, not Intel. Intel bought up StrongARM along with Digital, but they didn't get the core patents with it. ARM is making quite a mint out of licensing their cores.
TI has been one of ARM's rivals in the DSP business. I suppose this means TI has given up, now. The fun thing about ARM cores is they're pretty much as powerful as DSPs at an equivalent cost, even though they implement an easy to program architecture. I guess the DSP manufacturers are learning the hard way about how important ease of development is these days.
It'll probably take (very optimistically) months to get anywhere near completion. And there are so many ways in which Microsoft can delay progress here still - like making the source distribution somehow "incomplete" or lacking polish to the build process. It reminds me of the ISO distributions of MPEG decoders, which are rather like token efforts and either don't work or just don't even build.
Even given an easily buildable distribution (which I'm sure they must have internally), it's still going to take ages to untangle everything. The fact of the matter is that this kind of module mingling is a demonstration of very poor programming practice. In the end it boils down to one of these possibilities:
But back to my original point - the states being handed all this source code is all very well, but it's going to take a significant amount of time for them to get it working. And if it does take them a long time... then perhaps Microsoft will claim (proof by one statistic) that it wasn't actually easy.
Two of the other replies point out that this isn't quite right - the frequencies outside of nyquist just alias. However, this can actually be used to your advantage if you know that a signal lies within a narrow band of frequencies centered around a high frequency.
For example, you can perfectly sample a signal confined to 1.0-1.1MHz using a sampling rate of just 200kHz, instead of 2.2MHz. What's even more interesting is that you can play this 200kHz sample back and get the same signal in the 1.0-1.1MHz band you had originally, but along with aliases all over the rest of the spectrum. In this case, you need bandpass anti-aliasing filters and not lowpass bandlimiting ones.
48kHz 24 bit is all you need to generate a perfect reproduction of audio as far as the human ear is concerned. These days, audio in the pre-amplified stage is about as good as it's going to get, because it's already as good as the human ear.
Non-uniform sampling, if it really improves matters (which I doubt in the case of audio), can't improve on what's already perfect.
Just to emphasise: by perfect I mean the theory says that none of the distortions generated are even close to what a human ear can hear. This is also true in practice.
As another reply points out, the StrongARM core design was actually done by Digital. It's a far better core than, say, an ARM7TDMI, and faster in some ways than newer ARM9 cores.
It's basically an ARM7TDMI with a few improvements:
The pipeline depth is 5 instead of 4, so it can run at a somewhat higher lock (220MHz instead of 74MHz).
Digital managed to make branches take only 2 clock cycles instead of 3 - without the need for branch prediction.
The cache is a split code/data cache so data loads don't stall instruction loads.
You can perform arithmetic simultaneously to loads and multiplies (unlike ARM7).
If only desktop CPUs (read: Intel/AMD) were this simple and elegant in design.
The new X-Scale CPUs from Intel are ARM instruction set based, but bare little resemblence to any other ARM cores. They run potentially up to something like 700MHz with very little in the way of penalties for the extended pipeline. I get the impression sometimes that Intel/AMD CPUs would have an elegant design if it weren't for the shoddy instruction set.
Typically during an FFT, you need 16 bits plus an extra bit every stage, which is log2(points) stages. So a 1024 point fft would require 26 bits of accuracy, which would fit within a 32 bit integer.
On the other hand, a single precision float is 32 bits, but only 24 bits are used for mantissa.
Hands up everyone who can tell me where the rounding errors occur in the floating point algorithm. Now, hands up everyone who can tell me where the rounding errors are in the integer algorithm.
The point is, there are integer-only MP3 players, which happen to run extremely efficiently and with the same accuracy (or better) as the floating point ones.
It's one of the biggest myths that's going around today that floating point somehow has greater accuracy than fixed point. It only does in some very specific cases, which doesn't include pretty much any DSP algorithm. I blame Intel's marketing, personally :)
You may need the input from 1000+ cameras and 90MB/sec storage speed, but that doesn't mean that everything has to flow through just the one final system.
Why not instead split it into many mostly independent segments? If you have, say, 10 machines running 100+ cameras each, then you've instantly reduced the data rates by 10 times - 9MB/sec storage speed. And why not have each segment with its own tape rack backup system? You can get somebody to go around all the racks and collect the tapes at the end of the day. Much cheaper than a monster tape silo - and you can repair/replace a broken one without taking out every single camera.
The issue doesn't seem to be the viability of recording the input from 1000+ cameras, it's really about plowing all that data through one single device. My (admittedly amateur) advice would be: don't. You may even see an increase in the overall system's uptime if you nicely segment everything anyway. After all, a single point through which all data flows means that you have a single point through which everything can fail.
It was very difficult to find any information regarding this last I looked (about a week ago). For a start, none of it was linked in any way from discussion of "supporters of terrorism".
The facts you bring here are from the "official" version of events. Officially, the US gave aid directly to the farmers who had their livelihood cut off. Officially, the Taleban destroyed their crops.
Unofficially, it's impossible to make sure that funds go to the people you intend. They get intercepted, extorted or otherwise leached out from the actual victims and taken away. This is what happens in Iraq when relief funds and food arrives - shortly after everyone from the UN leaves, all their supplies get snatched by the army, or even while they're still there.
And as for the crops, there were one or two fields which were destroyed for the cameras (cameras are illegal in Afghanistan strangely enough). They kept enough for state sanctioned sales. There's evidence of just how much opium is still grown in Afghanistan in the massive drug problems reported in the cities. The possibility that this is used as a means to control the population makes it all the more worrying.
At least you see the point I'm making, then. Where's the arbitrary line drawn? The list of banned substances has more to do with unrelated historical acts than social issues. For example, hemp was banned primarily because it was competing with the production of paper using pulp - this has translated to a social issue pretty much through misinformation.
And why isn't alcohol banned? Again, it's to do with political agendas - which was the point I was trying to make to emphasise "the war on some terrorism". If it were truely the "war on terrorism" then the US should be cutting links with the IRA and sending troops into Ireland as well as bombing their own country.
As it stands, the "war on terrorism" is yet another example of politicians trampling over graves to further their own agendas. The lack of definitions of "terrorists" and "supporters" means it's pretty much a handy excuse to kick around anyone they don't like for a while.
I prefer calling it the "war on some drugs" - the drugs the current administration doesn't like for whatever reason. Tea, coffee, beer and cigarettes don't contain drugs apparently.
You could also more accurately call "the war on terrorism and supporters of terrorism" instead "the war on some terrorism and some supporters of terrorism". The US has been and still is a supporter of terrorism. Example 1: funding terrorists in Ireland. Example 2: giving the Taleban (about) $60m to "stop producing opium", which of course they didn't.
So, "the war on some drugs" is partially responsible for "the war on some terrorism and some supporters of terrorism". Evidently the US understands irony better than anyone else.
From dictionary.com:
"greed (grd)
n. An excessive desire to acquire or possess more than what one needs or deserves, especially with respect to material wealth: "Many... attach to competition the stigma of selfish greed" (Henry Fawcett)."
The industry neither needs nor deserves such a wide sweeping and damaging act. Perhaps we need to remind our respective governments just how little the entertainment industry makes to the GDP of a country. Such small corporations should not be destroying the freedoms of everyone else.
This is like saying that a CCTV system is for monitoring the 99 percent of people that don't commit crimes. Utter nonsense.
There's only two explanations for repeated use of such obviously flawed logic - the CEO of SunnComm is either an idiot or a liar. I say both for thinking that it would pass anyone by without ringing alarm bells.
I agree that in the general case of a multi-process environment (your typical desktop), some sort of OOM killer is a good idea - even better would be quota controls and non-overcommit, with OOM as absolute last resort (root processes with priority). Having a configure option would end this subject of much debate :)