3 ms·
Looks like it. Section 4.1 eliminates lower level languages on code size, and 4.2 eliminates higher level languages on performance. The challenge in C form woul
by quickben 8y ago
Looks like it. Section 4.1 eliminates lower level languages on code size, and 4.2 eliminates higher level languages on performance. The challenge in C form would be:
Create a better string copy way:
while (*d++ = *s++);
- simondanisch 8y agoas i said, if it makes sense, i'd totally allow using external libraries! maybe i should make that clearer since quite a few people get hung up on that
- quickben 8y agoA few of us perceive it as unrealistic, because it's too restrictive. C/C++ are general programming languages and I feel I am flat out eliminated before even starting. So if you didn't target the general programming languages, who did you want to target with the challenge? Also, heck, it's a challenge, we all want in, please make it so :)
- simondanisch 8y agoMakes sense. I will try to update the article! Feel free to use whatever library that helps you to compose your program nicely. It would be nice though, if those libraries were in a set of standard libraries ;) If you need to implement all helpers yourself, my point "in Julia, you can just sit down and start implementing a pretty difficult problem" would become a bit watered down... First of all, Julia is also pretty multi-purpose - and secondly, if you put it to the extreme, you could just write a DSL that you parse in C++ that is perfectly tailored to the problem, and consider the challenge as won :P
- quickben 8y agoYes but, then we can draw some scientific conclusion. If I can outperform Julia by 50% in C++, but I have to write 10x code. I won't bother with C++. If you manage to have that in the end, that's a very valuable promotional information. For one of my master courses, I had to write 200 lines in python. C++ solution would have been in the thousands. My colleague solved it in 10 R lines. R is on my list now :)
- oldandtired 8y agoIn Unicon/Icon d := s Strings are immutable, so it internally just copies a descriptor.
- ummonk 8y agoThis is how you get buffer overflows...
- Someone 8y agohttps://sourceware.org/git/?p=glibc.git;a=blob;f=string/strcpy.c;h=a4cce892df1fa6821128efaf203865f862027587;hb=refs/heads/release/2.28/master https://sourceware.org/git/?p=glibc.git;a=blob;f=string/strc...: return memcpy (dest, src, strlen (src) + 1); I think the logic is that strlen is virtually free for short strings, and that memcpy can be a lot faster for long ones (reading https://sourceware.org/git/?p=glibc.git;a=blob;f=string/memcpy.c;h=ecfa2218472d1c6d136ba6849620a813349fa65b;hb=refs/heads/release/2.28/master https://sourceware.org/git/?p=glibc.git;a=blob;f=string/memc..., it even copies “whole pages from SRCP to DSTP by virtual address manipulation, as much as possible”. strlen doesn’t do things the K&R way either anymore. It checks one byte at a time until things are word aligned, then checks words for zero bytes. That can read from past the string, so it requires the platform it runs on to make that OK. See https://sourceware.org/git/?p=glibc.git;a=blob;f=string/strlen.c;h=8ce131848710f0aa8fce0d9d12d6198cc6f0c613;hb=refs/heads/release/2.28/master https://sourceware.org/git/?p=glibc.git;a=blob;f=string/strl...)