Re: GHC 2013 in Paris

2013-08-24 Thread monarch_dodra

On Friday, 23 August 2013 at 16:31:17 UTC, Iain Buclaw wrote:
I've jsut been told there's no reception on Saturdays, so after 
9.00am
might be a slight problem, but I think they will leave a number 
for

you to call.

I *could* excuse myself to let you in, but that would require 
relying

on me to remember what time you are arriving. :o)


Hum... The forum was down yesterday, so I couldn't post this any 
earlier.


I actually only intend to see your talk, so I won't be there 
before 16:00. I'll be at the gates *before* 15:30, and see if/how 
I can get it from there.


FWI, I'll be the guy who walks with a crutch.

I don't if anyone will be seeing this today, but if you don't see 
me in the building by 15:50, then it means I failed to get in, 
and am waiting outside...


Re: GHC 2013 in Paris

2013-08-24 Thread Iain Buclaw
On 24 August 2013 09:42, monarch_dodra monarchdo...@gmail.com wrote:
 On Friday, 23 August 2013 at 16:31:17 UTC, Iain Buclaw wrote:

 I've jsut been told there's no reception on Saturdays, so after 9.00am
 might be a slight problem, but I think they will leave a number for
 you to call.

 I *could* excuse myself to let you in, but that would require relying
 on me to remember what time you are arriving. :o)


 Hum... The forum was down yesterday, so I couldn't post this any earlier.

 I actually only intend to see your talk, so I won't be there before 16:00.
 I'll be at the gates *before* 15:30, and see if/how I can get it from there.

 FWI, I'll be the guy who walks with a crutch.

 I don't if anyone will be seeing this today, but if you don't see me in the
 building by 15:50, then it means I failed to get in, and am waiting
 outside...

I'm feeling a little rough this morning, so am running late (sorry
Eles!) - just having breakfast, and will be down about 10.30...

Regards
-- 
Iain Buclaw

*(p  e ? p++ : p) = (c  0x0f) + '0';


Re: I'm porting some go code to D

2013-08-24 Thread Rory McGuire
On 24 Aug 2013 03:15, Jesse Phillips jesse.k.phillip...@gmail.com wrote:

 On Friday, 23 August 2013 at 23:54:55 UTC, Rory McGuire wrote:

 So I'm porting so #golang code to #dlang and there is all these blasted
 go statements.So I thought I'd give implmenting it in D a shot. What do
 you guys think?
 Fire away :).


 I'd suggest posting long snippets of code to https://gist.github.com/ or
http://dpaste.dzfl.pl/

 A couple lines is fine but whole implementations, definitely want a more
color friendly solution.

Good point.


Re: I'm porting some go code to D

2013-08-24 Thread David
Daemonic Threads often end with a segfault, so if your main thread
exists, the other threads will probably segfault.


Re: I'm porting some go code to D

2013-08-24 Thread Rory McGuire
On 24 Aug 2013 11:00, David d...@dav1d.de wrote:

 Daemonic Threads often end with a segfault, so if your main thread
 exists, the other threads will probably segfault.

Thanks, I wonder what they're accessing that they shouldn't.


Re: I'm porting some go code to D

2013-08-24 Thread Moritz Maxeiner

On Friday, 23 August 2013 at 23:54:55 UTC, Rory McGuire wrote:
So I'm porting so #golang code to #dlang and there is all these 
blasted
go statements.So I thought I'd give implmenting it in D a 
shot. What do

you guys think?
Fire away :).

/**
 * chan allows messaging between threads without having to deal 
with locks,

similar to how chan works in golang
 */
class chan_(T) {
shared Mutex lock;
struct Container(T) {
T value;
Container!T* next;


I'm probably missunderstanding somehting about the TLS model, but 
from what I know, for something like this, shouldn't you make the 
class instance itself go into shared storage instead instead of 
all the members?




Re: I'm porting some go code to D

2013-08-24 Thread David Nadlinger

On Friday, 23 August 2013 at 23:54:55 UTC, Rory McGuire wrote:
So I'm porting so #golang code to #dlang and there is all these 
blasted
go statements.So I thought I'd give implmenting it in D a 
shot. What do you guys think?


It's a cute idea, but not really practical, I'm afraid – 
Goroutines are managed by a scheduler in the Go runtime library, 
whereas D threads directly map to OS threads. Thus, if the Go 
application you are porting uses many Goroutines (and the Go code 
I've seen usually does so very liberally), the performance of the 
D equivalent is going to be horrible.


David


Re: I'm porting some go code to D

2013-08-24 Thread bearophile

David Nadlinger:

It's a cute idea, but not really practical, I'm afraid – 
Goroutines are managed by a scheduler in the Go runtime 
library, whereas D threads directly map to OS threads.


Can't Rory McGuire add a scheduler to his code? How much code 
does it take?


Bye,
bearophile


Re: I'm porting some go code to D

2013-08-24 Thread Rory McGuire
On 24 Aug 2013 11:25, Moritz Maxeiner mor...@ucworks.org wrote:

 On Friday, 23 August 2013 at 23:54:55 UTC, Rory McGuire wrote:

 So I'm porting so #golang code to #dlang and there is all these blasted
 go statements.So I thought I'd give implmenting it in D a shot. What do
 you guys think?
 Fire away :).

 /**
  * chan allows messaging between threads without having to deal with
locks,
 similar to how chan works in golang
  */
 class chan_(T) {
 shared Mutex lock;
 struct Container(T) {
 T value;
 Container!T* next;


 I'm probably missunderstanding somehting about the TLS model, but from
what I know, for something like this, shouldn't you make the class instance
itself go into shared storage instead instead of all the members?

I have no idea if shared on the class makes all it's parts shared.
It was a struct but I had problems with passing it to the spawn func when I
was using std.concurrent .

I'm trying to port a cassandra cql library from go so it's really just to
help with that.

I'm having a hard time imagining how to implement select from go. Could
probably use std.concurrent.receive because that can handle multiple types
at once.

Sorry I'm rambling...


Re: SIMD implementation of dot-product. Benchmarks

2013-08-24 Thread Ilya Yaroshenko

On Sunday, 18 August 2013 at 05:26:00 UTC, Manu wrote:
movups is not good. It'll be a lot faster (and portable) if you 
use movaps.


Process looks something like:
  * do the first few from a[0] until a's alignment interval as 
scalar

  * load the left of b's aligned pair
  * loop for each aligned vector in a
- load a[n..n+4] aligned
- load the right of b's pair
- combine left~right and shift left to match elements 
against a

- left = right
  * perform stragglers as scalar

Your benchmark is probably misleading too, because I suspect 
you are
passing directly alloc-ed arrays into the function (which are 
16 byte

aligned).
movups will be significantly slower if the pointers supplied 
are not 16

byte aligned.
Also, results vary significantly between chip manufacturers and 
revisions.



I have tried to write fast implementation with aligned loads:
1. I have now idea how to shift (rotate) 32-bytes avx vector 
without XOP instruction set (XOP available only for AMD).
2. I have tried to use one vmovaps and [one vmovups]/[two 
vinsertf128] with 16-bytes aligned arrays (previously iterates 
with a). It works slower then two vmovups (because loop tricks). 
Now I have 300 lines of slow dotProduct code =)

4. Condition for small arrays works good.


I think it is better to use:

1. vmovups if it is available with condition for small arrays
2. version like from phobos if vmovups is not avalible
3. special version for small static size arrays

I think version for static size arrays can be easily done for 
phobos, processors can unroll such code. And dot product 
optimized for complex numbers can be done too.


Best regards

Ilya


Re: I'm porting some go code to D

2013-08-24 Thread Jonas Drewsen

On Saturday, 24 August 2013 at 13:26:32 UTC, bearophile wrote:

David Nadlinger:

It's a cute idea, but not really practical, I'm afraid – 
Goroutines are managed by a scheduler in the Go runtime 
library, whereas D threads directly map to OS threads.


Can't Rory McGuire add a scheduler to his code? How much code 
does it take?


It would be very nice to have a builtin scheduler in the runtime. 
It would make async non-threaded programming so much nicer in D.


/Jonas


Re: I'm porting some go code to D

2013-08-24 Thread Rory McGuire
On Sat, Aug 24, 2013 at 3:26 PM, bearophile bearophileh...@lycos.comwrote:

 David Nadlinger:


  It's a cute idea, but not really practical, I'm afraid – Goroutines are
 managed by a scheduler in the Go runtime library, whereas D threads
 directly map to OS threads.


 Can't Rory McGuire add a scheduler to his code? How much code does it take?

 Bye,
 bearophile


I imagine that it will be fine on Linux because threads truly are
lightweight on Linux, but its not going to be great on windows.

Go's scheduler is basically the same as the way vibe.d works. Fibers. I
haven't tried it but I could use fibers to do the same sort of thing,
though it would be easiest to use in Vibe.d because even in go you have to
do something that will wait/sleep in order to have your program advance
unless you set GOPROCS to  a value greater than 1. Go's scheduler is not
preemptive so there are the equivalent of Fiber.yield() spread throughout
the standard library, I think.

I'm not sure how threads + fibers would have to interact in such a system.


Re: I'm porting some go code to D

2013-08-24 Thread Paulo Pinto

On Saturday, 24 August 2013 at 20:03:58 UTC, Rory McGuire wrote:
On Sat, Aug 24, 2013 at 3:26 PM, bearophile 
bearophileh...@lycos.comwrote:



David Nadlinger:


 It's a cute idea, but not really practical, I'm afraid – 
Goroutines are
managed by a scheduler in the Go runtime library, whereas D 
threads

directly map to OS threads.



Can't Rory McGuire add a scheduler to his code? How much code 
does it take?


Bye,
bearophile



I imagine that it will be fine on Linux because threads truly 
are

lightweight on Linux, but its not going to be great on windows.


Funny, I always thought otherwise, because Windows only has 
threads.


Processes are just a means of grouping threads on Windows, as 
there
isn't the distinction between threads and processes that UNIX 
systems used to make.


Then again, I lost track how the performance on Linux systems 
changed across the whole Processes - LinuxThreads - NPTL - 
Posix Threads evolution.


--
Paulo


Re: GHC 2013 in Paris

2013-08-24 Thread Iain Buclaw
On 24 August 2013 09:48, Iain Buclaw ibuc...@ubuntu.com wrote:
 On 24 August 2013 09:42, monarch_dodra monarchdo...@gmail.com wrote:
 On Friday, 23 August 2013 at 16:31:17 UTC, Iain Buclaw wrote:

 I've jsut been told there's no reception on Saturdays, so after 9.00am
 might be a slight problem, but I think they will leave a number for
 you to call.

 I *could* excuse myself to let you in, but that would require relying
 on me to remember what time you are arriving. :o)


 Hum... The forum was down yesterday, so I couldn't post this any earlier.

 I actually only intend to see your talk, so I won't be there before 16:00.
 I'll be at the gates *before* 15:30, and see if/how I can get it from there.

 FWI, I'll be the guy who walks with a crutch.

 I don't if anyone will be seeing this today, but if you don't see me in the
 building by 15:50, then it means I failed to get in, and am waiting
 outside...

 I'm feeling a little rough this morning, so am running late (sorry
 Eles!) - just having breakfast, and will be down about 10.30...


Hi Guys,

Thanks for making it down.  Are you going to be around tomorrow?  Feel
free to ping me or message me and we'll arrange something. :o)

Will be at the IRIS building at 9.00am (this time I will be present at
that time).  And will be staying in Paris until around 2.00pm, which
is when I have to check in for train back to London.


Regards
-- 
Iain Buclaw

*(p  e ? p++ : p) = (c  0x0f) + '0';