A Doom Renderer written in Rust • Hacker News Board

Re: A Doom Renderer written in Rust

#31

Post by pjmlp » Sun, Oct 12, 2014, 6:53 AM UTC

fspeech wrote: post #27

reubenmorais wrote: post #6

Earlier quoted context omitted.

Have you profiled the build? Is most of it spent in the compiler? A more practical point is that the main competitor is C++, a language notorious for long compilation times, so not-ultra-fast compile times might not be the highest priority for people working on rustc.

C++ compilers are very fast (I would say amazingly fast) unfortunately atrocious header only implementations like Boost drags it down. I just did clang++ -E on a single #include of cpp-netlib which depends on Boost asio and the dumped output came to: $ wc test1 279506 897765 10174700 test1 And this is after enabling dynamic linking which cuts down a few thousand lines. Library writers are not giving compiler writers…

Walter Bright, the author of D and the first real C++ native compiler (Zortech C++), explains it

http://www.drdobbs.com/cpp/c-compilation-speed/228701711

Compatibility with C tooling is also a big reason, as templates can only be header only to be consumed by other translation units.

Unfortunately "export template" was a failed experiment.

Now C++ developers need to wait until C++17 for modules, if they ever get into the standard. And if they do, most likely it will take until around 2020 for all major C++ compilers across embedded, desktop and server systems offer support for it.

Now the question is, if one is willing to wait that long or rather use a language that can use modules today.

Re: A Doom Renderer written in Rust

#32

Post by pcwalton » Sun, Oct 12, 2014, 6:53 AM UTC

Alupis wrote: post #30

pcwalton wrote: post #23

Earlier quoted context omitted.

The Rust compiler is much faster than Scala's compiler, from everything I have heard.

really doesn't matter how long the compiler takes, so long as the result is fast.

That's not true; for quick turnaround it's important to be able to get results out of the compiler quickly.

Re: A Doom Renderer written in Rust

#33

Post by chrismorgan » Sun, Oct 12, 2014, 7:19 AM UTC

Alupis wrote: post #30

pcwalton wrote: post #23

Earlier quoted context omitted.

The Rust compiler is much faster than Scala's compiler, from everything I have heard.

really doesn't matter how long the compiler takes, so long as the result is fast.

I want two types of results: when developing, I want fast turnaround and most of the time don’t care about runtime performance; when deploying, I don’t care much about how long it takes to compile, but I want runtime performance to be optimised.

Re: A Doom Renderer written in Rust

#34

Post by mercurial » Sun, Oct 12, 2014, 7:29 AM UTC

Alupis wrote: post #29

why do these post's titles keep getting moderated? "Doom I/II written in Rust" is a fine title for what this is.

The new title is more accurate. I sometimes disagree with moderated titles, but in this case it's not an issue.

Re: A Doom Renderer written in Rust

#35

Post by yen223 » Sun, Oct 12, 2014, 7:47 AM UTC

Stuff like that is the reason why I'm excited for Rust's future. It's really an amazing language.

Re: A Doom Renderer written in Rust

#36

Post by pjc50 » Sun, Oct 12, 2014, 8:22 AM UTC

comex wrote: post #2

This is sort of off topic, but the fact that every change to the source requires (on my machine) 3-4 full seconds to recompile, without optimization, is indicative of the compiler performance problems that remain my main roadblock with Rust.

3-4 seconds is extremely fast if you're coming from the C/C++ world. I can't see how this could possibly be a roadblock.

Re: A Doom Renderer written in Rust

#37

Post by PuercoPop » Sun, Oct 12, 2014, 8:24 AM UTC

A similar project, Quake 2 map renderer written with Julia https://github.com/jayschwa/Quake2.jl

Re: A Doom Renderer written in Rust

#38

Post by temuze » Sun, Oct 12, 2014, 8:50 AM UTC

Holy crap, this is f*ing awesome. Rust has made systems programming exciting for me again.

Seeing well written Rust code like this (also, the repos on Github https://github.com/trending?l=rust) has been a really good learning experience. As a Rust newbie, I only wish there were better examples of testing in public Rust repos.

Re: A Doom Renderer written in Rust

#39

Post by bjz_ » Sun, Oct 12, 2014, 8:51 AM UTC

shmerl wrote: post #9

How does it interact with OpenGL? Using C bindings?

We have a syntax extension that uses kronos' xml registry (https://www.opengl.org/registry/#specfiles) to generate symbol a loader (somewhat like GLEW) at compile time. https://github.com/bjz/gl-rs

Re: A Doom Renderer written in Rust

#40

Post by lultimouomo » Sun, Oct 12, 2014, 9:02 AM UTC

fspeech wrote: post #27

reubenmorais wrote: post #6

Earlier quoted context omitted.

Have you profiled the build? Is most of it spent in the compiler? A more practical point is that the main competitor is C++, a language notorious for long compilation times, so not-ultra-fast compile times might not be the highest priority for people working on rustc.

C++ compilers are very fast (I would say amazingly fast) unfortunately atrocious header only implementations like Boost drags it down. I just did clang++ -E on a single #include of cpp-netlib which depends on Boost asio and the dumped output came to: $ wc test1 279506 897765 10174700 test1 And this is after enabling dynamic linking which cuts down a few thousand lines. Library writers are not giving compiler writers…

While the problems with templates and huge includes are undeniable, I've found in my experience that for a decently size C++ program the linking stage alone can take way more than the 3-4 seconds the GP is talking about.

C and C++ are definitely some hard beasts to compile, even without boost.