Re: Please say hello to our third team member: Razvan Nitu
On Tuesday, 18 October 2016 at 18:21:31 UTC, Andrei Alexandrescu wrote: Hi everyone, Please join me in welcoming Razvan Nitu to our fledgling team of Romanian graduate students. Razvan has already some solid industrial experience and has a broad area of interests such as low-level kernel-level development, networking, distributed filesystems, and more. We're sure he'll find something to pique his interest :o). We are setting up the team in an office at University "Politehnica" Bucharest, close to their academic advisors. For now they're in bootcamp getting familiar with our toolchain. Please help me in getting everyone up to speed. Welcome, Razvan! Andrei Would you happen to know who of them is most interested in compiler development. I would like to delegate tasks like printing string-mixins.
Re: Battle-plan for CTFE
On Monday, 17 October 2016 at 00:56:01 UTC, Uplink_Coder wrote: If anyone want to take a look the lastest llvm_backend development is happening here : https://github.com/UplinkCoder/dmd/blob/_ctfe/src/bc_llvm_backend.d The time llvm takes to build it's IR and execute the JITed code is absolutely too much! multiple milliseconds! I will write a very simple x86 codegenerator tomorrow.
Re: Battle-plan for CTFE
On Sunday, 16 October 2016 at 13:51:55 UTC, Uplink_Coder wrote: On Sunday, 16 October 2016 at 10:58:57 UTC, Dmitry Olshansky wrote: That LLVM thing is surely nice to have but I highly doubt it will be allowed as dependency for DMD. --- Dmitry Olshansky LLVM is purely optional. A pure D interpreter exists. LLVM optimises most ctfe btw and returns constants. If anyone want to take a look the lastest llvm_backend development is happening here : https://github.com/UplinkCoder/dmd/blob/_ctfe/src/bc_llvm_backend.d
Re: Battle-plan for CTFE
On Wednesday, 5 October 2016 at 08:34:06 UTC, Rory McGuire wrote: No worries, I've been watching this space for over a decade. I really believe you are working on one of the most important parts of IT for the next decade. I am planning/making a library that uses CTFE extensively and feel much more confident about it purely because of your work on getting CTFE performance to be a non-issue. R Little update here: The LLVM backend is almost on feature parity. Meaning that that soon the new CTFE engine is a real jit. In the process I discoverd quite a few horrible bugs and inconsistency in the API. I am quite astonished that it ever ran before :)
Re: Battle-plan for CTFE
On Sunday, 16 October 2016 at 10:58:57 UTC, Dmitry Olshansky wrote: That LLVM thing is surely nice to have but I highly doubt it will be allowed as dependency for DMD. --- Dmitry Olshansky LLVM is purely optional. A pure D interpreter exists. LLVM optimises most ctfe btw and returns constants.
