Hi Ted,
I want to basically analyse the cost functions of the MapReduce
framework in Hadoop. That would include a good understanding of the
byte code execution costs which comes with Mappers and Reducers. I
know it might change for different MRs. So I am thinking of taking
WordCount and analysing it in-depth. The intention is trying to
optimize / tweak MapReduce for different workloads and commodity
resources.
It will be great if someone can provide some links to work already
done. Or help me with some framework which enables bytecode level
analysis ( I guess Eclipse could be a good option. But never tried it
).
Thanks,
Matthew John
On Fri, Feb 18, 2011 at 2:54 AM, Ted Yu <[EMAIL PROTECTED]> wrote:
> Are you investigating alternative map-reduce framework ?
>
> Please read:
>
http://www.craighenderson.co.uk/mapreduce/>
> On Thu, Feb 17, 2011 at 9:45 AM, Matthew John <[EMAIL PROTECTED]>wrote:
>
>> Hi Ted,
>>
>> Can u provide a link to the same ? Not able to find it :( .
>>
>>
>> On Thu, Feb 17, 2011 at 9:54 PM, Ted Yu <[EMAIL PROTECTED]> wrote:
>> > There was a discussion thread about why hadoop was developed in Java.
>> > Please read it.
>> >
>> > On Wed, Feb 16, 2011 at 10:39 PM, Matthew John
>> > <[EMAIL PROTECTED]>wrote:
>> >
>> >> hi Ted,
>> >> wanted to know if its development environment specific. Can u throw
>> >> some light on whether there is any inherent bytecode ececution cost ?
>> >> I am not using any specific development environment now (like Eclipse)
>> >> .
>> >>
>> >> Matthew
>> >>
>> >> On Thu, Feb 17, 2011 at 11:52 AM, Ted Yu <[EMAIL PROTECTED]> wrote:
>> >> > Is your target development environment using C++ ?
>> >> >
>> >> > On Wed, Feb 16, 2011 at 9:49 PM, Matthew John <
>> >> [EMAIL PROTECTED]>wrote:
>> >> >
>> >> >> Hi all,
>> >> >>
>> >> >> I wanted to know if the Map/Reduce (Mapper and Reducer) code incurs
>> >> >> any fixed cost of ByteCode execution. And how do the mappers (say of
>> >> >> WordCount MR) look like in detail (in bytecode detail) ?? Any good
>> >> >> pointers to this ?
>> >> >>
>> >> >> Thanks,
>> >> >> Matthew John
>> >> >>
>> >> >
>> >>
>> >
>>
>