/dpt/ - Daily Programming Thread

What are you working on, Sup Forums?

Previous thread:

Other urls found in this thread:

learnopengl.com
twitter.com/SFWRedditVideos

Please post an anime image next time.

Nothing. Give me a project. Preferably one that involves hardware because all this shit webdev at my job is killing me.

thats the face u'll be making when im in ur sissy ass

he did tho

...

>implying that is not animu

The hero /dpt/ deserves.

Wearing a hijab!

Holy shit this code is so disgusting.

No wonder GNU shit is so buggy.

It's clearly an optimisation.

Main goals are:
>computer blocks and automaton mobs programmable (eval yes!)
>multiplayer (kinda mandatory for this sort of thing but also I haven't done network programming since I was 11 so it should be fun)
>dynamically loading mods from ~/.game directory (really easy with (load))

We know it, it's called loop unrolling. It's still idiotic, because the sheer extra binary size will vitiate it. Not to mention unnecessarily long code is error prone and hard to maintain, and it looks like it was written by a pajeet.

>because the sheer extra binary size will vitiate it
Do you honestly think they don't profile and test the shit out of these sorts of things? God, you're so fucking stupid.
Also, standard libraries are known for all sorts of crazy tricks to push speed as much as possible. It benefits not only them, but every other C program.
>hard to maintain
The specification of strlen isn't going to fucking change. It's standard.
"maintainability" is unimportant here, and takes a backseat to performance.
You can't treat standard library code like you do other code.
>error prone
Please show how that particular function is buggy.

The sheer extra binary size from 20 extra instructions? Who cares if it looks like it was written by a pajeet? It's fast and libc should be fast.

glibc strlen is about a hundred times faster than a naive implementation. No joke. It's that much faster than the "pretty" solution.

Naive:
int shittystrlen(char * c) {
char * cursor = c;
while(*(++cursor) != 0);
return cursor - c;
}

real 0m51.536s
user 0m51.500s
sys 0m0.008s

glibc:
Horribly awful

real 0m0.378s
user 0m0.376s
sys 0m0.000s


And the code to test it:
#include
#include
char * benis = "fill this up with a longer string";
void main() {
int i;
for(int j = 0; j < 10000000; j++)
i = strlen(benis);
printf("%i\n",i);
}

>136 times faster
noice

First for /agdg/ plz go and stay go

Anyone here experienced in Android development?

I'm still dumbfounded by this, probably something trivial I'm not realizing. But idk if it's a peculiarity with the android studio IDE itself or just a rule of Java that I've forgotten.

Feel free to post and discuss other programs!

I hear people saying Rust will fail, but it seems to start getting a lot of adoption. Tell me how is Rust going to fail when it is already starting to become very popular.

Can anyone help me, I dont understand why this isnt working:

threads[prevIndex] -> nextThread = threads[currentIndex] -> nextThread

Im trying to achieve pic related.

"threads" is an array of pointers pointing to "thread" structs, where each thread struct contains a struct thread *nextThread; member.

How the fuck do I make a previous thread point to the thread of the current threads pointer to the next thread? (effectively taking out a node in the linked thread list)

Tried so much shit its getting frustrating

>String literal
Compiler optimisations are surely fucking with that.
Anyway, here is a more fair benchmark:
#include
#include
#include

__attribute__((noinline))
size_t glibc_strlen(const char *str)
{
// Omitted so this will fit in a single post, but it's taken from the latest glibc.
// Also, we don't use strlen directly, because the compiler notices it as a special function,
// and will omit different code.
}

__attribute__((noinline))
size_t naive_strlen(const char *str)
{
register size_t len = 0;
for (; *str; ++str)
++len;

return len;
}

int main(int argc, char *argv[])
{
if (argc != 2)
return 1;

clock_t start, end;
size_t len;

start = clock();
len = glibc_strlen(argv[1]);
end = clock();

printf("%zu: glibc_strlen took %f seconds\n", len, (float)(end - start) / CLOCKS_PER_SEC);

start = clock();
len = naive_strlen(argv[1]);
end = clock();

printf("%zu: naive_strlen took %f seconds\n", len, (float)(end - start) / CLOCKS_PER_SEC);
}
$ gcc test.c -O3
$ ./a.out "$(printf '%100000s')"
100000: glibc_strlen took 0.000036 seconds
100000: naive_strlen took 0.000147 seconds

Personally, I don't think Rust will fail, but I don't see it actually replacing C/C++ for larger programs, simply because of the inertia of the languages and tools for those languages.

When it comes to algorithms like Djikstra's, concerning the 'edges' that each node is connected to, would you implement these as just a list of nodes that the node is connected to?

So, something like a linked list of nodes inside of each node for every node they're connected to?

...

>Actually I feel like I'd committing an injustice against myself by releasing it for free
Release it under GPL and without the assets needed to play it, kind of like how the idTech engines have been released. I want to see this too.

Rust is nearly unheard of in the industries it is trying to take on. It might catch on for high performance applications, but I don't see it actually doing much in the systems world other than the occasional 30 year-old unix rewrite, now with terminal colors.

>anime
this is clearly a manga picture

I'm unable to learn OpenGL, I have the recommended book. What even is this shit fuggggg

>high performance applications
C is still the undisputed king in that arena.

I think unheard of is a bit of a stretch, but I agree that I don't really replacing anything.

Rust has inline assembly too.

>Rust has inline assembly too.
So? That's not what makes a language fast.

ground up neural net using sensory input for an embedded system.
>completely in C

When and if Rust becomes an industry standard is the day I should retire.

made a simple script that parses a user's pastebin for hentai games.

the real beauty lies in how it's organized.

uses jdownloader API to group the download links in the same package as the dlsite images, so now I can have a nice folder name, with proper images and the game in a folder

the best part?
only took 1 hour(and that was only because the jdownloader python api was undocumented and it took me forever to install pycrypto, a dependency of the api.

If threads is of type thread_t* and not thread_t** threads[i] returns the thread itself.

threads[previous].next = threads[current].next;


or

(threads + previous)->next = (threads + current)->next;


This is what I'm guessing since you didn't give any compiler error or weird behaviour.

It is, but the minimal losses you get with C++ is well worth the gains in the application world, as countless applications proved and continue to prove. Rust stands a chance here I feel, one because it's exactly Mozilla's wheelhouse, and two, it's a great area for disruption. Systems I'm still not sure how much of it can be disrupted, even if rust gains prominence among the community.

Hmm neat. That does make a little more sense. I was astonished with my results.

I didn't turn any optimization on though. I was worried about gcc optimizing away the loop i used to make glibc strlen take a noticeable amount of time. Dubious about compiler emitting different code

glibc:
main:
.LFB1:
.cfi_startproc
push rbp
.cfi_def_cfa_offset 16
.cfi_offset 6, -16
mov rbp, rsp
.cfi_def_cfa_register 6
sub rsp, 16
mov DWORD PTR -8[rbp], 0
jmp .L5
.L6:
mov rax, QWORD PTR benis[rip]
mov rdi, rax
call strlen@PLT
mov DWORD PTR -4[rbp], eax
add DWORD PTR -8[rbp], 1
.L5:
cmp DWORD PTR -8[rbp], 9999999
jle .L6
mov eax, DWORD PTR -4[rbp]
mov esi, eax
lea rdi, .LC1[rip]
mov eax, 0
call printf@PLT
nop
leave
.cfi_def_cfa 7, 8
ret
.cfi_endproc

And shittystrlen:
main:
.LFB1:
.cfi_startproc
push rbp
.cfi_def_cfa_offset 16
.cfi_offset 6, -16
mov rbp, rsp
.cfi_def_cfa_register 6
sub rsp, 16
mov DWORD PTR -8[rbp], 0
jmp .L5
.L6:
mov rax, QWORD PTR benis[rip]
mov rdi, rax
call shittystrlen
mov DWORD PTR -4[rbp], eax
add DWORD PTR -8[rbp], 1
.L5:
cmp DWORD PTR -8[rbp], 9999999
jle .L6
mov eax, DWORD PTR -4[rbp]
mov esi, eax
lea rdi, .LC1[rip]
mov eax, 0
call printf@PLT
nop
leave
.cfi_def_cfa 7, 8
ret
.cfi_endproc


Unless I'm missing something those look pretty identical.

As for why your code is 10 times faster than mine, I'm not sure desu. I doubt compiling in O5 would cause it. Found out that Sup Forums has a line cap too (fucking assembly) so can't post the full source for that but it looks pretty normal.
.L2:
add QWORD PTR -8[rbp], 1
mov rax, QWORD PTR -8[rbp]
movzx eax, BYTE PTR [rax]
test al, al

Both pointers are only in register, and I see nothing weird about it loading chars.

Having trouble with something user?

>Do you honestly think they don't profile and test the shit out of these sorts of things?
I don't think so. Not with the fame their software has. Do you really trust them so blindly?

>God, you're so fucking stupid.
No, you are just an obvious GNU zealot.

>standard libraries are known for all sorts of crazy tricks
I could pull up BSD's strlen, musl's strlen, Apple's strlen, and none of them are over 7 lines of code (counting empty lines). Compare it yourself!

>The specification of strlen isn't going to fucking change.
Maybe not, but have you ever heard of regressions?

>Please show how that particular function is buggy.
That one probably isn't, but the point here is bigger than only that function in particular, it's about good coding practices in general. And if this is standard GNU practice for all their code (and it must be), then it explains at least in part why their code is disproportionately buggier. glibc in particular's been known for having some pretty nasty bugs (pic related).

Reminder that your functions should fit in one 80x24 terminal screen.

>The sheer extra binary size from 20 extra instructions?
20 extra instructions here, 20 extra instructions there...

Again, like the poster above you, your vision is too narrow. All those extra instructions add up to glibc being the most bloated implementation of the standard C library out there. Compare it yourself!

>glibc strlen is about a hundred times faster than a naive implementation
It isn't. I'm gonna refute your little experiment in a following post, but first, let me say that, even if it was faster by a constant, anyone who knows the basics about algorithms knows that's meaningless asymptotically.

>your little experiment
For starters, it shows how little you understand about how libraries are loaded and how compilers work.

1st mistake: you used the linked strlen instead of copying and pasting the code from it in your function. That makes a huge difference.

2nd mistake: you didn't take into account compiler optimizations (the compiler knows when you're using the standard lib).

3rd mistake: you missed the point. The criticism is towards a particular section of the implementation, namely lines 84 through 102. Those can be replaced by a simple loop and return statement, and I guarantee you the difference will be in the order of milliseconds.

for (i=0; (i

Really? I found opengl superbible super good to learn opengl.

Daily reminder that Java is as fast as C these days.

Try learnopengl.com

FreeBSD libc also does it through a preprocessor function. No, it's not idiotic by concept, but GNU's coding style is. Pic related, where testbyte() is defined below.

#define testbyte(x) \
do { \
if (p[x] == '\0') \
return (p - str + x); \
} while (0)


The reason stated is that branching is more expensive on modern systems than raw conditions, and this type of optimization is very important in a libc that's used as the foundation for every userspace program on the system, so this function is expected to run many, many times every second.

Sorry im so lost right now spent so long trying to figure this out so nothings really making sense to me anymore, pic related, what do I do?

When you absolutely need the highest possible performance, you inline assembly.

>Java
I don't care how fast Java becomes, you couldn't pay me 6 figures to deal with that shit.

OOh lists you're a big boy. I looked at the source code because I know about compiler optimizaitons and stdlib.

They look identical minus the function call. Or does the optimization happen in the linker now?

(1) it's nanoseconds faster not miliseconds faster. (2) I missed zero points because optimizations add up. I don't care if you think it's ugly. No one except you does. Nanoseconds add up. A single nanosecond here and a single there make a difference for the standard library.

>tfw purchased the other one
There were 2 books, I didn't purchase the SuperBible. I can kind of program in it but I'm not sure what I'm doing, going to keep reading it and then read up on stuff I don't know afterwards. Right now it feels like I'm not making any progress though.

That is flat out wrong.

>in the order of milliseconds
That's actually quite a lot.

What's so bad about Java? What can be better done in C? Honest question I want to know.

Write a function in java that takes two ints and swaps them.

Oh the orange book is more of a reference manual to my understanding. Never read it though.

See

I think zero cost abstraction is such a meme. There is almost always cost when you abstract something because you are generalizing a problem. Compare these two programs fizzbuzz programs.

// rust_fizzbuzz.rs
fn main() {
for i in 1..101 {
match (i % 3, i % 5) {
(0, 0) => println!("Fizzbuzz"),
(0, _) => println!("Fizz"),
(_, 0) => println!("Buzz"),
(_, _) => println!("{}", i)
}
}
}

/* c_fizzbuzz.c */
#include

int main(int argc, char *argv[])
{
int i;
for (i = 1; i

>What's so bad about Java
I, personally, dislike its syntax, and I dislike being forced to only deal with OOP.

>being forced to only deal with OOP
Java doesn't force you to deal with OOP. You can write 100% procedural code with it. And a big part of the JCL is actually procedural.

The blue and red books? I remember those from school, I'm surprised they're still using them, shaders were still considered novel when I did my graphics programming course work.

Make sure you understand what's actually going on in the opengl pipeline.

did the authors fuck up the order of the arguments?

if L(y,y) is 0, that is a good thing because there is no loss.

If L(y=spam, ŷ=nospam) = 1 then you are classifying no spam as spam.

If L(y=nospam, ŷ=spam) = 10 then you are classifying spam as nospam.

but the second is worse than the first because it has a higher loss, yet they say the first (NS->S) is 10x worse than the second (S->NS)

what?

Have you compared the same version in Rust but with the if statements?

Wh-what's the point in doing that user?

The whole point of allowing for inline assembly is for you to maximize efficiency in areas that need it, if you need to fizz buzz as fast as possible, then you would write the slow parts in assembly.

oh wait shit I get it now. The actual value is spam but you are classifying it as nospam in the first case.

Making dumb posts is a great way to answer your own questions.

>You can write 100% procedural code
What? Do you mean just lopping all your functions inside of one giant class?

Quite literally everything can be done better in C, if you have the time to do it. This is just by design. One language compiles one step above bare metal, and the other is an intermediary language translated on the fly by a VM.

What book?

>Programming guide
>thought guide meant tutorial
I'm retarded. Also the preview of both books is basically the same thing, I thought they were basically the same books. I already spent my money on the book and I don't have enough shekels to buy another 50$+ book fuuuuggggggg why am I retarded

You don't have to do that. But you can write all functions as static and make all classes methodless with public fields.

>all GNU code follows this retarded style
Suddenly I understand why GTK development never gets anywhere, why GIMP development never gets anywhere, why GNOME development never gets anywhere, etc. etc. etc....

p.711

Just return it user.

That's why returns exist. Say "The description was vague about what it was. This is a reference manual."

Reposting here
If I care about data transfer speed between a windows service and a GUI which IPC method should I use?
So far I have looked at:
WCF
Named Pipes
Shared Memory

>code separation is OOP
>80% of what people call """OOP""" isn't procedural anyway

Do I need to understand anything deeper than what each stage does? I know what they do but how in-depth should I know them?

That wasn't really the point of my argument. The point of my argument was that zero cost abstractions is a meme because there is always a cost to generalize a problem from a specific solution. But, if you must

// rust_fizzbuzz.rs
fn main() {
for i in 1..101 {
if i % 5 == 0 && i % 3 == 0 {
println!("Fizzbuzz");
}
else if i % 3 == 0 {
println!("Fizz");
}
else if i % 5 == 0 {
println!("Buzz");
}
else {
println!("{}", i);
}
}
}


$ wc -l rust_fizzbuzz.s
211 rust_fizzbuzz.s


I get more lines of instructions which is weird. Rust compiler is not mature I guess?

I think it's generally disliked for it's shitty syntax and shitty performance. Combined with it's ubiquitous use in enterprise software (ensuring it's made by codemonkeys), it has quite a bad reputation.

no worries. You should take a break until you feel better though.

So threads is struct thread**? Can you show me the declaration of threads? I don't understand why you did modulus NUMTHREADS either.

If threads is a struct thread* you'll want to do this, keeping out the modulus NUMTHREADS that I don't understand:
(threads + (currentThread - 1))->next = (threads + currentThread)->next;
(threads + (currentThread + 1))->prev = (threads + currentThread)->prev;


if it's a struct thread** the solution you had earlier would've worked.

Don't you have to make your variables inside those functions also static?

Isn't that just going to end up having ridiculous heap allocations?

This is the most pathetic post, as if it's somehow impossible to have a script or macro to reformat code to whatever style wanted/needed for whatever purpose.

I don't really understand what you're struggling with. Is it the actual openGL pipeline and commands you need to call to make something happen? Or is it the underlying theory of 3D computer graphics?

>that really wasn't my point
Yes it was.
Look at the pattern matching vs the if statement verisons.
As you can see, the difference is only 5.

You can't just say "here's C code using C libraries" "here's Rust code using Rust libraries and pattern matching"
"clearly pattern matching is at fault"

Those never get anywhere because there's no money in them and it's not interesting. Companies don't fund gimp because it's worthless compared to adobe.

The only open source projects that get anywhere are ones interesting for programmers. Programmers, especially linux ones, don't care about UX and image editing when they do everything in a command line.
>all GNU code follows this retarded style
It's a pretty typical unrolled loop. You don't like optimizing code? Optimization is addictive desu. Very fun to get the execution time lower and lower and lower. What's wrong with its style?

>in the order of milliseconds.
>insignificant
I too, know nothing about scientifiy computing

>tfw still no file picker thumbnails

I'm in the planning stages on a program I want to write for work. I want to run a batch file of sorts to scan all the IP's on my network, see which ones are being used, gather information about the computer, and gather that information on a list. The ip list my boss and coordinator made is no longer accurate since they seem to forget to change it when they got new computers and such.

Then why the fuck does Rust use twice as many instructions as C? Zero cost abstractions my ass.

Just look at your router's DHCP/ARP log.

>doing scientific computing
>not using FORTRAN
You're asking for all the bad things that happen to you.

Are you sure you aren't just comparing static vs dynamic linking? Rust links statically by default, unlike clang

The point of your argument was only partially related to the specific topic at hand.
If you don't want abstractions, you're free to do away with them for the highest performance possible.
If you think some abstractions are a meme, do away with them.

WHAT DID YOU SAY ABOUT MY YEGOR

How do you static link Rust then?

Reread what I just said

You just saw pattern matching vs if in Rust.
The difference was only 5.
It's not the pattern matching that makes it twice as slow as C.

It's probably the libraries, or maybe a fundamental limitation of C.

I don't remember you having to declare stack variables static in main so I don't think so. But it's been 5 years since I've touched java.

It wouldn't make sense for you to have to do that because static fields and static variables are conceptually distinct.

*of Rust
or linking like says

threads is of type Thread* which was passed in an argument as this piece of code resides in a function. I dont wanna show the whole thing cause I might get fucked up or something by my uni.

But basically its:

some_function(Thread *thread){
...
...
while loop{
the code ive shown
}
...
}

The purpose of me going threads[prev thred % NUMTHREADS] is because I actually have a circular linked list, and I basically want to take one node out of the circular linked list and reattach where the pointers should go, so I can't do what youve shown.

threads is an array that contains pointers to other threads e.g

threads[0] = a pointer to a thread struct
threads[1] = a pointer to another thread struct

I hope this makes sense

Apparently Rust does static linking by default.