For the existing processes to continue they would need to be able to keep working without allocating any memory. That's feasible on a real-time OS, but on a general purpose OS at least some of the processes are going to become useless, even if they don't actually segfault. In that case it's better just to kill them off and free up the memory.
Actually i'd say it's better to tell the process it can't do what it asked. Return an ENOMEM to a brk or mmap. It's much better to know that there isn't enough memory at the point of allocation than at the point of usage. It's practically impossible to implement error handling in a user app when all you get is a SIGBUS at the point of accessing. I suppose you could use mlock() but you still have to deal with that SIGBUS somehow... and this only works for root apps.
There are systems where every app is controlled and written with non-overcommit in mind, and there's no reason Linux should intentionally ignore these possibilities.
In fact, the OOM killer blatantly does the wrong thing for an embedded device that I'm working on. There's a single process (apart from a custom init) which is the only userland allocator in the system, and it allocates pretty much all of memory (13-15MB out of 16MB). Trouble is the OOM handler quickly decides that this isn't OK and kills the process. Solution: comment out the OOM handler. Everybody's happy.
Re:So... how's the VM these days?
on
Linux Kernel 2.4.10
·
· Score: 2, Interesting
He knows what he's talking about. Even with overcommit_memory=0 the behaviour is still somewhat overcommit. "Turning overcommit off" just enables a check that any SINGLE allocation doesn't exceed available memory. This is fine except available memory == paged in memory. Easy example to kill a program:
256MB of RAM in machine...
Allocate 100 * 128MB using mmap. None of these ENOMEM.
Clear 100 * 128MB. Receive rather ungraceful SIGBUS.
XRender uses 24.8 fixed-point numbers. They give many arguments why (mostly for tranlational consistency), but I feel they may be mistaken. The main reason is that modern processors are highly optimized to handle fp anyway. Fixed point has annoying problems with the need to range-check everything.
Even on modern processors, it's still usually more efficient to handle integers than floating point. There are still a lot of processors in use which (quite sensibly) don't have floating point in hardware because of the cost and power draw. After all, any algorithm written to use floating point can be rewritten for integer with roughly the same performance.
It is a myth that floating point fixes range-check problems. Floating point still has range and truncation problems. A single precision float has only 24 bits of mantissa, which often means you can get worse precision by converting an integer algorithm to floating point if you're not careful about the magnitude of the numbers you're working with.
Basically, floating point is not the magic solution to range problems and the only excuses for its usage are either a) code which isn't time critical, b) code you can't be bothered to write properly, or c) functions which return or take values with huge ranges (greater than 2^64 magnitude between highest and lowest allowed values).
I've seen far too much code which proclaims something like "this is in floating point, so there's no problems with overflows" (a pentium-optimized FFT library springs to mind) but with absolutely no explanation as to why other than "it's floating point".
Switching is usually at around 100Hz. 100 * 3072 bytes = 300KB/sec. This is a relatively small cost and should hit L1 cache the vast majority of time. It does effectively knock 3KB out of the L1 cache.
I'd guess that the Itanium CPU has some scheme to reduce register swapping on context switching. I can instantly think of at least one way - having "dirty" bits for segments of the register set, so it can be broken into, say 32 register chunks. I'll have to grab the tech ref manual at some point.
This is the trouble with Ogg Vorbis. It isn't supported by these things. If they had rewriteable firmware, it would be possible to hack support into them, but as far as I know, not many of them do this.
There are two main reasons why Ogg Vorbis isn't used in hardware players yet:
1) There aren't any single chip decoders available.
2) If you used a powerful CPU instead of a decoder chip, there isn't an integer-only implementation.
Most hardware manufacturers are still hung up on using single chip decoders instead of doing the smart thing of putting a powerful embedded CPU into the box. This ultimately limits flexibility, and means they have to use a pathetic little micro controlling everything to offset the cost. Worse still, the decoder+micro combination often draws more power than an embedded CPU.
A good example of a powerful embedded CPU is a Cirrus 7212 ARM, which runs up to 74MHz. You'll find it in products such as the Creative Nomad and Rio Receiver. It's cheap, extremely powerful (mp3 takes about 30-40MHz), low on power draw, and has just about every hardware interface you could want built in.
However, you'll never see Ogg Vorbis in a consumer audio device until there's a integer-only version available. Very few embedded CPUs have floating point in hardware, and there's no chance it'll run real-time with emulation. The surprising thing is that integer-only versions of DSP code tend to be not only faster but also more accurate - it would be interesting to see how fast an x86 processor runs the integer version compared to floating point.
After many years of scientific research and development, Sound Alert Technology now owns the intellectual property rights to a revolutionary sound pattern, known as The Localizer, [...] This is better known as White Noise, or Directional Sound.
So, they've somehow managed to patent white noise? This is a VERY VERY old technology which people have known about probably for decades.
Broadband noise is good for localisation because it has a good immunity to multipath reflection of sound. Single frequencies can easily sound like they're coming from somewhere else because of wall reflections.
I can't find a patent number, so I can't look up the exact details. I should hope it's more than just a patent on "Method and apparatus for alerting people using white noise" - because that would just be dumb.
...At least when P2P means distributed data storage. My logic is simple if you take these examples:
1) Everyone has a high downstream:upstream ratio.
As a logical consequence, data is stored centrally on large server with large backbones. Everyone downloads from one or several major sites, upstream is used pretty much just for packet ACKs. The major servers need large amounts of long distance bandwidth, as do the ISPs the clients are using. This is the current state of affairs.
2) Everyone has lots of upstream (perhaps 1:1) and everyone has P2P software.
This means that there is a good chance a local peer will have a copy of data you want. The transfer would then take place over a small number of hops (perhaps they're even on the same ISP!) Long distance bandwidth is thus reduced as most transfers can be handled internally to the ISP.
The question is, which of examples 1 and 2 is the cheapest? Long distance links are expensive, and example 1 needs lots of bandwidth down long distances. Example 2 may require more bandwidth in total, but this is over short distances.
Well, you might say that "obviously less total bandwidth is cheaper." But think about the typical home network setup - 100mbit internal (local), 56kbit external (long distance). It's cheap because the high bandwidth carrying is short distance, and you'll be downloading once and copying between local computers.
My argument is that example 2 scales all the way to global, and the combination of P2P and greater upstream will in fact lower the cost to an ISP eventually.
The mouse pointer being "jumpy" is an artifact of aliasing. The position is being discretely sampled at intervals and displayed at those discrete positions, missing out all information on the path in between. At lower rates, you'll notice there are large gaps between cursor images when you move the mouse quickly.
In theory, the pixels between the old and new position need a proportion of the mouse image also applied to them, somewhat like a "speed blur". This need only be a subtle amount. This effect is in no way less correct than discrete jumps, and if anything it's technically a more correct representation of what's going on with mouse movement.
Simply increasing the mouse sampling rate will not cure the problem. You would need an infinite rate to fill all positions between jumps (although practically it'd probably be 1000Hz or something).
Thankfully caching is an integral part of most operating systems these days, so RAM disks are pretty much useless as "accelerators". At least in the case of Linux, multiple instances of the same memory or executable all point to the same physical memory, with some nifty copy-on-write (COW) tricks. This actually works faster than traditional caching in some (most) cases.
All a RAM disk does these days is deny any unused RAM disk space for usage by the system. The only possible reasons anyone would possibly want a RAM disk these days are:
- When your backing medium is removable/doesn't exist (e.g floppy root disks or diskless machines).
- When you absolutely must have a file's contents in memory for latency reasons, but there are others ways to guarentee this (use mlock() for instance).
In the example case of the 'trans-warp' Amiga, if the OS performed page caching and had enough RAM, it would never touch the hard drive after all pages were touched. The fact is the traditional use of RAM disks for acceleration is obsolete - page caching in the OS has replaced that.
The Solaris/tmp in RAM is a nice idea but it's questionable what the advantage is, seeing as it can get swapped to disk.
This holds only holds true up to a certain point. All things included, I think Z-Buffering (and friends) has complexity O(n) whereas tiling has complexity O(n log n), where n is number of polys. Yes, Z-Buffering takes longer in this case because of memory bandwidth constraints.
However, if the Z-Buffer renderer had higher memory bandwidth and fill rate, it would win out even in this pathological case. There's also a point where the number of polys would make the sorting algorithm used by tiling slower than the Z-Buffer renderer.
The true test is how it performs with the games it was designed for (or conversely, how well games designed for it perform). While tile based rendering has a band of price/performance where it performs well, it's always been at the low end of the market - and I'm including Dreamcast here. There's always a case for either renderer due to their different characteristics.
If you want very high poly counts, T&L and high fill rates seems to be the way to go.
As for Voodoo5-6000... I think they've got the fill rate vs poly count ratio wrong, unless 1600x1200 FSAA is your thing. Whatever happened to 3dfx providing the most cost effective option?
It's interesting how algorithms emerge for every combination of these factors:
In the days of 286s, some people came up with S-Buffering (segments of Z values) to get around the storage and computation problems of Z-Buffering and snail pace of poly sorting, when using medium poly counts. Plain poly sorting was used for low poly counts.
When memory got cheap and CPUs a bit faster, Z-Buffering met the demands of higher poly counts.
Then cheap 3D cards came along (for PCs) and Z-Buffering was an obvious win. Back in the days of the first 3DFX cards, memory far outpaced the renderer. There's a few exceptions which used tile rendering, and we all know what happened to those.
So now the renderer is exceeding the speed of memory again, and plain Z-Buffering is finally becoming less attractive. Note that Hyper-Z seems to only be a gain for scenes that exceed memory bandwidth, and for anything less it's the same speed as Z-Buffering.
I wonder if anyone will ever find a tile rendering hardware implementation which actually beats Z-Buffering (or derivations), when cost isn't an issue - so far it's always been a cost saving feature at the expense of performance.
If anyone knows of any other techniques for improving rendering performance, it'd make a good discussion.
Re:Here's how it's done (technical)
on
Focusing Audio
·
· Score: 1
Take two ultrasonic transducers, and modulate them so that the resulting interference (a difference signal) is the signal you want to reproduce.
This cannot produce signals below ultrasonic with conventional methods. If you sound them with different frequencies, you get those two frequencies and nothing else. If you introduce nonlinearity somewhere into the system, specifically when the signals multiply, only then do you get sum and difference allowing reproduction of lower frequencies. A linear system cannot do this.
Because most ultrasonic systems have a fixed carrier, you'll need to be able to do pulse width
modulation in order to get data in and out of the system. The easiest way to do this is to simply gate the carrier signal by finding the output of the modulator and inserting a nand gate or comparator to feed your PWM signal in.
Problem is the ultrasonic transducer can still only produce ultrasonics, even when the input is modulated. The article does mention they required transducers with greater bandwidth than usual. The key is not the use of ultrasonics - it's the nonlinearity. PWM modulation of a carrier would produce a typical square wave spectrum, which when modulated would produce a mess of audible difference frequencies. While you can correct for this, the amount of DSP required would be hideous. It's certainly not something you can build off the shelf with a couple of transducers and a book on signal processing.
The key component here is not addition of waves - it's multiplication and other nasty functions that nonlinearity is all about. Addition on its own simply won't work.
Re:Low frequency performance, impossible?
on
Focusing Audio
·
· Score: 1
The idea of the Audio Spotlight is that if you stand outside the beam, you don't hear anything. Another thought which comes to mind is this probably won't be true if the floor, ceiling or walls are reflective to sound, which means it'll never be confined to just the beam unless you put thick carpet on all surfaces.
The ear may not be able to pick out the direction of bass, but the point is that using a separate subwoofer defeats the point of having a spotlight of sound, as everyone outside the beam can still hear the sub. I only know of one subwoofer design which projects sound in tight beam, and that's a tube about 20ft long and 2ft wide with holes at intervals along its length with a speaker sealed inside one end, and the other free to air.
At a guess, modulating ultrasonics down to frequencies below 100Hz using non-linearity would involve serious wattage.
Low frequency performance, impossible?
on
Focusing Audio
·
· Score: 1
I've seen this demonstrated on Tomorrow's World (BBC series) about a year ago. The inventor quite flippantly commented that although it currently has no bass, they should be able to figure it out soon.
A simple law of speaker design is: 100Hz cutoff, 1 cu.ft volume, 100dB efficiency. If you want half the cutoff frequency, you need 8 times the volume, or you can trade off 9dB less efficiency. This is rather rough but it works for pretty much every speaker I've applied it to. If the Audio Spotlight is still subject to this law (I think it is), it would imply that getting below "a few 100Hz" would involve extreme efficiency losses or making it impractically large.
Producing a conventional small speaker capable of producing low frequencies at high efficiency is impossible. If you want lots of bass or lots of efficiency, it has to be big. Whether or not nonlinearity of air is a property that allows you to "cheat" is a good question, because the air no longer acts like ideal gas. The simple answer of coupling it with a separate sub would defeat the purpose as it would no longer be directional.
I'm interested to see if ultrasonics is the answer to the age old quest of compact bass reinforcement, but until that is demonstrated I doubt the practical use in hi-fi and PA systems.
The only way they can be absolutely certain that clients aren't doing bad calculations is if they know that every client that goes out is from their own thoroughly checked source code. Open sourcing the client and letting anyone submit data with unchecked clients would defeat the entire point of the project. Seeing as a message from space is rare enough as it is, I wouldn't risk a buggy client destroying data that might never come again.
Quite simply nobody has any respect for those who setup DVD encryption. The official reason from encryption is to stop duplication. This hasn't worked. Other 'unofficial' but blatantly obvious reasons are:
- To promote differential pricing between regions. - To create a closed group of manufacturers who are capable of producing DVD. - To have the ability to remove manufacturers from the allowed group. - To create a closed group of manufacturers capable of producing DVD players (and remove them at will).
What they have actually suceeded in doing is:
- Creating an industry in player chipping. - Creating an industry which sells massive amounts of region 1 discs to the rest of the world. - Ruined sales in countries not in region 1.
If it weren't for this encryption nonsense, we would have had DVD years earlier. In region 2, we get DVDs with barely any features, sometimes in the old dual sided (not dual layer) format and for double the cost of a region 1 disc. Not to mention the players are about 50-100% more expensive too.
No, I don't have any respect for the people who brought about DVD encryption, nor should anyone else.
Mindcraft seem to be saying that because they've rebenchmarked everything "fairly", their previous benchmark is vindicated. Doh? I'm sorry, Mindcraft, but your previous benchmark is just as completely rubbish as it always was regardless of all the spin put into this new one.
An important thing to remember is that a statistic is a representation of exactly the data you collect - in this case, it's representative of what you get when you benchmark an old Linux kernel against the latest NT server with hardware that Linux is known to not get the best out of (4 processors). The good thing is that now these results are known, something can be done about it.
I would enjoy Red Hat asking Mindcraft to rerun the benchmarks when these problems are addressed in the Linux kernel.
Problem is companies this big tend to forget that it's just a patent portfolio thing and actually try to enforce them. Take the example of Creative Labs a while back when they attempted to patent something to the words of "PCI sound" and started legal action with... pretty much everyone I think. Surprised they didn't try to sue Adaptec for allowing people to read audio off hard disks (or maybe they just didn't think of that one!)
As has already been mentioned in other posts, I don't think anyone will try to copy this solution anyway because it doesn't tackle the problem of latency, and as such it's inherently unscalable - a 4-way system at 40fps would have 100ms of latency, which would feel quite odd.
Luckily this one can be worked around unlike 3dfx's patent on a*x + b*y (in parallel).
"C. The frequency of alternating hand sequences is maximized and the frequency of same-finger typing is minimized."
As somebody who's been playing the piano for about 15 years I find it quite hard to believe that alternating hand sequences is the optimal typing pattern - it's one of the hardest things to do quickly!
Take for example typing the four keys on each hand in their natural resting position. You can probably type "asdf;lkj" about 4 times a second, but you'd be hard pressed to type "a;sldkfj" more than 1.5 times a second. This is why in all your early piano lessons you put those finger numbers over all the notes - you find the optimum pattern that flows easily (and usually sequentially) across fingers in the same hand.
Most articles of this type also assume a standard "touch typing" style. Touch typing may be the optimal pattern if your hands are to stay in the same position, but who says you have to keep your hands stationary? I tend to type with my hands drifting about the keyboard slightly depending on the sequence to be typed.
After trying Dvorak for a few months, I decided there was no way I could match the 150wpm that I currently manage with QWERTY. QWERTY suffers less from the alternating hands syndrome than Dvorak, and as such I'll be sticking with QWERTY. The one thing I can say for Dvorak is that it does put less strain on the hands overall.
Slashdot Mirror
Actually i'd say it's better to tell the process it can't do what it asked. Return an ENOMEM to a brk or mmap. It's much better to know that there isn't enough memory at the point of allocation than at the point of usage. It's practically impossible to implement error handling in a user app when all you get is a SIGBUS at the point of accessing. I suppose you could use mlock() but you still have to deal with that SIGBUS somehow... and this only works for root apps.
There are systems where every app is controlled and written with non-overcommit in mind, and there's no reason Linux should intentionally ignore these possibilities.
In fact, the OOM killer blatantly does the wrong thing for an embedded device that I'm working on. There's a single process (apart from a custom init) which is the only userland allocator in the system, and it allocates pretty much all of memory (13-15MB out of 16MB). Trouble is the OOM handler quickly decides that this isn't OK and kills the process. Solution: comment out the OOM handler. Everybody's happy.
He knows what he's talking about. Even with overcommit_memory=0 the behaviour is still somewhat overcommit. "Turning overcommit off" just enables a check that any SINGLE allocation doesn't exceed available memory. This is fine except available memory == paged in memory. Easy example to kill a program:
256MB of RAM in machine...
Allocate 100 * 128MB using mmap. None of these ENOMEM.
Clear 100 * 128MB. Receive rather ungraceful SIGBUS.
Even on modern processors, it's still usually more efficient to handle integers than floating point. There are still a lot of processors in use which (quite sensibly) don't have floating point in hardware because of the cost and power draw. After all, any algorithm written to use floating point can be rewritten for integer with roughly the same performance.
It is a myth that floating point fixes range-check problems. Floating point still has range and truncation problems. A single precision float has only 24 bits of mantissa, which often means you can get worse precision by converting an integer algorithm to floating point if you're not careful about the magnitude of the numbers you're working with.
Basically, floating point is not the magic solution to range problems and the only excuses for its usage are either a) code which isn't time critical, b) code you can't be bothered to write properly, or c) functions which return or take values with huge ranges (greater than 2^64 magnitude between highest and lowest allowed values).
I've seen far too much code which proclaims something like "this is in floating point, so there's no problems with overflows" (a pentium-optimized FFT library springs to mind) but with absolutely no explanation as to why other than "it's floating point".
Switching is usually at around 100Hz. 100 * 3072 bytes = 300KB/sec. This is a relatively small cost and should hit L1 cache the vast majority of time. It does effectively knock 3KB out of the L1 cache.
I'd guess that the Itanium CPU has some scheme to reduce register swapping on context switching. I can instantly think of at least one way - having "dirty" bits for segments of the register set, so it can be broken into, say 32 register chunks. I'll have to grab the tech ref manual at some point.
There are two main reasons why Ogg Vorbis isn't used in hardware players yet:
1) There aren't any single chip decoders available.
2) If you used a powerful CPU instead of a decoder chip, there isn't an integer-only implementation.
Most hardware manufacturers are still hung up on using single chip decoders instead of doing the smart thing of putting a powerful embedded CPU into the box. This ultimately limits flexibility, and means they have to use a pathetic little micro controlling everything to offset the cost. Worse still, the decoder+micro combination often draws more power than an embedded CPU.
A good example of a powerful embedded CPU is a Cirrus 7212 ARM, which runs up to 74MHz. You'll find it in products such as the Creative Nomad and Rio Receiver. It's cheap, extremely powerful (mp3 takes about 30-40MHz), low on power draw, and has just about every hardware interface you could want built in.
However, you'll never see Ogg Vorbis in a consumer audio device until there's a integer-only version available. Very few embedded CPUs have floating point in hardware, and there's no chance it'll run real-time with emulation. The surprising thing is that integer-only versions of DSP code tend to be not only faster but also more accurate - it would be interesting to see how fast an x86 processor runs the integer version compared to floating point.
So, they've somehow managed to patent white noise? This is a VERY VERY old technology which people have known about probably for decades.
Broadband noise is good for localisation because it has a good immunity to multipath reflection of sound. Single frequencies can easily sound like they're coming from somewhere else because of wall reflections.
I can't find a patent number, so I can't look up the exact details. I should hope it's more than just a patent on "Method and apparatus for alerting people using white noise" - because that would just be dumb.
1) Everyone has a high downstream:upstream ratio.
As a logical consequence, data is stored centrally on large server with large backbones. Everyone downloads from one or several major sites, upstream is used pretty much just for packet ACKs. The major servers need large amounts of long distance bandwidth, as do the ISPs the clients are using. This is the current state of affairs.
2) Everyone has lots of upstream (perhaps 1:1) and everyone has P2P software.
This means that there is a good chance a local peer will have a copy of data you want. The transfer would then take place over a small number of hops (perhaps they're even on the same ISP!) Long distance bandwidth is thus reduced as most transfers can be handled internally to the ISP.
The question is, which of examples 1 and 2 is the cheapest? Long distance links are expensive, and example 1 needs lots of bandwidth down long distances. Example 2 may require more bandwidth in total, but this is over short distances.
Well, you might say that "obviously less total bandwidth is cheaper." But think about the typical home network setup - 100mbit internal (local), 56kbit external (long distance). It's cheap because the high bandwidth carrying is short distance, and you'll be downloading once and copying between local computers.
My argument is that example 2 scales all the way to global, and the combination of P2P and greater upstream will in fact lower the cost to an ISP eventually.
The mouse pointer being "jumpy" is an artifact of aliasing. The position is being discretely sampled at intervals and displayed at those discrete positions, missing out all information on the path in between. At lower rates, you'll notice there are large gaps between cursor images when you move the mouse quickly.
In theory, the pixels between the old and new position need a proportion of the mouse image also applied to them, somewhat like a "speed blur". This need only be a subtle amount. This effect is in no way less correct than discrete jumps, and if anything it's technically a more correct representation of what's going on with mouse movement.
Simply increasing the mouse sampling rate will not cure the problem. You would need an infinite rate to fill all positions between jumps (although practically it'd probably be 1000Hz or something).
Thankfully caching is an integral part of most operating systems these days, so RAM disks are pretty much useless as "accelerators". At least in the case of Linux, multiple instances of the same memory or executable all point to the same physical memory, with some nifty copy-on-write (COW) tricks. This actually works faster than traditional caching in some (most) cases.
/tmp in RAM is a nice idea but it's questionable what the advantage is, seeing as it can get swapped to disk.
All a RAM disk does these days is deny any unused RAM disk space for usage by the system. The only possible reasons anyone would possibly want a RAM disk these days are:
- When your backing medium is removable/doesn't exist (e.g floppy root disks or diskless machines).
- When you absolutely must have a file's contents in memory for latency reasons, but there are others ways to guarentee this (use mlock() for instance).
In the example case of the 'trans-warp' Amiga, if the OS performed page caching and had enough RAM, it would never touch the hard drive after all pages were touched. The fact is the traditional use of RAM disks for acceleration is obsolete - page caching in the OS has replaced that.
The Solaris
This holds only holds true up to a certain point. All things included, I think Z-Buffering (and friends) has complexity O(n) whereas tiling has complexity O(n log n), where n is number of polys. Yes, Z-Buffering takes longer in this case because of memory bandwidth constraints.
However, if the Z-Buffer renderer had higher memory bandwidth and fill rate, it would win out even in this pathological case. There's also a point where the number of polys would make the sorting algorithm used by tiling slower than the Z-Buffer renderer.
The true test is how it performs with the games it was designed for (or conversely, how well games designed for it perform). While tile based rendering has a band of price/performance where it performs well, it's always been at the low end of the market - and I'm including Dreamcast here. There's always a case for either renderer due to their different characteristics.
If you want very high poly counts, T&L and high fill rates seems to be the way to go.
As for Voodoo5-6000... I think they've got the fill rate vs poly count ratio wrong, unless 1600x1200 FSAA is your thing. Whatever happened to 3dfx providing the most cost effective option?
It's interesting how algorithms emerge for every combination of these factors:
In the days of 286s, some people came up with S-Buffering (segments of Z values) to get around the storage and computation problems of Z-Buffering and snail pace of poly sorting, when using medium poly counts. Plain poly sorting was used for low poly counts.
When memory got cheap and CPUs a bit faster, Z-Buffering met the demands of higher poly counts.
Then cheap 3D cards came along (for PCs) and Z-Buffering was an obvious win. Back in the days of the first 3DFX cards, memory far outpaced the renderer. There's a few exceptions which used tile rendering, and we all know what happened to those.
So now the renderer is exceeding the speed of memory again, and plain Z-Buffering is finally becoming less attractive. Note that Hyper-Z seems to only be a gain for scenes that exceed memory bandwidth, and for anything less it's the same speed as Z-Buffering.
I wonder if anyone will ever find a tile rendering hardware implementation which actually beats Z-Buffering (or derivations), when cost isn't an issue - so far it's always been a cost saving feature at the expense of performance.
If anyone knows of any other techniques for improving rendering performance, it'd make a good discussion.
This cannot produce signals below ultrasonic with conventional methods. If you sound them with different frequencies, you get those two frequencies and nothing else. If you introduce nonlinearity somewhere into the system, specifically when the signals multiply, only then do you get sum and difference allowing reproduction of lower frequencies. A linear system cannot do this.
Because most ultrasonic systems have a fixed carrier, you'll need to be able to do pulse width modulation in order to get data in and out of the system. The easiest way to do this is to simply gate the carrier signal by finding the output of the modulator and inserting a nand gate or comparator to feed your PWM signal in.
Problem is the ultrasonic transducer can still only produce ultrasonics, even when the input is modulated. The article does mention they required transducers with greater bandwidth than usual. The key is not the use of ultrasonics - it's the nonlinearity. PWM modulation of a carrier would produce a typical square wave spectrum, which when modulated would produce a mess of audible difference frequencies. While you can correct for this, the amount of DSP required would be hideous. It's certainly not something you can build off the shelf with a couple of transducers and a book on signal processing.
The key component here is not addition of waves - it's multiplication and other nasty functions that nonlinearity is all about. Addition on its own simply won't work.
The ear may not be able to pick out the direction of bass, but the point is that using a separate subwoofer defeats the point of having a spotlight of sound, as everyone outside the beam can still hear the sub. I only know of one subwoofer design which projects sound in tight beam, and that's a tube about 20ft long and 2ft wide with holes at intervals along its length with a speaker sealed inside one end, and the other free to air.
At a guess, modulating ultrasonics down to frequencies below 100Hz using non-linearity would involve serious wattage.
A simple law of speaker design is: 100Hz cutoff, 1 cu.ft volume, 100dB efficiency. If you want half the cutoff frequency, you need 8 times the volume, or you can trade off 9dB less efficiency. This is rather rough but it works for pretty much every speaker I've applied it to. If the Audio Spotlight is still subject to this law (I think it is), it would imply that getting below "a few 100Hz" would involve extreme efficiency losses or making it impractically large.
Producing a conventional small speaker capable of producing low frequencies at high efficiency is impossible. If you want lots of bass or lots of efficiency, it has to be big. Whether or not nonlinearity of air is a property that allows you to "cheat" is a good question, because the air no longer acts like ideal gas. The simple answer of coupling it with a separate sub would defeat the purpose as it would no longer be directional.
I'm interested to see if ultrasonics is the answer to the age old quest of compact bass reinforcement, but until that is demonstrated I doubt the practical use in hi-fi and PA systems.
The only way they can be absolutely certain that clients aren't doing bad calculations is if they know that every client that goes out is from their own thoroughly checked source code. Open sourcing the client and letting anyone submit data with unchecked clients would defeat the entire point of the project. Seeing as a message from space is rare enough as it is, I wouldn't risk a buggy client destroying data that might never come again.
Quite simply nobody has any respect for those who setup DVD encryption. The official reason from encryption is to stop duplication. This hasn't worked. Other 'unofficial' but blatantly obvious reasons are:
- To promote differential pricing between regions.
- To create a closed group of manufacturers who are capable of producing DVD.
- To have the ability to remove manufacturers from the allowed group.
- To create a closed group of manufacturers capable of producing DVD players (and remove them at will).
What they have actually suceeded in doing is:
- Creating an industry in player chipping.
- Creating an industry which sells massive amounts of region 1 discs to the rest of the world.
- Ruined sales in countries not in region 1.
If it weren't for this encryption nonsense, we would have had DVD years earlier. In region 2, we get DVDs with barely any features, sometimes in the old dual sided (not dual layer) format and for double the cost of a region 1 disc. Not to mention the players are about 50-100% more expensive too.
No, I don't have any respect for the people who brought about DVD encryption, nor should anyone else.
Mindcraft seem to be saying that because they've rebenchmarked everything "fairly", their previous benchmark is vindicated. Doh? I'm sorry, Mindcraft, but your previous benchmark is just as completely rubbish as it always was regardless of all the spin put into this new one.
An important thing to remember is that a statistic is a representation of exactly the data you collect - in this case, it's representative of what you get when you benchmark an old Linux kernel against the latest NT server with hardware that Linux is known to not get the best out of (4 processors). The good thing is that now these results are known, something can be done about it.
I would enjoy Red Hat asking Mindcraft to rerun the benchmarks when these problems are addressed in the Linux kernel.
Problem is companies this big tend to forget that it's just a patent portfolio thing and actually try to enforce them. Take the example of Creative Labs a while back when they attempted to patent something to the words of "PCI sound" and started legal action with... pretty much everyone I think. Surprised they didn't try to sue Adaptec for allowing people to read audio off hard disks (or maybe they just didn't think of that one!)
As has already been mentioned in other posts, I don't think anyone will try to copy this solution anyway because it doesn't tackle the problem of latency, and as such it's inherently unscalable - a 4-way system at 40fps would have 100ms of latency, which would feel quite odd.
Luckily this one can be worked around unlike 3dfx's patent on a*x + b*y (in parallel).
"C. The frequency of alternating hand sequences is maximized and the frequency of same-finger typing is minimized."
As somebody who's been playing the piano for about 15 years I find it quite hard to believe that alternating hand sequences is the optimal typing pattern - it's one of the hardest things to do quickly!
Take for example typing the four keys on each hand in their natural resting position. You can probably type "asdf;lkj" about 4 times a second, but you'd be hard pressed to type "a;sldkfj" more than 1.5 times a second. This is why in all your early piano lessons you put those finger numbers over all the notes - you find the optimum pattern that flows easily (and usually sequentially) across fingers in the same hand.
Most articles of this type also assume a standard "touch typing" style. Touch typing may be the optimal pattern if your hands are to stay in the same position, but who says you have to keep your hands stationary? I tend to type with my hands drifting about the keyboard slightly depending on the sequence to be typed.
After trying Dvorak for a few months, I decided there was no way I could match the 150wpm that I currently manage with QWERTY. QWERTY suffers less from the alternating hands syndrome than Dvorak, and as such I'll be sticking with QWERTY. The one thing I can say for Dvorak is that it does put less strain on the hands overall.