I'm thinking that this is the right way to do it. 540 upsampled at twice the framerate wouldn't have any of the nasty de-interlacing artefacts you normally get when de-interlacing.
I think almost everyone will agree that carefully written C (or ++) is faster than pretty much anything out there, including OCaml.
I also (subjective statement warning) think most will agree that pretty much anything out there is easier to read / reason about / maintain than that C. Speed optimized C is rarely (tho not never) pretty.
OCaml's strength is that is is almost as fast as C, almost as pretty(*) as haskell, and scales to large projects fairly well.
I guess its true strength (IMHO) is that you can write 'dirty' ocaml for the criticial 10%, wrap that up in a nice interface, and access it from more idiomatic code, all without needing foreign functions and IDLs, and maintaining strong typing accross the application.
(*) I do agree about the surface syntax being ugly, but that's not what I mean.
I'm afraid no ones going to bother optimizing code until Moore's law runs up against some physical engineering walls.
And that is the right thing to do. It's probably cheaper for you the consumer (well, maybe not _you_, but the hypothetical windows user who buys COTS software) to buy a faster PC every so many years, than for the software vendors to spend emplyee-hours to make their snazzy software run well on old systems.
I'm sure M$ could have carefully coded Office XP (or whatever the current version is called) to run happily on a 486, but it would cost several K$ and be coming out sometime next decade.
It's fun to speculate that if Intel/AMD were forced to dramatically raise prices -- say that the next gen processor required an exorbitantly expensive substrate to manufacture -- that major software houses could be tempted to subsidize the costs, as it would still be cheaper than actually writing efficient software.
I _like_ that idea: have serveral magic wands active at the same time. To inhibit one wand, start another, in the region where you don't want the first to go.
Seems easier to just arrest the first person you come accross who's just under 7 feet tall, call it a day, get some good press for catching the bad-guy, and then go home and bed your wife.
I get this wrong EVERY SINGLE FUCKING TIME I upgrade. It's set in one of the many install-kernel scripts that are scattered seemingly randomly around the system.
Personally, the Manifold series was so bad that I vowed never to pay another dollar to him. Indeed, I want my money back for the last book in that series, where I was reduced to reading about pregnant gorillas.
So bad it tainted his good stuff (which he has written some, but earlier in his career)
a) win xp version is more optimized (spend more time optimizing the program used by 97% of your audience... heavens forbid)
or
b) win xp averages load over a longer period? both run a 100% when something can run; the question is over which period you average load when summarizing it as a simple number.
Re:Both statements are fine -- salt explained
on
SHA-1 Broken
·
· Score: 1
I thought most systems encrypted (password + salt) using the password as key, and stored the result in the passwd table.
This makes it easy to check for correct password (simply decrypt the stored string, check for same password), and relieves you of storing the salt anywhere. The salt is truly random.
What you should do is to whitelist everyone who has accessed it already -- this will no doubt include the offending deeplinker. Then when people start complaining to the deep linker about tubgirl or what not, they'll check and see nothing wrong. People will get upset that the deeplinker is both linking to a horrible image, AND denying it.
the linux kernel (and presumbaly the windows kernels as well) issue the hlt instruction when idle, which allows parts of the chip to power down, significantly reducing power and heat.
(some/all?) desktop P4s can also scale down clock cycles under software control, but that is significantly coarser grain than the hlt instruction. When it works, the hlt instruction should be sufficient to keep the cpu cool when not doing anything.
Of course, these recourses don't always work. My P4's fan is currently running very loud: I'm unsure whether the fan is on its last legs, or the CPU is erroneously not doing the hlt thing. Some suggestions are that SMP architectures hate hlt, and that hyperthreaded p4s are treated like SMPs. I'm still actively researching this. Anyone want to chime in?
Indeed, cat5 is pretty good quality stuff. Use it for the speaker cable, too! I bought a pair of ~$700 nucleus micro speakers, and the manufacturer's recommented cable looked an awful lot like repackaged cat 5: solid core narrow guage copper wire.
http://www.google.com/search?q=cat%205%20speaker%2 0cable
I'm thinking that this is the right way to do it. 540 upsampled at twice the framerate wouldn't have any of the nasty de-interlacing artefacts you normally get when de-interlacing.
You're comparing a cost to a rate?
How long were you going to run the systems for? OVer long enough a time frame, even a watt's difference will overcome any purchase price.
Just curious; how come there aren't any slot splitters? Fits into one ram slot on the mb, attach 2 sticks of ram to that?
The idea is obvious enough that there must be some technical reason why this doesn't exist.
JPG uses the YCrCb color space as well, by default at 4:2:2, which is also the resolution you get out of a bayer pattern in a digicam.
(or was it 4:2:0 you get out of a camera?)
Haskell's type classes are compatible with eager functional/imperative languages like ML
I seem to recall that someone tried a haskell compiler with a carefully broken strictness analyzer: it claimed that every function was strict.
Unfortunately, it didn't work, I think due to required laziness in the prelude. I don't recall it being impossible.
Would be a fun language to play with.
You might have to solve the problem differently
And therein lies the rub.
I think almost everyone will agree that carefully written C (or ++) is faster than pretty much anything out there, including OCaml.
I also (subjective statement warning) think most will agree that pretty much anything out there is easier to read / reason about / maintain than that C. Speed optimized C is rarely (tho not never) pretty.
OCaml's strength is that is is almost as fast as C, almost as pretty(*) as haskell, and scales to large projects fairly well.
I guess its true strength (IMHO) is that you can write 'dirty' ocaml for the criticial 10%, wrap that up in a nice interface, and access it from more idiomatic code, all without needing foreign functions and IDLs, and maintaining strong typing accross the application.
(*) I do agree about the surface syntax being ugly, but that's not what I mean.
how about intel's compiler?
Ignore parent post please.
I should have read linked article more closely.
it's not running the same algorithm
A good observation.
I'd recommend re-implementing the C++ algorithm in OCaml (it has classes and objects, after all), and then seeing if that is in the same ball park.
Then you can compare that to your purely functional version.
I'm afraid no ones going to bother optimizing code until Moore's law runs up against some physical engineering walls.
And that is the right thing to do. It's probably cheaper for you the consumer (well, maybe not _you_, but the hypothetical windows user who buys COTS software) to buy a faster PC every so many years, than for the software vendors to spend emplyee-hours to make their snazzy software run well on old systems.
I'm sure M$ could have carefully coded Office XP (or whatever the current version is called) to run happily on a 486, but it would cost several K$ and be coming out sometime next decade.
It's fun to speculate that if Intel/AMD were forced to dramatically raise prices -- say that the next gen processor required an exorbitantly expensive substrate to manufacture -- that major software houses could be tempted to subsidize the costs, as it would still be cheaper than actually writing efficient software.
I _like_ that idea: have serveral magic wands active at the same time. To inhibit one wand, start another, in the region where you don't want the first to go.
I have a couple of the samsung 160s. Cheap and silent.
As for reliability, don't know. Haven't died on me yet...
*knocks on wood*
I'm hoping the low noise and low heat implies that they won't wear out too quickly.
what _are_ the rules of salvage in space?
When does hubble become legal to grab by first-commers?
I dunno.
Seems easier to just arrest the first person you come accross who's just under 7 feet tall, call it a day, get some good press for catching the bad-guy, and then go home and bed your wife.
That's what we do with terrorists, isn't it?
I'm an idiot.
Surely, you must be joking, mr Feynman
was the correct title
You must be kidding, mr Feynman!
what a cock-up
Do the first root instead of the second.
I get this wrong EVERY SINGLE FUCKING TIME I upgrade. It's set in one of the many install-kernel scripts that are scattered seemingly randomly around the system.
How do other distros do it?
for some reason, red hat's label patch has not been included in the mainstream kernel.
IF you know which partition is your root, instead of having grub say
root=/dev/sda1
instead of
root=LABEL=/root
The use of initrd and LABEL= makes upgrading RH systems to mainline kernels more of a pain than it should be.
tastes are just that.
Personally, the Manifold series was so bad that I vowed never to pay another dollar to him. Indeed, I want my money back for the last book in that series, where I was reduced to reading about pregnant gorillas.
So bad it tainted his good stuff (which he has written some, but earlier in his career)
could it be that
a) win xp version is more optimized (spend more time optimizing the program used by 97% of your audience... heavens forbid)
or
b) win xp averages load over a longer period? both run a 100% when something can run; the question is over which period you average load when summarizing it as a simple number.
I thought most systems encrypted (password + salt) using the password as key, and stored the result in the passwd table.
This makes it easy to check for correct password (simply decrypt the stored string, check for same password), and relieves you of storing the salt anywhere. The salt is truly random.
What you should do is to whitelist everyone who has accessed it already -- this will no doubt include the offending deeplinker. Then when people start complaining to the deep linker about tubgirl or what not, they'll check and see nothing wrong. People will get upset that the deeplinker is both linking to a horrible image, AND denying it.
should be quite fun.
well,
the linux kernel (and presumbaly the windows kernels as well) issue the hlt instruction when idle, which allows parts of the chip to power down, significantly reducing power and heat.
(some/all?) desktop P4s can also scale down clock cycles under software control, but that is significantly coarser grain than the hlt instruction. When it works, the hlt instruction should be sufficient to keep the cpu cool when not doing anything.
Of course, these recourses don't always work. My P4's fan is currently running very loud: I'm unsure whether the fan is on its last legs, or the CPU is erroneously not doing the hlt thing. Some suggestions are that SMP architectures hate hlt, and that hyperthreaded p4s are treated like SMPs. I'm still actively researching this. Anyone want to chime in?
Indeed, cat5 is pretty good quality stuff. Use it for the speaker cable, too! I bought a pair of ~$700 nucleus micro speakers, and the manufacturer's recommented cable looked an awful lot like repackaged cat 5: solid core narrow guage copper wire. http://www.google.com/search?q=cat%205%20speaker%2 0cable
What does it store in the DB: just metadata, or the mp3s as well?