>This particular code example might be a bad one, >because the analysis that supports the author's >conclusion [slashdot.org] is omitted from the >article,
I agree (and with the rest).
>You're arguing about low-level implementation, >when the author was trying to make a point about >a high-level principle.
I'm arguing about this being used as an example 'look how silly the original programmer was', when in fact, this is a much more complicated issue than the paper makes it out to be. I don't argue with the rest of the paper - anything that aids in automatic bug discovery is a welcome addition in my book.
You are right about the kernel lock, but notice that the code gets and releases cam->busy_lock, which doesn't make sense to me if there really isn't anything else than can access cam at that point. If you can explain, please do so.
PS. I didn't find the quoted code from the paper in 2.4.1!? The code in that kernel is the same as the snippet you posted, and there the check does look redundant.
if (!cam || !cam->ops)
return -ENODEV;/* make this _really_ smp-safe */
if (down_interruptible(&cam->busy_lock))
return -EINTR;
if (!cam || !cam->ops)
return -ENODEV;
Their comment: 'We believe this could be indication of a novice programmer...blabla...shows poor grasp of the code'.
BZZZZZZZZZT
Nice try kids, but unlike you, this piece of code was probably written by an experienced guy that has actually written code for parallel systems before. Since it's tricky, you would be excused if not for the 'novice programmer' comment above and the fact that the code itself says it's there for SMP safety.
Here's a hint: UNTIL you acquire the lock on 'cam', any other process can change the value, including at the point BETWEEN the first check and the acquisation of the lock.
-- GCP
Re:Please, enough already: Check out the link!
on
Ogg/Vorbis on Palm OS
·
· Score: 5, Insightful
>So please no more of the "wow, decoding music >with a 33Mhz processor would never work," "wow, >I can hold two songs in my 8MB of RAM," etc., >etc. comments. You are right, the old Palms WILL >NEVER play music files; it is simply infeasible.
Actually, I'm not so convinced.
The older Palms had shitty sound hardware, but it is possible to play at least WAV files on them. The quality sucks major, but it works nevertheless.
Disk space is also not a problem. Standard Vorbis will get down to 8kbps, which put quite a bit of files in 8M. I have written prototypes of new Vorbis encoders that will go down to 4kbps mono with pretty acceptable quality. This gets you a full album in 2M. Three albums at least on a 8M Palm.
The big issue is the CPU. Old Palms have a 33Mhz 68k processor. All that I have seen could be overclocked without risk to at least 45Mhz, and since we're pushing the limits of the hardware anyway, let that make us our target.
The question is if a 45Mhz 68k can decode a 6-8khz sample rate mono Vorbis 1.0 file. We're not looking for full Vorbis 1.0 compatibility remember, we just want to play those files, which have significantly less hardware demands than for example an 128k stereo 44khz Ogg. Since we're not going to need 16bits output either, you can make compromises in the decoder trading quality for speed. I have no idea if it is possible to decode Vorbis in this conditions, but I certainly don't think the answer is an 'obviously not' and I am currently investigating it.
>I'd guess that libvorbis is better on Intel and >tremor is better on non-Intel x86 (due to the >relative strengths of different vendors),
Apparently, Tremor is faster on the K6. For the Pentium Pro and related architectures (P2/P3/Celeron), and the Athlon, the floating point decoder is faster.
>They can do this for any license, including one >where you only release binaries (I've seen at >least one instance where the only difference >between two programs is that one had the startup >messages patched to display a different message).
Doing the binary patch at least takes some effort. Changing a printf anyone can do.
This is why I avoid using the GPL as much as possible for my own work: if someone infringes upon it, they can just ignore your complaints and take an 'so sue me' attitude.
If you're a small developer and they're as resonably sized company, the prospect of shelling out bucks to stop them from copying something you don't make money off anyway is no good.
Being closed source doesn't protect your work from being copied, but it's at least a lot harder to rip it off and stick your name on it.
Re:Could Deep Junior be easily distributed?
on
Men vs. Machines
·
· Score: 1
>You neglect the possiblity of building a rather >huge database...one machine could do the simple >forking for a two-ply search, and then hand off the >work for plies three-and-four to other machines, >and infinitum.
This doesn't work due to the nature of the search algorithm used. The question was whether Deep Junior could be easily distributed. The answer is no. That doesn't mean you cannot try to make a distributed solver for chess in another way.
>real AI doesnt use trees (too many possibilities)
Define real AI then.
A chessplayer also explores a tree of variations in his head.
The difference is that they have much more selective heuristics (which moves not to look at) and usually a better esimatation of who is better (evaluation).
This is also exactly the area where computers have been making progress. More selectivity (so they can look deeper and at more crucial variations) and a better assesement of the board position.
This was played in the qualifying event for the Kramnik match. It's now more than a year ago I believe and Fritz won by half a point in a 24 game match or so.
In the latest World Computer Chess Championship (July 2002) Junior won in a tiebreak over Shredder.
Fritz did not even make the top 3. (They participated with the name Quest to limit their damages)
>The problem is that these machines are being >programmed to play against 1 opponent, and are >being fed data about that player's past games, >habits, techniques...
This gets posted at least 10 times a story like this hits/., and everybody keeps moaning it, but it's just patently false.
Programs like Fritz, Junior and even Deep Blue are tuned to perform as well as possible against a wide range of testing opponents or known testpositions.
You can't just feed the computer some games from it's future opponent and have it magically adapt itself to this. About the only thing that is done in reality is to have the computer play into an opening that it is know to play well. For a human vs computer match, this just means trying to get an open position where tactics become predominant over longtime strategy.
And that is independent of whether you're playing Kramnik, Kasparov, Anand. It's the same for any human opponent.
The predecessors of Deep Blue 2 (Deep Though, Deep Thought II, Deep Blue I) played public games which were available to Kasparov.
Deep Blue 2 was barely finished in time for the match, so they had simply nothing that they could give to Kasparov.
The whole fuzz about Deep Blue being specifically trained against Kasparov is nonsense. The machine played the best chess it could, regardless of the opponent. The only thing that was taylored was the opening book, which is nothing to complain about for Kasparov considering he is famous for doing the same.
Realistically, all of that was just whining by an poor loser. I wonder if he'll pull the same stint in the unlikely even Junior wins.
-- GCP
Re:Could Deep Junior be easily distributed?
on
Men vs. Machines
·
· Score: 1
>I have not paid any attention to this, but does >someone know whether it would be feasible to base a >massively distributed chess engine on the Deep >Junior basis
It's pretty much impossible. Latency is essential for parallel chess algorithms. Even using a cluster is already problematic.
>A better test would be to loop an encode. take a >piece and encode/decode/encode/decode this will >magnify the problems with the codec.
This isn't a valid way of comparing. The codecs are not designed to reencode music.
A codec may be perfectly transparent after a single encoding, and fall apart when comparing the second encoding with the original. (Think about this: the codec doesn't know what the _original_ signal was like when starting the second encode)
>I do not know why Vorbis tried to compress those >two so much more than the others.
Vorbis with the -q mode tries to maintain a certain quality level. The other codecs try to maintain a certain bitrate.
On an easy clip, Vorbis uses less bits because it can do so and keep reasonable quality. The other codecs use more bits because they try to reach the certain bitrate.
>I think, that for anyone who would actually be >interested in which codec does best on which >kind of music, it's a moot point, since by now >they delete anything below 128kbps on sight
>This is an interesting and relatively well done >test (although it appears that the listeners >knew which format they were listening to, so it >wasn't truly double-blind, and a anti-MS and pro- >Ogg bias can't be ruled out).
The test *was* double-blind. Some of the listeners had experience with some of the codecs involved, and were able to identify some codecs based on the flaws they heard.
>Basically, after the first listening, you have >already instinctively 'decided' how the sample >sounds.
If this were true, it would never have been possible to make conclusions with 95% certainty, and there would have been no correlation between the results of the listeners.
Both are false, and hence, your unsubtantiated claim.
>How many times were the tests repeated?
One test per listener per sample.
>Was there a control group?
There was a control group in the form of 'trusted' listeners also participating in the tests. The results were similar to the general ones.
>Also, there is no information on the sound >system used and no measurements on its effect on >the test.
If you had bothered to actually look, you would see that each tester used the system he generally uses to listen to music on his computer, whatever that was.
>My suspicion is, if the test were repeated, the >result would be completely different.
There is nothing that supports this claim and past tests contradict it.
>It sure does. This is a BIG problem with putting >Ogg Vorbis in devices - while all personal >computers these days have floating point, quite a >lot of embedded processors don't.
The example reference implementation does for ease of understanding, but you can do without just as well.
Slashdot Mirror
>This particular code example might be a bad one,
>because the analysis that supports the author's
>conclusion [slashdot.org] is omitted from the
>article,
I agree (and with the rest).
>You're arguing about low-level implementation,
>when the author was trying to make a point about
>a high-level principle.
I'm arguing about this being used as an example 'look how silly the original programmer was', when in fact, this is a much more complicated issue than the paper makes it out to be. I don't argue with the rest of the paper - anything that aids in automatic bug discovery is a welcome addition in my book.
--
GCP
You are right about the kernel lock, but notice that the code gets and releases cam->busy_lock, which doesn't make sense to me if there really isn't anything else than can access cam at that point. If you can explain, please do so.
PS. I didn't find the quoted code from the paper in 2.4.1!? The code in that kernel is the same as the snippet you posted, and there the check does look redundant.
--
GCP
>If they could acquire the lock, cam and cam->ops
>cannot be NULL due to the first check.
It *CAN* on an SMP machine, which is the whole point.
--
GCP
They made fools out of themselves with this one:
/* make this _really_ smp-safe */
if (!cam || !cam->ops)
return -ENODEV;
if (down_interruptible(&cam->busy_lock))
return -EINTR;
if (!cam || !cam->ops)
return -ENODEV;
Their comment: 'We believe this could be indication of a novice programmer...blabla...shows poor grasp of the code'.
BZZZZZZZZZT
Nice try kids, but unlike you, this piece of code was probably written by an experienced guy that has actually written code for parallel systems before. Since it's tricky, you would be excused if not for the 'novice programmer' comment above and the fact that the code itself says it's there for SMP safety.
Here's a hint: UNTIL you acquire the lock on 'cam', any other process can change the value, including at the point BETWEEN the first check and the acquisation of the lock.
--
GCP
>So please no more of the "wow, decoding music
>with a 33Mhz processor would never work," "wow,
>I can hold two songs in my 8MB of RAM," etc.,
>etc. comments. You are right, the old Palms WILL
>NEVER play music files; it is simply infeasible.
Actually, I'm not so convinced.
The older Palms had shitty sound hardware, but it is possible to play at least WAV files on them. The quality sucks major, but it works nevertheless.
Disk space is also not a problem. Standard Vorbis will get down to 8kbps, which put quite a bit of files in 8M. I have written prototypes of new Vorbis encoders that will go down to 4kbps mono with pretty acceptable quality. This gets you a full album in 2M. Three albums at least on a 8M Palm.
The big issue is the CPU. Old Palms have a 33Mhz 68k processor. All that I have seen could be overclocked without risk to at least 45Mhz, and since we're pushing the limits of the hardware anyway, let that make us our target.
The question is if a 45Mhz 68k can decode a 6-8khz sample rate mono Vorbis 1.0 file. We're not looking for full Vorbis 1.0 compatibility remember, we just want to play those files, which have significantly less hardware demands than for example an 128k stereo 44khz Ogg. Since we're not going to need 16bits output either, you can make compromises in the decoder trading quality for speed. I have no idea if it is possible to decode Vorbis in this conditions, but I certainly don't think the answer is an 'obviously not' and I am currently investigating it.
--
GCP
Not really. Older Palms can do as well, although the sound is crappy.
--
GCP
>I'd guess that libvorbis is better on Intel and
>tremor is better on non-Intel x86 (due to the
>relative strengths of different vendors),
Apparently, Tremor is faster on the K6. For the Pentium Pro and related architectures (P2/P3/Celeron), and the Athlon, the floating point decoder is faster.
--
GCP
>They can do this for any license, including one
>where you only release binaries (I've seen at
>least one instance where the only difference
>between two programs is that one had the startup
>messages patched to display a different message).
Doing the binary patch at least takes some effort. Changing a printf anyone can do.
--
GCP
This is why I avoid using the GPL as much as possible for my own work: if someone infringes upon it, they can just ignore your complaints and take an 'so sue me' attitude.
If you're a small developer and they're as resonably sized company, the prospect of shelling out bucks to stop them from copying something you don't make money off anyway is no good.
Being closed source doesn't protect your work from being copied, but it's at least a lot harder to rip it off and stick your name on it.
--
GCP
>You have this backwards. Because the GPL requires
>all code it associates with to also become GPL'ed,
>you can't simply take code from BSD.
*Completely* wrong. BSD is compatible with the GPL, so you can integerate BSD code into a GPL project without problems.
The reverse is not possible, because the GPL has additional restrictions over BSD code.
--
GCP
>Is anyone working on this?
They already exist a few months...
--
GCP
It can play Ogg Vorbis with tkcPlayer :) Wheeee!
--
GCP
>You neglect the possiblity of building a rather
>huge database...one machine could do the simple
>forking for a two-ply search, and then hand off the
>work for plies three-and-four to other machines,
>and infinitum.
This doesn't work due to the nature of the search algorithm used. The question was whether Deep Junior could be easily distributed. The answer is no. That doesn't mean you cannot try to make a distributed solver for chess in another way.
--
GCP
>real AI doesnt use trees (too many possibilities)
Define real AI then.
A chessplayer also explores a tree of variations in his head.
The difference is that they have much more selective heuristics (which moves not to look at) and usually a better esimatation of who is better (evaluation).
This is also exactly the area where computers have been making progress. More selectivity (so they can look deeper and at more crucial variations) and a better assesement of the board position.
--
GCP
This was played in the qualifying event for the Kramnik match. It's now more than a year ago I believe and Fritz won by half a point in a 24 game match or so.
In the latest World Computer Chess Championship (July 2002) Junior won in a tiebreak over Shredder.
Fritz did not even make the top 3. (They participated with the name Quest to limit their damages)
--
GCP
>The problem is that these machines are being
/., and everybody keeps moaning it, but it's just patently false.
>programmed to play against 1 opponent, and are
>being fed data about that player's past games,
>habits, techniques...
This gets posted at least 10 times a story like this hits
Programs like Fritz, Junior and even Deep Blue are tuned to perform as well as possible against a wide range of testing opponents or known testpositions.
You can't just feed the computer some games from it's future opponent and have it magically adapt itself to this. About the only thing that is done in reality is to have the computer play into an opening that it is know to play well. For a human vs computer match, this just means trying to get an open position where tactics become predominant over longtime strategy.
And that is independent of whether you're playing Kramnik, Kasparov, Anand. It's the same for any human opponent.
--
GCP
The predecessors of Deep Blue 2 (Deep Though, Deep Thought II, Deep Blue I) played public games which were available to Kasparov.
Deep Blue 2 was barely finished in time for the match, so they had simply nothing that they could give to Kasparov.
The whole fuzz about Deep Blue being specifically trained against Kasparov is nonsense. The machine played the best chess it could, regardless of the opponent. The only thing that was taylored was the opening book, which is nothing to complain about for Kasparov considering he is famous for doing the same.
Realistically, all of that was just whining by an poor loser. I wonder if he'll pull the same stint in the unlikely even Junior wins.
--
GCP
>I have not paid any attention to this, but does
>someone know whether it would be feasible to base a
>massively distributed chess engine on the Deep
>Junior basis
It's pretty much impossible. Latency is essential for parallel chess algorithms. Even using a cluster is already problematic.
--
GCP
>A better test would be to loop an encode. take a
>piece and encode/decode/encode/decode this will
>magnify the problems with the codec.
This isn't a valid way of comparing. The codecs are not designed to reencode music.
A codec may be perfectly transparent after a single encoding, and fall apart when comparing the second encoding with the original. (Think about this: the codec doesn't know what the _original_ signal was like when starting the second encode)
--
GCP
>I do not know why Vorbis tried to compress those
>two so much more than the others.
Vorbis with the -q mode tries to maintain a certain quality level. The other codecs try to maintain a certain bitrate.
On an easy clip, Vorbis uses less bits because it can do so and keep reasonable quality. The other codecs use more bits because they try to reach the certain bitrate.
--
GCP
>I think, that for anyone who would actually be
>interested in which codec does best on which
>kind of music, it's a moot point, since by now
>they delete anything below 128kbps on sight
One word: Streaming
--
GCP
>This is an interesting and relatively well done
>test (although it appears that the listeners
>knew which format they were listening to, so it
>wasn't truly double-blind, and a anti-MS and pro-
>Ogg bias can't be ruled out).
The test *was* double-blind. Some of the listeners had experience with some of the codecs involved, and were able to identify some codecs based on the flaws they heard.
--
GCP
>Basically, after the first listening, you have
>already instinctively 'decided' how the sample
>sounds.
If this were true, it would never have been possible to make conclusions with 95% certainty, and there would have been no correlation between the results of the listeners.
Both are false, and hence, your unsubtantiated claim.
>How many times were the tests repeated?
One test per listener per sample.
>Was there a control group?
There was a control group in the form of 'trusted' listeners also participating in the tests. The results were similar to the general ones.
>Also, there is no information on the sound
>system used and no measurements on its effect on
>the test.
If you had bothered to actually look, you would see that each tester used the system he generally uses to listen to music on his computer, whatever that was.
>My suspicion is, if the test were repeated, the
>result would be completely different.
There is nothing that supports this claim and past tests contradict it.
--
GCP
>Until a new study shows (with lots of people -
>it's hard to negotiate the personal preference
>differences in a small sample sizes)
If you had actually looked at the results, you would have seen that
a) the sample size was enough to draw 95% confidence level conclusions
b) CD audio _was_ included as a reference (5.0)
--
GCP
>It sure does. This is a BIG problem with putting
>Ogg Vorbis in devices - while all personal
>computers these days have floating point, quite a
>lot of embedded processors don't.
The example reference implementation does for ease of understanding, but you can do without just as well.
--
GCP