ubuntu12
fedora16
the hooks are there, but marked as "deprecated"
On Tue, Jun 11, 2013 at 4:05 AM, Jeff Squyres (jsquyres) wrote:
> On Jun 10, 2013, at 10:29 AM, "Barrett, Brian W"
> wrote:
>
> > At least they've finally come to that conclusion. I look forward to not
> > shipping a memory al
On Jun 11, 2013, at 9:37 AM, Mike Dubman wrote:
> ubuntu12
> fedora16
>
> the hooks are there, but marked as "deprecated"
Does that mean they come up with a compiler warning?
>
> On Tue, Jun 11, 2013 at 4:05 AM, Jeff Squyres (jsquyres)
> wrote:
> On Jun 10, 2013, at 10:29 AM, "Barrett, Bri
yes
On Tue, Jun 11, 2013 at 5:10 PM, Jeff Squyres (jsquyres) wrote:
> On Jun 11, 2013, at 9:37 AM, Mike Dubman wrote:
>
> > ubuntu12
> > fedora16
> >
> > the hooks are there, but marked as "deprecated"
>
> Does that mean they come up with a compiler warning?
>
>
> >
> > On Tue, Jun 11, 2013 at
On Jun 10, 2013, at 9:05 PM, Jeff Squyres wrote:
> That being said, that release note was for glibc 2.14. I just downloaded and
> built 2.17; it looks like a) the hooks are still there, and b) they're still
> installed by default.
Ah -- I see what happened. glibc marked the hook interfaces w
On Mon, Jun 10, 2013 at 06:53:36PM +0200, George Bosilca wrote:
>
> On Jun 10, 2013, at 17:18 , Nathan Hjelm wrote:
>
> > On Sat, Jun 08, 2013 at 12:28:02PM +0200, George Bosilca wrote:
> >> All Windows objects that are managed as HANDLES can easily be modified to
> >> have static initializer.
On Jun 11, 2013, at 9:09 AM, Nathan Hjelm wrote:
> On Mon, Jun 10, 2013 at 06:53:36PM +0200, George Bosilca wrote:
>>
>> On Jun 10, 2013, at 17:18 , Nathan Hjelm wrote:
>>
>>> On Sat, Jun 08, 2013 at 12:28:02PM +0200, George Bosilca wrote:
All Windows objects that are managed as HANDLES
On Tue, Jun 11, 2013 at 09:13:01AM -0700, Ralph Castain wrote:
>
> On Jun 11, 2013, at 9:09 AM, Nathan Hjelm wrote:
>
> > On Mon, Jun 10, 2013 at 06:53:36PM +0200, George Bosilca wrote:
> >>
> >> On Jun 10, 2013, at 17:18 , Nathan Hjelm wrote:
> >>
> >>> On Sat, Jun 08, 2013 at 12:28:02PM +02
On Jun 11, 2013, at 9:16 AM, Nathan Hjelm wrote:
> On Tue, Jun 11, 2013 at 09:13:01AM -0700, Ralph Castain wrote:
>>
>> On Jun 11, 2013, at 9:09 AM, Nathan Hjelm wrote:
>>
>>> On Mon, Jun 10, 2013 at 06:53:36PM +0200, George Bosilca wrote:
On Jun 10, 2013, at 17:18 , Nathan Hjelm
What: Implement a better hash function in opal_hash_table_t. The function is a
simple one-at-a-time Jenkin's hash (see
http://en.wikipedia.org/wiki/Jenkins_hash_function) and has good collision
rates and isn't overly complex or slow.
Why: I am preparing an update to the MCA variable system (add
Hello,
one of the best hash functions I know is crc32. It is not very expensive,
especially with modern CPUs where it is implemented as the CPU instruction.
Hope this helps.
Kind regards,
Alex Granovsky
-Original Message-
From: Nathan Hjelm
Sent: Wednesday, June 12, 2013 1:32 AM
T
The one-at-the-time version computes on chars, if the performance of the hash
function is a critical element in the equation then you will be better off
avoiding its usage. I would suggest going with Murmur
(http://en.wikipedia.org/wiki/MurmurHash) instead, which is faster and perform
well in r
I think as long as we are updating this we might as well add a performant hash
function. I see Murmur2 is 32-bit and has a public domain implementation:
https://code.google.com/p/smhasher/source/browse/trunk/MurmurHash2.cpp
Since Murmur2 hashes in 4-byte blocks I expect it probably would perform
On Jun 12, 2013, at 00:22 , Nathan Hjelm wrote:
> Though a hardware accelerated crc32 (if available) would probably work great
> as well.
http://google-opensource.blogspot.fr/2011/04/introducing-cityhash.html
with code available under MIT @ https://code.google.com/p/cityhash/
George.
13 matches
Mail list logo
