[subject change from:
`What's your favorite language and why? (LINUX)'
to:
`Azul vs. Dmitriy's hash-map...'
`comp.programming.thread' added to discussion.]
"Jon Harrop" <jon@[EMAIL PROTECTED]
> wrote in message
news:Esydnf1wH6eH-XLVnZ2dneKdnZydnZ2d@[EMAIL PROTECTED]
> Jon Harrop wrote:
>> Chris M. Thomasson wrote:
>>> "toby" <toby@[EMAIL PROTECTED]
> wrote in message
>>>
news:7964726b-c7c6-4c3a-b33e-6937b21d3b6d@[EMAIL PROTECTED]
>>>> On Oct 2, 12:52 am, RyanMcCoskrie <ryan.mccosk...@[EMAIL PROTECTED]
> wrote:
>>>>> Personally I code mostly in C++ because it can be scaled more easily
>>>>> than interpreted langs
>>>>
>>>> Is that so?
>>>>
>>>> Pardon my scepticism, but when was the last time you had an app that
>>>> wouldn't "scale" onaccounta being written in something other than
C/C+
>>>> +?
>>>
>>> Please try to create the following algorithm in a lang other than
C/C++:
>>>
>>>
>>
>
http://groups.google.com/group/comp.programming.threads/browse_frm/thread/396e89bef0921786
>>> ...
>>> The _low-level_ nature of C/C++ has its advantages indeed. You can do
>>> low-level optimizations that just might not be all that easy, or
>>> possible, in HLL. Well, so be it.
>>
>> The optimizations you are referring to require memory barriers and
atomic
>> operations (primarily CAS) to replace locks, neither of which are
>> provided
>> by C or C++ (they do not even have defined memory models) but both of
>> which are provided by both Java and .NET.
>
> Here is a lock-free wait-free hash table implementation written in Java
> that
> scales to hundreds of cores:
>
> http://www.azulsystems.com/events/stanford_2007/2007_LockFreeHash.pdf
IIRC, there can be a problem with that algorithm during when it grows. The
memory usage will climb uncontrollably in certain narrow scenarios. I
watched a video on the subject. I will look for the link and post it.
Somebody in the audience mentioned it, and the author of the algorithm
said
basically, ahh don't worry about that, it can happen, but it won't...
> Note that features not even provided by C or C++ are critical to its
> working.
Sorry, buy I think that Dmitriy V'jukov's clever algorihtm is simply much,
much better:
http://software.intel.com/en-us/forums/intel-threading-building-blocks/topic/60494
It does not rely on full-blown heavy GC. Its HEAVILY optimized for l2
cache
performance. I don't quite see how the Java version can compare. Also,
Dmitriy's algorithm amortizes the number of atomic ops and memory barriers
needed. His proxy garbage collector is clever indeed. I urge you to check
out this hash-map and see what you come up with.
|
