search for: leonardo

...way to connect the objects in the .lib to the > corresponding .ghash files, this would disable ghash usage for a large > amount of inputs. Supporting both is an option, but it adds a bit of > complexity and I’m not totally convinced it’s worth it > > On Fri, Jan 26, 2018 at 11:38 AM Leonardo Santagada <santagada at gmail.com> > wrote: > >> it does. >> >> I just had an epiphany: why not just write a .ghash file and have lld >> read those if they exist for an .obj file? >> >> Seem much simpler than trying to wire up a 20 year old file forma...

...ains. If you have many 3rd party libraries, it may be necessary to rewrite the .lib files too, not just the .obj files. Eventually I’ll get around to implementing all of this as well, as well as better heuristics in lld-link to disable ghash if it’s going to be slow On Sun, Jan 28, 2018 at 1:51 PM Leonardo Santagada <santagada at gmail.com> wrote: > Ok I went for kind of middle ground solution, I patch in the obj files, > but as adding a new section didn't seem to work, I add a "shadow" section, > by editing the pointer to line number and the virtual size on the .debug$T...

I don’t have pgo numbers. When I build using -flto=thin the link time is significantly faster than msvc /ltcg and runtime is slightly faster, but I haven’t tested on a large variety of different workloads, so YMMV. Link time will definitely be faster though On Sun, Jan 28, 2018 at 2:20 PM Leonardo Santagada <santagada at gmail.com> wrote: > This part is only for objects with /Z7 debug information in them right? I > think most of the third parties are either: .lib/obj without debug > information, the same with information on pdb files. Rewriting all > .lib/.obj with /Z7 inf...

...urner at google.com> wrote: > In general, we should be able to accept any MSVC .obj file to LLD. At the > very least, we're not aware of any cases that don't work. > > Does your MSVC .obj file link fine before you add the .debug$H? > > On Fri, Jan 26, 2018 at 11:23 AM Leonardo Santagada <santagada at gmail.com> > wrote: > >> Okay, apparently coff2yaml and yaml2coff are not in a great place as they >> both don't deal well with the fact that you can have overlapping sections, >> which seems to be what clang-cl produces (the .data section p...

...times from multiple processes. So it only looks like the memory usage is high because it reserves a large amount of address space in each process. But the total amount of physical memory used will not increase when additional instances of the same file are mapped. On Mon, Jan 29, 2018 at 9:24 AM Leonardo Santagada <santagada at gmail.com> wrote: > > I cleaned up my tests and figured that the obj file generated with > problems was only with msvc 2015, so trying again with msvc 2017 I get: > > lld-link: 4s > lld-link /debug: 1m30s and ~20gb of ram > lld-link /debug:ghash:...

...r ETW+WPA ( https://github.com/google/UIforETW/releases) are probably what you'll need to do. (We'd definitely love patches to improve performance, or even just ideas about how to make things faster. Improving link speed is one of our biggest priorities.) On Mon, Jan 29, 2018 at 10:47 AM Leonardo Santagada <santagada at gmail.com> wrote: > Yeah true, is there any switches to profile the linker? > > On 29 Jan 2018 18:43, "Zachary Turner" <zturner at google.com> wrote: > >> Part of the reason why lld is so fast is because we map every input file >&g...

Hola Amigos: Gracias por todas las respuestas sobre como filtrar datos en un data frame. Ahora tengo un nuevo problema, necesito instalar R 2.15 manualmente, pero no puedo hacerlo desde un repositorio. Alguna solución??????????' Un Saludos, Leonardo ------------ próxima parte ------------ An embedded and charset-unspecified text was scrubbed... Name: no disponible URL: <https://stat.ethz.ch/pipermail/r-help-es/attachments/20120713/48a123f6/attachment.pl>

...39;s one area for huge potential gains, but only some parts of the algorithm are parallelizable. We're trying to squeeze every last bit of performance out of the single-threaded case first before we parallelize, but that option is definitely still there for us. On Mon, Jan 29, 2018 at 4:35 PM Leonardo Santagada <santagada at gmail.com> wrote: > Does packing obj files in .lib helps linking in any way? My understanding > is that there would be no difference. It could help if I could make a pdb > per lib, but there is no way to do so... Maybe we could implement this on > lld? &gt...

...any 3rd party libraries, it may be necessary to rewrite the > .lib files too, not just the .obj files. Eventually I’ll get around to > implementing all of this as well, as well as better heuristics in lld-link > to disable ghash if it’s going to be slow > On Sun, Jan 28, 2018 at 1:51 PM Leonardo Santagada <santagada at gmail.com> > wrote: > >> Ok I went for kind of middle ground solution, I patch in the obj files, >> but as adding a new section didn't seem to work, I add a "shadow" section, >> by editing the pointer to line number and the virtual...

...vs 2015) doing fastlink. Now we are in a very good place, still not as fast as an incremental link, but generating better code and a full pdb. Do you want any of these patches? They don't look the nicest they can be but might help someone doing this cleanly. On Wed, Jan 31, 2018 at 9:39 AM, Leonardo Santagada <santagada at gmail.com> wrote: > Uhmm I changed only type hashing... Ok back to trying it again. Let's me > find where it is looking at 20 bytes instead of using the size of global > type hash. > > On 30 Jan 2018 21:33, "Zachary Turner" <zturner at g...

...the moment we are focused on making full linking as fast as possible because it's much easier and still provides benefits. We think we can get it fast enough that it will be acceptable, and that should give us some extra time to do incremental linking properly. On Mon, Jan 29, 2018 at 1:07 PM Leonardo Santagada <santagada at gmail.com> wrote: > About incremental linking, the only thing from my benchmark that needs to > be incremental is the pdb patching as generating the binary seems faster > than incremental linking on link.exe, so did anyone propose renaming the > current bi...

...er with the ghahes... my guess is that we have a bunch of pdb files for some third party libraries and calculating those ghashes takes more time than actual linking of this small part of the source (it links in 4s in both link.exe and lld-link.exe without ghashes). On Fri, Jan 26, 2018 at 8:52 PM, Leonardo Santagada <santagada at gmail.com> wrote: > We don't generate any .lib as those don't work well with incremental > linking (and give zero advantages when linking AFAIK), and it would be > pretty easy to have a modern format for having a .ghash for multiple files, > someth...

Did you change both the compiler and linker (or make sure that your objcopy was updated to write your 64 bit hashes)? The linker is hardcodes to expect 20-byte sha 1s , anything else and it will recompute them in serial On Tue, Jan 30, 2018 at 12:28 PM Leonardo Santagada <santagada at gmail.com> wrote: > Nice and why are you trying blake2 instead of a faster hash algorithm? And > do you have any guess as to why xxHash64 wasn't faster than SHA1? I still > have to see how many collision I get with it, but it seems so improbable > that...

...ve pgo numbers. When I build using -flto=thin the link time is > significantly faster than msvc /ltcg and runtime is slightly faster, but I > haven’t tested on a large variety of different workloads, so YMMV. Link > time will definitely be faster though > On Sun, Jan 28, 2018 at 2:20 PM Leonardo Santagada <santagada at gmail.com> > wrote: > >> This part is only for objects with /Z7 debug information in them right? I >> think most of the third parties are either: .lib/obj without debug >> information, the same with information on pdb files. Rewriting all >&g...

...ogle/UIforETW/releases) are probably what you'll > need to do. > > (We'd definitely love patches to improve performance, or even just ideas > about how to make things faster. Improving link speed is one of our > biggest priorities.) > > On Mon, Jan 29, 2018 at 10:47 AM Leonardo Santagada <santagada at gmail.com> > wrote: > >> Yeah true, is there any switches to profile the linker? >> >> On 29 Jan 2018 18:43, "Zachary Turner" <zturner at google.com> wrote: >> >>> Part of the reason why lld is so fast is because w...

...esses. So it only looks like the memory usage is high because it > reserves a large amount of address space in each process. But the total > amount of physical memory used will not increase when additional instances > of the same file are mapped. > > On Mon, Jan 29, 2018 at 9:24 AM Leonardo Santagada <santagada at gmail.com> > wrote: > >> >> I cleaned up my tests and figured that the obj file generated with >> problems was only with msvc 2015, so trying again with msvc 2017 I get: >> >> lld-link: 4s >> lld-link /debug: 1m30s and ~20gb of...

...jectYAML. BTW, I've also tried 8 byte ghashes locally, and in theory that should be faster, but I found a case where it's slower than 20 byte ghashes. This almost seems impossible, so I need to spend some time examining profiles to see what's going on. On Wed, Jan 31, 2018 at 4:44 AM Leonardo Santagada <santagada at gmail.com> wrote: > So I found all 20 bytes and changed then to GHASH_SIZE (a const I > defined in typehashing.h) and finished the switch to xxHash64, that > saved me around 50 seconds to 56s, then I changed it to uint64_t > instead of a 8 byte uint_8 arra...

....com> wrote: > Did you change both the compiler and linker (or make sure that your > objcopy was updated to write your 64 bit hashes)? > > The linker is hardcodes to expect 20-byte sha 1s , anything else and it > will recompute them in serial > On Tue, Jan 30, 2018 at 12:28 PM Leonardo Santagada <santagada at gmail.com> > wrote: > >> Nice and why are you trying blake2 instead of a faster hash algorithm? >> And do you have any guess as to why xxHash64 wasn't faster than SHA1? I >> still have to see how many collision I get with it, but it seems so...

...d on making full linking as fast as > possible because it's much easier and still provides benefits. We think we > can get it fast enough that it will be acceptable, and that should give us > some extra time to do incremental linking properly. > > On Mon, Jan 29, 2018 at 1:07 PM Leonardo Santagada <santagada at gmail.com> > wrote: > >> About incremental linking, the only thing from my benchmark that needs to >> be incremental is the pdb patching as generating the binary seems faster >> than incremental linking on link.exe, so did anyone propose renamin...

...ore optimizations that went in after that. And to get down to 28s I also used an LTO'ed build of lld. If you're building LLD at ToT you should have everything needed to reproduce those numbers, but it will vary depending on the speed of your CPU obviously. On Tue, Jan 30, 2018 at 9:21 AM Leonardo Santagada <santagada at gmail.com> wrote: > Today I played around replacing the sha1 with xxHash64 and the results so > far are bad. Linking times almost doubled and I can't really explain why, > the only thing that comes to mind is hash collisions but on type names they > sh...