31-Jul-2013 13:17, Walter Bright пишет:
> On 7/31/2013 1:49 AM, Dmitry Olshansky wrote:
>> Here key is 32 bits. Surely 2 strings can hash to the exact same 32
>> bit value.
>
> No, they cannot. The "hash value" is a pointer to the string. The
> strings are already inserted into another hash table,

The StringTable ? Then I have to look somewhere else entirely.

> so all strings
> that are the same are combined. Therefore, all unique strings "hash" to
> unique values.

Now that sets things straight ... if they ain't hashes then it isn't a hash table in the general sense :)

At least that means that contrary to my naive guess calcHash has no effect whatsoever on the distribution of keys in this AA. The "real hash function" could be rather biased. I've got to dig a bit deeper into the code then.

>
>> This resolves only slot collision. It doesn't resolve full hash
>> collision.
>
> If it was broken the compiler wouldn't work at all :-)

I had a feeling that it can't be that bad :)

-- 
Dmitry Olshansky

31-Jul-2013 19:04, Dmitry Olshansky пишет:
> 31-Jul-2013 13:17, Walter Bright пишет:
>> On 7/31/2013 1:49 AM, Dmitry Olshansky wrote:
[snip]
>> so all strings
>> that are the same are combined. Therefore, all unique strings "hash" to
>> unique values.
>
> Now that sets things straight ... if they ain't hashes then it isn't a
> hash table in the general sense :)
>
> At least that means that contrary to my naive guess calcHash has no
> effect whatsoever on the distribution of keys in this AA. The "real hash
> function" could be rather biased.

Ouch... to boot it's always aligned by word size, so
key % sizeof(size_t) == 0
...
rendering lower 2-3 bits useless, that would make straight slice lower bits approach rather weak :)

 I've got to dig a bit deeper into the
> code then.



-- 
Dmitry Olshansky

On 7/30/13 2:48 PM, Bill Baxter wrote:
> On Tue, Jul 30, 2013 at 12:05 PM, Andrei Alexandrescu
> <SeeWebsiteForEmail@erdani.org <mailto:SeeWebsiteForEmail@erdani.org>>
> wrote:
>
>     On 7/30/13 11:13 AM, Walter Bright wrote:
>
>         On 7/30/2013 2:59 AM, Leandro Lucarella wrote:
>
>             I just want to point out that being so much people getting
>             this wrong
>             (and even fighting to convince other people that the wrong
>             interpretation is right) might be an indication that the
>             message you
>             wanted to give in that blog is not extremely clear :)
>
>
>         It never occurred to me that anyone would have any difficulty
>         understanding the notion of "speed". After all, we deal with it
>         every
>         day when driving.
>
>
> Yeh sure.  Like "I made the trip to grandmother's house in 0.25
> trips/hour!.  That's 25% faster than last week when I only drove at 0.2
> trips/hour."
> I say that all the time.  ;-)
>
> --bb

One does say miles per hour or kilometers per hour, which is the same exact notion.

Andrei

On Wed, Jul 31, 2013 at 10:12 AM, Andrei Alexandrescu < SeeWebsiteForEmail@erdani.org> wrote:

> On 7/30/13 2:48 PM, Bill Baxter wrote:
>
>> On Tue, Jul 30, 2013 at 12:05 PM, Andrei Alexandrescu
>> <SeeWebsiteForEmail@erdani.org <mailto:SeeWebsiteForEmail@**erdani.org<SeeWebsiteForEmail@erdani.org>
>> >>
>> wrote:
>>
>>     On 7/30/13 11:13 AM, Walter Bright wrote:
>>
>>         On 7/30/2013 2:59 AM, Leandro Lucarella wrote:
>>
>>             I just want to point out that being so much people getting
>>             this wrong
>>             (and even fighting to convince other people that the wrong
>>             interpretation is right) might be an indication that the
>>             message you
>>             wanted to give in that blog is not extremely clear :)
>>
>>
>>         It never occurred to me that anyone would have any difficulty
>>         understanding the notion of "speed". After all, we deal with it
>>         every
>>         day when driving.
>>
>>
>> Yeh sure.  Like "I made the trip to grandmother's house in 0.25
>> trips/hour!.  That's 25% faster than last week when I only drove at 0.2
>> trips/hour."
>> I say that all the time.  ;-)
>>
>> --bb
>>
>
> One does say miles per hour or kilometers per hour, which is the same exact notion.
>
>
That's more analogous to something like MIPS than inverse program run time.

--bb

On 7/31/2013 8:26 AM, Dmitry Olshansky wrote:
> Ouch... to boot it's always aligned by word size, so
> key % sizeof(size_t) == 0
> ...
> rendering lower 2-3 bits useless, that would make straight slice lower bits
> approach rather weak :)

Yeah, I realized that, too. Gotta shift it right 3 or 4 bits.

On 7/31/2013 11:13 AM, Bill Baxter wrote:
> That's more analogous to something like MIPS than inverse program run time.

If you increase the speed 100%, then the elapsed time is cut by 50%.

This is a grammar school concept. It does not require an ivy league physics degree to understand. It is not obfuscated, confusing, or misleading. It doesn't rely on some rarely known "formal" definition of speed. I expect an audience of programmers to understand it without needing a sidebar.

We talk about speed of programs all the time, including compiler speed. I previously posted google searches you can try to verify it for yourself.

I.e. I'm being trolled here :-)

Are you serious that you can't fathom how it could be confusing to someone
than talking about differences in run times?
If you say something is faster than something else you want the two numbers
to be something you can relate to.  Like MPH.  Everyone has a clear concept
of what MPH is.  We use it every day.  So to say 25 MPH is 25% faster than
20 MPH is perfectly clear.  But nobody talks about program execution speed
in terms of programs per second.  So I think it's pretty clear why that
would be harder for people to grok than changes in car speeds or run times.

Anyway, congrats on the speed improvements!  When I was using D a lot, the compile times for heavily templated stuff were definitely starting to get to me.

--bb


On Wed, Jul 31, 2013 at 11:36 AM, Walter Bright <newshound2@digitalmars.com>wrote:

> On 7/31/2013 11:13 AM, Bill Baxter wrote:
>
>> That's more analogous to something like MIPS than inverse program run time.
>>
>
> If you increase the speed 100%, then the elapsed time is cut by 50%.
>
> This is a grammar school concept. It does not require an ivy league physics degree to understand. It is not obfuscated, confusing, or misleading. It doesn't rely on some rarely known "formal" definition of speed. I expect an audience of programmers to understand it without needing a sidebar.
>
> We talk about speed of programs all the time, including compiler speed. I previously posted google searches you can try to verify it for yourself.
>
> I.e. I'm being trolled here :-)
>
>

On Wednesday, 31 July 2013 at 21:40:45 UTC, Bill Baxter wrote:
> Are you serious that you can't fathom how it could be confusing to someone
> than talking about differences in run times?
> If you say something is faster than something else you want the two numbers
> to be something you can relate to.  Like MPH.  Everyone has a clear concept
> of what MPH is.  We use it every day.  So to say 25 MPH is 25% faster than
> 20 MPH is perfectly clear.  But nobody talks about program execution speed
> in terms of programs per second.  So I think it's pretty clear why that
> would be harder for people to grok than changes in car speeds or run times.

It's a quite impressively unbalanced education that provides understanding of memory allocation strategies, hashing and the performance pitfalls of integer division, but not something as basic as a speed.

On 7/31/2013 2:40 PM, Bill Baxter wrote:
> Are you serious that you can't fathom how it could be confusing to someone than
> talking about differences in run times?

Yes.

And no, I'm not talking about confusing to someone who lives in an undiscovered stone age tribe in the Amazon. I'm talking about computer programmers.


> If you say something is faster than something else you want the two numbers to
> be something you can relate to.  Like MPH.  Everyone has a clear concept of what
> MPH is.  We use it every day.  So to say 25 MPH is 25% faster than 20 MPH is
> perfectly clear.  But nobody talks about program execution speed in terms of
> programs per second.

Yes, they do, and certainly in "lines per second". Google it and see for yourself. And as you well understand, from using the same program to compile, the number of lines cancels out when comparing speeds.

There is nothing mysterious or confusing about this. Seriously.


> So I think it's pretty clear why that would be harder for
> people to grok than changes in car speeds or run times.

To be blunt, Baloney!


> Anyway, congrats on the speed improvements!  When I was using D a lot, the
> compile times for heavily templated stuff were definitely starting to get to me.

Thanks!

On 7/31/2013 3:58 PM, John Colvin wrote:
> It's a quite impressively unbalanced education that provides understanding of
> memory allocation strategies, hashing and the performance pitfalls of integer
> division, but not something as basic as a speed.

Have you ever seen those cards that some "electrical engineers" carry around, with the following equations on them:

    V = I * R
    R = V / I
    I = V / R

?

I found it: https://docs.google.com/drawings/d/1StlhTYjiUEljnfVtFjP1BXLbixO30DIkbw-DpaYJoA0/edit?hl=en&pli=1

Unbelievable. The author of it writes:

"I'm going to explain to you how to use this cheat sheet in case you've never seen this before."

http://blog.ricardoarturocabral.com/2010/07/electronic-electrical-cheat-sheets.html

Makes you want to cry.