Re: post on using go 1.5 and GC latency
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 Google management is backing Go > fully. > > I'm kinda hoping for Go++... I think Go 2 is a long way off, and even then generics will not be part of the plan. Go UK 2015 was held yesterday. It was less a conference and more a Google "rah rah" event. It was though very clear that Google are looking for new idioms and practices to come from users other than Google, rather than what has happened to date, which is the Go central team dictating everything to everyone else. -- 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: post on using go 1.5 and GC latency
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.com/document/d/1kBx98ulj5V5M9Zdeamy7v6ofZXX3yPziA f0V27A64Mo/edit It is rather obvious that a building a good concurrent GC is a time consuming effort. But one that Google are entirely happy to fully fund. because Go is not a general purpose language. A concurrent GC for D would kill D. Go programs saw a 25-50% performance decrease across the board for the lower latencies. D could make some very minor changes and be capable of a per-thread GC with none of these performance drawbacks, but nobody seems very interested in it.
Re: post on using go 1.5 and GC latency
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 has had). However, because of current traction in Web servers and general networking, it is clear that that is where the bulk of the libraries are. Canonical also use it for Qt UI applications. I am not sure of Google real intent for Go on Android, but there is one. > A concurrent GC for D would kill D. Go programs saw a 25-50% > performance decrease across the board for the lower latencies. They also saw a 100% increase in performance when it was rewritten, and a 20% fall with this latest rewrite. I anticipate great improvement for the 1.6 rewrite. I am surprised they are retaining having only a single garbage collector: different usages generally require different garbage collection strategies. Having said that Java is moving from having four collectors, to having one, it is going to be interesting to see if G1 meets the needs of all JVM usages. > D could make some very minor changes and be capable of a > per-thread GC with none of these performance drawbacks, but > nobody seems very interested in it. Until some organization properly funds a suite of garbage collectors for different performance targets, you have what there is. -- 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: post on using go 1.5 and GC latency
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 input Brian Kernighan has had). However, because of current traction in Web servers and general networking, it is clear that that is where the bulk of the libraries are. Canonical also use it for Qt UI applications. I am not sure of Google real intent for Go on Android, but there is one. [...] They also saw a 100% increase in performance when it was rewritten, and a 20% fall with this latest rewrite. I anticipate great improvement for the 1.6 rewrite. I am surprised they are retaining having only a single garbage collector: different usages generally require different garbage collection strategies. Having said that Java is moving from having four collectors, to having one, it is going to be interesting to see if G1 meets the needs of all JVM usages. [...] Until some organization properly funds a suite of garbage collectors for different performance targets, you have what there is. 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, now it probably struggles to keep up with mono.
Re: Appender at CTFE?
On Friday, 21 August 2015 at 23:51:16 UTC, cym13 wrote: On Friday, 21 August 2015 at 22:39:29 UTC, Nick Sabalausky wrote: Not at a pc, so can't test right now, but does Appender work at compile time? If not, does ~= still blow up CTFE memory usage like it used to? Any other best practice / trick for building strings in CTFE? I did two experiments: [...] Each make use of CTFE but the f (appender) variant blew my RAM (old computer) Excepted any error from my part, shouldn't you call '.reserve' in order to make the appender efficient ?
Re: post on using go 1.5 and GC latency
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, Russ Cox, and others (I am not sure how much input Brian Kernighan has had). However, because of current traction in Web servers and general networking, it is clear that that is where the bulk of the libraries are. Canonical also use it for Qt UI applications. I am not sure of Google real intent for Go on Android, but there is one. A concurrent GC for D would kill D. Go programs saw a 25-50% performance decrease across the board for the lower latencies. They also saw a 100% increase in performance when it was rewritten, and a 20% fall with this latest rewrite. I anticipate great improvement for the 1.6 rewrite. I am surprised they are retaining having only a single garbage collector: different usages generally require different garbage collection strategies. Having said that Java is moving from having four collectors, to having one, it is going to be interesting to see if G1 meets the needs of all JVM usages. D could make some very minor changes and be capable of a per-thread GC with none of these performance drawbacks, but nobody seems very interested in it. Until some organization properly funds a suite of garbage collectors for different performance targets, you have what there is. 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 funding is required to develop the more straightforward kind of GCs ? Or to take what's been done and make it possible for others to use? It needn't be a single organisation I would think if there are many that would benefit and one doesn't get bogged down in a mentality of people worrying about possibly spurious free rider problems. Since the D Foundation seems under way, it seems worth asking the question first and thinking about goals without worrying for now about what seems realistic.
Re: post on using go 1.5 and GC latency
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 successor to C as envisioned by Rob Pike, Russ Cox, and others (I am not sure how much input Brian Kernighan has had). However, because of current traction in Web servers and general networking, it is clear that that is where the bulk of the libraries are. Canonical also use it for Qt UI applications. I am not sure of Google real intent for Go on Android, but there is one. A concurrent GC for D would kill D. Go programs saw a 25-50% performance decrease across the board for the lower latencies. They also saw a 100% increase in performance when it was rewritten, and a 20% fall with this latest rewrite. I anticipate great improvement for the 1.6 rewrite. I am surprised they are retaining having only a single garbage collector: different usages generally require different garbage collection strategies. Having said that Java is moving from having four collectors, to having one, it is going to be interesting to see if G1 meets the needs of all JVM usages. D could make some very minor changes and be capable of a per-thread GC with none of these performance drawbacks, but nobody seems very interested in it. Until some organization properly funds a suite of garbage collectors for different performance targets, you have what there is. 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 funding is required to develop the more straightforward kind of GCs ? Or to take what's been done and make it possible for others to use? It needn't be a single organisation I would think if there are many that would benefit and one doesn't get bogged down in a mentality of people worrying about possibly spurious free rider problems. Since the D Foundation seems under way, it seems worth asking the question first and thinking about goals without worrying for now about what seems realistic. I believe the hardest part is finding somebody can and willing to work on it. For example I'm willing but I don't know how and there are people willing with a job and can do it. But cannot dedicated time because of money. Really it comes down to having a budget and if somebody says hey I'll do x, y and z features to pay them for their time as they do it. Even if they only do one small feature which takes a week.
Re: post on using go 1.5 and GC latency
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 released GC improvement plans for 1.6: https://docs.google.com/document/d/1kBx98ulj5V5M9Zdeamy7v6ofZXX3yPziA f0V27A64Mo/edit It is rather obvious that a building a good concurrent GC is a time consuming effort. But one that Google are entirely happy to fully fund. because Go is not a general purpose language. A concurrent GC for D would kill D. Go programs saw a 25-50% performance decrease across the board for the lower latencies. D could make some very minor changes and be capable of a per-thread GC with none of these performance drawbacks, but nobody seems very interested in it. This puts ddmd into context, bearing in mind an automated translation without won't I guess be much slower in LDC or GDC, and it's already a small difference: Release notes on go 1.5 via stack overflow. 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-written Go. Analysis tools and refactoring helped to improve the code, but much remains to be done. Further profiling and optimization will continue in Go 1.6 and future releases. For more details, see these slides and associated video.
Re: post on using go 1.5 and GC latency
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 the implementation used for Simula which is a precise stop-the world GC. Trivial to do. Or to take what's been done and make it possible for others to use? Therein is the trouble, a more advanced GC is intrinsically linked to the language semantics and has to be tuned to the hardware. Expect at least 2 years of work for anything approaching state-of-the-art. In the web server space you wait a lot for I/O so raw performance is not key for Go's success. Stability, memory usage and low latency is more important.
Re: post on using go 1.5 and GC latency
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. But I think the mechanics Go provides are generic enough that someone could build a transpiler providing more high level convenience. I am thinking along the lines of a convenient language that can compile to both Go and Javascript... I'm tempted to have a go at it. ;) Go UK 2015 was held yesterday. It was less a conference and more a Google "rah rah" event. It was though very clear that Google are looking for new idioms and practices to come from users other than Google, rather than what has happened to date, which is the Go central team dictating everything to everyone else. Go UK sounds interesting. I wonder if they will have one in Oslo? Probably not :-/.
Re: post on using go 1.5 and GC latency
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 funding is required to develop the more straightforward kind of GCs ? Or to take what's been done and make it possible for others to use? It needn't be a single organisation I would think if there are many that would benefit and one doesn't get bogged down in a mentality of people worrying about possibly spurious free rider problems. Since the D Foundation seems under way, it seems worth asking the question first and thinking about goals without worrying for now about what seems realistic. 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-thread GC immediately.
Template Parameters in Struct Member Functions
I'm having difficulty understanding how templates operate as
function parameters.
Say I have this:
struct ArrayTest {
void arrayTest(T) (T arrayT) {
writeln(arrayT);
}
}
unittest {
ArrayTest test;
float farray[] = [
0.5f, 0.5f, 0.0f,
0.5f, -0.5f, 0.0f,
-0.5f, -0.5f, 0.0f,
-0.5f, 0.5f, 0.0f
];
test.arrayTest(farray);
}
Everything works peachy as expected. But as soon as I add another
parameter to the arrayTest function like so (and changing the
unit test to match):
void arrayTest(T, int passing) (T arrayT) { ... }
I get 'cannot deduce function from argument types' errors.
Specifically stating the type of the function doesn't seem to
help:
test.arrayTest(float [])(farray, 1);
There must be a way to mix template and non-template parameters,
right? What am I missing here?
In addition, as I understand it, one can restrict the type of
parameter a template can use. So if I only wanted arrays as the
function name indicates, I should be able to do this:
void arrayTest(T : T[]) (T arrayT) { ... }
But that also doesn't seem to work.
Re: Template Parameters in Struct Member Functions
On Saturday, 22 August 2015 at 16:49:26 UTC, DarthCthulhu wrote:
I'm having difficulty understanding how templates operate as
function parameters.
Say I have this:
struct ArrayTest {
void arrayTest(T) (T arrayT) {
writeln(arrayT);
}
}
unittest {
ArrayTest test;
float farray[] = [
0.5f, 0.5f, 0.0f,
0.5f, -0.5f, 0.0f,
-0.5f, -0.5f, 0.0f,
-0.5f, 0.5f, 0.0f
];
test.arrayTest(farray);
}
Everything works peachy as expected. But as soon as I add
another parameter to the arrayTest function like so (and
changing the unit test to match):
void arrayTest(T, int passing) (T arrayT) { ... }
I get 'cannot deduce function from argument types' errors.
Specifically stating the type of the function doesn't seem to
help:
test.arrayTest(float [])(farray, 1);
test.arrayTest!(float, 1)(farray);
Re: Template Parameters in Struct Member Functions
On Saturday, 22 August 2015 at 17:08:36 UTC, Mike Parker wrote:
void arrayTest(T, int passing) (T arrayT) { ... }
I get 'cannot deduce function from argument types' errors.
Specifically stating the type of the function doesn't seem to
help:
test.arrayTest(float [])(farray, 1);
test.arrayTest!(float, 1)(farray);
Sorry, that should be:
test.arrayTest!(float[], 1)(farray);
In your template declaration, you have declared two template
parameters, T and passing, and one function parameter, arrayT. It
is equivalent to:
template arrayTest(T, int passing) {
void arrayTest(T arrayT) {...}
}
To call the function, you have to explicitly instantiate the
template with the instantiation operator (which is !) and give it
two arguments as template parameters in the first pair of
parentheses, then you have to give it one function argument in
the second pair of parentheses. The template parameters are
compile-time arguments, the function parameter is runtime.
With this form:
void arrayTest(T)(T arrayT) {...}
There is no need for the explicit instantiation. The compiler is
able to deduce what T should be since it has all the information
it needs, so you can call it like:
test.arrayTest(foo);
(De)Serializing interfaces
I think interfaces are very powerful and I heavily use them. The
only problem I have with them is that serializing/deserializing
them to XML or JSON doesn't seem to work. So far I got to try
Orange and painlessjson. Using Orange all I got was a lot of
compiler errors. Painlessjson did compile normally but just
ignores all interface class members.
This is the code I tried (I apologize for not formatting it, I
have no idea how to do that):
interface MyInterface {
int GetA();
}
class Foo: MyInterface {
int a;
int GetA() { return a; }
}
// maybe add a class Bar later which implements the same interface
class Foobar {
MyInterface myBar = new Foo();
}
void main()
{
// serialize it
}
Re: (De)Serializing interfaces
On 8/23/2015 7:14 AM, nims wrote:
I think interfaces are very powerful and I heavily use them. The only
problem I have with them is that serializing/deserializing them to XML
or JSON doesn't seem to work. So far I got to try Orange and
painlessjson. Using Orange all I got was a lot of compiler errors.
Painlessjson did compile normally but just ignores all interface class
members.
This is the code I tried (I apologize for not formatting it, I have no
idea how to do that):
interface MyInterface {
int GetA();
}
class Foo: MyInterface {
int a;
int GetA() { return a; }
}
// maybe add a class Bar later which implements the same interface
class Foobar {
MyInterface myBar = new Foo();
}
void main()
{
// serialize it
}
Based upon the name for 'GetA' I suspect you are comming from C#.
So let me put this into that context.
For C# ISerialize[0] interface is used to denote a class that can be
serialized.
Most notably is that ISerialize has a method called GetObjectData which
populates a data table SerializationInfo with enough information to
perform deserialization.
There is also a special constructor applied to any serializable class so
it can manually recreated. This is not possible to be called in D
unfortunately. You will need an empty constructor a separate method to
emulate this successfully.
Most importantly with D is knowing type sizes, offsets and of course if
pointer. If it is a pointer is it an array? Again if so, the sizes and
if pointer ext. ext.
Now if you want to look at how Java does it[1]. It is very similar to
what I'm saying with how C# also does it.
Anyway to summise why D doesn't yet have something akin to Java or C#.
Simply put, we generally work with the actual type not an interface. So
libraries like Orange can serialize/deserialize with great certainty
that it got everything.
However if you need any help with making such a library, please let me know!
[0]
https://msdn.microsoft.com/en-us/library/system.runtime.serialization.iserializable(v=vs.110).aspx
[1] http://docs.oracle.com/javase/7/docs/api/java/io/Serializable.html
Re: (De)Serializing interfaces
On Saturday, 22 August 2015 at 19:14:16 UTC, nims wrote: I think interfaces are very powerful and I heavily use them. The only problem I have with them is that serializing/deserializing them to XML or JSON doesn't seem to work. So far I got to try Orange and painlessjson. Using Orange all I got was a lot of compiler errors. Painlessjson did compile normally but just ignores all interface class members. I've never used Orange, but one thing you could try is casting your object from MyInterface to Object, and registering the type Foobar like in http://dsource.org/projects/orange/wiki/Tutorials/SerializeBase, then serializing/deserializing it as Object rather than MyInterface. I'm not sure if this will work, but it's worth a try if it doesn't handle interfaces. Interfaces are a bit odd in some ways, as they are not necessarily classes (and thus not implicitly convertible to Object) in situations like with COM / extern(C++).
