| EventName | Description |
|---|---|
| INST_RETIRED.ANY | This event counts the number of instructions retired from execution. For instructions that consist of multiple micro-ops, this event counts the retirement of the last micro-op of the instruction. Counting continues during hardware interrupts, traps, and inside interrupt handlers. |
| CPU_CLK_UNHALTED.THREAD | This event counts the number of core cycles while the thread is not in a halt state. The thread enters the halt state when it is running the HLT instruction. This event is a component in many key event ratios. The core frequency may change from time to time due to transitions associated with Enhanced Intel SpeedStep Technology or TM2. For this reason this event may have a changing ratio with regards to time. When the core frequency is constant, this event can approximate elapsed time while the core was not in the halt state. It is counted on a dedicated fixed counter, leaving the four (eight when Hyperthreading is disabled) programmable counters available for other events. |
| CPU_CLK_UNHALTED.REF_TSC | This event counts the number of reference cycles when the core is not in a halt state. The core enters the halt state when it is running the HLT instruction or the MWAIT instruction. This event is not affected by core frequency changes (for example, P states, TM2 transitions) but has the same incrementing frequency as the time stamp counter. This event can approximate elapsed time while the core was not in a halt state. This event has a constant ratio with the CPU_CLK_UNHALTED.REF_XCLK event. It is counted on a dedicated fixed counter, leaving the four (eight when Hyperthreading is disabled) programmable counters available for other events. |
| BR_INST_EXEC.NONTAKEN_CONDITIONAL | Not taken macro-conditional branches. |
| BR_INST_EXEC.TAKEN_CONDITIONAL | Taken speculative and retired macro-conditional branches. |
| BR_INST_EXEC.TAKEN_DIRECT_JUMP | Taken speculative and retired macro-conditional branch instructions excluding calls and indirects. |
| BR_INST_EXEC.TAKEN_INDIRECT_JUMP_NON_CALL_RET | Taken speculative and retired indirect branches excluding calls and returns. |
| BR_INST_EXEC.TAKEN_INDIRECT_NEAR_RETURN | Taken speculative and retired indirect branches with return mnemonic. |
| BR_INST_EXEC.TAKEN_DIRECT_NEAR_CALL | Taken speculative and retired direct near calls. |
| BR_INST_EXEC.TAKEN_INDIRECT_NEAR_CALL | Taken speculative and retired indirect calls. |
| BR_INST_EXEC.ALL_CONDITIONAL | Speculative and retired macro-conditional branches. |
| BR_INST_EXEC.ALL_DIRECT_JMP | Speculative and retired macro-unconditional branches excluding calls and indirects. |
| BR_INST_EXEC.ALL_INDIRECT_JUMP_NON_CALL_RET | Speculative and retired indirect branches excluding calls and returns. |
| BR_INST_EXEC.ALL_INDIRECT_NEAR_RETURN | Speculative and retired indirect return branches. |
| BR_INST_EXEC.ALL_DIRECT_NEAR_CALL | Speculative and retired direct near calls. |
| BR_MISP_EXEC.NONTAKEN_CONDITIONAL | Not taken speculative and retired mispredicted macro conditional branches. |
| BR_MISP_EXEC.TAKEN_CONDITIONAL | Taken speculative and retired mispredicted macro conditional branches. |
| BR_MISP_EXEC.TAKEN_INDIRECT_JUMP_NON_CALL_RET | Taken speculative and retired mispredicted indirect branches excluding calls and returns. |
| BR_MISP_EXEC.TAKEN_RETURN_NEAR | Taken speculative and retired mispredicted indirect branches with return mnemonic. |
| BR_MISP_EXEC.TAKEN_DIRECT_NEAR_CALL | Taken speculative and retired mispredicted direct near calls. |
| BR_MISP_EXEC.TAKEN_INDIRECT_NEAR_CALL | Taken speculative and retired mispredicted indirect calls. |
| BR_MISP_EXEC.ALL_CONDITIONAL | Speculative and retired mispredicted macro conditional branches. |
| BR_MISP_EXEC.ALL_INDIRECT_JUMP_NON_CALL_RET | Mispredicted indirect branches excluding calls and returns. |
| BR_MISP_EXEC.ALL_DIRECT_NEAR_CALL | Speculative and retired mispredicted direct near calls. |
| CPU_CLK_UNHALTED.THREAD_P | Thread cycles when thread is not in halt state. |
| ITLB.ITLB_FLUSH | Flushing of the Instruction TLB (ITLB) pages, includes 4k/2M/4M pages. |
| ICACHE.HIT | Number of Instruction Cache, Streaming Buffer and Victim Cache Reads. both cacheable and noncacheable, including UC fetches. |
| ICACHE.MISSES | This event counts the number of instruction cache, streaming buffer and victim cache misses. Counting includes unchacheable accesses. |
| LSD.UOPS | Number of Uops delivered by the LSD. |
| LSD.CYCLES_ACTIVE | Cycles Uops delivered by the LSD, but didn't come from the decoder. |
| ILD_STALL.LCP | Stalls caused by changing prefix length of the instruction. |
| ILD_STALL.IQ_FULL | Stall cycles because IQ is full. |
| INSTS_WRITTEN_TO_IQ.INSTS | Valid instructions written to IQ per cycle. |
| IDQ.EMPTY | Instruction Decode Queue (IDQ) empty cycles. |
| IDQ.MITE_UOPS | Uops delivered to Instruction Decode Queue (IDQ) from MITE path. |
| IDQ.DSB_UOPS | Uops delivered to Instruction Decode Queue (IDQ) from the Decode Stream Buffer (DSB) path. |
| IDQ.MS_DSB_UOPS | Uops initiated by Decode Stream Buffer (DSB) that are being delivered to Instruction Decode Queue (IDQ) while Microcode Sequenser (MS) is busy. |
| IDQ.MS_MITE_UOPS | Uops initiated by MITE and delivered to Instruction Decode Queue (IDQ) while Microcode Sequenser (MS) is busy. |
| IDQ.MS_UOPS | Uops delivered to Instruction Decode Queue (IDQ) while Microcode Sequenser (MS) is busy. |
| IDQ.MS_CYCLES | This event counts cycles during which the microcode sequencer assisted the front-end in delivering uops. Microcode assists are used for complex instructions or scenarios that can't be handled by the standard decoder. Using other instructions, if possible, will usually improve performance. See the Intel® 64 and IA-32 Architectures Optimization Reference Manual for more information. |
| IDQ_UOPS_NOT_DELIVERED.CORE | This event counts the number of uops not delivered to the back-end per cycle, per thread, when the back-end was not stalled. In the ideal case 4 uops can be delivered each cycle. The event counts the undelivered uops - so if 3 were delivered in one cycle, the counter would be incremented by 1 for that cycle (4 - 3). If the back-end is stalled, the count for this event is not incremented even when uops were not delivered, because the back-end would not have been able to accept them. This event is used in determining the front-end bound category of the top-down pipeline slots characterization. |
| IDQ_UOPS_NOT_DELIVERED.CYCLES_0_UOPS_DELIV.CORE | Cycles per thread when 4 or more uops are not delivered to Resource Allocation Table (RAT) when backend of the machine is not stalled. |
| IDQ_UOPS_NOT_DELIVERED.CYCLES_LE_1_UOP_DELIV.CORE | Cycles per thread when 3 or more uops are not delivered to Resource Allocation Table (RAT) when backend of the machine is not stalled. |
| DSB2MITE_SWITCHES.COUNT | Decode Stream Buffer (DSB)-to-MITE switches. |
| DSB2MITE_SWITCHES.PENALTY_CYCLES | This event counts the cycles attributed to a switch from the Decoded Stream Buffer (DSB), which holds decoded instructions, to the legacy decode pipeline. It excludes cycles when the back-end cannot accept new micro-ops. The penalty for these switches is potentially several cycles of instruction starvation, where no micro-ops are delivered to the back-end. |
| DSB_FILL.OTHER_CANCEL | Cases of cancelling valid DSB fill not because of exceeding way limit. |
| DSB_FILL.EXCEED_DSB_LINES | Cycles when Decode Stream Buffer (DSB) fill encounter more than 3 Decode Stream Buffer (DSB) lines. |
| INT_MISC.RAT_STALL_CYCLES | Cycles when Resource Allocation Table (RAT) external stall is sent to Instruction Decode Queue (IDQ) for the thread. |
| PARTIAL_RAT_STALLS.FLAGS_MERGE_UOP | Increments the number of flags-merge uops in flight each cycle. |
| PARTIAL_RAT_STALLS.SLOW_LEA_WINDOW | This event counts the number of cycles with at least one slow LEA uop being allocated. A uop is generally considered as slow LEA if it has three sources (for example, two sources and immediate) regardless of whether it is a result of LEA instruction or not. Examples of the slow LEA uop are or uops with base, index, and offset source operands using base and index reqisters, where base is EBR/RBP/R13, using RIP relative or 16-bit addressing modes. See the Intel® 64 and IA-32 Architectures Optimization Reference Manual for more details about slow LEA instructions. |
| PARTIAL_RAT_STALLS.MUL_SINGLE_UOP | Multiply packed/scalar single precision uops allocated. |
| RESOURCE_STALLS.ANY | Resource-related stall cycles. |
| RESOURCE_STALLS.LB | Counts the cycles of stall due to lack of load buffers. |
| RESOURCE_STALLS.RS | Cycles stalled due to no eligible RS entry available. |
| RESOURCE_STALLS.SB | Cycles stalled due to no store buffers available. (not including draining form sync). |
| RESOURCE_STALLS.ROB | Cycles stalled due to re-order buffer full. |
| RESOURCE_STALLS2.BOB_FULL | Cycles when Allocator is stalled if BOB is full and new branch needs it. |
| UOPS_ISSUED.ANY | This event counts the number of Uops issued by the front-end of the pipeilne to the back-end. |
| UOPS_ISSUED.STALL_CYCLES | Cycles when Resource Allocation Table (RAT) does not issue Uops to Reservation Station (RS) for the thread. |
| UOPS_ISSUED.CORE_STALL_CYCLES | Cycles when Resource Allocation Table (RAT) does not issue Uops to Reservation Station (RS) for all threads. |
| RS_EVENTS.EMPTY_CYCLES | Cycles when Reservation Station (RS) is empty for the thread. |
| CPL_CYCLES.RING0 | Unhalted core cycles when the thread is in ring 0. |
| CPL_CYCLES.RING0_TRANS | Number of intervals between processor halts while thread is in ring 0. |
| CPL_CYCLES.RING123 | Unhalted core cycles when thread is in rings 1, 2, or 3. |
| ROB_MISC_EVENTS.LBR_INSERTS | Count cases of saving new LBR. |
| MACHINE_CLEARS.MEMORY_ORDERING | This event counts the number of memory ordering Machine Clears detected. Memory Ordering Machine Clears can result from memory disambiguation, external snoops, or cross SMT-HW-thread snoop (stores) hitting load buffers. Machine clears can have a significant performance impact if they are happening frequently. |
| MACHINE_CLEARS.SMC | This event is incremented when self-modifying code (SMC) is detected, which causes a machine clear. Machine clears can have a significant performance impact if they are happening frequently. |
| MACHINE_CLEARS.MASKMOV | Maskmov false fault - counts number of time ucode passes through Maskmov flow due to instruction's mask being 0 while the flow was completed without raising a fault. |
| INST_RETIRED.ANY_P | Number of instructions retired. General Counter - architectural event. |
| UOPS_RETIRED.ALL | This event counts the number of micro-ops retired. |
| UOPS_RETIRED.RETIRE_SLOTS | This event counts the number of retirement slots used each cycle. There are potentially 4 slots that can be used each cycle - meaning, 4 micro-ops or 4 instructions could retire each cycle. This event is used in determining the 'Retiring' category of the Top-Down pipeline slots characterization. |
| UOPS_RETIRED.ALL_PS | This event counts the number of micro-ops retired. (Precise Event) |
| UOPS_RETIRED.STALL_CYCLES | Cycles without actually retired uops. |
| UOPS_RETIRED.TOTAL_CYCLES | Cycles with less than 10 actually retired uops. |
| UOPS_RETIRED.RETIRE_SLOTS_PS | This event counts the number of retirement slots used each cycle. There are potentially 4 slots that can be used each cycle - meaning, 4 micro-ops or 4 instructions could retire each cycle. This event is used in determining the 'Retiring' category of the Top-Down pipeline slots characterization. (Precise Event - PEBS) |
| BR_INST_RETIRED.CONDITIONAL | Conditional branch instructions retired. |
| BR_INST_RETIRED.NEAR_CALL | Direct and indirect near call instructions retired. |
| BR_INST_RETIRED.ALL_BRANCHES | All (macro) branch instructions retired. |
| BR_INST_RETIRED.NEAR_RETURN | Return instructions retired. |
| BR_INST_RETIRED.NOT_TAKEN | Not taken branch instructions retired. |
| BR_INST_RETIRED.NEAR_TAKEN | Taken branch instructions retired. |
| BR_INST_RETIRED.FAR_BRANCH | Far branch instructions retired. |
| BR_INST_RETIRED.CONDITIONAL_PS | Conditional branch instructions retired. (Precise Event - PEBS). |
| BR_INST_RETIRED.NEAR_CALL_PS | Direct and indirect near call instructions retired. (Precise Event - PEBS). |
| BR_INST_RETIRED.ALL_BRANCHES_PS | All (macro) branch instructions retired. (Precise Event - PEBS). |
| BR_INST_RETIRED.NEAR_RETURN_PS | Return instructions retired. (Precise Event - PEBS). |
| BR_INST_RETIRED.NEAR_TAKEN_PS | Taken branch instructions retired. (Precise Event - PEBS). |
| BR_MISP_RETIRED.CONDITIONAL | Mispredicted conditional branch instructions retired. |
| BR_MISP_RETIRED.NEAR_CALL | Direct and indirect mispredicted near call instructions retired. |
| BR_MISP_RETIRED.ALL_BRANCHES | All mispredicted macro branch instructions retired. |
| BR_MISP_RETIRED.NOT_TAKEN | Mispredicted not taken branch instructions retired. |
| BR_MISP_RETIRED.TAKEN | Mispredicted taken branch instructions retired. |
| BR_MISP_RETIRED.CONDITIONAL_PS | Mispredicted conditional branch instructions retired. (Precise Event - PEBS). |
| BR_MISP_RETIRED.NEAR_CALL_PS | Direct and indirect mispredicted near call instructions retired. (Precise Event - PEBS). |
| BR_MISP_RETIRED.ALL_BRANCHES_PS | Mispredicted macro branch instructions retired. (Precise Event - PEBS) |
| BR_MISP_RETIRED.NOT_TAKEN_PS | Mispredicted not taken branch instructions retired.(Precise Event - PEBS). |
| BR_MISP_RETIRED.TAKEN_PS | Mispredicted taken branch instructions retired. (Precise Event - PEBS). |
| OTHER_ASSISTS.ITLB_MISS_RETIRED | Retired instructions experiencing ITLB misses. |
| OTHER_ASSISTS.AVX_STORE | Number of GSSE memory assist for stores. GSSE microcode assist is being invoked whenever the hardware is unable to properly handle GSSE-256b operations. |
| OTHER_ASSISTS.AVX_TO_SSE | Number of transitions from AVX-256 to legacy SSE when penalty applicable. |
| OTHER_ASSISTS.SSE_TO_AVX | Number of transitions from SSE to AVX-256 when penalty applicable. |
| FP_ASSIST.X87_OUTPUT | Number of X87 assists due to output value. |
| FP_ASSIST.X87_INPUT | Number of X87 assists due to input value. |
| FP_ASSIST.SIMD_OUTPUT | Number of SIMD FP assists due to Output values. |
| FP_ASSIST.SIMD_INPUT | Number of SIMD FP assists due to input values. |
| MEM_TRANS_RETIRED.LOAD_LATENCY_GT_4 | Randomly selected loads with latency value being above 4 . |
| MEM_TRANS_RETIRED.LOAD_LATENCY_GT_8 | Randomly selected loads with latency value being above 8. |
| MEM_TRANS_RETIRED.LOAD_LATENCY_GT_16 | Randomly selected loads with latency value being above 16. |
| MEM_TRANS_RETIRED.LOAD_LATENCY_GT_32 | Randomly selected loads with latency value being above 32. |
| MEM_TRANS_RETIRED.LOAD_LATENCY_GT_64 | Randomly selected loads with latency value being above 64. |
| MEM_TRANS_RETIRED.LOAD_LATENCY_GT_128 | Randomly selected loads with latency value being above 128. |
| MEM_TRANS_RETIRED.LOAD_LATENCY_GT_256 | Randomly selected loads with latency value being above 256. |
| MEM_TRANS_RETIRED.LOAD_LATENCY_GT_512 | Randomly selected loads with latency value being above 512. |
| MEM_TRANS_RETIRED.PRECISE_STORE | Sample stores and collect precise store operation via PEBS record. PMC3 only. (Precise Event - PEBS). |
| MEM_UOPS_RETIRED.STLB_MISS_LOADS | Retired load uops that miss the STLB. |
| MEM_UOPS_RETIRED.STLB_MISS_STORES | Retired store uops that miss the STLB. |
| MEM_UOPS_RETIRED.LOCK_LOADS | Retired load uops with locked access. |
| MEM_UOPS_RETIRED.SPLIT_LOADS | This event counts line-splitted load uops retired to the architected path. A line split is across 64B cache-line which includes a page split (4K). |
| MEM_UOPS_RETIRED.SPLIT_STORES | This event counts line-splitted store uops retired to the architected path. A line split is across 64B cache-line which includes a page split (4K). |
| MEM_UOPS_RETIRED.ALL_LOADS | This event counts the number of load uops retired |
| MEM_UOPS_RETIRED.ALL_STORES | This event counts the number of store uops retired. |
| MEM_UOPS_RETIRED.STLB_MISS_LOADS_PS | Retired load uops that miss the STLB. (Precise Event - PEBS). |
| MEM_UOPS_RETIRED.STLB_MISS_STORES_PS | Retired store uops that miss the STLB. (Precise Event - PEBS). |
| MEM_UOPS_RETIRED.LOCK_LOADS_PS | Retired load uops with locked access. (Precise Event - PEBS). |
| MEM_UOPS_RETIRED.SPLIT_LOADS_PS | This event counts line-splitted load uops retired to the architected path. A line split is across 64B cache-line which includes a page split (4K). (Precise Event - PEBS) |
| MEM_UOPS_RETIRED.SPLIT_STORES_PS | This event counts line-splitted store uops retired to the architected path. A line split is across 64B cache-line which includes a page split (4K). (Precise Event - PEBS) |
| MEM_UOPS_RETIRED.ALL_LOADS_PS | This event counts the number of load uops retired (Precise Event) |
| MEM_UOPS_RETIRED.ALL_STORES_PS | This event counts the number of store uops retired. (Precise Event - PEBS) |
| MEM_LOAD_UOPS_RETIRED.L1_HIT | Retired load uops with L1 cache hits as data sources. |
| MEM_LOAD_UOPS_RETIRED.L2_HIT | Retired load uops with L2 cache hits as data sources. |
| MEM_LOAD_UOPS_RETIRED.LLC_HIT | This event counts retired load uops that hit in the last-level (L3) cache without snoops required. |
| MEM_LOAD_UOPS_RETIRED.HIT_LFB | Retired load uops which data sources were load uops missed L1 but hit FB due to preceding miss to the same cache line with data not ready. |
| MEM_LOAD_UOPS_RETIRED.L1_HIT_PS | Retired load uops with L1 cache hits as data sources. (Precise Event - PEBS). |
| MEM_LOAD_UOPS_RETIRED.L2_HIT_PS | Retired load uops with L2 cache hits as data sources. (Precise Event - PEBS). |
| MEM_LOAD_UOPS_RETIRED.LLC_HIT_PS | This event counts retired load uops that hit in the last-level (L3) cache without snoops required. (Precise Event - PEBS) |
| MEM_LOAD_UOPS_RETIRED.HIT_LFB_PS | Retired load uops which data sources were load uops missed L1 but hit FB due to preceding miss to the same cache line with data not ready. (Precise Event - PEBS). |
| MEM_LOAD_UOPS_LLC_HIT_RETIRED.XSNP_MISS | Retired load uops which data sources were LLC hit and cross-core snoop missed in on-pkg core cache. |
| MEM_LOAD_UOPS_LLC_HIT_RETIRED.XSNP_HIT | This event counts retired load uops that hit in the last-level cache (L3) and were found in a non-modified state in a neighboring core's private cache (same package). Since the last level cache is inclusive, hits to the L3 may require snooping the private L2 caches of any cores on the same socket that have the line. In this case, a snoop was required, and another L2 had the line in a non-modified state. |
| MEM_LOAD_UOPS_LLC_HIT_RETIRED.XSNP_HITM | This event counts retired load uops that hit in the last-level cache (L3) and were found in a non-modified state in a neighboring core's private cache (same package). Since the last level cache is inclusive, hits to the L3 may require snooping the private L2 caches of any cores on the same socket that have the line. In this case, a snoop was required, and another L2 had the line in a modified state, so the line had to be invalidated in that L2 cache and transferred to the requesting L2. |
| MEM_LOAD_UOPS_LLC_HIT_RETIRED.XSNP_NONE | Retired load uops which data sources were hits in LLC without snoops required. |
| MEM_LOAD_UOPS_LLC_HIT_RETIRED.XSNP_MISS_PS | Retired load uops which data sources were LLC hit and cross-core snoop missed in on-pkg core cache. (Precise Event - PEBS). |
| MEM_LOAD_UOPS_LLC_HIT_RETIRED.XSNP_HIT_PS | This event counts retired load uops that hit in the last-level cache (L3) and were found in a non-modified state in a neighboring core's private cache (same package). Since the last level cache is inclusive, hits to the L3 may require snooping the private L2 caches of any cores on the same socket that have the line. In this case, a snoop was required, and another L2 had the line in a non-modified state. (Precise Event - PEBS) |
| MEM_LOAD_UOPS_LLC_HIT_RETIRED.XSNP_HITM_PS | This event counts retired load uops that hit in the last-level cache (L3) and were found in a non-modified state in a neighboring core's private cache (same package). Since the last level cache is inclusive, hits to the L3 may require snooping the private L2 caches of any cores on the same socket that have the line. In this case, a snoop was required, and another L2 had the line in a modified state, so the line had to be invalidated in that L2 cache and transferred to the requesting L2. (Precise Event - PEBS) |
| MEM_LOAD_UOPS_LLC_HIT_RETIRED.XSNP_NONE_PS | Retired load uops which data sources were hits in LLC without snoops required. (Precise Event - PEBS). |
| MEM_LOAD_UOPS_MISC_RETIRED.LLC_MISS | This event counts retired demand loads that missed the last-level (L3) cache. This means that the load is usually satisfied from memory in a client system or possibly from the remote socket in a server. Demand loads are non speculative load uops. |
| MEM_LOAD_UOPS_MISC_RETIRED.LLC_MISS_PS | This event counts retired demand loads that missed the last-level (L3) cache. This means that the load is usually satisfied from memory in a client system or possibly from the remote socket in a server. Demand loads are non speculative load uops. (Precise Event - PEBS) |
| ARITH.FPU_DIV_ACTIVE | Cycles when divider is busy executing divide operations. |
| ARITH.FPU_DIV | This event counts the number of the divide operations executed. |
| FP_COMP_OPS_EXE.X87 | Number of FP Computational Uops Executed this cycle. The number of FADD, FSUB, FCOM, FMULs, integer MULsand IMULs, FDIVs, FPREMs, FSQRTS, integer DIVs, and IDIVs. This event does not distinguish an FADD used in the middle of a transcendental flow from a s. |
| FP_COMP_OPS_EXE.SSE_PACKED_DOUBLE | Number of SSE* or AVX-128 FP Computational packed double-precision uops issued this cycle. |
| FP_COMP_OPS_EXE.SSE_SCALAR_SINGLE | Number of SSE* or AVX-128 FP Computational scalar single-precision uops issued this cycle. |
| FP_COMP_OPS_EXE.SSE_PACKED_SINGLE | Number of SSE* or AVX-128 FP Computational packed single-precision uops issued this cycle. |
| FP_COMP_OPS_EXE.SSE_SCALAR_DOUBLE | Number of SSE* or AVX-128 FP Computational scalar double-precision uops issued this cycle. |
| SIMD_FP_256.PACKED_SINGLE | Number of GSSE-256 Computational FP single precision uops issued this cycle. |
| SIMD_FP_256.PACKED_DOUBLE | Number of AVX-256 Computational FP double precision uops issued this cycle. |
| UOPS_DISPATCHED.THREAD | Uops dispatched per thread. |
| UOPS_DISPATCHED.STALL_CYCLES | Cases of no uops dispatched per thread. |
| UOPS_DISPATCHED.CORE | Uops dispatched from any thread. |
| UOPS_DISPATCHED_PORT.PORT_0 | Cycles per thread when uops are dispatched to port 0. |
| UOPS_DISPATCHED_PORT.PORT_1 | Cycles per thread when uops are dispatched to port 1. |
| UOPS_DISPATCHED_PORT.PORT_4 | Cycles per thread when uops are dispatched to port 4. |
| UOPS_DISPATCHED_PORT.PORT_5 | Cycles per thread when uops are dispatched to port 5. |
| CYCLE_ACTIVITY.CYCLES_NO_DISPATCH | Each cycle there was no dispatch for this thread, increment by 1. Note this is connect to Umask 2. No dispatch can be deduced from the UOPS_EXECUTED event. |
| CYCLE_ACTIVITY.CYCLES_L1D_PENDING | Each cycle there was a miss-pending demand load this thread, increment by 1. Note this is in DCU and connected to Umask 1.  Note this is in MLC and connected to Umask 0. |
| CYCLE_ACTIVITY.STALLS_L1D_PENDING | Each cycle there was a miss-pending demand load this thread and no uops dispatched, increment by 1. Note this is in DCU and connected to Umask 1 and 2. Miss Pending demand load should be deduced by OR-ing increment bits of DCACHE_MISS_PEND.PENDING. |
| CYCLE_ACTIVITY.STALLS_L2_PENDING | Each cycle there was a MLC-miss pending demand load and no uops dispatched on this thread (i.e. Non-completed valid SQ entry allocated for demand load and waiting for Uncore), increment by 1. Note this is in MLC and connected to Umask 0 and 2. |
| EPT.WALK_CYCLES | Cycle count for an Extended Page table walk. The Extended Page Directory cache is used by Virtual Machine operating systems while the guest operating systems use the standard TLB caches. |
| ITLB_MISSES.MISS_CAUSES_A_WALK | Misses at all ITLB levels that cause page walks. |
| ITLB_MISSES.WALK_COMPLETED | Misses in all ITLB levels that cause completed page walks. |
| ITLB_MISSES.WALK_DURATION | This event count cycles when Page Miss Handler (PMH) is servicing page walks caused by ITLB misses. |
| ITLB_MISSES.STLB_HIT | Operations that miss the first ITLB level but hit the second and do not cause any page walks. |
| DTLB_LOAD_MISSES.MISS_CAUSES_A_WALK | Load misses in all DTLB levels that cause page walks. |
| DTLB_LOAD_MISSES.WALK_COMPLETED | Load misses at all DTLB levels that cause completed page walks. |
| DTLB_LOAD_MISSES.WALK_DURATION | This event counts cycles when the page miss handler (PMH) is servicing page walks caused by DTLB load misses. |
| DTLB_LOAD_MISSES.STLB_HIT | This event counts load operations that miss the first DTLB level but hit the second and do not cause any page walks. The penalty in this case is approximately 7 cycles. |
| DTLB_STORE_MISSES.MISS_CAUSES_A_WALK | Store misses in all DTLB levels that cause page walks. |
| DTLB_STORE_MISSES.WALK_COMPLETED | Store misses in all DTLB levels that cause completed page walks. |
| DTLB_STORE_MISSES.WALK_DURATION | Cycles when PMH is busy with page walks. |
| DTLB_STORE_MISSES.STLB_HIT | Store operations that miss the first TLB level but hit the second and do not cause page walks. |
| TLB_FLUSH.DTLB_THREAD | DTLB flush attempts of the thread-specific entries. |
| TLB_FLUSH.STLB_ANY | STLB flush attempts. |
| PAGE_WALKS.LLC_MISS | Number of any page walk that had a miss in LLC. Does not necessary cause a SUSPEND. |
| L1D.REPLACEMENT | This event counts L1D data line replacements. Replacements occur when a new line is brought into the cache, causing eviction of a line loaded earlier. |
| L1D.ALLOCATED_IN_M | Allocated L1D data cache lines in M state. |
| L1D.EVICTION | L1D data cache lines in M state evicted due to replacement. |
| L1D.ALL_M_REPLACEMENT | Cache lines in M state evicted out of L1D due to Snoop HitM or dirty line replacement. |
| L1D_PEND_MISS.PENDING | L1D miss oustandings duration in cycles. |
| L1D_PEND_MISS.PENDING_CYCLES | Cycles with L1D load Misses outstanding. |
| LOAD_HIT_PRE.SW_PF | Not software-prefetch load dispatches that hit FB allocated for software prefetch. |
| LOAD_HIT_PRE.HW_PF | Not software-prefetch load dispatches that hit FB allocated for hardware prefetch. |
| HW_PRE_REQ.DL1_MISS | Hardware Prefetch requests that miss the L1D cache. This accounts for both L1 streamer and IP-based (IPP) HW prefetchers. A request is being counted each time it access the cache & miss it, including if a block is applicable or if hit the Fill Buffer for . |
| LOCK_CYCLES.SPLIT_LOCK_UC_LOCK_DURATION | Cycles when L1 and L2 are locked due to UC or split lock. |
| LOCK_CYCLES.CACHE_LOCK_DURATION | Cycles when L1D is locked. |
| LD_BLOCKS.DATA_UNKNOWN | Loads delayed due to SB blocks, preceding store operations with known addresses but unknown data. |
| LD_BLOCKS.STORE_FORWARD | This event counts loads that followed a store to the same address, where the data could not be forwarded inside the pipeline from the store to the load. The most common reason why store forwarding would be blocked is when a load's address range overlaps with a preceeding smaller uncompleted store. See the table of not supported store forwards in the Intel® 64 and IA-32 Architectures Optimization Reference Manual. The penalty for blocked store forwarding is that the load must wait for the store to complete before it can be issued. |
| LD_BLOCKS.NO_SR | This event counts the number of times that split load operations are temporarily blocked because all resources for handling the split accesses are in use. |
| LD_BLOCKS.ALL_BLOCK | Number of cases where any load ends up with a valid block-code written to the load buffer (including blocks due to Memory Order Buffer (MOB), Data Cache Unit (DCU), TLB, but load has no DCU miss). |
| LD_BLOCKS_PARTIAL.ADDRESS_ALIAS | Aliasing occurs when a load is issued after a store and their memory addresses are offset by 4K. This event counts the number of loads that aliased with a preceding store, resulting in an extended address check in the pipeline. The enhanced address check typically has a performance penalty of 5 cycles. |
| LD_BLOCKS_PARTIAL.ALL_STA_BLOCK | This event counts the number of times that load operations are temporarily blocked because of older stores, with addresses that are not yet known. A load operation may incur more than one block of this type. |
| MISALIGN_MEM_REF.LOADS | Speculative cache line split load uops dispatched to L1 cache. |
| MISALIGN_MEM_REF.STORES | Speculative cache line split STA uops dispatched to L1 cache. |
| AGU_BYPASS_CANCEL.COUNT | This event counts executed load operations with all the following traits: 1. addressing of the format [base + offset], 2. the offset is between 1 and 2047, 3. the address specified in the base register is in one page and the address [base+offset] is in an. |
| OFFCORE_REQUESTS_OUTSTANDING.DEMAND_DATA_RD | Offcore outstanding Demand Data Read transactions in uncore queue. |
| OFFCORE_REQUESTS_OUTSTANDING.CYCLES_WITH_DEMAND_DATA_RD | Cycles when offcore outstanding Demand Data Read transactions are present in SuperQueue (SQ), queue to uncore. |
| OFFCORE_REQUESTS_OUTSTANDING.DEMAND_RFO | Offcore outstanding RFO store transactions in SuperQueue (SQ), queue to uncore. |
| OFFCORE_REQUESTS_OUTSTANDING.ALL_DATA_RD | Offcore outstanding cacheable Core Data Read transactions in SuperQueue (SQ), queue to uncore. |
| OFFCORE_REQUESTS_OUTSTANDING.CYCLES_WITH_DATA_RD | Cycles when offcore outstanding cacheable Core Data Read transactions are present in SuperQueue (SQ), queue to uncore. |
| OFFCORE_REQUESTS.DEMAND_DATA_RD | Demand Data Read requests sent to uncore. |
| OFFCORE_REQUESTS.DEMAND_CODE_RD | Cacheable and noncachaeble code read requests. |
| OFFCORE_REQUESTS.DEMAND_RFO | Demand RFO requests including regular RFOs, locks, ItoM. |
| OFFCORE_REQUESTS.ALL_DATA_RD | Demand and prefetch data reads. |
| OFFCORE_REQUESTS_BUFFER.SQ_FULL | Cases when offcore requests buffer cannot take more entries for core. |
| L2_RQSTS.DEMAND_DATA_RD_HIT | Demand Data Read requests that hit L2 cache. |
| L2_RQSTS.RFO_HIT | RFO requests that hit L2 cache. |
| L2_RQSTS.RFO_MISS | RFO requests that miss L2 cache. |
| L2_RQSTS.CODE_RD_HIT | L2 cache hits when fetching instructions, code reads. |
| L2_RQSTS.CODE_RD_MISS | L2 cache misses when fetching instructions. |
| L2_RQSTS.PF_HIT | Requests from the L2 hardware prefetchers that hit L2 cache. |
| L2_RQSTS.PF_MISS | Requests from the L2 hardware prefetchers that miss L2 cache. |
| L2_STORE_LOCK_RQSTS.MISS | RFOs that miss cache lines. |
| L2_STORE_LOCK_RQSTS.HIT_E | RFOs that hit cache lines in E state. |
| L2_STORE_LOCK_RQSTS.HIT_M | RFOs that hit cache lines in M state. |
| L2_STORE_LOCK_RQSTS.ALL | RFOs that access cache lines in any state. |
| L2_L1D_WB_RQSTS.MISS | Count the number of modified Lines evicted from L1 and missed L2. (Non-rejected WBs from the DCU.). |
| L2_L1D_WB_RQSTS.HIT_S | Not rejected writebacks from L1D to L2 cache lines in S state. |
| L2_L1D_WB_RQSTS.HIT_E | Not rejected writebacks from L1D to L2 cache lines in E state. |
| L2_L1D_WB_RQSTS.HIT_M | Not rejected writebacks from L1D to L2 cache lines in M state. |
| L2_L1D_WB_RQSTS.ALL | Not rejected writebacks from L1D to L2 cache lines in any state. |
| L2_TRANS.DEMAND_DATA_RD | Demand Data Read requests that access L2 cache. |
| L2_TRANS.RFO | RFO requests that access L2 cache. |
| L2_TRANS.CODE_RD | L2 cache accesses when fetching instructions. |
| L2_TRANS.ALL_PF | L2 or LLC HW prefetches that access L2 cache. |
| L2_TRANS.L1D_WB | L1D writebacks that access L2 cache. |
| L2_TRANS.L2_FILL | L2 fill requests that access L2 cache. |
| L2_TRANS.L2_WB | L2 writebacks that access L2 cache. |
| L2_TRANS.ALL_REQUESTS | Transactions accessing L2 pipe. |
| L2_LINES_IN.I | L2 cache lines in I state filling L2. |
| L2_LINES_IN.S | L2 cache lines in S state filling L2. |
| L2_LINES_IN.E | L2 cache lines in E state filling L2. |
| L2_LINES_IN.ALL | This event counts the number of L2 cache lines brought into the L2 cache. Lines are filled into the L2 cache when there was an L2 miss. |
| L2_LINES_OUT.DEMAND_CLEAN | Clean L2 cache lines evicted by demand. |
| L2_LINES_OUT.DEMAND_DIRTY | Dirty L2 cache lines evicted by demand. |
| L2_LINES_OUT.PF_CLEAN | Clean L2 cache lines evicted by L2 prefetch. |
| L2_LINES_OUT.PF_DIRTY | Dirty L2 cache lines evicted by L2 prefetch. |
| L2_LINES_OUT.DIRTY_ALL | Dirty L2 cache lines filling the L2. |
| LONGEST_LAT_CACHE.MISS | Core-originated cacheable demand requests missed LLC. |
| LONGEST_LAT_CACHE.REFERENCE | Core-originated cacheable demand requests that refer to LLC. |
| SQ_MISC.SPLIT_LOCK | Split locks in SQ. |
| CPU_CLK_THREAD_UNHALTED.REF_XCLK | Reference cycles when the thread is unhalted (counts at 100 MHz rate). |
| CPU_CLK_THREAD_UNHALTED.ONE_THREAD_ACTIVE | Count XClk pulses when this thread is unhalted and the other is halted. |
| BR_INST_RETIRED.NEAR_CALL_R3 | Direct and indirect macro near call instructions retired (captured in ring 3). |
| BR_INST_RETIRED.NEAR_CALL_R3_PS | Direct and indirect macro near call instructions retired (captured in ring 3). (Precise Event - PEBS). |
| UOPS_DISPATCHED_PORT.PORT_0_CORE | Cycles per core when uops are dispatched to port 0. |
| UOPS_DISPATCHED_PORT.PORT_1_CORE | Cycles per core when uops are dispatched to port 1. |
| UOPS_DISPATCHED_PORT.PORT_4_CORE | Cycles per core when uops are dispatched to port 4. |
| UOPS_DISPATCHED_PORT.PORT_5_CORE | Cycles per core when uops are dispatched to port 5. |
| IDQ.MITE_CYCLES | Cycles when uops are being delivered to Instruction Decode Queue (IDQ) from MITE path. |
| IDQ.DSB_CYCLES | Cycles when uops are being delivered to Instruction Decode Queue (IDQ) from Decode Stream Buffer (DSB) path. |
| UOPS_DISPATCHED_PORT.PORT_2 | Cycles per thread when load or STA uops are dispatched to port 2. |
| UOPS_DISPATCHED_PORT.PORT_3 | Cycles per thread when load or STA uops are dispatched to port 3. |
| IDQ.MS_DSB_CYCLES | Cycles when uops initiated by Decode Stream Buffer (DSB) are being delivered to Instruction Decode Queue (IDQ) while Microcode Sequenser (MS) is busy. |
| IDQ.MS_DSB_OCCUR | Deliveries to Instruction Decode Queue (IDQ) initiated by Decode Stream Buffer (DSB) while Microcode Sequenser (MS) is busy. |
| UOPS_DISPATCHED_PORT.PORT_2_CORE | Cycles per core when load or STA uops are dispatched to port 2. |
| UOPS_DISPATCHED_PORT.PORT_3_CORE | Cycles per core when load or STA uops are dispatched to port 3. |
| INST_RETIRED.PREC_DIST | Instructions retired. (Precise Event - PEBS). |
| L2_RQSTS.ALL_DEMAND_DATA_RD | Demand Data Read requests. |
| L2_RQSTS.ALL_RFO | RFO requests to L2 cache. |
| L2_RQSTS.ALL_CODE_RD | L2 code requests. |
| L2_RQSTS.ALL_PF | Requests from L2 hardware prefetchers. |
| L1D_BLOCKS.BANK_CONFLICT_CYCLES | Cycles when dispatched loads are cancelled due to L1D bank conflicts with other load ports. |
| RESOURCE_STALLS2.ALL_PRF_CONTROL | Resource stalls2 control structures full for physical registers. |
| IDQ_UOPS_NOT_DELIVERED.CYCLES_LE_2_UOP_DELIV.CORE | Cycles with less than 2 uops delivered by the front end. |
| IDQ_UOPS_NOT_DELIVERED.CYCLES_LE_3_UOP_DELIV.CORE | Cycles with less than 3 uops delivered by the front end. |
| RESOURCE_STALLS2.ALL_FL_EMPTY | Cycles with either free list is empty. |
| RESOURCE_STALLS.MEM_RS | Resource stalls due to memory buffers or Reservation Station (RS) being fully utilized. |
| RESOURCE_STALLS.OOO_RSRC | Resource stalls due to Rob being full, FCSW, MXCSR and OTHER. |
| RESOURCE_STALLS2.OOO_RSRC | Resource stalls out of order resources full. |
| RESOURCE_STALLS.LB_SB | Resource stalls due to load or store buffers all being in use. |
| INT_MISC.RECOVERY_CYCLES | Number of cycles waiting for the checkpoints in Resource Allocation Table (RAT) to be recovered after Nuke due to all other cases except JEClear (e.g. whenever a ucode assist is needed like SSE exception, memory disambiguation, etc...). |
| PARTIAL_RAT_STALLS.FLAGS_MERGE_UOP_CYCLES | This event counts the number of cycles spent executing performance-sensitive flags-merging uops. For example, shift CL (merge_arith_flags). For more details, See the Intel® 64 and IA-32 Architectures Optimization Reference Manual. |
| IDQ_UOPS_NOT_DELIVERED.CYCLES_GE_1_UOP_DELIV.CORE | Cycles when 1 or more uops were delivered to the by the front end. |
| INT_MISC.RECOVERY_STALLS_COUNT | Number of occurences waiting for the checkpoints in Resource Allocation Table (RAT) to be recovered after Nuke due to all other cases except JEClear (e.g. whenever a ucode assist is needed like SSE exception, memory disambiguation, etc...). |
| IDQ.ALL_DSB_CYCLES_4_UOPS | Cycles Decode Stream Buffer (DSB) is delivering 4 Uops. |
| IDQ.ALL_DSB_CYCLES_ANY_UOPS | Cycles Decode Stream Buffer (DSB) is delivering any Uop. |
| IDQ.ALL_MITE_CYCLES_4_UOPS | Cycles MITE is delivering 4 Uops. |
| IDQ.ALL_MITE_CYCLES_ANY_UOPS | Cycles MITE is delivering any Uop. |
| DSB_FILL.ALL_CANCEL | Cases of cancelling valid Decode Stream Buffer (DSB) fill not because of exceeding way limit. |
| FP_ASSIST.ANY | Cycles with any input/output SSE or FP assist. |
| BACLEARS.ANY | Counts the total number when the front end is resteered, mainly when the BPU cannot provide a correct prediction and this is corrected by other branch handling mechanisms at the front end. |
| OFFCORE_REQUESTS_OUTSTANDING.CYCLES_WITH_DEMAND_RFO | Offcore outstanding demand rfo reads transactions in SuperQueue (SQ), queue to uncore, every cycle. |
| IDQ_UOPS_NOT_DELIVERED.CYCLES_FE_WAS_OK | Counts cycles FE delivered 4 uops or Resource Allocation Table (RAT) was stalling FE. |
| BR_INST_EXEC.ALL_BRANCHES | Speculative and retired branches. |
| BR_MISP_EXEC.ALL_BRANCHES | Speculative and retired mispredicted macro conditional branches. |
| IDQ.MITE_ALL_UOPS | Uops delivered to Instruction Decode Queue (IDQ) from MITE path. |
| UOPS_RETIRED.CORE_STALL_CYCLES | Cycles without actually retired uops. |
| LSD.CYCLES_4_UOPS | Cycles 4 Uops delivered by the LSD, but didn't come from the decoder. |
| MACHINE_CLEARS.COUNT | Number of machine clears (nukes) of any type. |
| RS_EVENTS.EMPTY_END | Counts end of periods where the Reservation Station (RS) was empty. Could be useful to precisely locate Frontend Latency Bound issues. |
| IDQ.MS_SWITCHES | Number of switches from DSB (Decode Stream Buffer) or MITE (legacy decode pipeline) to the Microcode Sequencer. |
| CPU_CLK_UNHALTED.THREAD_ANY | Core cycles when at least one thread on the physical core is not in halt state. |
| CPU_CLK_UNHALTED.THREAD_P_ANY | Core cycles when at least one thread on the physical core is not in halt state. |
| CPU_CLK_THREAD_UNHALTED.REF_XCLK_ANY | Reference cycles when the at least one thread on the physical core is unhalted (counts at 100 MHz rate). |
| INT_MISC.RECOVERY_CYCLES_ANY | Core cycles the allocator was stalled due to recovery from earlier clear event for any thread running on the physical core (e.g. misprediction or memory nuke). |
| OFFCORE_REQUESTS_OUTSTANDING.DEMAND_DATA_RD_C6 | Cycles with at least 6 offcore outstanding Demand Data Read transactions in uncore queue. |
| UOPS_EXECUTED.CORE_CYCLES_GE_1 | Cycles at least 1 micro-op is executed from any thread on physical core. |
| UOPS_EXECUTED.CORE_CYCLES_GE_2 | Cycles at least 2 micro-op is executed from any thread on physical core. |
| UOPS_EXECUTED.CORE_CYCLES_GE_3 | Cycles at least 3 micro-op is executed from any thread on physical core. |
| UOPS_EXECUTED.CORE_CYCLES_GE_4 | Cycles at least 4 micro-op is executed from any thread on physical core. |
| UOPS_EXECUTED.CORE_CYCLES_NONE | Cycles with no micro-ops executed from any thread on physical core. |
| L1D_PEND_MISS.PENDING_CYCLES_ANY | Cycles with L1D load Misses outstanding from any thread on physical core. |
| L1D_PEND_MISS.FB_FULL | Cycles a demand request was blocked due to Fill Buffers inavailability. |
| CPU_CLK_UNHALTED.REF_XCLK | Reference cycles when the thread is unhalted (counts at 100 MHz rate) |
| CPU_CLK_UNHALTED.REF_XCLK_ANY | Reference cycles when the at least one thread on the physical core is unhalted (counts at 100 MHz rate). |
| CPU_CLK_UNHALTED.ONE_THREAD_ACTIVE | Count XClk pulses when this thread is unhalted and the other thread is halted. |
| UNC_ARB_TRK_OCCUPANCY.ALL | Counts cycles weighted by the number of requests waiting for data returning from the memory controller. Accounts for coherent and non-coherent requests initiated by IA cores, processor graphic units, or LLC. |
| UNC_ARB_TRK_REQUESTS.ALL | Counts the number of coherent and in-coherent requests initiated by IA cores, processor graphic units, or LLC. |
| UNC_ARB_TRK_REQUESTS.WRITES | Counts the number of allocated write entries, include full, partial, and LLC evictions. |
| UNC_ARB_TRK_REQUESTS.EVICTIONS | Counts the number of LLC evictions allocated. |
| UNC_ARB_COH_TRK_OCCUPANCY.ALL | Cycles weighted by number of requests pending in Coherency Tracker. |
| UNC_ARB_COH_TRK_REQUESTS.ALL | Number of requests allocated in Coherency Tracker. |
| UNC_ARB_TRK_OCCUPANCY.CYCLES_WITH_ANY_REQUEST | Cycles with at least one request outstanding is waiting for data return from memory controller. Account for coherent and non-coherent requests initiated by IA Cores, Processor Graphics Unit, or LLC. |
| UNC_ARB_TRK_OCCUPANCY.CYCLES_OVER_HALF_FULL | Cycles with at least half of the requests outstanding are waiting for data return from memory controller. Account for coherent and non-coherent requests initiated by IA Cores, Processor Graphics Unit, or LLC. |
| UNC_CLOCK.SOCKET | This 48-bit fixed counter counts the UCLK cycles. |
| UNC_CBO_XSNP_RESPONSE.MISS_EXTERNAL | An external snoop misses in some processor core. |
| UNC_CBO_XSNP_RESPONSE.MISS_XCORE | A cross-core snoop initiated by this Cbox due to processor core memory request which misses in some processor core. |
| UNC_CBO_XSNP_RESPONSE.MISS_EVICTION | A cross-core snoop resulted from L3 Eviction which misses in some processor core. |
| UNC_CBO_XSNP_RESPONSE.HIT_EXTERNAL | An external snoop hits a non-modified line in some processor core. |
| UNC_CBO_XSNP_RESPONSE.HIT_XCORE | A cross-core snoop initiated by this Cbox due to processor core memory request which hits a non-modified line in some processor core. |
| UNC_CBO_XSNP_RESPONSE.HIT_EVICTION | A cross-core snoop resulted from L3 Eviction which hits a non-modified line in some processor core. |
| UNC_CBO_XSNP_RESPONSE.HITM_EXTERNAL | An external snoop hits a modified line in some processor core. |
| UNC_CBO_XSNP_RESPONSE.HITM_XCORE | A cross-core snoop initiated by this Cbox due to processor core memory request which hits a modified line in some processor core. |
| UNC_CBO_XSNP_RESPONSE.HITM_EVICTION | A cross-core snoop resulted from L3 Eviction which hits a modified line in some processor core. |
| UNC_CBO_CACHE_LOOKUP.READ_M | L3 Lookup read request that access cache and found line in M-state. |
| UNC_CBO_CACHE_LOOKUP.WRITE_M | L3 Lookup write request that access cache and found line in M-state. |
| UNC_CBO_CACHE_LOOKUP.EXTSNP_M | L3 Lookup external snoop request that access cache and found line in M-state. |
| UNC_CBO_CACHE_LOOKUP.ANY_M | L3 Lookup any request that access cache and found line in M-state. |
| UNC_CBO_CACHE_LOOKUP.READ_I | L3 Lookup read request that access cache and found line in I-state. |
| UNC_CBO_CACHE_LOOKUP.WRITE_I | L3 Lookup write request that access cache and found line in I-state. |
| UNC_CBO_CACHE_LOOKUP.EXTSNP_I | L3 Lookup external snoop request that access cache and found line in I-state. |
| UNC_CBO_CACHE_LOOKUP.ANY_I | L3 Lookup any request that access cache and found line in I-state. |
| UNC_CBO_CACHE_LOOKUP.READ_MESI | L3 Lookup read request that access cache and found line in any MESI-state. |
| UNC_CBO_CACHE_LOOKUP.WRITE_MESI | L3 Lookup write request that access cache and found line in MESI-state. |
| UNC_CBO_CACHE_LOOKUP.EXTSNP_MESI | L3 Lookup external snoop request that access cache and found line in MESI-state. |
| UNC_CBO_CACHE_LOOKUP.ANY_MESI | L3 Lookup any request that access cache and found line in MESI-state. |
| UNC_CBO_CACHE_LOOKUP.ANY_ES | L3 Lookup any request that access cache and found line in E or S-state. |
| UNC_CBO_CACHE_LOOKUP.EXTSNP_ES | L3 Lookup external snoop request that access cache and found line in E or S-state. |
| UNC_CBO_CACHE_LOOKUP.READ_ES | L3 Lookup read request that access cache and found line in E or S-state. |
| UNC_CBO_CACHE_LOOKUP.WRITE_ES | L3 Lookup write request that access cache and found line in E or S-state. |


Our Civil engineers conceive, design, build, supervise, operate, construct and maintain infrastructure projects and systems , including roads, buildings, airports, tunnels, dams, bridges, and systems for water supply and sewage treatment.
Our team of architects and designers also make it a priority to stay up-to-date with new architectural breakthroughs in the architectural world. our staff is equipped with the very latest architectural methods and design options available.
If you are planning to design or just need some advice from qualified architects give us a call today. We will be happy to offer you more architectural information, so you can get your architectural project completed in
no time.
We are confident that our customers know best when it comes to their own environment ,our company also offering the best architecture and design services available but we also want our client’s to be informed every step of the way.
I am from Egypt.I am a civil engineer working in construction company. I have been working in the engineering field for several years, and during that time I have been a part of multiple projects, including ones that focused on the maintenance of several roads and the design of Cloud Clearwater Bridge. I am particularly detail oriented.
I am from Egypt.I am a civil engineer working in construction company. I have been working in the engineering field for several years, and during that time I have been a part of multiple projects, including ones that focused on the maintenance of several roads and the design of Cloud Clearwater Bridge. I am particularly detail oriented.


test compiled and minified CSS -->
He took his vorpal sword in hand: Long time the manxome foe he sought— So rested he by the Tumtum tree, And stood awhile in thought.
Run the animated typing!


I was a severe opiate user for about 2 years. My use included oxycodone, morphine, heroin, hydrocodone, hydromorphone, and every other opiate available. I was severe addict. My main drug of choice was heroin, either smoked or water-line snorted. I used everyday during this period of time. I recently decided to go to a bupe doctor and dry to cure myself of my disease.
My withdrawals were getting out of control (i.e. vomiting, insomnia, severe sweating and shivering, etc) It came to the point where I was contemplating suicide on a regular basis. All I can say about bupe is that it saved my life in many ways. This is by far the most important drug of my entire life. Unlike methadone, bupe will rarely produce any euphoric effects. However it completely kills any withdrawls and even cravings. When I'm on suboxone I have no craving for heroin whatsoever, I don't even think about it. The most important effect it had on me besides everything else was it's anti-depressant effects. It has completely eliminated my depression.
Bupe has saved my life in so many ways and I am thankful that I have health insurance to pay its incredible cost. A prescription will cost about 5 dollars a pill plus about 20 to fill it. This is expensive shit!
Experience Reports are the writings and opinions of the individual authors who submit them.
Some of the activities described are dangerous and/or illegal and none are recommended by Erowid.


Let's begin here, this class is not a programming class. The purpose of this class is not to teach you to be a master programmer. We are merely using programming as a way to teach problem solving and logic. That is what the essence of what programming is: problem solving and logic.
Tranquility is a language we created for this class where syntax, built-in functions, and IDEs are not the focus. Our focus is the process behind sequentially solving a problem. This is a language that is meant to be taught, not used in industry.
That being said, we try and keep Tranquility fairly internal. No Googling, no StackOverflow. Instead, we provide with you this ancient tomb, the Tranquility Programmers Manual. This artifact contains important information that can answer most, if not all of your Tranquility questions. Any other questions you have can be answered by your wise TAs and Professor.


NotifyCSV
NotifyCSV is a utility that uses the Mechanical Turk
API in Java to notify a number of workers in batch.
NotifyCSV is built on top of the Mechanical Turk sample package,
and uses the Apache ANT utility to both compile and execute
the java script.
File Setup
Before running the script, you must set up the csv input file and let
the script know the secret key for your Mechanical Turk account.
The testmsg.csv
file is included in
the samples
directory. The first line contains a
comma-separated list consisting of the message subject, the message
body, and the worker ID. Subsequent lines covntain only the next
worker ID to receive the same message.
This file sends the lorem ipsum greeting to the same worker three
times. Note that a message can only be sent to a worker ID that you
have interacted with in the past (e.g., by accepting a HIT). Notice
that quotation marks are needed for long messages with commas. You may use a
spreadsheet program such as excel to create your own csv file, and you
may save it anywhere on your hard drive.
The file mturk.properties
contains the relevant keys to
access your account. You can find your access keys by going to
aws.amazon.com, hovering your mouse over "Your Web Services Account"
in the top-right corner and selecting View Access Key Identifiers. Be
sure to log-in with the same username and password you registered with
your Mechanical Turk Requester account.
In the same file, choose the
appropriate service_url
for either the developer sandbox
(to test things) or the production side (if you are confident that
your system is correctly set-up).
Running
To run the script, open a terminal and navigate to the directory
containing the build.xml
file. Type ant
at
the command line, to verify that ant is installed:
This output demonstrates that ant is installed, and is referring to
the correct build.xml
file. To run the NotifyCSV
script, type ant notifycsv -Dnoitifycsv=[location]
Make sure you include the entire path to the file, e.g.:
As the script runs, it will echo back the information sent to the
Mechanical Turk servers.
Feedback
If you encounter any problems using this script, please contact<EMAIL_ADDRESS>Created 2011.12.13
by Alex Storer


Woman, children missing from Sunshine Coast
An urgent public appeal has been issued for help to find a woman who has disappeared with her two girls.
The 32-year-old woman and her two daughters, aged two and three, left a Maltman St address around 9am on Saturday.
The three have not been seen or heard of since and police have expressed concerns for their safety and wellbeing.
The woman is described as Caucasian, 170cm tall, proportionate build with dark hair and brown eyes.
The three-year-old girl is described as Caucasian, 110cm tall, slim build with blue eyes and long curly blonde hair.
The two-year-old girl is described as Caucasian, 80cm tall, slim build with brown eyes and short light brown curly hair.
Police believe the woman often visits the Caloundra, Kallangur and Caboolture areas.
Police urge anyone who has information regarding the whereabouts of the woman and the children to immediately contact police.


Table of Contents
Introduction to Information Extraction
-
- Information Extraction (IE):
- is the task of automatically extracting structured information from a (non/semi)-structured piece of text.
-
- Structured Representations of Inforamtion:
- Usually, the extracted information is represented as:
- Relations (in the DataBase sense)
- A Knowledge Base
-
- Goals:
-
- Organize information in a way that is useful to humans.
- Put information in a semantically precise form that allows further inference to be made by other computer algorithms.
-
- Common Applications:
-
- Gathering information (earning, profits, HQs, etc.) from reports
- Learning drug-gene product interactions from medical research literature
- Low-Level Information Extraction:
- Information about possible dates, schedules, activites gathered by companys (e.g. google, facebook)
-
- Tasks and Sub-tasks:
-
- Named entity extraction:
- Named Entity Recognition: recognition of known entity names (for people and organizations), place names, temporal expressions, and certain types of numerical expressions.
- Coreference Resolution: detection of coreference and anaphoric links between text entities.
- Relationship Extraction: identification of relations between entities.
- Semi-structured information extraction:
- Table Extraction: finding and extracting tables from documents.
- Comments extraction: extracting comments from actual content of article in order to restore the link between author of each sentence.
- Language and Vocabulary Analysis:
- Terminology extraction: finding the relevant terms for a given corpus.
- Named entity extraction:
-
- Methods:
- There are three standard approaches for tackling the problem of IE:
- Hand-written Regular Expressions: usually stacked.
- Classifiers:
- Generative:
- Naive Bayes Classifier
- Discriminative:
- MaxEnt Models (Multinomial Logistic Regr.)
- Generative:
- Sequence Models:
- Hidden Markov Models
- Conditional Markov model (CMM) / Maximum-entropy Markov model (MEMM)
- Conditional random fields (CRF)
Named Entity Recognition (NER)
-
- Named Entity Recognition:
- is the recognition of known entity names (for people and organizations), place names, temporal expressions, and certain types of numerical expressions;
this is usually done by employing existing knowledge of the domain or information extracted from other sentences.
-
- Applications:
-
- Named entities can be indexed, linked off, etc.
- Sentiment can be attributed to companies or products
- They define a lot of the IE relations, as associations between the named entities
- In QA, answers are often named entities
-
- Evaluation of NER Tasks:
- Evaluation is usually done at the level of Entities and not of Tokens.
- One common issue with the metrics defined for text classification, namely, (Precision/Recall/F1) is that they penalize the system based on a binary evaluation on how the system did; however, let’s demonstrate why that would be problamitic.
-
- Consider the following text:
“The First Bank of Chicago announced earnings…”
Let the italic part of the text be the enitity we want to recognize and let the bolded part of the text, be the entitiy that our model identified.
The (Precision/Recall/F1) metrics would penalize the model twice, once as a false-positive (for having picked an incorrect entitiy name), and again as a false-negative (for not having picked the actual entitiy name).
However, we notice that our system actually picked \(3/4\)ths of the actual entity name to be recognized. - This leads us seeking an evaluation metric that awards partial credit for this task.
- Consider the following text:
-
- The MUC Scorer is one, such, metric for giving partial credit.
- Albeit such complications and issues with the metrics described above, the field has, unfortunately, continued using the F1-Score as a metric for NER systems due to the complexity of formulating a metric that gives partial credit.
Sequence Models for Named Entity Recognition
-
- Approach:
-
- Training:
- Collect a set of representative training documents
- Label each token for its entity class or other (O)
- Design feature extractors appropriate to the text and classes
- Train a sequence classifier to predict the labels from the data
- Training:
-
- Testing:
- Receive a set of testing documents
- Run sequence model inference to label each token
- Appropriately output the recognized entities
- Testing:
-
- Encoding Classes for Sequence Labeling:
- There are two common ways to encode the classes:
- IO Encoding: this encoding will only encode only the entitiy of the token disregarding its order/position in the text (PER).
- For \(C\) classes, IO produces (\(C+1\) ) labels.
- IOB Encoding: this encoding is similar to IO encoding, however, it, also, keeps track to whether the token is the beginning of an entitiy-name (B-PER) or a continuation of such an entity-name (I-PER).
- For \(C\) classes, IO produces (\(2C+1\) ) labels.
- IO Encoding: this encoding will only encode only the entitiy of the token disregarding its order/position in the text (PER).
- The IO encoding, thus, is much lighter, and thus, allows the algorithm to run much faster than the IOB encoding.
Moreover, in practice, the issue presented for IO encoding rarely occurs and is only limited to instances where the entities that occur next to each other, are the same entity.
IOB encoded systems, also, tend to not learn quite as well due to the huge number of labels and are usually still prone to the same issues - Thus, due to the reasons mentioned above, the IO Encoding scheme is the one most commonly used.
-
- Features for Sequence Labeling:
-
- Words:
- Current word (like a learned dictionary)
- Previous/Next word (context)
- Other kinds of Inferred Linguistic Classification:
- Part-of-Speech Tags (POS-Tags)
- Label-Context:
- Previous (and perhaps next) label
This is usually what allows for sequence modeling
- Previous (and perhaps next) label
- Words:
- Other useful features:
- Word Substrings: usually there are substrings in words that are categorical in nature
- Examples:
“oxa” -> Drug
“(noun): (noun)” -> Movie
“(noun)-field” -> (usually) place
- Examples:
- Word Shapes: the idea is to map words to simplified representations that encode attributes such as:
length, capitalization, numerals, Greek-Letters, internal punctuation, etc.-
Example:
The representation below shows only the first two letters and the last two letters; for everything else, it will add the capitalization and the special characters, and for longer words, it will represent them in set notation.Varicella-zoster Xx-xxx mRNA xXXX CPA1 XXXd
-
- Word Substrings: usually there are substrings in words that are categorical in nature
Maximum Entropy Sequence Models
-
- Maximum-Entropy (Conditional) Markov Model:
- is a discriminative graphical model for sequence labeling that combines features of hidden Markov models (HMMs) and maximum entropy (MaxEnt) models.
- It is a discriminative model that extends a standard maximum entropy classifier by assuming that the unknown values to be learned are connected in a Markov chain rather than being conditionally independent of each other.
- It makes a single decision at a time, conditioned on evidence from observations and previous decisions.
-
A larger space of sequences is usually explored via search.
-
Inference:
-
- Exploring the Sequence Space (Search Methods):
-
- Beam Inference:
- Algorithm:
- At each position keep the top \(k\) complete sequences.
- Extend each sequence in each local way.
- The extensions compete for the \(k\) slots at the next position.
- Advantages:
- Fast. Beam sizes of 3-5 are almost as good as exact inference in many cases.
- Easy. Implementation does not require dynamic programming.
- Disadvantages:
- Inexact. The globally best sequence can fall off the beam.
- Algorithm:
- Beam Inference:
-
- Viterbi Inference:
- Algorithm:
- Dynamic Programming or Memoization.
- Requires small window of state influence (eg. past two states are relevant)
- Advantages:
- Exact. the global best sequence is returned.
- Disadvantages:
- Hard. Harder to implement long-distance state-state interactions.
- Algorithm:
- Viterbi Inference:
-
- Conditional Random Fields (CRFs):
- are a type of discriminative undirected probabilistic graphical model.
- They can take context into account; and are commonly used to encode known relationships between observations and construct consistent interpretations.


Introduction
Lauter is a lightweight grid system.
It's designed with the following tenets:
- Responsive
- Lightweight
- Easy to use
- Based on Flexbox
- All cells add up to 100% (or not)
- Support near-arbitrary column widths
- Support vertical alignment
Breakpoints
Lauter matches common responsive breakpoints.
- Mobile 0-543 PX
- Small 544-767 PX
- Medium 768-991 PX
- Large 992-1199 PX
- Extra 1200 PX+
Usage
A grid is composed of at least one Grid
and one Cell
.
Multiple Columns
Basic Example
You can support multiple columns using one Grid
element and two Cell
elements.
Fit Horizontally
To make Cell
elements fit horizontally, you can add one of the following: Fit-Mobile
Fit-Small
Fit-Medium
Fit-Large
Fit-Extra
on your Grid
.
You can add as many Cell
elements as you want, and if the Grid
is set to fit, they will all fit the full width until the break point is hit.
Above 768px, the cells below will fit next to each other. Below 768px they will stack on top of each other.
Add Padding
You can add padding to each Cell
by using Pad
.
Add Gutters
Horizontal Gutters
If you are fitting your cells, you can add a Gutter
between your Cell
elements.
Vertical Gutters
If Gutter
is used, each Grid
element will have a Gutter added to the bottom.
If you have Fit
the Grid
, bellow the fit breakpoint, the vertical gutter will be
placed on the Cell
. This will show a vertical gutter below the Large
viewport.
Cell Heights
Stretching
By default, a Cell
will stretch to the full height of the Grid
.
Vertical Aligning
You can place the contents of a Cell
in the middle using Align-Center
.
You can place the contents of a Cell
at the end using Align-Bottom
.
Cell Widths
Overview
Lauter does not mandate a 12 / 16 / 24 column grid. You can specify Cell
widths in 5% increments.
They can add up to 100%, or you can leave out widths to take up remaining space in the grid. You can also choose
to not fill the entire area of a grid as shown in the last example.
Basic example
You can declare sizes on a per-viewport basis. Below is a sample that sets the left column to 30% for medium and above viewports.
Widths are opt-in, you don't have to specify a width for all Cell
elements. In this case, the right column does not
have a width specified. It simply takes up the remainder of the available space.
Different widths for different devices example
You can declare sizes on a per-viewport basis. Below is a sample where the first Cell
takes up 50% on a small device, and 30% on a medium device.
Different widths that do not take up all available space
If you declare sizes on all Cell
elements, can choose to have them add up to 100% or only take up the desired amount of space.
Nesting
Basic example
Nesting should work as expected. This has not been tested thoroughly.
About
Lauter was built by Chris Millar in Salt Lake City, Utah. It is licensed under the Apache 2.0 license.


Trade Offers Received
Home
New Trade
View Trade Requests
View Unconfirmed Trades
{% for trade in pokes %}
Pokemon to be Received: {{trade.sent}}
Pokemon to be Sent : {{trade.rec}}
Trainer : {{trade.node}}
{% endfor %}


I want to be home and play vedio games all the summer. What a wonderful a idea!
print('Python is good!')
The concert starts at 20:00.
The concert took place on May 15.


<EMAIL_ADDRESS>Education
- Bachelor of Science: Appalachian State University, Boone, NC
- Major: Mathematics with concentration in Business
- May 2019
- Departmental Honors Student
- Chancellor’s List: Fall 2016, Spring 2017, Fall 2017, Spring 2018
- Junior Marshall: May 2018
Academic Research
Senior Honors Thesis August 2018 - Present
- Appalachian State University: Boone, NC
- Topic: Small Business Analysis
- Independent research
- Implement informational pivot charts/tables using excel
Undergraduate Research Intern May 2018 - July 2018
- North Carolina A&T State University: Greensboro, NC
- Team research in Data Science and Analytics
- Topic: Adaptive Contact Epidemiology
- Analyzed big data
- Self-motivated work environment
- Implemented graph network using Python
- Full time
Experience
Math Lab Tutor January 2018- Present
- University Tutor Services: Boone, NC
- Leadership role
- Assist students in various math courses
- Part time
Assistant Manager May 2017- Present
- Pleasantries Boutique, Home, and Wine Shoppe: Taylorsville, NC
- Calculate pricing for retail sales
- Provide exceptional customer service
- Analyze current sales
- Part time
Skills
- Experience in Python
- Experience in R Studio
- Proficiency in Microsoft Word and Excel
Clubs and Organizations
Pi Mu Epsilon- Math Honors Society
- September 2018- Present
- Member
Gamma Iota Sigma- Risk Management and Insurance Club
- August 2016-August 2017
- Member


Your role in {{ name }} has changedYou have been made an {{ role }} of {{ name }}. You were previously an {{ previousrole }}. Administrators are able to edit group's information and add or remove users. Editors are only able to edit the group's information. If you think this has been done in error, you will need to contact<EMAIL_ADDRESS>Thank you, Stockport Council |


Loading…
×
Session Expired. Please log in again to continue your work !
×
Are you sure you want to delete this source ?
×
Warning! This will delete all existing sources located in that category. Proceed ?
×
Source Name
Update
×
New Category Name
Create
×
Category Name
Update
×
Document
Website
Please upload a file(docx,doc,txt or pdf)
Go
URL:
Go
Toggle navigation
AnnotationPlus
Home
(current)
Help
Questions/Feedback
[[${userName}]]
Settings
Logout
Document
Website
INFO
! In order to add new sources you must create at least one category !
Existing Sources
Categories
Annotations


FindBugs FAQThis document contains answers to frequently asked questions about FindBugs. If you just want general information about FindBugs, have a look at the fact sheet and the manual. Contents
Q1: I'm getting java.lang.UnsupportedClassVersionError when I try to run FindBugsFindBugs requires JRE 1.7.0 or later to run. If you use an earlier version, you will see an exception error message similar to the following: Exception in thread "main" java.lang.UnsupportedClassVersionError: edu/umd/cs/findbugs/gui/FindBugsFrame (Unsupported major.minor version 51.0)The solution is to upgrade to JRE 1.7.0 or later. Q2: When I click the "Find Bugs!" button, I get a NoSuchMethodError or VerifyErrorThe symptom of this bug is that when you start the FindBugs analysis, you see an exception similar to the following: java.lang.NoSuchMethodError: org.apache.bcel.Repository.setRepository(Lorg/apache/bcel/util/Repository;)V at edu.umd.cs.findbugs.FindBugs.clearRepository(FindBugs.java:483) ...or java.lang.VerifyError: Cannot inherit from final class at java.lang.ClassLoader.defineClass0(Native Method) at java.lang.ClassLoader.defineClass(ClassLoader.java:537) ... The problem here is that the wrong version of the
Apache BCEL
library is being found. FindBugs requires its own
version of BCEL, which normally will be used automatically
when you invoke the
In all of these cases, you should be able to run FindBugs by either removing the offending version of BCEL from your JRE, or installing a clean JRE or JDK and using that to run FindBugs. Many thanks to Peter Meulmeester, Michael Levi, and Thomas Klaeger for providing information on this problem. Q3: FindBugs is running out of memory, or is taking a long time to finish In general, FindBugs requires lots of memory and a relatively
fast CPU. For large applications, 1024M or more of heap space may be
required. By default, FindBugs allocates 768M of heap space.
You can increase this using the Q4: What is the "auxiliary classpath"? Why should I specify it?Many important facts about a Java class require information about the classes that it references. For example:
The "auxiliary classpath" is a list of Jar files, directories, and class files containing classes that are used by the code you want FindBugs to analyze, but should not themselves be analyzed by FindBugs. If FindBugs doesn't have complete information about referenced classes, it will not be able to produce results that are as accurate as possible. For example, having a complete repository of referenced classes allows FindBugs to prune control flow information so it can concentrate on paths through methods that are most likely to be feasible at runtime. Also, some bug detectors (such as the suspicious reference comparison detector) rely on being able to perform type inference, which requires complete type hierarchy information. For these reasons, we strongly recommend that you completely specify
the auxiliary classpath when you run FindBugs. You can do this
by using the If FindBugs cannot find a class referenced by your application, it will print out a message when the analysis completes, specifying the classes that were missing. You should modify the auxiliary classpath to specify how to find the missing classes, and then run FindBugs again. Q5: The Eclipse plugin doesn't loadThe symptom of this problem is that Eclipse fails to load the FindBugs UI plugin with the message: Plug-in "edu.umd.cs.findbugs.plugin.eclipse" was disabled due to missing or disabled prerequisite plug-in "org.eclipse.ui.ide" The reason for this problem is that the Eclipse plugin distributed with FindBugs does not work with older 3.x versions of Eclipse. Please use Eclipse version 3.6 (June 2010) or newer. Q6: I'm getting a lot of false "OS" and "ODR" warnings By default, FindBugs assumes that any method invocation can
throw an unchecked runtime exception. As a result,
it may assume that an unchecked exception thrown out of the
method could bypass a call to a You can use the Q7: The Eclipse plugin loads, but doesn't work correctlyMake sure the Java code you trying to analyze is built properly and has no classpath or compile errors. Make sure the project and workspace FindBugs settings are valid - in doubt, revert them to defaults. Make sure the Error log view does not show errors. Q8: Where is the Maven plugin for FindBugs?The Maven Plugin for FindBugs may be found here. Please note that the Maven plugin is not maintained by the FindBugs developers, so we can't answer questions about it. Q9: Where is the NetBeans plugin for FindBugs?We recommend SQE: Software Quality Environment which bundles FindBugs, PMD and CheckStyle. Use the following update site: http://deadlock.netbeans.org/hudson/job/sqe/lastStableBuild/artifact/build/full-sqe-updatecenter/updates.xml Pease note that the SQE plugin is not maintained by the FindBugs developers, so we can't answer questions about it.
Send comments to<EMAIL_ADDRESS>|


Static Functions Declared in Header Files
Header files are meant to be shared. Static declarations, however, are not shared. It is unusual to combine the two, and it may be of interest to find all the symbols declared static in included files. In the next example, the included_files variable previously set are used.
set declares [get_declares $included_files]
1 (var) glob_var1
2 (var) glob_var2
3 (funct) DB_e
...
296 (struct) streambuf
set static_in_include [filter static $declares]
As in the first example that used the metric_LOC attribute, this example makes use of an attribute (static). Instead of applying the attribute as a function, in this case it is used as a simple “attribute-expression”—the first parameter to the filter command.
Hopefully, this sample did not report any hits. There are a couple of variations you could try to make the output more interesting:
• Look for static entities declared in source files:
filter static [set.subtract
$all.files $included_files]
• Look for non-static entities declared in a single header file:
filter {! static} [get_declares main.h]


--- layout: post status: publish published: true title: Watch Notes in the VS2010 Debugger author: display_name: Tomas Restrepo login: tomasr email<EMAIL_ADDRESS>url: http://winterdom.com/ author_login: tomasr author_email<EMAIL_ADDRESS>author_url: http://winterdom.com/ wordpress_id: 1266 wordpress_url: http://winterdom.com/2009/06/watch-notes-in-the-vs2010-debugger date: '2009-06-04 04:13:37 +0000' date_gmt: '2009-06-04 04:13:37 +0000' categories: - Visual Studio tags: [] comments: - id: 868 author: DotNetShoutout author_email: '' author_url: http://dotnetshoutout.com/Watch-Notes-in-the-VS2010-Debugger-Tomas-Restrepo date: '2009-06-05 09:23:07 +0000' date_gmt: '2009-06-05 09:23:07 +0000' content: |- Watch Notes in the VS2010 Debugger - Tomas Restrepo... Thank you for submitting this cool story - Trackback from DotNetShoutout... ---
One interesting new feature I noticed in the Visual Studio 2010 beta 1 debugger: You can now turn watch expressions into little detached “post-it”-like notes that float around your debugger window.
You can create them by hovering the mouse over an expression. Like in previous versions, you’ll get the watch popup with the details and value of the expression, but notice the little Note-icon on the right:
If you click on it, the watch expression window will be moved to turn yellow and get detached. It keeps around during your debugging and works just like any expression in the real watch window (that is, it’s context sensitive and insensitive at the same time).
I think this is pretty nifty for some debugging helpers. They will even persist across debugger sessions! More interesting, you can add a brief descriptive text to each watch note and keep it visible (or hidden).
I think these will be very useful when debugging complex issues in small pieces of code, because for general debugging sessions when you go through lots of places in the code, they will get a bit in the way.
Something I did not like, though, is that the note icon used to create these gets hidden away whenever you look into a complex expression that can be drilled down (i.e. one that has [+] next to it):
As soon as the expression properties is expanded, the note icon disappears, and since they always expand automatically as soon as you hover the the cursor over the expression and you need to move over it anyway to reach the note icon (otherwise, the whole popup disappears), then you have to go right away to collapse the properties before being able to create a watch note from the expression. This can get annoying real quick.


The client said they have received a letter of proceedings, letter of issue or have a court date.
Please accept the case to continue or reject it if this information is not correct.
The system is showing me that:
For our records I just need to know whether you and your partner


Reliable, efficent delivey
Powered by technology
Our Artificial Intelligence powered tools use millions of project data points to ensure that your project is successful
Supervisor
Monitors activity to identify project roadblocks
Team Builder
Scans our talent network to create the optimal team for your project
Karma
Regularly evaluates our talent to ensure quality
Calculator
Uses data from past projects to provide better delivery estimates


Simple, but very useful observation: chewing Betel nuts is a great stimulant that offsets many of the undesirable effects of mushrooms and even adds to the strength of the trip. Betel nuts, I hear, are apparently the world's most common 'lift', surpassing even caffeine, believe it or not, despite the fact that its almost unheard of in the US. (Incidently, my wife is from Sweden and she tells me that there's plenty of things that are unheard of in the US!). Hey, kids, don't worry I am not a saleman or anything trying to sell Betel--heck, if this damn message causes a run on the stuff then I'll have to wait weeks for a refill. But the stuff works so well with shrooms that I couldn't keep it a secret, so here I am.
Alright, we all know shrooms are kinder to your head than other hallucinogens, thank goodness. However, the physical stimulation that allows you (or in some cases, forces you!) to walk 16 miles during a trip on other stuff just isn't there for shrooms. I even read somewhere on a shroom website to 'Get out your pillow, you'll need it', or some such. That's exaggeration, no doubt, but is there anyone here who wouldn't like a mild stimulant once in a while to complement their shroomy feeling?--as long as it doesn't cause Tension, the Big Enemy, right? Well, try Betel nuts. For me, it gives an immediate lift. There won't be any question about it--you will feel the lift within one minute of starting to chew, its reliable.
Arecoline is a mild central nervous system (CNS) stimulant, which increases respiration while decreasing the work load on the heart. Now, name me an experienced shroomer who hasn't experienced a need to yawn during certain stages of the trip--an indication that respiration isn't keeping up, and here arecoline can help.
Yes, yes, I know, technically arecoline is in the same cholinergic alkaloid group as is muscarine, found in Amanita muscaria (fly agaric). But, although I haven't researched it deeply, it seems to me the upshot of this is simply that arecoline affects the acetylcholine receptor, Big Surprise. You won't find much similarity between the chemical structures of arecoline and muscarine, muscimol, ibotenic acid, etc. However, I suppose it is possible that there is a deeper interaction which could account for an apparent increase in the effect of the mushrooms. Someone should investigate this.
I would consider it more noteworthy that many people consider Betel an aid to meditation and those sorts of things.
So, shroomers (especially party shroomers, although I suppose you have other additives), give it a try. It's a substantial lift without the tension, irritability, or anxiety that is often associated with other stimulants (and don't we do shrooms exactly to get away from that sort of crap?). It is also worth mentioning that extract of Ashwagandha (Withania somnifera), preferably taken sublingually, is a great restorer if you're coming down from shrooms or any combination thereof, and for whatever reason had some stress during the voyage, which we all know can get amplified. And finally, I think it is good to check and make sure that everyone is being sure to meditate or do their hypnosis during the time when they are first coming on to their shrooms, so as to relieve any heaviness of spirit and focus on what is important. What?! You don't meditate OR do hypnosis every day?!!
Experience Reports are the writings and opinions of the individual authors who submit them.
Some of the activities described are dangerous and/or illegal and none are recommended by Erowid.


The Java EE 7 Tutorial
1.3 Distributed Multitiered Applications
The Java EE platform uses a distributed multitiered application model for enterprise applications. Application logic is divided into components according to function, and the application components that make up a Java EE application are installed on various machines depending on the tier in the multitiered Java EE environment to which the application component belongs.
Figure 1-1 shows two multitiered Java EE applications divided into the tiers described in the following list. The Java EE application parts shown in Figure 1-1 are presented in Java EE Components.
-
Client-tier components run on the client machine.
-
Web-tier components run on the Java EE server.
-
Business-tier components run on the Java EE server.
-
Enterprise information system (EIS)-tier software runs on the EIS server.
Although a Java EE application can consist of all tiers shown in Figure 1-1, Java EE multitiered applications are generally considered to be three-tiered applications because they are distributed over three locations: client machines, the Java EE server machine, and the database or legacy machines at the back end. Three-tiered applications that run in this way extend the standard two-tiered client-and-server model by placing a multithreaded application server between the client application and back-end storage.
1.3.1 Security
Although other enterprise application models require platform-specific security measures in each application, the Java EE security environment enables security constraints to be defined at deployment time. The Java EE platform makes applications portable to a wide variety of security implementations by shielding application developers from the complexity of implementing security features.
The Java EE platform provides standard declarative access control rules that are defined by the developer and interpreted when the application is deployed on the server. Java EE also provides standard login mechanisms so that application developers do not have to implement these mechanisms in their applications. The same application works in a variety of security environments without changing the source code.
1.3.2 Java EE Components
Java EE applications are made up of components. A Java EE component is a self-contained functional software unit that is assembled into a Java EE application with its related classes and files and that communicates with other components.
The Java EE specification defines the following Java EE components:
-
Application clients and applets are components that run on the client.
-
Java Servlet, JavaServer Faces, and JavaServer Pages (JSP) technology components are web components that run on the server.
-
EJB components (enterprise beans) are business components that run on the server.
Java EE components are written in the Java programming language and are compiled in the same way as any program in the language. The differences between Java EE components and "standard" Java classes are that Java EE components are assembled into a Java EE application, they are verified to be well formed and in compliance with the Java EE specification, and they are deployed to production, where they are run and managed by the Java EE server.
1.3.3 Java EE Clients
A Java EE client is usually either a web client or an application client.
<IP_ADDRESS> Web Clients
A web client consists of two parts:
-
Dynamic web pages containing various types of markup language (HTML, XML, and so on), which are generated by web components running in the web tier
-
A web browser, which renders the pages received from the server
A web client is sometimes called a thin client. Thin clients usually do not query databases, execute complex business rules, or connect to legacy applications. When you use a thin client, such heavyweight operations are off-loaded to enterprise beans executing on the Java EE server, where they can leverage the security, speed, services, and reliability of Java EE server-side technologies.
<IP_ADDRESS> Application Clients
An application client runs on a client machine and provides a way for users to handle tasks that require a richer user interface than can be provided by a markup language. An application client typically has a graphical user interface (GUI) created from the Swing API or the Abstract Window Toolkit (AWT) API, but a command-line interface is certainly possible.
Application clients directly access enterprise beans running in the business tier. However, if application requirements warrant it, an application client can open an HTTP connection to establish communication with a servlet running in the web tier. Application clients written in languages other than Java can interact with Java EE servers, enabling the Java EE platform to interoperate with legacy systems, clients, and non-Java languages.
<IP_ADDRESS> Applets
A web page received from the web tier can include an embedded applet. Written in the Java programming language, an applet is a small client application that executes in the Java virtual machine installed in the web browser. However, client systems will likely need the Java Plug-in and possibly a security policy file for the applet to successfully execute in the web browser.
Web components are the preferred API for creating a web client program because no plug-ins or security policy files are needed on the client systems. Also, web components enable cleaner and more modular application design because they provide a way to separate applications programming from web page design. Personnel involved in web page design thus do not need to understand Java programming language syntax to do their jobs.
<IP_ADDRESS> The JavaBeans Component Architecture
The server and client tiers might also include components based on the JavaBeans component architecture (JavaBeans components) to manage the data flow between the following:
-
An application client or applet and components running on the Java EE server
-
Server components and a database
JavaBeans components are not considered Java EE components by the Java EE specification.
JavaBeans components have properties and have get
and set
methods for accessing those properties. JavaBeans components used in this way are typically simple in design and implementation but should conform to the naming and design conventions outlined in the JavaBeans component architecture.
<IP_ADDRESS> Java EE Server Communications
Figure 1-2 shows the various elements that can make up the client tier. The client communicates with the business tier running on the Java EE server either directly or, as in the case of a client running in a browser, by going through web pages or servlets running in the web tier.
1.3.4 Web Components
Java EE web components are either servlets or web pages created using JavaServer Faces technology and/or JSP technology (JSP pages). Servlets are Java programming language classes that dynamically process requests and construct responses. JSP pages are text-based documents that execute as servlets but allow a more natural approach to creating static content. JavaServer Faces technology builds on servlets and JSP technology and provides a user interface component framework for web applications.
Static HTML pages and applets are bundled with web components during application assembly but are not considered web components by the Java EE specification. Server-side utility classes can also be bundled with web components and, like HTML pages, are not considered web components.
As shown in Figure 1-3, the web tier, like the client tier, might include a JavaBeans component to manage the user input and send that input to enterprise beans running in the business tier for processing.
Figure 1-3 Web Tier and Java EE Applications
Description of "Figure 1-3 Web Tier and Java EE Applications"
1.3.5 Business Components
Business code, which is logic that solves or meets the needs of a particular business domain such as banking, retail, or finance, is handled by enterprise beans running in either the business tier or the web tier. Figure 1-4 shows how an enterprise bean receives data from client programs, processes it (if necessary), and sends it to the enterprise information system tier for storage. An enterprise bean also retrieves data from storage, processes it (if necessary), and sends it back to the client program.
1.3.6 Enterprise Information System Tier
The enterprise information system tier handles EIS software and includes enterprise infrastructure systems, such as enterprise resource planning (ERP), mainframe transaction processing, database systems, and other legacy information systems. For example, Java EE application components might need access to enterprise information systems for database connectivity.


Xmake is a lightweight cross-platform build utility based on Lua.
It is very lightweight and has no dependencies because it has a built-in Lua runtime.
It uses xmake.lua to maintain project builds and its configuration syntax is very simple and readable.
We can use it to build project directly like Make/Ninja, or generate project files like CMake/Meson, and it also has a built-in package management system to help users solve the integrated use of C/C++ dependent libraries.
Xmake = Build backend + Project Generator + Package Manager + [Remote|Distributed] Build + Cache
Although not very precise, we can still understand Xmake in the following way:
Xmake ≈ Make/Ninja + CMake/Meson + Vcpkg/Conan + distcc + ccache/sccache
Introduction of new features
Quickly switch temporary virtual environments
Xmake has long supported the virtual environment management of packages, and can switch between different package environments through configuration files.
We can customize some package configurations by adding the xmake.lua file in the current directory, and then enter a specific package virtual environment.
add_requires("zlib 1.2.11")
add_requires("python 3.x", "luajit")
$ xrepo env shell
> python --version
> luajit --version
You can also switch environments by importing custom environment configuration files:
$ xrepo env --add /tmp/base.lua
$ xrepo env -b base shell
In the new version, we have made further improvements, allowing Xrepo to temporarily specify the list of environment packages that need to be bound directly on the command line to achieve fast switching without any configuration.
And it supports specifying multiple package environments at the same time.
For example, we want to enter an environment with python 3.0, luajit and cmake, just execute:
$ xrepo env -b "python 3.x,luajit,cmake" shell
[python, luajit, cmake] $ python --version
Python 3.10.6
[python, luajit, cmake] $ cmake --version
cmake version 3.25.3
Xmake will automatically install the relevant dependencies, and then open a new shell environment. There is also a prompt prompt on the left side of the terminal in the new environment.
If we want to exit the current environment, we only need to execute
[python, luajit, cmake] $ xrepo env quit
$
Improve code feature detection
A series of detection interfaces such as has_cfuncs/check_cxxsnippets have been provided in option, and there are corresponding auxiliary APIs to help detection.
For related documents, please refer to: helper detection interface.
However, the current detection interface provided by option is only for the global platform tool chain, and it is impossible to perform targeted detection according to each specific target configuration.
Because the target itself may also have dependent packages, different tool chains, compilation macros and other differences, the detection results will also have some differences.
Therefore, if users want more flexible and fine-grained detection of the compilation characteristics of each target target, they can use the target target instance interface provided by the new version.
- target: has_cfuncs
- target: has_cxxfuncs
- target:has_ctypes
- target:has_cxxtypes
- target: has_cincludes
- target:has_cxxincludes
- target:has_cflags
- target:has_cxxflags
- target:has_features
- target: check_csnippets
- target: check_cxxsnippets
Here, only for some of the more commonly used interfaces, a little introduction to the usage.
target:has_cfuncs
- Check whether the target compilation configuration can obtain the given C function
This should be used in on_config
, for example, it can be used to determine whether the current target can obtain some function interfaces of the zlib dependent package, and then automatically define HAVE_INFLATE
:
add_requires("zlib")
target("test")
set_kind("binary")
add_files("src/*.c")
add_packages("zlib")
on_config(function(target)
if target:has_cfuncs("inflate", {includes = "zlib.h"}) then
target:add("defines", "HAVE_INFLATE")
end
end)
Although option also provides similar detection functions, the detection of option uses the global platform tool chain, which cannot be accompanied by some compilation configurations related to target. It is also impossible to set different compilation toolchains according to the target to adapt the detection, and it is impossible to detect some interfaces in the package.
If we only want a coarse-grained detection function interface, and the target does not additionally set different tool chains, then the detection function provided by option is sufficient.
If you want more fine-grained control over detection, you can use the detection features provided by the target instance interface.
target:has_cxxfuncs
- Check whether the target compilation configuration can obtain the given C++ function
The usage is similar to target:has_cfuncs, except that it is mainly used to detect C++ functions.
However, while detecting functions, we can also additionally configure std languages to assist detection.
target:has_cxxfuncs("foo", {includes = "foo.h", configs = {languages = "cxx17"}})
target:has_ctypes
- Check whether the target compilation configuration can obtain the given C type
This should be used in on_config
like this:
add_requires("zlib")
target("test")
set_kind("binary")
add_files("src/*.c")
add_packages("zlib")
on_config(function(target)
if target:has_ctypes("z_stream", {includes = "zlib.h"}) then
target:add("defines", "HAVE_ZSTEAM_T")
end
end)
target:has_cflags
- Check whether the target compilation configuration can obtain the given C compilation flags
target("test")
set_kind("binary")
add_files("src/*.cpp")
on_config(function(target)
if target:has_cxxflags("-fPIC") then
target:add("defines", "HAS_PIC")
end
end)
target:has_cincludes
- Check whether the target compilation configuration can obtain the given C header file
This should be used in on_config
, for example, it can be used to determine whether the current target can obtain the zlib.h header file of the zlib dependency package, and then automatically define HAVE_INFLATE
:
add_requires("zlib")
target("test")
set_kind("binary")
add_files("src/*.c")
add_packages("zlib")
on_config(function(target)
if target:has_cincludes("zlib.h") then
target:add("defines", "HAVE_ZLIB_H")
end
end)
target:check_cxxsnippets
- Detect if a given piece of C++ code can be compiled and linked
This should be used in on_config
like this:
add_requires("libtins")
target("test")
set_kind("binary")
add_files("src/*.cpp")
add_packages("libtins")
on_config(function(target)
local has_snippet = target:check_cxxsnippets({test = [[
#include <string>
using namespace Tins;
void test() {
std::string name = NetworkInterface::default_interface().name();
printf("%s\n", name.c_str());
}
]]}, {configs = {languages = "c++11"}, includes = {"tins/tins.h"}}))
if has_snippet then
target:add("defines", "HAS_XXX")
end
end)
By default, it only checks whether the compilation link is passed. If you want to try the runtime check, you can set tryrun = true
.
target("test")
set_kind("binary")
add_files("src/*.cpp")
on_config(function(target)
local has_int_4 = target:check_cxxsnippets({test = [[
return (sizeof(int) == 4)? 0 : -1;
]]}, {configs = {languages = "c++11"}, tryrun = true}))
if has_int_4 then
target:add("defines", "HAS_INT4")
end
end)
We can also continue to capture the running output of the detection by setting output = true
, and add a custom main
entry to achieve a complete test code, not just a code snippet.
target("test")
set_kind("binary")
add_files("src/*.cpp")
on_config(function(target)
local int_size = target:check_cxxsnippets({test = [[
#include <stdio.h>
int main(int argc, char** argv) {
printf("%d", sizeof(int)); return 0;
return 0;
}
]]}, {configs = {languages = "c++11"}, tryrun = true,output = true}))
end)
target:has_features
- Detect if specified C/C++ compilation feature
It is faster than using check_cxxsnippets
, because it only performs preprocessing once to check all compiler features, instead of calling the compiler every time to try to compile.
target("test")
set_kind("binary")
add_files("src/*.cpp")
on_config(function(target)
if target:has_features("c_static_assert") then
target:add("defines", "HAS_STATIC_ASSERT")
end
if target:has_features("cxx_constexpr") then
target:add("defines", "HAS_CXX_CONSTEXPR")
end
end)
Optimize compilation performance
The build cache acceleration of Xmake is similar to ccache, which uses the preprocessor to calculate the hash and cache the compiled object files to achieve acceleration. It has a very obvious speed-up effect on linux/mac.
And because the preprocessor of msvc is very slow, it may also be that the starting process is heavier than that under linux/mac. After the build cache is enabled, the overall compilation efficiency of using msvc on windows is much slower.
Trying to use a third-party ccache to test and compare, the same problem, so I temporarily disabled the build cache for msvc by default, so that the overall build speed returned to normal levels.
clang-tidy autofix
In the last version, we added support for clang-tidy, and you can check the code through xmake check clang.tidy
.
In this version, we continue to improve it and add the --fix
parameter, which allows clang-tidy to automatically fix the detected problem code.
$ xmake check clang.tidy --fix
$ xmake check clang.tidy --fix_errors
$ xmake check clang.tidy --fix_notes
Swig/Java module build support
Additionally, other users have helped contribute build support for Swig/Java modules.
add_rules("mode. release", "mode. debug")
target("example")
set_kind('shared')
--set moduletype to java
add_rules("swig.c", {moduletype = "java"})
-- use swigflags to provider package name and output path of java files
add_files("src/example.i", {swigflags = {
"-package",
"com. example",
"-outdir",
"build/java/com/example/"
}})
add_files("src/example.c")
before_build(function()
-- ensure output path exists before running swig
os.mkdir("build/java/com/example/")
end)
For a complete example, see: Swig/Java Example
Changelog
New features
- #3518: Profile compile and link performance
- #3522: Add has_cflags, has_xxx for target
- #3537: Add –fix for clang.tidy checker
Changes
- #3433: Improve to build Qt project on msys2/mingw64 and wasm
- #3419: Support fish shell envirnoment
- #3455: Dlang incremental build support
- #3498: Improve to bind package virtual envirnoments
- #3504: Add swig java support
- #3508: Improve trybuild/cmake to support for switching toolchain
- disable build cache for msvc, because msvc’s preprocessor is too slow.