Recherche avancée

Sur d’autres sites (10025)

• Cortex-A7 instruction cycle timings

  15 mai 2014, par Mans — ARM

  The Cortex-A7 ARM core is a popular choice in low-power and low-cost designs. Unfortunately, the public TRM does not include instruction timing information. It does reveal that execution is in-order which makes measuring the throughput and latency for individual instructions relatively straight-forward.

  The table below lists the measured issue cycles (inverse throughput) and result latency of some commonly used instructions.

  It should be noted that in some cases, the perceived latency depends on the instruction consuming the result. Most of the values were measured with the result used as input to the same instruction. For instructions with multiple outputs, the latencies of the result registers may also differ.

  Finally, although instruction issue is in-order, completion is out of order, allowing independent instructions to issue and complete unimpeded while a multi-cycle instruction is executing in another unit. For example, a 3-cycle MUL instruction does not block ADD instructions following it in program order.

  ALU instructions	Issue cycles	Result latency
  MOV Rd, Rm	1/2	1
  ADD Rd, Rn, #imm	1/2	1
  ADD Rd, Rn, Rm	1	1
  ADD Rd, Rn, Rm, LSL #imm	1	1
  ADD Rd, Rn, Rm, LSL Rs	1	1
  LSL Rd, Rn, #imm	1	2
  LSL Rd, Rn, Rs	1	2
  QADD Rd, Rn, Rm	1	2
  QADD8 Rd, Rn, Rm	1	2
  QADD16 Rd, Rn, Rm	1	2
  CLZ Rd, Rm	1	1
  RBIT Rd, Rm	1	2
  REV Rd, Rm	1	2
  SBFX Rd, Rn	1	2
  BFC Rd, #lsb, #width	1	2
  BFI Rd, Rn, #lsb, #width	1	2
  NOTE : Shifted operands and shift amounts needed one cycle early.
  Multiply instructions	Issue cycles	Result latency
  MUL Rd, Rn, Rm	1	3
  MLA Rd, Rn, Rm, Ra	1	31
  SMULL Rd, RdHi, Rn, Rm	1	3
  SMLAL Rd, RdHi, Rn, Rm	1	31
  SMMUL Rd, Rn, Rm	1	3
  SMMLA Rd, Rn, Rm, Ra	1	31
  SMULBB Rd, Rn, Rm	1	3
  SMLABB Rd, Rn, Rm, Ra	1	31
  SMULWB Rd, Rn, Rm	1	3
  SMLAWB Rd, Rn, Rm, Ra	1	31
  SMUAD Rd, Rn, Rm	1	3
  1 Accumulator forwarding allows back to back MLA instructions without delay.
  Divide instructions	Issue cycles	Result latency
  SDIV Rd, Rn, Rm	4-20	6-22
  UDIV Rd, Rn, Rm	3-19	5-21
  Load/store instructions	Issue cycles	Result latency
  LDR Rt, [Rn]	1	3
  LDR Rt, [Rn, #imm]	1	3
  LDR Rt, [Rn, Rm]	1	3
  LDR Rt, [Rn, Rm, lsl #imm]	1	3
  LDRD Rt, Rt2, [Rn]	1	3-4
  LDM Rn, regs	1-8	3-10
  STR Rt, [Rn]	1	2
  STRD Rt, Rt2, [Rn]	1	2
  STM Rn, regs	1-10	2-12
  NOTE : Load results are forwarded to dependent stores without delay.
  VFP instructions	Issue cycles	Result latency
  VMOV.F32 Sd, Sm	1	4
  VMOV.F64 Dd, Dm	1	4
  VNEG.F32 Sd, Sm	1	4
  VNEG.F64 Dd, Dm	1	4
  VABS.F32 Sd, Sm	1	4
  VABS.F64 Dd, Dm	1	4
  VADD.F32 Sd, Sn, Sm	1	4
  VADD.F64 Dd, Dn, Dm	1	4
  VMUL.F32 Sd, Sn, Sm	1	4
  VMUL.F64 Dd, Dn, Dm	4	7
  VMLA.F32 Sd, Sn, Sm	1	81
  VMLA.F64 Dd, Dn, Dm	4	112
  VFMA.F32 Sd, Sn, Sm	1	81
  VFMA.F64 Dd, Dn, Dm	5	82
  VDIV.F32 Sd, Sn, Sm	15	18
  VDIV.F64 Dd, Dn, Dm	29	32
  VSQRT.F32 Sd, Sm	14	17
  VSQRT.F64 Dd, Dm	28	31
  VCVT.F32.F64 Sd, Dm	1	4
  VCVT.F64.F32 Dd, Sm	1	4
  VCVT.F32.S32 Sd, Sm	1	4
  VCVT.F64.S32 Dd, Sm	1	4
  VCVT.S32.F32 Sd, Sm	1	4
  VCVT.S32.F64 Sd, Dm	1	4
  VCVT.F32.S32 Sd, Sd, #fbits	1	4
  VCVT.F64.S32 Dd, Dd, #fbits	1	4
  VCVT.S32.F32 Sd, Sd, #fbits	1	4
  VCVT.S32.F64 Dd, Dd, #fbits	1	4
  1 5 cycles with dependency only on accumulator. 2 8 cycles with dependency only on accumulator.
  NEON integer instructions	Issue cycles	Result latency
  VADD.I8 Dd, Dn, Dm	1	4
  VADDL.S8 Qd, Dn, Dm	2	4
  VADD.I8 Qd, Qn, Qm	2	4
  VMUL.I8 Dd, Dn, Dm	2	4
  VMULL.S8 Qd, Dn, Dm	2	4
  VMUL.I8 Qd, Qn, Qm	4	4
  VMLA.I8 Dd, Dn, Dm	2	4
  VMLAL.S8 Qd, Dn, Dm	2	4
  VMLA.I8 Qd, Qn, Qm	4	4
  VADD.I16 Dd, Dn, Dm	1	4
  VADDL.S16 Qd, Dn, Dm	2	4
  VADD.I16 Qd, Qn, Qm	2	4
  VMUL.I16 Dd, Dn, Dm	1	4
  VMULL.S16 Qd, Dn, Dm	2	4
  VMUL.I16 Qd, Qn, Qm	2	4
  VMLA.I16 Dd, Dn, Dm	1	4
  VMLAL.S16 Qd, Dn, Dm	2	4
  VMLA.I16 Qd, Qn, Qm	2	4
  VADD.I32 Dd, Dn, Dm	1	4
  VADDL.S32 Qd, Dn, Dm	2	4
  VADD.I32 Qd, Qn, Qm	2	4
  VMUL.I32 Dd, Dn, Dm	2	4
  VMULL.S32 Qd, Dn, Dm	2	4
  VMUL.I32 Qd, Qn, Qm	4	4
  VMLA.I32 Dd, Dn, Dm	2	4
  VMLAL.S32 Qd, Dn, Dm	2	4
  VMLA.I32 Qd, Qn, Qm	4	4
  NEON floating-point instructions	Issue cycles	Result latency
  VADD.F32 Dd, Dn, Dm	2	4
  VADD.F32 Qd, Qn, Qm	4	4
  VMUL.F32 Dd, Dn, Dm	2	4
  VMUL.F32 Qd, Qn, Qm	4	4
  VMLA.F32 Dd, Dn, Dm	2	81
  VMLA.F32 Qd, Qn, Qm	4	81
  1 5 cycles with dependency only on accumulator.
  NEON permute instructions	Issue cycles	Result latency
  VEXT.n Dd, Dn, Dm, #imm	1	4
  VEXT.n Qd, Qn, Qm, #imm	2	5
  VTRN.n Dd, Dn, Dm	2	5
  VTRN.n Qd, Qn, Qm	4	5
  VUZP.n Dd, Dn, Dm	2	5
  VUZP.n Qd, Qn, Qm	4	6
  VZIP.n Dd, Dn, Dm	2	5
  VZIP.n Qd, Qn, Qm	4	6
  VTBL.8 Dd, Dn, Dm	1	4
  VTBL.8 Dd, Dn-Dn+1, Dm	1	4
  VTBL.8 Dd, Dn-Dn+2, Dm	2	5
  VTBL.8 Dd, Dn-Dn+3, Dm	2	5

• Anomalie #3675 : fsockopen => lenteur dans inc/queue

  7 février 2016, par Nicolas RICQUEMAQUE

  Il semble tout d’abord que les problèmes rapportés d’extrême lenteur de la fonction fsockopen semblent être communs sur Internet. Voir par exemple le post qui propose des solutions : http://stackoverflow.com/questions/5211658/php-fsockopen-painfully-slow ; notamment la résolution dns directe ne semble pas très efficace, mais la solution proposée, via un gethostbyname(), ne fonctionnera pas en tls (qui vérifie la cohérence du certificat publique avec l’url à connecter).

  En réfléchissant un peu, outre les différentes possibilités de mitigation des problèmes évoqués quant aux limitations de la fonction fsockopen ailleurs sur Internet, il semble que l’on est ici en face, de façon plus générale, d’une "fausse bonne idée". A savoir, la création d’une tâche asynchrone via l’ouverture d’une nouvelle connexion http sur le même serveur. Après 15 ans de travail dans les infrastructures télécom, je vois difficilement comment cela peut fonctionner à tous les coups. Une telle requête, effectuée du serveur vers lui-même en utilisant l’adresse IP récupérée dans un DNS va fonctionner très différemment en fonction de la structure technique du réseau de l’hébergeur. Où sont terminées les adresses publiques ? Le Firewall autorise-t-il la réentrance ? le DNS résout il différemment sur son réseau interne par rapport au réseau publique ? Comment est configuré et où se trouve le load-balancer ? La machine est elle une machine physique (mutualisée ou non) ou plutôt une machine virtuelle avec le NAT ou du bridging interne sur l’hôte ? Tout ceci va influer sur le fait que le fsockopen (ou curl) va fonctionner ou non. Il y a des bonnes pratiques dans l’industrie, mais à aucun moment vous pouvez être sûr, qu’un logiciel comme SPIP qui doit tenter de s’adapter partout, va fonctionner partout. Et le cURL n’est pas beaucoup plus rustique en la matière (un peu plus tout de même, c’est un appel unix hors php, les auteurs de cURL ont bien blindé leur code, mais je ne m’y fierai pas à 100%).

  Le problème est donc, que parfois, en fonction de l’hébergeur, tout simplement, comme l’indique bien le commentaire dans le code existant de queue.php, "cela ne va par marcher".
  Mais qu’est ce qui se passe quand cela ne fonctionne pas, et pourquoi cela ralenti autant l’affichage des pages web ?
  - Si !function_exists(’fsockopen’) et !function_exists("curl_init"), alors c’est simple, on va appliquer l’astuce de l’image-background
  - Si les fonctions existent bien, mais que "quelque chose" dans l’infrastructure "bloque" la connexion. Il y a 2 façons de bloquer. Un load balancer, un serveur, ou un routeur renverront probablement un TCP/RST immédiatement, fermant donc la connexion TCP, et 5 ms après on sort vers l’image background. Y’a pas de dégats.
  - Si les fonctions existent bien, et que c’est un "firewall" qui ne laisse pas passer, il ne va rien répondre du tout, c’est à dire laisser tomber la connexion en timeout, qui est ici de 1s (très très très long pour un appel vers sois-même ! c’est un premier bug, il ne faudrait pas dépasser 20ms maximum). Donc, Curl ou fsockopen, l’utilisateur, dans l’affichage de la page, va perdre une première seconde. Pourquoi première ? parce que le code de la fonction semble être pouvoir être appelé plusieurs fois (commentaire dans le code "ne pas relancer si on vient de lancer dans la meme seconde par un hit concurent") et que le fichier est locké avant l’appel à fsockopen ou à curl, dès la sortie de la fonction, après un timeout de 1s de fsockopen par exemple, on aura déjà expiré le lock. Donc on peut probablement se retrouver dans un cas ou la fonction (qui échoue à chaque fois via un timeout de 1s) est appelée plusieurs fois de suite. Bofff ;-). Il faut donc décorréler cette valeur de check du lock avec le timeout de durée des appels réseaux au moins d’un facteur 10 pour éviter les effets d’avalanche...

  Conclusion : les appels asynchrones sont une très bonne idée en théorie, mais en pratique, je pense qu’ils risquent d’amener plus de problèmes que de solutions. Et cela semble se vérifier en regard des nombreux utilisateurs qui semblent avoir le problème sur le réseau, ou décident finalement de rester sur la 2.1, ou de changer de crémerie (hébergeur ou CMS). Pour les moins chanceux, de se contenter d’un site qui est devenu irresponsif...

  Il est possible à mon avis toutefois de conserver intelligemment cette technique quand elle est applicable. Pourquoi réessayer et se remplanter d’une seconde comme les shadoks sur chaque page ? Si un hébergeur ne fonctionne pas, cela ne va pas fonctionner à tous les coups. Tout du moins jusqu’à ce qu’il change son infra ou le client déménage ailleurs. Je proposerai donc une approche "hybride", mais simple, en détectant d’un côté la bonne méthode à utiliser, et en l’appliqant simplement dans queue.php :
  - Sur le site "privé", exécutée par exemple une fois par session d’un rédacteur, par appel asynchrone via une background image (pour ne pas ralentir le rédacteur), une fonction toute simple qui essaie de se connecter sur l’url cron, successivement avec les différentes méthodes (fsockopen, curl, pourquoi pas fopen directement qui accepte aussi les urls..., et 36 nouvelles méthodes qui apparaitront à l’avenir). Cette fonction détermine la méthode la plus rapide (qui pourrait très bien être fsockopen sur beaucoup d’hébergeurs !) par simple comparaison et stocke ce résultat dans une variable quelque part dans le site. Elle peut aussi déterminer que même si cela marche, les délais introduits (>100ms par exemple) ne justifient pas se passer de la technique de l’image background.
  - quand le code de queue.php, on "n’essaie pas des méthodes jusqu’à en trouver une qui fonctionne en perdant du temps sur le dos du client", mais on utilise la méthode récupérée dans la variable avec un switch par exemple, et on est sûr d’utiliser la meilleure méthode :-) et la meilleure !

• ffmpeg memory leak in the avcodec_open2 method

  21 août 2019, par unresolved_external

  I’ve developed an application which handles live video stream. The problem is that it should run as a service and over time I am noticing some memory increase. When I check the application with valgrind - it did not find any leak related issues.
  So I’ve check it with google profile tools. This is a result(substracting the one of the first dumps from the latest) after approximately 6 hour run :

     30.0  35.7%  35.7%     30.0  35.7% av_malloc
  
      28.9  34.4%  70.2%     28.9  34.4% av_reallocp
  
      24.5  29.2%  99.4%     24.5  29.2% x264_malloc

  When I check the memory on the graph I see, that these allocations are related to avcodec_open2. The client code is :

  `           g_EncoderMutex.lock();
  
              ffmpeg_encoder_start(OutFileName.c_str(), AV_CODEC_ID_H264, m_FPS, width, height);
  
              for (pts = 0; pts < VideoImages.size(); pts++) {                
  
                  m_frame->pts = pts;
  
                  ffmpeg_encoder_encode_frame(VideoImages[pts].RGBimage[0]);
  
              }
  
              ffmpeg_encoder_finish();
  
              g_EncoderMutex.unlock()

  The ffmpeg_encoder_start method is :

   void VideoEncoder::ffmpeg_encoder_start(const char *filename, int codec_id, int fps, int width, int height)
  
          {
  
              int ret;
  
              m_FPS=fps;
  
              AVOutputFormat * fmt = av_guess_format(filename, NULL, NULL);
  
              m_oc = NULL;
  
              avformat_alloc_output_context2(&m_oc, NULL, NULL, filename);
  
  
  
              m_stream = avformat_new_stream(m_oc, 0);
  
              AVCodec *codec=NULL;
  
  
  
              codec =  avcodec_find_encoder(codec_id);    
  
              if (!codec) 
  
              {
  
                  fprintf(stderr, "Codec not found\n");
  
                  return; //-1
  
              }
  
  
  
              m_c=m_stream->codec;
  
  
  
              avcodec_get_context_defaults3(m_c, codec);
  
  
  
              m_c->bit_rate = 400000;
  
              m_c->width = width;
  
              m_c->height = height;
  
              m_c->time_base.num = 1;
  
              m_c->time_base.den = m_FPS;
  
              m_c->gop_size = 10;
  
              m_c->max_b_frames = 1;
  
              m_c->pix_fmt = AV_PIX_FMT_YUV420P;
  
              if (codec_id == AV_CODEC_ID_H264)
  
                  av_opt_set(m_c->priv_data, "preset", "ultrafast", 0);
  
  
  
              if (m_oc->oformat->flags & AVFMT_GLOBALHEADER) 
  
                  m_c->flags |= AV_CODEC_FLAG_GLOBAL_HEADER;
  
              avcodec_open2( m_c, codec, NULL );
  
  
  
              m_stream->time_base=(AVRational){1, m_FPS};
  
  
  
              if (avio_open(&m_oc->pb, filename, AVIO_FLAG_WRITE) < 0)
  
              {
  
                  printf( "Could not open '%s'\n", filename);
  
                  exit(1);
  
              }            
  
  
  
              avformat_write_header(m_oc, NULL);
  
              m_frame = av_frame_alloc();
  
              if (!m_frame) {
  
                  printf( "Could not allocate video frame\n");
  
                  exit(1);
  
              }
  
              m_frame->format = m_c->pix_fmt;
  
              m_frame->width  = m_c->width;
  
              m_frame->height = m_c->height;
  
              ret = av_image_alloc(m_frame->data, m_frame->linesize, m_c->width, m_c->height, m_c->pix_fmt, 32);
  
              if (ret < 0) {
  
                  printf("Could not allocate raw picture buffer\n");
  
                  exit(1);
  
              }
  
          }

  The ffmpeg_encoder_encode_frame is :

  void VideoEncoder::ffmpeg_encoder_encode_frame(uint8_t *rgb) 
  
  {
  
      int ret, got_output;
  
      ffmpeg_encoder_set_frame_yuv_from_rgb(rgb);
  
      av_init_packet(&m_pkt);
  
      m_pkt.data = NULL;
  
      m_pkt.size = 0;
  
  
  
      ret = avcodec_encode_video2(m_c, &m_pkt, m_frame, &got_output);
  
      if (ret < 0) {
  
          printf("Error encoding frame\n");
  
          exit(1);
  
      }
  
      if (got_output) 
  
      {
  
  
  
           av_packet_rescale_ts(&m_pkt,
  
                          (AVRational){1, m_FPS}, m_stream->time_base);
  
          m_pkt.stream_index = m_stream->index;
  
          int ret = av_interleaved_write_frame(m_oc, &m_pkt);
  
  
  
          av_packet_unref(&m_pkt);
  
  
  
      }
  
  
  
  }

  ffmpeg_encoder_finish code is :

  void VideoEncoder::ffmpeg_encoder_finish(void) 
  
          {
  
              int got_output, ret;
  
  
  
              do {
  
  
  
                  ret = avcodec_encode_video2(m_c, &m_pkt, NULL, &got_output);
  
                  if (ret < 0) {
  
                      printf( "Error encoding frame\n");
  
                      exit(1);
  
                  }
  
                  if (got_output) {
  
  
  
                      av_packet_rescale_ts(&m_pkt,
  
                                  (AVRational){1, m_FPS}, m_stream->time_base);
  
                      m_pkt.stream_index = m_stream->index;
  
                      int ret = av_interleaved_write_frame(m_oc, &m_pkt);
  
  
  
                      av_packet_unref(&m_pkt);
  
                  }
  
              } while (got_output);
  
  
  
              av_write_trailer(m_oc);
  
              avio_closep(&m_oc->pb);
  
  
  
              avformat_free_context(m_oc);
  
  
  
              av_freep(&m_frame->data[0]);
  
              av_frame_free(&m_frame);
  
  
  
              av_packet_unref(&m_pkt);
  
              sws_freeContext(m_sws_context);
  
          }

  This code runs multiple times in the loop.
  So my question is - what am I doing wrong ? maybe ffmpeg is using some kind of internal buffering ? If so, how to disable it ? Because such an increase in memory usage is unacceptable at all.