Recherche avancée

Sur d’autres sites (7654)

• ARM compiler update

  15 janvier 2010, par Mans — ARM, Compilers

  Since my last shootout, all the tested vendors have updated their compilers. Here is a quick update on each of them.

  Both the 4.3 and 4.4 branches of FSF GCC have had bugfix releases, bringing them to 4.3.4 and 4.4.2, respectively. Neither update contains anything particularly noteworthy.

  The CodeSourcery 2009q3 release sees an update to a GCC 4.4 base, a significant change from the 4.3 base used in 2009q1. The update is a mixed blessing. In fact, it is mostly a curse and hardly a blessing at all. On the bright side, the floating-point speed regressions in 2009q1 are gone, 2009q3 being a few per cent faster even than 2007q3. Unfortunately, this improvement is completely overshadowed by a major speed regression on integer code, a whopping 24% in one case. This ties in with the slowdown previously observed with FSF GCC 4.4 compared to 4.3.

  ARM RVCT 4.0 is now at Build 697. This update fixes some bugs and introduces others. Notably, it no longer builds FFmpeg correctly. The issue has been reported to ARM.

  Texas Instruments, finally, have made a formal release, v4.6.1, of their TMS470 compiler incorporating various fixes allowing it to build a moderately patched FFmpeg. The performance remains somewhere between GCC and RVCT on average.

  In light of the above, my recommendations remain unchanged :

  • For a free compiler, choose CodeSourcery 2009q1. It beats GCC 4.3.4 by 5-10% in most cases.
  • GNU purists are best served by GCC 4.3.4, which is up to 20% faster than 4.4.2 and rarely slower.
  • When price is not a concern, ARM RCVT is a good option, outperforming GCC by up to a factor 2.
  • In all cases, disable any auto-vectorisation features.

  Regardless of which compiler is chosen, I cannot overstress the importance of testing. All compilers are crawling with bugs, and even the most innocent-looking code change can trigger one of them. When using a compiler other than GCC, extra caution is advised considering a lot of code is developed using only GCC and may thus fall prey to bugs unique to said other compiler.

• Anomalie #4799 (Nouveau) : Validité du RSS

  26 mai 2021

  Marc, sur https://discuter.spip.net/t/rss-atom-enclosures-et-w3c/152922 signale quelques points de validité à améliorer sur le RSS de la dist

  backend.html¶

  • balise rss : rajout d’un lien xmlns:atom="http://www.w3.org/2005/Atom"
  • balise channel : rajout de
  • réf : Missing atom:link with rel="self"

  squelette rss-item.html (ou inc-rss.html)¶

  • enclosures multiples : item contains more than one enclosure
  • suggestion (discutable) rajouter un critère {0,1} dans la boucle document de rss-item.html

  <span class="CodeRay">
  
  <span class="tag">span><span class="error">(</span><span class="attribute-name">DOCUMENTS</span><span class="error">)</span><span class="error">{</span><span class="attribute-name">id_article</span><span class="error">}</span><span class="error">{</span><span class="attribute-name">mode</span>=<span class="attribute-value">document</span><span class="error">}</span><span class="error">{</span><span class="attribute-name">doublons</span><span class="error">}</span><span class="error">{</span><span class="attribute-name">0</span><span class="error">,</span><span class="attribute-name">1</span><span class="error">}</span><span class="tag">></span>[
  
  <span class="tag">span> <span class="attribute-name">url</span>=<span class="string"><span class="delimiter">"</span><span class="content">(#URL_DOCUMENT|url_absolue|unique)</span><span class="delimiter">"</span></span><span class="error">[</span> <span class="attribute-name">length</span>=<span class="string"><span class="delimiter">"</span><span class="content">(#TAILLE)</span><span class="delimiter">"</span></span><span class="error">]</span><span class="error">[</span> <span class="attribute-name">type</span>=<span class="string"><span class="delimiter">"</span><span class="content">(#MIME_TYPE)</span><span class="delimiter">"</span></span><span class="error">]</span> <span class="tag">/></span>]
  
  <span class="tag"></span>
  
  </span></span></span>

• avcodec/hevcpred : Pass HEVCLocalContext when slice-threading

  30 juin 2022, par Andreas Rheinhardt

  avcodec/hevcpred : Pass HEVCLocalContext when slice-threading
  The HEVC decoder has both HEVCContext and HEVCLocalContext
  
  structures. The latter is supposed to be the structure
  
  containing the per-slicethread state.
  Yet that is not how it is handled in practice : Each HEVCLocalContext
  
  has a unique HEVCContext allocated for it and each of these
  
  coincides except in exactly one field : The corresponding
  
  HEVCLocalContext. This makes it possible to pass the HEVCContext
  
  everywhere where logically a HEVCLocalContext should be used.
  This commit stops doing this for lavc/hevcpred as well as
  
  the corresponding mips code ; the latter is untested.
  Signed-off-by : Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
  

  • [DH] libavcodec/hevcdec.c
  • [DH] libavcodec/hevcpred.h
  • [DH] libavcodec/hevcpred_template.c
  • [DH] libavcodec/mips/hevcpred_mips.h
  • [DH] libavcodec/mips/hevcpred_msa.c