Re: Enabling Checksums
От | Tom Lane |
---|---|
Тема | Re: Enabling Checksums |
Дата | |
Msg-id | 12819.1366237925@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: Enabling Checksums (Ants Aasma <ants@cybertec.at>) |
Ответы |
Re: Enabling Checksums
Re: Enabling Checksums Re: Enabling Checksums |
Список | pgsql-hackers |
Ants Aasma <ants@cybertec.at> writes: > I was thinking about something similar too. The big issue here is that > the parallel checksums already hide each other latencies effectively > executing one each of movdqu/pmullw/paddw each cycle, that's why the > N_SUMS adds up to 128 bytes not 16 bytes. The more I read of this thread, the more unhappy I get. It appears that the entire design process is being driven by micro-optimization for CPUs being built by Intel in 2013. That ought to be, at best, a fifth-order consideration, with full recognition that it'll be obsolete in two years, and is already irrelevant to anyone not running one of those CPUs. I would like to ban all discussion of assembly-language optimizations until after 9.3 is out, so that we can concentrate on what actually matters. Which IMO is mostly the error detection rate and the probable nature of false successes. I'm glad to see that you're paying at least some attention to that, but the priorities in this discussion are completely backwards. And I reiterate that there is theory out there about the error detection capabilities of CRCs. I'm not seeing any theory here, which leaves me with very little confidence that we know what we're doing. regards, tom lane
В списке pgsql-hackers по дате отправления: