On Sunday, 29 December 2013 at 21:26:33 UTC, CJS wrote:
A variation of that is what numpy and Eigen use. In numpy, for
the array class '*' is element-wise by default and the function
np.dot is matrix multiplication. For Eigen '*' is matrix
multiplication by default while the (member) function
cwi
> I'm not sure if D's operator overloading is
sufficiently rich to
allow separate operators for matrix multiplication and
element-wise
multiplication in matrix. (Dealing with this is a pain in
numpy, the most common
Python matrix library, as well as in Eigen, a common c++
matrix library.)
I
On 28/12/13 06:53, CJS wrote:
I don't think anything related to linear algebra belongs in the standard
library. See here, for example:
http://forum.dlang.org/thread/rmyaglfeimzuggolu...@forum.dlang.org?page=2#post-rfnnzssennvpxcihmcmb:40forum.dlang.org.
The basic point is that linear algebra libr
Sounds good to me. By the way, I think Cristi was considering
targeting the linear algebra work towards Phobos -- you might
like to consider if some parts of SciD could be reworked as
standard library features, although obviously you have greater
freedom to extend and experiment in an inde
On 2013-12-24 01:30, Manu wrote:
DMD doesn't, which is where it's needed the most >_<
Ideally, this needs to be standardised, so compiler-specific intrinsics
can be properly wrapped up.
Perhaps you might be able to finish the implementation with GDC. You can
sill use @attribute("forceinline")
On 24 December 2013 09:37, Iain Buclaw wrote:
> On 23 December 2013 23:02, Manu wrote:
> > On 23 December 2013 22:06, bearophile wrote:
> >>
> >> Iain Buclaw:
> >>
> >>
> >> Did you really think that __simd went through a design phase? :-)
> >>
> >> I understand. So there is still a problem big
On 23 December 2013 23:02, Manu wrote:
> On 23 December 2013 22:06, bearophile wrote:
>>
>> Iain Buclaw:
>>
>>
>> Did you really think that __simd went through a design phase? :-)
>>
>> I understand. So there is still a problem bigger than __simd.
>
>
> To be fair, I don't think this is as signif
On 23 December 2013 22:06, bearophile wrote:
> Iain Buclaw:
>
>
> Did you really think that __simd went through a design phase? :-)
>
> I understand. So there is still a problem bigger than __simd.
>
To be fair, I don't think this is as significant as it sounds. I agree,
__simd had no real desig
On 23/12/13 12:57, Francesco Cattoglio wrote:
No real battleplan other than turning it into a DUB package, then I guess I will
move from there. But first, I need to analyze and understand the 2 codebases:
the Kyllingstad one and the cristicbz fork. I'd like to understand if there's
any way to rec
Iain Buclaw:
Did you really think that __simd went through a design phase? :-)
I understand. So there is still a problem bigger than __simd.
Bye,
bearophile
On 23 December 2013 11:05, bearophile wrote:
> Iain Buclaw:
>
>
>> For inline assembly, making dmd work better how?
>
>
> I meant making dmd better in general. Faster floating point, more
> optimization tricks, etc.
>
>
>
>> Not possible without some sort of translation map, which would be target
On Sunday, 22 December 2013 at 19:49:21 UTC, Joseph Rushton
Wakeling wrote:
On 20/12/13 02:40, Francesco Cattoglio wrote:
I don't know, I feel like I would be more useful if I only
sticked with working
on the standard library when needed and writing software that
others might find
interesting
Iain Buclaw:
For inline assembly, making dmd work better how?
I meant making dmd better in general. Faster floating point, more
optimization tricks, etc.
Not possible without some sort of translation map, which would
be target
specific, so not suitable for GDC, and language specific so not
On 2013-12-22 22:30, Iain Buclaw wrote:
While useful the ability to write inline assembler functions, DMD
can't inline these around the place. So you get all the benefits of
being able to shortcut the fastest route to do X, but with the
slowdown of 25% because there's a big elephant in the room.
On Dec 23, 2013 12:00 AM, "bearophile" wrote:
>
> Iain Buclaw:
>
>
>> That same support is never going to happen. Not because of
>> disagreement, but because our backends are designed to work most
>> naturally in conflicting ways.
>
>
> I think this means that working to make DMD better is a good
Iain Buclaw:
That same support is never going to happen. Not because of
disagreement, but because our backends are designed to work most
naturally in conflicting ways.
I think this means that working to make DMD better is a good
idea, because every compiler has different strengths, like Walt
On 21 December 2013 06:26, Paulo Pinto wrote:
> On 20.12.2013 22:05, Jacob Carlborg wrote:
>>
>> On 2013-12-20 08:03, Paulo Pinto wrote:
>>
>>> Even though I rather use D than Go, every time I read that, I am tempted
>>> to prove people wrong. If I had the time for it, that is.
>>>
>>> Go offers t
On 21/12/13 15:44, Russel Winder wrote:
Inline assembly means you have to have the assembly code for each
supported platform in the code with all the conditionals to the
compiler. Having separate files is often much easier to manage and to
build from.
OK so D only support Intel processors just n
On 20/12/13 02:40, Francesco Cattoglio wrote:
I don't know, I feel like I would be more useful if I only sticked with working
on the standard library when needed and writing software that others might find
interesting (I'm planning on "resurrecting" SciD btw)
Nice to know -- anything in particu
On Sunday, 22 December 2013 at 17:21:59 UTC, Walter Bright wrote:
There's nothing tricky about an assembler or its syntax. There
may be issues with supporting an inline assembler and the GDC
or LDC back end interfaces, that I don't know about.
Both GCC and LLVM actually support more extensive
Walter Bright:
Apparently nobody writing an assembler ever had the obvious
idea of tacking on a C front end so it could at least pull the
struct declarations out of the .h files.
In D you can do the opposite: write the asm files, import them
statically from D and parse and convert them with
On 12/22/2013 12:05 AM, Russel Winder wrote:
There is no case where D's support for intel inline assembler is worse than
forcing you to use a separate assembler.
My point is really that D needs to support ARM pdq to have any chance of
getting traction in an increasingly bi-partisan (Intel/AMD a
On 12/22/2013 12:10 AM, Russel Winder wrote:
Historically, and anecdotally, I found that as soon as the assembly
language was a function, it was better as a separate entity, that inline
assembler only worked for accessing a processor instruction that the
code generator could not generate. So I th
On Sunday, 22 December 2013 at 08:11:05 UTC, Russel Winder wrote:
Historically, and anecdotally, I found that as soon as the
assembly
language was a function, it was better as a separate entity,
Well, you can usually get what you want by first writing the code
in C, then generate asm and opti
On Sun, 2013-12-22 at 04:48 +, Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?=
[…]
> Depends, it allows you to add support for locking-mechanisms/SIMD
> instructions/etc before getting language support. You want that
> inlined and the compiler to do register assignment. I believe
> LLVM just pass it o
On Sat, 2013-12-21 at 11:29 -0800, Walter Bright wrote:
> On 12/21/2013 6:44 AM, Russel Winder wrote:
> > Inline assembly means you have to have the assembly code for each
> > supported platform in the code with all the conditionals to the
> > compiler. Having separate files is often much easier to
On Sat, 2013-12-21 at 20:18 +0100, Araq wrote:
[…]
> The point of an inline assembler is that the compiler knows
> things like field offsets and so can provide useful features no
> external assembler can. It can also inline the assembler code
> eliminating any function call overhead. Your ignora
On Saturday, 21 December 2013 at 10:14:32 UTC, Russel Winder
wrote:
C, C++, Go, D have the advantage of using separate files with
the
assembly code in.
Inline assembly language is a huge disadvantage in many (most?)
case.
Depends, it allows you to add support for locking-mechanisms/SIMD
ins
Personally I rather use powerful external macro assemblers like
NASM/MASM than inline assemblers, as I mentioned a few times
here.
Specially since most inline assemblers I used tend to be rather
limited in comparison.
Actually DMD might be the most powerful macro assembler out there:
On 12/21/2013 6:44 AM, Russel Winder wrote:
Inline assembly means you have to have the assembly code for each
supported platform in the code with all the conditionals to the
compiler. Having separate files is often much easier to manage and to
build from.
You can still put D inline assembly in
Inline assembly means you have to have the assembly code for
each
supported platform in the code with all the conditionals to the
compiler. Having separate files is often much easier to manage
and to
build from.
No, that's a completely orthogonal issue: You can easily have
architecture depe
On 21.12.2013 14:03, Jacob Carlborg wrote:
On 2013-12-21 11:14, Russel Winder wrote:
Inline assembly language is a huge disadvantage in many (most?) case.
I don't know. Would you like to move all the current inline assembly in
druntime to their own files? I don't use assembly myself but it se
On Sat, 2013-12-21 at 14:03 +0100, Jacob Carlborg wrote:
> On 2013-12-21 11:14, Russel Winder wrote:
>
> > Inline assembly language is a huge disadvantage in many (most?) case.
>
> I don't know. Would you like to move all the current inline assembly in
> druntime to their own files? I don't use
On 2013-12-21 11:14, Russel Winder wrote:
Inline assembly language is a huge disadvantage in many (most?) case.
I don't know. Would you like to move all the current inline assembly in
druntime to their own files? I don't use assembly myself but it seems
convenient to have support for inline
On 2013-12-21 07:26, Paulo Pinto wrote:
However you do touch a nice point, even ANSI/ISO C needs to rely on
external assemblers to be useful at systems level. This is something
developers forget when they equate language == what my compiler supports.
You will most likely not be able to rely on
On Fri, 2013-12-20 at 22:05 +0100, Jacob Carlborg wrote:
[…]
> When developing an OS, for somethings these languages are not enough,
> including C, Go and D. You need to use assembly. D has the advantage of
> supporting inline assembly.
C, C++, Go, D have the advantage of using separate files wi
On 20.12.2013 22:05, Jacob Carlborg wrote:
On 2013-12-20 08:03, Paulo Pinto wrote:
Even though I rather use D than Go, every time I read that, I am tempted
to prove people wrong. If I had the time for it, that is.
Go offers the same mechanisms for systems programming as Oberon does. If
ETHZ wa
On 2013-12-20 08:03, Paulo Pinto wrote:
Even though I rather use D than Go, every time I read that, I am tempted
to prove people wrong. If I had the time for it, that is.
Go offers the same mechanisms for systems programming as Oberon does. If
ETHZ was able to create Native Oberon, AOS and EthO
On 2013-12-20 16:12, bearophile wrote:
Lot of programmers ignore what academia does, this is a big problem.
Unfortunately the opposite is true as well. I read some article that
here in Sweden the universities and other schools examines around 1000
people in the area of game development. At t
Lot of programmers ignore what academia does, this is a big
problem.
Because these programmers are not to be convinced by some arcane
academic argument but by success stories of 'industrial'
projects. I don't think that's too bad, somehow the bad academic
ideas need to be filtered.
But now
pjmlp:
Now we have Julia already achieving C like speeds in some
areas, although the implementation is still quite young.
Julia compiles using LLVM, that is mature. But I think Julia uses
light optimization parameters (I don't know if the optimization
level can be changed).
So until a big
On Friday, 20 December 2013 at 10:26:09 UTC, Araq wrote:
On Friday, 20 December 2013 at 07:04:02 UTC, Paulo Pinto wrote:
On Friday, 20 December 2013 at 06:50:41 UTC, SomeDude wrote:
On Thursday, 19 December 2013 at 12:27:57 UTC, bearophile
wrote:
Russel Winder:
The whole point of Go is to re
On Friday, 20 December 2013 at 07:04:02 UTC, Paulo Pinto wrote:
On Friday, 20 December 2013 at 06:50:41 UTC, SomeDude wrote:
On Thursday, 19 December 2013 at 12:27:57 UTC, bearophile
wrote:
Russel Winder:
The whole point of Go is to replace C,
I didn't know this.
Bye,
bearophile
Because
On Friday, 20 December 2013 at 06:50:41 UTC, SomeDude wrote:
On Thursday, 19 December 2013 at 12:27:57 UTC, bearophile wrote:
Russel Winder:
The whole point of Go is to replace C,
I didn't know this.
Bye,
bearophile
Because it's no longer true at all. It was the goal at the
beginning, bu
On Thursday, 19 December 2013 at 12:27:57 UTC, bearophile wrote:
Russel Winder:
The whole point of Go is to replace C,
I didn't know this.
Bye,
bearophile
Because it's no longer true at all. It was the goal at the
beginning, but it's no longer, they've said that Go is not a
system progra
"Francesco Cattoglio" wrote in message
news:xahqixgqvbnyimyhz...@forum.dlang.org...
> On Thursday, 19 December 2013 at 12:10:28 UTC, Daniel Murphy wrote:
>> Lots and lots and lots and lots.
>
> I wish I could help, but I really know _nothing_ about compilers.
Well, that's where I was a few years
On Friday, 20 December 2013 at 01:40:37 UTC, Francesco Cattoglio
wrote:
[snip]
(I'm planning on "resurrecting" SciD btw)
[snip]
I've been using SciD for about 12 months and it does a fine job.
It would be great to see it grow even more.
Cheers,
Ed
On Thursday, 19 December 2013 at 15:48:07 UTC, Paulo Pinto wrote:
Am 19.12.2013 15:33, schrieb Francesco Cattoglio:
On Thursday, 19 December 2013 at 12:10:28 UTC, Daniel Murphy
wrote:
Lots and lots and lots and lots.
I wish I could help, but I really know _nothing_ about
compilers.
If you
Am 19.12.2013 15:33, schrieb Francesco Cattoglio:
On Thursday, 19 December 2013 at 12:10:28 UTC, Daniel Murphy wrote:
Lots and lots and lots and lots.
I wish I could help, but I really know _nothing_ about compilers.
If you feel like learning about them, Compiler Construction from Niklaus
W
On 2013-12-19 15:33, Francesco Cattoglio wrote:
On Thursday, 19 December 2013 at 12:10:28 UTC, Daniel Murphy wrote:
Lots and lots and lots and lots.
I wish I could help, but I really know _nothing_ about compilers.
That hasn't stopped me, for the small contributions I've made :)
--
/Jacob C
On Thursday, 19 December 2013 at 12:10:28 UTC, Daniel Murphy
wrote:
Lots and lots and lots and lots.
I wish I could help, but I really know _nothing_ about compilers.
Russel Winder:
The whole point of Go is to replace C,
I didn't know this.
Bye,
bearophile
"Francesco Cattoglio" wrote in message
news:msurcjlmbxmbxpmrg...@forum.dlang.org...
> On Thursday, 19 December 2013 at 11:42:34 UTC, Ola Fosheim Grøstad wrote:
>> I'd say it will be much more tempting to dabbel with it if it is in D.
>> I'd even say it will be difficult not to! :)
>
> Couldn't a
On Thursday, 19 December 2013 at 11:42:34 UTC, Ola Fosheim
Grøstad wrote:
I'd say it will be much more tempting to dabbel with it if it
is in D. I'd even say it will be difficult not to! :)
Couldn't agree more: I've been reading some sources of Phobos.
When compared to C++ standard library, it'
On Thursday, 19 December 2013 at 11:31:10 UTC, Russel Winder
wrote:
On Thu, 2013-12-19 at 12:23 +0100, bearophile wrote:
[…]
Moving their Go compiler from C to Go seems a good idea, for
the reasons they have listed. But moving all their other tools
from C to Go seems a little too much.
I thin
On Thursday, 19 December 2013 at 08:56:45 UTC, Daniel Murphy
wrote:
I think we're about two releases away (in terms of remaining
work) from
being able to ship ddmd on all supported platforms, and one
more from
switching over to D completely.
That's really cool! D is IMO a better fit for that
On Thu, 2013-12-19 at 12:23 +0100, bearophile wrote:
[…]
> Moving their Go compiler from C to Go seems a good idea, for the
> reasons they have listed. But moving all their other tools from C
> to Go seems a little too much.
I think not. The whole point of Go is to replace C, so it is right to
r
Paulo Pinto:
I find it very positive. I follow Wirth's school of thought that
bootstraping is always the best option, after you get a minimal
language compiling.
Moving their Go compiler from C to Go seems a good idea, for the
reasons they have listed. But moving all their other tools from C
"Andrei Alexandrescu" wrote in message
news:l8udt4$1rqf$1...@digitalmars.com...
> On 12/19/13 12:56 AM, Daniel Murphy wrote:
>> https://github.com/D-Programming-Language/dmd/pull/2754
>
> I will intervene there. All, prepare for destruction.
>
> Andrei
>
That would be great. I would very much l
On Thursday, 19 December 2013 at 08:56:45 UTC, Daniel Murphy
wrote:
"Paulo Pinto" wrote in message
Actually how is the effort of porting dmd to D going, any idea
when we could start playing with it?
It's going quite well. The D version passes the full test
suite on win32,
and can compile
On Thursday, 19 December 2013 at 09:25:12 UTC, Iain Buclaw wrote:
On 19 December 2013 06:58, Ziad Hatahet
wrote:
https://docs.google.com/document/d/1P3BLR31VA8cvLJLfMibSuTdwTuF7WWLux71CYD0eeD8/preview?sle=true&pli=1
Obviously not talking about gccgo (which is written in C++, not
C -
unles
On 12/19/13 12:56 AM, Daniel Murphy wrote:
https://github.com/D-Programming-Language/dmd/pull/2754
I will intervene there. All, prepare for destruction.
Andrei
On 19 December 2013 06:58, Ziad Hatahet wrote:
> https://docs.google.com/document/d/1P3BLR31VA8cvLJLfMibSuTdwTuF7WWLux71CYD0eeD8/preview?sle=true&pli=1
>
>
Obviously not talking about gccgo (which is written in C++, not C -
unless the author doesn't know the difference).
"Paulo Pinto" wrote in message
>
> Actually how is the effort of porting dmd to D going, any idea
> when we could start playing with it?
>
It's going quite well. The D version passes the full test suite on win32,
and can compile itself on linux64, as of this week.
There are some instructions h
On Thursday, 19 December 2013 at 07:26:58 UTC, Ziad Hatahet wrote:
https://docs.google.com/document/d/1P3BLR31VA8cvLJLfMibSuTdwTuF7WWLux71CYD0eeD8/preview?sle=true&pli=1
I find it very positive. I follow Wirth's school of thought that
bootstraping is always the best option, after you get a mini
https://docs.google.com/document/d/1P3BLR31VA8cvLJLfMibSuTdwTuF7WWLux71CYD0eeD8/preview?sle=true&pli=1
66 matches
Mail list logo
