I don't think this is an 'accurate' form of Sleep(). When the code encounters a Slepp() call, the thread gives up its time slice back to the task scheduler. When it is its time slice again, it checks if it is the time for Sleep() to end and continue execution, if it is isn't, the thread will give up its time slice again, and so on. Sleep() doesn't hog the CPU with this endless loop, afaik.
I decided to check. The results are attached to this post.
Interesting to note... Kind of proved your point wrong, as the WinAPI obviously does NOT check if the time has passed, because it returned early many times. I know, because I was using QueryPerformanceCounter and QueryPerformanceFrequency. Apparently, Sleep would either be calling a Wait function with a handle that will not be signaled ever, with the time passed to Sleep(), OR.... Sleep does take clock cycles and guestimates based off mhz and cycles per a certain instruction.
When there were no SPIKE changes, my version is alot more consistent.
Whose is more accurate?
Albeit, in terms of AFTER the intented .1 second, the most time that was off was one instance by mine being off by .00318167 seconds, that's .003 and a little change, HOWEVER... More often than not, (in fact, 90% of the time in those 100 tests) my function was off by less than .00000500!
And truthfully speaking, the time frame it takes for calling QueryPerformanceCounter after my function returns probably takes up that miniscule amount of time. So, in more likeliness? My function is pretty much 100% correct 90% of the time.
File2.txt is my second test of 50 iterations each of .2 seconds. My results are 94% (47 out of 50) when the same rules were applied.
File3.txt is my third test of 25 iterations of .3 seconds each. Results were with that same rule a result of 92% (23/25).
My last test (File4.txt results) was of 50 iterations of .020 sleeps a piece. The result on mine with the same rules? 45/50 for a 90%.
If this was an issue of 'comparing', I would be saying the following...
Code:
unsigned long TextFormatter::OutputDouble(char * pBuffer,double lfValue,unsigned long dwPrecis) throw()
{
const long long nDigit = static_cast<long long>(lfValue);
double lfRemain = lfValue - static_cast<double>(nDigit);
unsigned long dwOutput = OutputInt64(pBuffer,nDigit);
pBuffer[dwOutput] = '.';
++dwOutput;
char * pOutput = &pBuffer[dwOutput];
unsigned long dwTemp;
for (unsigned long x = 0; x < dwPrecis; ++x)
{
lfRemain *= 10.0;
dwTemp = static_cast<unsigned long>(lfRemain);
dwTemp %= 10;
pOutput[x] = static_cast<char>(dwTemp) + '0';
}
dwOutput += dwPrecis;
return dwOutput;
}
Is way faster than sprintf combined with other functions that are similar for the same result. (multiple functions calls faster than one sprintf)
Last edited by JamesSchumacher; September 24th, 2007 at 01:05 PM.
I don't think this is an 'accurate' form of Sleep(). When the code encounters a Slepp() call, the thread gives up its time slice back to the task scheduler. When it is its time slice again, it checks if it is the time for Sleep() to end and continue execution, if it is isn't, the thread will give up its time slice again, and so on. Sleep() doesn't hog the CPU with this endless loop, afaik.
And the thread gets a normal time slice running this loop. Really, no harm done.
As far as having a question, yeah... I do have a question... What if any ways can anyone think of creating a safe 'Wait' version of this function when dealing with implementing my own synchronization objects?
I am basking into the idea of writing a C++ "OS" in abstract, and then later implement the assembly to tie it to the hardware.
The use of QueryPerformanceCounter in my GetCurrentTicks() is an example of that abstraction.
GetCurrentTicks() is the abstract function (in terms of implementation, the interface being concrete - it's only a function) to call to get the performance ticks from the system. (Which on this Windows implementation it calls QueryPerformanceCounter)
Last edited by JamesSchumacher; September 24th, 2007 at 12:12 PM.
If you want to simply share code, then I suggest you write an article or Tip (in the form of a short article) and post it to the main site using the submission form you can find in the left navigation menu (on the main, www.codeguru.com site).
People can comment on such articles or tips as well.
It is pretty well know that Sleep is unreliable. Search google for 'Sleep multimedia time precision' for a boatload of information as well as many other articles on the subject.
As far as your posted code, you don't include the code for GetTicksInSecond() but mention it uses query perf counters. However, based on the implementation that is posted, it looks like your Sleep will peg the CPU, as unlike the Sleep api, it doesn't appear to relenquish the thread's time slice. If this is the case, I'm not sure a sleep routine that pegs the CPU is helpful, even if it is more accurate.
It is pretty well know that Sleep is unreliable. Search google for 'Sleep multimedia time precision' for a boatload of information as well as many other articles on the subject.
As far as your posted code, you don't include the code for GetTicksInSecond() but mention it uses query perf counters. However, based on the implementation that is posted, it looks like your Sleep will peg the CPU, as unlike the Sleep api, it doesn't appear to relenquish the thread's time slice. If this is the case, I'm not sure a sleep routine that pegs the CPU is helpful, even if it is more accurate.
Try it when it's not the only thread in your application. It does not peg the CPU, all other threads get the appropriate time slice. You cannot just test one thread.
The implementation of GetTicksInSecond() and GetCurrentTicks() are just wrappers for Windows API functions at the moment.
Code:
unsigned long long GetTicksInSecond()
{
unsigned long long value;
::QueryPerformanceFrequency(reinterpret_cast<LARGE_INTEGER *>(&value));
return value;
}
unsigned long long GetCurrentTicks()
{
unsigned long long value;
::QueryPerformanceCounter(reinterpret_cast<LARGE_INTEGER *>(&value));
return value;
}
The reason it may seem to peg the CPU, is that you are probably not running several processes in which there are more 'threads' to pass a time slice. Therefore, the CPU will just stay on that thread for a while, and it also has something to do with the fact that QueryPerformanceCounter takes very little time to execute... Therefore, it runs that loop MANY TIMES before giving up to a time slice. You are just used to the CPU not working that hard before it gives a slice to another thread.
I'll reiterate... Imagine if an application is given a .004 second time slice... And that the call to QueryPerformanceCounter through GetCurrentTicks() only takes 0.00000350 seconds on the average.
What is that? Like 1/119 of the time slice? That loop could conceivably run 100 times before it gives in to the thread scheduler.
I am not giving up any time to the scheduler for other threads... You are probably used to the fact that your app would 'yield time' in which it makes my approach seem like 'eating' clock cycles.
When in actuality, 'TimeSlice'->'TimeSliceUsed' > 'TimeSlice'->'SliceYielded' is how it should be described when thinking about available cycles.
In actuality, I am making more use of my allotted time slice, than the average application... Instead of actually 'wasting' time by allowing the processor to sit dormant.
Does this eat up your CPU so much it's sluggish? It does not this one.
Last edited by JamesSchumacher; September 24th, 2007 at 02:56 PM.
Let me preface this by saying that I'm not trying to argue with you or dismiss your work.
Originally Posted by JamesSchumacher
Try it when it's not the only thread in your application. It does not peg the CPU, all other threads get the appropriate time slice. You cannot just test one thread.
Why can't I test one thread? Shouldn't the behavior of a Sleep function work the same whether it's being used in a single or multithreaded app?
I've created a test app that runs your sleep( ). I first ran your sleep( ) in a single thread dialog app and it used 50% CPU. I then ran the same app except used the Sleep( ) api. While sleeping, it consumed 0% cpu.
Out of curiosity, I then added multithreading to the mix. While running your sleep() routine in a separate thread, it used 50% cpu.
See the attached project.
Originally Posted by JamesSchumacher
The reason it may seem to peg the CPU, is that you are probably not running several processes in which there are more 'threads' to pass a time slice. Therefore, the CPU will just stay on that thread for a while, and it also has something to do with the fact that QueryPerformanceCounter takes very little time to execute... Therefore, it runs that loop MANY TIMES before giving up to a time slice. You are just used to the CPU not working that hard before it gives a slice to another thread.
You're a little off base here. This statement:
"Therefore, it runs that loop MANY TIMES before giving up to a time slice."
is incorrect. You are mistaken how a pre-emptive OS works. The code doesn't ever control how long it gets to run, that's the scheduler's job.
The scheduler will run your code for a time slice as determined by the system and then switch to another thread. Whether your thread is caught in a infinite loop and spinning is of no importance to the OS. In this case, your sleep function essentially is running wild during it's time slice and that's why it's consuming high CPU %. The scheduler will preempt your thread (and does preempt your thread ) many times while it's running although it may not appear to be doing so.
Whether this occurs in a single thread or a multiple thread is irrelevant because the high CPU utilitization of your function occurs in either case. The OS doesn't care if a thread burning up the CPU is the main thread of an app or a secondary thread - it still burns up the cycles.
What the api Sleep() does is that while sleeping, it goes into an efficient sleep state so the OS just skips over the thread (i.e. doesn't schedule any time slices during the same sleep period). That is quite a bit different than spinning while waiting for the time period to expire.
Let me preface this by saying that I'm not trying to argue with you or dismiss your work.
Why can't I test one thread? Shouldn't the behavior of a Sleep function work the same whether it's being used in a single or multithreaded app?
I've created a test app that runs your sleep( ). I first ran your sleep( ) in a single thread dialog app and it used 50% CPU. I then ran the same app except used the Sleep( ) api. While sleeping, it consumed 0% cpu.
Out of curiosity, I then added multithreading to the mix. While running your sleep() routine in a separate thread, it used 50% cpu.
See the attached project.
You're a little off base here. This statement:
"Therefore, it runs that loop MANY TIMES before giving up to a time slice."
is incorrect. You are mistaken how a pre-emptive OS works. The code doesn't ever control how long it gets to run, that's the scheduler's job.
The scheduler will run your code for a time slice as determined by the system and then switch to another thread. Whether your thread is caught in a infinite loop and spinning is of no importance to the OS. In this case, your sleep function essentially is running wild during it's time slice and that's why it's consuming high CPU %. The scheduler will preempt your thread (and does preempt your thread ) many times while it's running although it may not appear to be doing so.
Whether this occurs in a single thread or a multiple thread is irrelevant because the high CPU utilitization of your function occurs in either case. The OS doesn't care if a thread burning up the CPU is the main thread of an app or a secondary thread - it still burns up the cycles.
What the api Sleep() does is that while sleeping, it goes into an efficient sleep state so the OS just skips over the thread (i.e. doesn't schedule any time slices during the same sleep period). That is quite a bit different than spinning while waiting for the time period to expire.
That is true... However... I am not just concerned with Sleep(), I was concerned more with the accuracy of timing. Timers work in different ways on Windows depending on the implementation, and because of the fact that Sleep() goes into a 'wait state' there is that issue of a waitable timer for example not being 'accurate'.
This is more along the lines of accuracy than clock cycles.
In that application that I posted a link to (the folder link) I use a similar loop. I will use a similar loop design when I write a game. (However, I am going to be a little more 'efficient' when I write that game. At 30 fps (my target) I can afford to Sleep() or wait on a dummy mutex or something for 1 millisecond. Then I can run this type of loop until the time 'expires'. Although, when relinquishing time for 1 millisecond, I might get a slice 5 milliseconds later or whatever... So I might just use the loop to ensure accuracy.
Your version of sleep is totally environment-unfriendly, in view of the global warming crisis. Wasting CPU cycles for doing nothing. When we use Sleep(), very rarely we need that kind of accuracy and precision, we just want to sleep while waiting for a response(not event based), when the sleep is over, the response is not ready, we sleep again. For that kind task, Sleep() is sufficient.
Imagine 1 million users are playing your game where their PC specs could have attain more than 30fps or even 60fps but you limit it to 30fps for no good reason and use full CPU utilization when that thread is running or sleeping(pun intended). Colossal waste of electricity!
Try it when it's not the only thread in your application. It does not peg the CPU, all other threads get the appropriate time slice. You cannot just test one thread.
It uses *all* the CPU it can.
For example, if you compress a file while this sleep function is running, it'll compress TWICE as slow (unless you've a dual core or multiprocessor machine).
It's even funnier if you set the priority of your thread to something above other threads. It'll hang the whole system during the whole sleep operation!
You should:
Immediately confess.
Become a hermit and pray during the rest of you life.
Hope that your sin will be forgiven.
If you need an accurate timer, use multimedia timers.
Very few programs do abominations like you did. I immediately uninstall these awful programs.
You could render your abomination less abominable by waiting N-50 milliseconds and use your horror for the last few milliseconds. It would still be evil, but less evil.
What is that? Like 1/119 of the time slice? That loop could conceivably run 100 times before it gives in to the thread scheduler.
Yes. It eats more than 100, 1000 or 10000 times the CPU required.
I am not giving up any time to the scheduler for other threads... You are probably used to the fact that your app would 'yield time' in which it makes my approach seem like 'eating' clock cycles.
Exactly.
An application that eats all the CPU the system accepts to give to it only to do NOTHING should be immediately killed.
On modern computers, even video players aren't that unfair!
On a normal system, when desktop applications are used, only a few percents of the CPU are used.
On laptops you eat battery power.
Instead of actually 'wasting' time by allowing the processor to sit dormant.
It is not wasted.
It is either used to save batteries, or used by OTHER PROGRAMS.
You're still thinking as if you were using a monotasking OS.
On a desktop computer, I want to be able to compress three files at once, and yet, use normally my computer.
Often, when working with desktop applications without background tasks, only a few percents of the CPU are used, indeed.
But, what if all the programs adopt your awful behavior?
Then, any tiny application-that-does-nothing will claim to need all the CPU it can have.
If twenty processes do that, we'll end up getting files compressed twenty times slower... Moreover, these programs will entirely loose their accuracy, because they'll execute their loop only 1/20th of the time... Something like once every 200 milliseconds (assuming the max time slice is 10 milliseconds).
lthough, when relinquishing time for 1 millisecond, I might get a slice 5 milliseconds later or whatever...
Actually, the time slice will, in average, be equal to the inaccuracy of Sleep(). So, just use Sleep().
Anyway, for a 30 fps game, Sleep()/WaitFor* are sufficiently accurate.
If you feel that you need more accuracy, use multimedia timers. With them, you can CHOOSE the accuracy. Something like 4 or 5 milliseconds should be ok.
In practice your game will never be smooth with this fixed-framerate approach, because:
Very fast machines won't ever have more than 30 fps in your game.
Medium and slow machines may need more than 1/30th of second for some images but not all, which will give the bad feeling that your game has a variable speed.
If you use an ID software game, you can experience this bad feeling when setting the min and max fps values to the same number. With the same computer, you'll feel that it's far less smooth than with a variable framerate than with a variable framerate.
Moreover, with a variable framerate, accuracy of Wait* operations is not needed anymore since if the time waited is five milliseconds more than planned, the game world will take that time in account for its next move.
A variable framerate game should have:
A min fps value. If the physical time to compute one frame is longer than 1/min-fps, then, the game time spend in this frame must be set to 1/min-fps
A max fps value. If one frame is computed in less than 1/max-fps, the game will wait (with Sleep or WaitFor*) for 1/max_fps - time_that_was_spent_to_compute_the_frame.
A user setting to change max fps and min fps values.
Then, instead of making the world move by constant steps, you should make everything a variable of the game time spent between two frames.
Originally Posted by CBasicNet
Imagine 1 million users are playing your game where their PC specs could have attain more than 30fps or even 60fps but you limit it to 30fps for no good reason and use full CPU utilization when that thread is running or sleeping(pun intended). Colossal waste of electricity!
Especially for laptops for which every joule eaten decreases the laptop autonomy and the battery lifetime.
To save power, many laptops run the CPU at a variable frequency. If all the CPU power is eaten, the frequency will raise and much more power will be eaten.
Last edited by SuperKoko; September 25th, 2007 at 03:09 AM.
"inherit to be reused by code that uses the base class, not to reuse base class code", Sutter and Alexandrescu, C++ Coding Standards.
Club of lovers of the C++ typecasts cute syntax: Only recorded member.
Out of memory happens! Handle it properly!
Say no to g_new()!
Apparently you did not get the just of what I said, I do not Sleep() in my games or run this exact loop of doing 'nothing'.
I simply stated that I wrote a similar loop to this that also does OTHER operations.
For example:
Code:
do
{
if (TimeHasPassed)
{
GameObject->Cycle();
}
} while (true);
I said a similar loop - I did not say I was using a 'nothing' loop.
So when you say that I am wasting 'cycles', you are wrong. The reason being in the sense of what I just decribed. When someone plays a game, they have very little intention of doing much else... So think about what your point was against what I just said.
Which was my point about the 'faster code' versus sprintf.
Timers are inaccurate as the Sleep() function, THAT is my point. Windows is not a REALTIME OS.
The structure of my code in terms of accuracy is what I meant. In 'structure' where a similar loop (relative to all code) such as the example above - for ACCURACY, to ensure what I want to happen is done correctly. You stated that in your own post, which is WHAT I MEANT in my post previously. What you just did is take my idea of what I said, and acted as if I did not intend that - in a way, not to sound like I am 'baiting', but that I 'do not know what I am talking about.' When in fact I do.
A dummy Wait() would be a solution to allow some other process some clock time, and NOT wait for the entire period between 'Cycles'. A dummy wait for a portion, and this 'looping' until it's time to cycle.
As for the laptop issue... Yes, you are correct. That is common sense. It's just like sampling audio at 48000 instead of 44100, it takes up more harddrive space.
About what you said about a thread priority boost, that is due to the QueryPerformance functions, they are probably making a kernel call. Kernel code has priority over user mode code. And, by looping in this manner, creating that priority boost - I can get 'more cycles' for my thread, in which when the time comes to Cycle(), those cycles will be used for the game itself. Which means it will actually run SMOOTHER.
I can also take advantage of this in a worker thread, when it's time to do something, have that thread post to the Waiting() GUI thread (GetMessage() sits there and waits for a message to be inserted into the queue, therefore when the event is set that one has been, it gets a BIG priority boost, and even bigger still - the priority boosted thread that called SendMessage adds the priority to that thread, because it is the thread that sent the message.)
This has it's pros and cons. More pros than cons actually. You want to get a task done as quickly as possible, then you can allow things to be done by other tasking 'objects'.
This is actually a good solution in terms of writing a 'time critical' application due to the fact of using up cycles. GUI threads generically do not use many cycles, they wait until an event has been inserted into the queue. So I say, why not use as many cycles as I can, considering the importance of GUI applications over console ones. That is why I witness no apparent downside in my testing. The GUI threads get a large priority boost when an event is inserted into the queue - therefore, what's the problem?
Example:
Using GetTickCount() previously (which is horrendously inaccurate, it can be off my 1 millisecond) I wrote a sampling app (note the word sampling, not polling like a standard GUI application) that all it did was get the desktop window DC, and painted text on it that was different colors every time. I set it to try and go as many frames as possible (10000).
It only mustered at most 900 FPS.
However, when I changed this to use QueryPerformanceCounter? I was able to muster 9600 FPS.
Last edited by JamesSchumacher; September 25th, 2007 at 03:33 PM.
Apparently you did not get the just of what I said, I do not Sleep() in my games or run this exact loop of doing 'nothing'.
I simply stated that I wrote a similar loop to this that also does OTHER operations.
For example:
Code:
do
{
if (TimeHasPassed)
{
GameObject->Cycle();
}
} while (true);
I said a similar loop - I did not say I was using a 'nothing' loop.
So when you say that I am wasting 'cycles', you are wrong. The reason being in the sense of what I just decribed. When someone plays a game, they have very little intention of doing much else... So think about what your point was against what I just said.
Which was my point about the 'faster code' versus sprintf.
Timers are inaccurate as the Sleep() function, THAT is my point. Windows is not a REALTIME OS.
The structure of my code in terms of accuracy is what I meant. In 'structure' where a similar loop (relative to all code) such as the example above - for ACCURACY, to ensure what I want to happen is done correctly. You stated that in your own post, which is WHAT I MEANT in my post previously. What you just did is take my idea of what I said, and acted as if I did not intend that - in a way, not to sound like I am 'baiting', but that I 'do not know what I am talking about.' When in fact I do.
A dummy Wait() would be a solution to allow some other process some clock time, and NOT wait for the entire period between 'Cycles'. A dummy wait for a portion, and this 'looping' until it's time to cycle.
As for the laptop issue... Yes, you are correct. That is common sense. It's just like sampling audio at 48000 instead of 44100, it takes up more harddrive space.
About what you said about a thread priority boost, that is due to the QueryPerformance functions, they are probably making a kernel call. Kernel code has priority over user mode code. And, by looping in this manner, creating that priority boost - I can get 'more cycles' for my thread, in which when the time comes to Cycle(), those cycles will be used for the game itself. Which means it will actually run SMOOTHER.
I can also take advantage of this in a worker thread, when it's time to do something, have that thread post to the Waiting() GUI thread (GetMessage() sits there and waits for a message to be inserted into the queue, therefore when the event is set that one has been, it gets a BIG priority boost, and even bigger still - the priority boosted thread that called SendMessage adds the priority to that thread, because it is the thread that sent the message.)
This has it's pros and cons. More pros than cons actually. You want to get a task done as quickly as possible, then you can allow things to be done by other tasking 'objects'.
This is actually a good solution in terms of writing a 'time critical' application due to the fact of using up cycles. GUI threads generically do not use many cycles, they wait until an event has been inserted into the queue. So I say, why not use as many cycles as I can, considering the importance of GUI applications over console ones. That is why I witness no apparent downside in my testing. The GUI threads get a large priority boost when an event is inserted into the queue - therefore, what's the problem?
Example:
Using GetTickCount() previously (which is horrendously inaccurate, it can be off my 1 millisecond) I wrote a sampling app (note the word sampling, not polling like a standard GUI application) that all it did was get the desktop window DC, and painted text on it that was different colors every time. I set it to try and go as many frames as possible (10000).
It only mustered at most 900 FPS.
However, when I changed this to use QueryPerformanceCounter? I was able to muster 9600 FPS.
I would like to add one more thing...
The only way to ensure something is done 'on time' or very close to 'on time' is to pretty much 'demand' more cycles/clock time. This ensures that the code (well, not ensure, but come closer to the intended timing target) begins executing at the target time.
In designing a game, you want to base it off input of the user, but with the mindset that you are sampling at a certain framerate. Games require that code do not take very long to execute in their minute selves, as a whole - the calling of all those functions, etc... must add up to less than the intended cycle time for a frame, otherwise... It will run at a slower framerate than the target. In order to make sure that code starts executing at the desired timestamp, it is necessary to demand more of the CPU and that could mean running a loop that only takes .00000009 seconds to execute, unless a time period has passes, and then it might take .00257865 seconds to execute. (This would be a target of 385 - 395 frames per second for a small game, in reality - you would not run this many frames)
The reality to hit the target framerate is to get as much CPU as you can if your code takes a little bit to execute. And by doing so, querying that performance counter in an endless loop (that is until a certain requirement is met) means that compared to all 'waiting threads' it gets the most clock time. And therefore, more clock time when it comes time to Cycle().
A smoother game operation. A little more intensive 'example' I wrote with QueryPerformance functions I always was at 60fps (the target). However, with GetTickCount() it varied as much as down to 44FPS. Ask yourself why.
The only time the average FPS dropped from 60 was when it had to process a window message from the queue. (PeekMessage returned a non-zero value - due to moving of the window) That was due to looping through until PeekMessage returned zero so all window events were handled before checking for time to Cycle(). I could have made it handle only one event if any through the loop, but I wanted to ensure all window events were handled before the next Cycle().
You have to remember...
In a single CPU machine, only 1 thread can be executing at any one time (although for such a minute time, it seems like everything is going at the same time) so when my thread is using cycles, it's technically not robbing from any other. IN FACT, it means they get fewer 'sessions' of cycles, but they get a longer time slice. Higher priority threads get 'more' sessions, with a smaller slice. Lower priorities get a LARGER slice less often. That is how threads are implemented on windows.
Smaller sections of slices more often allows for more 'accuracy' in the sense I have more opportunities to keep the 'time base' correctly synchronized.
That is why in certain situations why it might seem to YOU that it is deadlocking the CPU... Because in actuality - it gives more of a timeslice on a thread that is not intensive or doing much. It will use that alloted time slice to try and go back and forth between all those Waiting threads doing nothing.
It's not my applications fault - it's the design of the OS. That larger time slice gets devoted to checking all those waiting threads that are doing nothing. Therefore, it will come back to my app. My app in that situation due to the OS's design, is what is keeping the CPU actually doing something.
So this design pattern, actually defeats the problem in the design of the OS in intensive situations...
The FUTURE of computing if the programmers are smart, will be based off utilizing the CPU more often and detecting states of 'idle' to precalculate things that a user would want done instead of waiting for 'on demand'. An example of this, would be software that keeps track of scheduled flights. This software could be combined with weather tracking libraries in order to be able to predetermine what flights might be delayed long before the flight even gets scheduled.
Although, in GENERAL... You can plan for a flight months in advance, in which we cannot predict the weather... Imagine, 6 days before a flight in which a 'person' cannot deduct without the information as soon as it's available, that it will be delayed... Could create a situation (the need) for informing passengers that their flight may be delayed instead of waiting until the day of or the day before.
So it's more in the sense of before the scheduled flight would take off, but still... It's that IDEA.
If the person was to know 6 days in advance the flight might be delayed... They could have a chance to make preparations or other plans/cancel flight if it was a pertinent/important matter they were to attend.
You might think that something as small as a time slice wouldn't matter... It does in fact... Imagine what I said about sprintf versus my custom. The sprintf was in fact something like 25 or more times slower. Which is the difference between processing a million things in a loop in like 1 second, and 25 seconds.
sprintf is/was a standard C library function. They tell us it is not good to reinvent the wheel, when in fact reinventing the wheel can greatly aid in time saving, which in turn, like the above... Helps immensely if you were traversing a multi-megabyte / gigabyte file. (Think databases)
Think about a text parsing function like sscanf, sprintf scanning cousin. Imagine the SAME situation.
In fact, this is what Microsoft does not realize. With the invention of faster CPUs and more resources, Microsoft has 'jumped' the gun so to speak in terms of 'estimation' by creating 'managed' languages. Do they not realize the reason as to why JAVA failed to be as big as Sun Microsystems wanted? It's the fact the majority of Java implementations are not NATIVE based. The slow code. It's that simple.
People do not realize, most things take very little time to process... HOWEVER... Larger, more time consuming actions use these smaller actions to do a portion of the larger task... That is why when someone sits there waiting for 45 seconds for an operation to be completed, that same task COULD HAVE BEEN done in like 1/3 of the time.
Microsoft taking that plunge with a JIT for platform independency, when in fact for the most part, .NET is Windows only.... Has introduced and multiplied that problem... The consumer complains about things not being done in a timely fashion... .NET managed code (even installed in the CACHE as native) inflates this problem.
What Microsoft SHOULD HAVE DONE for a better OOP programming library, would be to rewrite Windows as an exposed OOP operating system. In this manner, the OOP approach to the OS in terms of a programmer, is as close to the hardware as possible without compromising security of the system.
The SAME TYPE of thinking will be Apple's boom downfall. The music industry is like a roller coaster, it comes and goes... Apple is taking advantage of the current boom, and focusing almost entirely on music... Jobs and his company will hit a reality awakening wall sometime in the near future.
Apple is not thinking of the future, they are thinking of now.
In a little bit of philosophical matter relating to the same issue...
Society has allowed itself to deteriorate and even preparing to chain itself up in locks and chains. What do I mean by that statement?
There is a thinking in the world today, that has been happening for a long time...
Look around you. So many religious based things... People do not realize how much... Without going into too much detail... Alot of society today... There is some person in this country that was held down throughout his life... And albeit not the entire societies fault, but a large portion (not majority, a large portion) and a part of that was due to a conspiracy in which was about religion. It has to do with a thinking of create chaos--->leave clues--->person exposes it.
The dependency and life living on that line of thinking... What happens when that <----> person <----> accomplishes the exposal of things in the government that was intended in the first place?
The learning of society to live in the way they do, will chain itself up... Because that is the only way they have known to live.
Computer industry will even be affected. The music industry has ALOT based off religious matters... With this removal of that line of thinking, when that knight of God does what was intended... Will find that with the proof of existence of that God... And they learn the truth the chaos in the world was not at all God's intention... Or that 007 conspiracy... Where does the inspiration for that music come from from that point?
When those people learn the truth about what our creator through the 5th dimension of evolution discover this... Their careers will be affected greatly.
Which is the reason behind God's warnings throughout the history of mankind on what it is doing to itself. Along with the other things he was trying to get people to realize NOT TO DO.
Creating of situations is like theatre... Although reality in the chaos they create, the celebratory manner in which thinking of 'to conquer in the final battle' thinking... Do people stop and think about that for one second? What are they to do with their careers if that is how they make their money?
And it's also to think on the other end of the stick... Those that made money for themselves through the conspiratory things in society. They will lose out, even more so. In addition to maddening God.
Last edited by JamesSchumacher; September 25th, 2007 at 05:11 PM.
* The Best Reasons to Target Windows 8
Learn some of the best reasons why you should seriously consider bringing your Android mobile development expertise to bear on the Windows 8 platform.
Reply With Quote
Originally Posted by CBasicNet
