Re: DConf 2013 Day 1 Talk 6: Concurrent Garbage Collection for D by Leandro Lucarella
On 5/24/2013 11:12 PM, Diggory wrote: On 64-bit windows there is also the GetWriteWatch function which lets you access the dirty flag in the page table = no page faults = super efficient concurrent generational GC. Just a shame it doesn't exist on 32-bit systems for some reason. There's all sorts of interesting stuff in 64 bit windows :) The user mode thread scheduler is pretty cool. On the flip side: 32 bit is in its twilight days, and I am reasonably confident the next game I work on will be the last one that even supports 32 bits. Then I can finally use all the new 64 bit goodies :) 32 bits will be reserved for phones and tablets (and even then tablets will probably be making the switch pretty soon-ish)
Re: dmd 2.063 beta 5
On 5/23/2013 11:17 PM, Walter Bright wrote: On 5/23/2013 8:53 PM, Steven Schveighoffer wrote: On Thu, 23 May 2013 23:38:32 -0400, Walter Bright newshou...@digitalmars.com wrote: On 5/23/2013 7:38 PM, Steven Schveighoffer wrote: This is one change where ALL code broken by this change is fixable with a simple solution, and at some point, people will have to deal with this. Yes, but it is not so urgent as RIGHT NOW YOU MUST FIX IT. Hence, the warning. If they aren't in the mood to change their code, they don't have to upgrade to the latest compiler. Q: Why do we bother with the whole warning and deprecation thing anyway? A: Because forcing people to conform to our schedule with no warning is a bit presumptuous. Someone writing a library, for example, has to be up to date, and anyone using that library, for another, has to deal with it if it fails to compile. If your code is built from multiple blobs from various places, it is unreasonable to expect them to all instantly and simultaneously upgrade. I would argue the language should be designed with the ability to easily add keywords without breaking things. I would expect a simple implementation to be that each source file needs to be marked up with a version of the compiler it is designed for, and the compiler could tell you that A) you are using what is now a keywords B) compile the code correctly anyway. The lack of this kind of feature is why c++11's new null type is named nullptr, and not null, and why pure virtuals are declared with '=0' instead of a keyword. Arguably c++11's range based for loops are also designed with this constraint (avoid adding a keyword), but is a not ugly like =0 pure virtuals :)
Re: GC vs. Manual Memory Management Real World Comparison
On 9/6/2012 4:30 AM, Peter Alexander wrote: In addition to Walter's response, it is very rare for advanced compiler optimisations to make 2x difference on any non-trivial code. Not impossible, but it's definitely suspicious. I love trying to explain to people our debug builds are too slow because they have instrumented too much of the code, and haven't disabled any of it. A lot of people are pushed into debugging release builds as a result, which is pretty silly. Now there are some pathological cases: non-inlined constructors can sometimes kill in some cases you for 3d vector math type libraries 128 bit SIMD intrinsics with microsofts compiler in debug builds makes horrifically slow code, each operation has its results written to memory and then is reloaded for the next 'instruction'. I believe its two order of magnitudes slower (the extra instructions, plus pegging the read and write ports of the CPU hurt quite a lot too). These tend to be right functions so can be optimized in debug builds selectively . . .
Re: NaNs Just Don't Get No Respect
On 8/20/2012 12:41 AM, Nick Sabalausky wrote: On Sun, 19 Aug 2012 01:21:03 -0500 Sean Cavanaughworksonmymach...@gmail.com wrote: Nobody knows how floats work, without being locked in a closet for a at least a week and told to change their doubles back into floats and fix their code, since thats where 99% of precision problems actually come from. Sorry, I don't understand, where are you saying 99% of precision problems come from? Chaining algorithms together without regard to how the floats are propagated through the system. Also, accumulating lots of values with addition and subtraction can be problematic, as can subtracting two values to near-zero values also leaves you with a most of the error. There is a pretty classic example in 3d graphics: the transform from object space to world space to projection space. Even if these matrices are combined, your geometry can be transformed a very large distance from the world origin and lose a lot of precision in the process. The way to fight this is to use camera instead of world space as much as possible. If you don't do this all the vertices on all the meshes in your world snap to different values at varying rates when they move or the camera moves, causing one of the main forms of z-fighting. Plus the further you get from your world origin the worse things get, which makes building something on the scale of an open-world game rather difficult.
Re: NaNs Just Don't Get No Respect
On 8/19/2012 12:12 AM, dennis luehring wrote: Am 19.08.2012 06:12, schrieb Jonathan M Davis: On Friday, August 17, 2012 17:03:13 Walter Bright wrote: Our discussion on this in the last few days inspired me to write a blog post about it: http://www.reddit.com/r/programming/comments/yehz4/nans_just_dont_get_no_res pect/ http://www.drdobbs.com/cpp/nans-just-dont-get-no-respect/240005723 FWIW, I'm very surprised by how negatively many programmers seem to react to NaN. I think that how D handles it is great. i think many of these programmers seems to think that D is introducing this NaN-Type ... Nobody knows how floats work, without being locked in a closet for a at least a week and told to change their doubles back into floats and fix their code, since thats where 99% of precision problems actually come from.
Re: First working Win64 program!
On 8/12/2012 4:12 PM, Walter Bright wrote: On 8/12/2012 1:38 AM, Alex Rønne Petersen wrote: One question: Will the 32-bit tool chain also be able to use the MSVC runtime and linker eventually? It's not the current plan. Frankly, I think 32 bits is rapidly becoming irrelevant on the desktop. Post windows 8 launch we should start seeing mainstream games shipping 32 and 64 bit binaries together in the same box. We already have moved off of 32 bit in house for our editors and tools. The biggest hangup is Microsoft keeps shipping 32 bit OSes, and we still have to support XP at least through the end of the year. With a little luck Win8 will be the last 32 bit one.
Re: First working Win64 program!
On 8/12/2012 6:43 PM, torhu wrote: On 12.08.2012 23:21, Sean Cavanaugh wrote: Post windows 8 launch we should start seeing mainstream games shipping 32 and 64 bit binaries together in the same box. We already have moved off of 32 bit in house for our editors and tools. The biggest hangup is Microsoft keeps shipping 32 bit OSes, and we still have to support XP at least through the end of the year. With a little luck Win8 will be the last 32 bit one. Can I ask, what are the reasons you want to move to 64 bits on the Windows platform? Is it higher memory requirements or something else? The game with the highest memory use I've got installed is AFAIK Starcraft II, still at only about one GB. And as you know, 64 bit apps can have lower performance than 32 bits in some cases. So I'm curious to know what the reasons are in your case. 32 bit Windows games are capped at around 1.3 GB due to WinXP support. You can get closer to 1.7 GB of address space out of your 32 bit apps when run under 64 bit windows, but thats about it, without playing with /3GB LARGEADDRESSAWARE flags etc. Games that push 1.3 GB or more run the risk of crashing due to both address space fragmentation and running out of memory from the heap. In XP, you also run the risk of crashing when alt-tabing out of the game and back. The video card's address space gets unmapped while you are away, and the app might have fragmented your nice 512 MB of contiguous while processing in the background, which causes the driver to fail to map the device back into your address space when you alt-tab crash, in a pretty much unrecoverable error. Vista fixed this by mapping the resources to the address space when you lock the resources, instead of a huge chunk of the video card when the app had an open and valid (not-lost) device context. Also, having the full address space opens up the ability to store game data into memory mapped files, which can greatly simplify loading data. Halo was designed this way for the XBOX, though for the PC version we had to modify the code to handle loading to alternate addresses with patched fixups if some random dll had taken the prefered load address at startup. Since it was done in 32 bits each level had the same load address, but in 64 bits you could give each environment its own address range, which makes it very nice for getting a new area loaded while you are playing in the previous one (run a separate thread to touch all the new pages etc).
Re: First working Win64 program!
On 8/12/2012 8:15 PM, Andrej Mitrovic wrote: On 8/13/12, Sean Cavanaughworksonmymach...@gmail.com wrote: we had to modify the code Sure enough I've found your name: http://www.microsoft.com/games/mgsgamecatalog/halopccredits.aspx I noticed you before here but never realized you worked on Halo. It's cool to see people of your caliber having interest in D! :) I have a theory that game development accelerates the rate at which you learn to hate C++
Re: First working Win64 program!
On 8/12/2012 8:22 PM, torhu wrote: Ok, so using LARGEADDRESSAWARE doesn't improve the situation on XP 64? What about on Vista 64? On XP64 it would help some, but the video adapter is still mapped to a huge contiguous range due to the XP driver model. Basically you get 1 extra GB (2.3GB effective usable instead of 1.3). Under 64 bit Vista/7 32 bit LAA apps get almost a full 4 GB to play with, and if they change their textures to default pool or use D3D10 or newer can get their texture data out of the app's address space as well, which is a huge percentage of a game's memory usage.
Re: unzip parallel, 3x faster than 7zip
On 4/5/2012 6:53 PM, Jay Norwood wrote: I'm curious why win7 is such a dog when removing directories. I see a lot of disk read activity going on which seems to dominate the delete time. This doesn't make any sense to me unless there is some file caching being triggered on files being deleted. I don't see any virus checker app being triggered ... it all seems to be system read activity. Maybe I'll try non cached flags, write truncate to 0 length before deleting and see if that results in faster execution when the files are deleted... If you delete a directory containing several hundred thousand directories (each with 4-5 files inside, don't ask), you can see windows freeze for long periods (10+seconds) of time until it is finished, which affects everything up to and including the audio mixing (it starts looping etc).
Re: dmd 2.057 release
On 1/3/2012 1:25 PM, Walter Bright wrote: On 1/3/2012 10:55 AM, Alex Rønne Petersen wrote: On 03-01-2012 19:47, Walter Bright wrote: On 1/3/2012 6:49 AM, Alex Rønne Petersen wrote: Perhaps some kind of experimental releases would be better. It could help getting new features out to the community (and thus tested) faster. We call them betas g. But anyone can pull the latest from github and use it, many do. That's not very practical for most users. Some kind of ready-to-download builds would be much better. As others suggested, the auto-tester publishing builds for download would be ideal. Using a nightly build is not very practical for most users, either, probably the same group. Well there is always the google (and mozilla) route of force-feeding the latest binaries to everyone :)
Re: Programming Windows D Examples are now Online!
On 6/21/2011 1:08 AM, Brad Anderson wrote: On Mon, Jun 20, 2011 at 10:14 PM, Andrej Mitrovic andrej.mitrov...@gmail.com mailto:andrej.mitrov...@gmail.com wrote: This is a translation project of Charles Petzold's Programming Windows (5th edition) book code samples. Currently over 120 code samples have been translated into D, with only a few modules remaining. Everything else you need to know is in the Readme file: https://github.com/AndrejMitrovic/DWindowsProgramming The examples were tested on fresh installs of XP and Win7 with the only dependency being DMD v2.053 and an NT operating system. I hope everyone will be able to build these examples without too much trouble. *crosses fingers* Awesome. If only I hadn't sold my copy a month ago :(. It's great that Petzold was OK with you doing this. He's a great author. Code is probably the most interesting technical book I've ever read (sorry, Andrei). I had ported a subset of the WTL functionality over to D for a personal project. This primarily consists of a D version of port of atlcrack.h for creating a message map for an HWND wrapped class, and some template mixins to hook up the message map to a class. The WTL uses the curiously recurring template design, and D can do the same thing, but is also able to use mixins which makes things a lot more flexible. The message handlers and bindings a bulk of the annoying work, so while my 'DWindow' class was only filled in just enough to function for my app, filling out Win32 API calls as needed is pretty trivial, compared to making all the message handlers typesafe and extract their arguments properly. I am not working on this at the moment but it would be a good starting point especially if you are working with GDI directly. I am also still quite new to D so style or alternative techniques available in the language might have been overlooked. Message cracking and handler binding helpers (dwindowmessages.d): http://codepad.org/0ApNSvas Simple 'DWindow' and MSG class and aliases (dwindow.d) http://codepad.org/Q4Flyanw A 'GameWindow' class with a bunch of message handlers hooked up correctly, and the message pump. http://codepad.org/JJpfqE7a win32fix.d, stuff that should be in the win32 bindings on the bindings web site but isn't (I was using rawinput for the mouse which is rather esoteric to most programmers). They are also missing from the Microsoft C/C++ headers, they are that obscure :) http://codepad.org/xA18pGEX
