Re: Role of D in Python and performance computing [was post on using go 1.5 and GC latency]
On Tuesday, 25 August 2015 at 05:12:55 UTC, Laeeth Isharc wrote: What's the best reference to learn more about PGAS? I've seen a few presentations, https://www.osc.edu/sites/osc.edu/files/staff_files/dhudak/pgas-tutorial.pdf http://www.inf.unideb.hu/~fazekasg/english/New_Programming_Paradims/PGAS.pdf papers, http://www.cs.rochester.edu/u/cding/amp/papers/full/The%20Asynchronous%20Partitioned%20Global%20Address%20Space%20Model.pdf and a stackoverflow question http://stackoverflow.com/questions/31992761/what-are-the-differences-between-tls-and-pgas Not sure what is the best one.
Re: Role of D in Python and performance computing [was post on using go 1.5 and GC latency]
More info on the Go 1.5 concurrent GC, a classic one: https://blog.golang.org/go15gc
Re: Role of D in Python and performance computing [was post on using go 1.5 and GC latency]
On Tuesday, 25 August 2015 at 07:18:24 UTC, Ola Fosheim Grøstad wrote: On Tuesday, 25 August 2015 at 05:09:56 UTC, Laeeth Isharc wrote: On Monday, 24 August 2015 at 21:57:41 UTC, rsw0x wrote: [...] Horses for courses ? Eg for Andy Smith's problem of processing trade information of tens of gigs where Python was choking, I guess nobody in their right mind would use Rust. I don't think there is much difference between C, D or Rust in terms of computing. The core semantics are similar. With Rust you have the additional option of linear type checking. But Rust programmers of course want to use idiomatic linear typing as much as possible and that makes designing graph-like structures a challenge. An option implies you can turn it off, has this changed since the last time I used Rust?(admittedly, a while back) Memory safety doesn't seem like it's the top priority for scientific computing as much as fast turnarouds and performance... in my opinion, anyways.
Re: Role of D in Python and performance computing [was post on using go 1.5 and GC latency]
On Tuesday, 25 August 2015 at 05:09:56 UTC, Laeeth Isharc wrote: On Monday, 24 August 2015 at 21:57:41 UTC, rsw0x wrote: On Monday, 24 August 2015 at 21:20:39 UTC, Russel Winder wrote: For Python and native code, D is a great fit, perhaps more so that Rust, except that Rust is getting more mind share, probably because it is new. I'm of the opinion that Rust's popularity will quickly die when people realize it's a pain to use. Horses for courses ? Eg for Andy Smith's problem of processing trade information of tens of gigs where Python was choking, I guess nobody in their right mind would use Rust. I don't think there is much difference between C, D or Rust in terms of computing. The core semantics are similar. With Rust you have the additional option of linear type checking. But Rust programmers of course want to use idiomatic linear typing as much as possible and that makes designing graph-like structures a challenge.
Re: Role of D in Python and performance computing [was post on using go 1.5 and GC latency]
On Tuesday, 25 August 2015 at 07:21:13 UTC, rsw0x wrote: An option implies you can turn it off, has this changed since the last time I used Rust?(admittedly, a while back) Rust supports other reference types, so you decide by design whether you want to use linear typing or not?
Re: Role of D in Python and performance computing [was post on using go 1.5 and GC latency]
On Monday, 24 August 2015 at 21:20:39 UTC, Russel Winder wrote: The issue here for me is that Chapel provides something that C, C++, D, Rust, Numba, NumPy, cannot – Partitioned Global Address Space (PGAS) programming. This directly attacks the multicore/multiprocessor/cluster side of computing, but not the GPGPU side, at least not per se. Yes, I agree that highly parallel batch programming requires a specialized approach. Though for most applications I think something like Pony will fit better. But they have to figure out how to do migration and load balancing I suppose. Javascript is moving towards programming using futures/promises, it is already built into Chrome. While that isn't actors per se, I think the computing objects approach will be more familiar for programmers over time and that will open up for actor-based languages too. Maybe.
Re: Role of D in Python and performance computing [was post on using go 1.5 and GC latency]
On Monday, 24 August 2015 at 21:20:39 UTC, Russel Winder wrote: For Python and native code, D is a great fit, perhaps more so that Rust, except that Rust is getting more mind share, probably because it is new. I'm of the opinion that Rust's popularity will quickly die when people realize it's a pain to use.
Re: Role of D in Python and performance computing [was post on using go 1.5 and GC latency]
On Sun, 2015-08-23 at 19:42 +, via Digitalmars-d-learn wrote: […] Yes, of course it is, but given it's typical use context I find it odd that they didn't go more towards higher level constructs. For me Go displaces Python where more speed is required, though I wish it was more pythonic… (neither C++, Rust or D are really eligible) I wondered about the Go/Python issue last year, and even did a London Python Group session on the topic. Clearly organizations like Canonical are displacing Python with Go for some of their projects, almost certainly rightly so: as you say Go has duck typing yet is strongly statically types, where Python (via PEP 484 and MyPy) is only now getting type hinting. However I think we will see that Go and Python are actually getting traction in different spaces and so are not competing as much as many would have us believe. For Python and native code, D is a great fit, perhaps more so that Rust, except that Rust is getting more mind share, probably because it is new. It would be good to get rid of C and C++ as the languages of Python extensions. Of course systems like Numba change the Python performance game, which undermines D's potential in the Python-verse, as it does C and C++. Currently I am investigating Python/Numba/Chapel as the way of doing performance computing. Anyone who just uses Python/NumPy/SciPy is probably not doing performance computing, NumPy is so slow (*). The issue here for me is that Chapel provides something that C, C++, D, Rust, Numba, NumPy, cannot – Partitioned Global Address Space (PGAS) programming. This directly attacks the multicore/multiprocessor/cluster side of computing, but not the GPGPU side, at least not per se. (*) Which comment allows this piece to be attacked as I have been attacking similar comments elsewhere ;-) -- Russel. = Dr Russel Winder t: +44 20 7585 2200 voip: sip:russel.win...@ekiga.net 41 Buckmaster Roadm: +44 7770 465 077 xmpp: rus...@winder.org.uk London SW11 1EN, UK w: www.russel.org.uk skype: russel_winder signature.asc Description: This is a digitally signed message part
Re: Role of D in Python and performance computing [was post on using go 1.5 and GC latency]
. Of course systems like Numba change the Python performance game, which undermines D's potential in the Python-verse, as it does C and C++. Currently I am investigating Python/Numba/Chapel as the way of doing performance computing. Anyone who just uses Python/NumPy/SciPy is probably not doing performance computing, NumPy is so slow (*). Can you elaborate ? The issue here for me is that Chapel provides something that C, C++, D, Rust, Numba, NumPy, cannot – Partitioned Global Address Space (PGAS) programming. This directly attacks the multicore/multiprocessor/cluster side of computing, but not the GPGPU side, at least not per se. What's the best reference to learn more about PGAS? Thanks. Laeeth.
Re: Role of D in Python and performance computing [was post on using go 1.5 and GC latency]
On Monday, 24 August 2015 at 21:57:41 UTC, rsw0x wrote: On Monday, 24 August 2015 at 21:20:39 UTC, Russel Winder wrote: For Python and native code, D is a great fit, perhaps more so that Rust, except that Rust is getting more mind share, probably because it is new. I'm of the opinion that Rust's popularity will quickly die when people realize it's a pain to use. Horses for courses ? Eg for Andy Smith's problem of processing trade information of tens of gigs where Python was choking, I guess nobody in their right mind would use Rust. But maybe D isn't quite yet what you would choose for a highly complex mass consumer product like a browser? Btw had a nice little test the other day. I haven't yet done much with intraday data - I only just lately took the FX data I had sitting around and pulled it into my data server.Someone asked me a question about something in that domain - would have taken them a few weeks at least to begin to get an answer. I have never been the fastest programmer, but took a couple hundred lines and three hours to write the analysis from scratch, and half the time was figuring out how to get it to display nicely in Mathgl. Took less than 10 minutes to run on my home machine using debug Dmd and pulling data from my server over the Internet with a spinning drive (so probably could get it down to a minute or two). I know it takes a big Wall Street firm an hour to run the same task. That gets in the way of using rapid iteration to explore the data.
