seb.wilzba.ch
Creating the big csv file:
rdmd --eval='10.iota.map!(a => "field".text(a)).join(",").repeat(10_000_000).joiner(newline).writeln' > input_big.csv
D: pastebin.com
real 0m17.875s
user 0m16.826s
sys 0m0.800s
Nim: pastebin.com
real 0m17.882s
user 0m16.977s
sys 0m0.810s
C++17: pastebin.com
real 0m17.447s
user 0m15.660s
sys 0m0.887s
Rust: pastebin.com
real 0m8.496s
user 0m5.792s
sys 0m1.219s
>zero-cost abstraction
>Some obscure "competition" that only Rust faggots competed in or knew about.
The competition is meant for C++ faggots originally, hence its free for anyone to participate.
From that link it looks like D won.
It's just some guy optimising shit after the fact
Did you read the C++ solution? Any above-average student could write a faster solution in C.
>All these programmers competing for the most "expressive" code
>An office drone could shit out a more expressive Excel macro without wasting hours of company time
I'd like to see how long would it take Excel to perform this task on 640MB CSV file.
>I'd like to see how long would it take Excel to perform this task on 640MB CSV file.
Probably about one coffee break.
>his boss doesn't want him shitting all over their database with sloppily written, unproven, UB filled C++ code written PER PROBLEM
>his office doesnt only hire CS grads to write said tools daily just to manage excel files
pleb tier
optimize your buffers
How?
Probably because Rust string splitting uses iterators to avoid heap allocations, while the C++17 (and I assume the others too) string split used a vector like a retard.
this
Looks like you're only looking at the sys time and not real+user+sys.
Rust is over twice as fast.
Or do you mean D wins because it's 1/4th as much code but just as fast as C++17?
I'd be inclined to agree.
GNU Awk beats them all no sweat, this is obviously optimization issue where language itself isn't bottleneck
Yep. This dumbass wrote a code, that
- Reads a string;
- Copies it into a vector of smaller strings;
- Construct a string to replace one in the vector;
- For each string in the vector checks if it is equal to the last one;
His code works in 33.5 seconds on average on my machine.
After I changed string copies with string_view, and dropped that dumb compare - it works in 12.8 seconds: pastebin.com
SJW propaganda that drew in a very incompetent but obnoxiously vocal psychotic individuals.
> write shitty C++ code
> RUST IS BETTER XDDDDD
SQL: UPDATE Table SET City = 'London';
Where's my cookie?
>Or do you mean D wins because it's 1/4th as much code but just as fast as C++17?
>I'd be inclined to agree.
Hear here. A 50% performance penalty is a fair price to pay for a language that's much easier to understand.
By using splitter you can improve the D code's performance
import std.stdio, std.algorithm, std.range, std.string, std.file;
void main(string[] args)
{
// source change change_with result
auto source = File(args[1], "r");
auto output = File(args[4], "w");
size_t change_at;
size_t number_of_columns = 0;
foreach (column_number, word; source.readln().split(','))
{
if (word == args[2])
{
change_at = column_number;
}
++number_of_columns;
}
int i = 0;
string line;
while (!source.eof)
{
line = source.readln;
foreach (word; line.splitter(','))
{
output.writef("%s%s", i == change_at ? args[3] : word,
i == number_of_columns - 1 ? "\n\n" : ",");
++i;
}
}
}
It is shitty c++ code
To be fair, it's HARDER to write good C++ code. That's one of its downsides.
No, you are just plain retarded.
>rustfag posting rigged bench
You can stop any day now, it's getting kind of old
>Anything that goes against me is rigged
Imagine being this buttflustered
Damn, now it's almost as fast as Rust!
$ >rust.csv && time ./rust input_big.csv field8 test rust.csv
real 0m8.175s
user 0m5.831s
sys 0m1.081s
$ >cpp.csv && time ./a.out input_big.csv field8 test cpp.csv
real 0m8.221s
user 0m6.759s
sys 0m0.503s
It's even harder to write good rust code because it's still fucking unstable, good luck writing everything again after 6 months and it has yet another half dozen "breakthroughs" which basically reinvents the same syntax it took from other languages while still complaining that Cpp is bloated.
But rust is pretty backwards compatible though, since it reached v1.0. Sure, there might be breaking changes but these are not very frequent. Breaking changes come in C++ too.
>Breaking changes come in C++ too.
Yes, for example?
The only thing that immediately comes to memory are trigraphs but nobody fucking uses them, so tell me another one.
auto ptr, far ptr, near ptr
well there was the whole 20~ years of not having a standard
auto_ptr is still in the standard, but deprecated. You can use it, but there's hundreds of documentation online telling you not to.
Near and far pointers were never part of the standard.
>Near and far pointers were never part of the standard.
Ah, old days. NVM.
It's only a matter of time the compilers deprecate auto_ptr too.
There hasn't been any language level breaking changes since 1.0.
>8086 segmented programming
So really, Rust is only like 5-10% faster. Not worth the shit Syntax.
So really D is the big winner here.
Is the D compiler even maintained anymore? You'd think the developers would have moved on since it's been over a decade and absolutely nobody uses D.
Last D compiler release was February 15th, 2018.
>dlang.org
Despite it not being developed with billions of investment like Go and Rust, it's still better than every other compiled language.
Go figure.
There are syntax changes in almost every point release, how can you say there aren't breaking changes?
All those languages should be able to do about equally well on the task. Rust just makes it a little easier.
>easier
>Rust
In my last job they used access to download table from database to excel, make some changes, AND THEN they were uploading the whole table to database again.
I wished that someone would kill me.
>unwrap()
>unwrap()
>unwrap()
>unwrap()
ugly. the c++ code is pretty badly done too.
Example? Note that old syntaxes still work if it's post 1.0
Why hasn't D gotten popular yet? Is it because of the library support?
Nobody wants another class based OOP language. Remove classes entirely and add typeclasses and then it might have a chance.
>make it haskal
Any non autistic reason?
Because Rust is a better version of safe C++ than D.
> make it haskal
Nobody said to make it pure, lazy or add 10,000 compiler extensions.
D is not about safety, it's about readability; writing fast code fast.
Just saying, but that is pretty shitty Rust code desu.
Brainlets can't into SQL
I see this kind of "data updates" all the time with devs who think they know shit in c++, but haven't got a clue in databases.
This is the reason they are pushing NoSQL this hard.
But this is mostly just file I/O, what would that tell you about language efficiency?
import sys
with open(sys.argv[1]) as fin:
head = fin.readline()
col = head.split(',').index(sys.argv[2])
with open(sys.argv[4], 'w') as fout:
fout.write(head)
for i in (x.split(',') for x in fin.readlines()):
i[col] = sys.argv[3]
fout.write(','.join(i))
$ time python prog.py input_big.csv field3 London output.csv
real 0m18.002s
user 0m16.795s
sys 0m1.176s
$ time ./dprog input_big.csv field3 London output.csv
real 1m35.236s
user 1m34.444s
sys 0m0.716s
Wait so D is fastest and requires the amount of code?
D is definitely about safety, just not as safety specific as Rust. I think what D is not about is idiomatic safety. Generally safe by design so as to not shoot self in foot but not by convention. Any non-enterprise project (see all D projects) will be sexed up for benchmarks or something.
>1m35.236s
kek
It's not just file I/O because the for some reason he loads whole file into memory, pre-creates whole output string and then outputs it with suboptimal buffering. It's a comparison how fast the code would be if it was created by retard who doesn't know what to do.
>he loads whole file into memory,
does he?
ok only the rust one does apparently, each does it's own weird sets of things. D one outputs by column item and not by whole line for example
You mean pastebin.com
I ran the code from the blog post for , not the pastebin.
Well I too can say that old syntaxes still compile and work mostly correctly in Cpp17.
Hear here. Not when a 1 second transaction is making you lose millions of dollars.
Language performance is a kinda moot point when doing file operations
real 0m39.658s
user 0m35.555s
sys 0m1.834s
c'mon haskal
how about raw cat input > output?
Is it faster to iterate over fin.readlines() (the list of lines) or over fin (the file iterator)?
Also, note that readline() includes the newline. If you try replacing the last column, does index() raise an exception?
real 0m10.303s
user 0m0.005s
sys 0m0.874s
I don't know haskell well at all so it's probably easy to make faster
>Is it faster to iterate over fin.readlines() (the list of lines) or over fin (the file iterator)?
Didn't try, that was just quickly work to work with the example.
>Also, note that readline() includes the newline. If you try replacing the last column, does index() raise an exception?
Probably, forgot about that.
>haskal
is ur dof ded
true true true
theres sed, awk, grep
why bother
$ ./csv_c field5 testing < input_big.csv > output.csv 4.84s user 0.53s system 99% cpu 5.372 total
$ ./csv_rust input_big.csv field5 testing output2.csv 7.64s user 1.24s system 99% cpu 8.904 total
$ cmp output.csv output2.csv && echo same
same
wat?
I spent 5 minutes shitting together a C program to solve this and it's faster than your fartsy rust solution.
inb4 "but muh safeties" - my code uses getchar, putchar and the only bit of fucking around with pointers is done in finding the header index.
Here's the solution:
#include
#include
#include
// Pardon this shit, I was in a rush
static int findcol(const char *tgt)
{
int c, offt, col, ret;
assert(tgt != NULL);
ret = -1;
col = 0;
offt = 0;
while (c = getchar(), c != EOF) {
switch (c) {
case '\0': return -1;
case '\n': case ',':
if (offt >= 0 && tgt[offt] == '\0')
ret = col;
col++;
offt = 0;
break;
default:
if (offt >= 0 && c != tgt[offt++])
offt = -1;
break;
}
putchar(c);
if (c == '\n')
return ret;
}
return -1;
}
int main(int argc, char **argv)
{
int c, col, tgtcol;
// just use file redirection you lazy fuck
if (argc != 3) exit(EXIT_FAILURE);
tgtcol = findcol(argv[1]);
col = 0;
while (c = getchar(), c != EOF) {
if ((c == '\n' || c == ',') && col == tgtcol)
fputs(argv[2], stdout);
switch (c) {
case '\n': col = 0; break;
case ',': col++; break;
default: if (col == tgtcol) continue; break;
}
putchar(c);
}
}
bump
That's not the same algorithm
What are you even on about?
This is nothing to do with algorithms.
It replaces all the fields in a column in a CSV with a specified new value, that's the challenge.
It is, but when you pick another algorithm, you cannot compare speeds. Rust code implements error handling which you didn't do. And you don't even comply with the challenge and tell us to use file redirection.
He doesn't account for non-ASCII inputs and doesn't even handle all ASCII cases properly. He's a fucking brainlet.
Do you seriously think there's a difference between the file redirection and having to replace putchar and getchar with fputc and fgetc?
What error handling?
Fucking hell, none of the shit you're talking about would affect the speed. Do you even know what you're talking about?
And for the last time, this has literally nothing to do with algorithms. "Read whole lines in and process them" isn't an "algorithm," it's "brain damage." This is just a trivial stream editing problem, just because you're too dumb for simple solutions doesn't mean my solution breaks the rules.
And after all that, awk could still beat your fucking sore ass. If you're so butthurt that your favourite language gets steamrolled by my shitty 5 minute C program or even an ancient programming language like awk then maybe you can "use a better algorithm" and re-implement your silly fucking program to perform better?
>"Read whole lines in and process them" isn't an "algorithm,"
Actually it is, read a book
>rest of the utter nonsense
Not going to bother.
it seems just fine to me.
>Distant cries regarding incapability of writing anything efficient due to "patterns" from a "book" which need to be followed under all circumstances.
No wonder you pajeets are going to get replaced by robots, all you ever do is read books and replicate everything in them word for word. But I have to say, not reading in files one line at a time used to be written in books, maybe modern day programming books are too hip for such an ancient and efficient method of processing files. It's not too surprising considering CS degrees have turned into 3 years of teaching people how to write in Java and C++. Also, it seems someone re-defined the term "algorithm" when I wasn't looking.
I apologise for not slowing down my code on purpose, next time I'll make sure that I spend at least 3 weeks writing anything and I'll make sure to include all the latest programming patterns, and I'll make sure that I use a regex library, maybe I'll add some random busy loops for good measure. Then I'll make sure that if I have to process a file I'll read the whole thing line by line and then process the line 10 times for no good reason.
Because fuck me if I ever write anything efficient, that's illegal in the modern day and age of programming. Heck, if anything ran efficiently anymore people would get worried that you code monkey actually do useful work.
>doesn't have a counter argument
>calls it "utter nonsense"
>yay I win the argument!
Are you being purposefully retarded or what?
1. Whatever you may call it, what you described actually is an algorithm. Problem with you "self taught" programmers is that you are opinionated and misinformed. Which is why no one wants to hire you.
2. No one forbid you to write "efficient" solutions and yours isn't "efficient" either. What you are told, clearly, is that the algorithms aren't the same and the performance comparison is futile.
Fucking retard gtfo.
Also
Not wanting to argue with an illiterate monkey is not the same as not having an argument.
> Whatever you may call it, what you described actually is an algorithm.
You must actually be lacking any form of education if you seriously think that "reading a whole line into a buffer for processing" is an algorithm. I would also say that if you think "reading a whole line into a buffer for processing" is a good solution to this problem on any day of the week, you shouldn't be writing any code which cares about performance.
> Problem with you "self taught" programmers is that you are opinionated and misinformed. Which is why no one wants to hire you.
Good thing I'm neither self taught (although there's nothing wrong with that) nor am I unemployed. I also seem to be capable of not masturbating my giant brain every time I write something which is why it takes me 5 minutes and doesn't involve implementing any kitchen sinks.
> No one forbid you to write "efficient" solutions and yours isn't "efficient" either.
It's not efficient, it's still better than the shit in the OP.
> What you are told, clearly, is that the algorithms aren't the same and the performance comparison is futile.
The OP makes no mention of using any specific "algorithm". The "algorithms" used by every language in the OP differ. The exercise simply asks you to fill a column in a CSV. The whole fucking point of the exercise seems to be to write some straightforward simple code in each language and then compare performance and character counts. The OP only seems to care about performance. Your concerns are bullshit.
quick, somebody bench a perl one-liner that does the same thing!
Or just awk.
>You must actually be lacking any form of education if you seriously think that "reading a whole line into a buffer for processing" is an algorithm.
holy shit. I knew Sup Forums was crawling with pajeets, but this is a new low.
>The whole fucking point of the exercise seems to be to write some straightforward simple code in each language and then compare things that are incomparable. The OP only seems to care about incomparable bullshit, and the OP is always right, therefore your concerns are bullshit.
(You)
Lmao classic
>I'm a brainlet so its much harder to understand
You lose because it was a competition of expression and readability. Your niave k&r style soloution won't win any awards, it isn't the fastest.
Awk is faster
I wonder why optimizing pageSize has no effect
Does anyone here unironically use rust? Will it eventually push c++ away?
