Jump to content

trag1c

Member
  • Posts

    2,140
  • Joined

  • Last visited

Reputation Activity

  1. Agree
    trag1c reacted to leadeater in Intel CEO Pat Gelsinger: I hope to build chips for Lisa Su and AMD   
    Intel would already mostly know anyway and the directions both companies have taken are so vastly different there isn't anything they could just bring across and use. Tiles vs chiplets vs whatever only sounds similar at face value but really they are very different and the internal data connections as well as how to interconnect Tiles/Chiplets aren't the same or interchangeable. 
     
    And anyway AMD's Infinity Fabric is just an evolution of Hypertransport which was an open standard used by both IBM and Apple, Intel has all the general knowledge of how it works as it is.
     
    Knowing what and how someone is doing something doesn't mean you copy them or even change your own plans, you can think or legitimately have the better path, or at a minimum one better for your own product.
  2. Agree
    trag1c reacted to AlwaysFSX in CNET blacklisted by Wikipedia   
    Now hang on a minute. I remember them making plenty of trashy articles in the early 2010s even.

    Now people are taking notice because they're having AI generated articles?
  3. Agree
    trag1c reacted to Sauron in What is the point of these useless typedefs?   
    The reason for these definitions is that these libraries are available across a variety of operating systems and architectures, which define stuff like integers differently. The underscores are just a naming convention used to avoid conflicts with something you might want to name your variables, for example.
    More like your code won't suddenly be filled with overflows the moment you try to compile and run it on a 32 bit system and your integers are now only 32 bits long rather than 64. Along with a large variety of problems that would make cross platform support a nightmare.
    If you're a beginner then you shouldn't concern yourself with any of this. Just use your standard language types and you'll be fine. You should focus on understanding basic algorithms, general programming concepts that apply across languages, common pitfalls... and definitely not on platform specific typedefs that were never intended for you to read through, or whether typing out a for loop slightly differently will result in a 0.000000001 ns difference in execution times that will almost certainly be optimized away by the compiler.
     
    I can assure you in a professional environment nobody is going to know by heart which exact sequence of C instructions would be marginally faster without optimization, or expect you to know; they probably won't care if you even know what a typedef is or why it's useful, because specific language syntax that is only useful in some circumstances is quickly learned on the job if need be. What they will expect you to know is how to structure a program, how to quickly familiarize yourself with a new language, what industry best practices can be applied to common problems.
  4. Agree
    trag1c reacted to LAwLz in What are some good programming QnA websites?   
    I went through your post history and to be honest, it seems like the issue isn't "toxic users" but rather how you ask questions and what questions you ask. I'd even go as far as to say that you are the toxic one based on statements like this:
    You are demanding that people do things for you in a rather ungracious way. "Just do the work for me"
     
    Your questions are confusing and when people try to help you by trying to get more information out of you (because your questions are often incomplete making it impossible to help you), you become rude or just stop responding and make a new thread.
     
     
     
    A lot of your topics seem to just be a stream of consciousness that doesn't make much sense, and you ask A LOT of questions.
    A lot of your questions could be answered by putting the thread title into Google and clicking the first link. Just take the question posed in this thread.
    "How to install a library in C".
     
    Not only does this question not make any sense (because you don't install C libraries), but if you search that exact line you get multiple articles written about the subject. The first one that appeared when I searched for it was in fact a Stack Overflow thread.
    The second link I got was a seemingly good article on Medium.
     
     
     
     
    Stack Overflow has a great article about how you should ask questions, and in general if you follow that then people aren't toxic and you will get help. That applies to all forums by the way, not just this one.
     
    You can't expect people to put a ton of effort into helping you when you seem unwilling to even do basic things like Googling your question before you ask it. Forum users aren't your personal slaves that exist only to help you. They help you in their spare time if they feel like it, and it is in your best interest to make their task of helping you as easy and painless as possible. 
  5. Agree
    trag1c reacted to Kilrah in for is way faster than goto in C?   
    You really need to start looking at the assembly output of your compiler and learn to understand it if you want to go into such detail.
  6. Agree
    trag1c reacted to wasab in Segfault in C when using FMA AVX2.   
    Rule #1: never copy and paste code you dont understand. Applies to even you(and all of us), stackoverflow copy pasters. 
  7. Agree
    trag1c reacted to Eigenvektor in Question in C about CPU performance.   
    The way you talk makes it seem like you still think of C like some kind of runtime. It isn't. Your code gets compiled to native machine code, so you can look at the compiled code to figure out what exactly is going on and where the difference is.
     
    Data needs to be loaded into registers for the CPU to perform mathematical operations on it. The only question is whether the result stays there or is moved back and forth between memory and registers.
     
    Maybe share your code? Otherwise we can't do anything other than speculate.
  8. Agree
    trag1c reacted to Eigenvektor in kernel parts   
    While the Linux Kernel may have started out as a one person project, it has had contributions from over 15K people by now.
     
    There is also much more to an OS than just its kernel. You also need apps that run on top of it, to make it actually useful.
     
    Developing a "simple" kernel is one thing, developing and entire OS from scratch is virtually impossible for a single person if you want to go beyond a command line with rudimentary commands.
     
    Learning about kernel development is certainly worthwhile, but try to keep your goals somewhat realistic. Otherwise, you'll likely end up frustrated instead.
  9. Informative
    trag1c got a reaction from Eigenvektor in How do I install these C libraries on Windows?   
    Unlike Linux, User libraries don't have central location that all applications can pull from (This is why just about every application folder you look into has a whole swath of DLLs). DLLs (the equivalent of .so on Linux) have to reside next your executable or in some known path (set at compile time of your application). So the process of installing shared libraries is simply build them and place them next to your executable. 

    Additionally, you need to instruct your build system how to link to the library. Essentially you're going to set an include directory for the headers so that you can write your code using those libraries, and finally you will set a link directory pointed to the windows version of a static library (.lib) that defines an import library which allows for your executable to link with the DLL at run time. The .libs are generated by the build process for the libraries. 
     
    TL;DR;
    Build library DLL and place next your executable
    Build library .lib and set your link directory/dependencies to this location.
    Add include directory to the libraries headers. 
  10. Informative
    trag1c got a reaction from Eigenvektor in How does this work??   
    Not just NASA, pretty much every single embedded, safety critical, or hard real time application will be written this way regardless if they run on a platform with an MMU or not. 
  11. Agree
    trag1c reacted to Eigenvektor in How does this work??   
    If you hit yourself with a hammer, it's not the responsibility of the toolmaker that you did so. You're expected to know how to wield it.
     
    There's a reason higher level languages exist. They often include safeguards that ensure you can't do things like access arrays out of bounds. But that comes at a price (e.g. performance penalty). The lower level you go, the more you, as a developer have to pay attention.
     
    You have to remember that a is simply a pointer to some arbitrary memory region and a[90] is basically just a shorthand expression for incrementing that pointer by 90, to give you access to some other memory region. The C compiler doesn't know whether that is an OK thing for you to do. It is your responsibility to know that.
     
    Writing your own garbage collector is not a trivial task. The easiest way to get going with automatic memory management is to implement reference counting. However, this would be a lot easier with a language like C++ that has objects that come with destructors that can take care of releasing resources again.
     
    To get real garbage collection you need some way to determine if a resource that was allocated is still referenced by the rest of the code and free it otherwise. You'll need to write some form of low level framework first that takes care of all the actual allocation and deallocation, then work on top of the framework to implement your actual program.
     
    And since you're in C, there's no real way to enforce internal vs external access (like private/public would in C++), so you'll still need to be disciplined about working with your framework, rather than against it.
  12. Agree
    trag1c reacted to mariushm in More bits, more numbers. So where is more than 64 bit computation?   
    Nothing stops you.  We use 32 bits and 64 bits because it's FAST, due to processors having 32 bit or 64 bit registers, 32 or 64 bit data paths to caches and memory and so on ... so it's the least amount of cpu cycles to perform an operation. When you work with sizes bigger than register sizes, operations have to be done in multiple cycles. 
     
    There are libraries that work with more than 64 bits variable, for example the bigNum library. 
     
    There are libraries that keep numbers in their string representation, so you can add or substract by manipulating characters. 
     
     
  13. Agree
    trag1c reacted to Eigenvektor in More bits, more numbers. So where is more than 64 bit computation?   
    Nothing is stopping you from doing this, other than maybe convenience. You can allocate any arbitrary number of bits and treat them as a number, but you'll have to take care of e.g. carry over if you add two such numbers, since the CPU has no native support for it. Even just basic addition, subtraction, multiplication and division will take take time to implement.
     
    Of course ideally you'll want to use a library (or write your own) that takes care of this under the hood. For example in Java you have classes like BigInteger, which can theoretically represent integers of (almost) arbitrary length.
     
    Internally it uses an int[] to be able to use more than 32 bit, so technically you're limited by the maximum size of an array (limited by the JVM and available memory). So the maximum number it can represent is as high as 2(32 x 2,147,483,642). Just keep in mind that one such number on its own would already require roughly 8 GiB of memory.
     
    Realistically, you'll find few use cases (other than maybe scientific) where 232 or 264 isn't big enough for your needs.
  14. Agree
    trag1c reacted to Slottr in Computer Science Studies in Canada   
    Cheap and international university in Canada doesn't exist. If you're looking at more affordable computer related education, you'll probably want to look at a polytechnic
  15. Agree
    trag1c reacted to Eigenvektor in Having trouble in C... help... somebody.   
    Just want to add something that is not directly related to the question.
     
    Reallocating any time an element is added is bad for performance.
     
    The way most libraries do it is to initialize the array for a certain number of elements, then e.g. double it in size when it is filled to capacity.
     
    And since you expect your list to only contain a specific type of element you could also determine sizeof once and store it.
  16. Like
    trag1c got a reaction from Eigenvektor in Having trouble in C... help... somebody.   
    This more or less comes down to typing... or lack there of it. void* ptr = (void*)somePtr is perfectly valid because you're assigning the pointer to memory address.  However, trying to access it as a pointer + offset won't work because the compiler has no idea what the stride (sizeof(void) which doesn't exist) is. However by declaring array pointer to pointer you can now address elements because it's data type is better defined as void pointer to void pointer which does exist as sizeof(void*) which is just the size of standard pointer. 
     
    So if you declare your array as void** the compiler will now see its pointer to pointer and as such you can address it as pointer + offset to retrieve a pointer to an element.
  17. Agree
    trag1c reacted to Eigenvektor in 84% PERFORMANCE INCREASE?   
    Because it would be extremely difficult to optimize any reasonably large program that way. You might just as well be writing assembler if you do that. It also makes the code less portable. Ideally any modern optimizing compiler should take care of such things for you already.
     
    There are very few registers and they are 8, 16, 32 or 64 bit in size (x86_64). E.g. there's 8x64 bit general purpose registers on x86_64, that can be subdivided into 32, 16 or 8 bit registers. This is extremely tiny compared to the gigabytes of RAM you have available today.
     
    Here's an overview of the registers available on modern x86_64: https://en.wikibooks.org/wiki/X86_Assembly/X86_Architecture
  18. Agree
    trag1c reacted to Eigenvektor in 84% PERFORMANCE INCREASE?   
    How many is "many" and what size were they? Technically a 64 bit register like RAX can hold up to 8x8 bit values. While you can only directly access two of these (AL/AH) you can use bit shift operations to make full use of it. But that adds a lot of mental complexity/overhead to keep track of when you want to write anything remotely non-trivial.
     
    Also keep in mind that the "register" keyword is just a hint for the compiler that you would like to store that value in a register. The compiler is free to ignore you. A modern compiler will generally be better at figuring out which value is the best to keep in a register (assuming you've turned on optimizations), so the performance difference is most likely negligible once you write more complex things (and you actually know what you're doing, otherwise I would expect the compiler's code to outperform you, by a lot).
  19. Agree
    trag1c reacted to Kilrah in 84% PERFORMANCE INCREASE?   
    Also if you really want to understand what happens you should... look at the assembly output of the compiler to check if it really did what you think it did, or what it did if you don't think it matches.
  20. Agree
    trag1c reacted to dcgreen2k in c++ const, constexpr, macros   
    You don't need to use polymorphism or any other fancy OOP features when using C++. In fact, you could write C++ code just like how you would write in C and have it work just the same.
     
    Why might someone prefer to write in C++ instead of C, if they aren't making use of OOP? For one, C++ has the standard template library. It's a set of generic data structures and algorithms, among other things, that I find to be very useful. C++ also has additions to help manage memory, like using smart pointers instead of raw pointers.
  21. Like
    trag1c got a reaction from shadow_ray in Memory leak goes away?   
    This will ultimately depend on your compiler. A compiler may choose to optimize much of your code away since you're only assigning to 'a' and not accessing, essentially see's it as a superfluous call that has no net effect on the outcome.
     
    GCC from -O0 to -O3 for optimization will keep the malloc call but using the same flags on clang show a much different story where the malloc disappears. See the assembly below and you can see. This with printf() commented out.
     
    GCC 13 with -O3
    main: push {r4, lr} movs r0, #0 bl time bl srand .L2: movs r0, #8 bl malloc # YOUR MALLOC CALL mov r4, r0 bl rand str r0, [r4] asrs r0, r0, #31 str r0, [r4, #4] b .L2  
    Clang with 17 with -O3 with no Malloc
    main:                                   # @main         push    rax         xor     edi, edi         call    time@PLT         mov     edi, eax         call    srand@PLT .LBB0_1:                                # =>This Inner Loop Header: Depth=1         call    rand@PLT         jmp     .LBB0_1  
    Even with the printf() call uncommented Clang still does not generate the call to malloc while GCC does. If optimization is turned off Clang will happily generate the malloc call as you would expect.
      main: # @main push rbp mov rbp, rsp sub rsp, 32 mov dword ptr [rbp - 4], 0 xor eax, eax mov edi, eax call time@PLT mov edi, eax call srand@PLT mov qword ptr [rbp - 16], 0 .LBB0_1: # =>This Inner Loop Header: Depth=1 cmp qword ptr [rbp - 16], -1 ja .LBB0_4 mov edi, 8 call malloc@PLT mov qword ptr [rbp - 24], rax call rand@PLT movsxd rcx, eax mov rax, qword ptr [rbp - 24] mov qword ptr [rax], rcx mov rax, qword ptr [rbp - 24] mov rsi, qword ptr [rax] lea rdi, [rip + .L.str] mov al, 0 call printf@PLT mov rax, qword ptr [rbp - 16] add rax, 1 mov qword ptr [rbp - 16], rax jmp .LBB0_1 .LBB0_4: mov eax, dword ptr [rbp - 4] add rsp, 32 pop rbp ret .L.str: .asciz "%p\n"  
     
  22. Agree
  23. Agree
    trag1c got a reaction from wanderingfool2 in Memory leak goes away?   
    This will ultimately depend on your compiler. A compiler may choose to optimize much of your code away since you're only assigning to 'a' and not accessing, essentially see's it as a superfluous call that has no net effect on the outcome.
     
    GCC from -O0 to -O3 for optimization will keep the malloc call but using the same flags on clang show a much different story where the malloc disappears. See the assembly below and you can see. This with printf() commented out.
     
    GCC 13 with -O3
    main: push {r4, lr} movs r0, #0 bl time bl srand .L2: movs r0, #8 bl malloc # YOUR MALLOC CALL mov r4, r0 bl rand str r0, [r4] asrs r0, r0, #31 str r0, [r4, #4] b .L2  
    Clang with 17 with -O3 with no Malloc
    main:                                   # @main         push    rax         xor     edi, edi         call    time@PLT         mov     edi, eax         call    srand@PLT .LBB0_1:                                # =>This Inner Loop Header: Depth=1         call    rand@PLT         jmp     .LBB0_1  
    Even with the printf() call uncommented Clang still does not generate the call to malloc while GCC does. If optimization is turned off Clang will happily generate the malloc call as you would expect.
      main: # @main push rbp mov rbp, rsp sub rsp, 32 mov dword ptr [rbp - 4], 0 xor eax, eax mov edi, eax call time@PLT mov edi, eax call srand@PLT mov qword ptr [rbp - 16], 0 .LBB0_1: # =>This Inner Loop Header: Depth=1 cmp qword ptr [rbp - 16], -1 ja .LBB0_4 mov edi, 8 call malloc@PLT mov qword ptr [rbp - 24], rax call rand@PLT movsxd rcx, eax mov rax, qword ptr [rbp - 24] mov qword ptr [rax], rcx mov rax, qword ptr [rbp - 24] mov rsi, qword ptr [rax] lea rdi, [rip + .L.str] mov al, 0 call printf@PLT mov rax, qword ptr [rbp - 16] add rax, 1 mov qword ptr [rbp - 16], rax jmp .LBB0_1 .LBB0_4: mov eax, dword ptr [rbp - 4] add rsp, 32 pop rbp ret .L.str: .asciz "%p\n"  
     
  24. Agree
    trag1c got a reaction from Eigenvektor in Memory leak goes away?   
    This will ultimately depend on your compiler. A compiler may choose to optimize much of your code away since you're only assigning to 'a' and not accessing, essentially see's it as a superfluous call that has no net effect on the outcome.
     
    GCC from -O0 to -O3 for optimization will keep the malloc call but using the same flags on clang show a much different story where the malloc disappears. See the assembly below and you can see. This with printf() commented out.
     
    GCC 13 with -O3
    main: push {r4, lr} movs r0, #0 bl time bl srand .L2: movs r0, #8 bl malloc # YOUR MALLOC CALL mov r4, r0 bl rand str r0, [r4] asrs r0, r0, #31 str r0, [r4, #4] b .L2  
    Clang with 17 with -O3 with no Malloc
    main:                                   # @main         push    rax         xor     edi, edi         call    time@PLT         mov     edi, eax         call    srand@PLT .LBB0_1:                                # =>This Inner Loop Header: Depth=1         call    rand@PLT         jmp     .LBB0_1  
    Even with the printf() call uncommented Clang still does not generate the call to malloc while GCC does. If optimization is turned off Clang will happily generate the malloc call as you would expect.
      main: # @main push rbp mov rbp, rsp sub rsp, 32 mov dword ptr [rbp - 4], 0 xor eax, eax mov edi, eax call time@PLT mov edi, eax call srand@PLT mov qword ptr [rbp - 16], 0 .LBB0_1: # =>This Inner Loop Header: Depth=1 cmp qword ptr [rbp - 16], -1 ja .LBB0_4 mov edi, 8 call malloc@PLT mov qword ptr [rbp - 24], rax call rand@PLT movsxd rcx, eax mov rax, qword ptr [rbp - 24] mov qword ptr [rax], rcx mov rax, qword ptr [rbp - 24] mov rsi, qword ptr [rax] lea rdi, [rip + .L.str] mov al, 0 call printf@PLT mov rax, qword ptr [rbp - 16] add rax, 1 mov qword ptr [rbp - 16], rax jmp .LBB0_1 .LBB0_4: mov eax, dword ptr [rbp - 4] add rsp, 32 pop rbp ret .L.str: .asciz "%p\n"  
     
  25. Agree
    trag1c got a reaction from dcgreen2k in Memory leak goes away?   
    This will ultimately depend on your compiler. A compiler may choose to optimize much of your code away since you're only assigning to 'a' and not accessing, essentially see's it as a superfluous call that has no net effect on the outcome.
     
    GCC from -O0 to -O3 for optimization will keep the malloc call but using the same flags on clang show a much different story where the malloc disappears. See the assembly below and you can see. This with printf() commented out.
     
    GCC 13 with -O3
    main: push {r4, lr} movs r0, #0 bl time bl srand .L2: movs r0, #8 bl malloc # YOUR MALLOC CALL mov r4, r0 bl rand str r0, [r4] asrs r0, r0, #31 str r0, [r4, #4] b .L2  
    Clang with 17 with -O3 with no Malloc
    main:                                   # @main         push    rax         xor     edi, edi         call    time@PLT         mov     edi, eax         call    srand@PLT .LBB0_1:                                # =>This Inner Loop Header: Depth=1         call    rand@PLT         jmp     .LBB0_1  
    Even with the printf() call uncommented Clang still does not generate the call to malloc while GCC does. If optimization is turned off Clang will happily generate the malloc call as you would expect.
      main: # @main push rbp mov rbp, rsp sub rsp, 32 mov dword ptr [rbp - 4], 0 xor eax, eax mov edi, eax call time@PLT mov edi, eax call srand@PLT mov qword ptr [rbp - 16], 0 .LBB0_1: # =>This Inner Loop Header: Depth=1 cmp qword ptr [rbp - 16], -1 ja .LBB0_4 mov edi, 8 call malloc@PLT mov qword ptr [rbp - 24], rax call rand@PLT movsxd rcx, eax mov rax, qword ptr [rbp - 24] mov qword ptr [rax], rcx mov rax, qword ptr [rbp - 24] mov rsi, qword ptr [rax] lea rdi, [rip + .L.str] mov al, 0 call printf@PLT mov rax, qword ptr [rbp - 16] add rax, 1 mov qword ptr [rbp - 16], rax jmp .LBB0_1 .LBB0_4: mov eax, dword ptr [rbp - 4] add rsp, 32 pop rbp ret .L.str: .asciz "%p\n"  
     
×