On Tuesday, 23 December 2014 at 03:07:10 UTC, Laeeth Isharc wrote:
It would certainly be nice to have matrices, but I also don't
think it would be right to say D is dead in water here because
it is so far behind. It also seems like the cost of writing
such a library is v small vs possible
On Friday, 21 March 2014 at 21:14:15 UTC, TJB wrote:
Walter,
I see that you will be discussing High Performance Code Using
D at the 2014 DConf. This will be a very welcomed topic for
many of us. I am a Finance Professor. I currently teach and
do research in computational finance. Might I
On Tuesday, 23 December 2014 at 07:51:18 UTC, Oren Tirosh wrote:
On Saturday, 22 March 2014 at 12:06:37 UTC, Russel Winder wrote:
On Sat, 2014-03-22 at 00:14 +, Daniel Davidson wrote:
[…]
Maybe a good starting point would be to port some of QuantLib
and see how the performance compares. In
On Tuesday, 23 December 2014 at 13:28:22 UTC, aldanor wrote:
On Tuesday, 23 December 2014 at 07:51:18 UTC, Oren Tirosh wrote:
On Saturday, 22 March 2014 at 12:06:37 UTC, Russel Winder
wrote:
On Sat, 2014-03-22 at 00:14 +, Daniel Davidson wrote:
[…]
Maybe a good starting point would be to
On Monday, 22 December 2014 at 13:37:55 UTC, aldanor wrote:
...
In this light, as I see it, D's main advantage is a high
runtime-efficiency / time-to-deploy ratio (whereas one of the
main disadvantages for practitioners would be the lack of
standard tools for working with structured
On Saturday, 22 March 2014 at 14:33:02 UTC, TJB wrote:
On Saturday, 22 March 2014 at 13:10:46 UTC, Daniel Davidson
wrote:
Data storage for high volume would also be nice. A D
implementation of HDF5, via wrappers or otherwise, would be a
very useful project. Imagine how much more friendly the
On Monday, 22 December 2014 at 08:35:59 UTC, Laeeth Isharc wrote:
On Saturday, 22 March 2014 at 14:33:02 UTC, TJB wrote:
On Saturday, 22 March 2014 at 13:10:46 UTC, Daniel Davidson
wrote:
Data storage for high volume would also be nice. A D
implementation of HDF5, via wrappers or otherwise,
On Monday, 22 December 2014 at 11:59:11 UTC, aldanor wrote:
@Laeeth
As a matter of fact, I've been working on HDF5 bindings for D
as well -- I'm done with the binding/wrapping part so far (with
automatic throwing of D exceptions whenever errors occur in the
C library, and other niceties) and
On Saturday, 22 March 2014 at 00:14:11 UTC, Daniel Davidson wrote:
On Friday, 21 March 2014 at 21:14:15 UTC, TJB wrote:
Walter,
I see that you will be discussing High Performance Code Using
D at the 2014 DConf. This will be a very welcomed topic for
many of us. I am a Finance Professor. I
On Monday, 22 December 2014 at 12:24:52 UTC, Laeeth Isharc wrote:
In case it wasn't obvious from the discussion that followed:
finance is a broad field with many different kinds of creature
within, and there are different kinds of problems faced by
different participants.
High Frequency
On Monday, 22 December 2014 at 13:37:55 UTC, aldanor wrote:
For some reason, people often relate quant finance / high
frequency trading with one of the two: either ultra-low-latency
execution or option pricing, which is just wrong. In most
likelihood, the execution is performed on FPGA
On Monday, 22 December 2014 at 17:28:39 UTC, Daniel Davidson
wrote:
I don't see D attempting to tackle that at this point.
If the bulk of the work for the data sciences piece is the
maths, which I believe it is, then the attraction of D as a
data sciences platform is muted. If the bulk of the
On Monday, 22 December 2014 at 19:25:51 UTC, aldanor wrote:
On Monday, 22 December 2014 at 17:28:39 UTC, Daniel Davidson
wrote:
I don't see D attempting to tackle that at this point.
If the bulk of the work for the data sciences piece is the
maths, which I believe it is, then the attraction of
On Monday, 22 December 2014 at 19:25:51 UTC, aldanor wrote:
On Monday, 22 December 2014 at 17:28:39 UTC, Daniel Davidson
wrote:
I don't see D attempting to tackle that at this point.
If the bulk of the work for the data sciences piece is the
maths, which I believe it is, then the attraction of
Hi.
Sorry if this is a bit long, but perhaps it may be interesting to
one or two.
On Monday, 22 December 2014 at 22:00:36 UTC, Daniel Davidson
wrote:
On Monday, 22 December 2014 at 19:25:51 UTC, aldanor wrote:
On Monday, 22 December 2014 at 17:28:39 UTC, Daniel Davidson
wrote:
I don't see
On Tuesday, 23 December 2014 at 03:07:10 UTC, Laeeth Isharc wrote:
At one very big US hf I worked with, the tools were initially
written in Perl (some years back). They weren't pretty, but
they worked, and were fast and robust enough. I has many new
features I needed for my trading strategy.
On Saturday, 22 March 2014 at 12:06:37 UTC, Russel Winder wrote:
On Sat, 2014-03-22 at 00:14 +, Daniel Davidson wrote:
[…]
Maybe a good starting point would be to port some of QuantLib
and see how the performance compares. In High Frequency
Trading I think D would be a tough sell,
On Monday, 24 March 2014 at 05:41:38 UTC, Sean Kelly wrote:
On Sunday, 23 March 2014 at 18:15:16 UTC, Paulo Pinto wrote:
At least on Java world it is not quite true.
And that's why I said a language like C/C++ that allows
aliasing.
If you use XML parsers that return a DOM or SAX, yes
On Saturday, 22 March 2014 at 17:30:45 UTC, TJB wrote:
On Saturday, 22 March 2014 at 16:35:07 UTC, Brian Rogoff wrote:
This is a very interesting thread that you started. Could you
flesh it out more with some example C++ that you'd like
compared to D? I'm sure quite a few people would assist
On Monday, 24 March 2014 at 11:57:14 UTC, Daniel Davidson wrote:
On Saturday, 22 March 2014 at 17:30:45 UTC, TJB wrote:
On Saturday, 22 March 2014 at 16:35:07 UTC, Brian Rogoff wrote:
This is a very interesting thread that you started. Could you
flesh it out more with some example C++ that
On Sunday, 23 March 2014 at 17:38:17 UTC, Sean Kelly wrote:
On Saturday, 22 March 2014 at 14:04:01 UTC, Daniel Davidson
wrote:
For example, I could see technical reasons why in certain
non-quant areas like XML parsing where D can be faster than
C++.
On Sunday, 23 March 2014 at 18:58:20 UTC, Walter Bright wrote:
On 3/23/2014 11:29 AM, Ola Fosheim Grøstad
While that is true you can have a soft real time thread
feeding the hard real time thread
Yes, and you can do that with GC, too.
You can, but the way I view soft real time is that you
On Sat, 2014-03-22 at 21:13 +, deadalnix wrote:
[…]
HFT is very latency sensitive. D stop the world GC is a no go.
D needs a better GC to be viable in these markets.
GC technology was well beyond stop the world in Common Lisp in the
1990s. Java learnt this lesson in the 2000s. IBM, Azul,
On 3/21/2014 3:33 PM, TJB wrote:
I would be happy to help you with an option pricing example that
is commonly used. Let me know if you are interested.
Sure, please email it to me.
Am 23.03.2014 08:13, schrieb Russel Winder:
On Sat, 2014-03-22 at 21:13 +, deadalnix wrote:
[…]
HFT is very latency sensitive. D stop the world GC is a no go.
D needs a better GC to be viable in these markets.
GC technology was well beyond stop the world in Common Lisp in the
1990s. Java
On 03/22/14 06:40, Russel Winder wrote:
[snip]
What you are alluding to is the use of Monte Carlo approach to solve
some of the models given boundary conditions. This is a bog standard
By bog standard do you mean plain or ordinary?
http://en.wiktionary.org/wiki/bog_standard
approach to
On Saturday, 22 March 2014 at 14:04:01 UTC, Daniel Davidson wrote:
For example, I could see technical reasons why in certain
non-quant areas like XML parsing where D can be faster than
C++.
(http://dotnot.org/blog/archives/2008/03/12/why-is-dtango-so-fast-at-parsing-xml/)
But then, with a
On 3/23/2014 12:13 AM, Russel Winder wrote:
But for real time you would just have to remove the
GC completely to have the needed guarantees.
malloc/free cannot be used in hard real time systems, either. malloc/free do not
have latency guarantees.
On Sunday, 23 March 2014 at 07:14:06 UTC, Walter Bright wrote:
On 3/21/2014 3:33 PM, TJB wrote:
I would be happy to help you with an option pricing example
that
is commonly used. Let me know if you are interested.
Sure, please email it to me.
Walter, I would be happy to. Where do I find
Am 23.03.2014 18:38, schrieb Sean Kelly:
On Saturday, 22 March 2014 at 14:04:01 UTC, Daniel Davidson wrote:
For example, I could see technical reasons why in certain non-quant
areas like XML parsing where D can be faster than C++.
On Sunday, 23 March 2014 at 17:35:37 UTC, Walter Bright wrote:
malloc/free cannot be used in hard real time systems, either.
malloc/free do not have latency guarantees.
While that is true you can have a soft real time thread feeding
the hard real time thread with new configurations and the
On 3/23/2014 11:29 AM, Ola Fosheim Grøstad
ola.fosheim.grostad+dl...@gmail.com wrote:
On Sunday, 23 March 2014 at 17:35:37 UTC, Walter Bright wrote:
malloc/free cannot be used in hard real time systems, either. malloc/free do
not have latency guarantees.
While that is true you can have a soft
On 3/23/2014 11:10 AM, TJB wrote:
Walter, I would be happy to. Where do I find your email address? Sorry if this
is a dumb question.
My first name followed by digitalmars.com.
On 3/23/2014 10:38 AM, Sean Kelly wrote:
Try no funding and a trivial amount of time. The JSON parser I wrote for work
in C performs zero allocations and unescaping is performed on demand. D
arguably makes this easier by building slicing into the language, but not
decoding or copying is a
On Sun, 2014-03-23 at 11:46 -0500, evansl wrote:
On 03/22/14 06:40, Russel Winder wrote:
[snip]
What you are alluding to is the use of Monte Carlo approach to solve
some of the models given boundary conditions. This is a bog standard
By bog standard do you mean plain or ordinary?
On Sun, 2014-03-23 at 19:15 +0100, Paulo Pinto wrote:
[…]
At least on Java world it is not quite true.
If you use XML parsers that return a DOM or SAX, yes quite true.
But as far as I can tell, XML streaming parsers (StAX) only parse on demand.
Unless I am missing something.
This is
On Sun, 2014-03-23 at 10:35 -0700, Walter Bright wrote:
On 3/23/2014 12:13 AM, Russel Winder wrote:
But for real time you would just have to remove the
GC completely to have the needed guarantees.
malloc/free cannot be used in hard real time systems, either. malloc/free do
not
have
On 3/22/2014 9:47 AM, Paulo Pinto wrote:
Assuming those 10% still happen if the test was done today as suggested,
how much are trade companies willing to pay for developers to achieve
those 10% in C++ vs having a system although 10% slower,
still fast enough for operations while saving salaries
Am 23.03.2014 22:04, schrieb Nick Sabalausky:
On 3/22/2014 9:47 AM, Paulo Pinto wrote:
Assuming those 10% still happen if the test was done today as suggested,
how much are trade companies willing to pay for developers to achieve
those 10% in C++ vs having a system although 10% slower,
still
On 3/23/2014 12:42 PM, Russel Winder wrote:
On Sun, 2014-03-23 at 10:35 -0700, Walter Bright wrote:
On 3/23/2014 12:13 AM, Russel Winder wrote:
But for real time you would just have to remove the
GC completely to have the needed guarantees.
malloc/free cannot be used in hard real time
On Sunday, 23 March 2014 at 18:15:16 UTC, Paulo Pinto wrote:
At least on Java world it is not quite true.
And that's why I said a language like C/C++ that allows aliasing.
If you use XML parsers that return a DOM or SAX, yes quite true.
But as far as I can tell, XML streaming parsers
On Saturday, 22 March 2014 at 01:24:38 UTC, Walter Bright wrote:
On 3/21/2014 5:39 PM, bearophile wrote:
That code must always be hard-real time. So a GC is allowed
only during startup
time (unless it's a quite special GC), hidden heap allocations
are forbidden,
data access patterns need to be
Am 22.03.2014 06:58, schrieb deadalnix:
On Saturday, 22 March 2014 at 01:24:38 UTC, Walter Bright wrote:
On 3/21/2014 5:39 PM, bearophile wrote:
That code must always be hard-real time. So a GC is allowed only
during startup
time (unless it's a quite special GC), hidden heap allocations are
On Sat, Mar 22, 2014 at 12:30 AM, Paulo Pinto pj...@progtools.org wrote:
Yes, as there are a few high performance trading systems done with
JVM/.NET languages.
--
Paulo
What about AAA games? :) Even though I agree with the pro-GC arguments you
put forth, but I really have a hard time
Am 22.03.2014 09:42, schrieb Ziad Hatahet:
On Sat, Mar 22, 2014 at 12:30 AM, Paulo Pinto pj...@progtools.org
mailto:pj...@progtools.org wrote:
Yes, as there are a few high performance trading systems done with
JVM/.NET languages.
--
Paulo
What about AAA games? :) Even though
On Saturday, 22 March 2014 at 08:54:46 UTC, Paulo Pinto wrote:
Am 22.03.2014 09:42, schrieb Ziad Hatahet:
On Sat, Mar 22, 2014 at 12:30 AM, Paulo Pinto
pj...@progtools.org
mailto:pj...@progtools.org wrote:
Yes, as there are a few high performance trading systems
done with
JVM/.NET
On Fri, 2014-03-21 at 22:44 +, Chris Williams wrote:
On Friday, 21 March 2014 at 22:28:36 UTC, Walter Bright wrote:
It's a good thought, but I have zero knowledge of how C++ is
used for high frequency trading.
Reading through the Wikipedia article on Computational Finance,
it looks
On Sat, 2014-03-22 at 00:39 +, bearophile wrote:
TJB:
Why a tough sell? Please explain.
That code must always be hard-real time. So a GC is allowed only
during startup time (unless it's a quite special GC), hidden heap
allocations are forbidden, data access patterns need to be
On Sat, 2014-03-22 at 00:14 +, Daniel Davidson wrote:
[…]
Maybe a good starting point would be to port some of QuantLib and
see how the performance compares. In High Frequency Trading I
think D would be a tough sell, unfortunately.
I would certainly agree that (at least initially)
On Saturday, 22 March 2014 at 11:46:43 UTC, Russel Winder wrote:
It is also worth pointing out the LMAX Disruptor which is a
lock-free
ring buffer based framework used to create dealing platforms on
the JVM.
They outperform any other trading platform still.
That is wrong. Trading is
You are absolutely correct - the finance industry _wants_ to
switch away fromC++. I work in a fledgeling HFT startup firm and
we are actively pursuing D. We have tested it out in a live
trading environment and the results are very promising.
1. We are measuring better latency numbers in D (As
Am 22.03.2014 13:38, schrieb Daniel Davidson:
On Saturday, 22 March 2014 at 11:46:43 UTC, Russel Winder wrote:
It is also worth pointing out the LMAX Disruptor which is a lock-free
ring buffer based framework used to create dealing platforms on the JVM.
They outperform any other trading
On Saturday, 22 March 2014 at 12:35:50 UTC, Saurabh Das wrote:
You are absolutely correct - the finance industry _wants_ to
switch away fromC++. I work in a fledgeling HFT startup firm and
we are actively pursuing D. We have tested it out in a live
trading environment and the results are very
On Saturday, 22 March 2014 at 12:06:37 UTC, Russel Winder wrote:
I suspect a rewrite of QuantLib in D is a bad idea, much better
to
create an adapter and offer it to the QuantLib folks. The ones
they have
already tend to be created using SWIG. JQuantLib is an attempt
to
rewrite QuantLib in
On Saturday, 22 March 2014 at 12:54:11 UTC, Paulo Pinto wrote:
Am 22.03.2014 13:38, schrieb Daniel Davidson:
On Saturday, 22 March 2014 at 11:46:43 UTC, Russel Winder
wrote:
It is also worth pointing out the LMAX Disruptor which is a
lock-free
ring buffer based framework used to create
Hi Dan,
On Saturday, 22 March 2014 at 12:56:03 UTC, Daniel Davidson wrote:
On Saturday, 22 March 2014 at 12:35:50 UTC, Saurabh Das wrote:
You are absolutely correct - the finance industry _wants_ to
switch away fromC++. I work in a fledgeling HFT startup firm
and
we are actively pursuing
Am 22.03.2014 14:21, schrieb Daniel Davidson:
On Saturday, 22 March 2014 at 12:54:11 UTC, Paulo Pinto wrote:
Am 22.03.2014 13:38, schrieb Daniel Davidson:
On Saturday, 22 March 2014 at 11:46:43 UTC, Russel Winder wrote:
It is also worth pointing out the LMAX Disruptor which is a lock-free
On Saturday, 22 March 2014 at 13:36:01 UTC, Saurabh Das wrote:
The edge for D in our case comes from 3 factors -
1. A lot of statistical data from older C++ systems means
better assumptions and decisions in the new D system; and
But, clearly that is not necessarily a benefit of D. It is a
On Saturday, 22 March 2014 at 13:47:31 UTC, Paulo Pinto wrote:
Assuming those 10% still happen if the test was done today as
suggested, how much are trade companies willing to pay for
developers to achieve those 10% in C++ vs having a system
although 10% slower,
still fast enough for
On Sat, 2014-03-22 at 12:38 +, Daniel Davidson wrote:
On Saturday, 22 March 2014 at 11:46:43 UTC, Russel Winder wrote:
It is also worth pointing out the LMAX Disruptor which is a
lock-free
ring buffer based framework used to create dealing platforms on
the JVM.
They outperform
On Sat, 2014-03-22 at 14:17 +, Daniel Davidson wrote:
[…]
Performance engineers who can eek out that 10% on existing
systems do very well. The same engineers who can build it
entirely do much better.
Good C++ programmers appear to be able to get $350k to $400k in NY.
Of course the
On Saturday, 22 March 2014 at 13:10:46 UTC, Daniel Davidson wrote:
Data storage for high volume would also be nice. A D
implementation of HDF5, via wrappers or otherwise, would be a
very useful project. Imagine how much more friendly the API
could be in D. Python's tables library makes it very
On Saturday, 22 March 2014 at 14:33:02 UTC, TJB wrote:
Well, I for one, would be hugely interested in such a thing. A
nice D API to HDF5 would be a dream for my data problems.
Did you use HDF5 in your finance industry days then? Just
curious.
A bit. You can check out some of my C++ code
On Friday, 21 March 2014 at 22:33:37 UTC, TJB wrote:
On Friday, 21 March 2014 at 22:28:36 UTC, Walter Bright wrote:
It's a good thought, but I have zero knowledge of how C++ is
used for high frequency trading.
I would be happy to help you with an option pricing example that
is commonly used.
On Saturday, 22 March 2014 at 16:35:07 UTC, Brian Rogoff wrote:
This is a very interesting thread that you started. Could you
flesh it out more with some example C++ that you'd like
compared to D? I'm sure quite a few people would assist with a
translation.
Well, right away people jumped to
On 3/22/2014 7:29 AM, Russel Winder wrote:
I guess D should be able to do things just as fast as C++, at least
using LDC or GDC. My little informal microbenchmarks indicate that this
is the case, but for now this is anecdotal evidence not statistically
significant.
Having built C++ and D
On 3/22/2014 5:35 AM, Saurabh Das wrote:
I'm quite confident that D is going to make good inroads into the
financial industry in the coming years. Looking forward to
Walter's talk in DConf and indeed all the talks in DConf. Wish I
could attend - but the flight costs too much :(. Maybe next year.
On 3/22/2014 5:56 AM, Daniel Davidson wrote:
I don't yet see where D adds distinction to that game yet - other
than being a great language.
Isn't that the best kind of distinction?
On 3/22/2014 7:04 AM, Daniel Davidson wrote:
But then, with a large amount of time and unlimited funding the techniques could
probably be duplicated in C++.
That's correct. It's also true of writing code in C or even assembler.
Productivity matters because time-to-deploy matters. I.e. if you
On Saturday, 22 March 2014 at 14:30:00 UTC, Russel Winder wrote:
On Sat, 2014-03-22 at 14:17 +, Daniel Davidson wrote:
[…]
Performance engineers who can eek out that 10% on existing
systems do very well. The same engineers who can build it
entirely do much better.
Good C++ programmers
The work Don's company does has very similar requirements to HFT.
His talks here are totally relevant to the use of D in this area.
On Saturday, 22 March 2014 at 23:27:18 UTC, Sean Kelly wrote:
The work Don's company does has very similar requirements to
HFT. His talks here are totally relevant to the use of D in
this area.
Yes, I'm very much looking forward to that talk as well.
His talk last year killed!
On Saturday, 22 March 2014 at 23:27:18 UTC, Sean Kelly wrote:
The work Don's company does has very similar requirements to
HFT. His talks here are totally relevant to the use of D in
this area.
They did significant work to customize th GC in order to meet the
requirements.
On Saturday, 22 March 2014 at 14:04:01 UTC, Daniel Davidson wrote:
On Saturday, 22 March 2014 at 13:36:01 UTC, Saurabh Das wrote:
The edge for D in our case comes from 3 factors -
1. A lot of statistical data from older C++ systems means
better assumptions and decisions in the new D system;
On Friday, 21 March 2014 at 21:14:15 UTC, TJB wrote:
Walter,
I see that you will be discussing High Performance Code Using
D at the 2014 DConf. This will be a very welcomed topic for
many of us. I am a Finance Professor. I currently teach and
do research in computational finance. Might I
On Friday, 21 March 2014 at 21:30:29 UTC, Joakim wrote:
Heh, right before I read this, I stumbled across this snippet
from Miguel De Icaza's blog from a couple months back, where he
regretted using C++ to build Moonlight, their Silverlight
implementation:
But this would not be a Saturday
Am 21.03.2014 22:39, schrieb w0rp:
On Friday, 21 March 2014 at 21:30:29 UTC, Joakim wrote:
Heh, right before I read this, I stumbled across this snippet from
Miguel De Icaza's blog from a couple months back, where he regretted
using C++ to build Moonlight, their Silverlight implementation:
But
On Friday, 21 March 2014 at 21:39:54 UTC, w0rp wrote:
On Friday, 21 March 2014 at 21:30:29 UTC, Joakim wrote:
Heh, right before I read this, I stumbled across this snippet
from Miguel De Icaza's blog from a couple months back, where
he regretted using C++ to build Moonlight, their Silverlight
On 3/21/2014 2:14 PM, TJB wrote:
I see that you will be discussing High Performance Code Using D at the 2014
DConf. This will be a very welcomed topic for many of us. I am a Finance
Professor. I currently teach and do research in computational finance. Might I
suggest that you include some
On Friday, 21 March 2014 at 22:28:36 UTC, Walter Bright wrote:
On 3/21/2014 2:14 PM, TJB wrote:
I see that you will be discussing High Performance Code Using
D at the 2014
DConf. This will be a very welcomed topic for many of us. I
am a Finance
Professor. I currently teach and do research in
On Friday, 21 March 2014 at 22:28:36 UTC, Walter Bright wrote:
It's a good thought, but I have zero knowledge of how C++ is
used for high frequency trading.
Reading through the Wikipedia article on Computational Finance,
it looks like it's basically performing simulations where some
data is
On Friday, 21 March 2014 at 21:14:15 UTC, TJB wrote:
Walter,
I see that you will be discussing High Performance Code Using
D at the 2014 DConf. This will be a very welcomed topic for
many of us. I am a Finance Professor. I currently teach and
do research in computational finance. Might I
On Saturday, 22 March 2014 at 00:14:11 UTC, Daniel Davidson wrote:
On Friday, 21 March 2014 at 21:14:15 UTC, TJB wrote:
Walter,
I see that you will be discussing High Performance Code Using
D at the 2014 DConf. This will be a very welcomed topic for
many of us. I am a Finance Professor. I
TJB:
Why a tough sell? Please explain.
That code must always be hard-real time. So a GC is allowed only
during startup time (unless it's a quite special GC), hidden heap
allocations are forbidden, data access patterns need to be
carefully chosen, you even have to use most of the hot part
On 3/21/2014 5:39 PM, bearophile wrote:
That code must always be hard-real time. So a GC is allowed only during startup
time (unless it's a quite special GC), hidden heap allocations are forbidden,
data access patterns need to be carefully chosen, you even have to use most of
the hot part of the
On Saturday, 22 March 2014 at 00:34:22 UTC, TJB wrote:
On Saturday, 22 March 2014 at 00:14:11 UTC, Daniel Davidson
wrote:
On Friday, 21 March 2014 at 21:14:15 UTC, TJB wrote:
Walter,
I see that you will be discussing High Performance Code
Using D at the 2014 DConf. This will be a very
86 matches
Mail list logo
