Re: D and GPGPU
On Wednesday, 18 February 2015 at 18:14:19 UTC, luminousone wrote: HSA does work with discrete gpu's and not just the embedded stuff, And I believe that HSA can be used to accelerate OpenCL 2.0, via copyless cache coherent memory access. Unless I'm mistaken, it will more like the opposite: HSA will use OpenCL 2.0 as a backend to do that kind of copyless GPGPU acceleration.
Re: Writing game engine in C++, considering switching to D
On Thursday, 19 February 2015 at 02:08:39 UTC, Will Cassella wrote: Thanks for the replies, everyone! I think I'll try my hand at writing bindings for my existing game engine, as Grøstad suggested - that way I can gradually transition the codebase to D if I like what I see. My 2 cents would be: start with a toy project that stresses a bit resource management (the toy project might as well be the rendering part of your existing engine). The only part of D I really don't like is non-deterministic resource destruction, because it can be really painful when it comes to stuff like OpenGL resources (e.g: if the GC calls any OpenGL function, you get a nice crash since OpenGL is not multithread-aware by default). IMO the first thing you should do, is trying to see if you are able to manage all your critical resources (including OpenGL objects) by using D structs coupled with Unique! and RefCounted! templates you can find in std.typecons module. I highly suggest you to do that, because that is the worst hurdle I had to face during any kind of D + OpenGL development. If you understand how to get stuff done right, you are set, and the rest of the work will be painless and fun.
Re: Writing game engine in C++, considering switching to D
On Friday, 20 February 2015 at 13:44:04 UTC, ponce wrote: On Friday, 20 February 2015 at 13:04:51 UTC, John Colvin wrote: On Friday, 20 February 2015 at 09:57:48 UTC, francesco.cattoglio wrote: (e.g: if the GC calls any OpenGL function, you get a nice crash since OpenGL is not multithread-aware by default). Really? I don't see this in my projects. The GC stops the world, so there shouldn't be any races. Not a race. An OpenGL contect can only active in one thread at once. If the GC calls a destructor from a thread which doesn't have that context active, it will probably crash. Exactly. Unless you do some special work yourself, you can't call OpenGL function from a different thread. It's not a real D problem, in fact, D is probably doing the right thing when it comes to Thread Local Storage and such. It is more of an OpenGL limitation. This is also the reason I can't wait to see OpenGL Next, since there were also promises of far better multithread support.
Re: Thoughts on replacement languages (Reddit + D)
On Monday, 12 January 2015 at 12:23:51 UTC, ponce wrote: Especially since destructors called by GC would release resources from the wrong thread, at the wrong moment, etc. Yeah, I almost forgot about this: destructing GC resources interacting with OpenGL was sooo fun :P
Re: Thoughts on replacement languages (Reddit + D)
On Monday, 12 January 2015 at 13:27:55 UTC, Adam D. Ruppe wrote: On Monday, 12 January 2015 at 11:04:45 UTC, francesco.cattoglio wrote: When the GC collects them the destructor runs close(), which in turn calls for some allocation (e.g: allocates for a string to send to the logger), Do you have to log? I've never had a problem calling C free functions in a class destructor in D. Not me personally, but gfm does that, and I'm not going to remove all the logging from the destructors :P I know the log example is weak, but I really think this issue is still valid. To be completely honest, it is my only real gripe with D.
Re: Thoughts on replacement languages (Reddit + D)
On Sunday, 11 January 2015 at 19:30:59 UTC, ponce wrote: When does invalidMemoryOperationError happen and how do you avoid it? Typical example: using (a slightly outdated version of) gfm library, I have few gfm objects lying around on which I forget to call a close() function. When the GC collects them the destructor runs close(), which in turn calls for some allocation (e.g: allocates for a string to send to the logger), invalidMemoryOperationError pops up. This usually only happens at the end of execution, sometimes however it happens randomly during program execution due to the randomness of GC operations. The only way out of this is manually closing everything correctly. I.e: I'm almost back to C++ manual memory management. Catching the exception is an unsatisfactory solution because I would still be leaking resources[1]. If possible, things are made even worse in that RefCounted doesn't work for classes, but that you can work around that (class instance into refcounted struct, not really elegant and requires lots of discipline, since it's easy to escape an extra reference). [1] For everyone who doesn't know: non trivial destructors are really useful in gfm because it wraps some C libraries, and cleaning up C allocated resources is usually important. Proper execution of gfm's close() for every class would be ideal.
Re: Thoughts on replacement languages (Reddit + D)
On Monday, 12 January 2015 at 15:22:41 UTC, eles wrote: On Monday, 12 January 2015 at 14:34:41 UTC, francesco.cattoglio wrote: On Monday, 12 January 2015 at 13:27:55 UTC, Adam D. Ruppe wrote: On Monday, 12 January 2015 at 11:04:45 UTC, francesco.cattoglio wrote: To be completely honest, it is my only real gripe with D. Yes, but it's at the very root of the language. Not sure about it. Things used to work differently some time ago, if I understand correctly. The GC was changed in order to avoid some memory corruption issues IIRC, before you could allocate during GC cycles.
Re: Thoughts on replacement languages (Reddit + D)
On Sunday, 11 January 2015 at 14:10:56 UTC, ponce wrote: None of them has Visual Studio integration with debugging support and that is pretty important for native and enterprise programmers. If I remember correctly, just 2 month ago someone was explaining how they lost a commercial user because D debugging experience was still not good enough by a long shot. And in my daily use, debug experience is still subpar on windows. only to discover it is not fun enough and fun is more important than memory safety without GC. WHAT? Syntax is boring, but I don't get the sense of the sentence I don't buy in the Rust team stability guarantees, you can't go from pondering about removing box this very week. They have not broken any promise just yet! :P And I somehow hope they can really manage a high level of stability after discussing throughtly this much about every bikeshed topic (including the recent int/uint change). And as soon as Servo is interrupted because of internal politics at Mozilla or rebudgeting (ie. very high probability), Rust will be halted in a heartbeat since loosing its purpose. Ever noticed the Rust original designer jumped off ship long ago? I do agree that this might be a real risk. But the bus factor for the D project ain't the smallest either. D development could grind to a halt if a handful of developers retire from the project. I'm obviously being the devil's advocate here, but we can't just say D is much more far ahead, we have nothing to fear from Go and Rust, because it's just not true. And I say it as a daily D user, daily facing issues like the horrible invalidMemoryOperationError exception.
Re: OT: Minecraft death by GC
On Tuesday, 21 October 2014 at 07:18:28 UTC, ROOAR wrote: So the latest Minecraft apparently runs really really poorly because of the GC. And it is running on Java desktop. The supposedly fast GC of Java can't handle the game anymore-- https://www.reddit.com/r/programming/comments/2jsrif/optifine_dev_minecraft_18_has_so_many_performance/ Take that GC fanatics D needs more action you know. More like: take that you smart business people who buy a bloated piece of for 2.5 BILLION $$$
