Displaying 20 results from an estimated 400 matches similar to: "truncating aggregation output"
2005 Dec 22
9
truncating aggregation output only
Hello dtrace-discuss,
Sometimes I want to run a script for some time and every n second
output N top entries. trunc() isn''t suitable here as it also removed
keys/values. I want it ''coz over time if I use sum() entries which
are normally truncated can actually get to top over a time.
Maybe printa() extension, something like: printa(@b[10]) - to output
top 10?
--
2005 Oct 31
11
Aggregation elements
Howdy,
Is there a method to get the number of elements in an aggregation? Are the
results stored in an aggregation guaranteed to be in any type of order?
Thanks for any insight,
- Ryan
--
UNIX Administrator
http://daemons.net/~matty
2005 Sep 15
10
Can I use printa() for printing multiple agg regations?
Hi Bryan,
> Does that sit well with everyone?
Seems fine to me.
Just revisiting one of Dragan''s points, though (sorry if I missed the
answer) - is there a reason for making this global (via a #pragma) rather
than, say, simply providing two functions which print in the different
orders? e.g. printa() for sort by sample, printak() for sort by key.
My reason for wanting to do both in
2018 Apr 11
0
exploring possibilities for unifying ThinLTO and FullLTO frontend + initial optimization pipeline
Hi Teresa,
Thank you so much for your reply!
I am on vacation until the end of this week and on EuroLLVM next week, so I have to apologize in advance that my replies are delayed.
>>Right - see my reply on this from last night, at the very least the ThinLTO importing thresholds will need retuning if we will
>>perform optimizations like unrolling/vectorization/etc that tend to
2018 Mar 27
1
[pre-RFC] Data races in concurrent ThinLTO processes
Hi Steven and Peter,
I think we resolved all the misunderstanding/concerns that we had with the proposal and decided that we don’t have to implement heavy-weight synchronization solutions (such as read-write locks, etc). Lightweight solution is expected to work on MacOS and Windows (however, there might be issues with Windows supporting non-NTFS file systems).
There are two options for the
2018 Apr 11
1
exploring possibilities for unifying ThinLTO and FullLTO frontend + initial optimization pipeline
See attached some quick slides (backup from the dev meeting talk) about the
pass pipeline.
--
Mehdi
Le mer. 11 avr. 2018 à 12:18, Mehdi AMINI <joker.eph at gmail.com> a écrit :
>
>
> Le mer. 11 avr. 2018 à 11:20, <katya.romanova at sony.com> a écrit :
>
>>
>>
>>
>>
>> *From:* Mehdi AMINI <joker.eph at gmail.com>
>> *Sent:*
2018 Apr 11
0
exploring possibilities for unifying ThinLTO and FullLTO frontend + initial optimization pipeline
Le mer. 11 avr. 2018 à 11:20, <katya.romanova at sony.com> a écrit :
>
>
>
>
> *From:* Mehdi AMINI <joker.eph at gmail.com>
> *Sent:* Tuesday, April 10, 2018 11:53 PM
> *To:* Romanova, Katya <katya.romanova at sony.com>
> *Cc:* David Blaikie <dblaikie at gmail.com>; Teresa Johnson <
> tejohnson at google.com>; llvm-dev <llvm-dev at
2018 Apr 11
2
exploring possibilities for unifying ThinLTO and FullLTO frontend + initial optimization pipeline
From: Mehdi AMINI <joker.eph at gmail.com>
Sent: Tuesday, April 10, 2018 11:53 PM
To: Romanova, Katya <katya.romanova at sony.com>
Cc: David Blaikie <dblaikie at gmail.com>; Teresa Johnson <tejohnson at google.com>; llvm-dev <llvm-dev at lists.llvm.org>
Subject: Re: [llvm-dev] exploring possibilities for unifying ThinLTO and FullLTO frontend + initial optimization
2018 Mar 27
0
[pre-RFC] Data races in concurrent ThinLTO processes
On Mon, Mar 26, 2018 at 7:34 PM, <katya.romanova at sony.com> wrote:
> Hi Peter,
>
>
>
> Thank you for the clarification J.
>
>
>
> I’m sure you have a very good understanding of how much efforts it will
> take to write a patch for legacy C LTO to implement caching the same way
> it’s done in new C++ LTO API. How easy/difficult do you think it will be
>
2018 Mar 27
2
[pre-RFC] Data races in concurrent ThinLTO processes
Hi Peter,
Thank you for the clarification ☺.
I’m sure you have a very good understanding of how much efforts it will take to write a patch for legacy C LTO to implement caching the same way it’s done in new C++ LTO API. How easy/difficult do you think it will be (very roughly, in LOC)? Do you anticipate that a lot of existing legacy C LTO infrastructure will have to be rewritten? Could this also
2018 Apr 11
0
exploring possibilities for unifying ThinLTO and FullLTO frontend + initial optimization pipeline
Le mar. 10 avr. 2018 à 23:18, <katya.romanova at sony.com> a écrit :
> Hi Mehdi,
>
>
>
> Awesome! It’s a very clear design. The only question left is which
> pipeline to choose for unified compile-phase optimization pipeline.
>
> - ThinLTO compile-phase pipeline? It might very negatively affect
> compile-time and the memory footprint for FullLTO link-phase.
2018 Apr 11
2
exploring possibilities for unifying ThinLTO and FullLTO frontend + initial optimization pipeline
On Tue, Apr 10, 2018 at 11:52 PM, Mehdi AMINI <joker.eph at gmail.com> wrote:
>
>
> Le mar. 10 avr. 2018 à 23:18, <katya.romanova at sony.com> a écrit :
>
>> Hi Mehdi,
>>
>>
>>
>> Awesome! It’s a very clear design. The only question left is which
>> pipeline to choose for unified compile-phase optimization pipeline.
>>
>> -
2018 Apr 11
1
exploring possibilities for unifying ThinLTO and FullLTO frontend + initial optimization pipeline
I think for ld64, you can mix thinLTO and fullLTO files and ld64 is going to compile them separately and combine the result. (Mehdi can confirm). I think this is aligned with the fact that whether to use full or thin LTO is decided during clang invocation, not linker invocation. I am not against any of the model, but I think we need to do some research before making the effort to switch the model.
2018 Mar 27
0
[pre-RFC] Data races in concurrent ThinLTO processes
> On Mar 26, 2018, at 6:03 PM, katya.romanova at sony.com wrote:
>
> Hi Steven,
> Look at my replies inline (below your comments).
> Katya.
>
> From: stevenwu at apple.com <mailto:stevenwu at apple.com> <stevenwu at apple.com <mailto:stevenwu at apple.com>>
> Sent: Thursday, March 22, 2018 4:46 PM
> To: Romanova, Katya <katya.romanova at sony.com
2018 Apr 11
3
exploring possibilities for unifying ThinLTO and FullLTO frontend + initial optimization pipeline
Hi Mehdi,
Awesome! It’s a very clear design. The only question left is which pipeline to choose for unified compile-phase optimization pipeline.
- ThinLTO compile-phase pipeline? It might very negatively affect compile-time and the memory footprint for FullLTO link-phase. That was the reason why so many optimization were moved from the link-phase to the parallel compile-phase for FullLTO
2018 Mar 27
0
[pre-RFC] Data races in concurrent ThinLTO processes
On Mon, Mar 26, 2018 at 6:03 PM, <katya.romanova at sony.com> wrote:
> Hi Steven,
>
> Look at my replies inline (below your comments).
>
> Katya.
>
>
>
> *From:* stevenwu at apple.com <stevenwu at apple.com>
> *Sent:* Thursday, March 22, 2018 4:46 PM
> *To:* Romanova, Katya <katya.romanova at sony.com>
> *Cc:* Teresa Johnson <tejohnson at
2014 Feb 25
2
[LLVMdev] question about the alignment of the .text section
Is there a reason why the alignment of the .text section should be 4 when we are optimizing for size (-Os or -Oz)? Note that when are optimizing for size, the symbols inside .text section don't have any alignment constraints. Alignment=4 for .text with the unaligned symbols inside this section prevent our linker from de-duplicating functions. Could the alignment of the .text section be
2015 Nov 20
2
UBSan runtime options
Hello,
I have several low priority UBSan questions...
(1) Is there a way for UBSan to print its output to a file that the user specified (e.g. via option) instead of dumping everything on stderr?
(2) Out of curiosity, why is the name of the option for printing the stacktrace spelled
"UBSAN_OPTIONS=print_stacktrace=1", though the allowed value is 1?
Since the only one value is
2018 Apr 10
3
exploring possibilities for unifying ThinLTO and FullLTO frontend + initial optimization pipeline
Hi David,
Thank you so much for your reply!
>> You're dealing with a situation where you are shipped BC files offline and then do one, or multiple builds with these BC files?
Yes, that’s exactly the case.
>> If the scenario was more like a naive build: Multiple BC files generated on a single (multi-core/threaded) machine (but some Thin, some
>> Full) & then fed to the
2013 Apr 09
1
[LLVMdev] inefficient code generation for 128-bit->256-bit typecast intrinsics
Hello,
LLVM generates two additional instructions for 128->256 bit typecasts
(e.g. _mm256_castsi128_si256()) to clear out the upper 128 bits of YMM register corresponding to source XMM register.
vxorps xmm2,xmm2,xmm2
vinsertf128 ymm0,ymm2,xmm0,0x0
Most of the industry-standard C/C++ compilers (GCC, Intel's compiler, Visual Studio compiler) don't
generate any extra moves