mxnet-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Marco de Abreu <marco.g.ab...@googlemail.com>
Subject Re: Using parts of code from library under PyTorch organization
Date Sat, 19 May 2018 00:47:03 GMT
By the way. In general, I'd prefer to have a solution in C++ as part of our
Backend, as this would allow us to share this information with all frontend
APIs. Tobias is currently working on a PR which does exactly the same, but
for GPUs.

Marco de Abreu <marco.g.abreu@googlemail.com> schrieb am Sa., 19. Mai 2018,
02:45:

> I would have to check the license, but I assume it's under Apache. In that
> case, it should be enough to copy the file and keep the original license
> header. Additionally, you have to document any changes you made and where
> you got it from. You can do this in the header, below the license.
>
> In any case, check the NOTICE of the project and see if they contain any
> special instructions.
>
> -Marco
>
> Anirudh <anirudh2290@gmail.com> schrieb am Sa., 19. Mai 2018, 00:27:
>
>> Hi Alex,
>>
>> I am no expert but adding the license and the copyright to the header of
>> the file should be enough.
>> Can someone who has experience with this confirm ?
>>
>> Anirudh
>>
>> On Fri, May 18, 2018 at 10:55 AM, Alex Zai <azai91@gmail.com> wrote:
>>
>> > For this issue (https://github.com/apache/incubator-mxnet/issues/10836
>> ),
>> > we
>> > need to determine the number of physical cores for each platform.
>> Currently
>> > we assume each platform supports HyperThreading and just fetch the
>> number
>> > of logical cores and divide by 2. However, in cases where the machine
>> does
>> > not support HTT, we underutilize the CPUs. Per the issue’s thread, the
>> > PyTorch organization has a library that does just this (
>> > https://github.com/pytorch/cpuinfo). The library is a bit heavy and we
>> > only
>> > need a small portion of the code. Does anyone know if there is an issue
>> > with just using a subset of the code?
>> >
>> >
>> >
>> > Alex
>> >
>>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message