Thread overview | |||||||||||||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
August 15, 2019 newCTFE Status August 2019 | ||||
---|---|---|---|---|
| ||||
Hi Guys, I had 2 weeks of vacation recently, and I used them to work on newCTFE again. The main addition was enriched internal debug data. Now newCTFE can emit proper dwarf source_locations which used with the gccjit backend. This means given you use the gccjit-backend for newCTFE you can (step through!) ctfe-code. At least in theory ... in reality some of the time there will not be source code for you to step through, (think mixins). Another rather important bugfix was done the handling of for loops, it turned out that for loops without increment statement would not properly behave when `continue` was encountered (they'd jump to the end of the loop instead of the beginning). There are currently 2 main bugs still to be fixed: - 1. floating point corner cases - 2. wrong code on indirections inside closures. It should be noted that I just spent the better part of a week working on the aforementioned 2 issues, and it does not look like they'll be fixed soon. That said, I am hopeful to be able to release newCTFE in 2020! My Thanks to everyone in this forum who encouraged me. Also a special thanks to Johnathan Blow, who's occasional streams on Jai's progress led me to pick up the newCTFE torch again! Cheers, Stefan P.S. the current newCTFE patch has about 17000 additional lines. 10700 of which are actual interpreter and test-code, and the rest are internal testcases, alternative back-ends (LLVM/GCCJIT/C/IR-Printer). Re-basing to newer versions of the compiler will be done once the dmd/druntime/phobos test-suites and my internal tests are passing. |
August 15, 2019 Re: newCTFE Status August 2019 | ||||
---|---|---|---|---|
| ||||
Posted in reply to Stefan Koch | On Thu, Aug 15, 2019 at 09:42:47PM +0000, Stefan Koch via Digitalmars-d wrote: > Hi Guys, > > I had 2 weeks of vacation recently, and I used them to work on newCTFE again. Yes!!! [...] > That said, I am hopeful to be able to release newCTFE in 2020! *celebratory dance* > My Thanks to everyone in this forum who encouraged me. > > Also a special thanks to Johnathan Blow, who's occasional streams on Jai's progress led me to pick up the newCTFE torch again! [...] Go, Stefan, go! Bring newCTFE into a reality! D badly needs this. Non-trivial CTFE is what D can do that no other language I know can. Right now it's seriously hampered by lackluster speed and memory usage; newCTFE can turn this into a huge game-changer. T -- Do not reason with the unreasonable; you lose by definition. |
August 17, 2019 Re: newCTFE Status August 2019 | ||||
---|---|---|---|---|
| ||||
Posted in reply to Stefan Koch | On Thursday, 15 August 2019 at 21:42:47 UTC, Stefan Koch wrote: > Hi Guys, > > I had 2 weeks of vacation recently, and I used them to work on newCTFE again. Nice to see that you keep the ball rolling! […] > It should be noted that I just spent the better part of a week working on the aforementioned 2 issues, and it does not look like they'll be fixed soon. Last time you told me about that other difficult issue, you were able to fix it shortly after. So who knows, maybe you will get a similar breakthrough soon. > That said, I am hopeful to be able to release newCTFE in 2020! That would be great! > My Thanks to everyone in this forum who encouraged me. > > Also a special thanks to Johnathan Blow, who's occasional streams on Jai's progress led me to pick up the newCTFE torch again! Interesting… Keep having fun, Bastiaan. |
August 18, 2019 Re: newCTFE Status August 2019 | ||||
---|---|---|---|---|
| ||||
Posted in reply to Stefan Koch | On Thursday, 15 August 2019 at 21:42:47 UTC, Stefan Koch wrote:
> P.S. the current newCTFE patch has about 17000 additional lines.
> 10700 of which are actual interpreter and test-code, and the rest are internal testcases, alternative back-ends (LLVM/GCCJIT/C/IR-Printer).
>
> Re-basing to newer versions of the compiler will be done once the dmd/druntime/phobos test-suites and my internal tests are passing.
Are you developing this out in the open or are you keeping the code closer to your chest until you are done?
Both are fine with me. I'm mostly curious.
Keep up the good work! You have taken on a beast of a spare time project!
|
August 19, 2019 Re: newCTFE Status August 2019 | ||||
---|---|---|---|---|
| ||||
Posted in reply to Gregor Mückl | On Sunday, 18 August 2019 at 22:18:29 UTC, Gregor Mückl wrote: > Are you developing this out in the open or are you keeping the code closer to your chest until you are done? These branches have been recently updated: https://github.com/UplinkCoder/dmd/tree/newCTFE_reboot_20741 https://github.com/UplinkCoder/dmd/tree/newCTFE_reboot_20741_gccjit |
August 19, 2019 Re: newCTFE Status August 2019 | ||||
---|---|---|---|---|
| ||||
Posted in reply to Stefan Koch | On Thursday, 15 August 2019 at 21:42:47 UTC, Stefan Koch wrote:
>
> That said, I am hopeful to be able to release newCTFE in 2020!
>
Can't wait! We'll be able to make a lot more parsing at compile-time :)
|
August 19, 2019 Re: newCTFE Status August 2019 | ||||
---|---|---|---|---|
| ||||
Posted in reply to Guillaume Piolat | On Monday, 19 August 2019 at 13:37:18 UTC, Guillaume Piolat wrote:
> Can't wait! We'll be able to make a lot more parsing at compile-time :)
My compiles are already at 8GB memory usage thanks to CTFE.
Even just a patch to fix array memory handling behind the scenes would be great. But newCTFE would certainly be the preferred option.
|
August 19, 2019 Re: newCTFE Status August 2019 | ||||
---|---|---|---|---|
| ||||
Posted in reply to Ethan | On 8/19/2019 7:02 AM, Ethan wrote:
> Even just a patch to fix array memory handling behind the scenes would be great.
The memory handling could be fixed if the CTFE's allocated AST's were all allocated from a separate pool, and marked as such. Then, the returned AST from CTFE can be scanned and every marked node replaced. Then, the entire pool can be discarded.
Should be fairly simple to implement.
|
August 20, 2019 Re: newCTFE Status August 2019 | ||||
---|---|---|---|---|
| ||||
Posted in reply to Walter Bright | On Monday, 19 August 2019 at 23:04:23 UTC, Walter Bright wrote:
> On 8/19/2019 7:02 AM, Ethan wrote:
>> Even just a patch to fix array memory handling behind the scenes would be great.
>
> The memory handling could be fixed if the CTFE's allocated AST's were all allocated from a separate pool, and marked as such. Then, the returned AST from CTFE can be scanned and every marked node replaced. Then, the entire pool can be discarded.
>
> Should be fairly simple to implement.
Replying to this to keep the topic on top!
That's an amazing outcome!
What would be also, IYUO, the expected impact on speed performance?
/Paolo
|
August 20, 2019 Re: newCTFE Status August 2019 | ||||
---|---|---|---|---|
| ||||
Posted in reply to Paolo Invernizzi | On 8/20/2019 6:43 AM, Paolo Invernizzi wrote:
> What would be also, IYUO, the expected impact on speed performance?
Probably none, excluding the effects of reduced swapping.
|
Copyright © 1999-2021 by the D Language Foundation