Comments for luminance http://www.luminance.org/blog Programming and Game Development - Kevin Gadd's Blog Wed, 18 Jan 2012 18:18:28 +0000 hourly 1 http://wordpress.org/?v=3.3.1 Comment on Tiled map loader for XNA by Anne http://www.luminance.org/blog/code/2009/06/17/tiled-map-loader-for-xna/comment-page-1#comment-5149 Anne Wed, 18 Jan 2012 18:18:28 +0000 http://www.luminance.org/?p=495#comment-5149 I had the exact same error as Soldat, but after following Kael's instructions, I managed to work it out and it runs fine now. I had the exact same error as Soldat, but after following Kael’s instructions, I managed to work it out and it runs fine now.

]]> Comment on A Journey Into Linker Hell, And A Mistake by Archaeopteryx http://www.luminance.org/blog/code/2011/08/01/a-journey-into-linker-hell-and-a-mistake/comment-page-1#comment-4741 Archaeopteryx Thu, 04 Aug 2011 08:28:29 +0000 http://www.luminance.org/?p=1013#comment-4741 Could https://bugzilla.mozilla.org/show_bug.cgi?id=479148 be the shutdown you see? Could https://bugzilla.mozilla.org/show_bug.cgi?id=479148 be the shutdown you see?

]]> Comment on A Journey Into Linker Hell, And A Mistake by Trillian http://www.luminance.org/blog/code/2011/08/01/a-journey-into-linker-hell-and-a-mistake/comment-page-1#comment-4738 Trillian Tue, 02 Aug 2011 21:45:49 +0000 http://www.luminance.org/?p=1013#comment-4738 This sounds like my daily job, but it was still interesting to see your way of approaching the problem. Thanks for the tips! This sounds like my daily job, but it was still interesting to see your way of approaching the problem. Thanks for the tips!

]]> Comment on A Journey Into Linker Hell, And A Mistake by Brant Gurganus http://www.luminance.org/blog/code/2011/08/01/a-journey-into-linker-hell-and-a-mistake/comment-page-1#comment-4736 Brant Gurganus Tue, 02 Aug 2011 13:38:37 +0000 http://www.luminance.org/?p=1013#comment-4736 I ran into a similar dual heap issue in the past. We were using a project with GTK/GLIB using the pre-compiled libraries. The issue is that GLIB exposes (at least at the time) g_malloc but not g_free. As a result, it's impossible to free the memory without a crash as the prebuilt GTK/GLIB links against msvcrt.dll (something that shouldn't be done) and the main project builds against a version-specific C library like msvcrt700.dll. So you crash if you try to free that memory. So my lesson there is if you ever do an API that exposes a resource like that, you also need to expose the resource release mechanism as well. Otherwise, you either have a crash from mismatched heaps or a memory leak from unfreed memory. I ran into a similar dual heap issue in the past. We were using a project with GTK/GLIB using the pre-compiled libraries. The issue is that GLIB exposes (at least at the time) g_malloc but not g_free. As a result, it’s impossible to free the memory without a crash as the prebuilt GTK/GLIB links against msvcrt.dll (something that shouldn’t be done) and the main project builds against a version-specific C library like msvcrt700.dll. So you crash if you try to free that memory. So my lesson there is if you ever do an API that exposes a resource like that, you also need to expose the resource release mechanism as well. Otherwise, you either have a crash from mismatched heaps or a memory leak from unfreed memory.

]]> Comment on A Journey Into Linker Hell, And A Mistake by Neil Rashbrook http://www.luminance.org/blog/code/2011/08/01/a-journey-into-linker-hell-and-a-mistake/comment-page-1#comment-4735 Neil Rashbrook Tue, 02 Aug 2011 11:46:29 +0000 http://www.luminance.org/?p=1013#comment-4735 In theory you can link NSPR and XUL against different CRTs because NSPR exposes free functions for all of its allocators, and most of the codebase takes care to match its allocators, although there are still one or two places that don't. In jemalloc builds this isn't a problem, because both NSPR and XUL are tricked into linking against the jemalloc allocator. In theory you can link NSPR and XUL against different CRTs because NSPR exposes free functions for all of its allocators, and most of the codebase takes care to match its allocators, although there are still one or two places that don’t.

In jemalloc builds this isn’t a problem, because both NSPR and XUL are tricked into linking against the jemalloc allocator.

]]> Comment on A Journey Into Linker Hell, And A Mistake by dfarmer http://www.luminance.org/blog/code/2011/08/01/a-journey-into-linker-hell-and-a-mistake/comment-page-1#comment-4734 dfarmer Tue, 02 Aug 2011 04:20:23 +0000 http://www.luminance.org/?p=1013#comment-4734 I learned a few debugging tips and was entertained. Mission accomplished ;) Thanks for sharing. I learned a few debugging tips and was entertained. Mission accomplished ;) Thanks for sharing.

]]> Comment on A Journey Into Linker Hell, And A Mistake by Kael http://www.luminance.org/blog/code/2011/08/01/a-journey-into-linker-hell-and-a-mistake/comment-page-1#comment-4733 Kael Tue, 02 Aug 2011 03:48:08 +0000 http://www.luminance.org/?p=1013#comment-4733 I think switching from strdup to _strdup would provide linker behavior equivalent to that for free(), so they'd at least pick the same .dll. The question is whether this would cause problems with other libraries - like, what happens if nspr4.dll imports everything from the debug runtime, but xul.dll imports everything from the release runtime? More heap corruption failures, but now they'll span modules. On the other hand, I guess cross-module free/malloc on Windows rarely works anyway, because each module gets its own heap... I think switching from strdup to _strdup would provide linker behavior equivalent to that for free(), so they’d at least pick the same .dll. The question is whether this would cause problems with other libraries – like, what happens if nspr4.dll imports everything from the debug runtime, but xul.dll imports everything from the release runtime? More heap corruption failures, but now they’ll span modules. On the other hand, I guess cross-module free/malloc on Windows rarely works anyway, because each module gets its own heap…

]]> Comment on A Journey Into Linker Hell, And A Mistake by azakai http://www.luminance.org/blog/code/2011/08/01/a-journey-into-linker-hell-and-a-mistake/comment-page-1#comment-4732 azakai Tue, 02 Aug 2011 03:35:11 +0000 http://www.luminance.org/?p=1013#comment-4732 Amusing and interesting! So, what can be done here? Is this fixed if we replace strdup with _strdup? Amusing and interesting!

So, what can be done here? Is this fixed if we replace strdup with _strdup?

]]> Comment on Performance Challenges in Compiling Code to JavaScript by azakai http://www.luminance.org/blog/code/2011/06/18/performance-challenges-in-compiling-code-to-javascript/comment-page-1#comment-4654 azakai Sat, 18 Jun 2011 22:49:36 +0000 http://www.luminance.org/?p=1001#comment-4654 > My personal perspective is that if you’re producing javascript, readability and debugger friendliness need to be a primary priority – at least until tools like Firebug and the Chrome debugger understand the concept of JavaScript as an intermediate language, and can map compiled JavaScript back to the original source code. SpiderMonkey should be able to do this already, with syntax like //@line 7 "srcFile.c" I haven't tried it out myself though. > My personal perspective is that if you’re producing javascript, readability and debugger friendliness need to be a primary priority – at least until tools like Firebug and the Chrome debugger understand the concept of JavaScript as an intermediate language, and can map compiled JavaScript back to the original source code.

SpiderMonkey should be able to do this already, with syntax like

//@line 7 “srcFile.c”

I haven’t tried it out myself though.

]]> Comment on Performance Challenges in Compiling Code to JavaScript by Kael http://www.luminance.org/blog/code/2011/06/18/performance-challenges-in-compiling-code-to-javascript/comment-page-1#comment-4653 Kael Sat, 18 Jun 2011 17:45:50 +0000 http://www.luminance.org/?p=1001#comment-4653 <blockquote> <a href="#comment-4652" rel="nofollow"> <strong><em>null:</em></strong> </a> <p>Content omitted</p> </blockquote>I haven't done extensive comparative benchmarking, but a few of my test cases are pulled from that old alioth benchmark shootout, and on the ones that aren't heavily dependent on value type semantics, Spidermonkey (with -j and -m) performs on par with debug-mode C#. In some cases, it actually performs slightly better. I'm not sure how much of the difference is due to startup overhead for the C# jit or startup overhead for SM's tracer/jit, though. Compiling .NET using the Mono LLVM backend + Emscripten would be an interesting experiment. I think struct based code would probably perform a lot better, but on the other hand, I think you'd end up with the Mono Boehm GC running inside the Spidermonkey GC, and that seems like it would be suboptimal to say the least... My translation approach could probably also be used to generate Emscripten style code as well, if you got serious about going with a similar 'array representing memory, no reference types' model. It would be interesting to see if that would produce better performance, but the need to preserve C# class garbage collection semantics seems like it would prevent it from being truly useful. My personal perspective is that if you're producing javascript, readability and debugger friendliness need to be a primary priority - at least until tools like Firebug and the Chrome debugger understand the concept of JavaScript as an intermediate language, and can map compiled JavaScript back to the original source code. It's already so hard to debug cross-browser javascript that the idea of asking people to debug complete gibberish seems likely to send them screaming into the arms of Flash or Silverlight.


null:

Content omitted

I haven’t done extensive comparative benchmarking, but a few of my test cases are pulled from that old alioth benchmark shootout, and on the ones that aren’t heavily dependent on value type semantics, Spidermonkey (with -j and -m) performs on par with debug-mode C#. In some cases, it actually performs slightly better. I’m not sure how much of the difference is due to startup overhead for the C# jit or startup overhead for SM’s tracer/jit, though.

Compiling .NET using the Mono LLVM backend + Emscripten would be an interesting experiment. I think struct based code would probably perform a lot better, but on the other hand, I think you’d end up with the Mono Boehm GC running inside the Spidermonkey GC, and that seems like it would be suboptimal to say the least…

My translation approach could probably also be used to generate Emscripten style code as well, if you got serious about going with a similar ‘array representing memory, no reference types’ model. It would be interesting to see if that would produce better performance, but the need to preserve C# class garbage collection semantics seems like it would prevent it from being truly useful.

My personal perspective is that if you’re producing javascript, readability and debugger friendliness need to be a primary priority – at least until tools like Firebug and the Chrome debugger understand the concept of JavaScript as an intermediate language, and can map compiled JavaScript back to the original source code. It’s already so hard to debug cross-browser javascript that the idea of asking people to debug complete gibberish seems likely to send them screaming into the arms of Flash or Silverlight.

]]>