Hi Patrik,

 

Thanks for the reply! I certainly understand the 64-bit changes with the background you provided. I agree that it might be worth it to turn *all* variables to size_t/ptrdiff_t for full 64-bit compatibility (and thus portability). Of course this isn’t a trivial change and I think you’d want to make it conditional to preserve the current “int” based API for many users. So maybe next release!

 

I do have a patch ready to fix the alignment pragmas and a few other trivial changes to clean up some compiler warnings on a few platforms. I’ll submit that patch right away. I’ll also dig a little deeper into the slew of compiler warnings where there appears to be 64 to 32-bit truncations and submit to the issue tracker.

 

Thanks again,

 

-Matt


On Sun, Jun 24, 2012 at 9:33 PM, Patrik Jonsson <code@familjenjonsson.org> wrote:
Hi Matt,

Since I'm the one that did the 64-bit and alignment changes, I thought
I'd pitch in.

When I did the 64-bit update, the purpose was to enable arrays with
>2^32 elements. This was pretty easy, as it only required changes to
the datatype used when calculating the indexing into the array This is
done in only a few places, so was not a very intrusive change. To
minimize the probability of introducing errors, I purposely did not go
through and change the type of the array *extents* themselves. These
are used in many more places and I didn't feel sufficiently familiar
with the code at the time to make that change. So, it's presently not
possible to have arrays with extents along single dimensions >2^32.
However, I'm not aware of any places where the 64-bit element index is
truncated back to 32 bit. That would indeed break arrays with 64-bit
number of elements, so if you have found any such examples I'd
encourage you to report it on the issue tracker so it can be fixed.

It might be good to change *all* variables to size_t/ptrdiff_t, so
blitz is fully 64-bit compatible (though that will also double the
size of the Array object which is already quite large). That does
however require essentially going through every line of code.

About the alignment/vectorization pragmas, I wanted to make them
portable between different compilers. What I had not realized is that
it is not possible to put #pragmas in preprocessor macros. So the only
way to implement different alignment pragmas for different compilers
is to hard-code them in a set of #ifdefs in each place... Since right
now icpc is the only compiler that has them (that I know of), it's not
a big deal, but it clearly won't scale.  The whole thing made me a bit
disappointed, so it's probably right that I never went through and
comprehensively added the check for BZ_USE_ALIGNMENT_PRAGMAS. It's
probably easier for someone who has a compiler that warns about the
unrecognized pragmas to find them all... ;-) If you've already patched
this, please send the patch and I'll commit it.

The reason your CXXFLAGS don't get passed is because blitz by default
overwrites them with its own flags. Use the --no-cxx-flags-preset
option to configure to disable this.

cheers,

/Patrik

On Fri, Jun 22, 2012 at 9:09 PM, Matt Bingen <mjbingen@gmail.com> wrote:
> Hi Julian,
>
> I'm very excited to hear about an upcoming release! I'm speaking for a team
> with a handful of developers, and we've all really enjoyed learning blitz
> and appreciate the work you have done thus far. I just wanted to reach out
> with a few observations and offer any help you may need since I've been
> doing a lot of building/testing with the latest code in the Mercurial
> repository.
>
> My team has mostly been using a version from 2009 from the CVS repository
> since it has been very stable for us. Recently we've been looking at getting
> some of the newer stuff and testing it out (great timing with the release!).
> So here are a few things I've noticed, and expect others might as well
> moving from 0.09 to 0.10. Note that we've been compiling in 64-bit Linux
> with gcc 4.4.5 and 4.3.3 as well as Windows VS2010 x64 and Win32.
>
> A change since 0.09 that required a fair amount of refactoring in our code
> was the update to using size_t and ptrdiff_t for sizes and strides. I think
> this is a great change for portability and safety, and well worth the
> refactoring. However, I noticed a few spots where it's not quite consistent
> or complete. There are a lot of places where int is still used in place of
> ptrdiff_t (or interchangeably). Thus a lot of value truncation and "possible
> loss of data" occur on most 64-bit platforms. Granted, unless people are
> using very large arrays or doing unique indexing there aren't too many
> safety concerns, but I think with a little work the interfaces could be a
> little more robust. Since a lot of the common APIs have changed already,
> seems like it could be worthwhile to update them all for consistency. Also,
> the compiler warning list generated from an x64 Windows build is not very
> comforting, largely due to the amount of ptrdiff_t to int truncations. A few
> specific examples are in range.h an range.cc in the "length" and
> "operator[]" members respectively. This is one area I've specifically looked
> at trying to clean up. I don't know the history behind a lot of the
> components or the extent of such a cleanup, but if you have any direction or
> suggestions I'd be glad to help.
>
> There are a few spots where there are alignment pragmas without the
> BZ_USE_ALIGNMENT_PRAGMAS check around them. Specifically in tvevaluate.h,
> tmevalute.h, and globeval.cc. For those not using Intel compilers, the
> warning list can get quite large :-)
>
> I noticed a slight issue with the configure setup in Linux with regard to
> passing CXXFLAGS. If I run "autoreconf -fiv" followed by "configure
> --prefix=$(MY_DIR) CXXFLAGS=-DMY_FLAG CPPFLAGS=-DMY_OTHER_FLAG" the CXXFLAGS
> do not seem to be passed to the Makefile correctly and get overwritten by
> default options or are left empty. The CPPFLAGS gets passed just fine.
> Couldn't seem to figure this one out, maybe just a weird quirk?
>
> I hope these issues help you gauge where some users might be coming from. I
> know it's hard to weigh getting releases out, not "breaking" users, and
> making things very clean, but let me know if I can help in any way with
> patches, testing, or more feedback.
>
> Thanks,
>
> -Matt
>
> ------------------------------------------------------------------------------
> Live Security Virtual Conference
> Exclusive live event will cover all the ways today's security and
> threat landscape has changed and how IT managers can respond. Discussions
> will include endpoint security, mobile security and the latest in malware
> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
> _______________________________________________
> Blitz-devel mailing list
> Blitz-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/blitz-devel
>