#include <stdio.h>
#include <stdlib.h>
#include <time.h>
int
main ( int argc, char *argv[] )
{
long i = 10000000L;
clock_t start, end;
double duration;
printf("Time do %ld loop spent ", i);
start = clock();
while (i--);
end = clock();
duration = (double)(end - start) / CLOCKS_PER_SEC;
printf("%f seconds\n", duration);
return EXIT_SUCCESS;
} /* ---------- end of function main ---------- */
I run the above the program,
The first time I spent 0.031000 seconds.
The second time I spent 0.015000 seconds
If I try again and again, the time spent on will 0.031 or 0.015
seconds
Why have such big difference?
thank you!!!
19  2612 
xianwei wrote:
#include <stdio.h>
#include <stdlib.h>
#include <time.h>
int
main ( int argc, char *argv[] )
{
long i = 10000000L;
clock_t start, end;
double duration;
printf("Time do %ld loop spent ", i);
start = clock();
while (i--);
end = clock();
duration = (double)(end - start) / CLOCKS_PER_SEC;
printf("%f seconds\n", duration);
return EXIT_SUCCESS;
} /* ---------- end of function main ---------- */
I run the above the program,
The first time I spent 0.031000 seconds.
The second time I spent 0.015000 seconds
If I try again and again, the time spent on will 0.031 or 0.015
seconds
Have you ever seen a hummingbird, and wondered
how fast its wings flutter? You might try to find
an answer by measuring the time for ten million beats.
So you set up your highly accurate wingbeat counter,
and then you start your timer: an hourglass ...
--
Eric Sosman es*****@ieee-dot-org.invalid
"xianwei" <ba*********@gmail.coma ¨¦crit dans le message de news: 11**********************@k79g2000hse.googlegroups. com...
#include <stdio.h>
#include <stdlib.h>
#include <time.h>
int
main ( int argc, char *argv[] )
{
long i = 10000000L;
clock_t start, end;
double duration;
printf("Time do %ld loop spent ", i);
start = clock();
while (i--);
end = clock();
duration = (double)(end - start) / CLOCKS_PER_SEC;
printf("%f seconds\n", duration);
return EXIT_SUCCESS;
} /* ---------- end of function main ---------- */
I run the above the program,
The first time I spent 0.031000 seconds.
The second time I spent 0.015000 seconds
If I try again and again, the time spent on will 0.031 or 0.015
seconds
Why have such big difference?
I suspect the clock() function on your system has a granularity of around 15
milliseconds. If this is the case, the clock() function will return the
same value for all calls during each 15 millisecond interval. Depending on
when exactly you start your measurements within that interval, a task
lasting cloless than 15ms can be "clocked" as lasting 0ms or 15ms.
Similarly, one that takes between 15 and 30 might be reposted as taking
exactly 15ms or exactly 30ms.
On top of this granularity issue, you should look into the clock() function.
Does it measure elapsed time? total processor time? processor time spent in
your program vs time spent in the system? or something else even... Your
"timings" will also be affected by other tasks the computer performs while
your program executes, and many other characteristics of you system (cache
memory, bus sharing with i/o devices, etc.)
For your peticular concern, I suggest you try and synchronize your timing
efforts with this small loop:
clock_t last, start;
last = start = clock();
while (start == last) {
start = clock();
}
You should try and measure longer computations, by repeating them in a loop
or increasing the constants.
You should consider using more accurate timing functions such as
non-standard gettimeofday in Linux.
You should repeat the tests many many times, and average the results,
discarding extreme values.
Effective code profiling is *very* difficult. Drawing conclusions or making
changes from profiling data is not easy either: what holds on one
architecture does not necessarily on another one, even just slightly
different. There is no definitive truth in this domain.
--
Chqrlie
On Sep 25, 8:15 pm, Eric Sosman <esos...@ieee-dot-org.invalidwrote:
Have you ever seen a hummingbird, and wondered
how fast its wings flutter? You might try to find
an answer by measuring the time for ten million beats.
Thank you, you are right, I should replace one millions to ten
millions.
When I do that, the time keep in 0.285 - 0.231 seconds, I think this
is
well.
To test how fast humming wings flutter sound not like a good
idea !! :-)
On Sep 25, 8:18 pm, "Charlie Gordon" <n...@chqrlie.orgwrote:
"xianwei" <baikaish...@gmail.coma ¨¦crit dans le message de news:
1190695176.006514.155...@k79g2000hse.googlegroups. com...
#include <stdio.h>
#include <stdlib.h>
#include <time.h>
int
main ( int argc, char *argv[] )
{
long i = 10000000L;
clock_t start, end;
double duration;
printf("Time do %ld loop spent ", i);
start = clock();
while (i--);
end = clock();
duration = (double)(end - start) / CLOCKS_PER_SEC;
printf("%f seconds\n", duration);
return EXIT_SUCCESS;
} /* ---------- end of function main ---------- */
I run the above the program,
The first time I spent 0.031000 seconds.
The second time I spent 0.015000 seconds
If I try again and again, the time spent on will 0.031 or 0.015
seconds
Why have such big difference?
I suspect the clock() function on your system has a granularity of around15
milliseconds. If this is the case, the clock() function will return the
same value for all calls during each 15 millisecond interval. Depending on
when exactly you start your measurements within that interval, a task
lasting cloless than 15ms can be "clocked" as lasting 0ms or 15ms.
Similarly, one that takes between 15 and 30 might be reposted as taking
exactly 15ms or exactly 30ms.
Thank you for you explanation about the question.
You should repeat the tests many many times, and average the results,
discarding extreme values.
Yes, when I larger the loop times, the spent times differs in a small
point.
Thanks you enthusiasm.
xianwei wrote:
>
.... snip ...
>
I run the above the program,
The first time I spent 0.031000 seconds.
The second time I spent 0.015000 seconds
If I try again and again, the time spent on will 0.031 or 0.015
seconds. Why have such big difference?
Because the resolution of your clock is obviously roughly 0.0155 S.
--
Chuck F (cbfalconer at maineline dot net)
Available for consulting/temporary embedded and systems.
<http://cbfalconer.home.att.net>
--
Posted via a free Usenet account from http://www.teranews.com
CBFalconer <cb********@yahoo.comwrites:
xianwei wrote:
... snip ...
>>
I run the above the program,
The first time I spent 0.031000 seconds.
The second time I spent 0.015000 seconds
If I try again and again, the time spent on will 0.031 or 0.015
seconds. Why have such big difference?
Because the resolution of your clock is obviously roughly 0.0155 S.
Most likely 1/60 second, but that's just a semi-educated guess.
--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <* <http://users.sdsc.edu/~kst>
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
Keith Thompson wrote:
CBFalconer <cb********@yahoo.comwrites:
>xianwei wrote:
... snip ...
>>>
I run the above the program,
The first time I spent 0.031000 seconds.
The second time I spent 0.015000 seconds
If I try again and again, the time spent on will 0.031 or 0.015
seconds. Why have such big difference?
Because the resolution of your clock is obviously roughly 0.0155 S.
Most likely 1/60 second, but that's just a semi-educated guess.
PCs can have some peculiar number, tied back to the old XT.
--
Chuck F (cbfalconer at maineline dot net)
Available for consulting/temporary embedded and systems.
<http://cbfalconer.home.att.net>
--
Posted via a free Usenet account from http://www.teranews.com
On 2007-09-25 21:40, CBFalconer <cb********@yahoo.comwrote:
Keith Thompson wrote:
>CBFalconer <cb********@yahoo.comwrites:
>>Because the resolution of your clock is obviously roughly 0.0155 S.
Most likely 1/60 second, but that's just a semi-educated guess.
PCs can have some peculiar number, tied back to the old XT.
That would be 1/18.2 seconds (or rather 1 / (4.77E6 / 4 / 65536)
seconds). Was CLOCKS_PER_SEC actually a floating point constant on
MS-DOS compilers? I don't remember but I guess it must have been.
hp
--
_ | Peter J. Holzer | I know I'd be respectful of a pirate
|_|_) | Sysadmin WSR | with an emu on his shoulder.
| | | hj*@hjp.at |
__/ | http://www.hjp.at/ | -- Sam in "Freefall"
"Peter J. Holzer" <hj*********@hjp.ata écrit dans le message de news: sl************************@zeno.hjp.at...
On 2007-09-25 21:40, CBFalconer <cb********@yahoo.comwrote:
>Keith Thompson wrote:
>>CBFalconer <cb********@yahoo.comwrites:
Because the resolution of your clock is obviously roughly 0.0155 S.
Most likely 1/60 second, but that's just a semi-educated guess.
PCs can have some peculiar number, tied back to the old XT.
That would be 1/18.2 seconds (or rather 1 / (4.77E6 / 4 / 65536)
seconds). Was CLOCKS_PER_SEC actually a floating point constant on
MS-DOS compilers? I don't remember but I guess it must have been.
For those who wonder why 18.2 Hz, that makes 64K ticks per hour.
This may be the very reason for the rather odd original PC frequency:
65536 * 65536 * 4 / 3600 = 4.772185 MHz
--
Chqrlie.
Charlie Gordon wrote:
"Peter J. Holzer" <hj*********@hjp.ata écrit dans le message de news:
sl************************@zeno.hjp.at...
>On 2007-09-25 21:40, CBFalconer <cb********@yahoo.comwrote:
>>Keith Thompson wrote:
CBFalconer <cb********@yahoo.comwrites:
Because the resolution of your clock is obviously roughly 0.0155 S.
Most likely 1/60 second, but that's just a semi-educated guess.
PCs can have some peculiar number, tied back to the old XT.
That would be 1/18.2 seconds (or rather 1 / (4.77E6 / 4 / 65536)
seconds). Was CLOCKS_PER_SEC actually a floating point constant on
MS-DOS compilers? I don't remember but I guess it must have been.
No. CLOCKS_PER_SEC is (mostly) an int.
Watcom compiler:
#define CLOCKS_PER_SEC 100
Microsoft C Compiler Version 2.00.000 V 6.00A
#define CLOCKS_PER_SEC 1000
Borland BC5 however disagrees.
#define CLOCKS_PER_SEC 1000.0
Digital Mars compiler:
#define CLOCKS_PER_SEC ((clock_t)1000)
In article <46***********************@news.free.fr>,
Charlie Gordon <ne**@chqrlie.orgwrote:
>This may be the very reason for the rather odd original PC frequency:
65536 * 65536 * 4 / 3600 = 4.772185 MHz
No, that comes from the 4/3 the frequency of an NTSC colour
sub-carrier oscillator. I'm not sure if the PC had one of these
anyway and it was reused, or if they were just cheap.
-- Richard
--
"Consideration shall be given to the need for as many as 32 characters
in some alphabets" - X3.4, 1963.
"Richard Tobin" <ri*****@cogsci.ed.ac.uka écrit dans le message de news:
fd***********@pc-news.cogsci.ed.ac.uk...
In article <46***********************@news.free.fr>,
Charlie Gordon <ne**@chqrlie.orgwrote:
>>This may be the very reason for the rather odd original PC frequency:
65536 * 65536 * 4 / 3600 = 4.772185 MHz
No, that comes from the 4/3 the frequency of an NTSC colour
sub-carrier oscillator. I'm not sure if the PC had one of these
anyway and it was reused, or if they were just cheap.
I am positive it did not, since the graphics was done on a separate adapter
board.
But you are right, these oscillators were common and cheap, and the
frequency may not have been exactly what I stated. The BIOS did take
advantage of the 64K ticks in an hour, but there might have been an
adjustment, I'll take a look.
--
Chqrlie.
On 2007-09-26 16:17, Sjouke Burry <bu*************@ppllaanneett.nnlllwrote:
Charlie Gordon wrote:
>"Peter J. Holzer" <hj*********@hjp.ata écrit dans le message de news:
sl************************@zeno.hjp.at...
>>On 2007-09-25 21:40, CBFalconer <cb********@yahoo.comwrote:
PCs can have some peculiar number, tied back to the old XT.
That would be 1/18.2 seconds (or rather 1 / (4.77E6 / 4 / 65536)
seconds). Was CLOCKS_PER_SEC actually a floating point constant on
MS-DOS compilers? I don't remember but I guess it must have been.
No. CLOCKS_PER_SEC is (mostly) an int.
Watcom compiler:
#define CLOCKS_PER_SEC 100
Microsoft C Compiler Version 2.00.000 V 6.00A
#define CLOCKS_PER_SEC 1000
Borland BC5 however disagrees.
#define CLOCKS_PER_SEC 1000.0
Digital Mars compiler:
#define CLOCKS_PER_SEC ((clock_t)1000)
These examples are rather irrelevant since the clock frequency in these
cases is (presumably) exactly 100 Hz or 1000 Hz. But in MS-DOS the
frequency was 18.2 Hz. If CLOCKS_PER_SEC was defined as 18, that would
have caused an error of about 1.1%, which I think would have been
noticable. (Maybe I should get out my old Turbo-C++ 1.0 disks and have a
look).
hp
--
_ | Peter J. Holzer | I know I'd be respectful of a pirate
|_|_) | Sysadmin WSR | with an emu on his shoulder.
| | | hj*@hjp.at |
__/ | http://www.hjp.at/ | -- Sam in "Freefall"
Peter J. Holzer wrote:
On 2007-09-26 16:17, Sjouke Burry <bu*************@ppllaanneett.nnlllwrote:
>Charlie Gordon wrote:
>>"Peter J. Holzer" <hj*********@hjp.ata écrit dans le message de news:
sl************************@zeno.hjp.at...
On 2007-09-25 21:40, CBFalconer <cb********@yahoo.comwrote:
PCs can have some peculiar number, tied back to the old XT.
That would be 1/18.2 seconds (or rather 1 / (4.77E6 / 4 / 65536)
seconds). Was CLOCKS_PER_SEC actually a floating point constant on
MS-DOS compilers? I don't remember but I guess it must have been.
No. CLOCKS_PER_SEC is (mostly) an int.
Watcom compiler:
#define CLOCKS_PER_SEC 100
Microsoft C Compiler Version 2.00.000 V 6.00A
#define CLOCKS_PER_SEC 1000
Borland BC5 however disagrees.
#define CLOCKS_PER_SEC 1000.0
Digital Mars compiler:
#define CLOCKS_PER_SEC ((clock_t)1000)
These examples are rather irrelevant since the clock frequency in these
cases is (presumably) exactly 100 Hz or 1000 Hz. But in MS-DOS the
frequency was 18.2 Hz. If CLOCKS_PER_SEC was defined as 18, that would
have caused an error of about 1.1%, which I think would have been
noticable. (Maybe I should get out my old Turbo-C++ 1.0 disks and have a
look).
hp
Pardon me??? That whole list is from dos computers.
However they all do modify their clockticks in some way.
I have never seen a clocktick to have a one to one relation
to the 18.2 HZ clock, they all modify that to give a
"decimal" clocktick.
When however you print all clockchanges,you can recognize the
relation to the systemclock.
"Peter J. Holzer" <hj*********@hjp.atwrites:
On 2007-09-26 16:17, Sjouke Burry <bu*************@ppllaanneett.nnlllwrote:
>Charlie Gordon wrote:
>>"Peter J. Holzer" <hj*********@hjp.ata écrit dans le message de news:
sl************************@zeno.hjp.at...
On 2007-09-25 21:40, CBFalconer <cb********@yahoo.comwrote:
PCs can have some peculiar number, tied back to the old XT.
That would be 1/18.2 seconds (or rather 1 / (4.77E6 / 4 / 65536)
seconds). Was CLOCKS_PER_SEC actually a floating point constant on
MS-DOS compilers? I don't remember but I guess it must have been.
No. CLOCKS_PER_SEC is (mostly) an int.
Watcom compiler:
#define CLOCKS_PER_SEC 100
Microsoft C Compiler Version 2.00.000 V 6.00A
#define CLOCKS_PER_SEC 1000
Borland BC5 however disagrees.
#define CLOCKS_PER_SEC 1000.0
Digital Mars compiler:
#define CLOCKS_PER_SEC ((clock_t)1000)
These examples are rather irrelevant since the clock frequency in these
cases is (presumably) exactly 100 Hz or 1000 Hz. But in MS-DOS the
frequency was 18.2 Hz. If CLOCKS_PER_SEC was defined as 18, that would
have caused an error of about 1.1%, which I think would have been
noticable. (Maybe I should get out my old Turbo-C++ 1.0 disks and have a
look).
CLOCKS_PER_SEC doesn't necessarily match the actual clock frequency.
It just gives you the factor by which you need to scale the value
returned by the clock() function.
For example, a physical clock frequency of 18.2 Hz and a
CLOCKS_PER_SEC value of 1000 would be consistent. Successive calls to
clock() might return
0
55
110
165
...
989
1044
and so forth; each result exceeds the prievous one by 54 or 55.
--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <* <http://users.sdsc.edu/~kst>
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
Keith Thompson <ks***@mib.orgwrites:
CLOCKS_PER_SEC doesn't necessarily match the actual clock frequency.
It just gives you the factor by which you need to scale the value
returned by the clock() function.
And in fact, CLOCKS_PER_SEC has the same value on all
XSI-conformant UNIX systems, even though such systems are not
required to have a clock that ticks at any particular frequency.
--
Ben Pfaff http://benpfaff.org
On 2007-09-27 17:34, Sjouke Burry <bu*************@ppllaanneett.nnlllwrote:
Peter J. Holzer wrote:
>On 2007-09-26 16:17, Sjouke Burry <bu*************@ppllaanneett.nnlllwrote:
>>Charlie Gordon wrote:
"Peter J. Holzer" <hj*********@hjp.ata écrit dans le message de news:
sl************************@zeno.hjp.at...
On 2007-09-25 21:40, CBFalconer <cb********@yahoo.comwrote:
>PCs can have some peculiar number, tied back to the old XT.
That would be 1/18.2 seconds (or rather 1 / (4.77E6 / 4 / 65536)
seconds). Was CLOCKS_PER_SEC actually a floating point constant on
MS-DOS compilers? I don't remember but I guess it must have been.
No. CLOCKS_PER_SEC is (mostly) an int.
Watcom compiler:
#define CLOCKS_PER_SEC 100
Microsoft C Compiler Version 2.00.000 V 6.00A
#define CLOCKS_PER_SEC 1000
Borland BC5 however disagrees.
#define CLOCKS_PER_SEC 1000.0
Digital Mars compiler:
#define CLOCKS_PER_SEC ((clock_t)1000)
These examples are rather irrelevant since the clock frequency in these
cases is (presumably) exactly 100 Hz or 1000 Hz. But in MS-DOS the
frequency was 18.2 Hz. If CLOCKS_PER_SEC was defined as 18, that would
have caused an error of about 1.1%, which I think would have been
noticable. (Maybe I should get out my old Turbo-C++ 1.0 disks and have a
look).
Pardon me??? That whole list is from dos computers.
However they all do modify their clockticks in some way.
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ ^^^^^^
That's the crux. If they modify the clockticks, they aren't the same any
more. If a program does NOT modify the clock ticks, the frequency is
18.2 Hz, which is not an integral number.
I have never seen a clocktick to have a one to one relation
to the 18.2 HZ clock, they all modify that to give a
"decimal" clocktick.
I am positive that Turbo C (up to and including Turbo-C++ 1.0, which
was the last version I've used) did not modify the clock rate, because
on ocassion I needed a higher resolution and had to reprogram the timer
chip myself. It is possible that clock did the conversion internally,
as Keith suggests, but I doubt that, because:
* I think I would remember it
* I found some old benchmark code of mine, which contains a comment
on the granularity of the times() function on Ultrix, but none on the
granularity of clock on MS-DOS. I think I would have added a comment
if granularity of clock was worse than CLOCKS_PER_SEC suggested.
So, I think that CLOCKS_PER_SEC should have been 18.2 on Turbo-C, but I
don't remember if they actually defined it as 18.2 or approximated it
with 18. However, I notice that in your examples the Borland compiler is
the only one which defines CLOCKS_PER_SEC as a floating point constant,
which strongly suggests that it was 18.2 in earlier versions and when
they changed it to 1000, they didn't want to break programs which
(erroneously) assumed that CLOCKS_PER_SEC was of type double.
hp
--
_ | Peter J. Holzer | I know I'd be respectful of a pirate
|_|_) | Sysadmin WSR | with an emu on his shoulder.
| | | hj*@hjp.at |
__/ | http://www.hjp.at/ | -- Sam in "Freefall"
On 2007-09-27 22:34, Keith Thompson <ks***@mib.orgwrote:
"Peter J. Holzer" <hj*********@hjp.atwrites:
>On 2007-09-26 16:17, Sjouke Burry <bu*************@ppllaanneett.nnlllwrote:
>>Charlie Gordon wrote:
"Peter J. Holzer" <hj*********@hjp.ata écrit dans le message de news:
sl************************@zeno.hjp.at...
On 2007-09-25 21:40, CBFalconer <cb********@yahoo.comwrote:
>PCs can have some peculiar number, tied back to the old XT.
That would be 1/18.2 seconds (or rather 1 / (4.77E6 / 4 / 65536)
seconds). Was CLOCKS_PER_SEC actually a floating point constant on
MS-DOS compilers? I don't remember but I guess it must have been.
No. CLOCKS_PER_SEC is (mostly) an int.
Watcom compiler:
#define CLOCKS_PER_SEC 100
Microsoft C Compiler Version 2.00.000 V 6.00A
#define CLOCKS_PER_SEC 1000
Borland BC5 however disagrees.
#define CLOCKS_PER_SEC 1000.0
Digital Mars compiler:
#define CLOCKS_PER_SEC ((clock_t)1000)
These examples are rather irrelevant since the clock frequency in these
cases is (presumably) exactly 100 Hz or 1000 Hz. But in MS-DOS the
frequency was 18.2 Hz. If CLOCKS_PER_SEC was defined as 18, that would
have caused an error of about 1.1%, which I think would have been
noticable. (Maybe I should get out my old Turbo-C++ 1.0 disks and have a
look).
CLOCKS_PER_SEC doesn't necessarily match the actual clock frequency.
I know, I have used systems where they didn't match (in fact I'm using
one right now). I am quite sure that they did match on MS-DOS with the
Turbo-C compilers, though. I should have written "... the unit of time
returned by clock is exactly 1/100 or 1/1000 second" instead of "...
clock frequency ...".
hp
--
_ | Peter J. Holzer | I know I'd be respectful of a pirate
|_|_) | Sysadmin WSR | with an emu on his shoulder.
| | | hj*@hjp.at |
__/ | http://www.hjp.at/ | -- Sam in "Freefall"
Just for reference:
Assuming a stock IBM PC without the counter reprogrammed,
the "18.2 per second" interrupt was derived as follows:
The IBM PC Clock Crystal oscillates at 4770000 Hertz.
4770000 / 4 / 65536 = 18.19610595703125 Hertz.
This is close to 65536 ticks per hour:
3600 Seconds (1 Hour) / 65536 = 18.20444... Hertz.
And is related to a NTSC Color Crystal at 14318180 Hertz:
14318180 / 12 / 65536 = 18.2065073649088541666... Hertz.
That 4770000 Hertz IBM PC Crystal had a best case accuracy
of +/- 0.0005%, a typical accuracy of +/- 0.002%, and a
worst case accuracy of +/- 0.01%. Some servers have oven
stabilized crystals with an accuracy approaching 0.00001%
(0.1 ppm).
Also, There is a list of interrupts and IRQs here: http://docs.huihoo.com/help-pc/int-int_table.html
--
Guy Macon
<http://www.guymacon.com/> This thread has been closed and replies have been disabled. Please start a new discussion. Similar topics
by: Brandon J. Van Every |
last post by:
What's better about Ruby than Python? I'm sure there's something. What is
it?
This is not a troll. I'm language shopping and I want people's answers. I
don't know beans about Ruby or have...
|
by: nospam |
last post by:
Reasons for a 3-tier achitecture for the WEB?
(NOTE: I said, WEB, NOT WINDOWS.
DON'T shoot your mouth off if you don't understand the difference.)
I hear only one reason and that's to switch a...
|
by: Sarah Tanembaum |
last post by:
Beside its an opensource and supported by community, what's the fundamental
differences between PostgreSQL and those high-price commercial database (and
some are bloated such as Oracle) from...
|
by: Charles Law |
last post by:
Hi guys
I have a time critical process, running on a worker thread. By "time
critical", I mean that certain parts of the process must be completed in a
specific time frame. The time when the...
|
by: SSG |
last post by:
Hi All!
I know how to calculate the running time of a particular routine, but i
want to know how to reduce the running time in a program...........
can anyone knows help me........
also...
|
by: colin |
last post by:
Hi,
I profile my code and find its spending a lot of time doing implicit
conversions from similar structures.
the conversions are mainly things like this
class Point
{
implicit conversion...
|
by: Charles Arthur |
last post by:
How do i turn on java script on a villaon, callus and itel keypad mobile phone
|
by: BarryA |
last post by:
What are the essential steps and strategies outlined in the Data Structures and Algorithms (DSA) roadmap for aspiring data scientists? How can individuals effectively utilize this roadmap to progress...
|
by: Sonnysonu |
last post by:
This is the data of csv file
1 2 3
1 2 3
1 2 3
1 2 3
2 3
2 3
3
the lengths should be different i have to store the data by column-wise with in the specific length.
suppose the i have to...
|
by: Hystou |
last post by:
Most computers default to English, but sometimes we require a different language, especially when relocating. Forgot to request a specific language before your computer shipped? No problem! You can...
|
by: Oralloy |
last post by:
Hello folks,
I am unable to find appropriate documentation on the type promotion of bit-fields when using the generalised comparison operator "<=>".
The problem is that using the GNU compilers,...
|
by: jinu1996 |
last post by:
In today's digital age, having a compelling online presence is paramount for businesses aiming to thrive in a competitive landscape. At the heart of this digital strategy lies an intricately woven...
|
by: Hystou |
last post by:
Overview:
Windows 11 and 10 have less user interface control over operating system update behaviour than previous versions of Windows. In Windows 11 and 10, there is no way to turn off the Windows...
|
by: tracyyun |
last post by:
Dear forum friends,
With the development of smart home technology, a variety of wireless communication protocols have appeared on the market, such as Zigbee, Z-Wave, Wi-Fi, Bluetooth, etc. Each...
|
by: agi2029 |
last post by:
Let's talk about the concept of autonomous AI software engineers and no-code agents. These AIs are designed to manage the entire lifecycle of a software development project—planning, coding, testing,...
| |
