But in the main() I have also had to use a deprecated delete,
And setting trades.length to zero and then using GC.free() on its
ptr gives the same good result.
Bye,
bearophile
And with the usual optimizations (struct splitting) coming from
talking a look at the access patterns, the D code gets faster:
http://codepad.org/SnxnpcAB
Bye,
bearophile
I use this GC thread to show a little GC-related benchmark.
A little Reddit thread about using memory more compactly in Java:
http://www.reddit.com/r/programming/comments/120xvf/compact_offheap_structurestuples_in_java/
The relative blog post:
On Friday, 26 October 2012 at 14:21:51 UTC, bearophile wrote:
But in the main() I have also had to use a deprecated delete,
because otherwise the GC doesn't deallocate the arrays and the
program burns all the memory (setting the array to null and
using GC.collect() isn't enough). This is not
Rob T:
Is this happening with dmd 2.060 as released?
I'm using 2.061alpha git head, but I guess the situation is the
same with dmd 2.060. The code is linked in my post, so trying it
is easy, it's one small module.
Bye,
bearophile
On Friday, 26 October 2012 at 23:10:48 UTC, bearophile wrote:
Rob T:
Is this happening with dmd 2.060 as released?
I'm using 2.061alpha git head, but I guess the situation is the
same with dmd 2.060. The code is linked in my post, so trying
it is easy, it's one small module.
Bye,
On Saturday, 27 October 2012 at 01:03:57 UTC, Rob T wrote:
On Friday, 26 October 2012 at 23:10:48 UTC, bearophile wrote:
Rob T:
Is this happening with dmd 2.060 as released?
I'm using 2.061alpha git head, but I guess the situation is
the same with dmd 2.060. The code is linked in my post,
On Saturday, 27 October 2012 at 01:03:57 UTC, Rob T wrote:
On Friday, 26 October 2012 at 23:10:48 UTC, bearophile wrote:
Rob T:
Is this happening with dmd 2.060 as released?
I'm using 2.061alpha git head, but I guess the situation is
the same with dmd 2.060. The code is linked in my post,
On Thursday, 25 October 2012 at 02:15:41 UTC, Jakob Ovrum wrote:
On Wednesday, 24 October 2012 at 23:05:29 UTC, Rob T wrote:
In my case, I'm not too concerned about performance, or pauses
in the execution, but I do require dynamic loadable libraries,
and I do want to link D code to existing
On Thursday, 25 October 2012 at 02:15:41 UTC, Jakob Ovrum wrote:
You can very much link to C and C++ code, or have C and C++
code link to your D code, while still using the GC, you just
have to be careful when you send GC memory to external code.
You can even share the same GC between
On Thursday, 25 October 2012 at 08:34:15 UTC, Rob T wrote:
My understanding of dynamic linking and the runtime is based on
this thread
http://www.digitalmars.com/d/archives/digitalmars/D/dynamic_library_building_and_loading_176983.html
The runtime is not compiled to be sharable, so you cannot
On Thursday, 25 October 2012 at 08:50:19 UTC, Jakob Ovrum wrote:
You are right that compiling the runtime itself (druntime and
Phobos) as a shared library is not yet fully realized, but that
doesn't stop you from compiling your own libraries and
applications as shared libraries even if they
On Thursday, 25 October 2012 at 02:15:41 UTC, Jakob Ovrum wrote:
You can even share the same GC between dynamic libraries and
the host application (if both are D and use GC, of course)
using the GC proxy system.
What is the GC proxy system, and how do I make use of it?
--rt
On Thursday, 25 October 2012 at 17:17:01 UTC, Rob T wrote:
Yes I can build my own D shared libs, both as static PIC (.a)
and dynamically loadable (.so). however I cannot statically
link my shared libs to druntime + phobos as-is. The only way I
can do that, is to also compile druntime + phobos
On Thursday, 25 October 2012 at 17:17:01 UTC, Rob T wrote:
Yes I can build my own D shared libs, both as static PIC (.a)
and dynamically loadable (.so). however I cannot statically
link my shared libs to druntime + phobos as-is. The only way I
can do that, is to also compile druntime + phobos
On Thursday, 25 October 2012 at 17:20:40 UTC, Rob T wrote:
On Thursday, 25 October 2012 at 02:15:41 UTC, Jakob Ovrum wrote:
You can even share the same GC between dynamic libraries and
the host application (if both are D and use GC, of course)
using the GC proxy system.
What is the GC proxy
On Tuesday, 23 October 2012 at 22:31:03 UTC, Rob T wrote:
On Tuesday, 23 October 2012 at 16:30:41 UTC, Benjamin Thaut
wrote:
Here a small update:
I found a piece of code that did manually slow down the
simulation in case it got to fast. This code never kicked in
with the GC version, because
On Wednesday, 24 October 2012 at 12:21:03 UTC, Paulo Pinto wrote:
Having dealt with systems programming in languages with GC
(Native Oberon, Modula-3), I wonder how much an optional GC
would really matter, if D's GC had better performance.
--
Paulo
Well, performnce is only part of the GC
On Wednesday, 24 October 2012 at 18:26:48 UTC, Rob T wrote:
On Wednesday, 24 October 2012 at 12:21:03 UTC, Paulo Pinto
wrote:
Having dealt with systems programming in languages with GC
(Native Oberon, Modula-3), I wonder how much an optional GC
would really matter, if D's GC had better
On Wednesday, 24 October 2012 at 21:02:34 UTC, Paulo Pinto wrote:
So I always take the assertions that manual memory management
is a must with a grain of salt.
--
Paulo
Probably no one in here is thinking that we should not have a GC.
I'm sure that many applications will benefit from a GC,
On Wednesday, 24 October 2012 at 23:05:29 UTC, Rob T wrote:
In my case, I'm not too concerned about performance, or pauses
in the execution, but I do require dynamic loadable libraries,
and I do want to link D code to existing C/C++ code, but in
order to do these things, I cannot use the GC
On Wednesday, 24 October 2012 at 23:05:29 UTC, Rob T wrote:
In my case, I'm not too concerned about performance, or pauses
in the execution, but I do require dynamic loadable libraries,
and I do want to link D code to existing C/C++ code, but in
order to do these things, I cannot use the GC
Here a small update:
I found a piece of code that did manually slow down the simulation in
case it got to fast. This code never kicked in with the GC version,
because it never reached the margin. The manual memory managed version
however did reach the margin and was slowed down. With this
On Tuesday, 23 October 2012 at 16:30:41 UTC, Benjamin Thaut wrote:
Here a small update:
I found a piece of code that did manually slow down the
simulation in case it got to fast. This code never kicked in
with the GC version, because it never reached the margin. The
manual memory managed
On Tuesday, 11 September 2012 at 10:28:29 UTC, bearophile wrote:
SomeDude:
It's a bad solution imho. Monitoring the druntime and hunting
every part that allocates until our codebase is correct like
Benjamen Thaut is a much better solution
Why do you think such hunt is better than letting
On Wednesday, 12 September 2012 at 02:37:52 UTC, SomeDude wrote:
On Tuesday, 11 September 2012 at 10:28:29 UTC, bearophile wrote:
SomeDude:
It's a bad solution imho. Monitoring the druntime and hunting
every part that allocates until our codebase is correct like
Benjamen Thaut is a much
SomeDude:
It's a bad solution imho. Monitoring the druntime and hunting
every part that allocates until our codebase is correct like
Benjamen Thaut is a much better solution
Why do you think such hunt is better than letting the compiler
tell you what parts of your program have the side
On Tuesday, 11 September 2012 at 10:28:29 UTC, bearophile wrote:
SomeDude:
It's a bad solution imho. Monitoring the druntime and hunting
every part that allocates until our codebase is correct like
Benjamen Thaut is a much better solution
Why do you think such hunt is better than letting
The full sourcecode for the non-GC version is now aviable on github. The
GC version will follow soon.
https://github.com/Ingrater/Spacecraft
Kind Regards
Benjamin Thaut
On 2012-09-07 01:53, Sean Kelly wrote:
What version flags are set by GDC vs. DMD in your target apps? The way stop the
world is done on Linux vs. Windows is different, for example.
He's using only Windows as far as I understand, GDC MinGW.
--
/Jacob Carlborg
On Thursday, 6 September 2012 at 20:44:29 UTC, Walter Bright
wrote:
On 9/6/2012 10:50 AM, Benjamin Thaut wrote:
I just tried profiling it with Very Sleepy but basically it
only tells me for
both versions that most of the time is spend in
gcx.fullcollect.
Just that the GDC version spends less
On 7 September 2012 07:28, Sven Torvinger s...@torvinger.se wrote:
On Thursday, 6 September 2012 at 20:44:29 UTC, Walter Bright wrote:
On 9/6/2012 10:50 AM, Benjamin Thaut wrote:
I just tried profiling it with Very Sleepy but basically it only tells me
for
both versions that most of the
You can find the full article at:
http://3d.benjamin-thaut.de/?p=20#more-20
You make some good points about what happen under the hood.
Especially:
- homogeneous variadic function call allocate
- comparison of const object allocate
- useless druntime invariant handlers calls
I removed some
Benjamin Thaut wrote:
I rewrote a 3d game I created during my studies with D 2.0 to manual
memory mangement. If I'm not studying I'm working in the 3d Engine
deparement of Havok. As I needed to pratice manual memory management
and did want to get rid of the GC in D for quite some time, I did
On 9/6/2012 11:47 PM, Iain Buclaw wrote:
On a side note of that though, GDC has bt, btr, bts, etc, as
intrinsics to its compiler front-end. So it would be no problem
switching to version = bitops for version GNU.
Would it be easy to give that a try, and see what happens?
On 7 September 2012 10:31, Walter Bright newshou...@digitalmars.com wrote:
On 9/6/2012 11:47 PM, Iain Buclaw wrote:
On a side note of that though, GDC has bt, btr, bts, etc, as
intrinsics to its compiler front-end. So it would be no problem
switching to version = bitops for version GNU.
On 9/7/2012 2:52 AM, Iain Buclaw wrote:
On 7 September 2012 10:31, Walter Bright newshou...@digitalmars.com wrote:
On 9/6/2012 11:47 PM, Iain Buclaw wrote:
On a side note of that though, GDC has bt, btr, bts, etc, as
intrinsics to its compiler front-end. So it would be no problem
switching
On Sep 6, 2012, at 10:57 PM, Jacob Carlborg d...@me.com wrote:
On 2012-09-07 01:53, Sean Kelly wrote:
What version flags are set by GDC vs. DMD in your target apps? The way
stop the world is done on Linux vs. Windows is different, for example.
He's using only Windows as far as I
Am 07.09.2012 01:53, schrieb Sean Kelly:
On Sep 6, 2012, at 10:50 AM, Benjamin Thaut c...@benjamin-thaut.de wrote:
Am 06.09.2012 15:30, schrieb ponce:
The problem with intstrumentation is, that I can not recompile
druntime for the MinGW GDC, as this is not possible with the binary
release of
On 9/7/12 6:31 PM, Benjamin Thaut wrote:
I did build druntime and phobos with -release -noboundscheck -inline -O
for DMD.
For MinGW GDC I just used whatever version of druntime and phobos came
precompiled with it, so I can't tell you which flags have been used to
compile that. But I can tell you
Am 07.09.2012 18:36, schrieb Andrei Alexandrescu:
You mentioned some issues in Phobos with memory allocation, that you had
to replace with your own code. It would be awesome if you could post
more about that, and possibly post a few pull requests where directly
applicable.
Thanks,
Andrei
On Thursday, 6 September 2012 at 00:00:31 UTC, bearophile wrote:
Walter Bright:
I'd like it if you could add some instrumentation to see what
accounts for the time difference. I presume they both use the
same D source code.
Maybe that performance difference comes from the sum of some
Walter Bright:
No code gen changes whatsoever were needed.
In that case I think I didn't specify what subsystem of the D
compiler was not good enough, I have just shown a performance
difference. The division was slow, regardless of the cause. This
is what's important for the final C/D
On 9/6/2012 4:30 AM, Peter Alexander wrote:
In addition to Walter's response, it is very rare for advanced compiler
optimisations to make 2x difference on any non-trivial code. Not
impossible, but it's definitely suspicious.
I love trying to explain to people our debug builds are too slow
Am 06.09.2012 01:10, schrieb Walter Bright:
On 9/5/2012 4:03 AM, Benjamin Thaut wrote:
GC collection times:
DMD GC Version: 8.9 ms
GDC GC Version: 4.1 ms
I'd like it if you could add some instrumentation to see what accounts
for the time difference. I presume they both use the same D source
The problem with intstrumentation is, that I can not recompile
druntime for the MinGW GDC, as this is not possible with the
binary release of MinGW GDC and I did not go thorugh the effort
to setup the whole build.
I'm open to suggestions though how I could profile the GC
without recompiling
Am 06.09.2012 15:30, schrieb ponce:
The problem with intstrumentation is, that I can not recompile
druntime for the MinGW GDC, as this is not possible with the binary
release of MinGW GDC and I did not go thorugh the effort to setup the
whole build.
I'm open to suggestions though how I could
I just tried profiling it with Very Sleepy but basically it
only tells me for both versions that most of the time is spend
in gcx.fullcollect.
Just that the GDC version spends less time in gcx.fullcollect
then the DMD version.
As I can not rebuild druntime with GDC it will be quite hard to
On 9/6/2012 10:50 AM, Benjamin Thaut wrote:
I just tried profiling it with Very Sleepy but basically it only tells me for
both versions that most of the time is spend in gcx.fullcollect.
Just that the GDC version spends less time in gcx.fullcollect then the DMD
version.
Even so, that in
On Sep 6, 2012, at 10:50 AM, Benjamin Thaut c...@benjamin-thaut.de wrote:
Am 06.09.2012 15:30, schrieb ponce:
The problem with intstrumentation is, that I can not recompile
druntime for the MinGW GDC, as this is not possible with the binary
release of MinGW GDC and I did not go thorugh the
On 05-09-2012 13:03, Benjamin Thaut wrote:
I rewrote a 3d game I created during my studies with D 2.0 to manual
memory mangement. If I'm not studying I'm working in the 3d Engine
deparement of Havok. As I needed to pratice manual memory management and
did want to get rid of the GC in D for quite
Am 05.09.2012 13:10, schrieb Alex Rønne Petersen:
Is source code available anywhere?
Also, I have to point out that programming for a garbage collected
runtime is very different from doing manual memory management. The same
patterns don't apply, and you optimize in different ways. For
On 05-09-2012 13:19, Benjamin Thaut wrote:
Am 05.09.2012 13:10, schrieb Alex Rønne Petersen:
Is source code available anywhere?
Also, I have to point out that programming for a garbage collected
runtime is very different from doing manual memory management. The same
patterns don't apply, and
Benjamin Thaut:
But still in the GC version you have the problem that way to
many parts of the language allocate and you don't event notice
it when using the GC.
Maybe a compiler-enforced annotation for functions and modules is
able to remove this problem in D.
Bye,
bearophile
Am 05.09.2012 14:07, schrieb Benjamin Thaut:
class A {}
class B : A{}
A a = new A();
B b = new B();
if(a == b) //this will allocate
{
}
Should be:
class A {}
class B : A{}
const(A) a = new A();
const(B) b = new B();
if(a == b) //this will allocate
{
}
On 05-09-2012 14:07, Benjamin Thaut wrote:
Am 05.09.2012 14:00, schrieb Alex Rønne Petersen:
Sure, I just want to point out that it's a problem with the language (GC
allocations being very non-obvious) as opposed to the nature of GC.
Thats exactly what I want to cause with this post. More
On 05-09-2012 13:03, Benjamin Thaut wrote:
I rewrote a 3d game I created during my studies with D 2.0 to manual
memory mangement. If I'm not studying I'm working in the 3d Engine
deparement of Havok. As I needed to pratice manual memory management and
did want to get rid of the GC in D for quite
Benjamin Thaut wrote:
I do object pooling in both versions, as in game developement you
usually don't allocate during the frame. But still in the GC version you
have the problem that way to many parts of the language allocate and you
don't event notice it when using the GC.
There's one
Am 05.09.2012 14:14, schrieb Alex Rønne Petersen:
Where's the catch? From looking in druntime, I don't see where the
allocation could occur.
Everything is in object_.d:
equals_t opEquals(Object lhs, Object rhs)
{
if (lhs is rhs)
return true;
if (lhs is
On Wednesday, 5 September 2012 at 12:27:05 UTC, Benjamin Thaut
wrote:
Then because they are const, TypeInfo_Const.toString() will be
called:
override string toString()
{
return cast(string) (const( ~ base.toString() ~ ));
}
which allocates, due to array concardination.
Am 05.09.2012 14:34, schrieb Peter Alexander:
On Wednesday, 5 September 2012 at 12:27:05 UTC, Benjamin Thaut wrote:
Then because they are const, TypeInfo_Const.toString() will be called:
override string toString()
{
return cast(string) (const( ~ base.toString() ~ ));
}
On 5 September 2012 13:27, Benjamin Thaut c...@benjamin-thaut.de wrote:
Am 05.09.2012 14:14, schrieb Alex Rønne Petersen:
Where's the catch? From looking in druntime, I don't see where the
allocation could occur.
Everything is in object_.d:
equals_t opEquals(Object lhs, Object rhs)
On 5 September 2012 14:04, Iain Buclaw ibuc...@ubuntu.com wrote:
On 5 September 2012 13:27, Benjamin Thaut c...@benjamin-thaut.de wrote:
Am 05.09.2012 14:14, schrieb Alex Rønne Petersen:
Where's the catch? From looking in druntime, I don't see where the
allocation could occur.
Everything
On 9/5/12 1:03 PM, Benjamin Thaut wrote:
http://3d.benjamin-thaut.de/?p=20#more-20
Smile, you're on reddit:
http://www.reddit.com/r/programming/comments/ze4cx/real_world_comparison_gc_vs_manual_memory/
Andrei
On Wednesday, 5 September 2012 at 12:22:52 UTC, Alex Rønne
Petersen wrote:
On 05-09-2012 13:03, Benjamin Thaut wrote:
I rewrote a 3d game I created during my studies with D 2.0 to
manual
memory mangement. If I'm not studying I'm working in the 3d
Engine
deparement of Havok. As I needed to
Am 05.09.2012 15:07, schrieb Iain Buclaw:
On 5 September 2012 14:04, Iain Buclaw ibuc...@ubuntu.com wrote:
On 5 September 2012 13:27, Benjamin Thaut c...@benjamin-thaut.de wrote:
Am 05.09.2012 14:14, schrieb Alex Rønne Petersen:
Where's the catch? From looking in druntime, I don't see where
Benjamin Thaut:
http://3d.benjamin-thaut.de/?p=20#more-20
Regardind your issues list, most of them are fixable, like the
one regarding array literals, and even the one regarding the
invariant handler.
But I didn't know about this, and I don't know how and if this is
fixable:
The new
On 5 September 2012 15:57, bearophile bearophileh...@lycos.com wrote:
Benjamin Thaut:
http://3d.benjamin-thaut.de/?p=20#more-20
Regardind your issues list, most of them are fixable, like the one regarding
array literals, and even the one regarding the invariant handler.
I have no clue
On 9/5/12 4:59 PM, Benjamin Thaut wrote:
Still, comparing two type info objects will result in one or multiple
allocations most of the time.
Could you please submit a patch for that? Thanks!
Andrei
P.S. Very nice work. Congrats!
Iain Buclaw:
Most of the array allocation cases we are talking about are like:
void main() {
int[3] a = [1, 2, 3]; // fixed size array
}
That currently produces, with DMD:
__Dmain:
L0: sub ESP, 010h
mov EAX, offset FLAT:_D12TypeInfo_xAi6__initZ
push EBX
push 0Ch
On 5 September 2012 16:31, bearophile bearophileh...@lycos.com wrote:
Iain Buclaw:
Most of the array allocation cases we are talking about are like:
void main() {
int[3] a = [1, 2, 3]; // fixed size array
}
That currently produces, with DMD:
__Dmain:
L0: sub ESP, 010h
Iain Buclaw:
I think it was mostly due to that you can't tell the difference
between array literals that are to be assigned to either
dynamic or static arrays (as far as I can tell).
I see.
I do believe that the issues
surrounded dynamic arrays causing SEGVs, and not static (I
don't
Am 05.09.2012 16:57, schrieb bearophile:
Benjamin Thaut:
http://3d.benjamin-thaut.de/?p=20#more-20
Regardind your issues list, most of them are fixable, like the one
regarding array literals, and even the one regarding the invariant handler.
But I didn't know about this, and I don't know
Am 05.09.2012 16:07, schrieb anonymous:
It was interesting to read it. What about GDC MMM?
The GDC druntime does have a different folder structure, which makes it
a lot more time consuming to add in the changes. Also it is not possible
to rebuild phobos or druntime with the binary release
My standard library is now aviable on github:
https://github.com/Ingrater/thBase
Kind Regards
Benjamin Thaut
Am Wed, 05 Sep 2012 13:03:37 +0200
schrieb Benjamin Thaut c...@benjamin-thaut.de:
I rewrote a 3d game I created during my studies with D 2.0 to manual
memory mangement. If I'm not studying I'm working in the 3d Engine
deparement of Havok. As I needed to pratice manual memory management
and
Am 05.09.2012 19:31, schrieb Johannes Pfau:
Would be great if some of the code could be merged into phobos,
especially the memory tracker. But also things like memory or object
pools would be great in phobos, an emplace wrapper which accepts a
custom alloc function to replace new (and something
On Sep 5, 2012, at 8:08 AM, Iain Buclaw ibuc...@ubuntu.com wrote:
Array literals are not so easy to fix. I once thought that it would
be optimal to make it a stack initialisation given that all values are
known at compile time, this infact caused many strange SEGV's in quite
a few of my
On Wednesday, 5 September 2012 at 11:03:03 UTC, Benjamin Thaut
wrote:
I rewrote a 3d game I created during my studies with D 2.0 to
manual memory mangement. If I'm not studying I'm working in the
3d Engine deparement of Havok. As I needed to pratice manual
memory management and did want to get
On 9/5/2012 4:03 AM, Benjamin Thaut wrote:
GC collection times:
DMD GC Version: 8.9 ms
GDC GC Version: 4.1 ms
I'd like it if you could add some instrumentation to see what accounts for the
time difference. I presume they both use the same D source code.
On 6 September 2012 00:10, Walter Bright newshou...@digitalmars.com wrote:
On 9/5/2012 4:03 AM, Benjamin Thaut wrote:
GC collection times:
DMD GC Version: 8.9 ms
GDC GC Version: 4.1 ms
I'd like it if you could add some instrumentation to see what accounts for
the time
Walter Bright:
I'd like it if you could add some instrumentation to see what
accounts for the time difference. I presume they both use the
same D source code.
Maybe that performance difference comes from the sum of some
metric tons of different little optimizations done by the GCC
On 9/5/2012 5:01 PM, bearophile wrote:
Walter Bright:
I'd like it if you could add some instrumentation to see what accounts for the
time difference. I presume they both use the same D source code.
Maybe that performance difference comes from the sum of some metric tons of
different little
83 matches
Mail list logo
