Re: Maximum String size in Java?
From: Randy Howard (randyhoward_at_FOOverizonBAR.net)
Date: 03/06/05
- Next message: james: "From buffer to Bitmap"
- Previous message: jasonbwork_at_hotmail.com: "Re: Does US Patent 863 enable Web O/S?"
- In reply to: websnarf_at_gmail.com: "Re: Maximum String size in Java?"
- Next in thread: CBFalconer: "Re: Maximum String size in Java?"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Date: Sun, 06 Mar 2005 15:17:09 GMT
In article <1110105341.380637.160840@g14g2000cwa.googlegroups.com>,
websnarf@gmail.com says...
> Randy Howard wrote:
> > Lightbulb NMI. I get what you are saying now. My response to this
> > would be that you do not have to. You need only support those that
> > you are aware of directly, and have a error output during
> > compilation on any new target platform that does not already have
> > either an implementation <stdint.h>, or code added to your own
> > "stdint.h".
> >
> > Perhaps along with a note that you would like any modifications for a
> > new, previously untargeted platform emailed to a particular email
> > address so you can include them in a base package on your website,
> > sf.net, whatever.
> >
> > It's not ideal, but could become very close to ideal over time,
> > provided it is widely used and you get useful feedback from those
> > who use it.
>
> Hmmm ... I spent a couple hours looking into this. What do you think
> of:
>
> http://www.azillionmonkeys.com/qed/stdint.h
>
> as a first cut?
Well, it's a lot more expansive than I expected, so it will take a
while to digest. I figured you would start with something a bit
smaller, focused on the bits needed for SFH. :-)
Do you have a version of SFH posted with changes to use this file
yet? I can give it a try, but I don't have a working Win64 XP Beta
install right now, I'd like to try it with MS' compiler for AMD64.
gcc has one, but I could bypass it and use this instead.
I will say that it could do with a lot less sarcasm, slings at the
ANSI committee and comments upon social security benefits, but
do what you must.
> Of course, its not much use to these CDC Cyber's or strange 36 bit
> DSPs, or Tandem OneStops or whatever.
True, but that's their problem. If they intend to use a hash
function that requires something not attainable on the hardware,
that's not your fault. If they can figure out a way to mangle
the file such that the code works as expected on the hardware,
great. Let em try.
> I think the main
> compilers that are outstanding are Borland C and Sun (which should
> mostly work anyways.) But I would need feedback for Itaniums, x86-64,
> (Ultra)Sparc, Xscale, AIX/Power and some IBM mainframes before I could
> make any serious claim to this thing being universally portable.
So don't make the claim. Say it's a starting point, and that it has
primarily been tested with SFH only, not broader scale applications.
You may also want to take a look at http://www.lysator.liu.se/c/q8/
which has some work Doug Gwyn did on this front. I should have
mentioned it before, in case you were not already familiar with it,
it might have saved you some time and effort.
> > I should think that there is a broad enough representation of
> > obscure platforms available to developers between the c.l.c.,
> > alt.folklore.computers and right here that such a file could be
> > very well fleshed out in short time.
>
> I think its highly unlikely that such a file would ever have an
> audience in clc. Remember the core people in that group constantly
> make the argument that "portability" really means "availability". The
> very notion of a single cross platform source file is just beyond them.
If you look for the worst, you will surely find it.
> And alt.folklore.computers, sounds like it would be looking
> *backwards*, which would be of limited use -- getting this to work on
> Lattice C would not likely be in anyone's interest.
There are quite a few people that hang out there that have historic,
as well as current platform development experience. Some wouldn't
be able to help, but I think there is far less of an x86-centric
crowd there amongst those that are actively working than here.
YMMV.
> > [...] I wonder that it hasn't
> > happened already. I suspect that if the "libclc" effort had
> > not died out from the excessive pedantry it would have been a
> > logical outcome from that.
>
> Well these guys are a case in point. They were using "restrict" in
> their library even though C99 does *not* have widespread adoption.
No, it was a macro that could be enabled or disabled, IIRC it was
CLC_RESTRICT.
> Besides -- the idea that general libraries should force programmer
> restrictions on aliasing is a throwback to notions from the 1970s.
It seems there is almost no topic upon which you do not hold a very
strong opinion, 95% of it negative. :-)
> > I suspect it will be self-resolving, much as the comments from a
> > mainframe user's positive results (already on your website). Over
> > time, if it is widely adopted, this little debate will vanish
> > with little trace outside of the google archive.
>
> Uhhh ... no, I thought *you* were going to test it.
I am, in fact it is being used right now, but I am not going to
be trying to break it. I am already suitably convinced that it
is beneficial in almost all cases, and seems to have better
distribution properties than other "fast hashes" and more
complicated ones as well (crypto aside).
It is clear that, for whatever reason, CBF has a mission to throw
darts at SFH, so since is more highly motivated to break it than
I am, no doubt if something ugly pops out, he will let us all
know. :-)
If for some bizarre reason I run into a situation where I wish to
only hash 5 char strings, I don't think the minuscule performance
benefit of 31/33 will sway me into using more than one hash function.
> I mean CBF claims
> he wrote an I/O bound test even after I explicitely told him how to
> avoid that. (It makes you wonder if he has something to hide.)
It seems to me that he is focused on using hash functions in
situations with heavy file I/O, and puts far less weight on
their use in other situations, like an application that will
run for weeks, months, or years with a fairly static hash table.
> Has my bravado been completely lost on everyone?
I wish, but alas, no.
> I am *CHALLENGING* you, CBF, or anyone who wants to see just how
> good this function is. I've painted a target on my forehead.
> Nobody wants to take a shot?
I thought I had made it fairly clear that I was impressed with it
already. I wish I had access to a wider hardware base right now,
as that seems the only area such investigations in search of putting
a bullseye on your forehead are likely to find fruitful.
I could try it on a 16-bit embedded processor, but what would be
the point of that?
-- Randy Howard (2reply remove FOOBAR) "Making it hard to do stupid things often makes it hard to do smart ones too." -- Andrew Koenig
- Next message: james: "From buffer to Bitmap"
- Previous message: jasonbwork_at_hotmail.com: "Re: Does US Patent 863 enable Web O/S?"
- In reply to: websnarf_at_gmail.com: "Re: Maximum String size in Java?"
- Next in thread: CBFalconer: "Re: Maximum String size in Java?"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Relevant Pages
|
|
