from:"luminousone"


On Friday, 11 October 2013 at 09:37:33 UTC, Jacob Carlborg wrote:

On 2013-10-11 07:49, luminousone wrote:


import std.traits;

bool ChildInheritsFromParent( parent, child )( ) {

foreach ( k, t; BaseClassesTuple!child ) {
if( typeid(t) == typeid(parent) )
return true;
}
return false;
}


That will perform a runtime check and not a compile time check.


Is is just the typeid call that makes it unable to be ran at 
compile time or is their something else wrong in their?,


Would a string compare with type.classInfo.name fix that, or is 
their not a tool yet in place for that?

Re: Traits


On Friday, 11 October 2013 at 14:09:09 UTC, Gary Willoughby wrote:

On Friday, 11 October 2013 at 05:49:38 UTC, luminousone wrote:

On Friday, 11 October 2013 at 04:13:55 UTC, Agustin wrote:
I have a function that needs to check if the template 
provided inherit a class.


For example:

public void function(T, A...)(auto ref A values)
{
// static assert(IsBaseOf(L, T));
}

Check if T inherit class L. Same result that 
std::is_base_ofL, T::value using C++. Any clean way to do 
it, without a dirty hack.


import std.traits;

bool ChildInheritsFromParent( parent, child )( ) {

foreach ( k, t; BaseClassesTuple!child ) {
if( typeid(t) == typeid(parent) )
return true;
}
return false;
}


A simpler way:

import std.stdio;

bool instanceOf(A, B)(B value)
{
return !!cast(A)value;
}

void main()
{
assert(1.instanceOf!(int));
}


Using casts that way won't always be correct, it would be better 
to use reflection in some way if possible.

Re: Traits

On Friday, 11 October 2013 at 19:54:39 UTC, Jonathan M Davis 
wrote:

On Friday, October 11, 2013 21:19:29 luminousone wrote:
Using casts that way won't always be correct, it would be 
better

to use reflection in some way if possible.


The only reason that the casts wouldn't be correct would be if 
the class
overrode opCast for the type that you're casting to or had an 
alias this
declaration for it. Using casting for instanceOf is 
considered the standard
and correct way to do it. But if you're being paranoid about 
the possibility
of a conversion being defined with opCast or alias this, then 
yes, you need to

use typeid.

- Jonathan M Davis


import std.stdio;

bool instanceOf(A, B)(B value) {
return !!cast(A)value;
}

class e {
}

class f : e {

}

class g {

}


void main() {
int a;
float b;
char c;

e E;
f F;
g G;

assert( 1.instanceOf!int, 1);
assert( a.instanceOf!int, a); // fails here ?!?
assert( b.instanceOf!int, b);
assert( c.instanceOf!int, c);

assert( E.instanceOf!e  , e); // fails here !??
assert( F.instanceOf!e  , f);
assert( G.instanceOf!e  , g); // fails as expected
}


Seems to be problems, at least with quick testing using rdmd. 
Using casts seems terribly hackish, I would think that some sort 
of reflection should be much safer/correct way todo this.

Re: Traits

On Friday, 11 October 2013 at 21:49:50 UTC, Jonathan M Davis 
wrote:

On Friday, October 11, 2013 23:06:53 luminousone wrote:

On Friday, 11 October 2013 at 19:54:39 UTC, Jonathan M Davis

wrote:
 On Friday, October 11, 2013 21:19:29 luminousone wrote:
 Using casts that way won't always be correct, it would be
 better
 to use reflection in some way if possible.
 
 The only reason that the casts wouldn't be correct would be 
 if

 the class
 overrode opCast for the type that you're casting to or had an
 alias this
 declaration for it. Using casting for instanceOf is
 considered the standard
 and correct way to do it. But if you're being paranoid about
 the possibility
 of a conversion being defined with opCast or alias this, then
 yes, you need to
 use typeid.
 
 - Jonathan M Davis


import std.stdio;

bool instanceOf(A, B)(B value) {
return !!cast(A)value;
}

class e {
}

class f : e {

}

class g {

}


void main() {
int a;
float b;
char c;

e E;
f F;
g G;

assert( 1.instanceOf!int, 1);
assert( a.instanceOf!int, a); // fails here ?!?
assert( b.instanceOf!int, b);
assert( c.instanceOf!int, c);

assert( E.instanceOf!e , e); // fails here !??
assert( F.instanceOf!e , f);
assert( G.instanceOf!e , g); // fails as expected
}


Seems to be problems, at least with quick testing using rdmd.
Using casts seems terribly hackish, I would think that some 
sort

of reflection should be much safer/correct way todo this.


Two things:

1. Casting to determine the type of a variable only makes sense 
with classes.
The idea is that casting a reference to a particular class will 
result in null
if the cast fails. That doesn't work at all with types that 
aren't classes.


2. All of your objects are null. Of course the cast is going to 
fail. You need
to be operating on actual instances. The whole point of casting 
is to check
the actual type of an object at runtime. It's a completely 
different use case
from using compile-time reflection on two types to see whether 
one is a base
class of the other. And usually all that's done for that is to 
see whether one
implicitly converts to the other, which is(DerivedClass : 
BaseClass) will do
for you. The only reason to use compile-time reflection is if 
you're want to
make sure that DerivedClass doesn't implicitly convert to 
BaseClass via alias
this instead of by actually being a class derived from 
BaseClass.


I'd also change the implementation of instanceOf to something 
like


bool instanceOf(A, B)(B value)
 if(is(A == class)  is(B == class))
{
 return cast(A)value !is null;
}

since it doesn't rely on the conversion to bool that ! does and 
is more

explicit that way, but the other version will work.

- Jonathan M Davis


The inability to handle null is pretty big, specially considering 
that at not point is the class instance itself cared about!, 
Again this should be done via reflection, this method above is 
hackish at best.


perhaps,

bool instanceOf(A, B)( )
   if( is( A == class )  is( B == class ) ) {
   if( __traits( isSame, A, B ) )
  return true;
   foreach( k, v ; BaseClassesTuple!A ) {
  if( __traits(isSame, B, v ) )
 return true;
   }
   return false;
}

Re: Traits

2013-10-10 Thread luminousone


On Friday, 11 October 2013 at 04:13:55 UTC, Agustin wrote:
I have a function that needs to check if the template provided 
inherit a class.


For example:

public void function(T, A...)(auto ref A values)
{
  // static assert(IsBaseOf(L, T));
}

Check if T inherit class L. Same result that 
std::is_base_ofL, T::value using C++. Any clean way to do it, 
without a dirty hack.


import std.traits;

bool ChildInheritsFromParent( parent, child )( ) {

foreach ( k, t; BaseClassesTuple!child ) {
if( typeid(t) == typeid(parent) )
return true;
}
return false;
}

Re: Huge pages and druntime parameters

2013-09-26 Thread luminousone


On Friday, 27 September 2013 at 00:31:23 UTC, Martin Nowak wrote:
Running dmd with huge page backed malloc resulted in about 10% 
faster compilations.
This looks very promising though other tests with some D GC 
microbenchmarks did not benefit from huge pages.

You can read more about this here.
http://www.ibm.com/developerworks/systems/library/es-lop-leveragepages/

I'm interested in adding a runtime parameter that would advise 
the GC to preferably use huge pages as backing memory.
There are a number of other interesting runtime parameters, 
like max heap size, GC grow policies, turning on statistics, so 
I wonders how to make them available.
Java seems to use -XX:+UseLargePages and -Xmx for the maximum 
heap size.
GHC uses a nice scheme where runtime parameters passed via 
command line are embraced by +RTS arg1 arg2 -RTS. They also 
require to link-in support for this.

http://www.haskell.org/ghc/docs/7.0.1/html/users_guide/runtime-control.html
Any good ideas for druntime?


I have played around with huge pages a bit, my understanding from 
reading about them, and use(ROAM diamond tree nodes in huge page 
memory), is that they need to be used carefully, many processors 
only have a small number of entries for huge pages in their 
lookup tables.


The best use of huge pages seems to be from code built around 
them, not sure if it entirely makes sense to put them in gc,

Re: dub: should we make it the de jure package manager for D?

2013-09-10 Thread luminousone

On Tuesday, 10 September 2013 at 20:48:58 UTC, Andrei 
Alexandrescu wrote:
We've been experimenting with http://code.dlang.org for a while 
and things are going well. In particular Sönke has been very 
active about maintaining and improving it, which brings further 
confidence in the future of the project.


We're considering making dub the official package manager for 
D. What do you all think?



Andrei


Not big on package repository systems for languages, The amount
of crap that eventually accumulates from abandoned projects wears
down on its usefulness.

Examples being php-pear, php-pecl, python pypi, etc I am sure
their are more examples.

Mostly however it comes down to strong policy about what stays in
the main package management system.

Projects that haven't had an update for an excessive amount of
time should likely be hidden but still available except in cases
where it is known to be unchanged without need for updates(such
as most wrappers).

And license acknowledgement, this is much more important with
source libraries then it is with say apt on Ubuntu.  Accidentally
polluting a bsd project or a closed source project with LGPL/GPL
code would be very bad, And often these package management
systems obscure what the sources license actually is by simply
not showing it or informing the user.

Basically I suggest that after one year without an update a
package gets moved into a old packages list, or flagged as
hidden, Except where the author sets a flag that says the package
is a wrapper.

And when packages are fetched give a summary of the licenses
used, the license name should be enough, google can fill in the
rest if need be.

Re: dub: should we make it the de jure package manager for D?

2013-09-10 Thread luminousone

On Wednesday, 11 September 2013 at 00:18:27 UTC, Martin Nowak 
wrote:

On 09/10/2013 10:48 PM, Andrei Alexandrescu wrote:
We've been experimenting with http://code.dlang.org for a 
while and
things are going well. In particular Sönke has been very 
active about
maintaining and improving it, which brings further confidence 
in the

future of the project.

We're considering making dub the official package manager for 
D. What do

you all think?


Andrei


I think the package format is really good.
The registry is essential but needs to support categories, 
searching and some sort of quality ranking (voting?) for future 
grow.

Dub itself works but is still somewhat raw.

So I am for making dub's package format and the registry the 
official place for packages and supporting dub as the primary 
package manager.


Old, python proverb, I found 10 packages in the repo but all 11
of them are broken, or conflict with another package I am using!

Re: dub: should we make it the de jure package manager for D?

2013-09-10 Thread luminousone

On Wednesday, 11 September 2013 at 04:06:18 UTC, Jason den Dulk 
wrote:
On Tuesday, 10 September 2013 at 20:48:58 UTC, Andrei 
Alexandrescu wrote:


We're considering making dub the official package manager for 
D. What do you all think?


I think it is a good idea. Having a broad library available for 
developers to use is a big boost to productivity.


However, I agree with luminousone that there need to be some 
rules about inclusion in the registry. Here are my ideas.


1) Must be legal.
2) Must be release usable.
3) Always has an active caretaker.
4) Must compile and run with a reasonably recent version of 
the official compiler.

5) Have a clear  precise descrption of what it does.
6) Have proper licensing.


On number 4, I will point out that Derelicts opengl wrapper 
defines several win32 api structs and functions that are also in 
core.sys.windows.windows. Leaving me in the position of having to 
maintain a change set to the wrapper in order or use it.


Don't get me wrong I love derelict, Aldacron has done one hell of 
a job with it. And this complaint may have more todo with the 
somewhat ambiguous status that the windowsapi wrapper and 
core.sys.windows.windows and very simply what import has what 
function or struct declaration, and the conflicts arising from 
multiple definitions etc.


 And I get it that the wrapper is more designed to work with 
derelicts sdl or sfml wrappers, But this is a point that should 
be brought up, their does exist libraries that will break when 
used with the standard library.


I believe this would apply to point 2 and 4.

Maybe we need to define some package names that are reserved for 
particular purposes, such as std, or core, or etc/etc.c/ etc... 
Atleast within the context of the package manager so that 
multiple packages don't use the same module name(unless of course 
this is done intentionally for some useful purpose).

Re: improve concurrent queue

2013-08-27 Thread luminousone


On Tuesday, 27 August 2013 at 17:35:13 UTC, qznc wrote:

On Monday, 26 August 2013 at 19:35:28 UTC, luminousone wrote:
I have been working on a project and needed a good concurrent 
queue


What does good mean? Concurrent queues have so many design 
parameters (single reader? single writer? blocking? bounded? 
etc) and there is no queue, which performs optimal for every 
case.


Generally, multiple writers and a single reader, but multiple 
writers and multiple readers may also occur.



I can recommand this paper (paywalled though):
http://dl.acm.org/citation.cfm?id=248106

Nevertheless, I believe you rather wanted some comments on your 
specific code. I wonder why you implemented spinlocks yourself? 
If you write a blocking algorithm, you should probably use the 
phobos locks.


I was under the impression that the atomic spinlock has a lower 
latency for any waiters, then a mutex when its unlocked?


I am using this for a temporary or depending on performance, a 
perminate replacement for std.concurrency send/receive until such 
time as bugs in std.variant are fixed.


I have a thread with an opengl context, and I am using the queue 
to send messages to this thread containing interface Drawable 
objects, that have any needed preprocessing on them done such 
that only opengl calls have to be made to the video card to 
render it.

improve concurrent queue

2013-08-26 Thread luminousone

I have been working on a project and needed a good concurrent 
queue, so I wrote one, is their anyone more familiar with the 
atomic arts that could tell me if their is anyway i can further 
improve it.


module container.concurrentqueue;

import std.typetuple;
import core.atomic;

class ConcurrentQueue( items...  ) {

align(64) class nodeType {
align(1):
		this( ) { atomicStore( this.next, cast(shared nodeType) null ); 
}

this( TypeTuple!items value ) {
foreach( k, v ; value ) {
this.value[k] = v;
}
this();
}

TypeTuple!items value;
shared nodeType next;
}

class ConsumerResult {
TypeTuple!items value;

alias value this;
}

public this() {
shared nodeType temp = cast(shared)new nodeType( );

atomicStore( first, temp );
atomicStore( last , temp );
atomicStore( producerLock, false );
atomicStore( consumerLock, false );
}   

public void Produce( items item ) {

TypeTuple!items t = item;
shared nodeType temp = cast(shared)new nodeType ( t );

while( !cas(producerLock, false, true ) ) { }

atomicStore( last.next   , temp );
atomicStore( last, temp );
atomicStore( producerLock, false );
}

public ConsumerResult Consume( ) {
while( !cas(consumerLock, false, true ) ) { }

shared nodeType temp = cast(shared)atomicLoad( first );
shared nodeType next = cast(shared)atomicLoad( temp.next );

ConsumerResult result = new ConsumerResult();

if( next !is null ) {
foreach( k, v ; items ) {
result[k] = cast(v)next.value[k];
}
first = next;
atomicStore( consumerLock, false );
return result;
}
atomicStore( consumerLock, false );
return null;
}

private shared nodeType first;

private byte padd1[64];

private shared nodeType last;

private byte padd2[64];

private shared bool consumerLock;

private byte padd3[64];

private shared bool producerLock;
}

Re: Allocators

2013-08-24 Thread luminousone


On Saturday, 24 August 2013 at 22:41:54 UTC, Kapps wrote:
On Saturday, 24 August 2013 at 21:53:47 UTC, Andrej Mitrovic 
wrote:

On 8/24/13, Namespace rswhi...@googlemail.com wrote:

What about the probable change of virtual by default - final
by default?


Btw, can someone find the link to the forum thread where the 
last

discussion of this took place? I remember Walter agreeing to
something, but can't recall anymore.


It seemed like eventually Walter supported virtual by default, 
but nothing came of it. For some reason I can't find the thread 
anymore with Google.


Pretty sure Walter supported final by default, he even laid out a 
transition plan as I recall. Seems like Manu was involved, so 
asking him might bear fruit on that question.

Re: GPGPUs


On Sunday, 18 August 2013 at 05:05:48 UTC, Atash wrote:

On Sunday, 18 August 2013 at 03:55:58 UTC, luminousone wrote:
You do have limited Atomics, but you don't really have any 
sort of complex messages, or anything like that.


I said 'point 11', not 'point 10'. You also dodged points 1 and 
3...


Intel doesn't have a dog in this race, so their is no way to 
know what they plan on doing if anything at all.


http://software.intel.com/en-us/vcsource/tools/opencl-sdk
http://www.intel.com/content/www/us/en/processors/xeon/xeon-phi-detail.html

Just based on those, I'm pretty certain they 'have a dog in 
this race'. The dog happens to be running with MPI and OpenCL 
across a bridge made of PCIe.


The Xeon Phi is interesting in so far as taking generic 
programming to a more parallel environment. However it has some 
serious limitations that will heavily damage its potential 
performance.


AVX2 is completely the wrong path to go about improving 
performance in parallel computing, The SIMD nature of this 
instruction set means that scalar operations, or even just not 
being able to fill the giant 256/512bit register wastes huge 
chunks of this things peak theoretical performance, and if any 
rules apply to instruction pairing on this multi issue pipeline 
you have yet more potential for wasted cycles.


I haven't seen anything about intels, micro thread scheduler, or 
how these chips handle mass context switching natural of micro 
threaded environments, These two items make a huge difference in 
performance, comparing radeon VLIW5/4 to radeon GCN is a good 
example, most of the performance benefit of GCN is from easy of 
scheduling scalar pipelines over more complex pipes with 
instruction pairing rules etc.


Frankly Intel, has some cool stuff, but they have been caught 
with their pants down, they have depended on their large fab 
advantage to carry them over and got lazy.


We likely are watching AMD64 all over again.

The reason to point out HSA, is because it is really easy add 
support for, it is not a giant task like opencl would be. A 
few changes to the front end compiler is all that is needed, 
LLVM's backend does the rest.


H'okay. I can accept that.

OpenCL isn't just a library, it is a language extension, that 
is ran through a preprocessor that compiles the embedded 
__KERNEL and __DEVICE functions, into usable code, and then 
outputs .c/.cpp files for the c compiler to deal with.


But all those extra bits are part of the computing 
*environment*. Is there something wrong with requiring the 
proper environment for an executable?


A more objective question: which devices are you trying to 
target here?


A first, simply a different way of approaching std.parallel like 
functionality, with an eye gpgpu in the future when easy 
integration solutions popup(such as HSA).


Those are all platform specific, they change based on the whim 
and fancy of NVIDIA and AMD with each and every new chip 
released, The size and configuration of CUDA clusters, or 
compute clusters, or EU's, or whatever the hell x chip maker 
feels like using at the moment.


Long term this will all be managed by the underlying support 
software in the video drivers, and operating system kernel. 
Putting any effort into this is a waste of time.


Yes. And the only way to optimize around them is to *know 
them*, otherwise you're pinning the developer down the same way 
OpenMP does. Actually, even worse than the way OpenMP does - at 
least OpenMP lets you set some hints about how many threads you 
want.


It would be best to wait for a more generic software platform, to 
find out how this is handled by the next generation of micro 
threading tools.


The way openCL/CUDA work reminds me to much of someone setting up 
tomcat to have java code generate php that runs on their apache 
server, just because they can. I would rather tighter integration 
with the core language, then having a language in language.



void example( aggregate in float a[] ; key , in float b[], out
  float c[]) {
c[key] = a[key] + b[key];
}

example(a,b,c);

in the function declaration you can think of the aggregate 
basically having the reserve order of the items in a foreach 
statement.


int a[100] = [ ... ];
int b[100];
foreach( v, k ; a ) { b = a[k]; }

int a[100] = [ ... ];
int b[100];

void example2( aggregate in float A[] ; k, out float B[] ) { 
B[k] = A[k]; }


example2(a,b);


Contextually solid. Read my response to the next bit.

I am pretty sure they are simply multiplying the index value 
by the unit size they desire to work on


int a[100] = [ ... ];
int b[100];
void example3( aggregate in range r ; k, in float a[], float 
b[]){

  b[k]   = a[k];
  b[k+1] = a[k+1];
}

example3( 0 .. 50 , a,b);

Then likely they are simply executing multiple __KERNEL 
functions in sequence, would be my guess.


I've implemented this algorithm before in OpenCL already, and 
what you're saying so far doesn't rhyme with what's needed.


There are at least

Re: GPGPUs


On Sunday, 18 August 2013 at 07:28:02 UTC, Atash wrote:

On Sunday, 18 August 2013 at 06:22:30 UTC, luminousone wrote:
The Xeon Phi is interesting in so far as taking generic 
programming to a more parallel environment. However it has 
some serious limitations that will heavily damage its 
potential performance.


AVX2 is completely the wrong path to go about improving 
performance in parallel computing, The SIMD nature of this 
instruction set means that scalar operations, or even just not 
being able to fill the giant 256/512bit register wastes huge 
chunks of this things peak theoretical performance, and if any 
rules apply to instruction pairing on this multi issue 
pipeline you have yet more potential for wasted cycles.


I haven't seen anything about intels, micro thread scheduler, 
or how these chips handle mass context switching natural of 
micro threaded environments, These two items make a huge 
difference in performance, comparing radeon VLIW5/4 to radeon 
GCN is a good example, most of the performance benefit of GCN 
is from easy of scheduling scalar pipelines over more complex 
pipes with instruction pairing rules etc.


Frankly Intel, has some cool stuff, but they have been caught 
with their pants down, they have depended on their large fab 
advantage to carry them over and got lazy.


We likely are watching AMD64 all over again.


Well, I can't argue that one.

A first, simply a different way of approaching std.parallel 
like functionality, with an eye gpgpu in the future when easy 
integration solutions popup(such as HSA).


I can't argue with that either.

It would be best to wait for a more generic software platform, 
to find out how this is handled by the next generation of 
micro threading tools.


The way openCL/CUDA work reminds me to much of someone setting 
up tomcat to have java code generate php that runs on their 
apache server, just because they can. I would rather tighter 
integration with the core language, then having a language in 
language.


Fair point. I have my own share of idyllic wants, so I can't 
argue with those.


Low level optimization is a wonderful thing, But I almost 
wonder if this will always be something where in order todo 
the low level optimization you will be using the vendors 
provided platform for doing it, as no generic tool will be 
able to match the custom one.


But OpenCL is by no means a 'custom tool'. CUDA, maybe, but 
OpenCL just doesn't fit the bill in my opinion. I can see it 
being possible in the future that it'd be considered 
'low-level', but it's a fairly generic solution. A little 
hackneyed under your earlier metaphors, but still a generic, 
standard solution.


I can agree with that.

Most of my interaction with the gpu is via shader programs for 
Opengl, I have only lightly used CUDA for some image 
processing software, So I am certainly not the one to give in 
depth detail to optimization strategies.


There was a *lot* of stuff that opened up when vendors dumped 
GPGPU out of Pandora's box. If you want to get a feel for some 
optimization strategies and what they require, check this site 
out: http://www.bealto.com/gpu-sorting_intro.html (and I hope 
I'm not insulting your intelligence here, if I am, I truly 
apologize).


I am still learning and additional links to go over never hurt!, 
I am of the opinion that a good programmers has never finished 
learning new stuff.



sorry on point 1, that was a typo, I meant

1. The range must be known prior to execution of a gpu code 
block.


as for

3. Code blocks can only receive a single range, it can however 
be multidimensional


int a[100] = [ ... ];
int b[100];
void example3( aggregate in range r ; k, in float a[], float
 b[]){
 b[k]   = a[k];
}
example3( 0 .. 100 , a,b);

This function would be executed 100 times.

int a[10_000] = [ ... ];
int b[10_000];
void example3( aggregate in range r ; kx,aggregate in range r2 
; ky, in float a[], float

 b[]){
 b[kx+(ky*100)]   = a[kx+(ky*100)];
}
example3( 0 .. 100 , 0 .. 100 , a,b);

this function would be executed 10,000 times. the two 
aggregate ranges being treated as a single 2 dimensional range.


Maybe a better description of the rule would be that multiple 
ranges are multiplicative, and functionally operate as a 
single range.


OH.

I think I was totally misunderstanding you earlier. The 
'aggregate' is the range over the *problem space*, not the 
values being punched into the problem. Is this true or false?


(if true I'm about to feel incredibly sheepish)


Is problem space the correct industry term, I am self taught on 
much of this, so I on occasion I miss out on what the correct 
terminology for something is.


But yes that is what i meant.

Re: GPGPUs

I chose the term aggregate, because it is the term used in the 
description of the foreach syntax.


foreach( value, key ; aggregate )

aggregate being an array or range, it seems to fit as even when 
the aggregate is an array, as you still implicitly have a range 
being 0 .. array.length, and will have a key or index position 
created by the foreach in addition to the value.


A wrapped function could very easily be similar to the intended 
initial outcome


void example( ref float a[], float b[], float c[] ) {

   foreach( v, k ; a ) {
  a[k] = b[k] + c[k];
   }
}

is functionally the same as

void example( aggregate ref float a[] ; k, float b[], float c[] ) 
{

   a[k] = b[k] + c[k];
}

maybe : would make more sense then ; but I am not sure as to the 
best way to represent that index value.

Re: GPGPU and D


On Sunday, 18 August 2013 at 08:40:33 UTC, Russel Winder wrote:

Luminousone, Atash, John,

Thanks for the email exchanges on this, there is a lot of good 
stuff in
there that needs to be extracted from the mail threads and 
turned into a
manifesto type document that can be used to drive getting a 
design and
realization together. The question is what infrastructure would 
work for
us to collaborate. Perhaps create a GitHub group and a 
repository to act

as a shared filestore?

I can certainly do that bit of admin and then try and start a 
document
summarizing the email threads so far, if that is a good way 
forward on

this.


Github seems fine to me, my coding skills are likely more limited 
then Atash or John; I am currently working as a student 
programmer at Utah's Weber State University while also attending 
as a part time student, I am currently working on finishing the 
last couple credit hours of the assoc degree in CS, I would like 
to work towards a higher level degree or even eventually a Phd in 
CS.


I will help in whatever way I can however.

Re: GPGPUs


On Saturday, 17 August 2013 at 06:09:53 UTC, Atash wrote:

On Saturday, 17 August 2013 at 00:53:39 UTC, luminousone wrote:

You can't mix cpu and gpu code, they must be separate.


H'okay, let's be clear here. When you say 'mix CPU and GPU 
code', you mean you can't mix them physically in the compiled 
executable for all currently extant cases. They aren't the 
same. I agree with that.


That said, this doesn't preclude having CUDA-like behavior 
where small functions could be written that don't violate the 
constraints of GPU code and simultaneously has semantics that 
could be executed on the CPU, and where such small functions 
are then allowed to be called from both CPU and GPU code.


However this still has problems of the cpu having to generate 
CPU code from the contents of gpu{} code blocks, as the GPU is 
unable to allocate memory, so for example ,


gpu{
   auto resultGPU = dot(c, cGPU);
}

likely either won't work, or generates an array allocation in 
cpu code before the gpu block is otherwise ran.


I'm fine with an array allocation. I'd 'prolly have to do it 
anyway.


Also how does that dot product function know the correct index 
range to run on?, are we assuming it knows based on the length 
of a?, while the syntax,


c[] = a[] * b[];

is safe for this sort of call, a function is less safe todo 
this with, with function calls the range needs to be told to 
the function, and you would call this function without the 
gpu{} block as the function itself is marked.


auto resultGPU = dot$(0 .. 
returnLesser(cGPU.length,dGPU.length))(cGPU, dGPU);


'Dat's a point.

Remember with gpu's you don't send instructions, you send 
whole programs, and the whole program must finish before you 
can move onto the next cpu instruction.


I disagree with the assumption that the CPU must wait for the 
GPU while the GPU is executing. Perhaps by default the behavior 
could be helpful for sequencing global memory in the GPU with 
CPU operations, but it's not a *necessary* behavior.


Well, I disagree with the assumption assuming said assumption 
is being made and I'm not just misreading that bit. :-P


=== Another thing...

I'm with luminousone's suggestion for some manner of function 
attribute, to the tune of several metric tonnes of chimes. Wind 
chimes. I'm supporting this suggestion with at least a metric 
tonne of wind chimes.


I'd prefer this (and some small number of helpers) rather than 
straight-up dumping a new keyword and block type into the 
language. I really don't think D *needs* to have this any lower 
level than a library based solution, because it already has the 
tools to make it ridiculously more convenient than C/C++ (not 
necessarily as much as CUDA's totally separate program nvcc 
does, but a huge amount).


ex.


@kernel auto myFun(BufferT)(BufferT glbmem)
{
  // brings in the kernel keywords and whatnot depending 
__FUNCTION__

  // (because mixins eval where they're mixed in)
  mixin KernelDefs;
  // ^ and that's just about all the syntactic noise, the rest 
uses mixed-in
  //   keywords and the glbmem object to define several 
expressions that
  //   effectively record the operations to be performed into 
the return type


  // assignment into global memory recovers the expression type 
in the glbmem.

  glbmem[glbid] += 4;

  // This assigns the *expression* glbmem[glbid] to val.
  auto val = glbmem[glbid];

  // Ignoring that this has a data race, this exemplifies 
recapturing the

  // expression 'val' (glbmem[glbid]) in glbmem[glbid+1].
  glbmem[glbid+1] = val;

  return glbmem; /// I lied about the syntactic noise. This is 
the last bit.

}


Now if you want to, you can at runtime create an OpenCL-code 
string (for example) by passing a heavily metaprogrammed type 
in as BufferT. The call ends up looking like this:



auto promisedFutureResult = Gpu.call!myFun(buffer);


The kernel compilation (assuming OpenCL) is memoized, and the 
promisedFutureResult is some asynchronous object that 
implements concurrent programming's future (or something to 
that extent). For convenience, let's say that it blocks on any 
read other than some special poll/checking mechanism.


The constraints imposed on the kernel functions is 
generalizable to even execute the code on the CPU, as the 
launching call ( Gpu.call!myFun(buffer) ) can, instead of using 
an expression-buffer, just pass a normal array in and have the 
proper result pop out given some interaction between the 
identifiers mixed in by KernelDefs and the launching caller 
(ex. using a loop).


Alternatively to returning the captured expressions, the 
argument glbmem could have been passed ref, and the same sort 
of expression capturing could occur. Heck, more arguments 
could've been passed, too, this doesn't require there to be one 
single argument representing global memory.


With CTFE, this method *I think* can also generate the code at 
compile time given the proper kind of 
expression-type-recording-BufferT.


Again, though, all

Re: GPGPUs


On Saturday, 17 August 2013 at 20:17:17 UTC, Atash wrote:

On Saturday, 17 August 2013 at 15:37:58 UTC, deadalnix wrote:
Unified memory have too much benefice for it to be ignored. 
The open questions are about cache coherency, direct 
communication between chips, identical performances through 
the address space, and so on. But the unified memory will 
remains. Even when memory is physically separated, you'll see 
an unified memory model emerge, with disparate performances 
depending on address space.


I'm not saying 'ignore it', I'm saying that it's not the least 
common denominator among popular devices, and that in all 
likelihood it won't be the least common denominator among 
compute devices ever. AMD/ATi being 'right' doesn't mean that 
they'll dominate the whole market. Having two slots on your 
mobo is more limiting than having the ability to just chuck 
more computers in a line hidden behind some thin wrapper around 
some code built to deal with non-uniform memory access.


Additionally, in another post, I tried to demonstrate a way for 
it to target the least common denominator, and in my (obviously 
biased) opinion, it didn't look half bad.


Unlike uniform memory access, non-uniform memory access will 
*always* be a thing. Uniform memory access is cool n'all, but 
it isn't popular enough to be here now, and it isn't like 
non-uniform memory access which has a long history of being 
here and looks like it has a permanent stay in computing.


Pragmatism dictates to me here that any tool we want to be 
'awesome', eliciting 'wowzers' from all the folk of the land, 
should target the widest variety of devices while still being 
pleasant to work with. *That* tells me that it is paramount to 
*not* brush off non-uniform access, and that because 
non-uniform access is the least common denominator, that should 
be what is targeted.


On the other hand, if we want to start up some sort of thing 
where one lib handles the paradigm of uniform memory access in 
as convenient a way as possible, and another lib handles 
non-uniform memory access, that's fine too. Except that the 
first lib really would just be a specialization of the second 
alongside some more 'convenience'-functions.


There are two major things, unified memory, and unified virtual 
address space.


Unified virtual address will be universal within a few years, and 
the user space application will no longer manage the cpu/gpu 
copies anymore, this instead will be handled by the gpu system 
library, hMMU, and operating system.


Even non-uniform memory will be uniform from the perspective of 
the application writer.

Re: GPGPUs


We basically have to follow these rules,

1. The range must be none prior to execution of a gpu code block
2. The range can not be changed during execution of a gpu code 
block
3. Code blocks can only receive a single range, it can however be 
multidimensional

4. index keys used in a code block are immutable
5. Code blocks can only use a single key(the gpu executes many 
instances in parallel each with their own unique key)

6. index's are always an unsigned integer type
7. openCL,CUDA have no access to global state
8. gpu code blocks can not allocate memory
9. gpu code blocks can not call cpu functions
10. atomics tho available on the gpu are many times slower then 
on the cpu
11. separate running instances of the same code block on the gpu 
can not have any interdependency on each other.


Now if we are talking about HSA, or other similar setup, then a 
few of those rules don't apply or become fuzzy.


HSA, does have limited access to global state, HSA can call cpu 
functions that are pure, and of course because in HSA the cpu and 
gpu share the same virtual address space most of memory is open 
for access.


HSA also manages memory, via the hMMU, and their is no need for 
gpu memory management functions, as that is managed by the 
operating system and video card drivers.


Basically, D would either need to opt out of legacy api's such as 
openCL, CUDA, etc, these are mostly tied to c/c++ anyway, and 
generally have ugly as sin syntax; or D would have go the route 
of a full and safe gpu subset of features.


I don't think such a setup can be implemented as simply a 
library, as the GPU needs compiled source.


If D where to implement gpgpu features, I would actually suggest 
starting by simply adding a microthreading function syntax, for 
example...


void example( aggregate in float a[] ; key , in float b[], out 
float c[]) {

c[key] = a[key] + b[key];
}

By adding an aggregate keyword to the function, we can assume the 
range simply using the length of a[] without adding an extra set 
of brackets or something similar.


This would make access to the gpu more generic, and more 
importantly, because llvm will support HSA, removes the needs for 
writing more complex support into dmd as openCL and CUDA would 
require, a few hints for the llvm backend would be enough to 
generate the dual bytecode ELF executables.

Re: GPGPUs


On Sunday, 18 August 2013 at 01:43:33 UTC, Atash wrote:
Unified virtual address-space I can accept, fine. Ignoring that 
it is, in fact, in a totally different address-space where 
memory latency is *entirely different*, I'm far *far* more iffy 
about.



We basically have to follow these rules,

1. The range must be none prior to execution of a gpu code 
block
2. The range can not be changed during execution of a gpu code 
block
3. Code blocks can only receive a single range, it can however 
be multidimensional

4. index keys used in a code block are immutable
5. Code blocks can only use a single key(the gpu executes many 
instances in parallel each with their own unique key)

6. index's are always an unsigned integer type
7. openCL,CUDA have no access to global state
8. gpu code blocks can not allocate memory
9. gpu code blocks can not call cpu functions
10. atomics tho available on the gpu are many times slower 
then on the cpu
11. separate running instances of the same code block on the 
gpu can not have any interdependency on each other.


Please explain point 1 (specifically the use of the word 
'none'), and why you added in point 3?


Additionally, point 11 doesn't make any sense to me. There is 
research out there showing how to use cooperative warp-scans, 
for example, to have multiple work-items cooperate over some 
local block of memory and perform sorting in blocks. There are 
even tutorials out there for OpenCL and CUDA that shows how to 
do this, specifically to create better performing code. This 
statement is in direct contradiction with what exists.


Now if we are talking about HSA, or other similar setup, then 
a few of those rules don't apply or become fuzzy.


HSA, does have limited access to global state, HSA can call 
cpu functions that are pure, and of course because in HSA the 
cpu and gpu share the same virtual address space most of 
memory is open for access.


HSA also manages memory, via the hMMU, and their is no need 
for gpu memory management functions, as that is managed by the 
operating system and video card drivers.


Good for HSA. Now why are we latching onto this particular 
construction that, as far as I can tell, is missing the support 
of at least two highly relevant giants (Intel and NVidia)?


Basically, D would either need to opt out of legacy api's such 
as openCL, CUDA, etc, these are mostly tied to c/c++ anyway, 
and generally have ugly as sin syntax; or D would have go the 
route of a full and safe gpu subset of features.


Wrappers do a lot to change the appearance of a program. Raw 
OpenCL may look ugly, but so do BLAS and LAPACK routines. The 
use of wrappers and expression templates does a lot to clean up 
code (ex. look at the way Eigen 3 or any other linear algebra 
library does expression templates in C++; something D can do 
even better).


I don't think such a setup can be implemented as simply a 
library, as the GPU needs compiled source.


This doesn't make sense. Your claim is contingent on opting out 
of OpenCL or any other mechanism that provides for the 
application to carry abstract instructions which are then 
compiled on the fly. If you're okay with creating kernel code 
on the fly, this can be implemented as a library, beyond any 
reasonable doubt.


If D where to implement gpgpu features, I would actually 
suggest starting by simply adding a microthreading function 
syntax, for example...


void example( aggregate in float a[] ; key , in float b[], out 
float c[]) {

c[key] = a[key] + b[key];
}

By adding an aggregate keyword to the function, we can assume 
the range simply using the length of a[] without adding an 
extra set of brackets or something similar.


This would make access to the gpu more generic, and more 
importantly, because llvm will support HSA, removes the needs 
for writing more complex support into dmd as openCL and CUDA 
would require, a few hints for the llvm backend would be 
enough to generate the dual bytecode ELF executables.


1) If you wanted to have that 'key' nonsense in there, I'm 
thinking you'd need to add several additional parameters: 
global size, group size, group count, and maybe group-local 
memory access (requires allowing multiple aggregates?). I mean, 
I get the gist of what you're saying, this isn't me pointing 
out a problem, just trying to get a clarification on it (maybe 
give 'key' some additional structure, or something).


2) ... I kind of like this idea. I disagree with how you led up 
to it, but I like the idea.


3) How do you envision *calling* microthreaded code? Just the 
usual syntax?


4) How would this handle working on subranges?

ex. Let's say I'm coding up a radix sort using something like 
this:


https://sites.google.com/site/duanemerrill/PplGpuSortingPreprint.pdf?attredirects=0

What's the high-level program organization with this syntax if 
we can only use one range at a time? How many work-items get 
fired off? What's the gpu-code launch procedure?


sorry typo,

Re: GPGPUs


On Sunday, 18 August 2013 at 01:43:33 UTC, Atash wrote:
Unified virtual address-space I can accept, fine. Ignoring that 
it is, in fact, in a totally different address-space where 
memory latency is *entirely different*, I'm far *far* more iffy 
about.



We basically have to follow these rules,

1. The range must be none prior to execution of a gpu code 
block
2. The range can not be changed during execution of a gpu code 
block
3. Code blocks can only receive a single range, it can however 
be multidimensional

4. index keys used in a code block are immutable
5. Code blocks can only use a single key(the gpu executes many 
instances in parallel each with their own unique key)

6. index's are always an unsigned integer type
7. openCL,CUDA have no access to global state
8. gpu code blocks can not allocate memory
9. gpu code blocks can not call cpu functions
10. atomics tho available on the gpu are many times slower 
then on the cpu
11. separate running instances of the same code block on the 
gpu can not have any interdependency on each other.


Please explain point 1 (specifically the use of the word 
'none'), and why you added in point 3?


Additionally, point 11 doesn't make any sense to me. There is 
research out there showing how to use cooperative warp-scans, 
for example, to have multiple work-items cooperate over some 
local block of memory and perform sorting in blocks. There are 
even tutorials out there for OpenCL and CUDA that shows how to 
do this, specifically to create better performing code. This 
statement is in direct contradiction with what exists.


You do have limited Atomics, but you don't really have any sort 
of complex messages, or anything like that.


Now if we are talking about HSA, or other similar setup, then 
a few of those rules don't apply or become fuzzy.


HSA, does have limited access to global state, HSA can call 
cpu functions that are pure, and of course because in HSA the 
cpu and gpu share the same virtual address space most of 
memory is open for access.


HSA also manages memory, via the hMMU, and their is no need 
for gpu memory management functions, as that is managed by the 
operating system and video card drivers.


Good for HSA. Now why are we latching onto this particular 
construction that, as far as I can tell, is missing the support 
of at least two highly relevant giants (Intel and NVidia)?


Intel doesn't have a dog in this race, so their is no way to know 
what they plan on doing if anything at all.


The reason to point out HSA, is because it is really easy add 
support for, it is not a giant task like opencl would be. A few 
changes to the front end compiler is all that is needed, LLVM's 
backend does the rest.


Basically, D would either need to opt out of legacy api's such 
as openCL, CUDA, etc, these are mostly tied to c/c++ anyway, 
and generally have ugly as sin syntax; or D would have go the 
route of a full and safe gpu subset of features.


Wrappers do a lot to change the appearance of a program. Raw 
OpenCL may look ugly, but so do BLAS and LAPACK routines. The 
use of wrappers and expression templates does a lot to clean up 
code (ex. look at the way Eigen 3 or any other linear algebra 
library does expression templates in C++; something D can do 
even better).


I don't think such a setup can be implemented as simply a 
library, as the GPU needs compiled source.


This doesn't make sense. Your claim is contingent on opting out 
of OpenCL or any other mechanism that provides for the 
application to carry abstract instructions which are then 
compiled on the fly. If you're okay with creating kernel code 
on the fly, this can be implemented as a library, beyond any 
reasonable doubt.


OpenCL isn't just a library, it is a language extension, that is 
ran through a preprocessor that compiles the embedded __KERNEL 
and __DEVICE functions, into usable code, and then outputs 
.c/.cpp files for the c compiler to deal with.


If D where to implement gpgpu features, I would actually 
suggest starting by simply adding a microthreading function 
syntax, for example...


void example( aggregate in float a[] ; key , in float b[], out 
float c[]) {

c[key] = a[key] + b[key];
}

By adding an aggregate keyword to the function, we can assume 
the range simply using the length of a[] without adding an 
extra set of brackets or something similar.


This would make access to the gpu more generic, and more 
importantly, because llvm will support HSA, removes the needs 
for writing more complex support into dmd as openCL and CUDA 
would require, a few hints for the llvm backend would be 
enough to generate the dual bytecode ELF executables.


1) If you wanted to have that 'key' nonsense in there, I'm 
thinking you'd need to add several additional parameters: 
global size, group size, group count, and maybe group-local 
memory access (requires allowing multiple aggregates?). I mean, 
I get the gist of what you're saying, this isn't me pointing 
out a

Re: GPGPUs

The core (!) point here is that processor chips are rapidly 
becoming a
collection of heterogeneous cores. Any programming language 
that assumes

a single CPU or a collection of homogeneous CPUs has built-in
obsolescence.

So the question I am interested in is whether D is the language 
that can
allow me to express in a single codebase a program in which 
parts will
be executed on one or more GPGPUs and parts on multiple CPUs. D 
has

support for the latter, std.parallelism and std.concurrency.

I guess my question is whether people are interested in 
std.gpgpu (or

some more sane name).


CUDA, works as a preprocessor pass that generates c files from 
.cu extension files.


In effect, to create a sensible environment for microthreaded 
programming, they extend the language.


a basic CUDA function looking something like...

__global__ void add( float * a, float * b, float * c) {
   int i = threadIdx.x;
   c[i] = a[i] + b[i];
}

add 1, 10 ( ptrA, ptrB, ptrC );

Their is the buildin variables to handle the index location 
threadIdx.x in the above example, this is something generated by 
the thread scheduler in the video card/apu device.


Generally calls to this setup has a very high latency, so using 
this for a small handful of items as in the above example makes 
no sense. In the above example that would end up using a single 
execution cluster, and leave you prey to the latency of the pcie 
bus, execution time, and latency costs of the video memory.


it doesn't get effective until you are working with large data 
sets, that can take advantage of a massive number of threads 
where the latency problems would be secondary to the sheer 
calculations done.


as far as D goes, we really only have one build in microthreading 
capable language construct, foreach.


However I don't think a library extension similar to 
std.parallelism would work gpu based microthreading.


foreach would need to have something to tell the compiler to 
generate gpu bytecode for the code block it uses, and would need 
instructions on when to use said code block based on dataset size.


while it is completely possible to have very little change with 
function just add new property @microthreaded and the build in 
variables for the index position/s, the calling syntax would need 
changes to support a work range or multidimensional range of some 
sort.


perhaps looking something like

add$(1 .. 10)(ptrA,ptrB,ptrC);

a templated function looking similar

add!(float)$(1 .. 10)(ptrA,ptrB,ptrC);

Re: GPGPUs


On Friday, 16 August 2013 at 20:07:32 UTC, John Colvin wrote:
We have a[] = b[] * c[] - 5; etc. which could work very neatly 
perhaps?


While this in fact could work, given the nature of GPGPU it would
not be very effective.

In a non shared memory and non cache coherent setup, the entirety
of all 3 arrays have to be copied into GPU memory, had that
statement ran as gpu bytecode, and then copied back to complete
the operation.

GPGPU doesn't make sense on small code blocks, both in
instruction count, and by how memory bound a particular statement
would be.

The compiler needs to either be explicitly told what can/should
be ran as a GPU function, or have some intelligence about what to
or not to run as a GPU function.

This will get better in the future, APU's using the full HSA
implementation will drastically reduce the buyin latency/cycle
cost of using a GPGPU function, and make them more practical for
smaller(in instruction count/memory boundess) operations.

Re: GPGPUs


On Friday, 16 August 2013 at 21:14:12 UTC, Atash wrote:

Regarding functionality, @microthreaded is sounding a lot like 
the __kernel or __global__ keywords in OpenCL and CUDA. Is this 
intentional?


The more metaphors that can be drawn between extant tools and 
whatever is come up with the better, methinks.


Yes, And that is just a word I pull out the air, if another term 
makes more sense then I am not against it.

Re: GPGPUs


On Friday, 16 August 2013 at 23:30:12 UTC, John Colvin wrote:

On Friday, 16 August 2013 at 22:11:41 UTC, luminousone wrote:

On Friday, 16 August 2013 at 20:07:32 UTC, John Colvin wrote:
We have a[] = b[] * c[] - 5; etc. which could work very 
neatly perhaps?


While this in fact could work, given the nature of GPGPU it 
would

not be very effective.

In a non shared memory and non cache coherent setup, the 
entirety

of all 3 arrays have to be copied into GPU memory, had that
statement ran as gpu bytecode, and then copied back to complete
the operation.

GPGPU doesn't make sense on small code blocks, both in
instruction count, and by how memory bound a particular 
statement

would be.

The compiler needs to either be explicitly told what can/should
be ran as a GPU function, or have some intelligence about what 
to

or not to run as a GPU function.

This will get better in the future, APU's using the full HSA
implementation will drastically reduce the buyin 
latency/cycle
cost of using a GPGPU function, and make them more practical 
for

smaller(in instruction count/memory boundess) operations.


I didn't literally mean automatically inserting GPU code.

I was more imagining this:

void foo(T)(T[] arr)
{
useArray(arr);
}

auto a = someLongArray;
auto b = someOtherLongArray;

gpu
{
auto aGPU = toGPUMem(a);
auto bGPU = toGPUMem(b);

auto c = GPUArr(a.length);

c[] = a[] * b[];

auto cCPU = toCPUMem(c);
c.foo();

dot(c, iota(c.length).array().toGPUMem())
.foo();
}

gpu T dot(T)(T[] a, T[] b)
{
//gpu dot product
}


with cpu arrays and gpu arrays identified separately in the 
type system. Automatic conversions could be possible, but of 
course that would allow carelessness.


Obviously there is some cpu code mixed in with the gpu code 
there, which should be executed asynchronously if possible. You 
could also have

onlyGPU
{
//only code that can all be executed on the GPU.
}



Just ideas off the top of my head. Definitely full of holes and 
I haven't really considered the detail :)



You can't mix cpu and gpu code, they must be separate.

auto a = someLongArray;
auto b = someOtherLongArray;

auto aGPU = toGPUMem(a);
auto bGPU = toGPUMem(b);

auto c = GPUArr(a.length);

gpu
{
// this block is one gpu shader program
c[] = a[] * b[];
}

auto cCPU = toCPUMem(c);
cCPU.foo();
auto cGPU = toGPUMem(cCPU);
auto dGPU = iota(c.length).array().toGPUMem();

gpu{
// this block is another wholly separate shader program
auto resultGPU = dot(cGPU, dGPU);
}

auto resultCPU = toCPUMem(resultGPU);
resultCPU.foo();

gpu T dot(T)(T[] a, T[] b)
{
//gpu dot product
}


Your example rewritten to fit the gpu.

However this still has problems of the cpu having to generate CPU 
code from the contents of gpu{} code blocks, as the GPU is unable 
to allocate memory, so for example ,


gpu{
auto resultGPU = dot(c, cGPU);
}

likely either won't work, or generates an array allocation in cpu 
code before the gpu block is otherwise ran.


Also how does that dot product function know the correct index 
range to run on?, are we assuming it knows based on the length of 
a?, while the syntax,


c[] = a[] * b[];

is safe for this sort of call, a function is less safe todo this 
with, with function calls the range needs to be told to the 
function, and you would call this function without the gpu{} 
block as the function itself is marked.


auto resultGPU = dot$(0 .. 
returnLesser(cGPU.length,dGPU.length))(cGPU, dGPU);




Remember with gpu's you don't send instructions, you send whole 
programs, and the whole program must finish before you can move 
onto the next cpu instruction.

Re: GPGPUs

2013-08-13 Thread luminousone


On Tuesday, 13 August 2013 at 16:27:46 UTC, Russel Winder wrote:
The era of GPGPUs for Bitcoin mining are now over, they moved 
to ASICs.
The new market for GPGPUs is likely the banks, and other Big 
Data
folk. True many of the banks are already doing some GPGPU 
usage, but it

is not big as yet. But it is coming.

Most of the banks are either reinforcing their JVM commitment, 
via
Scala, or are re-architecting to C++ and Python. True there is 
some
C#/F# but it is all for terminals not for strategic computing, 
and it is
diminishing (despite what you might hear from .NET oriented 
training

companies).

Currently GPGPU tooling means C. OpenCL and CUDA (if you have 
to) are C
API for C coding. There are some C++ bindings. There are 
interesting
moves afoot with the JVM to enable access to GPGPU from Java, 
Scala,
Groovy, etc. but this is years away, which is a longer 
timescale than

the opportunity.

Python's offerings, PyOpenCL and PyCUDA are basically ways of 
managing C
coded kernels which rather misses the point. I may get involved 
in
trying to write an expression language in Python to go with 
PyOpenCL so
that kernels can be written in Python – a more ambitious 
version aimed

at Groovy is also mooted.

However, D has the opportunity of gaining a bridgehead if a 
combination
of D, PyD, QtD and C++ gets to be seen as a viable solid 
platform for
development.  The analogue here is the way Java is giving way 
to Scala
and Groovy, but in an evolutionary way as things all interwork. 
The
opportunity is for D to be seen as the analogue of Scala on the 
JVM for
the native code world: a language that interworks well with all 
the

other players on the platform but provides more.

The entry point would be if D had a way of creating GPGPU 
kernels that

is better than the current C/C++ + tooling.

This email is not a direct proposal to do work, just really an 
enquiry

to see if there is any interest in this area.


I suggest looking into HSA.

http://developer.amd.com/wordpress/media/2012/10/hsa10.pdf

This will be available on AMD APUs in December, and will trickle 
out to arm and other platforms over time.

Re: GPGPUs

2013-08-13 Thread luminousone

On Tuesday, 13 August 2013 at 22:24:18 UTC, Nick B wrote:

On Tuesday, 13 August 2013 at 18:35:28 UTC, luminousone wrote:
On Tuesday, 13 August 2013 at 16:27:46 UTC, Russel Winder
wrote:
The era of GPGPUs for Bitcoin mining are now over, they moved
to ASICs.

http://developer.amd.com/wordpress/media/2012/10/hsa10.pdf

This will be available on AMD APUs in December, and will
trickle out to arm and other platforms over time.

What a very interesting concept redesigned from the ground up.

How about this for the future:

D2 LLVM Compiler HSAIC Finaliser Architected Queueing
Language

Here is a another usefull link:

http://developer.amd.com/resources/heterogeneous-computing/what-is-heterogeneous-system-architecture-hsa/

Nick

And its not just AMD, HSA is supported by the HSA Foundation,
with wide industry support.

http://hsafoundation.com/

It is platform independent, at least in so far as it doesn't need
x86 to operate, within a few years most ARM devices will support
HSA.

And HSAIL bytecode sits inside the ELF executable file next to
the platform's bytecode, so compiling it in does not break any
platform that does not support HSA.

Memory isn't simply a shared architecture, its fully cache
coherent, allows the GPU to use the same virtual address space as
the CPU, On an APU platform you never need to copy data to and
from GPU memory, simply pass a pointer and your done.

HSAIL bytecode also is expressive enough for c++(including
virtual functions) to compile directly to it, so no reason D
can't.

Some additions to D to handle micro threading, wouldn't go amiss
however.

The HSA finalizer AMD will be provided is supposed to use LLVM(at
least that is my understanding).

So changes required to support HSA would likely be minimal, most
of these changes would be friendly to building in support for
openCL or the like as well for none supported platforms.

deimos libx11 license

2013-08-12 Thread luminousone

I finely got around to checking the libx11 deimos project for 
updates, i haven't updated in ages, and the github has a LGPL 
license file included with it, is this intentional?, The opengl 
deimos library does not contain this, are all of the deimos 
projects LGPL, or is their some sort of error in this repository 
containing this?

Re: deimos libx11 license

2013-08-12 Thread luminousone

On Tuesday, 13 August 2013 at 05:03:10 UTC, Jonathan M Davis 
wrote:

On Tuesday, August 13, 2013 05:53:50 luminousone wrote:

I finely got around to checking the libx11 deimos project for
updates, i haven't updated in ages, and the github has a LGPL
license file included with it, is this intentional?, The opengl
deimos library does not contain this, are all of the deimos
projects LGPL, or is their some sort of error in this 
repository

containing this?


Deimos projects have no relation to each other beyond the fact 
that they're
all in the same group on github. They're simply D bindings to a 
variety of
unrelated libraries which were written in C. So, the license of 
one project

has no bearing on the license of another.

Given that they're bindings, I would expect them to have the 
same license as
the original C code. In the case of flac, I outright copied the 
copyrights from
the C code. It really doesn't make much sense IMHO to give the 
bindings a
different license from the original. At best, you might be able 
to get away
with marking them as Boost, but since you'd be using the 
original library to
do anything, you'd still be restricted by its license. But I'm 
not a lawyer,
so I don't know what all of the murky details are. It just 
seemed simplest to

me to copy the copyrights over.

As for the opengl deimos project, I don't know what its license 
is. It's

probably listed in the copyright notices in the files.

- Jonathan M Davis


Their are other opengl wrappers with various licenses, I am 
actually more concered with the libx11 license, I need to be able 
to statically link without surrendering my code to the lgpl 
license.


The original license of Xlib I am pretty sure is the x11 license, 
any idea who the maintainer of the libx11 deimos project is, such 
that I may query them, before I relagate myself to writting a new 
xlib wrapper?


I ask purely because I think their might be an error, not because 
I am arguing the merits of the license, I just wanna be sure all 
my ducks are in a row so to speak!

Re: request switch statement with common block

perhaps a more generic solution should be looked at, extend 
contracts to work with all scope blocks.


switch(somenumber)
in {
... before stuff ...
}
out {
 after stuff ...
}
body {
case 1:
in {
   ... etc 
}
out {
   ... more etc ...
}
body {
   ...
}
case 2:
  // and so on
}

or perhaps

for( int i = 0 ; i  10 ; i ++ )
in {
assert( i == 0 );
}
out {
assert( i == 9 );
}
body {
   ... stuff ...
}

if it is desired for a particular contract block to be called in 
release builds perhaps a attribute label to mark it as a runtime 
block or something similar.


foreach( i, k ; somerange )
@runtime in {
 ...
}
body {
}

Re: request switch statement with common block


On Monday, 5 August 2013 at 20:45:47 UTC, Borislav Kosharov wrote:

On Monday, 5 August 2013 at 19:58:21 UTC, ron wrote:

On Monday, 5 August 2013 at 08:46:54 UTC, Andre Artus wrote:

On Monday, 5 August 2013 at 06:28:12 UTC, luminousone wrote:
perhaps a more generic solution should be looked at, extend 
contracts to work with all scope blocks.


switch(somenumber)
in {
 ... before stuff ...
}
out {
  after stuff ...
}
body {
 case 1:
 in {
... etc 
 }
 out {
... more etc ...
 }
 body {
...
 }
 case 2:
   // and so on
}

or perhaps

for( int i = 0 ; i  10 ; i ++ )
in {
 assert( i == 0 );
}
out {
 assert( i == 9 );
}
body {
... stuff ...
}

if it is desired for a particular contract block to be 
called in release builds perhaps a attribute label to mark 
it as a runtime block or something similar.


foreach( i, k ; somerange )
@runtime in {
...
}
body {
}


Please do not take offense, but I do not see this as a good 
idea. Contracts have a very different function; not just in 
D, but every language that uses them. The idea is to support 
design-by-contract programming. Overloading the constructs 
for the purposes proposed here would, in my opinion, cause 
confusion and/or weaken the proper use of contract 
programming.



The code in the contract conditions should never do anything 
more than what is necessary to specify the contract. It 
should not do explicit IO (other than implied by assert()), 
mutate state, or anything like that.


At the bottom of this page you can find a reading list for 
more info.

http://www.digitalmars.com/d/dbc.html

Or for a general overview:
http://en.wikipedia.org/wiki/Design_by_contract

Walter, does the D compiler or any of it's companion tools do 
any static analysis on the contracts? Such as a void 
safety/null reference check?


None taken, =-p.

I don't see how this is different from current contract usage, 
right now they apply to function scopes only. currently I 
believe you could get a similar effect via using an inner 
function.


void a() {
  int i = 0;
  void b()
  in {
 assert( i == 0 );
  }
  out {
 assert( i == 10 );
  }
  body {
 for( ; i  10 ; i ++ ) {
... do something ...
 }
  }
  b();
}


Speaking of contracts, and reading the docs I see:
Pre and Post Contracts

The pre contracts specify the preconditions before a statement 
is executed. The most typical use of this would be in 
validating the parameters to a function. The post contracts 
validate the result of the statement. The most typical use of 
this would be in validating the return value of a function and 
of any side effects it has...


So are contracts possible outside function declarations? For 
example just scopes or random places in code.


I being zero is the precondition for that loop, and i being 10 is 
the post condition for that loop.


Pretty much I think that any scope can potentially fit the 
definition for contracts.


Really any block of code, can be considered to have pre and post 
conditions, functions just happen to be one way to organize code.

Re: request switch statement with common block


On Monday, 5 August 2013 at 21:48:46 UTC, Andre Artus wrote:

On Monday, 5 August 2013 at 19:58:21 UTC, ron wrote:

On Monday, 5 August 2013 at 08:46:54 UTC, Andre Artus wrote:

On Monday, 5 August 2013 at 06:28:12 UTC, luminousone wrote:
perhaps a more generic solution should be looked at, extend 
contracts to work with all scope blocks.


switch(somenumber)
in {
 ... before stuff ...
}
out {
  after stuff ...
}
body {
 case 1:
 in {
... etc 
 }
 out {
... more etc ...
 }
 body {
...
 }
 case 2:
   // and so on
}

or perhaps

for( int i = 0 ; i  10 ; i ++ )
in {
 assert( i == 0 );
}
out {
 assert( i == 9 );
}
body {
... stuff ...
}

if it is desired for a particular contract block to be 
called in release builds perhaps a attribute label to mark 
it as a runtime block or something similar.


foreach( i, k ; somerange )
@runtime in {
...
}
body {
}


Please do not take offense, but I do not see this as a good 
idea. Contracts have a very different function; not just in 
D, but every language that uses them. The idea is to support 
design-by-contract programming. Overloading the constructs 
for the purposes proposed here would, in my opinion, cause 
confusion and/or weaken the proper use of contract 
programming.



The code in the contract conditions should never do anything 
more than what is necessary to specify the contract. It 
should not do explicit IO (other than implied by assert()), 
mutate state, or anything like that.


At the bottom of this page you can find a reading list for 
more info.

http://www.digitalmars.com/d/dbc.html

Or for a general overview:
http://en.wikipedia.org/wiki/Design_by_contract

Walter, does the D compiler or any of it's companion tools do 
any static analysis on the contracts? Such as a void 
safety/null reference check?


None taken, =-p.

I don't see how this is different from current contract usage, 
right now they apply to function scopes only. currently I 
believe you could get a similar effect via using an inner 
function.


void a() {
  int i = 0;
  void b()
  in {
 assert( i == 0 );
  }
  out {
 assert( i == 10 );
  }
  body {
 for( ; i  10 ; i ++ ) {
... do something ...
 }
  }
  b();
}


I could be missing something, if so please clarify.

The construct I have issue with is this one,


switch(somenumber)
in {
 ... before stuff ...
}
out {
  after stuff ...
}


I would contend that code within in/out/invariant blocks should 
be 'pure' (no state changes, no IO [other than assert 
throwing]), it's only there to validate that a class and it's 
methods do not violate certain conditions. They should be able 
to be stripped out of the release build without altering the 
execution of the application in any way.


A classic example is the null dereference check, which some 
compilers and most (all?) static analysers can detect.




string whoIsAMonkey(Person p)
  in
  {
assert(p !is null, Person can not be null);
assert(!isNullOrEmpty(p.Name), Person name can not be null 
or empty);

  }
  body
  {
return p.Name ~  is a monkey!;
  }


void main() {
Person p = null;
// Compiler / analyser should complain with
// Person can not be null
writeln(whoIsAMonkey(p));
//   ^ here
}

void main() {
Person p = new Person();
// Compiler / analyser should complain with
// Person name can not be null or empty
writeln(whoIsAMonkey(p));
}

etc.

Contracts are meant to define the public (*) interface of a 
class.


* By public I mean here anything not 'private', e.g. 
'protected' for inheritance.


As Andrei points out in his book (The D Programming Language) 
contracts are not used to validate/scrub user (or any external) 
input as they can be compiled out of the executable.


Contracts are there to check sanity at compile time, or at the 
very least during testing.


The contract is (or should be) part of the documentation.


You are correct. I will have to check out his book.

Re: D game development: a call to action