I don't know who the STL gatekeeper is. It seemed to be better if this is submitted to STL community? If there is no suggestion within a couple of days, I might forward? Shin, any suggestion? For what it's worth, the open64 compiler's base (i.e. SGI compiler) used to have a lot of input improving STL's API, performance etc, it will be great to reinvigorate this tradition again. :-) Sun
2011/6/1 Das, Dibyendu <dibyendu....@amd.com>: > Regarding the first question, there will be binary compatibility issue if g++ > and open64 generated binaries are mixed and matched. > > Regarding the second part, we can support a new flag with the fast STL as a > default for an upcoming release. Is that going to gate this checkin ? > > -tx > Dibyendu > > -----Original Message----- > From: Christopher Bergström [mailto:cbergst...@pathscale.com] > Sent: Wednesday, June 01, 2011 12:00 PM > To: Das, Dibyendu > Cc: C Bergström; Open64-devel@lists.sourceforge.net > Subject: Re: [Open64-devel] Code Review Request for changes in STL tree > implementation to speed up set<>/map<> > > On Wed, Jun 1, 2011 at 2:15 PM, Das, Dibyendu <dibyendu....@amd.com> wrote: >> A few more points. >> 1) The new 1.C with and without -D__OPEN64_FAST_SET will show speedups ( the >> earlier one I sent was illustrative only ) >> 2) Basically, your set/map iteration should be hot to get improvement. If >> not you may not get any speedups ( and maybe minor slowdowns ). This is >> another reason not to enable this feature as a default. > > To be pragmatic about this.. > > I'd bet the number of Open64 C++ users is *very* small and there may > in fact not be any in production use at all (Not being rude here, but > if someone uses and depends on the Open64 c++ compiler please speak > up) With this being the case are you worried about binary compat with > the system installed g++ or just compat against previously compiled > Open64 code? As long as it's not a benchmark hack a plan should be > made when it'll be enabled by default and alert users of the binary > breaking change. > > In general this change should also be documented somewhere so it's > accessible to end users. -ffast-stl, turned on with -Ofast or > something along those lines.. > > Just my 0.02$ and hope this makes sense. > > > > ------------------------------------------------------------------------------ > Simplify data backup and recovery for your virtual environment with vRanger. > Installation's a snap, and flexible recovery options mean your data is safe, > secure and there when you need it. Data protection magic? > Nope - It's vRanger. Get your free trial download today. > http://p.sf.net/sfu/quest-sfdev2dev > _______________________________________________ > Open64-devel mailing list > Open64-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/open64-devel > ------------------------------------------------------------------------------ Simplify data backup and recovery for your virtual environment with vRanger. Installation's a snap, and flexible recovery options mean your data is safe, secure and there when you need it. Data protection magic? Nope - It's vRanger. Get your free trial download today. http://p.sf.net/sfu/quest-sfdev2dev _______________________________________________ Open64-devel mailing list Open64-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/open64-devel
