The turbo button was very useful for gamers. Games back in those early days did not auto-adapt to different frame rates if more processing power was available. They expected 4.77mhz and a certain video RAM access speed. Change that in any way and the "time" in the game changed. Running your car racing game at 10mhz (turbo) instead of 4.77mhz meant that things happened twice as fast as they should have.

I used to flip in and out of turbo mode constantly on my old turbo XT clone...

I really thought your point was going to be about purposely slowing down software for whatever reason. The point of the turbo button was to slow down the computer as needed. Not to speed it up. It was actually misnamed.

I think it goes without saying that you want your software to run as fast as it can all the time. So unless you have a specific reason to want it to run slower then this whole post is really pointless.

It sounds like you had a blast from the past and you were thinking about the old turbo button. Instead of just producing a "hey, you guys remember the turbo button?" post you tried to come up with some analogy. The analogy simply doesn't work.

It's not the hardware, it's a network that is a bottleneck these days.

I saw an article that compared the performance of a 1986 Mac and a 2007 PC. For the most mundane tasks -- booting, launching Word, opening a file, doing a search and replace, etc. -- the old Mac was slightly faster. We've squandered most of the benefits of Moore's law on bloatware.

This reminds me of an old DOS screensaver I once had, "explosive.com" or something, which was some fireworks. I copied it over to my new Windows 95 PC and ran it, crickey those fireworks were launching and exploding fast!

And then there's the game Police Quest, which at last check still worked on XP. The character moved too fast on screen to be able play it properly. Move right and suddenly your at a far end of the map.

Is this some kind of indirect encouragement to overclock my work computer?

My first job was writing code for a system that took 12 hours to build. So we'd write code all day and it would build all night. Then we'd come in the next morning and start debugging. If, at 9:01, I found a bug, I'd note it on my printout and then I'd need to patch it to go on testing.

Of course, there was no assembler in the debugger so I would need to modify x86 hex directly. I'd need to find a place where I could insert a long jump to empty RAM, and then write my new code in hex, and then jump back. This would continue on until about 2pm. I'd take my printouts/notes to a VT100 and type in my changes. Repeat.

The biggest programming arguments were between the old guys who used nothing but fixed length arrays (which overflowed) and the 'new' guys who preferred linked lists (with pointers that sometimes got corrupted).

The longest patch I wrote was 2K bytes. I pretty much had that pocket x86 instruction book memorized. For a long time after that, when I wasn't sure of the syntax for something in C, I'd look at the assembly output to verify that I'd written the code correctly :-)

What's slowing me down?

People are listening to your last post and aren't optimizing their software ;-)

Actually I went from PHP to compiled software, and with programs with a reasonable size, while the compilation takes some time, the compile ends up saving me lots of time due to the type checking the languages I'm using employ.

I think of languages like PHP and perl, with less compile-time checks, as hurry up and fail languages. I've come to think of compile-time checks as a sweet mercy from god (or a vendor I suppose)

I agree with Matt. Plus this article doesn't really make sense; it's almost as if you quoted without reading.

"Hey guys, remember the turbo button? [quotes someone else explaining the point of the turbo button was a compatibility mode for certain software] It's funny, I always wanted it turned on! And even nowadays I wouldn't turn off the turbo for my computer! And I suspect other people also prefer fast computers! [quotes someone talking about Turbo Pascal, then applies emphasis as if what they were talking was somehow related to the turbo button]"

Just an additional (and more relevant aside), I think we all remember putting some old game on a new PC and going, "who put my avatar on crack" as he ran around the screen in fast motion.

When I originally heard that the problem was that the programmers assumed processor speed, it seemed incomprehensible to me that such a major assumption could have been made. Computers aren't going to get faster?

What other assumptions are we making? The year 2000 will never come. Now it's 2038 I believe. We'll never need more than a byte for a character. SMTP is a trusting protocol, etc. What are we doing today that will be blindingly obvious tomorrow?

I completely agree with the need for enough of the following

RAM
Processor speed

And it's amazing to me how many developers come back with a reply that they don't need 4 gigs ram and 2 will suffice. It's amazing that some developers think that having a slower laptop or desktop is completely fine and waiting for things to compile (lack of a 7200 rpm hard disk in a laptop), or waiting literally a total of many minutes a day to wait for things to load and launch is acceptable when developers are expected to produce at usually an unreasonable pace by most businesses these days.

Well, at least 3 gigs on an XP machine, but preferably 4+ on a 64-bit machine is ideal for any developer and costs the company measly amounts extra considering they pay developers good salaries to begin with.

The only thing I ever I remember having to use the turbo button for was to make our Packard Bell 486DX2/66 run slow enough for Tank Wars (http://en.wikipedia.org/wiki/Tank_Wars).

The only real use I remember was in Space Quest 1 to get through the cave with boiling acid. If I weren't running at 16mhz I'd have surely fried my pixelated Roger Wilco.

@Bill Pudim

Actually, it appears more like you _commented_ without reading... but anyways...

Oregon Trail was the only game I used the Turbo for, but I think it detected the speed, as the best way to run the game was to start the game with turbo, then turn it off when you hit the "trail".

This way I could finish the game in 5 minutes or so without having to stop for any supplies.

I remember batch compiles. I used to submit a compile, fix a couple errors or make some changes, and submit another compile about the time the first one was finishing. Then I'd go look at the output from the first compile and fix errors from that compile in the code I'd just submitted. Lather, rinse, repeat.

It sure wasn't the most efficient use of time, but it made me appreciate PC development when I made the switch.

Funny article. You can interpret it anyway you want ;-)

I think responsive software is overrated. Don't understand me wrong: I like my software being responsive. Google Chrome rocks. I also tell my co-workers how great VB6 was? Why? Just fire it up, and see how quick things run! That is a great difference to say Visual Studio 2008...

But the overrated part: I don't think (most) people are getting more productive with quicker reponsive programs. Responsive software is more about being spoiled (in a good way, that is). I feel good about Google Chrome, because it respons quick to my needs. But do I read more blogs? Do I answer more stackoverflow questions? Do I write more emails? You know the answer. I think that learning to type with ten fingers is more productive...

So my thinking of software responsiveness as being overrated is about productiveness. That's crap. But valueing your customers, by letting your software being responsive? That's more like it.

ultima 7 on a 486 definitely needed the turbo button :)

For me, it's slow network speeds that play with my emotions.

In addition to that, the worse status message on Earth tends to ruin my day: "Web site found. Waiting for reply..."

Wait. Are we supposed to have faster hardware or are we supposed to develop interactively (whatever that means)?

Or are we supposed to have faster hardware so we *can* develop interactively.

Is that a comparison to developing *blindly*? What does interactive mean?

I am a little lost on this one.

> Then I got Turbo Pascal and life was forever changed. I could write, compile and debug applications virtually instantly and my need for speed has never looked back.

If you still desire fast compile speed and native code, Delphi 2009 has it. Actually, so does Delphi 2007 and Delphi 2006. In case you are not familiar, Delphi is the successor to Turbo Pascal that writes native code for Windows. I love C#, but I just can't find a reason to stop using Delphi...it's awesome!

Yeah, right. We need faster computers to accomplish more "write-crappy-code -> compile-it -> see-it-doesnt-work -> tweak-crappy-code"-cycles per hour. Surely a very good investment to crank out more crappy software per hour.

Note: Proper design takes time, no matter how fast your hardware is.

But these days blazing fast stupidity seems to catch up with thinking much better.

Back when I was doing hardware for a living we found a mainboard that had a turbo button on a 286 machine which ran the AT bus @ 12MHz rather than 6 or 8. Very handy when stress testing and checking to see if your SBHE decode logic ran fast enough to decode in smaller than 128K lumps for memory access.

Worse slow down for me is faulty error messages from Sql Server 2000 nowadays. Sql Server 2000 just sucks when there is any kind of issue. It gives the wrong line numbers and misdiagnoses the cause of the issue constantly. Sql Server 2005 is a HUGE improvement since the CLR is hosted in the database engine so I can watch sprocs execute line by line. Much much better feedback to track down and fix errors.

What's keeping you from going as fast as you can? As a user? As a software developer?

The way I see it, nobody cares much about optimizing today, making pretty much everything slow and bloated. Songbird (the Mozilla Foundation media player) takes over 100 Mb for playing a 4-5 Mb song. Firefox used to kill my PC due to some "is not a memory leak, is a feature" bug. Eclipse (and pretty much everything Java) will laugh at you if you try to run it with 1 Gb or less.
The sad truth is: nobody cares about "fast" anymore. If your code runs in the span of a lifetime, then is good enough for everyone. True, you have gems like utorrent (6 Mb in memory), but if you mention it everyone will give you the "but our 250 Mb framework makes programming easier" talk and walk away. It doesn't seem to matter the fact that your 10-seconds function could take only 2, everyone is happy waiting those 10 seconds.
On the other hand, I do most of my web design in vim/notepad, so maybe I'm not the best one to talk about the efficiency/effort ratio...

Oh, the memories :-). I've had several computers with a Turbo button, and the only time you wanted to slow down the computer was playing games.

However, sometimes you actually improve usability by slowing down your application (on the ultra-fast, modern computers).

But it is a good thing that it is no longer the user that has to control this.

Hey, the turbo button still exists!

I have a laptop which is a few years old and it has a button that, for all intents and purposes, can be considered a turbo button. While it's purpose is now to save power, it's implementation is basically the same.

VB6 is way faster than Visual Studio 2008... It is like instant vs slow.

In high school (~'93) a friend of mine had his PC for a good year or so before he realized one day that the turbo button was off.

So, of course, he turned it on.

I guess that's ONE way to upgrade your machine cheaply. ;)

Only mildly related but you might get a kick out of it. A friend of ours about 10 years ago drove a pretty small oldish car (like a Chevy Sprint or something can't remember the exact model). We were driving through some hills in July and the car was a bit sluggish, so he as he pushed the button to turn off the A/C he said "turbo button". And the car sped up a bit. It was funny at the time, of course we were all EE's and CSci's in the car.

what's keeping me from going as fast as i can? a pentium 4.

What's keeping you from going as fast as you can? As a user? As a software developer?

The inabililty to put a 10,000 RPM 300GB WD Velociraptor drive into my Mac Pro. 150GB fits, 300GB doesn't :( (connector was moved 1/2 inch)

I think you've just made the argument for me on why I prefer vim and the linux command line over visual studio, even on modern PCs. I think its also why the command line still survives to this day as a viable development option despite tons of development in GUI/IDE development. Some would rather

For me, I feel so much more productive in vim/command line than in visual studio, and I spend less time dealing with visual studio crashing explorer or just waiting forever for some debug session to stop. ugh. Give me the linux command line any day. So much simpler, gets the job done, fewer do-dads to hog my PC's resources.

Sure if visual studio was as rock solid, fast, and stable as the linux command line I would trust it and I would be so much more productive. In many ways visual studio is a vastly superior tool. I mean I can rename variables in once click (with visual assist x) and the change propagates everywhere. That's cool! But search and replace isn't that much worse.

I'm in the minority here maybe, but I've found that being forced into a relatively slow development cycle can be beneficial on a large project, or one where the target application takes a long time to run ... it makes you think more about what you're doing.

However, this doesn't mean that you shouldn't have good tools on a responsive machine, that level of interaction is still important.

What's keeping me from going as fast as I can as a software developer? Reading your blog entries; they're too good!

Give a developer a slow machine, and save hundreds/thousands of users hours of waiting apiece.

Tell me about it...
http://stackoverflow.com/questions/354962/how-do-i-make-quartus-ii-compile-faster

My computer has two buttons: Turbo and Ultra-Turbo! (That makes it go to 11.)

From the codist:
>I could write code, compile it and run it at the same time.

>I could write, compile and debug applications virtually instantly

Surely he is some kind of god! We worship you, O Codist! Lo, let not your wrath fall upon our heads, for we are weak and mortal and sometimes it takes finite amounts of time for us to write even a 'Hello World' program!

Games for the most part don't use "speed detection" algorithms to slow the games down intentionally.... they use better techniques to manage what's going on over the course of a time line, animations for example simply transition over time mathematically.

Didn't you post an argument against optimising code just a few days ago? Just to throw more money at it, I think was your point.

Personally, I'd like to see hardware speeds hit a ceiling for 5-10 years before they pick up again.

What really irks me, performance wise, is every application's need (often due to their dependant libraries) to thrash the hard drive. Why is it that Firefox is an 8.5 meg download, yet the hard drive activity when launching it is roughly on par with copying a 100 Mb file? (Even with no cache or personal data.)

I'd LOVE to have five years of fixed-speed hardware, so that software learns how to be fast again.

I used the turbo button when I wanted to see what was happening while booting. If I had some kind of hardware crash I could see what things were loading and what was messed up. I think I was only 10years old at the time so I didn't really understand what I was doing and I'm not sure if it actually solved any problems but I remember it all non the less :)

I recall that Linus T. wrote 'git' so that code 'merges' ocurred near instantly...
would performance like he describes (merge rapidly and often) be enough to convince you to change your software version management software?

I read this blog while waiting for: VS to compile, TFS to get latest, tests to run. I would get 40% more done in a day if everything was instant. The 2 minutes I have to wait kills my productivity, my mind wanders and I get side tracked (like right now).

And its not like my machine is slow: quad core 3GHz, 8GB RAM, RAID-0. Most of my coworkers think I'm crazy when I complain about waiting 2 minutes for a compile. Anything longer than a few seconds is too long!

I had a 386/33MHz which could be overclocked to 40MHz by connecting 2 motherboard pins with a jumper. I connected these pins to the case's turbo button, an voila - a real Turbo button! I even hacked the 7-segment MHz display to show correct numbers.

I remember the game Test Drive running on our 8088. The car was simply not drivable without the Turbo OFF. It was too fast. Some games were CPU clock independent, and some others were CPU clock dependent.

Obviously, game programmers at Accolade got it wrong for Test Drive.

I can't really disagree with the idea that "developers need fast machines to be productive".

Of course I wish these same developers with very fast whiz bang
workstations would remember that the rest of us "users" probably do
not have the latest and greatest hardware at our fingertips.

Back in college (early 70's) we were learning Fortran on a mainframe. The input entry was with punch cards. In order to speed up the turn around for testing our programs, they would put the card reader "on line". They would have one operator feed he card reader and one sit behind the line printer to rip apart the print outs. You could literally see your card deck get read in and the output fly out of the printer. If you got in line early, you could get a couple of iterations of running and fixing your code before the hour was up and the card reader went back to spooling jobs for later running.

I think he means that compilers should be super optimized and fast. This is of paramount importance. But for any other software, just get faster hardware. That's good enough for those dirty idiot users. They probably wouldn't notice if you optimised your code anyway.

There's a related problem of course is game consoles. Many of the games for the NES and SNES were dependent, not on CPU speed, but on TV refresh rates. That is, NES and SNES games were essentially programs designed to draw a "fixed" list of frames.

The code for games would would have to be tweaked seperately for the NTSC and PAL versions because PAL draws to the screen 50 times a second, while NTSC 60 times a second. So the PAL version had to be modified to be 13% "faster" to compensate for the fact that 10 fewer frames were being drawn per second.

This unfortunately resulted in a bug in the PAL version of Super Mario Kart, which made it impossible to get to a secret area in one of the ghost house runs. There was a very long jump you had to make, and the physics engine just ran slightly too fast to make the jump.

another problem for NES games (especially in the megaman series), is that if the code for calculating a frame takes slightly more than 1/60th of a second to run, the program would have to wait for the next scan to draw the frame it calculated. So on screens where there's just slightly too many enemies, the game would suddenly run twice as slow, even if the program only overshot the frame drawing interupt by only 1 millisecond, you'd get a whole frame of wasted CPU time, while the program waits for the next interrupt.

7 damn megaman games and they never addressed this. Couldn't they have written a subroutine to detect if they missed a frame, and compensate in the next frame? apparently not.

"I saw an article that compared the performance of a 1986 Mac and a 2007 PC. For the most mundane tasks -- booting, launching Word, opening a file, doing a search and replace, etc. -- the old Mac was slightly faster. We've squandered most of the benefits of Moore's law on bloatware."
John on December 23, 2008 05:50 AM

And then you realize the one thing that has been driving the massive acceleration of computer hardware capabilities: Computer Gaming

Just a couple days ago, after getting a new PC, I encountered a bug in a game from 2001, the speed estimating function ran too fast and returned zero while its caller never expected that. Result - unhandled divide by zero exception.
I remember the same type of crash happening when certain DOS Pascal programs ran on the first 32 bit chips... something to be said about learning from history.

(The game is C&C Yuri's Revenge, btw, and luckily I'm versed enough in assembly to fix that bug /and a lot more bugs in the C&C series/ myself.)

Things should definitely happen instantaneously on computers, if it takes more than 3ms to open the start menu in Xp, its time to reinstall.

MARTIN YOU SUCK.THE 1 GB FRAMEWORK DOES MAKE PROGRAMMING EASY NOT THE NOTEPAD!

Those were the days!

@Mick: That is true for the compiler itself. But the debugger takes ages to start up (rearranging all those windows).

Plus performance is not everything: The compiler is so full of bugs, I decided to stop using Delphi 2009 until (at least) SP3 (too bad I already purchased it.

Oh and there is a nice counter example: The fastest N64 emulator (Corn) was created by a Russian genius who (as far as I know) simply could not afford a faster machine. It ran flawlessly on a 200-300 mhz machine (which is awesome, considering the N64 was a MIPS running at 93 Mhz plus a coprocessor running at 66 Mhz (if I recall correctly)).

Maybe the rule should be: Developers should have fast machines to be productive but should test their software on damn slow hardware.

P.S.: UltraHLE was also damn fast but due to slowdown routines that could not be disabled it is very difficult to compare those two emulators.

In addition to Peter Turner's comment about Space Quest 1,
our little turbo button was also helpful while trying to hit the spider which came from an outer space. :)

The problem wasn't that programs weren't written to run on different clockspeeds, which there were even then a multitude of by the early nineties. The problem was a lot of those program's calibration loops didn't do enough iterations and so on a 486 a loop that went around 100 times to estimate a slowdown-number to pauze between frames completed in 0.0 seconds and so the game crashed with a divide by zero error.

So which developer would you rather be?

The one that writes a line, hits run, tests / fixes it, repeats.

Or, the developer that writes everything in one go and then hits run once?

The first one relies upon fast compile times... The second one relies upon understanding and planning your code and not just hacking. I know which one I'd rather be. Would you turn off that "turbo" button to make your compiles so slow that you actually then start thinking about what your writing rather than hacking?

Robin

I've never need fast compile times. Like Robin mentions above, I'm one of those programmers that writes 90% of what is needed up front with very few bugs. I'm not like those programmers that rely on constant iterations to get things right.

Those kinds of programmers really bother me. They really don't know what they are doing and are likely just shooting from the hip most of the time. The ones I've known in the past that worked like that were the worst programmers I'd ever worked with.

I entirely agree with Robin and Matt. I code to the next milestone, test, and may or may not encounter a bug to fix.

Being at young one at the time, I used to love to press the Turbo button and watch "dir" change from a flash on the screen to a slow crawl of text. Those were the days.

Funny you mentioned this. We do development at my work using Eclipse and Java, and we all had PCs running Windows on our desktops. That meant it took Eclipse two or three minutes to open, and about 15 minutes to open our Subversion repository.

I installed Ubuntu and VirtualBox to run Windows under Linux in case I needed access to some Windows only piece of software. I am using Evolution for access to our Exchange Server and Open Office. Now, Eclipse opens in a few seconds and I can download the repository in under 2 minutes.

Heck, I think even Windows runs faster under VirtualBox under Linux than when it was directly on the box. It's like pushing the ol' Turbo button (or is it taking the PC out of Turbo mode?).

So far, I haven't had much of a need to use my Windows install. I suspect that the other developers will soon also want to switch to Linux desktops too.

There's no appreciable difference between running Wordstar on my old 2 MHz Z80 and running any other text editor on my new G5. Maybe I should type faster....

I don't think your snippet from Fred brooks has anything to do with what you are talking about. It seems to be taken out of context and fit in your article to give you more credibility. In fact, I would suggest that sometimes such immediacy is sometimes detrimental to comprehending problems and understanding systems. Too often I see people just use a compiler and linker combined with trial and error to get things "working". Sometimes it has desired effects, but many times it allows weak minds and weak developers to compile and check in bad code without understanding anything they were doing. I don't yearn for the olden days of slow responses, but I think we have gotten to the point where many developers don't even think about what they are doing before writing code. The instant feedback exacerbates that.

My 'turbo button' is almost always non-responsive customers. Wait a day to get back to me on an issue, don't look at the sample screenshots I sent you, or keep forgetting to have IT set up that user account, and my interest in your project slows to 16Mhz.

Merry Christmas Jeff. Keep up the great writing.

> I saw an article that compared the performance of a 1986 Mac and a 2007 PC

Perhaps this one?

http://hubpages.com/hub/_86_Mac_Plus_Vs_07_AMD_DualCore_You_Wont_Believe_Who_Wins

> many times it allows weak minds and weak developers to compile and check in bad code without understanding anything they were doing

Bad programmers will write bad code, no matter how fast their tools go. Good programmers, on the other hand..

Bad programmers will write bad code, no matter how fast their tools go. Good programmers, on the other hand..

"... write good code, no matter how slow their tools go."

One of my programs displays a line of progress *'s across the screen as it does lengthy recalculations. After the last *, they get cleared away. Over the years, I improved the algorithm and machines got faster.

One year a user complained that the recalculation function was not working, since she did not see the progress bar.

I asked her to hold down the recalculate key. It turned out that what had once taken about 40 seconds was now taking less than .1 second. Once she held down the recalculate key, she could see the progress bar flicker as it recalculated everything at the keyboard character repetition rate.

I then changed the program to display a "calculation complete" message instead of proogress *'s.

"Bad programmers will write bad code, no matter how fast their tools go. Good programmers, on the other hand.."

I agree.

Fast tools allow more bad code to get developers by sloppy programmers. So instead of getting frustrated and choosing another profession, they stick with it and give us all headaches.

I had to work with one imbecile that actually somehow convinced management to tell the other developers not to bother him with details like the fact that his code didn't compile or work - he had a deadline, goddamnit and he had to get it done.

There is some asymptotic limit to how fast good developers can code and the responsiveness of a keyboard input buffer or the compiler is far in front of that limit.

Tim, see this:

http://www.codinghorror.com/blog/archives/000427.html

--

"So let's get real. Bad programmers write bad code. Good programmers write good code. RAD lets bad programmers write bad code faster. RAD does NOT cause good programmers to suddenly start writing bad code. RAD tools can make a good programmer more productive, because they speed up the coding process without compromising the level of quality that a good programmer is going to achieve."

The turbo button got really useless in later years when it continued to, in every PC I saw, halve the clock speed. Halving the speed made sense when the turbo button was introduced on PCs that ran twice as fast as the original. Now when you had a PC running 40 times as fast as the original, cutting the speed down to 20 times as fast didn't really buy you anything.

At that point it was just an annoying button that did nothing good and would occasionally get pressed (by mistake or by some joker) and cut your speed in half. What a horrible feature, and what an example of inertia compromising future designs.

"So let's get real. Bad programmers write bad code. Good programmers write good code. RAD lets bad programmers write bad code faster. RAD does NOT cause good programmers to suddenly start writing bad code. RAD tools can make a good programmer more productive, because they speed up the coding process without compromising the level of quality that a good programmer is going to achieve."

Jeff Atwood on December 26, 2008 01:22 AM

I tend to agree, yet ... this ain't nothing to do with hardware performance.

That's so funny you posted this. I asked the same question on StackOverflow.com if anyone else misses the Turbo Button. After 3 negative votes on the question I eventually deleted it. There must have been a Turbo Vibe in the wind recently.

"What's keeping you from going as fast as you can?"

It is this attitude that keeps many developers from writing fast applications:

http://www.codinghorror.com/blog/archives/001198.html (Hardware is Cheap, Programmers are Expensive)

Why trying to optimize, when users can optimize by buying a faster HW?

I had a constant argument with a friend of mine back in college in the late 80's. He insisted on running his computer with the Turbo button in the "off" position. First thing I would do when I used it was to turn it back on and he would freak out! He feared running it on Turbo would burn out the processor somehow. Nothing I said ever changed his mind.

What a bunch of geeks!

The turbo button came in handy talking to POS systems. The poor old registers couldn't keep up duing com's. Indeed so much so we had a combination of the turbo button set to off and software written to slow down coms.

Turbo Pascal 6 (and perhaps previous versions? I believe they stopped supporting it in version 7, which was renamed Borland Pascal) had a pretty cool feature when compiling: it could build directly to RAM, bypassing the harddisk. When developing on 286 machines with painfully slow drives, this sped up the develop/test cycle tremendously.

Of course the code generation sucked (which is typical of Borland), and even in the later 486 days you often needed to code routines in assembly to make things run fast enough.

Needed to turn it off to play Joust, which didn't scale automatically with the clock speed.

>I could write, compile and debug applications virtually instantly and my need for speed has never looked back. Even on the compared-to-today crappy hardware I never really found another environment as fast until I started using PHP this year (which of course has no compilation).
I don't think anybody will like what I say, but...
That's the spirit and power of Visual Basic. I didn't value it that much because I didn't know other languages/IDEs. When I had to write a project in C++ it stuck me hard. There was now longer "pressing F5 to run the program". There was "compilation" which took significant time even for a simple program. Not to mention the absense of Edit and Continue. What amused me even more was that C# also had very noticeable compilation stage. Even though VB.Net produces the same low-level code as C# and runs the same .exe files when I press F5, the program runs instantly.

Golden Rules In stock market trading
Rule # 1: First things first - First, decide whether you are a trader or an investor? Be sure that you really want to trade. It is common for people who think that they want to trade to discover that they really do not. Examine your motives and think about why you really want to trade. If you just want to trade for the excitement, you might be better off riding on a roller coaster or taking up hang-gliding. You need to examine your motives and the activity that will result from it as many times there may be some form of conflict. The share market is a stern master. You need to do almost everything right to win. If parts of you are pulling in opposite directions, the game is lost before you start.
Rule # 2: Match the trading or investment strategy to your personality
Rule # 3: Know who you are financially for a moneyless man goes fast through the share market –
Rule # 4: The trend is your friend or a trend in motion is assumed intact until it actually ends
Rule # 5: Do not ever make the mistake of telling the market that it is too high or too low
Rule # 6: If you catch the wrong bus, get off and catch the right bus
Rule # 7: Never marry a share
Rule # 8 :Take your losses quickly, your profits slowly
Rule# 9: He who looks back on the market, usually dies of remorse
Rule # 10: It is far better to buy a fine company at a fair price, than a fair company at a fine price.-
Rule # 11: After a drunken spree, you must expect a hangover
Rule # 12: When in doubt, stay out

www.Sharehottips.com
www.vaibhavmicron.com
Vaibhav International
25, cement Gali, Dholi Bawri, Udaipur(Rajasthan)-India
Email : info@sharehottips.com, sharehottips@gmail.com, sharehottips@rediffmail.com
For any query contact us:--
Ph.: + 91 94142 33706, 93524 97766 (After 4 PM to 9 PM)
Yahoo messenger Id is sharehottips@ymail.com

Golden Rules In stock market trading
Rule # 1: First things first - First, decide whether you are a trader or an investor? Be sure that you really want to trade. It is common for people who think that they want to trade to discover that they really do not. Examine your motives and think about why you really want to trade. If you just want to trade for the excitement, you might be better off riding on a roller coaster or taking up hang-gliding. You need to examine your motives and the activity that will result from it as many times there may be some form of conflict. The share market is a stern master. You need to do almost everything right to win. If parts of you are pulling in opposite directions, the game is lost before you start.
Rule # 2: Match the trading or investment strategy to your personality
Rule # 3: Know who you are financially for a moneyless man goes fast through the share market –
Rule # 4: The trend is your friend or a trend in motion is assumed intact until it actually ends
Rule # 5: Do not ever make the mistake of telling the market that it is too high or too low
Rule # 6: If you catch the wrong bus, get off and catch the right bus
Rule # 7: Never marry a share
Rule # 8 :Take your losses quickly, your profits slowly
Rule# 9: He who looks back on the market, usually dies of remorse
Rule # 10: It is far better to buy a fine company at a fair price, than a fair company at a fine price.-
Rule # 11: After a drunken spree, you must expect a hangover
Rule # 12: When in doubt, stay out

www.Sharehottips.com
www.vaibhavmicron.com
Vaibhav International
25, cement Gali, Dholi Bawri, Udaipur(Rajasthan)-India
Email : info@sharehottips.com, sharehottips@gmail.com, sharehottips@rediffmail.com
For any query contact us:--
Ph.: + 91 94142 33706, 93524 97766 (After 4 PM to 9 PM)
Yahoo messenger Id is sharehottips@ymail.com

WWW.sharehottips.com are providing Market Psychology with Technical Analysis and give you simple entry and exit points on the best Indian stocks, every day.
You get Live! Calls on the Indian stocks, options and futures, for NSE & BSE market and Commodity in MCX. Day Trading Calls through yahoo messenger. shartips, share tips, daytrading tips, BTST, STBT, future option, Advice, Analysis, Bse Intraday, Bse Stock Tips, Btst, Buy, By, Deleivery, Equity, Financial, India, Indian, Indian Share Market, Indian Share Market Tips, Indian Shares, Indian Stock Market, Intraday, Intraday Trading, Live Indian Stocks, Market, Money, Nifty, Nse, Nse Market Tips, Of, Penny, Pre-market Analysis,Recommendations,SENSEX,Sell,Shares,Sms,Stbt,Stock,Stocks,Technical Analysis,Trading
We give you clear entry and exit points, for Indian stock market. Cash market, Futures/Options calls are given on a LIVE! Basis. Calls for short, medium and long term.
Our trading calls for Indian shares is in demand among intra-day traders, as it provides clear target with stop loss, it includes Nifty target levels as well.
www.Sharehottips.com
www.vaibhavmicron.com
Vaibhav International
25, cement Gali, Dholi Bawri, Udaipur(Rajasthan)-India
Email : info@sharehottips.com, sharehottips@gmail.com, sharehottips@rediffmail.com
For any query contact us:--
Ph.: + 91 94142 33706, 93524 97766
Yahoo messenger Id is sharehottips@ymail.com

WWW.sharehottips.com are providing Market Psychology with Technical Analysis and give you simple entry and exit points on the best Indian stocks, every day.
You get Live! Calls on the Indian stocks, options and futures, for NSE & BSE market and Commodity in MCX. Day Trading Calls through yahoo messenger. shartips, share tips, daytrading tips, BTST, STBT, future option, Advice, Analysis, Bse Intraday, Bse Stock Tips, Btst, Buy, By, Deleivery, Equity, Financial, India, Indian, Indian Share Market, Indian Share Market Tips, Indian Shares, Indian Stock Market, Intraday, Intraday Trading, Live Indian Stocks, Market, Money, Nifty, Nse, Nse Market Tips, Of, Penny, Pre-market Analysis,Recommendations,SENSEX,Sell,Shares,Sms,Stbt,Stock,Stocks,Technical Analysis,Trading
We give you clear entry and exit points, for Indian stock market. Cash market, Futures/Options calls are given on a LIVE! Basis. Calls for short, medium and long term.
Our trading calls for Indian shares is in demand among intra-day traders, as it provides clear target with stop loss, it includes Nifty target levels as well.
www.Sharehottips.com
www.vaibhavmicron.com
Vaibhav International
25, cement Gali, Dholi Bawri, Udaipur(Rajasthan)-India
Email : info@sharehottips.com, sharehottips@gmail.com, sharehottips@rediffmail.com
For any query contact us:--
Ph.: + 91 94142 33706, 93524 97766
Yahoo messenger Id is sharehottips@ymail.com

Golden Rules of Trading
- Plan your trades. Trade your plan.
- Keep records of your trading results.
- Keep a positive attitude, no matter how much you lose.
- Don't take the market home.
- Forget your College degree and trust your instincts.
- Successful traders buy into bad news and sell into good news.
- Successful traders are not afraid to buy high and sell low.
- Continually strive for patience, perseverance, determination, and rational action.
- Limit your losses - use stops!
- Never cancel a stop loss order after you have placed it!
- Place the stop at the time you make your trade.
- Never get into the market because you are anxious because of waiting.
- Avoid getting in or out of the market too often.
- The most difficult task in speculation is not prediction but self-control. Successful trading is difficult and frustrating. You are the most important element in the equation for success.
- Always discipline yourself by following a pre-determined set of rules.
- Remember that a bear market will give back in one month what a bull market has taken three months to build.
- Don't ever allow a big winning trade to turn into a loser. Stop yourself out if the market moves against you 20% from your peak profit point.
- Expect and accept losses gracefully. Those who brood over losses always miss the next opportunity, which more than likely will be profitable.
- Split your profits right down the middle and never risk more than 50% of them again in the market.
- The key to successful trading is knowing yourself and your stress point.
- The difference between winners and losers isn't so much native ability as it is discipline exercised in avoiding mistakes.
- Speech may be silver but silence is golden. Traders with the golden touch do not talk about their success.
- Dream big dreams and think tall. Very few people set goals too high.
A man becomes what he thinks about all day long.
- Accept failure as a step towards victory.
- Have you taken a loss? Forget it quickly. Have you taken a profit? Forget it even quicker!
- You don't invest ...You will lose.
- You don't manage risks ...You will lose.
- You follow tips ...You will lose.
- You don't investigate before you invest ...You will lose.
- You panic ...You will lose.
- You want to speculate ...You will lose.
- You don't understand your finances ...You will lose.
- You don't use cost averaging ...You will lose.
- You want to play ...You will lose.
- You are greedy ...You will lose.
- You place all your eggs in the same basket ...You will lose.
- You don't know when not to invest ...You will lose.
- You don't know when not to exit ...You will lose.
- You can't afford to lose ...You can't afford to make a profit.
www.Sharehottips.com
www.vaibhavmicron.com
Vaibhav International
25, cement Gali, Dholi Bawri, Udaipur(Rajasthan)-India
Email : info@sharehottips.com, sharehottips@gmail.com, sharehottips@rediffmail.com
For any query contact us:--
Ph.: + 91 94142 33706, 93524 97766 (After 4 PM to 9 PM)
Yahoo messenger Id is sharehottips@ymail.com

www.sharehottips.com are providing Market Psychology with Technical Analysis and give you simple entry and exit points on the best Indian stocks, every day.

You get Live! Calls on the Indian stocks, options and futures, for NSE & BSE market and Commodity in MCX. Day Trading Calls through yahoo messenger.

We give you clear entry and exit points, for Indian stock market. Cash market, Futures/Options calls are given on a LIVE! Basis. Calls for short, medium, long term, BTST, STBT, Day trading, Nifty Target.

Our trading calls for Indian shares is in demand among intra-day traders, as it provides clear target with stop loss, it includes Nifty target levels as well.

Vaibhav International, Udaipur Rajasthan, India
Email : info@sharehottips.com, sharehottips@gmail.com, sharehottips@rediffmail.com
Ph.: + 91 94142 33706, 93524 97766 (After 4 PM to 9 PM)

www.vaibhavmicron.com
We are the manufacturer and exporters of micronized mineral powder. Our specialties are manufacturing of up to 10 micron Talc and Calcium Carbonate powder, Coated calcium carbonate powder. We also deal in chaina clay, Feldspar, quartz, Dolomite Powder. The powder uses in plastic, paper, soap, detergents, adhesives, food, pharmaceuticals, chemicals, master batches etc.
Vaibhav International,
25, cement Gali, Inside delhi gate, Udaipur (Rajasthan)- India
Email: info@vaibhavmicron.com, vaibhav_international5@yahoo.co.in
Ph.: + 91 94142 33706, 93524 97766

Seems I'm now in with the spammers, but this post reminded me of my funniest 'turbo button' episode:

I used to have Greek neighbours who would ply me with some pretty amazing food to help them with their (answering machine|fax|computer) issues. Nice! One day they said their computer was really slow, and that they'd paid some guy $100 to not ultimately help, might I try? Oh, and we just made spanikopita...

So over I went. I looked at the config files, the memory, it all looked okay. And even their apps weren't bad. I was starting to wonder if it was just their imagination. Until I ran Doom II.

See, I had pretty much the same computer (486-25, I think... don't laugh, I was underemployed at the time) and... holy crap, Doom was really really slow -- seemingly an order of magnitude slow.

LIGHT BULB!

Sure enough, their computer had one of those useless turbo buttons. And sure enough it had been unswitched. CLICK! Doom was back up to speed, problem solved.

And, yes, the spanikopita was quite tasty. :p

This blog is nice and informative,good to know that the blog created by the webmaster is very helpfull to the visitors

RBI has cut Repo rate by 100 BPS to 6.5%, due to this we can see some rebound in the <a href="http://knowyourprofit.com" title="Indian Stock Market">Indian Stock Market</a>,as this is one of the factors which will also decide the movement of Nifty in coming days along with different other factors,our advice for intraday traders is to trade light

Any Query

Call us

+91-9871142419
+91-9212663485

Mail at :-
support@knowyourprofit.com

<a href="http://knowyourprofit.com" title="KnowYourProfit">KnowYourProfit</a>

The operating system should reserve the space for programs that suddenly use more memory or processing time. Noone is ever nice to other threads anyway.

This blog is great and informative,and nice to know that the blog created by the webmaster is very helpful to the visitors. I always wondered what that button was for on old keyboard

@softwaredevelopment

The keyboard 'turbo' is to change the key repetition rate - not the computers speed.

In the time of recession one job or one work is hardly fulfilling needs of people. So everyone is looking for supplementary source of income.
Now the question is what can be that source of income in such a bad phase of economy??

Well it’s very difficult to start new business at this point of time as it requires lot of cash and efforts. So again question is how to make more money in such conditions when needs are same and income is low?

We strongly suggest that if you like to take bit of risk and don’t want to spend too much money and time on new venture then stock market is the right place for you.
To be very frank this is not the right time for investment that is for long term to medium term investment but every day is a favourable day for day trading. No matter if NSE or <a href="http://www.sharetipsinfo.com" title="BSE">BSE</a>
is bullish or bearish as In stock market one can earn in both of these trends.

So just think about it and see if stock market can be the right place to make some extra money.

Please feel free to contact us for any query.

Regards
<a href="http://www.sharetipsinfo.com" title="SHARETIPSINFO TEAM">SHARETIPSINFO TEAM </a>