search for: memcpy'ing

...you mean that cross-target execution CAN break on examples like > this > one? [eventually on this example it doesn't] > > struct X { > void *a; > int b; > } x; > > *(int *) ((char *)&x + sizeof(void*)) = 1; > What about something much simpler: memcpy'ing an array of structs around. The number of bytes to be memcpy'd is dependent on the padding of the struct. --Owen -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2624 bytes Desc: not available URL...

..., each thread in LLD consumes very small amount of memory (probably just a few megabytes), so that's not a problem for me. At the final stage of linking, we spawn threads to copy section contents and apply relocations, and I guess that causes a lot of memory traffic because that's basically memcpy'ing input files to an output file, so the memory bandwidth could be a limiting factor there. But I do not see a reason to limit the number of threads to the number of physical core. For LLD, it seems like we can just spawn as many threads as HT provides. -------------- next part --------------...

Owen Anderson wrote: > What about something much simpler: memcpy'ing an array of structs > around. The number of bytes to be memcpy'd is dependent on the padding > of the struct. Anyway, I've got your point. sizeof() constant expression is calculated during wrong stage of compilation process. Thanks for pointing it out! -- Best Regards...

...mall amount of memory >> (probably just a few megabytes), so that's not a problem for me. At the >> final stage of linking, we spawn threads to copy section contents and apply >> relocations, and I guess that causes a lot of memory traffic because that's >> basically memcpy'ing input files to an output file, so the memory bandwidth >> could be a limiting factor there. But I do not see a reason to limit the >> number of threads to the number of physical core. For LLD, it seems like we >> can just spawn as many threads as HT provides. > > &gt...

...so that's not a problem for me. At the >> >> final stage of linking, we spawn threads to copy section contents and >> >> apply >> >> relocations, and I guess that causes a lot of memory traffic because >> >> that's >> >> basically memcpy'ing input files to an output file, so the memory >> >> bandwidth >> >> could be a limiting factor there. But I do not see a reason to limit >> >> the >> >> number of threads to the number of physical core. For LLD, it seems >> >> like...

On Nov 11, 2008, at 5:11 PM, Peter Shugalev wrote: > Owen Anderson wrote: >> What about something much simpler: memcpy'ing an array of structs >> around. The number of bytes to be memcpy'd is dependent on the >> padding >> of the struct. > > Anyway, I've got your point. sizeof() constant expression is > calculated > during wrong stage of compilation process. Thanks for...

Owen Anderson wrote: > If you configure it as a cross-compiler for 64-bit x86 Linux and feed it > the appropriate header files, it will produce the same output on any > platform. However, that output will not be executable on most > platforms, just on 64-bit x86 Linux. The problems go beyond pointer > size. The size of int is implementation dependent, etc. The layout and

...e), Actual primary surface is a shadow bo though. Display updates are done by sending a draw command for the primary surface, with the pixel data coming from the dumb gem bo. We could maybe optimize that, by having the image chunk point directly to the dumb gem bo instead of allocating memory and memcpy'ing the pixel data. I don't feel like putting too much effort into qxl performance optimization though. The time is better spent on virtio-gpu I think. BTW: should I send virtio-gpu kernel patches to spice-devel too? > Not also sure if this workaround make the server consume more net...

On Nov 11, 2008, at 2:19 PM, Peter Shugalev wrote: > Hi, > > Owen Anderson wrote: >>> I can see only one reason for such dependence: inclusion of system >>> headers in /usr/include. If I compile llvm-gcc with predefined set >>> of >>> Linux headers (the way cross-compilers are usually made) will the IR >>> output be the same no matter which

...omething like this, but shelved the idea for the first release. > So yes, LLVM can capture the live variable information and stack into > a buffer, but it currently has no functionality to do so, thus you > have to do it yourself as I do.  Although the above way is vastly > faster then memcpy'ing entire stacks around (as we do in C++ itself to > simulate full coroutines). >From what you're telling me, as far as LLVM is concerned there are ways to do it manually, you just have to pick one that suits the project. There aren't any automatic solutions, nor hooks to attac...

...> the stack, and give me a way to capture and restore that stack (and > pc)? So yes, LLVM can capture the live variable information and stack into a buffer, but it currently has no functionality to do so, thus you have to do it yourself as I do. Although the above way is vastly faster then memcpy'ing entire stacks around (as we do in C++ itself to simulate full coroutines). Also, I apologize for the length, once I start explaining things I find it hard to stop, should have seen how I was going on about how sexpressions are better then xml yesterday at work (and no, we use neither, it...

I saw this was mentioned briefly last year, but there seemed to be some confusion as to what coroutines entailed and the thread died out. This technique has an unfortunate number of names, but it does get a lot of use, including popular languages like Ruby. I'm currently working on a programming language called Minnow (http://www.minnow-lang.org). It's an actor-based language, where

On Thu, Nov 17, 2016 at 6:12 AM, Teresa Johnson via llvm-dev < llvm-dev at lists.llvm.org> wrote: > > > On Thu, Nov 17, 2016 at 4:11 AM, Rafael Espíndola via llvm-dev < > llvm-dev at lists.llvm.org> wrote: > >> > Sounds like threading isn't beneficial much beyond the second CPU... >> > Maybe blindly creating one thread per core isn't the best