Re: Button: A fast, correct, and elegantly simple build system.
On Mon, Jun 27, 2016 at 2:23 AM, Jason White via Digitalmars-d-announce < digitalmars-d-announce@puremagic.com> wrote: > On Monday, 20 June 2016 at 08:21:29 UTC, Dicebot wrote: > >> On Monday, 20 June 2016 at 02:46:13 UTC, Jason White wrote: >> >>> This actually sounds nice. Main problem that comes to my mind is that there is no cross-platform shell script. Even if it is list of plain unconditional commands there are always differences like normalized path form. Of course, one can always generate `build.d` as a shell script, but that would only work for D projects and Button is supposed to be a generic solution. >>> >>> I'd make it so it could either produce a Bash or Batch script. Possibly >>> also a PowerShell script because error handling in Batch is awful. That >>> should cover any platform it might be needed on. Normalizing paths >>> shouldn't be a problem either. >>> >>> This should actually be pretty easy to implement. >>> >> >> Will plain sh script script also work for MacOS / BSD flavors? Committing >> just two scripts is fine but I wonder how it scales. >> > > FYI, I implemented this feature today (no Batch/PowerShell output yet > though): > > http://jasonwhite.github.io/button/docs/commands/convert > > I think Bash should work on most Unix-like platforms. > And there is this[0] for windows, if you wanted to try bash on windows: [0]: https://msdn.microsoft.com/en-us/commandline/wsl/about
Re: 4x faster strlen with 4 char sentinel
On Monday, 27 June 2016 at 05:27:12 UTC, chmike wrote: Ending strings with a single null byte/char is to save space. It was critical in the 70´s when C was created and memory space was very limited. That's not the case anymore and I guess the Not only to save space, some CPUs also had cheap incrementing load/stores and branching on zero is faster than sacrificing another register for a counter. IIRC Pascal has a short string with a single byte length. Besides there are plenty of other advantages to using a terminating sentinel depending on the use scenario. E.g. if you want many versions of the same tail or if you are splitting a string at white space (overwrite a white space char with a zero).
Re: 4x faster strlen with 4 char sentinel
On Monday, 27 June 2016 at 05:10:37 UTC, chmike wrote: If you store the string size in a four byte field, you get a hard to beat fast strlen. :) If you have the constrain to work with null terminated strings, then it could be interesting to look at SIMD as was suggested or use one of the following algorithms to test the presence of a 0 byte in a 4 byte or 8 byte integer when simd is not available. https://graphics.stanford.edu/~seander/bithacks.html#ZeroInWord Ending strings with a single null byte/char is to save space. It was critical in the 70´s when C was created and memory space was very limited. That's not the case anymore and I guess the reason why you assume that ending a string with 4 null chars is OK.
Re: 4x faster strlen with 4 char sentinel
If you store the string size in a four byte field, you get a hard to beat fast strlen. :)
Re: Button: A fast, correct, and elegantly simple build system.
On Monday, 20 June 2016 at 08:21:29 UTC, Dicebot wrote: On Monday, 20 June 2016 at 02:46:13 UTC, Jason White wrote: This actually sounds nice. Main problem that comes to my mind is that there is no cross-platform shell script. Even if it is list of plain unconditional commands there are always differences like normalized path form. Of course, one can always generate `build.d` as a shell script, but that would only work for D projects and Button is supposed to be a generic solution. I'd make it so it could either produce a Bash or Batch script. Possibly also a PowerShell script because error handling in Batch is awful. That should cover any platform it might be needed on. Normalizing paths shouldn't be a problem either. This should actually be pretty easy to implement. Will plain sh script script also work for MacOS / BSD flavors? Committing just two scripts is fine but I wonder how it scales. FYI, I implemented this feature today (no Batch/PowerShell output yet though): http://jasonwhite.github.io/button/docs/commands/convert I think Bash should work on most Unix-like platforms.
[Semi OT] About code review
Several people during DConf asked abut tips and tricks on code review. So I wrote an article about it: http://www.deadalnix.me/2016/06/27/on-code-review/
Re: 4x faster strlen with 4 char sentinel
On Sunday, 26 June 2016 at 16:59:54 UTC, David Nadlinger wrote: Please keep general discussions like this off the announce list, which would e.g. be suitable for announcing a fleshed out collection of high-performance string handling routines. A couple of quick hints: - This is not a correct implementation of strlen, as it already assumes that the array is terminated by four zero bytes. That iterating memory with a stride of 4 instead of 1 will be faster is a self-evident truth. - You should be benchmarking against a "proper" SIMD-optimised strlen implementation. — David This is more of just an observation that the choice of the single zero sentinel for C string termination comes at a cost of 4x strlen speed vs using four terminating zeros. I don't see a SIMD strlen implementation in the D libraries. The strlen2 function I posted works on any string that is terminated by four zeros, and returns the same len as strlen in that case, but much faster. How to get strings initialized with four terminating zeros at compile time is a separate issue. I don't know the solution, else I might consider doing more with this.
Re: 4x faster strlen with 4 char sentinel
Hi Jay, On Sunday, 26 June 2016 at 16:40:08 UTC, Jay Norwood wrote: After watching Andre's sentinel thing, I'm playing with strlen on char strings with 4 terminating 0s instead of a single one. Seems to work and is 4x faster compared to the runtime version. Please keep general discussions like this off the announce list, which would e.g. be suitable for announcing a fleshed out collection of high-performance string handling routines. nothrow pure size_t strlen2(const(char)* c) { if (c is null) return 0; size_t l=0; while (*c){ c+=4; l+=4;} while (*c==0){ c--; l--;} return l+1; } A couple of quick hints: - This is not a correct implementation of strlen, as it already assumes that the array is terminated by four zero bytes. That iterating memory with a stride of 4 instead of 1 will be faster is a self-evident truth. - You should be benchmarking against a "proper" SIMD-optimised strlen implementation. — David
4x faster strlen with 4 char sentinel
After watching Andre's sentinel thing, I'm playing with strlen on char strings with 4 terminating 0s instead of a single one. Seems to work and is 4x faster compared to the runtime version. nothrow pure size_t strlen2(const(char)* c) { if (c is null) return 0; size_t l=0; while (*c){ c+=4; l+=4;} while (*c==0){ c--; l--;} return l+1; } This is the timing of my test case, which I can post if anyone is interested. strlen\Release>strlen 2738 681
Re: PowerNex - New release of my D kernel
On Sunday, 26 June 2016 at 07:43:37 UTC, Werner wrote: Latest release shows this: http://imgur.com/QOPsqkc.png Looks like you didn't give it enough RAM. What command did you run?
Re: Beta release vibe.d 0.7.29-beta.2
Am 02.06.2016 um 10:27 schrieb Sönke Ludwig: The release candidate is planned for the 6th, so please take a moment to test this release. Instead of `dub upgrade --prerelease`, edit dub.selections.json directly and put 0.7.29-beta.2 as the vibe-d version (there is already an alpha version of 0.7.30 out, so the upgrade would pick that instead). Main changes over 0.7.28: - Drops support for DMD frontend 2.066.x and below and adds support up to 2.071.0 - Removes all deprecated functionality, as well as the libev driver - Contains considerable performance improvement for URLRouter - Contains a critical fix for the Json struct, which was prone to dangling pointers due to wrong alignment on x64 - Hopefully removes all instances of "Manually resuming taks that is already scheduled" assertion failures The first release candidate is now out! All changes: https://github.com/rejectedsoftware/vibe.d/blob/master/CHANGELOG.md DUB package: http://code.dlang.org/packages/vibe-d/0.7.29-rc.1
Re: PowerNex - New release of my D kernel
Latest release shows this: http://imgur.com/QOPsqkc.png
Re: Project Highlight: The PowerNex Kernel
On Saturday, 25 June 2016 at 18:42:20 UTC, Wild wrote: On Friday, 24 June 2016 at 15:09:41 UTC, Satoshi wrote: On Friday, 24 June 2016 at 14:09:12 UTC, Mike Parker wrote: Not that long ago, Dan Printzell announced his D OS Kernel, PowerNex [1], in this forum. It is now the subject of the first project highlight on the D Blog [2]. [1] https://github.com/Vild/PowerNex [2] http://dlang.org/blog/2016/06/24/project-highlight-the-powernex-kernel/ Its funny how he took existing sources from my OS https://github.com/Rikarin/Trinix rewrite it during stream session on Livecoding and get more popularity than my OS. Do you want me to remove all the code that is influenced by your code in the kernel and rewrite from scratch? Because I don't want my project to contain illegal/controversial code. no