>>103105243
ESLs have no use in programming. Please remove yourself.

>>103105272
imagine being brown though. Couldnt be me

>>103105243
Linked lists have no use case
It just happens to be a few less lines of code to implement in C than a dynamic array, so C programmers do what is easier

They're fine for queues and stacks. Python deques are literally just doubly linked lists.
Languages like Lisp and Haskell make extensive use of them (Lisp basically IS linked lists), but unlike cniles, the fags who use these languages are actually aware of the pitfalls and ameliorate them.

>>103105243
>Whats the use case if you use anything else than C?
Writing programs. C is good for LARPing.

>>103105340
linked lists allow each item to have a stable address.

>>103105390
>Languages like Lisp and Haskell make extensive use of them (Lisp basically IS linked lists), but unlike cniles, the fags who use these languages are actually aware of the pitfalls and ameliorate them.
they ameliorate them by never writing any software that isn't just a toy command line experiment, kek

>>103105436
Just use an index int

>>103105243
Singly linked lists are not used much, even in C. The only language that really relies on them is Haskell, because they combine well with lazy evaluation. (Lisp doesn't actually use linked lists, the basic Lisp data structure is a pair, which can be used in various ways)

They get attention because you have to understand them well to have a hope of understanding more advanced data structures, which do get used a lot.

>>103105340
SSA in optimizing compilers

>>103105740
Isn't that a tree, not a linked list?

>>103105340
TRVTHNVKE

>>103105243
I've been using sys/queue.h SLIST_* macros for decades, so enjoy your useless DSA classes in your overpriced, reality-divorced compsci degrees, chuddies.

>>103105790
umm no but it's neither a simple linked list either. the SSA IR of a function is an set, generally ordered, of basic blocks and each basic block contains a list of instruction. this is the list I'm talking about. then, on top of what, the struct of a instruction can contain pointers to previous instruction to indicate where a given instruction's argument (a virtual register/variable, assigned only once), (for example r4 in r5 = add r3, r4) was defined and assigned.

>>103105886
I don't understand why it would implement the instructions as a linked list instead of a dynamic array

>>103105340
> dynamic array
on a magical computer, realloc() is a no-cost operation. in real-life, it’s a ball buster.
To avoid that, you just make the initial size absolutely huge. Which explains modern software bloat, and accidentally touched virtual memory.

>>103106025
realloc'ing makes iterating through the stuff way faster. If it gets iterated through more than like twice, it's probably faster using a dynamic array
And for compiler optimizations, it's probably pretty easy to get a rough count of the instruction list size, so the initial alloc shouldnt be off by an order of magnitude

>>103105243
>Whats the use case if you use anything else than C?
You mean Lisp, ML and Haskell. Linked lists in C are just another way to cause memory leaks and use after frees.

>>103105975
it's also possible as long as its a sequence, there is no one way, but the few VM and compilers implementations that I found information about on this specific aspect, of how the SSA is represented, do this and apparently for speed reasons. LLVM, GCC and PHP at least. I guess that inserting and deleting nodes thousands of times must have some impact on performance. I'll be fully convince when I'll try each one though, like you, but it's safe to say that the LLVM and GCC guys already did profile it.

>>103106120
it's also possible that the memory footprint is smaller with a linked list because with dynamic arrays you'd overallocate knowing that you would do insertions. if you don't overallocate you'd reallocate and may end up doing a boatload of memcopies

but I use singly linked list for my queue and stack.

What's the downside?
I'm using C.

>>103105243
If you want random removal without reference invalidation of other elements and don't want to deal with double indirection.

>rust trannies can't into tree structures
grim

>>103106120
the instructions themselves are huge
https://github.com/gcc-mirror/gcc/blob/master/gcc/rtl-ssa/insns.h

>>103106120
I don't trust LLVM or GCC guys with developing anything fast. It should take less than a second to compile a few megabytes of code, but it doesnt

guys? I was using singly linked lists for my queues and stacks.

What's so wrong about it?
I'm using C.

>>103106249
yes they compile very slowly but they do a lot of analysis and optimizations and I don't really know what takes time exactly in that whole process.
we should like at existing JITs to know how to do it fast. I'm looking at PHP again and it looks like the basic blocks are mode of arrays of instruction struct contrary to what I said. variables have their own structs and contain pointers to their definition though.

>>103106413
*look at existing JITs

>>103106188
The downside is sparse allocation. In some cases I implemented the equivalent of sql vacuum to fix that. Basically some algo will do some wild allocations, frees and whatnot but eventually get stable, at this point I "array" it for fast reads and smaller footprint. It's really not hard to do in C, no idea if cuck languages allow it at all.

>>103106249
A good C developer’s code runs just as fast with -O0 as the same code compiled with -O3.

>>103106560
the register allocation under -O0 is garbage

>>103106611
> register allocation is garbage
That’s a cpu architecture problem that intel created coupled with the “all the world is an x86” mentality.
Virtually everything else has at least twice as many registers. Also, for backward compatibility, it is still being held-back by the traditional 8 register pre-x64 limitation.

>>103106712
I can't argue with what you said, but at -O0 it looks like there is no register allocation at all in fact:
>int func(int a, int b) { return a + b; }

0000000000000000 <func>:
   0:   55                      push   rbp
   1:   48 89 e5                mov    rbp,rsp
   4:   89 7d fc                mov    DWORD PTR [rbp-0x4],edi
   7:   89 75 f8                mov    DWORD PTR [rbp-0x8],esi
   a:   8b 55 fc                mov    edx,DWORD PTR [rbp-0x4]
   d:   8b 45 f8                mov    eax,DWORD PTR [rbp-0x8]
  10:   01 d0                   add    eax,edx
  12:   5d                      pop    rbp
  13:   c3

there is well enough registers and yet the arguments are still stored to and loaded from the stack.

>>103105243
If you want to interface with hardware or work with file systems, inodes and device transfers descriptors are just linked lists with added bloat

>>103106560
Post a 30+ line example of code where this is the case

>>103105480
Then you have to keep track of all of your indices and update them whenever you add or remove something that isn't at the end of the list.

>>103106950
Yeah -O0 sucks, you get absolutely no optimization with it. Which to be fair, is kind of the point.

>>103105817
why do you have a piss bag?

>>103106950
I bet that even if GCC/LLVM avoids the stack and uses only edi, esi, and eax, it will still insist on saving+restoring that frame pointer unless you take off its cock cage and explicitly tell it to omit the frame pointer.
>>103107935
Urinary incontinence.

>>103108083
>omit the frame pointer
ah yes, I read something about this recently. It said -fomit-frame-pointer was a good gcc flag to use in the 32 bit area because there was a very limited number of general purpose registers, that it fucked with profilers, and that now with the extended 64bit register set the register pressure is less bad than it was and that it's ok to omit this flag or something.