[GHC] #13070: time after evaluation
#13070: time after evaluation -------------------------------------+------------------------------------- Reporter: vanto | Owner: Type: feature | Status: new request | Priority: normal | Milestone: Component: GHCi | Version: 8.0.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- the {{{:set +s}}} gives the time after each evaluation.This time may have a difference of 68% in same calculation.It should not change after each evaluation of computation. Can we have a fixed and real time? -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/13070 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler
#13070: time after evaluation -------------------------------------+------------------------------------- Reporter: vanto | Owner: Type: feature request | Status: closed Priority: normal | Milestone: 8.0.2 Component: GHCi | Version: 8.0.1 Resolution: invalid | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by dfeuer): * status: new => closed * resolution: => invalid * milestone: => 8.0.2 Comment: There are quite a few situations in which the time can legitimately vary between evaluations. For example, {{{
x = big_expensive_computation f x <slow answer> f x
}}}
If you can point out a specific example where you think the times should be similar but they are not, you can reopen this ticket with more details. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/13070#comment:1 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler
#13070: time after evaluation -------------------------------------+------------------------------------- Reporter: vanto | Owner: Type: feature request | Status: new Priority: normal | Milestone: 8.0.2 Component: GHCi | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by vanto): * status: closed => new * resolution: invalid => Comment: Thank you.[[BR]] Though your code in the answer is not adapted I agree with you. However the timing varies. Timing (and memory) is given roughly. If it is for educational purpose then why not, otherwise the result is wrong.[[BR]][[BR]] You know that time never varies in a computation into a CPU. It is impossible! Here is a function:[[BR]] {{{ fact :: Integer -> Integer fact n = if n==0 then 1 else n*fact(n-1) }}} {{{ let x = fact 123456 }}} In GHCi, the time to compute 10 times x is:[[BR]] {{{ 1) 55.10 secs, 21,427,209,296 bytes 2) 5.07 secs, 230,369,932 bytes 3) 5.05 secs, 230,369,932 bytes 4) 4.98 secs, 230,372,432 bytes 5) 4.59 secs, 230,367,100 bytes 6) 5.57 secs, 230,372,576 bytes 7) 5.58 secs, 230,368,404 bytes 8) 5.19 secs, 230,367,872 bytes 9) 5.37 secs, 230,372,576 bytes 10) 5.32 secs, 230,368,404 bytes }}} However as you can see, timing is not correct to return x. And is 55.10 secs a correct time? I say no. See evidence below. If I compute 10 times "fact 123456" I have:[[BR]] {{{ 1) 50.79 secs, 21,427,207,192 bytes 2) 49.66 secs, 21,427,207,840 bytes 3) 50.08 secs, 21,427,208,388 bytes 4) 49.23 secs, 21,427,206,484 bytes 5) 49.12 secs, 21,427,207,840 bytes 6) 48.58 secs, 21,427,207,788 bytes 7) 47.55 secs, 21,427,209,036 bytes 8) 47.66 secs, 21,427,206,536 bytes 9) 48.16 secs, 21,427,206,484 bytes 10) 46.88 secs, 21,427,208,984 bytes }}} Which is the real time? And if I compute 10 times "fact 12345" I have:[[BR]] {{{ 1) 0.80 secs, 172,989,980 bytes 2) 1.06 secs, 172,985,364 bytes 3) 0.89 secs, 172,986,620 bytes 4) 0.83 secs, 172,985,364 bytes 5) 0.86 secs, 172,984,624 bytes 6) 0.78 secs, 172,988,552 bytes 7) 0.81 secs, 172,986,924 bytes 8) 0.87 secs, 172,987,520 bytes 9) 1.08 secs, 172,985,728 bytes 10) 1.12 secs, 172,985,364 bytes }}} The timing varies. This is not correct. And as you can see, the amount of memory is not the same. In a Central Processing Unit (CPU) the activities are cyclical. The processor fetches an instruction, performs the operations required, fetches the next instruction, and so on.[[BR]] This orderly sequence of events requires a free running oscillator clock which furnishes the reference for all processor actions.[[BR]] The combined fetch and execution of a single instruction is referred to as an Instruction Cycle. The portion of a cycle identified with a clearly defined activity is called a State. And the interval between pulses of the timing oscillator is referred to as a Clock Period.[[BR]] As a general rule, one or more clock periods are necessary for the completion of a state, and there are several states in a cycle. For example, with Intel 8080A CPU, the instruction set "MOVr1,r2" which is "Move register to register" has 5 Clock Cycles, and the instruction set "INR M" which is "Increment memory" has 10 Clock Cycles.[[BR]][[BR]] Time never varies.[[BR]][[BR]] I think that the code which implements {{{:set +s}}} is to be rewritten if the values of time (and memory) are used for work otherwise it is acceptable, but it would be better to indicate it in the help of GHCi that the time is approximate and the memory also.[[BR]] What do you think? -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/13070#comment:2 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler
#13070: time after evaluation -------------------------------------+------------------------------------- Reporter: vanto | Owner: Type: feature request | Status: closed Priority: normal | Milestone: 8.0.2 Component: GHCi | Version: 8.0.1 Resolution: invalid | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by rwbarton): * status: new => closed * resolution: => invalid Comment: If you can figure out how to run ghci on a processor from 1974 then you might get consistent runtimes from ghci. With a modern preemptive- multitasking OS using virtual memory and running on a pipelining, branch- predicting processor with many levels of caching, where a memory read might cost 4 to 200 cycles depending what level of the cache it is in (or orders of magnitude more if it's swapped out to disk!), you cannot add up cycle counts like this any more. Unfortunately it does mean that there is a significant, effectively random component of program runtime; that's the cost of computers getting many thousands of times faster. Even your processor's clock rate is not constant any more. It's increased and decreased according to demand to save power when the processor is idle, or to avoid overheating. The numbers displayed by `:set +s` are the real times, and they are not fixed because the real times are not fixed. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/13070#comment:3 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler
#13070: time after evaluation -------------------------------------+------------------------------------- Reporter: vanto | Owner: Type: feature request | Status: new Priority: normal | Milestone: 8.0.2 Component: GHCi | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by vanto): * status: closed => new * resolution: invalid => Comment: Be polite M. rwbarton.[[BR]] Instead of giving the time in seconds it is better to give it as a clock cycle.[[BR]] 8080 was an example to show clock cycles, because I know this processor. But I am aware of the latest technologies.[[BR]] What were you doing in the year of 1971?[[BR]] Me, I developed on this microprocessor, with instructions set. And you?[[BR]] If you hold the truth... ask the engineers at Intel Corp, please.[[BR]] Time never varies, because time are clock cycles and clock cycles do not varies.[[BR]] -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/13070#comment:4 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler
#13070: time after evaluation -------------------------------------+------------------------------------- Reporter: vanto | Owner: Type: feature request | Status: new Priority: normal | Milestone: 8.0.2 Component: GHCi | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by vanto): I would like to say a precision to avoid all confusions. I think it is a matter of importance. There is a difference between the frequency of the microprocessor and the clock cycles of an instruction set from the processor.[[BR]] Somebody said that real times are not fixed. Well, that is the problem. We speak about time, we speak about Physics. The time of which you speak is a relative (real) time. With this time you can't do a comparison of values because, as you say, it is not fixed. We need a referential to something. And something is the clock cycles of instruction set. The clock cycles of an instruction set from the CPU nevers varies. You can have 2GHz CPU or 3GHz CPU, clock cycles never varies. [[BR]] Suppose you have an instruction set MOVX,X which move register from register in a core i7 CPU and takes 5 clock cycles. With 2Ghz CPU or with 3GHz CPU MOVX,X will always keep 5 clock cycles. The difference is in the speed of the processor. Do you understand this?[[BR]] If you compute starting from that you have a true time and you can make comparison with another values. [[BR]] Thus currently the number displayed by :set +s is a relative time which is useless, and the code which implements this is to be rewritten.[[BR]] Of course you can keep the code such as and not change it if it is appropriate to you. But I invite you to consider that.[[BR]] When some people are disturbed by something they don't know, they quickly close tickets. Let others give their opinions, please.[[BR]] -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/13070#comment:5 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler
#13070: time after evaluation -------------------------------------+------------------------------------- Reporter: vanto | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: GHCi | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by mpickering): * milestone: 8.0.2 => -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/13070#comment:6 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler
#13070: time after evaluation -------------------------------------+------------------------------------- Reporter: vanto | Owner: (none) Type: feature request | Status: closed Priority: normal | Milestone: Component: GHCi | Version: 8.0.1 Resolution: invalid | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by vanto): * status: new => closed * resolution: => invalid Comment: Rwbarton, I looked at the question from all side and you are right. The clock cycles of an instruction do not varies but the number of clock cycles to go from the registers to memory or cache memory can be different. So it is impossible to have an absolute time (CPU time) but only a relative time of CPU in current processors. Sorry!. I closed this ticket. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/13070#comment:7 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler
participants (1)
-
GHC