Strategy for Traction

Russel Winder russel at winder.org.uk
Sun Feb 23 07:03:32 PST 2014


As some of you will know Python is big in bioinformatics, HEP, finance,
signal processing and many other computational areas. Originally (and
still to some extent) Python was (and still is) used for coordination of
Fortran and C++ computations, and for rendering the visualizations.
Mathematica, R, Julia, Maple, etc. also have roles in this game.

Those in the Python side of the game disliked C and C++ co much they
created abstractions, ending up with NumPy, Cython, ShedSkin, Numba,
SciPy and also PyPy to replace CPython. All attempts to write Python and
gain native code speed of computation. C is definitely not the right
tool for this. C++14 however may give a new impetus especially using
Boost.Python. The question is whether the anti-C/C++ mindset, pro
NumPy/Cython midset is now so embedded there is no other alternative.

It would have been really nice to have had a D option since writing D
makes writing C++ look like a labour of Sisyphus.

I think it might be a very good idea to ensure that D is a really good
tool for native code sub-systems within a Python system. Basically to
try and remove the NumPy component, and also the Cython, ShedSkin and
Numba ones.

As we know from recent little experiments and email list threads, D can
create C linkage shared libraries which is exactly what is needed for
CPython usage (as PyPy sort of), and there is PyD for create CPython
extensions. With a little tidying via "annotations" all the runtime
initialization can be handled for C linkage shared libraries, PyD
already handles all that for extensions.

In a sense all that is needed is some good examples and thence
marketing.

However I think std.parallelism needs some work: the data parallelism
offered is not yet low enough in overhead to really offer argument-free
competition to NumPy. The goal needs to be for D + std.parallelism to be
as fast of execution as C++ + TBB. Currently it is far from that.

Also we need good ARM support so we can run D on RaspberryPis. OK so the
GPU of a RaspberryPi is great and the CPU dreadful, but they are the
platform of fashion just now. Python is the language of choice, except
for those using Java or C and C++.

So I suggest two directions to go:

1. Create a NumPy replacement.

2. Ensure D can be used on Raspberry Pis.

If there is interest and resource for this then last year was the time
to implement, so time is of the essence ;-)
 
-- 
Russel.
=============================================================================
Dr Russel Winder      t: +44 20 7585 2200   voip: sip:russel.winder at ekiga.net
41 Buckmaster Road    m: +44 7770 465 077   xmpp: russel at winder.org.uk
London SW11 1EN, UK   w: www.russel.org.uk  skype: russel_winder



More information about the Digitalmars-d mailing list