Why not just have people on every server split their bills up each month by processor time/bandwidth used by each person accessing the server, then send them a bill when their total reaches $20 or so. (adjusted a bit to compensate for people who never get that much)
That's what people really want (with a bit of profit on the side, of course), but no matter what you do, it's a nightmare to keep track of (thus adding to the cost) and will fail anyway unless everyone jumps on board. It's also pretty much impossible to prevent abuses, on either end.
I know, what is this guy, 12? I mean if the "olden days" was a year or two ago...
Besides, all the chip companies have to do to get massive overclocking is to underrate the chips. If intel had properly rated their Celerons rather than marking them down to fill the marketplace you wouldn't have had that huge gain.
Yeah right, how many discs before they claim your laptop is defective and tell you to get lost? Oh sure, bring in another CD that plays fine, if they can whip out a player that works with the "defective" CD you've lost. (sorta, you'll probly be able to go through a few CDs)
So how can a compiler be more accurate at run time? It's not there at run time!
No, but it could run/emulate the code to profile it while compiling. Not likely, but possible. (and not quite as good since you wouldn't have actual input values, but simulated values can be used)
Unrolling a 100-iteration loop will have nearly the same drawbacks either way. When you unroll the loop has no effect on the size of the cache. Sure, you can make more intelligent decisions based on cache size, but I'd think the gain from that would be negligible. (If you've already unrolled 25 iterations, what percentage of the cycles do the loop instructions take?)
As for increased exe size/memory acess time, you'd probably be better off with a dumb compression algorithm. Something that takes very little time to decompress. (this could make loop unrolling very cheap)
I'll concede that there are optimizations that can only be done once you know the final system/user input, but a lot of the translation could be done by the compiler, and would result in faster execution time.
Re:PayPal. Nice idea, but it has it's problems.
on
The PayPal Phenomenon
·
· Score: 1
Similarly, I can only assume you're an arrogant bastard with no respect for others.
Regular compilers have more time, but they have neither the available memory nor the accurate statistics that a run time compiler/optimizer has.
Currently existing compilers, and statistics will always be more accurate for run time optimization, but who's to say some of that can't be done ahead of time?
And since when does anyone worry about larger exe files?
Crusoe does cool things because it runtime optimizes the code that it is morphing. If you were to run crusoe code natively, you'd no longer get the optimization benefits, and all you'd be left with is an even slower low-power chip.
Hmm, crusoe basically has a fast x86 to crusoe optimizing compiler built in. If you compiled to native crusoe ahead of time, you could spend more time on the optimization. (as I believe the crusoe does for instructions used more frequently)
Since a regular compiler compiling to native code has more time available, it is always possible to produce faster code with it. (more time to try/think about different optimization methods) Not to mention the question of whether or not you have to recompile next time you run the program.
Not that this means existing compiler techniques could necessarily do a better job (tho I would assume that's likely), but since you don't give any time limits, neither will I:)
There is a distinction to be made between passively letting someone die and actively causing them to die.
The problem isn't drug companies. If the drug companies are only interested in money, what's to stop others from giving them that money? What are you doing about it? What am I doing?
The problem isn't big faceless corporations, the problem is human nature. How do you propose to change human nature?
I know in the general case you need ions in the water, but does it really matter if the stuff with the electricity has lots of free particles laying around?
Re:No more 16-bit DOS code... again?
on
MS DOS: A Eulogy
·
· Score: 1
That's what I thought. So in other words, it's clever (but needs to RIP), but only about half of it's accurate at all.
With two reassamblations, code for the 4004 can be run on the P4.
Uh... So how do you assemble a piece of code more than once? You assemble it and get machine code, then...? Granted, we've probably got some degree of binary compatibility with the 8085, which is pretty sad, but you can't do that down to 4-bit, I mean you can't even operate on 4-bit numbers.
Re:No more 16-bit DOS code... again?
on
MS DOS: A Eulogy
·
· Score: 1
Maybe I'm just too young, but what 8-bit command line? (DOS was 16-bit) and what 4-bit processor? (how many of those did they even *make*?)
I mean it's cute and all, but it's rather stupid if it's not even true. (and it's getting just a tad old anyway)
And give the information! Don't make us email you for it.
That reminds me: The statistics for "Yahoo!" hosted web pages doesn't read the strings from some browsers correctly. Try to email them about it. You can't! (Or can you? I looked for quite a while...)
I suppose many large companies have found that if there's a webmaster link at the bottom of every page, people will email them about all their problems. The solution is not to remove that, but to add more. Maybe have a link that goes to a contact page with many specific and clear email addresses, but having no email contact addresses is like ripping your corporate eyeballs out.
No kidding, imagine what you could fit in that 256 MB with programs written for the "64k small"! After all, 64k is.024% of 256M! Now that's tiny!
And just cuz I have to mention it someplace in this article: Sweatbox Software once wrote a fairly well featured version of tetris for dos in 10k. Not that tetris is all that complex, but still.
I had a Genius mouse for about 10 years (secondhand!) before it started getting flaky. I guess they just made their hardware too good tho, I can't find their stuff in this country any more. Luckily the mouse/cutting pad still works, and it's much better than the stupid foam rubber ones that everyone gives you now.
I bought a Logitech mouse last year, left button died after a year and a half (under waranty, but a pain to return, tho I'll get to that sometime). Now I'm using a Kensington, feels nice, 5 year waranty, let's see how it lasts...
A smaller disc should be lighter, would be easier to spin, require less current, and so lead to a player with a longer battery life. (CD player battery life is pretty good, tho)
A smaller disc should also skip less (less mass, less distance per degree of jolt) so require less antiskip memory.
The discs are in a plastic case, this means that it's much harder to damage the media. (and it's likely it'll only be slot loaded, not top loaded)
Regular CDs are too large for my taste, although these are too small. I'd rather have something 2 to 3 inches across. (I want an 8cm CD MP3 player!)
Re:Pretty big quarters (elliptical media?)
on
Quarter-sized CD's?
·
· Score: 1
Look at the image in the article. The discs are about 1.125" across, circular, and encased in a slightly larger plastic case, which is 1.5" by 1.25"
Ok, put it this way: I might make enough money to justify paying the fees for this toolkit, I might not. There's no way to know until *after* I've developed and released it, at which point it's too late.
Now, I could assume I'll release it for free and just develop with QT, then decide after it's written if I want to pay the fees or not, (ie, if the program seems like it's worth something) but *my* opinion isn't what's important.
he other interesting point I'd like to bring up is: Fakes. How hard would these things be to fake? No matter how hard you try, someone with enough time and money will find a way to make a fake. I mean, there's high school kids with fake drivers licenses now.
Done properly, you'd have to fake the card *and* hack the database (which, if there's any sanity in the government, will not be connected to the internet). What happens when you've got a card with someone else's name, but the fingerprints don't match the database? Sure, you could always chop off their thumb and bring it with you, and doing both of these is just harder, not impossible, but it'll be a while.
Slashdot Mirror
Yeah, crazy idea.
Why not just have people on every server split their bills up each month by processor time/bandwidth used by each person accessing the server, then send them a bill when their total reaches $20 or so. (adjusted a bit to compensate for people who never get that much)
That's what people really want (with a bit of profit on the side, of course), but no matter what you do, it's a nightmare to keep track of (thus adding to the cost) and will fail anyway unless everyone jumps on board. It's also pretty much impossible to prevent abuses, on either end.
I know, what is this guy, 12? I mean if the "olden days" was a year or two ago...
Besides, all the chip companies have to do to get massive overclocking is to underrate the chips. If intel had properly rated their Celerons rather than marking them down to fill the marketplace you wouldn't have had that huge gain.
Yeah right, how many discs before they claim your laptop is defective and tell you to get lost? Oh sure, bring in another CD that plays fine, if they can whip out a player that works with the "defective" CD you've lost. (sorta, you'll probly be able to go through a few CDs)
aww, what about the 150*2 ddr memory? Why don't they move to that?
Or does that have issues with the PCI bus?
you don't see people fighting over mastercraft vs black and decker when they come to buy a screwdriver
That's because they all know DeWalt is the best! ;)
(Trust me, people do fight over power tool brands
Give people a choice, they'll make one and defend it, often just because they just don't want to admit they're wrong.
So how can a compiler be more accurate at run time? It's not there at run time!
No, but it could run/emulate the code to profile it while compiling. Not likely, but possible. (and not quite as good since you wouldn't have actual input values, but simulated values can be used)
Unrolling a 100-iteration loop will have nearly the same drawbacks either way. When you unroll the loop has no effect on the size of the cache. Sure, you can make more intelligent decisions based on cache size, but I'd think the gain from that would be negligible. (If you've already unrolled 25 iterations, what percentage of the cycles do the loop instructions take?)
As for increased exe size/memory acess time, you'd probably be better off with a dumb compression algorithm. Something that takes very little time to decompress. (this could make loop unrolling very cheap)
I'll concede that there are optimizations that can only be done once you know the final system/user input, but a lot of the translation could be done by the compiler, and would result in faster execution time.
Similarly, I can only assume you're an arrogant bastard with no respect for others.
Regular compilers have more time, but they have neither the available memory nor the accurate statistics that a run time compiler/optimizer has.
Currently existing compilers, and statistics will always be more accurate for run time optimization, but who's to say some of that can't be done ahead of time?
And since when does anyone worry about larger exe files?
What about tux2? I think that was it "phase tree"/"tree phase" whatever it was... That sounded cool, is anybody still working on that?
Basically you don't need journalling because the fs is always consistant.
Crusoe does cool things because it runtime optimizes the code that it is morphing. If you were to run crusoe code natively, you'd no longer get the optimization benefits, and all you'd be left with is an even slower low-power chip.
Hmm, crusoe basically has a fast x86 to crusoe optimizing compiler built in. If you compiled to native crusoe ahead of time, you could spend more time on the optimization. (as I believe the crusoe does for instructions used more frequently)
Since a regular compiler compiling to native code has more time available, it is always possible to produce faster code with it. (more time to try/think about different optimization methods) Not to mention the question of whether or not you have to recompile next time you run the program.
Not that this means existing compiler techniques could necessarily do a better job (tho I would assume that's likely), but since you don't give any time limits, neither will I :)
There is a distinction to be made between passively letting someone die and actively causing them to die.
The problem isn't drug companies. If the drug companies are only interested in money, what's to stop others from giving them that money? What are you doing about it? What am I doing?
The problem isn't big faceless corporations, the problem is human nature. How do you propose to change human nature?
Does the dust on the mb count as impurities?
I know in the general case you need ions in the water, but does it really matter if the stuff with the electricity has lots of free particles laying around?
That's what I thought. So in other words, it's clever (but needs to RIP), but only about half of it's accurate at all.
With two reassamblations, code for the 4004 can be run on the P4.
Uh... So how do you assemble a piece of code more than once? You assemble it and get machine code, then...? Granted, we've probably got some degree of binary compatibility with the 8085, which is pretty sad, but you can't do that down to 4-bit, I mean you can't even operate on 4-bit numbers.
Maybe I'm just too young, but what 8-bit command line? (DOS was 16-bit) and what 4-bit processor? (how many of those did they even *make*?)
I mean it's cute and all, but it's rather stupid if it's not even true. (and it's getting just a tad old anyway)
Except, at least with win2k, it breaks if you try to do anything more complicated than that:
...
...
Files:
chicken-1234.txt
chicken-4567.txt
ren chicken-*.txt beef-*.txt
Files are now:
beef-en-1234.txt
beef-en-4567.txt
GRR!
And give the information! Don't make us email you for it.
That reminds me: The statistics for "Yahoo!" hosted web pages doesn't read the strings from some browsers correctly. Try to email them about it. You can't! (Or can you? I looked for quite a while...)
I suppose many large companies have found that if there's a webmaster link at the bottom of every page, people will email them about all their problems. The solution is not to remove that, but to add more. Maybe have a link that goes to a contact page with many specific and clear email addresses, but having no email contact addresses is like ripping your corporate eyeballs out.
No kidding, imagine what you could fit in that 256 MB with programs written for the "64k small"! After all, 64k is .024% of 256M! Now that's tiny!
And just cuz I have to mention it someplace in this article: Sweatbox Software once wrote a fairly well featured version of tetris for dos in 10k. Not that tetris is all that complex, but still.
I had a Genius mouse for about 10 years (secondhand!) before it started getting flaky. I guess they just made their hardware too good tho, I can't find their stuff in this country any more. Luckily the mouse/cutting pad still works, and it's much better than the stupid foam rubber ones that everyone gives you now.
I bought a Logitech mouse last year, left button died after a year and a half (under waranty, but a pain to return, tho I'll get to that sometime). Now I'm using a Kensington, feels nice, 5 year waranty, let's see how it lasts...
We just get sick of Marketing changing the product name every 6 months.
PC-60 midi-tower
Is it a mid-tower or a mini-tower? Or is it designed for musicians?
A smaller disc should be lighter, would be easier to spin, require less current, and so lead to a player with a longer battery life. (CD player battery life is pretty good, tho)
A smaller disc should also skip less (less mass, less distance per degree of jolt) so require less antiskip memory.
The discs are in a plastic case, this means that it's much harder to damage the media. (and it's likely it'll only be slot loaded, not top loaded)
Regular CDs are too large for my taste, although these are too small. I'd rather have something 2 to 3 inches across. (I want an 8cm CD MP3 player!)
Look at the image in the article. The discs are about 1.125" across, circular, and encased in a slightly larger plastic case, which is 1.5" by 1.25"
Ok, put it this way: I might make enough money to justify paying the fees for this toolkit, I might not. There's no way to know until *after* I've developed and released it, at which point it's too late.
Now, I could assume I'll release it for free and just develop with QT, then decide after it's written if I want to pay the fees or not, (ie, if the program seems like it's worth something) but *my* opinion isn't what's important.
he other interesting point I'd like to bring up is: Fakes. How hard would these things be to fake? No matter how hard you try, someone with enough time and money will find a way to make a fake. I mean, there's high school kids with fake drivers licenses now.
Done properly, you'd have to fake the card *and* hack the database (which, if there's any sanity in the government, will not be connected to the internet). What happens when you've got a card with someone else's name, but the fingerprints don't match the database? Sure, you could always chop off their thumb and bring it with you, and doing both of these is just harder, not impossible, but it'll be a while.
duh. That's where the "national database" comes in. You swipe the card, give them a print, and the computer pops up, "Hey, this guy's a terrorist!"