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/
More info on the Go 1.5 concurrent GC, a classic one:
https://blog.golang.org/go15gc
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?
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 g
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
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,
. 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
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 Rus
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
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 pyt
On Sunday, 23 August 2015 at 12:49:35 UTC, Russel Winder wrote:
You are mixing too many factors here. "General purpose" has
nothing to do with performance, it is to do with can the
language describe most if not all forms of computation. Go is a
general purpose programming language just like C,
On Saturday, 22 August 2015 at 06:54:43 UTC, Ola Fosheim Grøstad
wrote:
On Saturday, 22 August 2015 at 06:48:48 UTC, Russel Winder
wrote:
But one that Google are entirely happy to fully fund.
Yes, they have made Go fully supported on Google Cloud now, so
I think it is safe to say that Google
On Sun, 2015-08-23 at 11:26 +, rsw0x via Digitalmars-d-learn wrote:
> […]
>
> https://groups.google.com/forum/#!msg/golang
> -dev/pIuOcqAlvKU/C0wooVzXLZwJ
> 25-50% performance decrease across the board in 1.4 with the
> addition of write barriers, to an already slow language.
Garbage collect
On Sunday, 23 August 2015 at 11:06:20 UTC, Russel Winder wrote:
On Sat, 2015-08-22 at 09:27 +, rsw0x via
Digitalmars-d-learn wrote:
[…]
The performance decrease has been there since 1.4 and there is
no way to remove it - write barriers are the cost you pay for
concurrent collection. Go wa
On Sat, 2015-08-22 at 09:27 +, rsw0x via Digitalmars-d-learn wrote:
> […]
>
> The performance decrease has been there since 1.4 and there is no
> way to remove it - write barriers are the cost you pay for
> concurrent collection. Go was already much slower than other
> compiled languages, n
On Sat, 2015-08-22 at 11:06 +, Laeeth Isharc via Digitalmars-d
-learn wrote:
> […]
>
> Builds in Go 1.5 will be slower by a factor of about two. The
> automatic translation of the compiler and linker from C to Go
> resulted in unidiomatic Go code that performs poorly compared to
> well-writ
On Saturday, 22 August 2015 at 12:48:31 UTC, rsw0x wrote:
The problem with D's GC is that there's no scaffolding there
for it, so you can't really improve it.
At best you could make the collector parallel.
If I had the runtime hooks and language guarantees I needed I'd
begin work on a per-thre
On Saturday, 22 August 2015 at 10:47:55 UTC, Laeeth Isharc wrote:
On Saturday, 22 August 2015 at 09:16:32 UTC, Russel Winder
wrote:
[...]
I didn't mean to start again the whole GC and Go vs D thing.
Just that one ought to know the lay of the land as it develops.
Out of curiosity, how much
On Saturday, 22 August 2015 at 07:02:40 UTC, Russel Winder wrote:
I think Go 2 is a long way off, and even then generics will not
be part of the plan.
I agree that Go from Google will stay close to the ideals of the
creators. I think it would be difficult get beyond that for
social reasons.
On Saturday, 22 August 2015 at 10:47:55 UTC, Laeeth Isharc wrote:
Out of curiosity, how much funding is required to develop the
more straightforward kind of GCs ?
A classical GC like D has is very straightforward. It is been
used since the 60s, I even have a paper from 1974 or so
describing t
On Saturday, 22 August 2015 at 07:30:23 UTC, rsw0x wrote:
On Saturday, 22 August 2015 at 06:48:48 UTC, Russel Winder
wrote:
On Fri, 2015-08-21 at 10:47 +, via Digitalmars-d-learn
wrote:
Yes, Go has sacrificed some compute performance in favour of
latency and convenience. They have also rele
On 8/22/2015 10:47 PM, Laeeth Isharc wrote:
On Saturday, 22 August 2015 at 09:16:32 UTC, Russel Winder wrote:
On Sat, 2015-08-22 at 07:30 +, rsw0x via Digitalmars-d-learn wrote:
[…]
because Go is not a general purpose language.
Not entirely true. Go is a general purpose language, it is a
On Saturday, 22 August 2015 at 09:16:32 UTC, Russel Winder wrote:
On Sat, 2015-08-22 at 07:30 +, rsw0x via
Digitalmars-d-learn wrote:
[…]
because Go is not a general purpose language.
Not entirely true. Go is a general purpose language, it is a
successor to C as envisioned by Rob Pike, R
On Saturday, 22 August 2015 at 09:16:32 UTC, Russel Winder wrote:
On Sat, 2015-08-22 at 07:30 +, rsw0x via
Digitalmars-d-learn wrote:
[...]
Not entirely true. Go is a general purpose language, it is a
successor to C as envisioned by Rob Pike, Russ Cox, and others
(I am not sure how much
On Sat, 2015-08-22 at 07:30 +, rsw0x via Digitalmars-d-learn wrote:
> […]
>
> because Go is not a general purpose language.
Not entirely true. Go is a general purpose language, it is a successor
to C as envisioned by Rob Pike, Russ Cox, and others (I am not sure how
much input Brian Kernighan
On Saturday, 22 August 2015 at 06:48:48 UTC, Russel Winder wrote:
On Fri, 2015-08-21 at 10:47 +, via Digitalmars-d-learn
wrote:
Yes, Go has sacrificed some compute performance in favour of
latency and convenience. They have also released GC
improvement plans for 1.6:
https://docs.google.c
On Sat, 2015-08-22 at 06:54 +, via Digitalmars-d-learn wrote:
> On Saturday, 22 August 2015 at 06:48:48 UTC, Russel Winder wrote:
> > But one that Google are entirely happy to fully fund.
>
> Yes, they have made Go fully supported on Google Cloud now, so I
> think it is safe to say that Googl
On Saturday, 22 August 2015 at 06:48:48 UTC, Russel Winder wrote:
But one that Google are entirely happy to fully fund.
Yes, they have made Go fully supported on Google Cloud now, so I
think it is safe to say that Google management is backing Go
fully.
I'm kinda hoping for Go++...
On Fri, 2015-08-21 at 10:47 +, via Digitalmars-d-learn wrote:
> Yes, Go has sacrificed some compute performance in favour of
> latency and convenience. They have also released GC improvement
> plans for 1.6:
>
> https://docs.google.com/document/d/1kBx98ulj5V5M9Zdeamy7v6ofZXX3yPziA
> f0V27A64
Yes, Go has sacrificed some compute performance in favour of
latency and convenience. They have also released GC improvement
plans for 1.6:
https://docs.google.com/document/d/1kBx98ulj5V5M9Zdeamy7v6ofZXX3yPziAf0V27A64Mo/edit
It is rather obvious that a building a good concurrent GC is a
time
https://medium.com/@robin.verlangen/billions-of-request-per-day-meet-go-1-5-362bfefa0911
We then started analyzing the behavior of our Go application. On
average the application spent ~ 2ms per request, which was great!
It gave us 98 milliseconds to spare for network overhead, SSL
handshake, D
31 matches
Mail list logo
