Recherche avancée

Sur d’autres sites (6002)

• 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

• The neutering of Google Code-In 2011

  23 octobre 2011, par Dark Shikari — development, GCI, google, x264

  Posting this from the Google Summer of Code Mentor Summit, at a session about Google Code-In !

  Google Code-In is the most innovative open-source program I’ve ever seen. It provided a way for students who had never done open source — or never even done programming — to get involved in open source work. It made it easy for people who weren’t sure of their ability, who didn’t know whether they could do open source, to get involved and realize that yes, they too could do amazing work — whether code useful to millions of people, documentation to make the code useful, translations to make it accessible, and more. Hundreds of students had a great experience, learned new things, and many stayed around in open source projects afterwards because they enjoyed it so much !

  x264 benefitted greatly from Google Code-In. Most of the high bit depth assembly code was written through GCI — literally man-weeks of work by an professional developer, done by high-schoolers who had never written assembly before ! Furthermore, we got loads of bugs fixed in ffmpeg/libav, a regression test tool, and more. And best of all, we gained a new developer : Daniel Kang, who is now a student at MIT, an x264 and libav developer, and has gotten paid work applying the skills he learned in Google Code-In !

  Some students in GCI complained about the system being “unfair”. Task difficulties were inconsistent and there were many ways to game the system to get lots of points. Some people complained about Daniel — he was completing a staggering number of tasks, so they must be too easy. Yet many of the other students considered these tasks too hard. I mean, I’m asking high school students to write hundreds of lines of complicated assembly code in one of the world’s most complicated instruction sets, and optimize it to meet extremely strict code-review standards ! Of course, there may have been valid complaints about other projects : I did hear from many students talking about gaming the system and finding the easiest, most “profitable” tasks. Though, with the payout capped at $500, the only prize for gaming the system is a high rank on the points list.

  According to people at the session, in an effort to make GCI more “fair”, Google has decided to change the system. There are two big changes they’re making.

  Firstly, Google is requiring projects to submit tasks on only two dates : the start, and the halfway point. But in Google Code-In, we certainly had no idea at the start what types of tasks would be the most popular — or new ideas that came up over time. Often students would come up with ideas for tasks, which we could then add ! A waterfall-style plan-everything-in-advance model does not work for real-world coding. The halfway point addition may solve this somewhat, but this is still going to dramatically reduce the number of ideas that can be proposed as tasks.

  Secondly, Google is requiring projects to submit at least 5 tasks of each category just to apply. Quality assurance, translation, documentation, coding, outreach, training, user interface, and research. For large projects like Gnome, this is easy : they can certainly come up with 5 for each on such a large, general project. But often for a small, focused project, some of these are completely irrelevant. This rules out a huge number of smaller projects that just don’t have relevant work in all these categories. x264 may be saved here : as we work under the Videolan umbrella, we’ll likely be able to fudge enough tasks from Videolan to cover the gaps. But for hundreds of other organizations, they are going to be out of luck. It would make more sense to require, say, 5 out of 8 of the categories, to allow some flexibility, while still encouraging interesting non-coding tasks.

  For example, what’s “user interface” for a software library with a stable API, say, a libc ? Can you make 5 tasks out of it that are actually useful ?

  If x264 applied on its own, could you come up with 5 real, meaningful tasks in each category for it ? It might be possible, but it’d require a lot of stretching.

  How many smaller or more-focused projects do you think are going to give up and not apply because of this ?

  Is GCI supposed to be something for everyone, or just or Gnome, KDE, and other megaprojects ?

• Selecting a library / framework for video capture & recording

  21 décembre 2011, par Saurabh Gandhi

  In one of the project that we have undertaken we are looking for a video capture & recording library. Our groundwork (based on google search) shows that vlc (libvlc), ffmpeg (libavcodec) and gstreamer are the three popular free and open source libraries / multimedia frameworks available for the same. How do these libraries compare on the following parameters :

  1. Licensing policy to allow use within a commercial product without the need to open source any of the components of the product that is using the library
  2. Ability to be used effectively in a multi-threaded environment (library should be inherently thread-safe)
  3. Easy to use and maintain
  4. Documentation : API should be well documented...this is relative... :)

  Our primary intention is to be able to capture RTSP video streams (H.264/MPEG-2/MJPEG encoded), convert these streams to raw video / frames so that it can be used for analysis / processing and later on compress these frames and store it on the disk in the form of an MP4 file (using MPEG2 / H.264 encoding).

  P.S. We understand that FFmpeg is also one of the components of vlc since vlc uses libavcodec library. Is the same true for gstreamer as well ? Does it have any ffmpeg dependency ?

  Awaiting your responses.

  Regards,

  Saurabh Gandhi