Optimized gcc 4.3.0 build on Windows returns 0 secs for all time values of system-process-attributes

Optimized gcc 4.3.0 build on Windows returns 0 secs for all time values of system-process-attributes

[Juanma Barranquero]

Building Emacs on Windows with the following compiler

  gcc (GCC) 4.3.0 20080305 (alpha-testing) mingw-20080502

and optimizations on, Emacs returns 0 seconds for all time values
computed in w32.c:process_times:

ELISP> (mapcar (lambda (p) (assq 'start (system-process-attributes
p))) (list-system-processes))
(nil
 (start 0 0 0)
 (start 0 0 484375)
 (start 0 0 484375)
 (start 0 0 921875)
 ;;; etc

and the same goes for 'utime, 'ctime and 'etime.

Could someone please try with another version of MinGW GCC?

    Juanma

Re: Optimized gcc 4.3.0 build on Windows returns 0 secs for all time values of system-process-attributes

[dhruva]

Hello,

On Wed, Dec 31, 2008 at 6:30 PM, Juanma Barranquero <lekktu@gmail.com> wrote:
> Building Emacs on Windows with the following compiler
>
>  gcc (GCC) 4.3.0 20080305 (alpha-testing) mingw-20080502
>
> and optimizations on, Emacs returns 0 seconds for all time values
> computed in w32.c:process_times:
>
> ELISP> (mapcar (lambda (p) (assq 'start (system-process-attributes
> p))) (list-system-processes))
> (nil
>  (start 0 0 0)
>  (start 0 0 484375)
>  (start 0 0 484375)
>  (start 0 0 921875)
>  ;;; etc
>
> and the same goes for 'utime, 'ctime and 'etime.
>
> Could someone please try with another version of MinGW GCC?

I confirm the same results, I am having a similar setup on WXP.

-dhruva

-- 
Contents reflect my personal views only!

Re: Optimized gcc 4.3.0 build on Windows returns 0 secs for all time values of system-process-attributes

[Eli Zaretskii]

> Date: Wed, 31 Dec 2008 14:00:33 +0100
> From: "Juanma Barranquero" <lekktu@gmail.com>
> 
> Building Emacs on Windows with the following compiler
> 
>   gcc (GCC) 4.3.0 20080305 (alpha-testing) mingw-20080502
> 
> and optimizations on, Emacs returns 0 seconds for all time values
> computed in w32.c:process_times:
> 
> ELISP> (mapcar (lambda (p) (assq 'start (system-process-attributes
> p))) (list-system-processes))
> (nil
>  (start 0 0 0)
>  (start 0 0 484375)
>  (start 0 0 484375)
>  (start 0 0 921875)
>  ;;; etc
> 
> and the same goes for 'utime, 'ctime and 'etime.
> 
> Could someone please try with another version of MinGW GCC?

It works for me with GCC 3.4.2 and MinGW 3.14:

 (mapcar (lambda (p) (assq 'start (system-process-attributes p))) (list-system-processes))

  => (nil (start 0 0 0) (start 18778 61572 203125) (start 18778 61575 984375) (start 18778 61576 671875) (start 18778 61578 640625) (start 18778 61578 687500) (start 18778 61580 390625) (start 18778 61580 953125) (start 18778 61581 203125) (start 18778 61581 296875) (start 18778 61581 906250) (start 18778 61582 140625) (start 18778 61584 875000) (start 18778 61585 31250) (start 18778 61591 781250) (start 18778 61592 406250) (start 18778 61592 562500) (start 18778 61592 953125) (start 18778 61593 78125) (start 18778 61593 234375) (start 18778 61593 359375) (start 18778 61596 828125) (start 18778 61596 875000) (start 18778 61604 93750) (start 18778 61699 156250) (start 18778 61702 15625) (start 18778 61702 250000) (start 18778 61702 812500) (start 18778 61704 390625) (start 18778 61704 98437
 5) (start 18778 61705 921875) (start 18778 61709 828125) (start 18778 61712 828125) (start 18778 61713 62500) (start 18778 61714 328125) (start 18778 61715 671875) (start 18778 61715 984375) (start 

Could you please step into process_times and ltime (or add printf's if
stepping doesn't work), and see what is going wrong and where?  Or
maybe it's convert_time_raw that fails? do other callers of
convert_time_raw still work?

Re: Optimized gcc 4.3.0 build on Windows returns 0 secs for all time values of system-process-attributes

[Juanma Barranquero]

On Wed, Dec 31, 2008 at 20:12, Eli Zaretskii <eliz@gnu.org> wrote:

> It works for me with GCC 3.4.2 and MinGW 3.14:

Optimized or unoptimized build?

> Could you please step into process_times and ltime (or add printf's if
> stepping doesn't work), and see what is going wrong and where?

Stepping isn't much helpful because most variables are optimized away.

As for printf, I'm not sure what's wrong, but

    long double x = 3.5;
    printf ("f = %Lf\n", x);
    printf ("g = %Lg\n", x);

  =>

f = -26815615859885194000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
000000000000000000000000000000.000000
g = -2.68156e+154

(Not just with gcc 4.3.0, I get the same result with 3.4.5.)

Am I missing something obvious?

I tried rewriting w32.c:process_time to do time computations by using
ULARGE_INTEGER (see attached patch), as the Platform SDK recommends,
and it works fine. Why it is implemented with long doubles?

    Juanma


Index: src/w32.c
===================================================================
RCS file: /sources/emacs/emacs/src/w32.c,v
retrieving revision 1.157
diff -u -2 -r1.157 w32.c
--- src/w32.c	19 Dec 2008 19:50:39 -0000	1.157
+++ src/w32.c	31 Dec 2008 17:04:23 -0000
@@ -3778,7 +3778,7 @@
 {
   FILETIME ft_creation, ft_exit, ft_kernel, ft_user, ft_current;
-  long ctime_sec, ctime_usec, stime_sec, stime_usec, utime_sec, utime_usec;
-  long etime_sec, etime_usec;
-  long double tem1, tem2, tem;
+  DWORD ctime_sec, ctime_usec, stime_sec, stime_usec, utime_sec, utime_usec;
+  DWORD etime_sec, etime_usec;
+  ULARGE_INTEGER tem1, tem2, tem, utc;

   if (!h_proc
@@ -3788,31 +3788,43 @@
     return 0;

+  utc.LowPart = utc_base_ft.dwLowDateTime;
+  utc.HighPart = utc_base_ft.dwHighDateTime;
+
   GetSystemTimeAsFileTime (&ft_current);

-  tem1 = convert_time_raw (ft_kernel) * 0.1L;
-  stime_usec = fmodl (tem1, 1000000.0L);
-  stime_sec = tem1 * 0.000001L;
+  tem1.LowPart = ft_kernel.dwLowDateTime;
+  tem1.HighPart = ft_kernel.dwHighDateTime;
+  tem1.QuadPart /= 10L;
+  stime_usec = tem1.QuadPart % 1000000L;
+  stime_sec = tem1.QuadPart / 1000000L;
   *stime = ltime (stime_sec, stime_usec);
-  tem2 = convert_time_raw (ft_user) * 0.1L;
-  utime_usec = fmodl (tem2, 1000000.0L);
-  utime_sec = tem2 * 0.000001L;
+  tem2.LowPart = ft_user.dwLowDateTime;
+  tem2.HighPart = ft_user.dwHighDateTime;
+  tem2.QuadPart /= 10L;
+  utime_usec = tem2.QuadPart % 1000000L;
+  utime_sec = tem2.QuadPart / 1000000L;
   *utime = ltime (utime_sec, utime_usec);
-  tem = convert_time_raw (ft_creation);
+  tem.LowPart = ft_creation.dwLowDateTime;
+  tem.HighPart = ft_creation.dwHighDateTime;
   /* Process no 4 (System) returns zero creation time.  */
-  if (tem)
-    tem = (tem - utc_base) * 0.1;
-  ctime_usec = fmodl (tem, 1000000.0L);
-  ctime_sec = tem * 0.000001L;
+  if (tem.QuadPart)
+    tem.QuadPart = (tem.QuadPart - utc.QuadPart) / 10L;
+  ctime_usec = tem.QuadPart % 1000000L;
+  ctime_sec = tem.QuadPart / 1000000L;
   *ctime = ltime (ctime_sec, ctime_usec);
-  if (tem)
-    tem = (convert_time_raw (ft_current) - utc_base) * 0.1L - tem;
-  etime_usec = fmodl (tem, 1000000.0L);
-  etime_sec = tem * 0.000001L;
+  if (tem.QuadPart)
+    {
+      ULARGE_INTEGER current;
+      current.LowPart = ft_current.dwLowDateTime;
+      current.HighPart = ft_current.dwHighDateTime;
+      tem.QuadPart = (current.QuadPart - utc.QuadPart) / 10L - tem.QuadPart;
+    }
+  etime_usec = tem.QuadPart % 1000000L;
+  etime_sec = tem.QuadPart / 1000000L;
   *etime = ltime (etime_sec, etime_usec);
-
-  if (tem)
+  if (tem.QuadPart)
     {
-      *pcpu = 100.0 * (tem1 + tem2) / tem;
-      if (*pcpu > 100)
+      *pcpu = (100.0 * (tem1.QuadPart + tem2.QuadPart)) / tem.QuadPart;
+      if (*pcpu > 100.0)
 	*pcpu = 100.0;
     }

Re: Optimized gcc 4.3.0 build on Windows returns 0 secs for all time values of system-process-attributes

[dhruva]

I have a shorter patch, not sure it if catches all use cases. I see
non zero results but will confirm if this is the right fix but
comparing the results with optimized with my change and non optimized
build with out my change.

-dhruva

=== modified file 'src/w32.c'
--- src/w32.c   2008-12-20 02:50:35 +0000
+++ src/w32.c   2009-01-01 12:46:37 +0000
@@ -2739,15 +2739,17 @@
 }

 static FILETIME utc_base_ft;
-static long double utc_base;
+static LONGLONG utc_base;
 static int init = 0;

-static long double
+static LONGLONG
 convert_time_raw (FILETIME ft)
 {
-  return
-    (long double) ft.dwHighDateTime
-    * 4096.0L * 1024.0L * 1024.0L + ft.dwLowDateTime;
+  LARGE_INTEGER tmp_var;
+  tmp_var.LowPart = ft.dwLowDateTime;
+  tmp_var.HighPart = ft.dwHighDateTime;
+
+  return tmp_var.QuadPart * 4096.0L * 1024.0L * 1024.0L;
 }

 static time_t
@@ -3777,9 +3779,9 @@
      double *pcpu;
 {
   FILETIME ft_creation, ft_exit, ft_kernel, ft_user, ft_current;
-  long ctime_sec, ctime_usec, stime_sec, stime_usec, utime_sec, utime_usec;
-  long etime_sec, etime_usec;
-  long double tem1, tem2, tem;
+  LONGLONG ctime_sec, ctime_usec, stime_sec, stime_usec, utime_sec, utime_usec;
+  LONGLONG etime_sec, etime_usec;
+  LONGLONG tem1, tem2, tem;

   if (!h_proc
       || !get_process_times_fn

-dhruva

-- 
Contents reflect my personal views only!

Re: Optimized gcc 4.3.0 build on Windows returns 0 secs for all time values of system-process-attributes

[dhruva]

On Thu, Jan 1, 2009 at 6:27 PM, dhruva <dhruvakm@gmail.com> wrote:
> I have a shorter patch, not sure it if catches all use cases. I see
> non zero results but will confirm if this is the right fix but
> comparing the results with optimized with my change and non optimized
> build with out my change.

There is something wrong in my previous change. All values are same
with my change (but not zero) however with no opt build without my
change, I see different values.

-dhruva

-- 
Contents reflect my personal views only!

Re: Optimized gcc 4.3.0 build on Windows returns 0 secs for all time values of system-process-attributes

[Jason Rumney]

dhruva wrote:
> +  return tmp_var.QuadPart * 4096.0L * 1024.0L * 1024.0L;
>   

Shouldn't this just be return tmp_var.QuadPart?

Re: Optimized gcc 4.3.0 build on Windows returns 0 secs for all time values of system-process-attributes

[dhruva]

Here is a modified patch that seems to give me different values! Not
sure how to interpret it though :(

[dk]bzr diff
=== modified file 'src/w32.c'
--- src/w32.c   2008-12-20 02:50:35 +0000
+++ src/w32.c   2009-01-01 13:39:13 +0000
@@ -2739,26 +2739,27 @@
 }

 static FILETIME utc_base_ft;
-static long double utc_base;
+static LONGLONG utc_base;
 static int init = 0;

-static long double
+static LONGLONG
 convert_time_raw (FILETIME ft)
 {
-  return
-    (long double) ft.dwHighDateTime
-    * 4096.0L * 1024.0L * 1024.0L + ft.dwLowDateTime;
+  LARGE_INTEGER tmp_var;
+  tmp_var.LowPart = ft.dwLowDateTime;
+  tmp_var.HighPart = ft.dwHighDateTime;
+
+  return tmp_var.QuadPart;
 }

 static time_t
 convert_time (FILETIME ft)
 {
-  long double ret;
-
   if (!init)
     {
       /* Determine the delta between 1-Jan-1601 and 1-Jan-1970. */
       SYSTEMTIME st;
+      LARGE_INTEGER utc;

       st.wYear = 1970;
       st.wMonth = 1;
@@ -2769,8 +2770,9 @@
       st.wMilliseconds = 0;

       SystemTimeToFileTime (&st, &utc_base_ft);
-      utc_base = (long double) utc_base_ft.dwHighDateTime
-       * 4096.0L * 1024.0L * 1024.0L + utc_base_ft.dwLowDateTime;
+      utc.LowPart = utc_base_ft.dwLowDateTime;
+      utc.HighPart = utc_base_ft.dwHighDateTime;
+      utc_base = utc.QuadPart;
       init = 1;
     }

@@ -2784,12 +2786,13 @@
 void
 convert_from_time_t (time_t time, FILETIME * pft)
 {
-  long double tmp;
+  LARGE_INTEGER tmp;

   if (!init)
     {
       /* Determine the delta between 1-Jan-1601 and 1-Jan-1970. */
       SYSTEMTIME st;
+      LARGE_INTEGER utc;

       st.wYear = 1970;
       st.wMonth = 1;
@@ -2800,15 +2803,16 @@
       st.wMilliseconds = 0;

       SystemTimeToFileTime (&st, &utc_base_ft);
-      utc_base = (long double) utc_base_ft.dwHighDateTime
-       * 4096 * 1024 * 1024 + utc_base_ft.dwLowDateTime;
+      utc.LowPart = utc_base_ft.dwLowDateTime;
+      utc.HighPart = utc_base_ft.dwHighDateTime;
+      utc_base = utc.QuadPart;
       init = 1;
     }

   /* time in 100ns units since 1-Jan-1601 */
-  tmp = (long double) time * 1e7 + utc_base;
-  pft->dwHighDateTime = (DWORD) (tmp / (4096.0 * 1024 * 1024));
-  pft->dwLowDateTime = (DWORD) (tmp - (4096.0 * 1024 * 1024) *
pft->dwHighDateTime);
+  tmp.QuadPart = time * 1e7 + utc_base;
+  pft->dwHighDateTime = tmp.HighPart;
+  pft->dwLowDateTime = tmp.LowPart;
 }

 #if 0
@@ -3777,9 +3781,9 @@
      double *pcpu;
 {
   FILETIME ft_creation, ft_exit, ft_kernel, ft_user, ft_current;
-  long ctime_sec, ctime_usec, stime_sec, stime_usec, utime_sec, utime_usec;
-  long etime_sec, etime_usec;
-  long double tem1, tem2, tem;
+  LONGLONG ctime_sec, ctime_usec, stime_sec, stime_usec, utime_sec, utime_usec;
+  LONGLONG etime_sec, etime_usec;
+  LONGLONG tem1, tem2, tem;

   if (!h_proc
       || !get_process_times_fn


On Thu, Jan 1, 2009 at 6:46 PM, Jason Rumney <jasonr@gnu.org> wrote:
> dhruva wrote:
>>
>> +  return tmp_var.QuadPart * 4096.0L * 1024.0L * 1024.0L;
>>
>
> Shouldn't this just be return tmp_var.QuadPart?
>

I guess you are right, I did not understand all the math till you pointed out.


-- 
Contents reflect my personal views only!

Re: Optimized gcc 4.3.0 build on Windows returns 0 secs for all time values of system-process-attributes

[Juanma Barranquero]

On Thu, Jan 1, 2009 at 13:57, dhruva <dhruvakm@gmail.com> wrote:

> I have a shorter patch, not sure it if catches all use cases.

Shorter is not an advantage per se. It is clear that using
ULARGE_INTEGER works; if that's the right thing to do, we can settle
on the cleanest patch afterwards.

My concern is why was it done with long double in the first place.
Perhaps there's some reason of back compatibility with older
compilers.

    Juanma

Re: Optimized gcc 4.3.0 build on Windows returns 0 secs for all time values of system-process-attributes

[Eli Zaretskii]

> Date: Thu, 1 Jan 2009 05:38:36 +0100
> From: "Juanma Barranquero" <lekktu@gmail.com>
> Cc: emacs-devel@gnu.org
> 
> On Wed, Dec 31, 2008 at 20:12, Eli Zaretskii <eliz@gnu.org> wrote:
> 
> > It works for me with GCC 3.4.2 and MinGW 3.14:
> 
> Optimized or unoptimized build?

Optimized.  I used the default switches that nt/gmake.defs sets.

> > Could you please step into process_times and ltime (or add printf's if
> > stepping doesn't work), and see what is going wrong and where?
> 
> Stepping isn't much helpful because most variables are optimized away.
> 
> As for printf, I'm not sure what's wrong, but
> 
>     long double x = 3.5;
>     printf ("f = %Lf\n", x);
>     printf ("g = %Lg\n", x);
> 
>   =>
> 
> f = -26815615859885194000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
> 000000000000000000000000000000.000000
> g = -2.68156e+154
> 
> (Not just with gcc 4.3.0, I get the same result with 3.4.5.)
> 
> Am I missing something obvious?

Looks like Microsoft's runtime does not support the GCC 80-bit long
double, it thinks that long double is the same as double, a 64-bit FP
number.

> I tried rewriting w32.c:process_time to do time computations by using
> ULARGE_INTEGER (see attached patch), as the Platform SDK recommends,
> and it works fine. Why it is implemented with long doubles?

Why not? it worked for me, and it still does.

If the suspicion is that long double calculations don't work here, can
you please show the disassembly of these source lines, as they are
compiled by GCC 4.3.0:

> -  tem1 = convert_time_raw (ft_kernel) * 0.1L;
> -  stime_usec = fmodl (tem1, 1000000.0L);
> -  stime_sec = tem1 * 0.000001L;

I'd like to compare them with what GCC 3.4.2 produces.  Thanks.

Also, which version of the MinGW runtime do you use?

Re: Optimized gcc 4.3.0 build on Windows returns 0 secs for all time values of system-process-attributes

[Eli Zaretskii]

> Date: Thu, 1 Jan 2009 19:13:05 +0530
> From: dhruva <dhruvakm@gmail.com>
> Cc: "Juanma Barranquero" <lekktu@gmail.com>, "Eli Zaretskii" <eliz@gnu.org>, 
> 	emacs-devel@gnu.org
> 
> Here is a modified patch that seems to give me different values! Not
> sure how to interpret it though :(

Use Proced, it will display them in human-readable format.  Do the
values it shows seem reasonable?

Anyway, I don't like fixing a problem we don't understand.  I'd like
to find out what is wrong with the original code, before we start
looking for alternative ways of doing 64-bit arithmetics.

Re: Optimized gcc 4.3.0 build on Windows returns 0 secs for all time values of system-process-attributes

[dhruva]

Hello,

On Fri, Jan 2, 2009 at 12:30 AM, Eli Zaretskii <eliz@gnu.org> wrote:
>> Date: Thu, 1 Jan 2009 19:13:05 +0530
>> From: dhruva <dhruvakm@gmail.com>
>> Cc: "Juanma Barranquero" <lekktu@gmail.com>, "Eli Zaretskii" <eliz@gnu.org>,
>>       emacs-devel@gnu.org
>>
>> Here is a modified patch that seems to give me different values! Not
>> sure how to interpret it though :(
>
> Use Proced, it will display them in human-readable format.  Do the
> values it shows seem reasonable?

It does. But I notice process started in 2008 have the year and 00:00
in the start time. Maybe, it is a separate issue.
Ex:
  dhruva 1400  0.0  1.1  10:21 00:00 emacs.exe
  dhruva 2476  0.0  0.1  10:20 00:00 cmd.exe
  dhruva 2340  0.0  2.7  08:50 00:00 opera.exe
  dhruva 4252  0.0  1.4   2008 00:01 procexp.exe
  dhruva 2956  0.0  0.6   2008 00:00 BTSTAC~1.EXE
  dhruva 1912  0.0  0.2   2008 00:00 DLG.exe

> Anyway, I don't like fixing a problem we don't understand.  I'd like
> to find out what is wrong with the original code, before we start
> looking for alternative ways of doing 64-bit arithmetics.

I agree. I notice the problem might be due to signed and unsigned. The
FILETIME high or low part if interpreted as 'long double' which is
signed shows negative value as in 'convert_raw_time' function.

Anyway, I will continue to explore this to the best of my abilities.

-dhruva

-- 
Contents reflect my personal views only!

Re: Optimized gcc 4.3.0 build on Windows returns 0 secs for all time values of system-process-attributes

[Eli Zaretskii]

> Date: Fri, 2 Jan 2009 10:29:59 +0530
> From: dhruva <dhruvakm@gmail.com>
> Cc: jasonr@gnu.org, lekktu@gmail.com, emacs-devel@gnu.org
> 
> I notice process started in 2008 have the year and 00:00
> in the start time. Maybe, it is a separate issue.
> Ex:
>   dhruva 1400  0.0  1.1  10:21 00:00 emacs.exe
>   dhruva 2476  0.0  0.1  10:20 00:00 cmd.exe
>   dhruva 2340  0.0  2.7  08:50 00:00 opera.exe
>   dhruva 4252  0.0  1.4   2008 00:01 procexp.exe
>   dhruva 2956  0.0  0.6   2008 00:00 BTSTAC~1.EXE
>   dhruva 1912  0.0  0.2   2008 00:00 DLG.exe

If you mean the column after START, the one whose header is TIME, then
that's not the start time, it's the sum of UTIME and STIME.  I think
these processes simply used up less than 1 sec of utime+stime
combined.  I see such processes as well, but others, which started in
2008, have non-zero TIME.  Here's a couple of examples from my system:

  USER   GROUP   PID   START     TIME UTIME STIME      ETIME COMMAND
  SYSTEM SYSTEM  392    2008    25:03 19:35 05:27 2-10:08:41 avgrsx.exe
  SYSTEM SYSTEM 8049    2008    01:46 00:12 01:34 2-10:09:06 services.exe
  SYSTEM SYSTEM  8162   2008    00:12 00:03 00:09 2-10:09:06 lsass.exe

> Anyway, I will continue to explore this to the best of my abilities.

Thank you.

Re: Optimized gcc 4.3.0 build on Windows returns 0 secs for all time values of system-process-attributes

[Chetan Pandya]

I build with gcc version 3.4.5 so I don't know if there are other compiler differences, but I found that changing the format to  
(format-time-string "%Y-%m-%d %H:%M" start)
in proced.el:proced-format-start made it better.

I still have a number of questions about proced and related changes, but I haven't looked at it carefully yet.

Chetan

--- On Fri, 1/2/09, Eli Zaretskii <eliz@gnu.org> wrote:

> From: Eli Zaretskii <eliz@gnu.org>
> Subject: Re: Optimized gcc 4.3.0 build on Windows returns 0 secs for all time values of system-process-attributes
> To: "dhruva" <dhruvakm@gmail.com>
> Cc: lekktu@gmail.com, emacs-devel@gnu.org, jasonr@gnu.org
> Date: Friday, January 2, 2009, 2:33 PM
> > Date: Fri, 2 Jan 2009 10:29:59 +0530
> > From: dhruva <dhruvakm@gmail.com>
> > Cc: jasonr@gnu.org, lekktu@gmail.com,
> emacs-devel@gnu.org
> > 
> > I notice process started in 2008 have the year and 00:00
> > in the start time. Maybe, it is a separate issue.
> > Ex:
> >   dhruva 1400  0.0  1.1  10:21 00:00 emacs.exe
> >   dhruva 2476  0.0  0.1  10:20 00:00 cmd.exe
> >   dhruva 2340  0.0  2.7  08:50 00:00 opera.exe
> >   dhruva 4252  0.0  1.4   2008 00:01 procexp.exe
> >   dhruva 2956  0.0  0.6   2008 00:00 BTSTAC~1.EXE
> >   dhruva 1912  0.0  0.2   2008 00:00 DLG.exe
> 
> If you mean the column after START, the one whose header is TIME, then
> that's not the start time, it's the sum of UTIME and STIME.  I think
> these processes simply used up less than 1 sec of utime+stime
> combined.  I see such processes as well, but others, which started in
> 2008, have non-zero TIME.  Here's a couple of examples
> from my system:
> 
>   USER   GROUP   PID   START     TIME UTIME STIME ETIME COMMAND
>   SYSTEM SYSTEM  392    2008    25:03 19:35 05:27 2-10:08:41 avgrsx.exe
>   SYSTEM SYSTEM 8049    2008    01:46 00:12 01:34 2-10:09:06 services.exe
>   SYSTEM SYSTEM  8162   2008    00:12 00:03 00:09 2-10:09:06 lsass.exe
> 
> > Anyway, I will continue to explore this to the best of my abilities.
> 
> Thank you.

Re: Optimized gcc 4.3.0 build on Windows returns 0 secs for all time values of system-process-attributes

[Juanma Barranquero]

On Thu, Jan 1, 2009 at 19:54, Eli Zaretskii <eliz@gnu.org> wrote:

> Looks like Microsoft's runtime does not support the GCC 80-bit long
> double, it thinks that long double is the same as double, a 64-bit FP
> number.

OK.

> Why not? it worked for me, and it still does.

Manipulating precise quantities through floats seems ugly.

> If the suspicion is that long double calculations don't work here, can
> you please show the disassembly of these source lines, as they are
> compiled by GCC 4.3.0:
>
>> -  tem1 = convert_time_raw (ft_kernel) * 0.1L;
>> -  stime_usec = fmodl (tem1, 1000000.0L);
>> -  stime_sec = tem1 * 0.000001L;

3792      tem1 = convert_time_raw (ft_kernel) * 0.1L;
0x010b6a94 <system_process_attributes+2140>:    mov    -0x6c(%ebp),%eax
0x010b6a97 <system_process_attributes+2143>:    xor    %edx,%edx
0x010b6a99 <system_process_attributes+2145>:    push   %edx
0x010b6a9a <system_process_attributes+2146>:    push   %eax
0x010b6a9b <system_process_attributes+2147>:    fildll (%esp)
0x010b6a9e <system_process_attributes+2150>:    add    $0x8,%esp
0x010b6aa1 <system_process_attributes+2153>:    fmuls  0x140ff84
0x010b6aa7 <system_process_attributes+2159>:    flds   0x140ff88
0x010b6aad <system_process_attributes+2165>:    fmul   %st,%st(1)
0x010b6aaf <system_process_attributes+2167>:    fmulp  %st,%st(1)
0x010b6ab1 <system_process_attributes+2169>:    mov    -0x70(%ebp),%eax
0x010b6ab4 <system_process_attributes+2172>:    xor    %edx,%edx
0x010b6ab6 <system_process_attributes+2174>:    push   %edx
0x010b6ab7 <system_process_attributes+2175>:    push   %eax
0x010b6ab8 <system_process_attributes+2176>:    fildll (%esp)
0x010b6abb <system_process_attributes+2179>:    add    $0x8,%esp
0x010b6abe <system_process_attributes+2182>:    faddp  %st,%st(1)
0x010b6ac0 <system_process_attributes+2184>:    fldt   0x140ff90
0x010b6ac6 <system_process_attributes+2190>:    fmulp  %st,%st(1)
3793      stime_usec = fmodl (tem1, 1000000.0L);
0x010b6ac8 <system_process_attributes+2192>:    flds   0x140ff9c
0x010b6ace <system_process_attributes+2198>:    fxch   %st(1)
0x010b6ad0 <system_process_attributes+2200>:    fprem
0x010b6ad2 <system_process_attributes+2202>:    fnstsw %ax
0x010b6ad4 <system_process_attributes+2204>:    sahf
0x010b6ad5 <system_process_attributes+2205>:    jp     0x10b6ad0
<system_process_attributes+2200>
0x010b6ad7 <system_process_attributes+2207>:    fstp   %st(1)
0x010b6ad9 <system_process_attributes+2209>:    fld    %st(0)
0x010b6adb <system_process_attributes+2211>:    fucom  %st(0)
0x010b6add <system_process_attributes+2213>:    fnstsw %ax
0x010b6adf <system_process_attributes+2215>:    sahf
0x010b6ae0 <system_process_attributes+2216>:    jp     0x10b70e6
<system_process_attributes+3758>
0x010b6ae6 <system_process_attributes+2222>:    jne    0x10b70ea
<system_process_attributes+3762>
3794      stime_sec = tem1 * 0.000001L;
0x010b6aec <system_process_attributes+2228>:    fldt   0x140ffa0
0x010b6af2 <system_process_attributes+2234>:    fmul   %st(1),%st
0x010b6af4 <system_process_attributes+2236>:    fnstcw -0x892(%ebp)
0x010b6afa <system_process_attributes+2242>:    movzwl -0x892(%ebp),%eax
0x010b6b01 <system_process_attributes+2249>:    mov    $0xc,%ah
0x010b6b03 <system_process_attributes+2251>:    mov    %ax,-0x894(%ebp)
0x010b6b0a <system_process_attributes+2258>:    fldcw  -0x894(%ebp)
0x010b6b10 <system_process_attributes+2264>:    fistpl -0x898(%ebp)
0x010b6b16 <system_process_attributes+2270>:    fldcw  -0x892(%ebp)
0x010b6b1c <system_process_attributes+2276>:    fxch   %st(1)
0x010b6b1e <system_process_attributes+2278>:    mov    -0x898(%ebp),%edx

> Also, which version of the MinGW runtime do you use?

gcc 4.3.0-20080502-mingw32-alpha
mingw-runtime 3.15.1
w32api 3.13

Hope this helps,

    Juanma

Re: Optimized gcc 4.3.0 build on Windows returns 0 secs for all time values of system-process-attributes

[Eli Zaretskii]

> Date: Sat, 3 Jan 2009 03:27:15 +0100
> From: "Juanma Barranquero" <lekktu@gmail.com>
> Cc: emacs-devel@gnu.org
> 
> > Why not? it worked for me, and it still does.
> 
> Manipulating precise quantities through floats seems ugly.

That's what that code did before I wrote system-process-attributes,
and I wanted to reuse existing code.  A `long double' type has 64 bits
of mantissa on an IA-32 machine, so no loss of precision seemed to be
involved.

> > If the suspicion is that long double calculations don't work here, can
> > you please show the disassembly of these source lines, as they are
> > compiled by GCC 4.3.0:
> >
> >> -  tem1 = convert_time_raw (ft_kernel) * 0.1L;
> >> -  stime_usec = fmodl (tem1, 1000000.0L);
> >> -  stime_sec = tem1 * 0.000001L;
> 
> 3792      tem1 = convert_time_raw (ft_kernel) * 0.1L;
> 0x010b6a94 <system_process_attributes+2140>:    mov    -0x6c(%ebp),%eax

Thanks.  This is still not enough info to zero in on the problem (at
least not for me), but I do see that the produced code is very
different from what GCC 3.x produces for me (see below).  (If someone
can spot the crucial differences in the code that could explain why
the results come out as zero, please speak up.)

Could you please show the values of ft_kernel, stime_sec, and
stime_usec after the last of the above 3 lines, namely after

  stime_sec = tem1 * 0.000001L;

?

These variables are all integers, so printf should handle them
correctly (although you will need to use the non-standard %I64d format
specifier for 64-bit values).

By the way, it sounds like, if you use snprintf, you should be able to
have long double values printed correctly as well, because snprintf
comes from libmingwex library, not from MS runtime.

> > Also, which version of the MinGW runtime do you use?
> 
> gcc 4.3.0-20080502-mingw32-alpha
> mingw-runtime 3.15.1
> w32api 3.13

The MinGW runtime version seems to be irrelevant, since the code you
show doesn't call fmodl at all; instead, it does everything inline.

For the record, here is the corresponding code produced by GCC 3.4.2:

3792   tem1 = convert_time_raw (ft_kernel) * 0.1L;
0x0107e8c9 <system_process_attributes+2341>:    mov    -0x8f0(%ebp),%eax
0x0107e8cf <system_process_attributes+2347>:    mov    -0x8ec(%ebp),%edx
0x0107e8d5 <system_process_attributes+2353>:    sub    $0x4,%esp
0x0107e8d8 <system_process_attributes+2356>:    call   0x107c368 <convert_time_raw>
0x0107e8dd <system_process_attributes+2361>:    fldt   0x12ce760
0x0107e8e3 <system_process_attributes+2367>:    fmulp  %st,%st(1)
0x0107e8e5 <system_process_attributes+2369>:    fstpt  -0x948(%ebp)
3792   stime_usec = fmodl (tem1, 1000000.0L);
0x0107e8eb <system_process_attributes+2375>:    flds   0x12ce76c
0x0107e8f1 <system_process_attributes+2381>:    fstpt  -0x988(%ebp)
0x0107e8f7 <system_process_attributes+2387>:    mov    -0x988(%ebp),%ebx
0x0107e8fd <system_process_attributes+2393>:    mov    -0x984(%ebp),%esi
0x0107e903 <system_process_attributes+2399>:    mov    -0x980(%ebp),%edi
0x0107e909 <system_process_attributes+2405>:    mov    %edi,0x14(%esp)
0x0107e90d <system_process_attributes+2409>:    mov    %ebx,0xc(%esp)
0x0107e911 <system_process_attributes+2413>:    mov    %esi,0x10(%esp)
0x0107e915 <system_process_attributes+2417>:    fldt   -0x948(%ebp)
0x0107e91b <system_process_attributes+2423>:    fstpt  (%esp)
0x0107e91e <system_process_attributes+2426>:    call   0x1178ba0 <fmodl>
0x0107e923 <system_process_attributes+2431>:    fldt   0x12ce770
3794   stime_sec = tem1 * 0.000001L;
0x0107e929 <system_process_attributes+2437>:    fxch   %st(1)
0x0107e92b <system_process_attributes+2439>:    fnstcw -0x90a(%ebp)
0x0107e931 <system_process_attributes+2445>:    movzwl -0x90a(%ebp),%eax
0x0107e938 <system_process_attributes+2452>:    mov    $0xc,%ah
0x0107e93a <system_process_attributes+2454>:    mov    %ax,-0x90c(%ebp)
0x0107e941 <system_process_attributes+2461>:    fldcw  -0x90c(%ebp)
0x0107e947 <system_process_attributes+2467>:    fistpl -0x910(%ebp)
0x0107e94d <system_process_attributes+2473>:    fldcw  -0x90a(%ebp)
0x0107e953 <system_process_attributes+2479>:    fldt   -0x948(%ebp)
0x0107e959 <system_process_attributes+2485>:    fmulp  %st,%st(1)
0x0107e95b <system_process_attributes+2487>:    mov    -0x910(%ebp),%edx
0x0107e961 <system_process_attributes+2493>:    fldcw  -0x90c(%ebp)
0x0107e967 <system_process_attributes+2499>:    fistpl -0x910(%ebp)

And the code produced for convert_time_raw (which is inlined by GCC
4.3.0) is this:

2748    return
          (long double) ft.dwHighDateTime
          * 4096.0L * 1024.0L * 1024.0L + ft.dwLowDateTime;
0x0107c368 <convert_time_raw+0>:        push   %ebp
0x0107c369 <convert_time_raw+1>:        flds   0x12ce424
0x0107c36f <convert_time_raw+7>:        mov    %esp,%ebp
0x0107c371 <convert_time_raw+9>:        push   %ebx
0x0107c372 <convert_time_raw+10>:       xor    %ebx,%ebx
0x0107c374 <convert_time_raw+12>:       push   %ebx
0x0107c375 <convert_time_raw+13>:       push   %edx
0x0107c376 <convert_time_raw+14>:       xor    %edx,%edx
0x0107c378 <convert_time_raw+16>:       fildll (%esp)
0x0107c37b <convert_time_raw+19>:       add    $0x8,%esp
0x0107c37e <convert_time_raw+22>:       push   %edx
0x0107c37f <convert_time_raw+23>:       fmuls  0x12ce420
0x0107c385 <convert_time_raw+29>:       fmul   %st(1),%st
0x0107c387 <convert_time_raw+31>:       push   %eax
0x0107c388 <convert_time_raw+32>:       fmulp  %st,%st(1)
0x0107c38a <convert_time_raw+34>:       fildll (%esp)
0x0107c38d <convert_time_raw+37>:       add    $0x8,%esp
0x0107c390 <convert_time_raw+40>:       pop    %ebx
0x0107c391 <convert_time_raw+41>:       faddp  %st,%st(1)
0x0107c393 <convert_time_raw+43>:       pop    %ebp
0x0107c394 <convert_time_raw+44>:       ret

Re: Optimized gcc 4.3.0 build on Windows returns 0 secs for all time values of system-process-attributes

[Juanma Barranquero]

On Sat, Jan 3, 2009 at 13:29, Eli Zaretskii <eliz@gnu.org> wrote:

> That's what that code did before I wrote system-process-attributes,
> and I wanted to reuse existing code.  A `long double' type has 64 bits
> of mantissa on an IA-32 machine, so no loss of precision seemed to be
> involved.

Yes, I understand that. Still it seems ugly to divide a whole number
by ten doing X * 0.1...

> Could you please show the values of ft_kernel, stime_sec, and
> stime_usec after the last of the above 3 lines, namely after
>
>  stime_sec = tem1 * 0.000001L;
>
> ?

Attached. I've used snprintf, with %Lg for tem1, %I64d for ft_kernel
and %ld for stime_u?sec.

> By the way, it sounds like, if you use snprintf, you should be able to
> have long double values printed correctly as well, because snprintf
> comes from libmingwex library, not from MS runtime.

Great, thanks.

    Juanma


tem1       = 484375.000000
ft_kernel  = 584843750
stime_usec = 484375
stime_sec  = 0

tem1       = 31250.000000
ft_kernel  = 312500
stime_usec = 31250
stime_sec  = 0

tem1       = 218750.000000
ft_kernel  = 122187500
stime_usec = 218750
stime_sec  = 0

tem1       = 328125.000000
ft_kernel  = 13281250
stime_usec = 328125
stime_sec  = 0

tem1       = 296875.000000
ft_kernel  = 72968750
stime_usec = 296875
stime_sec  = 0

tem1       = 156250.000000
ft_kernel  = 11562500
stime_usec = 156250
stime_sec  = 0

tem1       = 171875.000000
ft_kernel  = 1718750
stime_usec = 171875
stime_sec  = 0

tem1       = 93750.000000
ft_kernel  = 10937500
stime_usec = 93750
stime_sec  = 0

tem1       = 843750.000000
ft_kernel  = 78437500
stime_usec = 843750
stime_sec  = 0

tem1       = 31250.000000
ft_kernel  = 312500
stime_usec = 31250
stime_sec  = 0

tem1       = 203125.000000
ft_kernel  = 2031250
stime_usec = 203125
stime_sec  = 0

tem1       = 62500.000000
ft_kernel  = 625000
stime_usec = 62500
stime_sec  = 0

tem1       = 62500.000000
ft_kernel  = 625000
stime_usec = 62500
stime_sec  = 0

tem1       = 62500.000000
ft_kernel  = 625000
stime_usec = 62500
stime_sec  = 0

tem1       = 0.000000
ft_kernel  = 0
stime_usec = 0
stime_sec  = 0

tem1       = 703125.000000
ft_kernel  = 47031250
stime_usec = 703125
stime_sec  = 0

tem1       = 968750.000000
ft_kernel  = 49687500
stime_usec = 968750
stime_sec  = 0

tem1       = 93750.000000
ft_kernel  = 20937500
stime_usec = 93750
stime_sec  = 0

tem1       = 531250.000000
ft_kernel  = 115312500
stime_usec = 531250
stime_sec  = 0

tem1       = 468750.000000
ft_kernel  = 4687500
stime_usec = 468750
stime_sec  = 0

tem1       = 93750.000000
ft_kernel  = 937500
stime_usec = 93750
stime_sec  = 0

tem1       = 140625.000000
ft_kernel  = 1406250
stime_usec = 140625
stime_sec  = 0

tem1       = 93750.000000
ft_kernel  = 937500
stime_usec = 93750
stime_sec  = 0

tem1       = 31250.000000
ft_kernel  = 312500
stime_usec = 31250
stime_sec  = 0

tem1       = 312500.000000
ft_kernel  = 3125000
stime_usec = 312500
stime_sec  = 0

tem1       = 687500.000000
ft_kernel  = 26875000
stime_usec = 687500
stime_sec  = 0

tem1       = 93750.000000
ft_kernel  = 937500
stime_usec = 93750
stime_sec  = 0

tem1       = 140625.000000
ft_kernel  = 1406250
stime_usec = 140625
stime_sec  = 0

tem1       = 46875.000000
ft_kernel  = 468750
stime_usec = 46875
stime_sec  = 0

tem1       = 46875.000000
ft_kernel  = 468750
stime_usec = 46875
stime_sec  = 0

tem1       = 296875.000000
ft_kernel  = 2968750
stime_usec = 296875
stime_sec  = 0

tem1       = 578125.000000
ft_kernel  = 615781250
stime_usec = 578125
stime_sec  = 0

tem1       = 281250.000000
ft_kernel  = 32812500
stime_usec = 281250
stime_sec  = 0

tem1       = 531250.000000
ft_kernel  = 315312500
stime_usec = 531250
stime_sec  = 0

tem1       = 781250.000000
ft_kernel  = 317812500
stime_usec = 781250
stime_sec  = 0

tem1       = 281250.000000
ft_kernel  = 332812500
stime_usec = 281250
stime_sec  = 0

tem1       = 31250.000000
ft_kernel  = 312500
stime_usec = 31250
stime_sec  = 0

tem1       = 109375.000000
ft_kernel  = 1093750
stime_usec = 109375
stime_sec  = 0

tem1       = 46875.000000
ft_kernel  = 468750
stime_usec = 46875
stime_sec  = 0

tem1       = 906250.000000
ft_kernel  = 99062500
stime_usec = 906250
stime_sec  = 0

tem1       = 500000.000000
ft_kernel  = 5000000
stime_usec = 500000
stime_sec  = 0

tem1       = 218750.000000
ft_kernel  = 12187500
stime_usec = 218750
stime_sec  = 0

tem1       = 218750.000000
ft_kernel  = 12187500
stime_usec = 218750
stime_sec  = 0

Re: Optimized gcc 4.3.0 build on Windows returns 0 secs for all time values of system-process-attributes

[Juanma Barranquero]

On Sat, Jan 3, 2009 at 14:28, Juanma Barranquero <lekktu@gmail.com> wrote:

>> Could you please show the values of ft_kernel, stime_sec, and
>> stime_usec after the last of the above 3 lines, namely after
>>
>>  stime_sec = tem1 * 0.000001L;
>>
>> ?

Hmm.

The inlined code that implements the fmodl() call seems to be modifying tem1;
doing

  snprintf (buf, sizeof (buf), "tem1 (1) = %Lf\n", tem1);
OutputDebugString (buf);
  stime_usec = fmodl (tem1, 1000000.0L);
  snprintf (buf, sizeof (buf), "tem1 (2) = %Lf\n", tem1);
OutputDebugString (buf);

I get the following results:

tem1 (1) = 82703125.000000
tem1 (2) = 703125.000000

tem1 (1) = 31250.000000
tem1 (2) = 31250.000000

tem1 (1) = 14671875.000000
tem1 (2) = 671875.000000

tem1 (1) = 1453125.000000
tem1 (2) = 453125.000000

tem1 (1) = 7687500.000000
tem1 (2) = 687500.000000

tem1 (1) = 1250000.000000
tem1 (2) = 250000.000000

tem1 (1) = 171875.000000
tem1 (2) = 171875.000000

tem1 (1) = 1125000.000000
tem1 (2) = 125000.000000

tem1 (1) = 9718750.000000
tem1 (2) = 718750.000000

tem1 (1) = 31250.000000
tem1 (2) = 31250.000000

tem1 (1) = 203125.000000
tem1 (2) = 203125.000000

tem1 (1) = 62500.000000
tem1 (2) = 62500.000000

tem1 (1) = 62500.000000
tem1 (2) = 62500.000000

tem1 (1) = 62500.000000
tem1 (2) = 62500.000000

tem1 (1) = 0.000000
tem1 (2) = 0.000000

tem1 (1) = 6453125.000000
tem1 (2) = 453125.000000

tem1 (1) = 6000000.000000
tem1 (2) = 0.000000

tem1 (1) = 2109375.000000
tem1 (2) = 109375.000000

tem1 (1) = 14468750.000000
tem1 (2) = 468750.000000

tem1 (1) = 468750.000000
tem1 (2) = 468750.000000

tem1 (1) = 125000.000000
tem1 (2) = 125000.000000

tem1 (1) = 140625.000000
tem1 (2) = 140625.000000

tem1 (1) = 93750.000000
tem1 (2) = 93750.000000

tem1 (1) = 31250.000000
tem1 (2) = 31250.000000

tem1 (1) = 312500.000000
tem1 (2) = 312500.000000

tem1 (1) = 3765625.000000
tem1 (2) = 765625.000000

tem1 (1) = 93750.000000
tem1 (2) = 93750.000000

tem1 (1) = 140625.000000
tem1 (2) = 140625.000000

tem1 (1) = 46875.000000
tem1 (2) = 46875.000000

tem1 (1) = 46875.000000
tem1 (2) = 46875.000000

tem1 (1) = 296875.000000
tem1 (2) = 296875.000000

tem1 (1) = 71437500.000000
tem1 (2) = 437500.000000

tem1 (1) = 4234375.000000
tem1 (2) = 234375.000000

tem1 (1) = 38015625.000000
tem1 (2) = 15625.000000

tem1 (1) = 38218750.000000
tem1 (2) = 218750.000000

tem1 (1) = 39500000.000000
tem1 (2) = 500000.000000

tem1 (1) = 31250.000000
tem1 (2) = 31250.000000

tem1 (1) = 109375.000000
tem1 (2) = 109375.000000

tem1 (1) = 46875.000000
tem1 (2) = 46875.000000

tem1 (1) = 10328125.000000
tem1 (2) = 328125.000000

tem1 (1) = 1546875.000000
tem1 (2) = 546875.000000

tem1 (1) = 328125.000000
tem1 (2) = 328125.000000

tem1 (1) = 343750.000000
tem1 (2) = 343750.000000


  Juanma

Re: Optimized gcc 4.3.0 build on Windows returns 0 secs for all time values of system-process-attributes

[Eli Zaretskii]

> Date: Sat, 3 Jan 2009 14:53:25 +0100
> From: "Juanma Barranquero" <lekktu@gmail.com>
> Cc: emacs-devel@gnu.org
> 
> On Sat, Jan 3, 2009 at 14:28, Juanma Barranquero <lekktu@gmail.com> wrote:
> 
> >> Could you please show the values of ft_kernel, stime_sec, and
> >> stime_usec after the last of the above 3 lines, namely after
> >>
> >>  stime_sec = tem1 * 0.000001L;
> >>
> >> ?
> 
> Hmm.
> 
> The inlined code that implements the fmodl() call seems to be modifying tem1;
> doing
> 
>   snprintf (buf, sizeof (buf), "tem1 (1) = %Lf\n", tem1);
> OutputDebugString (buf);
>   stime_usec = fmodl (tem1, 1000000.0L);
>   snprintf (buf, sizeof (buf), "tem1 (2) = %Lf\n", tem1);
> OutputDebugString (buf);
> 
> I get the following results:
> 
> tem1 (1) = 82703125.000000
> tem1 (2) = 703125.000000

That's a bug in GCC, I'd say: all these variables are in registers, so
it probably reuses one of the FP registers incorrectly.

What happens if you transpose these two lines:

  stime_usec = fmodl (tem1, 1000000.0L);
  stime_sec = tem1 * 0.000001L;

(and similarly for other ?time_* qualities)? does the code work again
then?  (Note that I reuse tem1 and tem2 twice in the code, so even if
transposition works, something else will need to be done to make all
of the function work correctly.)

Re: Optimized gcc 4.3.0 build on Windows returns 0 secs for all time values of system-process-attributes

[Juanma Barranquero]

On Sat, Jan 3, 2009 at 16:33, Eli Zaretskii <eliz@gnu.org> wrote:

> That's a bug in GCC, I'd say: all these variables are in registers, so
> it probably reuses one of the FP registers incorrectly.

Yes, definitely a compiler bug.

> What happens if you transpose these two lines:
>
>  stime_usec = fmodl (tem1, 1000000.0L);
>  stime_sec = tem1 * 0.000001L;
>
> (and similarly for other ?time_* qualities)? does the code work again
> then?

It works; at least, proced shows meaningful results:

  Juanma 1006 Ninguno  513  180  332 0     8 100.0  3.7      12  27356
 38252  37052  13:36 00:01 00:02 00:16 14247-15:50:47 explorer.exe
  Juanma 1006 Ninguno  513 2600 3596 0     8  12.6  0.3       4  10328
  3252  10855  12:11 00:01 00:04 00:08 14247-15:50:47 tcmd.exe
  Juanma 1006 Ninguno  513 1760 2600  1    4  55.6  1.2       3   9964
 12512  13799  12:12 00:01 00:09 01:08 14247-15:50:47 tcc.exe
  Juanma 1006 Ninguno  513 2680 2600  1    4 100.0  1.1       3   9036
 11512  23211  12:12 00:01 00:11 01:08 14247-15:50:47 tcc.exe
  Juanma 1006 Ninguno  513 4080 2600  1    4  52.0  1.1       3   9800
 11888   6821  12:12 00:01 00:08 01:06 14247-15:50:46 tcc.exe
  Juanma 1006 Ninguno  513 2888 1716 0     8 100.0  1.9       3  17092
 19996   8667  16:50 00:00 00:01 00:01 14247-15:50:47 emacs.exe

> (Note that I reuse tem1 and tem2 twice in the code, so even if
> transposition works, something else will need to be done to make all
> of the function work correctly.)

I suppose it can be made to work by adding additional temporary
variables, but at this point, I'm not sure it wouldn't be just easier
and cleaner to switch to 64-bit integer arithmetic.

    Juanma

Re: Optimized gcc 4.3.0 build on Windows returns 0 secs for all time values of system-process-attributes

[Eli Zaretskii]

> Date: Sat, 3 Jan 2009 17:00:23 +0100
> From: "Juanma Barranquero" <lekktu@gmail.com>
> Cc: emacs-devel@gnu.org
> 
> > What happens if you transpose these two lines:
> >
> >  stime_usec = fmodl (tem1, 1000000.0L);
> >  stime_sec = tem1 * 0.000001L;
> >
> > (and similarly for other ?time_* qualities)? does the code work again
> > then?
> 
> It works; at least, proced shows meaningful results:
> 
>   Juanma 1006 Ninguno  513  180  332 0     8 100.0  3.7      12  27356
>  38252  37052  13:36 00:01 00:02 00:16 14247-15:50:47 explorer.exe
                                         ^^^^^
What's that 14247 part?  That's supposed to say 14247 days of elapsed
time, I think, in which case it sounds incredible.

Re: Optimized gcc 4.3.0 build on Windows returns 0 secs for all time values of system-process-attributes

[Eli Zaretskii]

> Date: Sat, 3 Jan 2009 17:00:23 +0100
> From: "Juanma Barranquero" <lekktu@gmail.com>
> Cc: emacs-devel@gnu.org
> 
> On Sat, Jan 3, 2009 at 16:33, Eli Zaretskii <eliz@gnu.org> wrote:
> 
> > That's a bug in GCC, I'd say: all these variables are in registers, so
> > it probably reuses one of the FP registers incorrectly.
> 
> Yes, definitely a compiler bug.

It's probably worth reporting that to the GCC mailing list, and/or
file a bug report with them.

> I suppose it can be made to work by adding additional temporary
> variables, but at this point, I'm not sure it wouldn't be just easier
> and cleaner to switch to 64-bit integer arithmetic.

Please install your change, but please try making the code more
concise and clear, if possible.  For example, you could introduce a
macro or an inline function for this repeated pattern:

> +  tem1.LowPart = ft_kernel.dwLowDateTime;
> +  tem1.HighPart = ft_kernel.dwHighDateTime;
> +  tem1.QuadPart /= 10L;
> +  stime_usec = tem1.QuadPart % 1000000L;
> +  stime_sec = tem1.QuadPart / 1000000L;
>    *stime = ltime (stime_sec, stime_usec);

In addition, please also change the other user of convert_time_raw
similarly to this.

Re: Optimized gcc 4.3.0 build on Windows returns 0 secs for all time values of system-process-attributes

[Juanma Barranquero]

On Sat, Jan 3, 2009 at 17:56, Eli Zaretskii <eliz@gnu.org> wrote:

> It's probably worth reporting that to the GCC mailing list, and/or
> file a bug report with them.

Yes, will do.

> Please install your change, but please try making the code more
> concise and clear, if possible.  For example, you could introduce a
> macro or an inline function for this repeated pattern:
>
>> +  tem1.LowPart = ft_kernel.dwLowDateTime;
>> +  tem1.HighPart = ft_kernel.dwHighDateTime;
>> +  tem1.QuadPart /= 10L;

The patch I was using locally already has two macros:

  #define CONVERT_TO_ULARGE(result, ft, div)   \
    do {                                       \
      (result).LowPart = (ft).dwLowDateTime;   \
      (result).HighPart = (ft).dwHighDateTime; \
      if (div)                                 \
        (result).QuadPart /= (div);            \
    } while (0)

  #define TO_LISP_OBJECT(time) ltime ((time).QuadPart / 1000000L,
(time).QuadPart % 1000000L)

so most conversions are like this:

 CONVERT_TO_ULARGE (tem1, ft_kernel, 10L);
 *stime = TO_LISP_OBJECT (tem1);

(better names are very welcome).

> In addition, please also change the other user of convert_time_raw
> similarly to this.

Yes, of course.

    Juanma

Re: Optimized gcc 4.3.0 build on Windows returns 0 secs for all time values of system-process-attributes

[Eli Zaretskii]

> Date: Sat, 3 Jan 2009 18:14:05 +0100
> From: "Juanma Barranquero" <lekktu@gmail.com>
> Cc: emacs-devel@gnu.org
> 
>  CONVERT_TO_ULARGE (tem1, ft_kernel, 10L);
>  *stime = TO_LISP_OBJECT (tem1);
> 
> (better names are very welcome).

FILETIME_TO_ULARGE and ULARGE_TO_LISP_TIME ?

Re: Optimized gcc 4.3.0 build on Windows returns 0 secs for all time values of system-process-attributes

[Jason Rumney]

Juanma Barranquero wrote:
> The patch I was using locally already has two macros:
>
>   #define CONVERT_TO_ULARGE(result, ft, div)   \
>     do {                                       \
>       (result).LowPart = (ft).dwLowDateTime;   \
>       (result).HighPart = (ft).dwHighDateTime; \
>       if (div)                                 \
>         (result).QuadPart /= (div);            \
>     } while (0)
>   

This seems to be doing more than just converting a value to ularge. It 
seems to be more like a ULARGE_DIVIDE.

Re: Optimized gcc 4.3.0 build on Windows returns 0 secs for all time values of system-process-attributes

[Juanma Barranquero]

On Sun, Jan 4, 2009 at 03:24, Jason Rumney <jasonr@gnu.org> wrote:

> This seems to be doing more than just converting a value to ularge. It seems
> to be more like a ULARGE_DIVIDE.

Yes. In the patch I'm working on, it is used with div = 0 (four times)
and div = 10L (two times). Perhaps it'd be cleaner just to take the
division out for these two cases.

    Juanma

Re: Optimized gcc 4.3.0 build on Windows returns 0 secs for all time values of system-process-attributes

[Jason Rumney]

Juanma Barranquero wrote:
> Yes. In the patch I'm working on, it is used with div = 0 (four times)
>   
That doesn't seem like a good idea.

Re: Optimized gcc 4.3.0 build on Windows returns 0 secs for all time values of system-process-attributes

[Juanma Barranquero]

On Sun, Jan 4, 2009 at 03:33, Jason Rumney <jasonr@gnu.org> wrote:

> That doesn't seem like a good idea.

It was a flag, there was no division. But I've already removed it.

    Juanma