| 1 |
Hi Andrew,
|
| 2 |
|
| 3 |
Andrew Savchenko <bircoph@g.o> writes:
|
| 4 |
|
| 5 |
>> I’ll then start the most challenge part, porting and packaging |
| 6 |
>> Intel Tools. |
| 7 |
> |
| 8 |
> While Intel stuff may rightfully be a part of your project, I do not |
| 9 |
> recommend to focus on them too much, since this is a proprietary |
| 10 |
> software and GSoC is all about Free/Libre software. |
| 11 |
> |
| 12 |
>> I’m also interested to port Intel’s python distribution |
| 13 |
> |
| 14 |
> I've discussed this project with Intel devs on one of the |
| 15 |
> conferences. There is nothing special about it: it is a normal |
| 16 |
> Python linked with Intel libraries and with some math libs replaced |
| 17 |
> with more optimized free software solutions. So everyone can do the |
| 18 |
> same with Intel MKL without need to obtain Intel Python. They |
| 19 |
> created this project mostly due to marketing issues, since python |
| 20 |
> is a popular language and management want to establish Intel's |
| 21 |
> presence in this area. |
| 22 |
> |
| 23 |
> If you want to pursue this task, I recommend to build on FLOSS |
| 24 |
> solutions as described above, packaging Intel Python itself is |
| 25 |
> quite useless. |
| 26 |
|
| 27 |
+1
|
| 28 |
|
| 29 |
With a more rubost blas/lapack framework/eclass, an optimized
|
| 30 |
scipy/numpy linked with OpenBLAS or Intel MKL will be on par if not
|
| 31 |
overtake the Intel python binaries.
|
| 32 |
|
| 33 |
>> I’d like if it is possible to bring into the sci-gentoo overlay |
| 34 |
>> an “official” matlab ebuild |
| 35 |
> |
| 36 |
> Devoting a whole month to the proprietary piece of software is |
| 37 |
> questionable again. Devoting some time to improve |
| 38 |
> proprietary software packaging in Gentoo is OK, but devoting half of |
| 39 |
> your time for them is questionable at least. |
| 40 |
|
| 41 |
+1
|
| 42 |
|
| 43 |
I don't think a gigantic piece of proprietary software is very
|
| 44 |
interesting to us.
|
| 45 |
|
| 46 |
Benda |
Archives