Re: static this sucks, we should deprecate it
Derek Parnell wrote:
On Sat, 30 May 2009 03:52:44 +1200, Tim Matthews wrote:
Walter Bright wrote:
It's unreliable because how do you specify the load order? And how does
the user relate that to the source semantics?
grauzone suggested this earlier:
static this {} //full dependencies (all import statements)
static this : a, b {} //only dependent from module a and b
static this : void {} //no dependencies at all
Is there a situation in which the dependancies are not known by the coder
writer? For example, linking in some object code that has a "static this{}"
section and not having the source code for that object code.
file A.di:
void foo();
file B.d:
static this () { foo(); }
All bets are off. A more sophisticated object format can correct this.
Re: Bartosz Milewski Missing post
Bartosz Milewski wrote: I don't think the item-by-item pingpong works well in the newsgroup. Let's separate our discussion into separate threads. One philosophical, about the future of concurrency. Another about the immediate future of concurrency in D2. And a separate one about my proposed system in the parallel universe where we all agree that for the next 10 years shared-memory concurrency will be the dominating paradigm. I'm sure it's a good idea, particularly if others will participate as well. I warn that I'll be at a conference Sat-Thu and I don't have much time even apart from that. Andrei
Re: Cuda for C++
On Fri, 29 May 2009 07:33:55 -0400, Denis Koroskin <2kor...@gmail.com> wrote: On Fri, 29 May 2009 15:28:00 +0400, Trass3r wrote: bearophile schrieb: "Thrust is a CUDA library of parallel algorithms with an interface resembling the C++ Standard Template Library (STL). Thrust provides a flexible high-level interface for GPU programming": http://code.google.com/p/thrust/ Something like this (but OpenCL) for D sounds quite interesting. Hopefully OpenCL's runtime will be compatible to D's: Chris R Miller wrote (in Feb): > I looked into writing CUDA with D a while back. The problem is that the > CUDA C runtime and the D runtime are 100% incompatible. I don't have any new information about the topic though. Maybe it works with druntime. Yeah, OpenCL looks interesting. For example, they annotate variables with either __global, __local or __private attributes, that are very close to D2 shared/TLS/unique. Well, that's not quite right, global : shared, accessible by the host local : restricted to a 'work-group', not accessible by the host private: value-types on the function's stack
Re: Bartosz Milewski Missing post
I don't think the item-by-item pingpong works well in the newsgroup. Let's separate our discussion into separate threads. One philosophical, about the future of concurrency. Another about the immediate future of concurrency in D2. And a separate one about my proposed system in the parallel universe where we all agree that for the next 10 years shared-memory concurrency will be the dominating paradigm.
Re: Bartosz Milewski Missing post
Can you believe it? I was convinced that my response was lost because the stupid news reader on Digital Mars web site returned an error (twice, hence two posts). I diligently rewrote the riposte from scratch and tried to post it. It flunked again! Now I'm not sure if it won't appear in the newsgroup after an hour. (By the way, I refined my arguments.)
Re: Bartosz Milewski Missing post
Leandro Lucarella wrote: bearophile, el 29 de mayo a las 13:39 me escribiste: Leandro Lucarella: I agree. Maybe is just unjustified fear, but I see D2 being to concurrency what C++ was to templates. Sometimes you need lot of time to find what a simple implementation can be. Often someone has to pay the price of being the first one to implement something :-] This is bad if you mix it with the will of keeping backwards compatibility. Exactly. I think D had a good model of "steal good proven stuff that other languages got right". With this, I thinks it's taking a new path of being a pioneer, and chances are it get it wrong (I don't mean to be offensive with this, I'm just speaking statistically) and suffer the mistake for a long long time because of backward compatibility. With its staunch default isolation, I think D is already making a departure from the traditional imperative languages (which extend their imperative approach to concurrent programming). The difference is that it takes what I think is a sound model (interprocess isolation) and augment it with the likes of shared and Bartosz's work. So my perception is that it's less likely to get things regrettably wrong. But then you never know. Andrei
Re: Bartosz Milewski Missing post
bearophile, el 29 de mayo a las 13:39 me escribiste: > Leandro Lucarella: > > I agree. Maybe is just unjustified fear, but I see D2 being to concurrency > > what C++ was to templates. > > Sometimes you need lot of time to find what a simple implementation can > be. Often someone has to pay the price of being the first one to > implement something :-] This is bad if you mix it with the will of > keeping backwards compatibility. Exactly. I think D had a good model of "steal good proven stuff that other languages got right". With this, I thinks it's taking a new path of being a pioneer, and chances are it get it wrong (I don't mean to be offensive with this, I'm just speaking statistically) and suffer the mistake for a long long time because of backward compatibility. -- Leandro Lucarella (luca) | Blog colectivo: http://www.mazziblog.com.ar/blog/ GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145 104C 949E BFB6 5F5A 8D05)
Re: Bartosz Milewski Missing post
Bartosz Milewski wrote: Andrei Alexandrescu Wrote: Scala doesn't know what to do about threads. That's my impression too, although Scala's support for actors leaves D in the dust. Scala actors are a library. The trend I'm seeing is that functional languages are getting increasing attention, and that's exactly because they never share mutable memory. As far as I can see, languages that are based on heavy shared mutation are pretty much dead in the water. We have the chance to not be so. It's a very sweeping statement. I just looked at the TIOBE index and couldn't find _any_ functional languages in the top 20. We can safely ditch Tiobe, but I agree that functional languages aren't mainstream. There are two trends though. One is that for most of its existence Haskell has had about 12 users. It has definitely turned an exponential elbow during the recent years. Similar trends are to be seen for ML, Ocaml, and friends. The other trend is that all of today's languages are scrambling to add support for pure functional programming. I'm not at all sure the focus must be put on high-level race avoidance, particularly given that the cost in perceived complexity is this high. The complexity argument is tenuous. It might look like my proposal is complex because I'm dropping the whole system in at once. But it's a solid, well thought-out system. What I see happening in D is the creeping complexity resulting from sloppy design. We've been talking for years about closing some gaping holes in the design of arrays, slices, immutable, qualifier polymorphism--the list goes on--and there's little progress. There is no solid semantics for scope and shared. A solid solution to those issues will look complex too. What do those holes have to do with the problem at hand? I'm seeing implementation bugs, not design holes. I'd love them to be fixed as much as the next guy, but I don't think we're looking at issues that would be complex (except for scope which sucks; I never claimed there was a solution to that). All of other features you mention have no holes I know of in their design. Why wouldn't we think of making message passing a language feature in D? Because we don't have even a tiniest proposal describing it, not to mention a design. That doesn't mean we shouldn't think of it. Why does message passing need erlangization to support message passing? Because the strength of the Erlang model is the isolation of processes. Take away isolation and it's no better than Scala or Java. Granted, having to explicitly mark objects for sharing in D is a big help. Here we agree. So we should be thinking about it, right? What I discussed was a holistic approach in which language + standard library provides a trusted computing base. Have you thought about how to eliminate data races in your holistic approach? Will "shared" be forbidden in SafeD? Will library-based message-passing channels (and actors?) only accept simple value types and immutables? Shared will be allowed in SafeD but it will be the responsibility of user code to ensure high-level race elimination. Shared will eliminate low-level races. I think it's worth contemplating a scenario in which message passing is restricted to certain types. Andrei, you are the grand wizard of squeezing powerful abstractions out of a kludge of a language that is C++ with its ad-hoc support for generics. It's impressive and very useful, but it's also hermetic. By contrast, generic programming in D is relatively easy because of the right kind of support built into the language (compile-time interpreter). Please no ad hominem, flattering or not. I trust that you could squeeze powerful multithreading abstraction out of D, even if the language/type system doesn't offer much of a support. But it will be hermetic. Prove me wrong by implementing a message queue using the current D2 (plus some things that are still in the pipeline). I don't have the time, but I think it's worth looking into what a message queue implementation should look like. How is this related to the discussion at hand? You want to put all concurrency support in the language. That is, you want to put enough power into the language to be able to typecheck a variety of concurrent programming primitives and patterns. This approach is blindsided to the opportunity of defining some of these primitives in the standard library, in unsafe/unportable D, yet offering safe primitives to the user. In the process, the user is not hurt because she still has access to the primitives. What she can't do is define their own primitives in safe D. But I think that's as useless a pursuit as adding keywords to C to allow one to implement malloc() in safe C. That's a bad analogy. I'm proposing the tightening of the type system, not the implementation of weak atomics. A better analogy would be adding immutable/const to the language. Except that I don't think const-correctness is as importan
Re: static this sucks, we should deprecate it
On Sat, 30 May 2009 03:52:44 +1200, Tim Matthews wrote:
> Walter Bright wrote:
>
>>
>> It's unreliable because how do you specify the load order? And how does
>> the user relate that to the source semantics?
>
> grauzone suggested this earlier:
>
> static this {} //full dependencies (all import statements)
> static this : a, b {} //only dependent from module a and b
> static this : void {} //no dependencies at all
Is there a situation in which the dependancies are not known by the coder
writer? For example, linking in some object code that has a "static this{}"
section and not having the source code for that object code.
--
Derek Parnell
Melbourne, Australia
skype: derek.j.parnell
Re: [OT] Convention of Communication
"Simen Kjaeraas" wrote in message news:op.uun3kgep1hx...@biotronic-pc.osir.hihm.no... > Nick Sabalausky wrote: > >> "Manfred Nowak" wrote in message >> news:xns9c197a654df6dsvv1999hotmail...@65.204.18.192... >>> At least a quarter of the last postings here do not follow the usenet >>> convention of proper identifying the author---which is the full name of >>> the author and a valid email adress of the author. >> >> Are you kidding me? There isn't a chance in hell I'd put a valid email >> address for myself on a newsgroup posting. "Hey bots! Please spam me!". > > I'm doing it. Mostly 'cause of gmail's filter being good. I think two > spam messages have made it past it since I got the account, some 4 years > ago. 'course, if you got a crappy mail provider, it might not be as good > an idea. > I've tried a number of filters over the years, even popular and highly-respected ones, but never found one that didn't give me both false-positives and false-negatives. The way I do things now, despite having no filters, I also have no spam at all and (naturally) no valid messages accidentally being rejected. So I see the filters as little more than clumbsy bandage-appoach.
Re: Bartosz Milewski Missing post
Jason House Wrote: > Bartosz Milewski Wrote: > > My hobby project is a multi-threaded game-playing AI. My current scheme uses > a shared search tree using lockless updates with search results. Besides > general ability to use your scheme for what I've already done, I'm also > interested in how to overhaul the garbage collector and implementing lockless > hashtables (see high-scale-lib on sf.net) > I see, you're a hardcore lockfree programmer. All you can expect from D is Sequential Consistency--nothing fancy like C++ weak atomics. But that's for the better. > > The complex part is for library writers who have very demanding needs. > > Unfortunately, I have to describe the whole shebang in my blog, otherwise > > people won't believe that the system is workable and that it satisfies > > their high expectations. > > Yeah, I'm waiting for more details like which fences are introduced by the > lockless SC requirements. The high-scale-lib is virtually fence free. > I don't have much to say about that because it's a know problem and it has already been solved in Java. I can tell you what is required on an x86: use xchg for writes, and that's all. I think Walter has already implemented it, because he asked me the same question.
Re: Bartosz Milewski Missing post
Andrei Alexandrescu Wrote: > Scala doesn't know what to do about threads. That's my impression too, although Scala's support for actors leaves D in the dust. > The trend I'm seeing is > that functional languages are getting increasing attention, and that's > exactly because they never share mutable memory. As far as I can see, > languages that are based on heavy shared mutation are pretty much dead > in the water. We have the chance to not be so. > It's a very sweeping statement. I just looked at the TIOBE index and couldn't find _any_ functional languages in the top 20. > I'm > not at all sure the focus must be put on high-level race avoidance, > particularly given that the cost in perceived complexity is this high. The complexity argument is tenuous. It might look like my proposal is complex because I'm dropping the whole system in at once. But it's a solid, well thought-out system. What I see happening in D is the creeping complexity resulting from sloppy design. We've been talking for years about closing some gaping holes in the design of arrays, slices, immutable, qualifier polymorphism--the list goes on--and there's little progress. There is no solid semantics for scope and shared. A solid solution to those issues will look complex too. > Why wouldn't we think of making message passing a language feature in D? Because we don't have even a tiniest proposal describing it, not to mention a design. > Why does message passing need erlangization to support message passing? Because the strength of the Erlang model is the isolation of processes. Take away isolation and it's no better than Scala or Java. Granted, having to explicitly mark objects for sharing in D is a big help. Here we agree. > What I discussed was a holistic approach in which language + standard > library provides a trusted computing base. Have you thought about how to eliminate data races in your holistic approach? Will "shared" be forbidden in SafeD? Will library-based message-passing channels (and actors?) only accept simple value types and immutables? Andrei, you are the grand wizard of squeezing powerful abstractions out of a kludge of a language that is C++ with its ad-hoc support for generics. It's impressive and very useful, but it's also hermetic. By contrast, generic programming in D is relatively easy because of the right kind of support built into the language (compile-time interpreter). I trust that you could squeeze powerful multithreading abstraction out of D, even if the language/type system doesn't offer much of a support. But it will be hermetic. Prove me wrong by implementing a message queue using the current D2 (plus some things that are still in the pipeline). > How is this related to the discussion at hand? You want to put all > concurrency support in the language. That is, you want to put enough > power into the language to be able to typecheck a variety of concurrent > programming primitives and patterns. This approach is blindsided to the > opportunity of defining some of these primitives in the standard > library, in unsafe/unportable D, yet offering safe primitives to the > user. In the process, the user is not hurt because she still has access > to the primitives. What she can't do is define their own primitives in > safe D. But I think that's as useless a pursuit as adding keywords to C > to allow one to implement malloc() in safe C. > That's a bad analogy. I'm proposing the tightening of the type system, not the implementation of weak atomics. A better analogy would be adding immutable/const to the language. Except that I don't think const-correctness is as important as the safety of shared-memory concurrency. > > Without > > type-system support, though, such queues would have to be either > > unsafe (no guarantee that the client doesn't have unprotected aliases > > to messages), or restrict messages to very simple data structures > > (pass-by-value and maybe some very clever unique pointer/array > > template). The latter approach introduces huge complexity into the > > library, essentially making user-defined extensions impossible > > (unless the user's name is Andrei ;-) ). > > Complexity will be somewhere. The problem is, you want to put much of it > in the language, and that will hit the language user too. I'm being very careful not to hit the language user. You might have noticed that my primitive channel, the MVar, is less complex than a D2 implementation (it doesn't require "synchronized"). And the compiler will immediately tell you if you use it in an unsafe way. > Semantic > checking will always be harder on everyone than a human being who sits > down and implements a provably safe library in ways that the compiler > can't prove. > Be careful with such arguments. Somebody might use them to discredit immutability. > > Let's not forget that right now D is _designed_ to support > > shared-memory programming. Every D object has
Re: Cuda for C++
Trass3r wrote: I don't have any new information about the topic though. No problem: http://www.seriouswheels.com/1970-1979/1970-Plymouth-Hemi-Cuda-Orange-FA.htm
Re: Cuda for C++
Trass3r wrote: bearophile schrieb: "Thrust is a CUDA library of parallel algorithms with an interface resembling the C++ Standard Template Library (STL). Thrust provides a flexible high-level interface for GPU programming": http://code.google.com/p/thrust/ Something like this (but OpenCL) for D sounds quite interesting. Hopefully OpenCL's runtime will be compatible to D's: Chris R Miller wrote (in Feb): > I looked into writing CUDA with D a while back. The problem is that the > CUDA C runtime and the D runtime are 100% incompatible. I don't have any new information about the topic though. Maybe it works with druntime. Isn't there a dcuda project at team0xf? Not sure what state it's in, though. I'd say OpenCL/DirectX Compute Shaders are the future... CUDA is only supported on NVIDIA, and as a proud ATI user, I must take exception.
Re: Bartosz Milewski Missing post
Leandro Lucarella: > I agree. Maybe is just unjustified fear, but I see D2 being to concurrency > what C++ was to templates. Sometimes you need lot of time to find what a simple implementation can be. Often someone has to pay the price of being the first one to implement something :-] This is bad if you mix it with the will of keeping backwards compatibility. Bye, bearophile
Re: Source control for all dmd source
Reply to dennis, On 29.05.2009 16:26, dennis luehring wrote: On 29.05.2009 15:18, Jason House wrote: Over in D.anounce, the LDC devs said they would have an easier time upgrading to newer dmd (fe) versions if the source was in source control. Even if Walter is the only one with write access, it's still be helpful. It's helpful for more than just the LDC folks; that's just the most recent example. How about it Walter? IIRC, Andrei has been encouraging you to do this for awhile now. maybe on dsource.org like phobos 1/2 - seams to work realy good for walter and andrei (and all others) does all include optlink sources, too? :-) IIRC Walter dosn't own OPLINK and it's in ASM!
Re: Bartosz Milewski Missing post
BCS wrote: Reply to Andrei, It follows that message passing is not only an attractive model I'm thinking implementation not model. How is the message passing implemented? OS system calls (probably on top of kernel level shared memory)? user space shared memory? Special hardware? If you can't get #3, I'd rather a good standard implemntation using #2 (and a back door :). I think it depends on whether the message is intraprocess or interprocess. In the first case, I expect message passing would probably be done via user space shared memory if possible (things get a bit weird with per-thread heaps). In the latter case, a kernel api would probably be used if possible--perhaps TIPC or something related to MPI. It's the back door bit that's at issue right now. Should the language provide full explicit support for the intraprocess message passing? ie. move semantics, memory protection, etc? for programming at large, but also a model that's closer to machine than memory sharing. I think I see what your getting at,.. even for shared memory on a deep cache; the cache invalidation system /is/ your message path. Yeah kinda. Look at NUMA machines, for example (SPARC, etc). I expect that NUMA architectures will become increasingly common in the coming years, and it makes total sense to try and build a language that expects such a model.
Re: Source control for all dmd source
Frits van Bommel wrote: Thomas Lindquist Sorry about the misspelling there, Tomas. I get annoyed when people misspell my name, and now I'm doing it too... :(
Re: static this sucks, we should deprecate it
Walter Bright wrote:
It's unreliable because how do you specify the load order? And how does
the user relate that to the source semantics?
grauzone suggested this earlier:
static this {} //full dependencies (all import statements)
static this : a, b {} //only dependent from module a and b
static this : void {} //no dependencies at all
Re: Bartosz Milewski Missing post
Andrei Alexandrescu, el 28 de mayo a las 19:52 me escribiste: > To me, adding concurrency capabilities to D is nothing like adding window > dressing on top of whatever crap is there. Java and C++ are in trouble, and > doing what they do doesn't strike me as a good bet. You're right about > missing > the train, but I think you and I are talking about different trains. I don't > want to embark on the steam-powered train. I agree. Maybe is just unjustified fear, but I see D2 being to concurrency what C++ was to templates. Great new idea, terrible hard to use and understand for mortals. For some time people used to think they were complex because they had to, but I think D could prove that wrong ;) -- Leandro Lucarella (luca) | Blog colectivo: http://www.mazziblog.com.ar/blog/ GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145 104C 949E BFB6 5F5A 8D05)
Re: Cuda for C++
On Fri, 29 May 2009 07:28:00 -0400, Trass3r wrote: bearophile schrieb: "Thrust is a CUDA library of parallel algorithms with an interface resembling the C++ Standard Template Library (STL). Thrust provides a flexible high-level interface for GPU programming": http://code.google.com/p/thrust/ Something like this (but OpenCL) for D sounds quite interesting. Hopefully OpenCL's runtime will be compatible to D's: Chris R Miller wrote (in Feb): > I looked into writing CUDA with D a while back. The problem is that the > CUDA C runtime and the D runtime are 100% incompatible. I don't have any new information about the topic though. Maybe it works with druntime. Umm... I've gotten D's and CUDA's runtime to play nice together.
Re: Source control for all dmd source
Sean Kelly wrote: Jason House wrote: Over in D.anounce, the LDC devs said they would have an easier time upgrading to newer dmd (fe) versions if the source was in source control. Even if Walter is the only one with write access, it's still be helpful. It's helpful for more than just the LDC folks; that's just the most recent example. It would be nice to have DMD in version control, but I don't buy the LDC argument. It's trivial to diff one release against another, regardless of whether version control is involved. It's probably just easier what a change is for[1] if it's small and self-contained, with a description (commit message) of what it's supposed to do. But that's just a guess, you'd have to ask Thomas Lindquist since he's the one that usually merges new frontend versions. [1]: And thus what to do in case of conflicts, as well as what may need to change in the backend (if anything).
Re: Source control for all dmd source
Jason House wrote: Over in D.anounce, the LDC devs said they would have an easier time upgrading to newer dmd (fe) versions if the source was in source control. Even if Walter is the only one with write access, it's still be helpful. It's helpful for more than just the LDC folks; that's just the most recent example. It would be nice to have DMD in version control, but I don't buy the LDC argument. It's trivial to diff one release against another, regardless of whether version control is involved.
Re: Source control for all dmd source
On 29.05.2009 16:26, dennis luehring wrote: On 29.05.2009 15:18, Jason House wrote: Over in D.anounce, the LDC devs said they would have an easier time upgrading to newer dmd (fe) versions if the source was in source control. Even if Walter is the only one with write access, it's still be helpful. It's helpful for more than just the LDC folks; that's just the most recent example. How about it Walter? IIRC, Andrei has been encouraging you to do this for awhile now. maybe on dsource.org like phobos 1/2 - seams to work realy good for walter and andrei (and all others) does all include optlink sources, too? :-)
Re: Source control for all dmd source
On 29.05.2009 15:18, Jason House wrote: Over in D.anounce, the LDC devs said they would have an easier time upgrading to newer dmd (fe) versions if the source was in source control. Even if Walter is the only one with write access, it's still be helpful. It's helpful for more than just the LDC folks; that's just the most recent example. How about it Walter? IIRC, Andrei has been encouraging you to do this for awhile now. maybe on dsource.org like phobos 1/2 - seams to work realy good for walter and andrei (and all others)
Re: Source control for all dmd source
On Fri, 29 May 2009 17:53:42 +0400, Georg Wrede wrote: > Jason House wrote: >> Over in D.anounce, the LDC devs said they would have an easier time >> upgrading to newer dmd (fe) versions if the source was in source >> control. Even if Walter is the only one with write access, it's still >> be helpful. It's helpful for more than just the LDC folks; that's >> just the most recent example. >> How about it Walter? IIRC, Andrei has been encouraging you to do >> this for awhile now. > > I don't see that it necessarily has to be Walter. > > It could even be automated. Ideas? There is no problem in having third-party source control system. Problem is, commits once per month without any description are practically worthless, everyone can diff one DMD version against another.
Re: Source control for all dmd source
Jason House wrote: Over in D.anounce, the LDC devs said they would have an easier time upgrading to newer dmd (fe) versions if the source was in source control. Even if Walter is the only one with write access, it's still be helpful. It's helpful for more than just the LDC folks; that's just the most recent example. How about it Walter? IIRC, Andrei has been encouraging you to do this for awhile now. I don't see that it necessarily has to be Walter. It could even be automated. Ideas?
Source control for all dmd source
Over in D.anounce, the LDC devs said they would have an easier time upgrading to newer dmd (fe) versions if the source was in source control. Even if Walter is the only one with write access, it's still be helpful. It's helpful for more than just the LDC folks; that's just the most recent example. How about it Walter? IIRC, Andrei has been encouraging you to do this for awhile now.
HotOS 2009
A colleague at UW posted these links from HotOS 2009: http://matt-welsh.blogspot.com/2009/05/hotos-2009-day-one.html http://matt-welsh.blogspot.com/2009/05/hotos-2009-day-two.html http://matt-welsh.blogspot.com/2009/05/hotos-2009-day-three.html The full program can be found here: http://www.usenix.org/events/hotos09/tech/ One paper related to our discussion about concurrency was: http://www.usenix.org/event/hotos09/tech/full_papers/baumann/baumann_html/ which has an interesting discussion of sharing memory and passing messages. Andrei
HotOS 2009
A colleagues at UW posted these links from HotOS 2009: http://matt-welsh.blogspot.com/2009/05/hotos-2009-day-one.html http://matt-welsh.blogspot.com/2009/05/hotos-2009-day-two.html http://matt-welsh.blogspot.com/2009/05/hotos-2009-day-three.html The full program can be found here: http://www.usenix.org/events/hotos09/tech/ One paper related to our discussion about concurrency was: http://www.usenix.org/event/hotos09/tech/full_papers/baumann/baumann_html/ which has an interesting discussion of sharing memory and passing messages. Andrei
Re: Cuda for C++
On Fri, 29 May 2009 15:28:00 +0400, Trass3r wrote: > bearophile schrieb: >> "Thrust is a CUDA library of parallel algorithms with an interface >> resembling the C++ Standard Template Library (STL). Thrust provides a >> flexible high-level interface for GPU programming": >> http://code.google.com/p/thrust/ >> Something like this (but OpenCL) for D sounds quite interesting. >> > > Hopefully OpenCL's runtime will be compatible to D's: > > Chris R Miller wrote (in Feb): > > I looked into writing CUDA with D a while back. The problem is that > the > > CUDA C runtime and the D runtime are 100% incompatible. > > > I don't have any new information about the topic though. Maybe it works > with druntime. Yeah, OpenCL looks interesting. For example, they annotate variables with either __global, __local or __private attributes, that are very close to D2 shared/TLS/unique.
Re: Cuda for C++
bearophile schrieb: "Thrust is a CUDA library of parallel algorithms with an interface resembling the C++ Standard Template Library (STL). Thrust provides a flexible high-level interface for GPU programming": http://code.google.com/p/thrust/ Something like this (but OpenCL) for D sounds quite interesting. Hopefully OpenCL's runtime will be compatible to D's: Chris R Miller wrote (in Feb): > I looked into writing CUDA with D a while back. The problem is that the > CUDA C runtime and the D runtime are 100% incompatible. I don't have any new information about the topic though. Maybe it works with druntime.
Re: static this sucks, we should deprecate it
Christopher Wright wrote: The compiler could examine the symbols used in the static constructors to build these dependency lists. Eh, this would have to extend to every function, since static ctors can call functions. And these functions can be provided without implementations via a .di file. This is fail.
Cuda for C++
"Thrust is a CUDA library of parallel algorithms with an interface resembling the C++ Standard Template Library (STL). Thrust provides a flexible high-level interface for GPU programming": http://code.google.com/p/thrust/ Something like this (but OpenCL) for D sounds quite interesting. Bye, bearophile
Re: [OT] Convention of Communication
Simen Kjaeraas Wrote: > I'm doing it. Mostly 'cause of gmail's filter being good. I think two > spam messages have made it past it since I got the account, some 4 years > ago. 'course, if you got a crappy mail provider, it might not be as good > an idea. Yeah, spam fighting is the best application for computers.
