ruby-core@ruby-lang.org archive (unofficial mirror)
 help / color / mirror / Atom feed
From: "Christoph" <chr_news@gmx.net>
To: <ruby-core@ruby-lang.org>
Subject: RE: Mswin32 build flags
Date: Wed, 4 Sep 2002 03:51:20 +0900	[thread overview]
Message-ID: <000001c2537a$7e290c10$0100a8c0@lony> (raw)
In-Reply-To: <20020816160523.8A67.USA@osb.att.ne.jp>



> -----Original Message-----
> From: U.Nakamura [mailto:usa@osb.att.ne.jp]
> Sent: Friday, August 16, 2002 9:13 AM
> To: ruby-core@ruby-lang.org
> Subject: Re: Mswin32 build flags
> 
> Hello,
> 
> In message "Mswin32 build flags"
>     on Aug.16,2002 15:52:41, <chr_news@gmx.net> wrote:
> | Unfortunately these builds also miserably fail the basic
> | ``nmake test'', however by only turning off the /Og
> | flag turning the compilation of the file ``sprint.c''
> | one seems to get an executable which seem to enjoy
> | the speed gain of a full /Og optimization which
> | passes the basic  "nmake test" (true at least for
> | VC 7) - so I am wondering if there are known issues
> | against such a compilation strategy?
> 
> Because there are more problems with /Og flag
> (GC, Regexp, etc).
> So, I cannot say that /Og is reliable.

Thanks  (and sorry for the late reply) 


I played around with this yesterday and essentially found 
four methods which not should be compiled with the /Og flag 
(turned on/off with the optimize pragma)


rb_big2dbl(x) ( bignum.c  811 )
rb_f_sprintf  ( sprintf.c 105 )
rb_obj_as_string(obj) ( string.c  280)
pack_pack     ( pack.c 332 ) 

Compiled like this ruby (1.7.3 (2002-08-29) [i386-mswin32])
fails no additional rubicon test, in fact it passes one 
additional, hence all, thread tests (on my machine at least).
An additional advantage is that the notoriously low recursion
limit (on mswin32) is also improved by a factor of two.  

It is really a pity that the /Og flag is not totally reliable,
but why not make it a configure option or at least mention it 
the ``README''  + put on/off optimize macros around known ``iffy''
methods? The speed increase is sooo substantial that it should not
be ignored imho - (I'm particularly thinking about Andy's binary 
distribution here).

   

/Christoph

  reply	other threads:[~2002-09-03 18:48 UTC|newest]

Thread overview: 42+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2002-07-24 15:02 [PATCH] object.c ruby.h (fwd) Robert Skarwecki
2002-07-24 16:51 ` Boolean class (Re: [PATCH] object.c ruby.h) Yukihiro Matsumoto
2002-07-24 19:50 ` [PATCH] object.c ruby.h (fwd) GOTO Kentaro
2002-07-24 20:05   ` Dave Thomas
2002-07-25  4:22     ` unifying nil and false (Re: [PATCH] object.c ruby.h) Yukihiro Matsumoto
2002-07-25  4:59       ` Dave Thomas
2002-07-25  6:46         ` Yukihiro Matsumoto
2002-07-25 11:06     ` [PATCH] object.c ruby.h (fwd) GOTO Kentaro
2002-07-25 13:20       ` Dave Thomas
2002-07-25 17:42         ` nobu.nokada
2002-07-25 17:55           ` Dave Thomas
2002-07-25 18:11             ` nobu.nokada
2002-07-25 18:28               ` Dave Thomas
2002-07-25 19:53               ` GOTO Kentaro
2002-07-25 20:34                 ` Dave Thomas
2002-07-25 22:23                   ` GOTO Kentaro
2002-07-27  8:04                     ` Masaki Suketa
2002-07-27 12:40                       ` Dave Thomas
2002-08-03  9:04                         ` Masaki Suketa
2002-08-05  1:39                           ` NAKAMURA, Hiroshi
2002-08-06 11:53                             ` Masaki Suketa
2002-08-09 13:20                               ` NAKAMURA, Hiroshi
2002-08-10 12:19                                 ` Masaki Suketa
2002-08-12  3:48                                   ` NAKAMURA, Hiroshi
2002-07-26 10:11                   ` YANAGAWA Kazuhisa
2002-07-31 14:47                     ` A truth? patch + benchmarks Christoph
2002-07-31 15:03                       ` ts
2002-08-01  6:39                         ` Christoph
2002-08-01  7:02                           ` Yukihiro Matsumoto
2002-08-02  7:12                             ` Christoph
2002-08-02  7:20                               ` ts
2002-08-02  8:54                                 ` Christoph
2002-08-03  9:51                               ` Yukihiro Matsumoto
2002-08-05  0:58                                 ` Christoph
2002-08-05  1:44                                   ` nobu.nokada
2002-08-16  6:52               ` Mswin32 build flags Christoph
2002-08-16  7:12                 ` U.Nakamura
2002-09-03 18:51                   ` Christoph [this message]
2002-07-26  1:16         ` [PATCH] object.c ruby.h (fwd) NAKAMURA, Hiroshi
2002-07-26 15:23       ` Michal Rokos
2002-07-26 15:31         ` Dave Thomas
2002-07-26 16:37         ` Yukihiro Matsumoto

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-list from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.ruby-lang.org/en/community/mailing-lists/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='000001c2537a$7e290c10$0100a8c0@lony' \
    --to=ruby-core@ruby-lang.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).