Re: 4x faster strlen with 4 char sentinel

2016-06-26 Thread chmike via Digitalmars-d-announce

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

2016-06-26 Thread chmike via Digitalmars-d-announce
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.

2016-06-26 Thread Jason White via Digitalmars-d-announce

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

2016-06-26 Thread deadalnix via Digitalmars-d-announce
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

2016-06-26 Thread Jay Norwood via Digitalmars-d-announce

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

2016-06-26 Thread David Nadlinger via Digitalmars-d-announce

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

2016-06-26 Thread Jay Norwood via Digitalmars-d-announce
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

2016-06-26 Thread Wild via Digitalmars-d-announce

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

2016-06-26 Thread Sönke Ludwig via Digitalmars-d-announce

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

2016-06-26 Thread Werner via Digitalmars-d-announce

Latest release shows this: http://imgur.com/QOPsqkc.png


Re: Project Highlight: The PowerNex Kernel

2016-06-26 Thread Satoshi via Digitalmars-d-announce

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