On Wednesday, 13 May 2015 at 03:38:33 UTC, Maxime
Chevalier-Boisvert wrote:
I was wondering if anyone has written D code to access the x86
performance counters, to get information such as the number of
cache misses and cycle count.
I considered doing that at one point. So I looked for resource
I was wondering if anyone has written D code to access the x86
performance counters, to get information such as the number of
cache misses and cycle count.
On Tuesday, 12 May 2015 at 20:50:45 UTC, Gerald Jansen wrote:
Your advice is appreciated but quite disheartening. I was
hoping for something (nearly) as easy to use as Python's
parallel.Pool() map(), given that this is essentially an
"embarassingly parallel" problem. Avoidance of GC allocation
see
import std.stdio;
import std.datetime;
import std.process;
void main() {
auto ct = Clock.currTime;
write("\n\n\tData: ",ct.day," / ",ct.month," / ",ct.year,".\n");
auto tv = Clock.currTime;
write("\tHour: ",
tv.hour,":",
tv.minute
The "interfacing to C" header of this page talks about it:
http://dlang.org/intro-to-datetime.html
import std.datetime;
import core.stdc.time;
void main() {
time_t unixTime = core.stdc.time.time(null);
auto stdTime = unixTimeToStdTime(unixTime);
auto st = SysTime(stdTime)
On Wednesday, 13 May 2015 at 01:40:04 UTC, Adam D. Ruppe wrote:
The "interfacing to C"
Sorry, "interfacing with C", search for those words on that page
and it will bring you to the header.
As strange as it sounds, after 20 minutes reading the docs about
std.datetime I could not figure out how to get a SysTime object
starting from a long unixtime. I'm sure I'm missing something
obvious, any tips?
Thanks,
dat
On Tuesday, 12 May 2015 at 20:58:16 UTC, Vladimir Panteleev wrote:
On Tuesday, 12 May 2015 at 18:14:56 UTC, Gerald Jansen wrote:
On Tuesday, 12 May 2015 at 16:35:23 UTC, Rikki Cattermole
wrote:
On 13/05/2015 4:20 a.m., Gerald Jansen wrote:
At the risk of great embarassment ... here's my progra
On Tuesday, 12 May 2015 at 03:20:34 UTC, TJB wrote:
I'm sure this question has been asked a thousand times. I've
even asked similar questions in the past (I've been away for
quite a while). But all of the tutorials that I have found
assume quite a lot and leave a lot to be inferred. Is there a
On Tuesday, 12 May 2015 at 18:14:56 UTC, Gerald Jansen wrote:
On Tuesday, 12 May 2015 at 16:35:23 UTC, Rikki Cattermole wrote:
On 13/05/2015 4:20 a.m., Gerald Jansen wrote:
At the risk of great embarassment ... here's my program:
http://dekoppel.eu/tmp/pedupg.d
Would it be possible to give us
On Tuesday, 12 May 2015 at 17:45:54 UTC, thedeemon wrote:
On Tuesday, 12 May 2015 at 17:02:19 UTC, Gerald Jansen wrote:
About 3.5 million lines read by main(), 0.5 to 2 million lines
read and 3.5 million lines written by runTraits (aka runJob).
Each GC allocation in D is a locking operation (
On Tuesday, 12 May 2015 at 19:14:23 UTC, Laeeth Isharc wrote:
But if you disable the logging does that change things?
There is only a tiny bit of logging happening.
And are you using optimization on gdc ?
gdc -Ofast -march=native -frelease
Also try byLineFast eg
http://forum.dlang.org/th
On Tuesday, 12 May 2015 at 19:10:13 UTC, Laeeth Isharc wrote:
On Tuesday, 12 May 2015 at 18:14:56 UTC, Gerald Jansen wrote:
On Tuesday, 12 May 2015 at 16:35:23 UTC, Rikki Cattermole
wrote:
On 13/05/2015 4:20 a.m., Gerald Jansen wrote:
At the risk of great embarassment ... here's my program:
ht
On Tuesday, 12 May 2015 at 18:14:56 UTC, Gerald Jansen wrote:
On Tuesday, 12 May 2015 at 16:35:23 UTC, Rikki Cattermole wrote:
On 13/05/2015 4:20 a.m., Gerald Jansen wrote:
At the risk of great embarassment ... here's my program:
http://dekoppel.eu/tmp/pedupg.d
Would it be possible to give us
On Tuesday, 12 May 2015 at 16:35:23 UTC, Rikki Cattermole wrote:
On 13/05/2015 4:20 a.m., Gerald Jansen wrote:
At the risk of great embarassment ... here's my program:
http://dekoppel.eu/tmp/pedupg.d
Would it be possible to give us some example data?
I might give it a go to try rewriting it to
On Tuesday, 12 May 2015 at 17:02:19 UTC, Gerald Jansen wrote:
About 3.5 million lines read by main(), 0.5 to 2 million lines
read and 3.5 million lines written by runTraits (aka runJob).
Each GC allocation in D is a locking operation (and disabling GC
doesn't help here at all), probably each
On Tuesday, 12 May 2015 at 16:46:42 UTC, thedeemon wrote:
On Tuesday, 12 May 2015 at 14:59:38 UTC, Gerald Jansen wrote:
The output of /usr/bin/time is as follows:
Lang JobsUser System Elapsed %CPU
Py 2 79.242.16 0:48.90 166
D 2 19.41 10.14 0:17.96 164
Py 30
On Tuesday, 12 May 2015 at 14:59:38 UTC, Gerald Jansen wrote:
The output of /usr/bin/time is as follows:
Lang JobsUser System Elapsed %CPU
Py 2 79.242.16 0:48.90 166
D 2 19.41 10.14 0:17.96 164
Py 30 1255.17 58.38 2:39.54 823 * Pool(12)
D 30 421.61
On 13/05/2015 4:20 a.m., Gerald Jansen wrote:
At the risk of great embarassment ... here's my program:
http://dekoppel.eu/tmp/pedupg.d
As per Rick's first suggestion (thanks) I added
import core.memory : GC;
main()
GC.disable;
GC.reserve(1024 * 1024 * 1024);
... to no avail.
thanks
At the risk of great embarassment ... here's my program:
http://dekoppel.eu/tmp/pedupg.d
As per Rick's first suggestion (thanks) I added
import core.memory : GC;
main()
GC.disable;
GC.reserve(1024 * 1024 * 1024);
... to no avail.
thanks for all the help so far.
Gerald
ps. I am using G
On 05/12/2015 08:35 AM, Gerald Jansen wrote:
> I could put it somewhere if that would help.
Please do so. We all want to learn to avoid such issues.
Thank you,
Ali
On 13/05/2015 2:59 a.m., Gerald Jansen wrote:
I am a data analyst trying to learn enough D to decide whether to use D
for a new project rather than Python + Fortran. I have recoded a
non-trivial Python program to do some simple parallel data processing
(using the map function in Python's multipr
Thanks Ali. I have tried putting GC.disable() in both main and
runJob, but the timing behaviour did not change. The python
version works in a similar fashion and also has automatic GC. I
tend to think that is not the (biggest) problem.
The program is long and newbie-ugly ... but I could put it
On 05/12/2015 07:59 AM, Gerald Jansen wrote:
> the performance of my D version deteriorates
> rapidly beyond a handful of jobs whereas the time for the Python version
> increases linearly with the number of jobs per cpu core.
It may be related to GC collections. If it hasn't been changed recentl
On Tuesday, 12 May 2015 at 15:11:01 UTC, John Colvin wrote:
On Tuesday, 12 May 2015 at 14:59:38 UTC, Gerald Jansen wrote:
I am a data analyst trying to learn enough D to decide whether
to use D for a new project rather than Python + Fortran. I
have recoded a non-trivial Python program to do so
On Tuesday, 12 May 2015 at 14:59:38 UTC, Gerald Jansen wrote:
I am a data analyst trying to learn enough D to decide whether
to use D for a new project rather than Python + Fortran. I
have recoded a non-trivial Python program to do some simple
parallel data processing (using the map function i
I am a data analyst trying to learn enough D to decide whether to
use D for a new project rather than Python + Fortran. I have
recoded a non-trivial Python program to do some simple parallel
data processing (using the map function in Python's
multiprocessing module and parallel foreach in D).
On Monday, 11 May 2015 at 22:46:00 UTC, Per Nordlöw wrote:
The pattern
final switch (_index)
{
import std.range: empty, front;
foreach (i, R; Rs)
{
case i:
assert(!source[i].empty)
On Tuesday, 12 May 2015 at 12:31:35 UTC, Adam D. Ruppe wrote:
Let me suggest a completely different option: make a destructor
that works while the GC is running by managing the resources
manually in both construction and destruction.
I see, but not all ressources can be disposed by any thread.
Let me suggest a completely different option: make a destructor
that works while the GC is running by managing the resources
manually in both construction and destruction. Remember, it isn't
*all* reference types that are problematic to access, it is just
GC managed references. So anything from
I need a robust "isCalledByGC" function to leak intentionally
when a destructor is called as a result of the GC.
It is a way to enforce deterministic destruction without ever
relying on accidental correctness.
class A
{
~this()
{
if(iscalledByGC())
{
[leak
On Monday, 11 May 2015 at 23:12:17 UTC, Alex Parrill wrote:
Would this work?
auto x = std.typecons.tuple(Rs)[_index]
Nope. _index must be know at compile-time.
On Monday, 11 May 2015 at 22:46:00 UTC, Per Nordlöw wrote:
The pattern
final switch (_index)
{
import std.range: empty, front;
foreach (i, R; Rs)
{
case i:
assert(!source[i].empty)
On Tuesday, 12 May 2015 at 09:26:07 UTC, John Colvin wrote:
On Monday, 11 May 2015 at 22:46:00 UTC, Per Nordlöw wrote:
The pattern
final switch (_index)
{
import std.range: empty, front;
foreach (i, R; Rs)
{
c
On Monday, 27 April 2015 at 13:54:42 UTC, Steven Schveighoffer
wrote:
On 4/25/15 3:07 AM, Dan Olson wrote:
Jacob Carlborg writes:
On 2015-04-24 20:37, Steven Schveighoffer wrote:
So am I going crazy? Or is dmd doing things differently
depending on
where its environment is? Any compiler guru
On Tuesday, 12 May 2015 at 03:20:34 UTC, TJB wrote:
I'm sure this question has been asked a thousand times. I've
even asked similar questions in the past (I've been away for
quite a while). But all of the tutorials that I have found
assume quite a lot and leave a lot to be inferred. Is there a
36 matches
Mail list logo
