Re: Operation Reordering

Thanks, "Assume nothing" is a pretty scientific approach,I like it :) But this (absence of) assumption lead me to think about another couple of things: what about all the encoders/decoders or any program that rely on data access patterns to pretend to be and remain "fast"? Writing mechanichal

Epoch Based Reclamation

Hi guys! For who's interested in lock/wait-free data structures that requires some form of reclamation/garbage collecting (others than an out-of-the-box collector provided by a JVM) this thesis is a good starting point to learn about

Re: Disk-based logger - write pretouch

Il giorno lunedì 10 luglio 2017 20:41:23 UTC+2, Roman Leventov ha scritto: > > On 10 July 2017 at 13:21, Martin Thompson > wrote: > >> Are you running recent MacOS with APFS which supports sparse files? >> > > If this is of any interest, my OS version is > > Darwin

Re: Detailed post on using SEDA-like algorithms to improve IPC

Thanks! It is a very interesting post! Il giorno lunedì 17 luglio 2017 16:44:13 UTC+2, Avi Kivity ha scritto: > > Some time ago I posted about how we ~ doubled our IPC; here is a > detailed blog post explaining the problem and solution: > > > >

Re: Aeron zero'ing buffer?

The Intel manual effectively is pretty short while explaining it, but anyway a "simple" check with proper tools could be a good experiment to validate it: https://joemario.github.io/blog/2016/09/01/c2c-blog/ I've asked to an Intel engineer about it some times ago (on 14th Feb) and he answered

Re: Aeron zero'ing buffer?

The coolest thing IMHO about the Aeron LogBuffer is how it trades performances on concurrent writings with a measurable loss of precision on backpressure: it is a really a very smart and effective idea! Il giorno martedì 30 maggio 2017 13:06:32 UTC+2, Martin Thompson ha scritto: > > The claim

Re: synchronized and ReentrantLock are REALLY the same?

Thanks Gil! I will failback to my original (semi-practical) concern, using this renewed knowledge :) Suppose that we want to perform write operations surrounding both a j.u.c. Lock and synchronized mutual exclusion block and we want: 1. these writes operations to not being moved inside the

synchronized and ReentrantLock are REALLY the same?

Hi guys! probably this one should be more a concurrency-interest question, but I'm sure that's will fit with most of the people around here as well :) I was looking to how ReentrantLock and synchronized are different from a semantic point of view and I've found (there are no experimental proofs

Re: synchronized and ReentrantLock are REALLY the same?

19 maggio 2018 06:21:19 UTC+2, Gil Tene ha scritto: > > > > On Friday, May 18, 2018 at 11:10:45 PM UTC-5, Gil Tene wrote: >> >> >> >> On Friday, May 18, 2018 at 2:30:08 AM UTC-5, Francesco Nigro wrote: >>> >>> Thanks Gil! >>> >>> I will

Mutex and Spectre/Meltdown

Hi guys! Any of you have already measured (or simply know) if OS mutexes are somehow affected by Spectre/Meltdown? Cheers, Franz -- You received this message because you are subscribed to the Google Groups "mechanical-sympathy" group. To unsubscribe from this group and stop receiving emails

Call site (optimizations)

My cell phone has decided to cut the third question: 3. I know that compiled code from the JVM is available in a Code Cache to allow different call-sites to use it: that means that the same compiled method is used in all those call-sites (provided that's the best version of it)? -- You

Re: Call site (optimizations)

ual method lookup followed by a jump to that code. So to see the benefits of inlining from a different path, that path would also have to be "warmed up". Il giorno mercoledì 31 gennaio 2018 05:42:12 UTC-5, Rémi Forax ha scritto: > > > > ------ > >

Re: Intra-process queue between Java and C++

(or just resync of state) can be done a number of ways. > Including just a system graceful reset. > > On Tue, Apr 3, 2018 at 7:36 AM, Francesco Nigro <nigr...@gmail.com > > wrote: > >> There are a couple of things to be considered: >> >>1. size request and re

Re: Intra-process queue between Java and C++

There are a couple of things to be considered: 1. size request and response buffers to avoid deadlocks (there is an interesting topic on this list re it too) -> could be used a broadcast buffer too to avoid it, but it change the semantic by adding a new "failure" state 2.

Re: Avoiding expensive memory barriers

HI guys! Re > 2. prevent preceding writes from being reordered by the compiler (they are implicitly ordered by the processor on x86). I have had a quite interesting chat with Jeff Preshing (http://preshing.com/) about relaxed guarantees and he pointed me this one to help on it:

Re: Concurrent retrieval of statistics

Or you could use something similar to this too: if you are slow to collect, you loose things (and you know how many samples), but you won't slow down too much the producer...https://github.com/real-logic/agrona/pull/119 Il giorno martedì 16 ottobre 2018 10:47:31 UTC+2, Wojciech Kudla ha

Load generators and Coordination Omission compensations

HI guys, I have put a question (probably too basic for many folks here!) on HdrHistogram issues page: Load generator CO free and HdrHistogram I'm assuming most of the folks here to be familiar with the "Coordinated Omission" term but

Re: Happens before between putting and getting from and to ConcurrentHashMap

It would matter if you add some logic around it: //put of a value in the map with just a lazySet/putOrdered etc etc If (anyConsumerIsSleeping()) { wakeUpConsumers(); } If you won't have a full barrier the compile *could* reorder anyConsumerIsSleeping() ahead of the map.put, making possible

Re: Happens before between putting and getting from and to ConcurrentHashMap

me for java.util.concurrent's Queue implementations, such as > ConcurrentLinkedQueue: Javadoc doesn't say that queue.offer() and poll() > are synchronization actions. > > On Mon, 19 Nov 2018 at 16:11, Francesco Nigro wrote: > >> It would matter if you add some logic around it: >>

Performance is not composable

Hi folks, while reading the awesome https://shipilev.net/blog/2014/nanotrusting-nanotime/ I have some questions on the "Building Performance Models" part. Specifically, when you want to compare 2 operations (ie A,B) and you want to emulate the same behaviour of a real application you need to

Re: Huge, unexpected performance overhead (of static methods?)

I suspect that the build phase of an app using Graal AOT could suffer the same limitation, but it is correct that static initializers *shouldn't* be used for heavyweight computations given that are ensured to be called serially... Il giorno ven 8 feb 2019, 02:36 Andrei Pangin ha scritto: >

Re: Volatile semantic for failed/noop atomic operations

Although not mentioned (neither on Doug's cookbook) I have always supposed was more likely the c++ default for both weak/strong CAS ie seq_cst memory ordering. To make this question more mechanical sympathy focused: on hardware level what happen? I would be curious to know both x86/arm versions

Re: Volatile semantic for failed/noop atomic operations

art, > it fails). But, I’m not overly familiar with ARM internals/mechanics. > > On Sat, Sep 14, 2019 at 3:20 PM Francesco Nigro > wrote: > >> Although not mentioned (neither on Doug's cookbook) I have always >> supposed was more likely the c++ default for both weak/s