Loading ...
Sorry, an error occurred while loading the content.
 

VIM 7.0026: A Patch for Make_mvc.mak and failed tests

Expand Messages
  • Johnny Blaze
    Bram, I have attached a patch to Make_mvc.mak. It adds another CPUNR option and removes some debug options from CFLAGS, PDB, and LINK_PDB. CPUNR: Adds P4 to
    Message 1 of 27 , Dec 31, 2004
      Bram,

      I have attached a patch to Make_mvc.mak. It adds another CPUNR option
      and removes some debug options from CFLAGS, PDB, and LINK_PDB.

      CPUNR: Adds "P4" to the list. It uses the options /G7 and /arch:SSE2.
      This causes CL to optimize the code specifically for P4 and AMD
      processors that implement SSE2 instructions. /arch:SSE2 is a new
      option as of VC7.0.

      CFLAGS: Removed /Zi in the no-debug block. According to Microsoft, if
      you use this, it adds debug information to the assemblies and marks
      them as debug. This slows down execution.

      PDB: Removed all options in the no-debug block. If there is no PDB
      created, why give this option?

      LINK_PDB: same as above

      On PDB and LINK_PDB, Microsoft indicates that these options take a
      file name, but the makefile gives a directory. Is this correct?

      VIM 7.0026 fails these tests:

      test54 - test.out has double-quotes around the text, while test54.ok does not.
      test11 - It looks like line-endings problems
      test30 - this still gives line-endings problems

      These tests were ran from a CVS working directory. I restored
      test30.in and test30.ok from the snapshot zip and the problem went
      away. I know you had test30.ok marked as binary, does it need to be
      checked in again? I tried restoring test11.in and test11.ok, but it
      failed both ways.

      These tests were performed using the options in the in included
      makefile patch as well as a standard makeflie with CPUNR=i686.

      --

      . o O pyromancer O o .
    • George V. Reilly
      ... Does Vim actually generate code that uses SSE2 instructions or does it notably benefit from P4-specific optimizations? Vim is fast on modern hardware. ...
      Message 2 of 27 , Dec 31, 2004
        Johnny Blaze wrote:

        >I have attached a patch to Make_mvc.mak. It adds another CPUNR option
        >and removes some debug options from CFLAGS, PDB, and LINK_PDB.
        >
        >CPUNR: Adds "P4" to the list. It uses the options /G7 and /arch:SSE2.
        > This causes CL to optimize the code specifically for P4 and AMD
        >processors that implement SSE2 instructions. /arch:SSE2 is a new
        >option as of VC7.0.
        >
        >

        Does Vim actually generate code that uses SSE2 instructions or does it
        notably benefit from P4-specific optimizations? Vim is fast on modern
        hardware.

        >CFLAGS: Removed /Zi in the no-debug block. According to Microsoft, if
        >you use this, it adds debug information to the assemblies and marks
        >them as debug. This slows down execution.
        >
        >

        /Zi does not slow down execution. It generates debugGER information:
        debug symbols and the like. It does not affect the optimization of the
        code. I've spent most of the last eight years working in the Windows
        division at Microsoft, and I can tell you that the optimized binaries
        that ship on the Windows CD were built with debugger information
        (actually the related /Z7 flag).

        It's an enormous pain to debug if you don't have symbols. Omitting the
        debugger information makes the binaries slightly smaller, but it doesn't
        affect the code generation. I say "slightly smaller" because most of the
        debugger information (the symbols) ends up in external PDB files, which
        can be quite large.

        If you're worried about the size of the binary, switch off some of the
        more arcane Vim features, or compress the binary with UPX.

        --
        I know of no safe depository of the ultimate powers of society
        but the people themselves;
        and if we think them not enlightened enough
        to exercise their control with a wholesome discretion,
        the remedy is not to take it from them,
        but to inform their discretion by education.
        -- Thomas Jefferson, letter to William Charles Jarvis, 1820
        (Get Witty Auto-Generated Signatures from http://SmartBee.org)
        George V. Reilly george@...
        http://george.reilly.org/
        Read my blog: http://weblogs.asp.net/george_v_reilly/
      • Johnny Blaze
        ... I runs faster for me with the optimizations. ... Well, according to the CL Command Line Switch Reference published by Microsoft, it slows down execution.
        Message 3 of 27 , Dec 31, 2004
          On Fri, 31 Dec 2004 13:24:28 -0800, George V. Reilly <george@...> wrote:
          > Does Vim actually generate code that uses SSE2 instructions or does it
          > notably benefit from P4-specific optimizations? Vim is fast on modern
          > hardware.

          I runs faster for me with the optimizations.

          > >CFLAGS: Removed /Zi in the no-debug block. According to Microsoft, if
          > >you use this, it adds debug information to the assemblies and marks
          > >them as debug. This slows down execution.
          > >
          > >
          >
          > /Zi does not slow down execution. It generates debugGER information:
          > debug symbols and the like. It does not affect the optimization of the
          > code. I've spent most of the last eight years working in the Windows
          > division at Microsoft, and I can tell you that the optimized binaries
          > that ship on the Windows CD were built with debugger information
          > (actually the related /Z7 flag).

          Well, according to the CL Command Line Switch Reference published by
          Microsoft, it slows down execution. I realize that this would make it
          hard to debug, but its not supposed to be a debug version.

          --

          . o O pyromancer O o .
        • Walter Briscoe
          In message of Sat, 1 Jan 2005 07:17:02 in , Johnny Blaze writes ... Scenario? Numbers? --
          Message 4 of 27 , Jan 1, 2005
            In message <804f592d04123117177ef4e581@...> of Sat, 1 Jan
            2005 07:17:02 in , Johnny Blaze <pyromancer@...> writes
            >On Fri, 31 Dec 2004 13:24:28 -0800, George V. Reilly <george@...> wrote:
            >> Does Vim actually generate code that uses SSE2 instructions or does it
            >> notably benefit from P4-specific optimizations? Vim is fast on modern
            >> hardware.
            >
            >I runs faster for me with the optimizations.

            Scenario? Numbers?
            --
            Walter Briscoe
          • Bram Moolenaar
            ... Looks OK. P4 also needs to be added to the comments at line 58. ... OK. ... OK. ... Perhaps this is for an older version of MSVC? I notice you also
            Message 5 of 27 , Jan 1, 2005
              Johnny Blaze wrote:

              > I have attached a patch to Make_mvc.mak. It adds another CPUNR option
              > and removes some debug options from CFLAGS, PDB, and LINK_PDB.
              >
              > CPUNR: Adds "P4" to the list. It uses the options /G7 and /arch:SSE2.
              > This causes CL to optimize the code specifically for P4 and AMD
              > processors that implement SSE2 instructions. /arch:SSE2 is a new
              > option as of VC7.0.

              Looks OK. P4 also needs to be added to the comments at line 58.

              > CFLAGS: Removed /Zi in the no-debug block. According to Microsoft, if
              > you use this, it adds debug information to the assemblies and marks
              > them as debug. This slows down execution.

              OK.

              > PDB: Removed all options in the no-debug block. If there is no PDB
              > created, why give this option?
              >
              > LINK_PDB: same as above

              OK.

              > On PDB and LINK_PDB, Microsoft indicates that these options take a
              > file name, but the makefile gives a directory. Is this correct?

              Perhaps this is for an older version of MSVC?

              I notice you also changed "-MD" to "/MD". Specific reason?

              > VIM 7.0026 fails these tests:
              >
              > test54 - test.out has double-quotes around the text, while test54.ok does not.
              > test11 - It looks like line-endings problems
              > test30 - this still gives line-endings problems
              >
              > These tests were ran from a CVS working directory. I restored
              > test30.in and test30.ok from the snapshot zip and the problem went
              > away. I know you had test30.ok marked as binary, does it need to be
              > checked in again? I tried restoring test11.in and test11.ok, but it
              > failed both ways.
              >
              > These tests were performed using the options in the in included
              > makefile patch as well as a standard makeflie with CPUNR=i686.

              I only see the problem with test54. The others must be caused by
              unix/dos fileformat trouble. I use the files copied from Unix and then
              change 'fileformat' in all files to dos.

              Test 54 can be fixed by removing the quotes from test54.in. Also remove
              the space before ">>".

              I would think that for CVS all test files should actually NOT be marked
              binary, so that the line endings are adjusted. Problem is that this
              process apparently fails to work properly, not adding a CR to a line
              that already ends in a CR. I don't know how to solve that...

              Otherwise, we would need to run a script that fixes the fileformats
              before running the actual tests. It seems using this in
              src/testdir/Make_dos.mak works:


              nongui: fixff $(SCRIPTS16) $(SCRIPTS)
              echo ALL DONE

              small: fixff $(SCRIPTS16)
              echo ALL DONE

              gui: fixff $(SCRIPTS16) $(SCRIPTS) $(SCRIPTS_GUI)
              echo ALL DONE

              win32: fixff $(SCRIPTS16) $(SCRIPTS) $(SCRIPTS32)
              echo ALL DONE

              fixff:
              -$(VIMPROG) -u dos.vim --noplugin "+argdo set ff=dos|upd" +q *.in *.ok


              If this works properly then ALL files in src/testdir can be marked binary.

              --
              hundred-and-one symptoms of being an internet addict:
              196. Your computer costs more than your car.

              /// Bram Moolenaar -- Bram@... -- http://www.Moolenaar.net \\\
              /// Sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\
              \\\ Project leader for A-A-P -- http://www.A-A-P.org ///
              \\\ Buy LOTR 3 and help AIDS victims -- http://ICCF.nl/lotr.html ///
            • Johnny Blaze
              ... got it. ... sorry, I meant to change that back. I looked it up, cl and link should both take either - or / without differences. I have attached an updated
              Message 6 of 27 , Jan 1, 2005
                On Sat, 01 Jan 2005 14:23:06 +0100, Bram Moolenaar <Bram@...> wrote:
                >
                > Johnny Blaze wrote:
                >
                > > I have attached a patch to Make_mvc.mak. It adds another CPUNR option
                > > and removes some debug options from CFLAGS, PDB, and LINK_PDB.
                > >
                > > CPUNR: Adds "P4" to the list. It uses the options /G7 and /arch:SSE2.
                > > This causes CL to optimize the code specifically for P4 and AMD
                > > processors that implement SSE2 instructions. /arch:SSE2 is a new
                > > option as of VC7.0.
                >
                > Looks OK. P4 also needs to be added to the comments at line 58.

                got it.

                > I notice you also changed "-MD" to "/MD". Specific reason?

                sorry, I meant to change that back. I looked it up, cl and link
                should both take either - or / without differences.

                I have attached an updated patch.

                --

                . o O pyromancer O o .
              • Johnny Blaze
                ... test30 and test11 still fail with fixff added. I could only get test11 to be successful if I change the line in test11.in: set nobin ff& to set nobin
                Message 7 of 27 , Jan 1, 2005
                  On Sat, 01 Jan 2005 14:23:06 +0100, Bram Moolenaar <Bram@...> wrote:

                  > I would think that for CVS all test files should actually NOT be marked
                  > binary, so that the line endings are adjusted. Problem is that this
                  > process apparently fails to work properly, not adding a CR to a line
                  > that already ends in a CR. I don't know how to solve that...
                  >
                  > Otherwise, we would need to run a script that fixes the fileformats
                  > before running the actual tests. It seems using this in
                  > src/testdir/Make_dos.mak works:
                  >
                  > nongui: fixff $(SCRIPTS16) $(SCRIPTS)
                  > echo ALL DONE
                  >
                  > small: fixff $(SCRIPTS16)
                  > echo ALL DONE
                  >
                  > gui: fixff $(SCRIPTS16) $(SCRIPTS) $(SCRIPTS_GUI)
                  > echo ALL DONE
                  >
                  > win32: fixff $(SCRIPTS16) $(SCRIPTS) $(SCRIPTS32)
                  > echo ALL DONE
                  >
                  > fixff:
                  > -$(VIMPROG) -u dos.vim --noplugin "+argdo set ff=dos|upd" +q *.in *.ok
                  >
                  > If this works properly then ALL files in src/testdir can be marked binary.

                  test30 and test11 still fail with fixff added. I could only get
                  test11 to be successful if I change the line in test11.in:"set nobin
                  ff&" to "set nobin ff=unix". test30 is only successful if I restore
                  test30.ok from the snapshot (and keep fixff from changing it).


                  --

                  . o O pyromancer O o .
                • Bram Moolenaar
                  ... Did you check out the files in Unix mode, thus without CVS doing any CR adding? I suspect it only adds a CR when there isn t one already, that breaks the
                  Message 8 of 27 , Jan 1, 2005
                    Johnny Blaze wrote:

                    > On Sat, 01 Jan 2005 14:23:06 +0100, Bram Moolenaar <Bram@...> wrote:
                    >
                    > > I would think that for CVS all test files should actually NOT be marked
                    > > binary, so that the line endings are adjusted. Problem is that this
                    > > process apparently fails to work properly, not adding a CR to a line
                    > > that already ends in a CR. I don't know how to solve that...
                    > >
                    > > Otherwise, we would need to run a script that fixes the fileformats
                    > > before running the actual tests. It seems using this in
                    > > src/testdir/Make_dos.mak works:
                    > >
                    > > nongui: fixff $(SCRIPTS16) $(SCRIPTS)
                    > > echo ALL DONE
                    > >
                    > > small: fixff $(SCRIPTS16)
                    > > echo ALL DONE
                    > >
                    > > gui: fixff $(SCRIPTS16) $(SCRIPTS) $(SCRIPTS_GUI)
                    > > echo ALL DONE
                    > >
                    > > win32: fixff $(SCRIPTS16) $(SCRIPTS) $(SCRIPTS32)
                    > > echo ALL DONE
                    > >
                    > > fixff:
                    > > -$(VIMPROG) -u dos.vim --noplugin "+argdo set ff=dos|upd" +q *.in *.ok
                    > >
                    > > If this works properly then ALL files in src/testdir can be marked binary.
                    >
                    > test30 and test11 still fail with fixff added. I could only get
                    > test11 to be successful if I change the line in test11.in:"set nobin
                    > ff&" to "set nobin ff=unix". test30 is only successful if I restore
                    > test30.ok from the snapshot (and keep fixff from changing it).

                    Did you check out the files in Unix mode, thus without CVS doing any CR
                    adding? I suspect it only adds a CR when there isn't one already, that
                    breaks the tests. Vim adds a CR to every line, then it should be OK.

                    --
                    $ echo pizza > /dev/oven

                    /// Bram Moolenaar -- Bram@... -- http://www.Moolenaar.net \\\
                    /// Sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\
                    \\\ Project leader for A-A-P -- http://www.A-A-P.org ///
                    \\\ Buy LOTR 3 and help AIDS victims -- http://ICCF.nl/lotr.html ///
                  • Johnny Blaze
                    test11 and test30 still fail. I used cvs co -kb vim7/src/testdir after removing testdir. -kb is supposed to use the same line endings as stored in CVS. On
                    Message 9 of 27 , Jan 2, 2005
                      test11 and test30 still fail. I used "cvs co -kb vim7/src/testdir"
                      after removing testdir. -kb is supposed to use the same line endings
                      as stored in CVS.

                      On a related note, have you considered switching the repository to
                      subversion? (http://subversion.tigris.org) There are scripts to
                      convert a CVS repository to a Subversion repository.... :-)



                      On Sat, 01 Jan 2005 17:37:57 +0100, Bram Moolenaar <Bram@...> wrote:
                      >
                      > Johnny Blaze wrote:
                      >
                      > > On Sat, 01 Jan 2005 14:23:06 +0100, Bram Moolenaar <Bram@...> wrote:
                      > >
                      > > > I would think that for CVS all test files should actually NOT be marked
                      > > > binary, so that the line endings are adjusted. Problem is that this
                      > > > process apparently fails to work properly, not adding a CR to a line
                      > > > that already ends in a CR. I don't know how to solve that...
                      > > >
                      > > > Otherwise, we would need to run a script that fixes the fileformats
                      > > > before running the actual tests. It seems using this in
                      > > > src/testdir/Make_dos.mak works:
                      > > >
                      > > > nongui: fixff $(SCRIPTS16) $(SCRIPTS)
                      > > > echo ALL DONE
                      > > >
                      > > > small: fixff $(SCRIPTS16)
                      > > > echo ALL DONE
                      > > >
                      > > > gui: fixff $(SCRIPTS16) $(SCRIPTS) $(SCRIPTS_GUI)
                      > > > echo ALL DONE
                      > > >
                      > > > win32: fixff $(SCRIPTS16) $(SCRIPTS) $(SCRIPTS32)
                      > > > echo ALL DONE
                      > > >
                      > > > fixff:
                      > > > -$(VIMPROG) -u dos.vim --noplugin "+argdo set ff=dos|upd" +q *.in *.ok
                      > > >
                      > > > If this works properly then ALL files in src/testdir can be marked binary.
                      > >
                      > > test30 and test11 still fail with fixff added. I could only get
                      > > test11 to be successful if I change the line in test11.in:"set nobin
                      > > ff&" to "set nobin ff=unix". test30 is only successful if I restore
                      > > test30.ok from the snapshot (and keep fixff from changing it).
                      >
                      > Did you check out the files in Unix mode, thus without CVS doing any CR
                      > adding? I suspect it only adds a CR when there isn't one already, that
                      > breaks the tests. Vim adds a CR to every line, then it should be OK.
                      >
                      > --
                      > $ echo pizza > /dev/oven
                      >
                      > /// Bram Moolenaar -- Bram@... -- http://www.Moolenaar.net \\\
                      > /// Sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\
                      > \\\ Project leader for A-A-P -- http://www.A-A-P.org ///
                      > \\\ Buy LOTR 3 and help AIDS victims -- http://ICCF.nl/lotr.html ///
                      >


                      --

                      . o O pyromancer O o .
                    • Bram Moolenaar
                      ... test11 fails if gzip is not available. Perhaps that s the problem you are encountering? It appears the test[11|30].[in|ok] files in CVS are identical to
                      Message 10 of 27 , Jan 2, 2005
                        Johnny Blaze wrote:

                        > test11 and test30 still fail. I used "cvs co -kb vim7/src/testdir"
                        > after removing testdir. -kb is supposed to use the same line endings
                        > as stored in CVS.

                        test11 fails if gzip is not available. Perhaps that's the problem you
                        are encountering?

                        It appears the test[11|30].[in|ok] files in CVS are identical to what I
                        have. Another cause for problems is a diff program that can't handle
                        the different line endings.

                        > On a related note, have you considered switching the repository to
                        > subversion? (http://subversion.tigris.org) There are scripts to
                        > convert a CVS repository to a Subversion repository.... :-)

                        It has been considered. There are two problems:
                        (1) we don't have a reliable repository for subversion (SourceForge
                        doesn't support it).
                        (2) Not many people have it, thus we would have to keep the CVS
                        repository as well.

                        Since we are using CVS for distribution and keeping old versions, not
                        for actual development, it's not much use to switch to subversion.

                        --
                        hundred-and-one symptoms of being an internet addict:
                        211. Your husband leaves you...taking the computer with him and you
                        call him crying, and beg him to bring the computer back.

                        /// Bram Moolenaar -- Bram@... -- http://www.Moolenaar.net \\\
                        /// Sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\
                        \\\ Project leader for A-A-P -- http://www.A-A-P.org ///
                        \\\ Buy LOTR 3 and help AIDS victims -- http://ICCF.nl/lotr.html ///
                      • Johnny Blaze
                        ... hmm... I am using the current versions of both diff and gzip from gnuwin32.sf.net ... I ll check into diff and see if they have fiddled with it. Thanks
                        Message 11 of 27 , Jan 2, 2005
                          On Sun, 02 Jan 2005 22:33:08 +0100, Bram Moolenaar <Bram@...> wrote:
                          >
                          > Johnny Blaze wrote:
                          >
                          > > test11 and test30 still fail. I used "cvs co -kb vim7/src/testdir"
                          > > after removing testdir. -kb is supposed to use the same line endings
                          > > as stored in CVS.
                          >
                          > test11 fails if gzip is not available. Perhaps that's the problem you
                          > are encountering?
                          >
                          > It appears the test[11|30].[in|ok] files in CVS are identical to what I
                          > have. Another cause for problems is a diff program that can't handle
                          > the different line endings.

                          hmm... I am using the current versions of both diff and gzip from
                          gnuwin32.sf.net ... I'll check into diff and see if they have fiddled
                          with it. Thanks Bram.

                          > > On a related note, have you considered switching the repository to
                          > > subversion? (http://subversion.tigris.org) There are scripts to
                          > > convert a CVS repository to a Subversion repository.... :-)
                          >
                          > It has been considered. There are two problems:
                          > (1) we don't have a reliable repository for subversion (SourceForge
                          > doesn't support it).
                          > (2) Not many people have it, thus we would have to keep the CVS
                          > repository as well.

                          1: ww.tigris.org (for project hosting) and svn.collab.net (for the
                          subverison repository hosting)

                          > Since we are using CVS for distribution and keeping old versions, not
                          > for actual development, it's not much use to switch to subversion.

                          okay... Subversion is my new favorite toy (okay, second favorite
                          behind vim :-)... just thought I would share :-)

                          --

                          . o O pyromancer O o .
                        • George V. Reilly
                          [Adding vim-dev back, since I inadvertently dropped them] [!#@!@# qmail bounced the first copy of this since it was in HTML] ... native ... It s talking about
                          Message 12 of 27 , Jan 2, 2005
                            [Adding vim-dev back, since I inadvertently dropped them]
                            [!#@!@# qmail bounced the first copy of this since it was in HTML]

                            Johnny Blaze wrote:
                            >George V. Reilly <george@...> wrote:
                            >>According to
                            >>http://msdn.microsoft.com/library/en-us/vccore/html/_core_.2f.z7.2c_2f.zd.2c_2f.zi.asp
                            >>it does no such thing.
                            >>
                            >>/Zi can affect the runtime performance of *managed* code, but Vim is
                            native
                            >>code. The /clr flag is not present in the compiler flags. Generating
                            >>debugger information can also make the compilation a little slower.
                            >
                            >From the link you gave:
                            >
                            >"This attribute can affect the runtime performance of the application.
                            >For more information about how the Debuggable attribute affects
                            >performance and how you can modify the performance impact, see Making
                            >an Image Easier to Debug."
                            >
                            >Its unclear to me as to whether this is talking about the combination
                            >of /Zi and /clr ("This attribute" not "these attributes"). or /Zi
                            >alone.

                            It's talking about the "Debuggable" attribute from the preceding
                            sentence, which you omitted. /Zi and /clr are _options_ to the compiler.
                            Debuggable is an _attribute_ in the the assembly metadata. There are no
                            assemblies in the unmanaged world.

                            Compare the language in the description for the VC6 compiler, which was
                            the last compiler before .NET:
                            http://msdn.microsoft.com/library/en-us/vccore98/html/_core_.2f.z7.2c_2f.zd.2c_2f.zi.asp

                            /Zi Produces a program database (PDB) that contains type
                            information and symbolic debugging information for use with
                            the debugger. The symbolic debugging information includes
                            the names and types of variables, as well as functions
                            and line numbers.

                            It doesn't say anything about performance, for the good reason that /Zi
                            doesn't affect performance.

                            I used to be the Performance Lead for IIS. Here are some performance
                            articles that I wrote, which may convince you that I know something
                            about the subject:
                            http://msdn.microsoft.com/workshop/server/asp/asptips.asp
                            http://www.microsoft.com/technet/prodtechnol/windows2000serv/technologies/iis/maintain/optimize/iis5tune.mspx
                            http://msdn.microsoft.com/workshop/server/iis/tencom.asp

                            But here's an even better way to convince yourself. Use the /FAcs option
                            to generate a .cod (combined machine, source, and assembly listing)
                            file. Try this on several Vim source files, both with and without /Zi.
                            Let us know if you find a real difference in code generation.

                            >> I don't know about you, but I often need to debug optimized code, and
                            >>without symbols, it's a pain. You don't have to ship the symbols. Just
                            >>archive them for major releases.
                            >
                            >Why can't this be a separate option? (PDB=yes) Does the vast majority
                            >of people compiling a SSE2 optimized, no-debug version of vim with
                            >MSVC need debugging information?

                            The debugging information is essentially free, because almost all of it
                            ends up in the PDB symbols file. You just get a small amount of
                            metainformation in the EXE, which makes it slightly larger, but no slower.

                            Microsoft builds all binaries with debugging information and archives
                            the PDBs on symbol servers. This helps enormously when crashes happen in
                            the field. These symbols are available for developers to use with
                            Windbg/ntsd/kd: see
                            http://www.microsoft.com/whdc/devtools/debugging/symbols.mspx

                            One other thing. I'd recommend using the /GS flag, which inserts stack
                            canaries to detect stack buffer overruns. All the binaries in Windows XP
                            SP2 and in Windows Server 2003 are compiled with this flag.
                            http://msdn.microsoft.com/library/en-us/vccore/html/vclrfGSBufferSecurity.asp
                            http://blogs.msdn.com/branbray/archive/2003/11/11/51012.aspx
                            --
                            1) The project is on schedule.
                            2) I just fixed the last bug.
                            3) I only changed one little thing.
                            4) This will take just a minute.
                            -- The four great lies of computing
                            (Get Witty Auto-Generated Signatures from http://SmartBee.org)
                            George V. Reilly george@...
                            http://george.reilly.org/
                            Read my blog: http://weblogs.asp.net/george_v_reilly/
                          • Johnny Blaze
                            ... oh, I didn t mean to imply that you weren t who you said you are, or to indicate that you didn t know what you were talking about, I was just going off of
                            Message 13 of 27 , Jan 3, 2005
                              On Sun, 02 Jan 2005 22:08:19 -0800, George V. Reilly <george@...> wrote:
                              > I used to be the Performance Lead for IIS. Here are some performance
                              > articles that I wrote, which may convince you that I know something
                              > about the subject:
                              > http://msdn.microsoft.com/workshop/server/asp/asptips.asp
                              > http://www.microsoft.com/technet/prodtechnol/windows2000serv/technologies/iis/maintain/optimize/iis5tune.mspx
                              > http://msdn.microsoft.com/workshop/server/iis/tencom.asp

                              oh, I didn't mean to imply that you weren't who you said you are, or
                              to indicate that you didn't know what you were talking about, I was
                              just going off of my understanding of the Microsoft Docs. I
                              appreciate the information.

                              --

                              . o O pyromancer O o .
                            • Johnny Blaze
                              ... Bram, The problem with test11 appears to be the gnuwin32 port of sed. This version of sed operates in text mode by default, which changes line-endings to
                              Message 14 of 27 , Jan 3, 2005
                                On Sun, 02 Jan 2005 22:33:08 +0100, Bram Moolenaar <Bram@...> wrote:
                                >
                                > Johnny Blaze wrote:
                                >
                                > > test11 and test30 still fail. I used "cvs co -kb vim7/src/testdir"
                                > > after removing testdir. -kb is supposed to use the same line endings
                                > > as stored in CVS.
                                >
                                > test11 fails if gzip is not available. Perhaps that's the problem you
                                > are encountering?
                                >
                                > It appears the test[11|30].[in|ok] files in CVS are identical to what I
                                > have. Another cause for problems is a diff program that can't handle
                                > the different line endings.

                                Bram,

                                The problem with test11 appears to be the gnuwin32 port of sed. This
                                version of sed operates in text mode by default, which changes
                                line-endings to the native system (only if sed changes something, if
                                you run a cat-like sed script, it appears to put out what you put in).
                                If you run it in binary mode, it leaves line-endings alone.

                                I changed the sed command in test11.in to sed -B s/e/E ... and it works fine.

                                Again on test30, If I put the snapshot-zip version of test30.ok in the
                                working directory and cvs update test30.ok it shows that it was
                                locally modified. If I cvs update -kb test30.ok (-kb is supposed to
                                use the same line-endings as stored in the repos.) it still shows
                                modified. Vim sees test30.ok as ff=unix, so fixff will cause test30
                                to fail if you put the snapshot version in.

                                --

                                . o O pyromancer O o .
                              • Walter Briscoe
                                In message of Tue, 4 Jan 2005 09:40:59 in , Johnny Blaze writes ... -B is not a standard
                                Message 15 of 27 , Jan 4, 2005
                                  In message <804f592d05010319402ef2deab@...> of Tue, 4 Jan
                                  2005 09:40:59 in , Johnny Blaze <pyromancer@...> writes
                                  >On Sun, 02 Jan 2005 22:33:08 +0100, Bram Moolenaar <Bram@...> wrote:
                                  >>
                                  >> Johnny Blaze wrote:
                                  >>
                                  >> > test11 and test30 still fail. I used "cvs co -kb vim7/src/testdir"
                                  >> > after removing testdir. -kb is supposed to use the same line endings
                                  >> > as stored in CVS.
                                  >>
                                  >> test11 fails if gzip is not available. Perhaps that's the problem you
                                  >> are encountering?
                                  >>
                                  >> It appears the test[11|30].[in|ok] files in CVS are identical to what I
                                  >> have. Another cause for problems is a diff program that can't handle
                                  >> the different line endings.
                                  >
                                  >Bram,
                                  >
                                  >The problem with test11 appears to be the gnuwin32 port of sed. This
                                  >version of sed operates in text mode by default, which changes
                                  >line-endings to the native system (only if sed changes something, if
                                  >you run a cat-like sed script, it appears to put out what you put in).
                                  > If you run it in binary mode, it leaves line-endings alone.
                                  >
                                  >I changed the sed command in test11.in to sed -B s/e/E ... and it works fine.

                                  -B is not a standard flag in sed which only operates on text files.

                                  I download the UNIX files to an MS system. I have to convert line
                                  endings for tests. I do this with the following in a .bat file:

                                  tar c testdir | gzip -c > testdir.tar.gz
                                  move testdir testdir.0 > nul
                                  untar -cq testdir.tar.gz

                                  :: vim.bat sets echo off
                                  call vim.bat -eu NONE "+set backup backupext=.0 ff=dos" +wq Make_ivc.mak
                                  @if not %makevim%.==. @echo on
                                  call vim.bat -eu NONE "+set backup backupext=.0 ff=dos" +wq vim16.def
                                  @if not %makevim%.==. @echo on
                                  call vim.bat -eu NONE "+set backup backupext=.0 ff=dos" +wq vim.rc
                                  @if not %makevim%.==. @echo on

                                  (The echo manipulation code above is unnecessary. "vim ..." allows vim
                                  to change reporting in the calling script; "call vim ..." isolates the
                                  effect.)

                                  As I found using vim to change line endings was painfully slow, I use
                                  untar from ftp://ftp.cs.pdx.edu/pub/elvis/untar.c. - a 40k portable file

                                  I don't have time now to get back up to speed on vim testing.

                                  BTW Johnny, you did not reply to "Scenario? Numbers?" from me when you
                                  asserted a change was an optimisation. A long time ago, I absorbed 3
                                  optimisation rules which I paraphrase as: don't; don't yet; measure.
                                  --
                                  Walter Briscoe
                                • Bram Moolenaar
                                  ... Ah, that explains the problems. The -B argument is not available elsewhere, thus we can t use that. You can try adding a command to remove the extra CR
                                  Message 16 of 27 , Jan 4, 2005
                                    Johnny Blaze wrote:

                                    > The problem with test11 appears to be the gnuwin32 port of sed. This
                                    > version of sed operates in text mode by default, which changes
                                    > line-endings to the native system (only if sed changes something, if
                                    > you run a cat-like sed script, it appears to put out what you put in).
                                    > If you run it in binary mode, it leaves line-endings alone.
                                    >
                                    > I changed the sed command in test11.in to sed -B s/e/E ... and it
                                    > works fine.

                                    Ah, that explains the problems. The -B argument is not available
                                    elsewhere, thus we can't use that. You can try adding a command to
                                    remove the extra CR characters:

                                    *** testdir/test11.in~ Sun Jul 18 21:46:21 2004
                                    --- testdir/test11.in Tue Jan 4 09:55:07 2005
                                    ***************
                                    *** 44,49 ****
                                    --- 44,50 ----
                                    :au FilterReadPost *.out '[,']s/x/X/g
                                    :e! test.out " Edit the output file
                                    :23,$!cat
                                    + :23,$s/\r$// " remove CR for when sed adds them
                                    :au! FileReadPre *.gz !gzip -d <afile>
                                    :au FileReadPre *.gz call rename(expand("<afile>:r"), expand("<afile>"))
                                    :au! FileReadPost *.gz '[,']s/l/L/

                                    > Again on test30, If I put the snapshot-zip version of test30.ok in the
                                    > working directory and cvs update test30.ok it shows that it was
                                    > locally modified. If I cvs update -kb test30.ok (-kb is supposed to
                                    > use the same line-endings as stored in the repos.) it still shows
                                    > modified. Vim sees test30.ok as ff=unix, so fixff will cause test30
                                    > to fail if you put the snapshot version in.

                                    I don't understand this. It works fine for me, thus the version of
                                    test30.ok in the snapshot should be OK. Note that it is in unix format,
                                    thus fixff must change it to dos format. If you compare the files after
                                    that they will differ.

                                    I just checked again that the current files (snapshot 29) work fine for
                                    me. That is using Make_mvc.mak.

                                    --
                                    hundred-and-one symptoms of being an internet addict:
                                    218. Your spouse hands you a gift wrapped magnet with your PC's name
                                    on it and you accuse him or her of genocide.

                                    /// Bram Moolenaar -- Bram@... -- http://www.Moolenaar.net \\\
                                    /// Sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\
                                    \\\ Project leader for A-A-P -- http://www.A-A-P.org ///
                                    \\\ Buy LOTR 3 and help AIDS victims -- http://ICCF.nl/lotr.html ///
                                  • Johnny Blaze
                                    ... This works excellently. ... I found something that does work. (I have attached a patch for src/testdir/Make_dos.mak. Basically duplicate fixff s only
                                    Message 17 of 27 , Jan 4, 2005
                                      On Tue, 04 Jan 2005 11:18:31 +0100, Bram Moolenaar <Bram@...> wrote:
                                      >
                                      > Johnny Blaze wrote:
                                      >
                                      > > The problem with test11 appears to be the gnuwin32 port of sed. This
                                      > > version of sed operates in text mode by default, which changes
                                      > > line-endings to the native system (only if sed changes something, if
                                      > > you run a cat-like sed script, it appears to put out what you put in).
                                      > > If you run it in binary mode, it leaves line-endings alone.
                                      > >
                                      > > I changed the sed command in test11.in to sed -B s/e/E ... and it
                                      > > works fine.
                                      >
                                      > Ah, that explains the problems. The -B argument is not available
                                      > elsewhere, thus we can't use that. You can try adding a command to
                                      > remove the extra CR characters:
                                      >
                                      > *** testdir/test11.in~ Sun Jul 18 21:46:21 2004
                                      > --- testdir/test11.in Tue Jan 4 09:55:07 2005
                                      > ***************
                                      > *** 44,49 ****
                                      > --- 44,50 ----
                                      > :au FilterReadPost *.out '[,']s/x/X/g
                                      > :e! test.out " Edit the output file
                                      > :23,$!cat
                                      > + :23,$s/\r$// " remove CR for when sed adds them
                                      > :au! FileReadPre *.gz !gzip -d <afile>
                                      > :au FileReadPre *.gz call rename(expand("<afile>:r"), expand("<afile>"))
                                      > :au! FileReadPost *.gz '[,']s/l/L/

                                      This works excellently.

                                      > I don't understand this. It works fine for me, thus the version of
                                      > test30.ok in the snapshot should be OK. Note that it is in unix format,
                                      > thus fixff must change it to dos format. If you compare the files after
                                      > that they will differ.
                                      >
                                      > I just checked again that the current files (snapshot 29) work fine for
                                      > me. That is using Make_mvc.mak.

                                      I found something that does work. (I have attached a patch for
                                      src/testdir/Make_dos.mak. Basically duplicate fixff's only action and
                                      change ff=dos to ff=unix and make it only for test30.ok.

                                      @@ -46,6 +45,7 @@

                                      fixff:
                                      -$(VIMPROG) -u dos.vim --noplugin "+argdo set ff=dos|upd" +q *.in *.ok
                                      + -$(VIMPROG) -u dos.vim --noplugin "+argdo set ff=unix|upd" +q test30.ok

                                      -------------

                                      That seems to work everytime even after deleting the file (test30.ok)
                                      and pulling another from CVS.

                                      Its kinda kludgy, but it works.

                                      --

                                      . o O pyromancer O o .
                                    • Bram Moolenaar
                                      ... I don t like this solution, because it makes an exception for one file. It does point in the right direction: Apparently it worked for me because my diff
                                      Message 18 of 27 , Jan 4, 2005
                                        Johnny Blaze wrote:

                                        > > I don't understand this. It works fine for me, thus the version of
                                        > > test30.ok in the snapshot should be OK. Note that it is in unix
                                        > > format, thus fixff must change it to dos format. If you compare the
                                        > > files after that they will differ.
                                        > >
                                        > > I just checked again that the current files (snapshot 29) work fine for
                                        > > me. That is using Make_mvc.mak.
                                        >
                                        > I found something that does work. (I have attached a patch for
                                        > src/testdir/Make_dos.mak. Basically duplicate fixff's only action and
                                        > change ff=dos to ff=unix and make it only for test30.ok.

                                        I don't like this solution, because it makes an exception for one file.
                                        It does point in the right direction: Apparently it worked for me
                                        because my "diff" ignored differences in dos/unix file formats.
                                        test30.ok would be dos and test30.out will be unix format.

                                        For DOS I prefer all file formats to be dos (after fixff), so that there
                                        are no exceptions.

                                        Besides this, using the "cat" command will break the test for people
                                        that don't have it. I'll change the test to avoid it. Makes it
                                        portable and faster too.

                                        --
                                        hundred-and-one symptoms of being an internet addict:
                                        225. You sign up for free subscriptions for all the computer magazines

                                        /// Bram Moolenaar -- Bram@... -- http://www.Moolenaar.net \\\
                                        /// Sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\
                                        \\\ Project leader for A-A-P -- http://www.A-A-P.org ///
                                        \\\ Buy LOTR 3 and help AIDS victims -- http://ICCF.nl/lotr.html ///
                                      • Johnny Blaze
                                        ... Thanks Bram. -- . o O pyromancer O o .
                                        Message 19 of 27 , Jan 4, 2005
                                          On Tue, 04 Jan 2005 16:07:50 +0100, Bram Moolenaar <Bram@...> wrote:
                                          > For DOS I prefer all file formats to be dos (after fixff), so that there
                                          > are no exceptions.
                                          >
                                          > Besides this, using the "cat" command will break the test for people
                                          > that don't have it. I'll change the test to avoid it. Makes it
                                          > portable and faster too.

                                          Thanks Bram.

                                          --

                                          . o O pyromancer O o .
                                        • Johnny Blaze
                                          On Tue, 4 Jan 2005 08:01:21 +0000, Walter Briscoe ... Bram s got it fixed without using the -B switch. So now, its nice and portable. ... I ve been looking for
                                          Message 20 of 27 , Jan 5, 2005
                                            On Tue, 4 Jan 2005 08:01:21 +0000, Walter Briscoe
                                            <wbriscoe@...> wrote:
                                            > -B is not a standard flag in sed which only operates on text files.
                                            >
                                            > I download the UNIX files to an MS system. I have to convert line
                                            > endings for tests. I do this with the following in a .bat file:
                                            > [snip]

                                            Bram's got it fixed without using the -B switch. So now, its nice and portable.

                                            > BTW Johnny, you did not reply to "Scenario? Numbers?" from me when you
                                            > asserted a change was an optimisation. A long time ago, I absorbed 3
                                            > optimisation rules which I paraphrase as: don't; don't yet; measure.

                                            I've been looking for an MS equivalent of time on linux. I was going
                                            to time vim as it went through the tests... it should give a profile
                                            of vim doing alot of different things. then some simple load times.

                                            The data that I have now... It "pops" faster (loads) on both a 1.8GHz
                                            P4 and a 3.0GHz than it does with CPUNR=i686. It takes longer to
                                            compile, and it runs the tests faster. As you can see I have no hard
                                            numbers as of yet.


                                            --

                                            . o O pyromancer O o .
                                          • Walter Briscoe
                                            In message of Wed, 5 Jan 2005 18:36:52 in , Johnny Blaze writes ... Good! ... Look for
                                            Message 21 of 27 , Jan 6, 2005
                                              In message <804f592d050105043637e68b22@...> of Wed, 5 Jan
                                              2005 18:36:52 in , Johnny Blaze <pyromancer@...> writes
                                              >On Tue, 4 Jan 2005 08:01:21 +0000, Walter Briscoe
                                              ><wbriscoe@...> wrote:
                                              >> -B is not a standard flag in sed which only operates on text files.
                                              >>
                                              >> I download the UNIX files to an MS system. I have to convert line
                                              >> endings for tests. I do this with the following in a .bat file:
                                              >> [snip]
                                              >
                                              >Bram's got it fixed without using the -B switch. So now, its nice and portable.
                                              Good!

                                              >
                                              >> BTW Johnny, you did not reply to "Scenario? Numbers?" from me when you
                                              >> asserted a change was an optimisation. A long time ago, I absorbed 3
                                              >> optimisation rules which I paraphrase as: don't; don't yet; measure.
                                              >
                                              >I've been looking for an MS equivalent of time on linux. I was going
                                              >to time vim as it went through the tests... it should give a profile
                                              >of vim doing alot of different things. then some simple load times.
                                              Look for timethis.exe which is a crude MS elapsed time measurer. If you
                                              can't find it, I will send you a copy. Time comparison is REALLY hard
                                              due to caching. On UNIX (AIX), I never found satisfactory way to flush
                                              cache. I wrote a small MS program to time repeated runs of a given
                                              program. It measures mean and standard deviation of execution times. You
                                              then need standard difference of means techniques to estimate
                                              probability of chance giving observed results. I attach source. Real
                                              gonad crusher is that execution times are not normally distributed and I
                                              have no theory to compare anything else. It is easy where something
                                              takes one hour rather than six. It is really hard when it takes 59
                                              minutes rather than 60. I think you should probably reboot your machine
                                              before making each measurement to have any chance of repeatable results.
                                              You then have a problem that your repeatable results may not be typical.

                                              >
                                              >The data that I have now... It "pops" faster (loads) on both a 1.8GHz
                                              >P4 and a 3.0GHz than it does with CPUNR=i686. It takes longer to
                                              >compile, and it runs the tests faster. As you can see I have no hard
                                              >numbers as of yet.

                                              With rare exceptions, such as searching multi-megabyte files or running
                                              it once for each file in a directory, I find vim is fast enough.
                                              The former case can be sped by avoiding expensive things like
                                              'incsearch'; the latter by running vim once for all files in a directory
                                              if one has enough effort to improve the algorithm. That effort is not
                                              usually available.
                                            • Antoine J. Mechelynck
                                              Bram Moolenaar wrote: [...] ... Dos has equivalents of the cat command for the most common cases, as follows: Copy to stdout: Unix: cat foo.bar Dos: type
                                              Message 22 of 27 , Jan 7, 2005
                                                Bram Moolenaar wrote:
                                                [...]
                                                > Besides this, using the "cat" command will break the test for people
                                                > that don't have it. I'll change the test to avoid it. Makes it
                                                > portable and faster too.
                                                >

                                                Dos has equivalents of the "cat" command for the most common cases, as
                                                follows:

                                                Copy to stdout:
                                                Unix: cat foo.bar
                                                Dos: type foo.bar

                                                Append:
                                                Unix: cat foo.txt >> bar.txt
                                                Dos: type foo.txt >> bar.txt

                                                Concatenate:
                                                Unix: cat file1 file2 file3 > file4
                                                Dos: copy /B file1+file2+file3 file4

                                                (the /B is optional, it forces "binary" or "raw" mode. /A would mean
                                                "ASCII" or "cooked" mode instead, including stop on Ctrl-Z and add
                                                Ctrl-Z at EOF if not present. The default depends on the file type
                                                [extension or device name].)

                                                Just FYI (my 0,02€).
                                                Best regards,
                                                Tony.
                                              • Antoine J. Mechelynck
                                                Johnny Blaze wrote: [...] ... [...] I m not sure what time on Linux does but Dos has date and time commands: DATE [new date] TIME [new time] Arguments (if
                                                Message 23 of 27 , Jan 7, 2005
                                                  Johnny Blaze wrote:
                                                  [...]
                                                  > I've been looking for an MS equivalent of time on linux. I was going
                                                  > to time vim as it went through the tests... it should give a profile
                                                  > of vim doing alot of different things. then some simple load times.
                                                  [...]

                                                  I'm not sure what time on Linux does but Dos has "date" and "time" commands:

                                                  DATE [new date]

                                                  TIME [new time]

                                                  Arguments (if present) are locale-dependent. If called without an
                                                  argument, each of these commands displays the current value then asks
                                                  for a new setting. (The prompt for DATE tells you which format is
                                                  expected.) A workaround (to display the date/time without changing it)
                                                  would be

                                                  DATE < nul
                                                  TIME < nul

                                                  but of course they still display the prompts, which may in this case be
                                                  regarded as interspersed garbage. This may or may not suit you.

                                                  In CMD.EXE only (not in COMMAND.COM), and only when command extensions
                                                  are enabled, you can also use

                                                  DATE /T
                                                  TIME /T

                                                  to display the current values with no prompting. On my system,
                                                  "time<nul" displays the time to the last tenth of a second, but "time/t"
                                                  only gives it to the minute, which might not be precise enough for you.

                                                  Note: IIRC (and if ECHO ON displays the %PROMPT% -- I haven't tested it
                                                  recently in batch), you can also achieve timestamping of all commands in
                                                  a batch script with

                                                  ECHO ON
                                                  PROMPT $D^I$T$_$P$G

                                                  instead of the more usual "@ECHO OFF" at the start. ^I is an actual hard
                                                  tab (or spaces if you like that better). This gives a timestamp (to the
                                                  tenth of a second in COMMAND.COM or CMD.EXE) immediately above each
                                                  executed command. Or remove the $_$P and you get the timestamp (instead
                                                  of the current drive and directory) left of the > prompt.

                                                  HTH,
                                                  Tony.
                                                • Johnny Blaze
                                                  I compiled two different versions. The only difference is CPUNR=i686 and CPUNR=P4. These are from the vim7 module in CVS current as of 10:00PM CST
                                                  Message 24 of 27 , Jan 7, 2005
                                                    I compiled two different versions. The only difference is CPUNR=i686
                                                    and CPUNR=P4. These are from the vim7 module in CVS current as of
                                                    10:00PM CST 1/6/2004.

                                                    I ran two test runs for the cli and the gui

                                                    Test1: run the test suite
                                                    Test2: load vim and quit immediately ((g)vim +q) in the build
                                                    directory, which should mean minimal options/plugins etc.

                                                    Note: the gui tests are a little skewed (they should be shorter)
                                                    since when the gui runs the tests, vimrun pops a window that you have
                                                    to press enter before it returns control. I practiced a few times and
                                                    think that the skew is minimal.

                                                    Test System: P4 2.6GHz, 1GB Ram (DDR200), UDMA hard drive, WinXPSP2

                                                    Results:

                                                    Test1:
                                                    --------
                                                    (i686, cli) = 1:08.750
                                                    (P4, cli) = 1:07.562
                                                    ========
                                                    difference: P4 1.188 seconds faster

                                                    (i686, gui) = 1:17.985
                                                    (P4, gui) = 1:16.203
                                                    ========
                                                    difference: P4 1.782 seconds faster

                                                    Test2:
                                                    --------
                                                    (i686, cli) = 0.360
                                                    (P4, cli) = 0.344
                                                    =========
                                                    difference: P4 0.016 seconds faster

                                                    (i686, gui) = 0.531
                                                    (P4, gui) = 0.484
                                                    =========
                                                    difference: P4 0.047 seconds faster

                                                    I've noticed that several people were sceptical about any performance
                                                    gain. I realize that these gains are quite small, but they are
                                                    performance gains. Seeing as how there were no actual code changes
                                                    needed to get this performance increase, only a different compiler
                                                    option, I don't know why anyone would protest the option being
                                                    available.


                                                    On Thu, 6 Jan 2005 09:38:06 +0000, Walter Briscoe
                                                    <wbriscoe@...> wrote:
                                                    > In message <804f592d050105043637e68b22@...> of Wed, 5 Jan
                                                    > 2005 18:36:52 in , Johnny Blaze <pyromancer@...> writes
                                                    > >On Tue, 4 Jan 2005 08:01:21 +0000, Walter Briscoe
                                                    > ><wbriscoe@...> wrote:
                                                    > >> -B is not a standard flag in sed which only operates on text files.
                                                    > >>
                                                    > >> I download the UNIX files to an MS system. I have to convert line
                                                    > >> endings for tests. I do this with the following in a .bat file:
                                                    > >> [snip]
                                                    > >
                                                    > >Bram's got it fixed without using the -B switch. So now, its nice and portable.
                                                    > Good!
                                                    >
                                                    > >
                                                    > >> BTW Johnny, you did not reply to "Scenario? Numbers?" from me when you
                                                    > >> asserted a change was an optimisation. A long time ago, I absorbed 3
                                                    > >> optimisation rules which I paraphrase as: don't; don't yet; measure.
                                                    > >
                                                    > >I've been looking for an MS equivalent of time on linux. I was going
                                                    > >to time vim as it went through the tests... it should give a profile
                                                    > >of vim doing alot of different things. then some simple load times.
                                                    > Look for timethis.exe which is a crude MS elapsed time measurer. If you
                                                    > can't find it, I will send you a copy. Time comparison is REALLY hard
                                                    > due to caching. On UNIX (AIX), I never found satisfactory way to flush
                                                    > cache. I wrote a small MS program to time repeated runs of a given
                                                    > program. It measures mean and standard deviation of execution times. You
                                                    > then need standard difference of means techniques to estimate
                                                    > probability of chance giving observed results. I attach source. Real
                                                    > gonad crusher is that execution times are not normally distributed and I
                                                    > have no theory to compare anything else. It is easy where something
                                                    > takes one hour rather than six. It is really hard when it takes 59
                                                    > minutes rather than 60. I think you should probably reboot your machine
                                                    > before making each measurement to have any chance of repeatable results.
                                                    > You then have a problem that your repeatable results may not be typical.
                                                    >
                                                    > >
                                                    > >The data that I have now... It "pops" faster (loads) on both a 1.8GHz
                                                    > >P4 and a 3.0GHz than it does with CPUNR=i686. It takes longer to
                                                    > >compile, and it runs the tests faster. As you can see I have no hard
                                                    > >numbers as of yet.
                                                    >
                                                    > With rare exceptions, such as searching multi-megabyte files or running
                                                    > it once for each file in a directory, I find vim is fast enough.
                                                    > The former case can be sped by avoiding expensive things like
                                                    > 'incsearch'; the latter by running vim once for all files in a directory
                                                    > if one has enough effort to improve the algorithm. That effort is not
                                                    > usually available.
                                                    >
                                                    >
                                                    > --
                                                    > Walter Briscoe
                                                    >
                                                    >
                                                    >
                                                    >


                                                    --

                                                    . o O pyromancer O o .
                                                  • Dan Sharp
                                                    ... Sorry for not thinking of this earlier, but would you care to change the P4 option value to pentium4 instead? This would make it consistent with the gcc
                                                    Message 25 of 27 , Jan 7, 2005
                                                      Johnny Blaze wrote:
                                                      > On Sat, 01 Jan 2005 14:23:06 +0100, Bram Moolenaar <Bram@...> wrote:
                                                      >
                                                      >>>I have attached a patch to Make_mvc.mak. It adds another CPUNR option
                                                      >>>and removes some debug options from CFLAGS, PDB, and LINK_PDB.
                                                      >>>
                                                      >>>CPUNR: Adds "P4" to the list. It uses the options /G7 and /arch:SSE2.
                                                      >>> This causes CL to optimize the code specifically for P4 and AMD
                                                      >>>processors that implement SSE2 instructions. /arch:SSE2 is a new
                                                      >>>option as of VC7.0.
                                                      >>
                                                      >>Looks OK. P4 also needs to be added to the comments at line 58.
                                                      >
                                                      >
                                                      > got it.

                                                      Sorry for not thinking of this earlier, but would you care to change the
                                                      P4 option value to pentium4 instead? This would make it consistent with
                                                      the gcc values for ARCH (and formerly CPUNR) in Make_cyg.mak and
                                                      Make_ming.mak, which include values like i386, i486, i586, i686,
                                                      pentium, pentium-mmx, pentiumpro, pentium2, pentium3, pentium4,
                                                      prescott, nocona, k6, k6-2, k6-3, athlon, athlon-tbird, athlon-4,
                                                      athlon-xp, athlon-mp, winchip-c6, winchip2 and c3 [from the gcc 3.3.3
                                                      man page]. I don't know if the msvc compiler supports all these
                                                      targets, but for those it does I think it would be a good idea to use a
                                                      matching name.

                                                      Also, in earlier messages it was decided to remove the CPUNR option from
                                                      Make_cyg.mak and Make_ming.mak in favor of ARCH. I was wondering if
                                                      the ARCH option could be renamed CPUNR as well. It would still do
                                                      everything that ARCH currently does, and everything the previous CPUNR
                                                      option did would still be removed. Alternatively, the CPUNR option in
                                                      Make_mvc.mak and Make_bc5.mak could be renamed ARCH.

                                                      The main reason for the above two suggestions is consistency. The four
                                                      win32 makefiles (Make_bc5.mak, Make_cyg.mak, Make_ming.mak, and
                                                      Make_mvc.mak) should have as much in common as possible so that you can
                                                      use the same compile options for each one. The above two changes would
                                                      let CPUNR=pentium4 work in all four makefiles (in Make_bc5.mak it would
                                                      be unrecognized and simply get converted to i386).

                                                      Dan Sharp
                                                    • Bram Moolenaar
                                                      ... Does MSVC understand pentium4 ? Then we can change P4 to pentium4. ... For things that are CPU numbers we should use CPUNR. ARCH sounds more like
                                                      Message 26 of 27 , Jan 8, 2005
                                                        Dan Sharp wrote:

                                                        > >>Looks OK. P4 also needs to be added to the comments at line 58.
                                                        >
                                                        > Sorry for not thinking of this earlier, but would you care to change the
                                                        > P4 option value to pentium4 instead? This would make it consistent with
                                                        > the gcc values for ARCH (and formerly CPUNR) in Make_cyg.mak and
                                                        > Make_ming.mak, which include values like i386, i486, i586, i686,
                                                        > pentium, pentium-mmx, pentiumpro, pentium2, pentium3, pentium4,
                                                        > prescott, nocona, k6, k6-2, k6-3, athlon, athlon-tbird, athlon-4,
                                                        > athlon-xp, athlon-mp, winchip-c6, winchip2 and c3 [from the gcc 3.3.3
                                                        > man page]. I don't know if the msvc compiler supports all these
                                                        > targets, but for those it does I think it would be a good idea to use a
                                                        > matching name.

                                                        Does MSVC understand "pentium4"? Then we can change P4 to pentium4.

                                                        > Also, in earlier messages it was decided to remove the CPUNR option from
                                                        > Make_cyg.mak and Make_ming.mak in favor of ARCH. I was wondering if
                                                        > the ARCH option could be renamed CPUNR as well. It would still do
                                                        > everything that ARCH currently does, and everything the previous CPUNR
                                                        > option did would still be removed. Alternatively, the CPUNR option in
                                                        > Make_mvc.mak and Make_bc5.mak could be renamed ARCH.

                                                        For things that are CPU numbers we should use CPUNR. ARCH sounds more
                                                        like "architecture", which could mean many things.

                                                        > The main reason for the above two suggestions is consistency. The four
                                                        > win32 makefiles (Make_bc5.mak, Make_cyg.mak, Make_ming.mak, and
                                                        > Make_mvc.mak) should have as much in common as possible so that you can
                                                        > use the same compile options for each one. The above two changes would
                                                        > let CPUNR=pentium4 work in all four makefiles (in Make_bc5.mak it would
                                                        > be unrecognized and simply get converted to i386).

                                                        That's good. For Vim 7 we can make changes like this.

                                                        --
                                                        GOD: That is your purpose Arthur ... the Quest for the Holy Grail ...
                                                        "Monty Python and the Holy Grail" PYTHON (MONTY) PICTURES LTD

                                                        /// Bram Moolenaar -- Bram@... -- http://www.Moolenaar.net \\\
                                                        /// Sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\
                                                        \\\ Project leader for A-A-P -- http://www.A-A-P.org ///
                                                        \\\ Buy LOTR 3 and help AIDS victims -- http://ICCF.nl/lotr.html ///
                                                      • Dan Sharp
                                                        ... Not directly, but that doesn t matter. Make_mvc.mak just looks at the value of CPUNR and converts it to the appropriate /Gx option, so it really shouldn t
                                                        Message 27 of 27 , Jan 8, 2005
                                                          Bram Moolenaar wrote:

                                                          > Dan Sharp wrote:
                                                          >
                                                          >>>> Looks OK. P4 also needs to be added to the comments at line 58.
                                                          >>
                                                          >>
                                                          >> Sorry for not thinking of this earlier, but would you care to change
                                                          >> the P4 option value to pentium4 instead? This would make it
                                                          >> consistent with the gcc values for ARCH (and formerly CPUNR) in
                                                          >> Make_cyg.mak and Make_ming.mak, which include values like i386, i486,
                                                          >> i586, i686, pentium, pentium-mmx, pentiumpro, pentium2, pentium3,
                                                          >> pentium4, prescott, nocona, k6, k6-2, k6-3, athlon, athlon-tbird,
                                                          >> athlon-4, athlon-xp, athlon-mp, winchip-c6, winchip2 and c3 [from the
                                                          >> gcc 3.3.3 man page]. I don't know if the msvc compiler supports all
                                                          >> these targets, but for those it does I think it would be a good idea
                                                          >> to use a matching name.
                                                          >
                                                          > Does MSVC understand "pentium4"? Then we can change P4 to pentium4.

                                                          Not directly, but that doesn't matter. Make_mvc.mak just looks at the
                                                          value of CPUNR and converts it to the appropriate /Gx option, so it
                                                          really shouldn't matter which label is used to assign the value.
                                                          Make_cyg.mak and Make_ming.mak are the ones that use the value directly
                                                          (-march=$CPUNR) so those must use use correct value, like pentium4.

                                                          >> Also, in earlier messages it was decided to remove the CPUNR option
                                                          >> from Make_cyg.mak and Make_ming.mak in favor of ARCH. I was
                                                          >> wondering if the ARCH option could be renamed CPUNR as well. It
                                                          >> would still do everything that ARCH currently does, and everything
                                                          >> the previous CPUNR option did would still be removed. Alternatively,
                                                          >> the CPUNR option in Make_mvc.mak and Make_bc5.mak could be renamed
                                                          >> ARCH.
                                                          >
                                                          > For things that are CPU numbers we should use CPUNR. ARCH sounds more
                                                          > like "architecture", which could mean many things.

                                                          Sounds good. The ARCH option does mean architecture, because that is
                                                          what is getting set by it (the -march compile flag) for gcc. The CPUNR
                                                          option was used to set the -mcpu compile flag for gcc. MSVC and BCC55
                                                          only have one option to set, but I am not sure if it corresponds more to
                                                          the -march or the -mcpu option. Using CPUNR for all of them would
                                                          probably be the safest bet.

                                                          Dan Sharp
                                                        Your message has been successfully submitted and would be delivered to recipients shortly.