Пікірлер

• 
  @darkengine593117 сағат бұрын

  Our main rationale for abandoning object-oriented design (not entirely, but as the broad-level architectural design paradigm) was actually related to maintainability, flexibility, and above all else, ease of learning the system, not performance. We substantially improved the ease of learning and maintaining our codebase (millions of LOC) in ways all of our team members agreed, and some of us begrudgingly since most of us were taught to favor OOP in CompSci. One reason is that OOP creates a boatload of coupling with its inseparable bundling of functions and data: loose coupling between abstractions in well-designed cases, but a whole lot of it which means a new developer working in any corner of the system tends to have to learn substantially more (or even exponentially more) information than minimally required to perform their task. Consider the example of a physicist as a new member of the team implementing a physics engine (which he already knows how to do easily in isolation) into an object-oriented architecture. He might first need to learn about scene graphs. Since scene graphs serve a wide variety of needs (audio, lights, models, cameras, textures, motion hierarchies, etc), chances are that he will need to sift through a lot of information irrelevant to his needs to understand how to work with the scene graph interface, even in the best-case scenario where the scene graph interface is designed as generally and abstractly as possible. Yet to further understand scene graphs, he must first understand scene nodes. To understand scene nodes, he must understand channels and how they link together. To understand channels, he must understand variants. To understand how to create his own scene nodes and insert them to the scene graph, he must understand the abstract node factory. To understand the abstract node factory, he must understand node descriptors. To understand node descriptors, he must understand the difference between dynamic and static descriptors. To understand how to manipulate the motion of scene entities through his physics engine, he must understand transformation objects. To understand transformation objects, .... I can keep going and going but I'm sure others get my point of how overwhelming this can be, and this is how large-scale OO databases can end up requiring months of training a new team member with careful supervision before they can be free to confidently navigate the codebase even if their only task is to introduce new features and not even change any existing ones. At the end of the day, all a physics system needs to do is input motion data and either modify it (procedural) or output new motion data (functional). This simplicity is something that we can very rapidly lose sight of if our primary paradigm for the broad-level design of a system is object-oriented. All a software does at the end of the day -- down to its individual functions -- is input/output or modify data. When we leave the data open rather closed in the codebase, all the physics programmer needs to learn is the barebones way to receive/access the motion data required to apply physics to entities. I'm sure people can already imagine how much simpler this can be with careful procedural or functional design (we favor functional). He can begin implementing his system from day one with almost zero training this way. However, we admittedly lost the immediacy of maintaining invariants (or data integrity) at the immediate level of individual objects (ex: making sure a numeric data field intended to represent a quantity is never set to/initialized with a negative value). Yet that validation can be done en masse across broad phases of processing, such as performing a data integrity test after every major system has performed its data transformations for debug builds on top of writing unit/integration tests. Doing this at the broad level also tends to shrink the amount of test code (runtime assertions) to a tiny fraction compared to encapsulated OOP. The way to keep it manageable and avoid getting tangled up losing track of what parts of the codebase are accessing what is to think at the broader of "systems" or "engines" instead of individual functions: build a hierarchy of data-transforming functions which, at the root level, add up to something like a "physics system" or "audio system" or "input system" with an organized and singular entry point so that we don't have to think of the data transformations of a physics system individually in terms of the 200 functions which comprise it. We shouldn't require too many of such broad entry points, and it should be very easy to reason about exactly what data each broad system is transforming if we design the systems carefully and collaborate with the team to document what central data each major system is transforming. This is primarily how we document and collaborate. I have next to zero knowledge of how our physics engine works (I work on rendering graphics), and understanding it requires PhD-level domain expertise of papers which recursively reference many other papers, yet all of us on the team know that our physics system just inputs motion data and outputs new motion data (which is bundled into motion component structs). It's the only system that does besides the animation system, so if there's something wrong with the shared motion data at any stage in processing, we know it's either the animation or physics system that contains the programmer mistake. This is the main way we admittedly have to be careful in our designs and collaboration is with respect to data-oriented organization and documentation, since the data is no longer owned and hidden by individual objects: it's openly shared across systems. Some might point out that this type of organization of systems and their functions is still working towards something resembling objects, and we do even use C++ classes to define them just for organization sake, yet the difference is that the physics system doesn't receive objects (in the OOP sense, not the C++ sense) as input or mutate its state (member variables). Instead it inputs raw motion data and outputs raw motion data, as with the case of the animation system which always inputs raw motion data and outputs raw motion data. Object-oriented design would want to assign ownership of the data and make it hidden in one of these two systems or a third one (or a generalized motion object), and that's when we start working towards a whole lot more coupling between interfaces. Favoring a separation of data from the functionality that transforms it substantially decouples the entire codebase.

• 
  @jogra19895 күн бұрын

  This is really great stuff! Is there an open source implementation of type-safe-matrix or the compile-time-sparse-matrix available?

• 
  @alexeysubbota13 күн бұрын

  What is the talk about?

• 
  @MeetingCPP13 күн бұрын

  About progressive C++. But its a keynote, so not like a normal talk covering just one topic.

• 
  @alexey10416 күн бұрын

  Dear Rainer, you are such an inspiring person, I've learned so much from your excellent talks, blogs and books! I wish you all the best and hope you get better soon.

• 
  @thisisnotchaotic198822 күн бұрын

  I think there is a flaw with this design. Since the spmc queue supports variable-length messages, if a consumer is lapped by the consumer, the mVersion field the consumer thinks it is spinning on is probably not the version counter field at all. It may well be spinning on some random bytes right in the middle of mData. Then if the random bytes happen to be the version of the consumer is expecting(although the probability is very low), it could be disastrous. The customer does not know it is lapped at all, and continue processing with the meaningless data.

• 
  @helium7327 күн бұрын

  What ends up happening is that people explain the easy stuff with very simple clear language and they really break it down. But with the advanced stuff they prefer to believe you already know everything. I've been able to use Make to make compilation easier but CMake is really complex. It looks like it's got it's own language. A basic tutorial might include using CMake to write hello world then have it compile a very basic C hello world project with minimal Cmake files

• 
  @MeetingCPP26 күн бұрын

  Yes, CMake is complex. I personally favor using a generator to get the project started and did a talk about this in spring: kzread.info/dash/bejne/ZX-grqmHn5jInpM.html

• 
  @wolpumba4099Ай бұрын

  *Abstract* This video explores C++20's coroutines, comparing them to traditional functions and highlighting their unique ability to preserve state and be resumed. The speaker delves into the key components of coroutines, including the promise type, awaiter type, and iterator, showcasing their customization potential. Through practical examples like interleaving data streams and task scheduling, the video demonstrates the power of coroutines in simplifying code and achieving efficient concurrency. *Speaker Introduction* * *0:00* Andreas Fertig, a C++ trainer and consultant, introduces himself and the topic of his talk: C++20 coroutines for beginners. * *0:37* Fertig explains the meaning and origin of his last name, highlighting the challenges of spellcheckers recognizing it as a proper noun. *Understanding Coroutines* * *2:35* Fertig differentiates coroutines from traditional functions by emphasizing the ability of coroutines to be resumed and preserve their state through `co_yield`, `co_await`, and `co_return` keywords. * *3:00* He illustrates the control flow of functions and coroutines, showcasing the resumable nature of the latter. * *6:14* He clarifies that coroutines are a superset of functions, with functions being a specialization of coroutines that do not pause. * *7:21* Fertig explains the distinction between stackful and stackless coroutines, noting that C++ implements stackless coroutines where state is stored on the heap. * *8:39* He introduces the concept of cooperative multitasking, where threads decide when to yield control, contrasting it with preemptive multitasking used in `std::thread`. *Coroutine Elements and Customization* * *11:50* Fertig details the key elements of a C++ coroutine: the return type (awaiter type), the promise type, the awaitable type (optional), and the iterator (optional). * *13:32* He emphasizes the role of the promise type in customizing coroutine behavior through various customization points like `get_return_object`, `initial_suspend`, `yield_value`, `await_transform`, `final_suspend`, and `return_value`. *Coroutine Examples* * *17:56* *Example: A Basic Chat Coroutine:* Fertig showcases a simple chat coroutine demonstrating the use of `co_yield`, `co_await`, and `co_return`, along with the implementation of the promise and return types. * *35:19* *Example: Interleaving Data with Coroutines:* He presents a coroutine that interleaves elements from two `std::vector` objects, highlighting the use of an iterator to enable range-based for loops for more readable code. * *46:12* *Example: Cooperative Task Scheduling:* Fertig demonstrates a coroutine-based scheduler that manages multiple tasks cooperatively, contrasting it with preemptive multitasking using threads. *Coroutine Restrictions and Limitations* * *56:21* Fertig outlines several restrictions on coroutines, including their incompatibility with `constexpr`, `consteval`, constructors, destructors, `varargs`, plain `auto` return types, concept return types, and the `main` function. *Q&A Session* * *1:00:01* *C++23 and Coroutines:* The discussion touches upon the `std::generator` introduced in C++23, its limitations, and the challenges of creating a universal library type for coroutines due to their flexibility. * *1:02:06* *Parallelism and Coroutines:* Fertig clarifies that coroutines do not inherently run in parallel but offer efficient concurrency through cooperative multitasking. He emphasizes the possibility of combining coroutines with `std::thread` for more complex scenarios. * *1:03:56* *Coroutine Depth and Heap Usage:* He confirms that the depth of coroutine chains is practically limited only by available heap memory. * *1:07:51* *Coroutine Preemption:* Fertig reiterates that coroutines are not preemptible and require careful design to avoid long-running tasks that block other coroutines. * *1:08:47* *Coroutines and Boost.Asio:* He suggests that the upcoming C++26 `sender/receiver` feature might be a better fit for Boost.Asio integration than coroutines. * *1:16:05* *Typical Use Cases:* Fertig highlights callback replacement and event handling as common scenarios where coroutines excel. * *1:21:04* *Coroutines in Embedded Systems:* He clarifies that coroutines do not require special OS support, making them suitable for embedded systems with limited resources. The primary requirement is heap access for storing coroutine state. * *1:23:12* *Stackful Coroutines in C++:* Fertig acknowledges the possibility of introducing stackful coroutines in the future if their benefits are clearly demonstrated. * *1:23:51* *Allocator Awareness:* While coroutines are not directly allocator-aware, they can utilize custom allocators through overloading `operator new` and `operator delete` in the promise type. i used gemini 1.5 pro Token count 19,459 / 1,048,576

• 
  @WildlifeAnimalsfulАй бұрын

  where are conference materials published, e.g. codes?

• 
  @MeetingCPPАй бұрын

  You can find the slides - which speakers have uploaded - under slides.meetingcpp.com Otherwise reach out to the speakers.

• 
  @ovrskrАй бұрын

  if it's not broken, don't fix it. now there's so many ways to import and the build system is a mess -_-

• 
  @muratsahin1975Ай бұрын

  So, adding new draw or serialize overloads for new ShapeConcepts just really needed? Maybe it should also be included to implementation details of the Shape with a templated version.

• 
  @danadam0Ай бұрын

  36:07 I may be mistaken, but I think currently such reinterpret_cast from buffer.data() is technically an UB unless std::launder() is used. Technically, because apparently popular compilers don't require std::launder() in this case. See P3006R0 "Launder less".

• 
  @framm7032 ай бұрын

  Cool

• 
  @shaulfridman44442 ай бұрын

  Great talk, thanks 🙏

• 
  @danialtoor29582 ай бұрын

  so is c++ worth learning hm.

• 
  @MeetingCPP2 ай бұрын

  Yes, I think it is. Its in wide use and the committee releases a new version every 3 years. So some changes and modernization is coming to C++ for sure.

• 
  @danialtoor29582 ай бұрын

  @@MeetingCPP I think that's great. However, I am often see job postings for other languages, such as C-sharp or Java or Javascript..... way more than c++

• 
  @MeetingCPP2 ай бұрын

  Sure, other languages also have open positions. It also often depends on in which area you like to live and in what industry you'd like to work. Performance critical code and embedded are often using C++.

• 
  @danialtoor29582 ай бұрын

  @@MeetingCPP this is the same thing every cpp person says.... like by and large cpp is much less popular than the current web dev languages. C# Java and Javascript dominate the market... yes you can still be a devils advocate.. but it's such a cop out to say "well it depends on location.." nowhere in the USA is cpp being used than any of the above languages. I am talking about the entire industry, not just the handpicked ones where cpp is used

• 
  @MeetingCPP2 ай бұрын

  Because its true from the C++ perspective. Its not a popularity contest. There is easier languages to learn, one has to make a decision in which field one wants to make a career. C++ is surely not for everyone.

• 
  @toncikokan96982 ай бұрын

  Tehnically, "probability zero" doesn't imply "impossible".

• 
  @TNothingFree2 ай бұрын

  37:05 - Interesting Example. I taught my students that in C# the Random class actually took the time, so in order to make it work you need to initialize an instance and reuse the same instance. Or else you'll be getting bugs because it generates the same number.

• 
  @IvanBudiselic2 ай бұрын

  Great talk! Well done, and thank you!

• 
  @SimonToth832 ай бұрын

  Write a thick client, write your own serializers, implement custom schema publishing... Hmm, I wonder what features from gRPC are actually there after all this and what is even the point of using such a heavy-duty library in this context. And yes, I am genuinely curious.

• 
  @wolpumba40992 ай бұрын

  *Abstract* This presentation explores gRPC, a modern Remote Procedure Call (RPC) framework designed for high-performance distributed systems. It begins with an overview of gRPC's features, including cross-platform support, load balancing, and authentication. The presentation then delves into Protobuf, the language-neutral serialization mechanism commonly used with gRPC. The core of the presentation covers both the standard approach to using gRPC and a novel alternative. The standard approach involves defining services in `.proto` files, generating code, and directly using gRPC's service APIs. The alternative approach introduces a custom library called 'mygrpc,' which wraps gRPC and Protobuf. This library simplifies development by: * *Hiding gRPC and Protobuf Internals:* Users interact with custom APIs, not raw gRPC or Protobuf. * *Providing Generic Services:* A single generic service definition replaces complex `.proto` files. * *Streamlining RPC Calls:* The library handles reactors, message chunking, and data serialization. The presentation concludes with a summary of the benefits and drawbacks of this alternative approach, noting increased flexibility and cleaner code, but also the overhead of maintaining custom serializers. *Keywords:* gRPC, Protobuf, RPC, Remote Procedure Calls, distributed systems, serialization, C++

• 
  @wolpumba40992 ай бұрын

  *Summary* *Introduction* * *0:00* Introduction to gRPC for distributed systems with C++. * *3:00* Overview of gRPC features (modern, cross-platform, etc.). * *3:39* Introduction to Protobuf for serialization with gRPC. *Standard gRPC Usage* * *9:11* Standard approach: Defining services in `.proto` files. * *9:20* Example of a restaurant order service. * *12:37* Code generation for data models and service APIs. *New Approach: Wrapping gRPC and Protobuf* * *23:32* Introduction to the 'mygrpc' library for simplified gRPC development. * *23:40* Key changes in the new approach: * *23:40* Protobuf definitions are moved into 'mygrpc'. * *23:54* Generic services replace complex `.proto` files. * *24:01* Users interact with custom APIs, not gRPC/Protobuf directly. *'mygrpc' Components* * *25:50* Library components overview: * *Internal:* `mygrpcGenericService`, handlers, reactors. * *Exposed:* `myRequest`/`myResponse`, Server, `myService` base class, `myStub`. *Service Methods in 'mygrpc'* * *27:34* Methods use `std::iostream` for data exchange. * *27:45* Library handles message chunking and streams. * *30:34* Server-side: User services inherit from `myService`, binding methods to standard functions. *Benefits of the New Approach* * *23:54* Removes direct gRPC/Protobuf dependencies. * *27:21* Cleaner code and intuitive client-side APIs. * *28:03* Potential for advanced features built on top of gRPC. *Drawbacks* * *34:00* Requires custom serializers for existing data models. * *25:22* C++ only; no automatic multi-language support. Disclaimer: I used gemini ultra 1.0 (2024.02.21) to summarize the video transcript. This method may make mistakes in recognizing words and it can't distinguish between speakers.

• 
  @friedrichdergroe96642 ай бұрын

  Massively Cool.

• 
  @TheOnlyAndreySotnikov2 ай бұрын

  7:48 Interfaces must always be non-virtual, even if we use good old inheritance-based runtime polymorphism.

• 
  @MalcolmParsons2 ай бұрын

  Defining operator == is still useful when also defining operator <=> because operator == (and operator !=) can return early when 2 containers don't have the same size.

• 
  @fwopkins2 ай бұрын

  6:30 what a brilliant illustration of time travel debugging by time travelling through his presentation. 🥇

• 
  @aniketbisht28232 ай бұрын

  std::memcpy is not data-race safe as per the standard. you could use std::atomic_ref<std::byte> to read/wrie individual bytes of the object.

• 
  @billionai48712 ай бұрын

  Hah, what a coincidence! Early this month i JUST gave a talk on FOSDEM about the internal workings of GDB's inbuilt time travel debugging and how we're taking baby steps in improving it On an interesting note, the hardware watchpoint was fixed recently, and will no longe be a bug in GDB 15 :)

• 
  @nhanNguyen-wo8fy2 ай бұрын

  23:35 24:00 monitor builder 24.35 monitor 27:18

• 
  @saturdaysequalsyouth2 ай бұрын

  Ubuntu 20.04 has some different configuration which makes following this example very difficult. I didn't get the same crash reason the presenter got. Ubuntu 20.04 has some stack protection. "*** stack smashing detected ***: terminated"

• 
  @blowfishfugu42302 ай бұрын

  ok, after the joy of minute 58, i'll stay on std::partition to prefilter.

• 
  @marsob90382 ай бұрын

  does this apply also to userland(green) threads - like in boost fiber ?

• 
  @fernandoiglesiasg2 ай бұрын

  With all due respect , following-up the other comments, it might look like there are some old-school developers a bit grumpy to have to learn stuff. Regarding the logic of the talk, I can’t follow along why (1) begin MUST be O(1) generally, even more when taking into that there was something special with fwdlist before ranges already, (2) why begin in a view must have the same semantics than in a container. In other words, if one is applying a filter to a collection and then surprised that it needs to iterate through it… 🤷🏻‍♂️ In any case, excellent talk from Nico as usual, top learning material. It is essential to make these parts also visible and talk about them.

• 
  @RudMerriam2 ай бұрын

  As alway Klaus provides an interesting approach for C++ development. 😀

• 
  @wolpumba40993 ай бұрын

  Abstract: Test-Driven Development (TDD) has been acknowledged for its effectiveness in reducing development time and error rates, leading to widespread adoption in many C++ projects. However, its application in embedded C++ development, especially those involving microcontrollers with significant hardware dependence, presents unique challenges. At the Meeting C++ 2023, Daniel Penning addresses the obstacles and opportunities for integrating TDD in microcontroller-based development. The talk delves into the dual-target approach, advocated by James Grenning, which recommends running unit tests both on microcontrollers (On Target) and personal computers (Off Target). Despite its advantages, this method reveals limitations when dealing with hardware-related code such as drivers. Penning introduces open loop testing to complement dual targeting, an innovative method where external microcontroller interfaces are mimicked using mocks and stubs. This methodology facilitates a practical TDD workflow that enables developers to reap the full benefits of TDD in their microcontroller development process. The talk not only illustrates how the dual-target approach can be built using open source solutions but also compares the additional advantages provided by commercial alternatives. It also touches upon the significance of TDD in embedded development, emphasizing the need for quick, automated feedback loops essential for TDD efficacy. Demonstrations within the presentation showcase the implementation of open loop testing, using a Robot Framework to script tests at the pin level for direct hardware interaction. Penning provides a thorough analysis of the nuances in off-target and on-target testing, detailing their respective limitations and how open loop testing fills the gaps for a comprehensive TDD practice. Finally, the session concludes with an insightful Q&A that explores related topics such as hardware verification, functional safety, and integration testing, and discusses industry trends in hardware abstraction layer and driver development. This presentation serves as a crucial guide for software engineers and project managers in embedded systems looking to refine their development practices with TDD, improving their product quality and reliability in a domain where traditional testing methods often fall short. Chapter Titles I. Fundamentals of TDD in Embedded Systems - 00:00 Introduction to TDD and Embedded Software Development - 01:59 The Importance and Challenges of TDD in Embedded Systems II. Testing Strategies for Embedded Software - 04:22 Testing Embedded Software Off-Target vs. On-Target - 07:26 Establishing Off Target Testing in Embedded Development - 11:41 Limitations and Risks of Off Target Testing - 14:33 Testing Hardware Dependent Code - 15:34 On Target Testing III. Advanced Testing Techniques and Tools - 17:09 State-of-the-Art in Testing: Pin Behavior - 19:13 Challenges with Manual and Register-Based Testing - 25:06 Open Loop Testing: A New Approach - 28:00 Demonstration of Open Loop Testing IV. Practical Application and Case Studies - 31:09 Configuration and Initial Test - 33:10 Multiple Byte Reception and Hardware Interaction - 35:19 Implementation Adjustments and Debugging V. Summation and Addressing Complex Testing Scenarios - 39:01 Summary and QA Session - 45:12 Concerning Emulation and Real-Time Testing - 47:50 Challenges in Hardware Verification VI. Ensuring Functional Safety and System Integration - 48:35 Functional Safety and Testing Approaches - 50:15 Integration Testing and Developer Feedback - 51:34 Hardware Abstraction Layer and Driver Development VII. Closing Remarks - 53:15 Conclusion

• 
  @dgkimpton3 ай бұрын

  Depressing is the only way to describe this. We've waited so long for ranges because they would make it so much harder to make programming errors, and instead they've gone and made it more likely to make errors. It's a shame they didn't make the easy case easy and the complex case possible and instead made the easy (common) case hard and the complex (rare) case easy. The only safe way to teach this is the simple "don't use ranges", which sucks.

• 
  @NielsGx3 ай бұрын

  So that's how these "script extender" DLL mods for some games work, interesting SKSE for Skyrim, BG3se for Baldur's Gate 3, CET for CP2077, ... sadly these are never available on Linux/MacOS I guess there's no DLL there I'll never get NativeCameraTweaks on BG3 MacOS version, rip

• 
  @valshaped2 ай бұрын

  Linux has .so ("shared object") files, which are equivalent. You can tell the linker to link arbitrary .so files into any program, as well. It won't do anything if the program never calls those functions, but it's a thing you can do

• 
  @SimonToth833 ай бұрын

  I would agree with the "prefer std::ranges over std::", however, there is std::ranges::less (and the other suite of comparators), which you definitely shouldn't use, and you should use C++14 deducing versions of std::less (and the rest of the comparators).

• 
  @sirhenrystalwart83033 ай бұрын

  That was depressing. Today I learned that ranges are a completely broken feature. It's so frustrating listening to others justify all the undefined behavior in the standard. They make it sound like it's necessary to not suffer undue performance loss on various platforms, but clauses like the one shown at 46:55 show how ridiculous that excuse is. We have to stop adding broken features into c++. And then we turn around and wonder why rust is gaining traction...

• 
  @paulmccartney23273 ай бұрын

  Who is "we" lmao

• 
  @wolpumba40993 ай бұрын

  *Abstract* While C++20's filter view offers a powerful way to process data, its design compromises usability and can lead to surprising errors. This presentation reveals the internal mechanisms of views, explaining how cached 'begin' operations limit const correctness and create unexpected issues like runtime errors or undefined behavior. The 'filter' view, in particular, presents challenges due to its differing behavior on temporary and non-temporary objects. The speaker explores the trade-offs made in filter view design, raises concerns about broken const protection, and highlights the pitfalls developers need to be aware of. The presentation also critiques the C++ Standard Committee's decisions, advocating for changes to mitigate these problems. *Key Points* - *Issues with Filter Views:* Filter views can lead to unpredictable behavior and errors due to cached 'begin' operations and inconsistent const propagation. - *Broken Const Correctness:* Design decisions in filter views make it difficult to maintain const correctness, causing unexpected risks and undefined behavior. - *Internal Design Limitations:* View design, particularly around caching, imposes constraints on view usage, which may conflict with common coding practices. - *Standard Committee Debate:* There appears to be internal debate and disagreement within the C++ Standard Committee on how to address these problems. - *Call for User Feedback:* The presenter encourages viewers to provide feedback and bug reports to help facilitate a fix to these issues within the C++ standard. *Chapter Titles* *Chapter 1: Introduction to C++ Views* - 0:00 Introduction to C++ Views - 1:11 Basics of Using Views - 3:41 More Examples of C++ Views *Chapter 2: How Views Work* - 6:04 Understanding How Views Work - 9:23 Internal Structure of Views - 11:00 Iteration and Value Creation with Views - 14:30 Important Considerations *Chapter 3: Views and Performance* - 15:52 C++ Views Performance - 17:02 Performance Considerations with Views - 17:35 Performance Differences: Drop View - 19:44 Performance Differences: Filter View - 21:38 The Standard Template Library and Performance - 22:42 API Choices for Views *Chapter 4: Challenges and Pitfalls* - 28:18 Performance Constraints and Solutions - 31:04 Caching Mechanisms in C++ Views - 33:39 Caching of 'begin' with Cost Implications - 37:10 Consequences of Caching of 'begin' - 39:37 Workarounds and Issues - 44:39 Issues with a 'filter' View Example - 49:02 More Problems with a 'drop' View Example *Chapter 5: The 'filter' View Controversy* - 51:22 Broken 'const' Protection, Caching, and Design Concerns - 52:58 Understanding the 'filter' View - 55:14 Problematic Consequences of View Design - 56:47 How to (Not) Use a 'filter' View - 58:07 Lingering Consequences and Frustrations - 59:59 Call to Action *Summary* *Introduction to C++ Views* - 0:02 Introduction to C++ views technology. - 0:15 Discussion of important things to know about views. - 0:38 Focus on the filter view and its appropriate use. *Basics of Using Views* - 1:11 Example of a vector container. - 1:24 Example of set container. - 1:37 Introduction to generic print function - 2:03 Using Auto with constraints for generic code. - 2:19 Examples of the `take` view. - 2:42 Using pipelines for cleaner view syntax. - 3:16 `transform` view in combination with filter. *More Examples of C++ Views* - 3:41 Views offer a powerful way to process data. - 3:47 Example using a map to store key-value pairs. - 4:19 Filtering values within a map structure. - 5:23 `iota` view provides generated number sequences. *Understanding How Views Work* - 6:04 The importance of understanding internal mechanisms - 6:10 Views differ fundamentally from Unix pipes. - 6:17 Container iteration based on the begin/end interface. - 7:28 Range-based for loop leverages this container interface. - 8:05 Applying the same interface to views. - 8:19 Example of filter and transformation views. *Internal Structure of Views* - 9:23 Pipelines are syntactic sugar on nested view applications. - 9:28 Views don't generate elements upfront, focus on processing description. - 9:54 Views form a wrapper-like data structure. - 10:47 Iteration remains consistent but uses the view’s begin/end *Iteration and Value Creation with Views* - 11:00 Value creation and printing occur during iteration. - 11:15 Example of a view's begin call cascading down. - 12:07 The filter view may skip multiple elements. - 12:44 Filter views require both position and value, impacting cost. - 13:45 Cascading calls from star (to access value) through the views. - 14:10 Transformations act on values when accessed. *Important Considerations* - 14:30 Performance impact of filter view's begin operation. - 15:06 The begin operation cost depends on the underlying data structure. *C++ Views Performance* - 15:52 Discussion on how value transformations impact iterations. - 16:07 Example of how the filter view handles values that don't fit the criteria. - 16:35 The end iterator returned by a view signals completion. *Performance Considerations with Views*

• 
  @XDjUanZInHO3 ай бұрын

  The nordic shorts dude codes????

• 
  @LeDabe3 ай бұрын

  Yes.

• 
  @VincentZalzal3 ай бұрын

  I have limited experience with ranges, but I think I agree that views would be better off without caching. As a counter-argument to the committee for the case where a view is used twice, could we use the same subrange trick to eagerly compute begin instead of caching? I.e. in the rare case you want to re-use a view twice and want to cache begin, do it manually by wrapping your view in a subrange? I think it would be easier to teach too.

• 
  @Roibarkan3 ай бұрын

  I think the committee is concerned about “how should people write generic code” - if someone writes a template function that receives some range, and doesn’t know if it’s a filter_view (won’t know if begin() is cheap), they won’t know whether to wrap it win a subrange (and always wrapping in a subrange seems expensive). I believe there are/were suggestions to add something like “cache1” which acts like a subrange-wrapper if needed, and does nothing otherwise. I personally like the alternative Nico describes in slide 35 (use view by value and the all_view for containers- but it still might hit the jthread race condition if a reference is passed to the jthread)

• 
  @sddndsiduae4b-6883 ай бұрын

  i think correct behavior is always calculate begin, i.e. subrange build in into operation, otherwise there is no point to actually create view, in very rare cases when view is created but not used(no element used) dead code elimination in compiler would do the job, anyway i better learn Rust.

• 
  @sadranezam33673 ай бұрын

  eagle burger lol

• 
  @Ch40zz3 ай бұрын

  Would've probably reverse engineered bejeweled instead of relying on image data but this seems more versatile for other games if you dont want to reverse them all. For the algorithm an improvement could be MinMax + AlphaBeta pruning but without knowing what stones move in next that becomes a much much smaller improvement. Can obviously reverse engineer that too :P

• 
  @dave_oleksy3 ай бұрын

  Brilliant!

• 
  @miroslavhoudek70853 ай бұрын

  I remember that my colleague was tasked to chose between CUDA and OpenCL some 10 years ago. He liked OpenCL much more, because it allowed him to run code on both cards. But then it turned out that AMD did not support running OpenCL headless, without X server running and screen connected. Also CUDA was slightly more consistent. And that's how OpenCL was removed from feasible standards. It's hard to get also the usability and reliability right, even if the idea is great, I guess.

• 
  @wolpumba40993 ай бұрын

  *Abstract* In the talk "A Smooth Introduction to SYCL for C++20 aficionados" at Meeting C++ 2023, Joel Falcou, an associate professor and co-founder of a C++ and HPC training company, delves into the challenges faced by developers in the era of performance-driven architectures such as GPUs and FPGAs. Addressing the need for efficient programming without compromising the elegance of C++20, Falcou introduces SYCL, an open standard for cross-platform programming that enables developers to target a variety of accelerators. The presentation provides insight into SYCL's compatibility with C++ syntax, its programming model, and how it facilitates device connection and management through 'queue' objects and memory management techniques. Additionally, Falcou outlines SYCL's support for hierarchical parallelism and its implementation in scientific computing, specifically particle physics. Falcou discusses the use of a custom C++20 library called Kiwaku, which is designed for multidimensional data storage and processing. The library leverages C++20 features and concepts to provide efficient execution contexts, data views, and algorithmic execution. The talk also touches on OneAPI's role as the implementation of SYCL used for the presentation and alternatives to Intel's implementation. Furthermore, Falcou emphasizes SYCL's ease of use, deployability, and forward-thinking approach to concepts and type handling. He concludes with remarks on SYCL's documentation, hardware support updates, and encourages the use of SYCL for working with accelerators. The talk ends with a discussion on device selection, fallback implementations, and CPU support, along with implementation recommendations for those getting started with SYCL. *Chapter Titles* *Chapter 1: Introduction to SYCL and Computing Paradigms* - 0:00 Introduction and Background - 1:24 Overview of Computing Challenges and Tools - 3:39 Introduction to SYCL (Pronounced 'sickle') - 6:06 OneAPI and Supporting Companies *Chapter 2: Understanding the SYCL Programming Model* - 7:48 Programming Model and Device Connection - 10:38 Device Selection and Queue Management - 14:22 Introduction to Shared Memory and Parallel Operations - 15:46 Synchronization and Memory Management *Chapter 3: Optimizing Memory Operations in SYCL* - 17:35 Improving Memory Operations with Buffers - 19:57 Automatic Data Transfer with Buffer Destruction *Chapter 4: Advanced Parallelism Techniques in SYCL* - 21:11 Leveraging Hierarchical Parallelism - 22:53 Implementing Algorithms with Hierarchical Parallelism - 24:51 Utilizing SYCL-based Parallel STL Implementation *Chapter 5: SYCL Applications in High-Performance Computing* - 26:00 Application in Scientific Computing - 28:16 Overview of Accelerated Computation in Particle Physics *Chapter 6: The Role of Custom C++ Libraries in Computational Efficiency* - 29:43 Advantages of a Custom C++ Library - 31:09 Utilizing C++20 Features and Concepts - 31:57 Data Views and Parametric Concepts - 33:40 Algorithmic Execution and Slicing Techniques *Chapter 7: Performance Considerations Across Different Hardware* - 35:38 Contexts and Performance on Different Hardware - 37:31 Flexibility and Extensibility of the Library - 39:00 Concluding Remarks on Acceleration APIs and the Future *Chapter 8: Compilation Aspects and Device Handling* - 42:22 Compilation Timing and Options - 45:08 Device Selection and Ranking - 48:04 Fallback Implementations and Targeting Specific Compilers - 49:53 CPU Support and SIMD Vectorization - 53:16 Decoding the Secret String and Implementation Recommendations

• 
  @wolpumba40993 ай бұрын

  *Summary* *Introduction and Background* - 00:00 Speaker introduces himself as an associate professor at a computer science lab near Paris and co-founder of Codon, a company focused on C++ and HPC training. - 00:30 His research includes parallel computing and creating interfaces and abstractions in C++. *Overview of Computing Challenges and Tools* - 01:24 Discussion on how increasing computer complexity and core numbers lead to challenges for developers in writing efficient code for various hardware systems. - 02:04 The difficulty lies in handling threads, vectorizing code, and now, thousands of cores in GPUs and reconfigurable systems. *Introduction to SYCL (Pronounced 'sickle')* - 03:29 SYCL is an open standard for writing C++ code that targets various computing systems like CPUs, GPUs, and FPGAs. - 04:14 It maintains proximity to regular C++ syntax and allows for more accessible reasoning about code and building around it. *OneAPI and Supporting Companies* - 06:06 OneAPI by Intel is mentioned as the implementation of SYCL used for their presentation, including various Intel-specific libraries and compilers. - 06:54 Alternatives to Intel's implementation, like Clang, which supports SYCL starting from version 50, are mentioned. *Programming Model and Device Connection* - 07:48 SYCL programming model compared to other GPU programming models, with differences highlighted in terms of verbosity and explicitness. - 09:30 Connection to a device using the 'queue' object is discussed, which acts as an intermediary for data and operation transfer between host and device. *Device Selection and Queue Management* - 10:38 Describes how developers can select devices based on properties or write custom logic to rank devices based on specific criteria. - 12:25 Explains the explicit nature of building queues and the flexibility to manage multiple queues and devices, all operating asynchronously. *Introduction to Shared Memory and Parallel Operations* - 14:22 Explains the concept of a shared memory block that is not the same as CUDA's shared memory. It's shared between CPU and device, not within the device. - 14:48 Describes initiating data transfer to the shared memory block and starting parallel operations using a queue. - 15:05 Discusses how C++ lambdas or callable objects can be used as kernel functions for parallel operations. *Synchronization and Memory Management* - 15:46 Details the process of waiting for the completion of parallel operations and the option to wait on the queue or an event object. - 16:12 Once operations are complete, the result is already in the shared memory, and it can be sent back to the system. *Improving Memory Operations with Buffers* - 17:35 Introduces the use of buffers and accessors to create a relationship between host and device memory for more efficient operations. - 18:49 Discusses the use of host accessors to read data back from the device to the CPU. - 19:07 Highlights the significance of accessor modifiers to infer task graph dependencies. *Automatic Data Transfer with Buffer Destruction* - 19:57 Describes how automatically transferring data back to the host is handled by scoping buffers and destroying them after computation is complete. *Leveraging Hierarchical Parallelism* - 21:11 Explores the concept of work groups and subgroups to exploit different levels of parallelism, which can improve performance on different hardware architectures. *Implementing Algorithms with Hierarchical Parallelism* - 22:53 Illustrates writing an algorithm using work groups and subgroups to perform parallel computations on a dataset. - 24:18 Describes how a regular C++ lambda function is transferred and executed on the device without additional complexity. *Utilizing SYCL-based Parallel STL Implementation* - 24:51 Examines the Parallel STL implementation by Kronos which uses SYCL-based execution policy to run algorithms on the GPU. *Application in Scientific Computing* - 26:00 Describes the use of parallel computing techniques in scientific research, such as analyzing data from the Large Hadron Collider's ATLAS experiment. *Overview of Accelerated Computation in Particle Physics* - 28:16 Scientists looking to accelerate computations in particle physics use GPUs and FPGAs to handle hundreds of gigabytes per second during collisions. - 28:50 Multiple ICTs, such as Nvidia machines with Cuda and CLE, show significant speedup over CPU versions. *Advantages of a Custom C++ Library* - 29:43 Discusses a C++20 library called Kaku designed for multidimensional data storage, highlighting its flexibility and efficiency. - 30:04 Kaku differentiates from other libraries by combining owning and non-owning data structures and offering an API for algorithm and interface definitions. - 30:53 The library focuses on data storage and processing in a configurable way, avoiding linear algebra and expression templates. *Utilizing C++20 Features and Concepts* - 31:09 Emphasizes the use of C++20 features like template metaprogramming and concepts to handle data processing efficiently. - 31:33 Describes creating execution contexts that users can define themselves, differing from execution policies. *Data Views and Parametric Concepts* - 31:57 Explains the creation and definition of data views with named parameter interfaces and complex deduction guides for ease of use. - 32:44 Discusses the importance of parametric concepts in handling complicated types without relying on specific implementations like zip. *Algorithmic Execution and Slicing Techniques* - 33:40 Provides examples of using algorithms to handle data, including transforming views and creating subranges similar to practices in MATLAB or NumPy. - 34:50 Describes more complex slicing and the transformation of data using custom algorithmic contexts for specific hardware. *Contexts and Performance on Different Hardware* - 35:38 Showcases how they offer a variety of contexts, including CPU and GPU contexts, to run algorithms effectively on diverse hardware. - 36:10 Discusses the performance results of complex computations using the CPU and GPU, demonstrating the efficiency of the library's design. *Flexibility and Extensibility of the Library* - 37:31 The library aims to provide proper implementation for a wide range of algorithms and support complex operations by leveraging simple base operations. - 38:15 Shares the experience of integrating the CLE into their C++20 codebase, which took about two weeks to wrap elements correctly and achieve good performance. *Concluding Remarks on Acceleration APIs and the Future* - 39:00 Mentions the thorough documentation provided by the Kronos Group on using their APIs and the support for updating hardware support in SYCL. - 40:31 Encourages the use of tools like SYCL for working with accelerators to combine knowledge of business algorithms and machine-specific expertise. - 41:01 Praises SYCL's simplicity, deployability, and compatibility with C++20 and its forward-thinking approach to concepts and type handling. - 41:34 Acknowledges the openness of the Kronos Group for feedback and concludes with a special thanks to their PhD student who contributed to the graphs and explanations. *Compilation Timing and Options* - 42:22 Compiling SQO code for devices can happen either ahead of time, like PTX for CUDA, or at runtime, adapting to available hardware. - 42:45 You can pre-select the target device (CPU or GPU) and the compiler will compile for that device ahead of time. - 43:31 There is also a just-in-time compilation option. - 44:03 Partial compilation was previously supported, but the current status is unclear. *Device Selection and Ranking* - 45:08 You can set multiple conditions for device selection to ensure the best match for execution. - 45:29 A device can be chosen based on whether it fulfills a certain condition or set of conditions. - 45:37 Device aspects and deny lists allow for a fine-grained selection of required or unwanted features. - 46:12 Custom ranking functions enable prioritization of devices based on scores for their properties. *Fallback Implementations and Targeting Specific Compilers* - 48:04 For writing open-source libraries, it's possible to provide a fallback implementation for users with different compilers. - 48:32 There's an option to use a CPU scheduling library implementation if the user's compiler lacks specific support. - 48:45 TriSYCL is suggested for users who want to ensure compatibility across different systems. *CPU Support and SIMD Vectorization* - 49:53 The question about how CLE can get close to handwritten SIMD and threading code targeting CPUs. - 50:20 CPU support for threading uses platforms like OpenMP or TBB in the backend, providing solid multithreading. - 50:33 SIMD support quality depends on the compiler backend and its auto-vectorization capabilities. - 51:54 A specialized platform backend for CLE could potentially utilize a more advanced vectorization system. *Decoding the Secret String and Implementation Recommendations* - 53:16 The secret string is a hello world message from SYCL or oneAPI. - 53:59 Clang can be used directly for SYCL implementation and is recommended for getting started with SYCL. - 54:11 The oneAPI Docker image is suggested for those who don't want to install compilers locally. - 55:03 For advanced users needing CUDA support, oneAPI provides detailed setup documentation for Linux distributions. Disclaimer: I used gpt4-1106 to summarize the video transcript. This method may make mistakes in recognizing words and it can't distinguish between speakers.

• 
  @snbv5real3 ай бұрын

  The problem with sycl is it's basically *another* standard, on top of what should have already *been* the open standard (OpenCL) which was knee capped by Nvidia a decade ago. Sycl is trying to circumvent this by just running on top of the other APIs, but the problem is that to do this, it lacks a bunch of performance critical features, and while the presenter claims it's easy to use, my experience, (as well as *many* other people) has been the exact opposite, it takes a *looong* time to set up, hard to make libraries for, and hard to make re-producible environments for (if you're not using Intel). And OneAPI might be easier to set up, but now you've effectively got *another* standard, because there are things in OneAPI not supported by Sycl on other platforms, and TBH, I'm not interested in *only* supporting Intel. Then there's the whole graphics interop issue... There *is* a cross platform solution to compute, but when I mention it, people on the Sycl end tend to wince. It's Vulkan. It works on mobile, Windows, Linux, some consoles even, and through MoltenVK, works on Apple as well,. which IIRC Sycl *still* doesn't support. It also supports those platforms *with out* translation layers. Sycl does not have the *modern* hardware support and featureset required to run applications at the speeds we require, Vulkan, for better or worse, does. The last things vulkan needs (which I don't even think Sycl suppports) are storage class aware physical pointers with reinterpret cast/pointer arithmetic (this is available for global memory storage classes only currently) and *device side enqueue*, which this year AMD submitted an extension for which will be even more powerful than it was in OpenCL, and no longer buggy and unusable like it was there as well github.com/KhronosGroup/Vulkan-Docs/blob/main/proposals/VK_AMDX_shader_enqueue.adoc.

• 
  @wolpumba40993 ай бұрын

  *Abstract:* Test-Driven Development (TDD) has been acknowledged for its effectiveness in reducing development time and error rates, leading to widespread adoption in many C++ projects. However, its application in embedded C++ development, especially those involving microcontrollers with significant hardware dependence, presents unique challenges. At the Meeting C++ 2023, Daniel Penning addresses the obstacles and opportunities for integrating TDD in microcontroller-based development. The talk delves into the dual-target approach, advocated by James Grenning, which recommends running unit tests both on microcontrollers (On Target) and personal computers (Off Target). Despite its advantages, this method reveals limitations when dealing with hardware-related code such as drivers. Penning introduces open loop testing to complement dual targeting, an innovative method where external microcontroller interfaces are mimicked using mocks and stubs. This methodology facilitates a practical TDD workflow that enables developers to reap the full benefits of TDD in their microcontroller development process. The talk not only illustrates how the dual-target approach can be built using open source solutions but also compares the additional advantages provided by commercial alternatives. It also touches upon the significance of TDD in embedded development, emphasizing the need for quick, automated feedback loops essential for TDD efficacy. Demonstrations within the presentation showcase the implementation of open loop testing, using a Robot Framework to script tests at the pin level for direct hardware interaction. Penning provides a thorough analysis of the nuances in off-target and on-target testing, detailing their respective limitations and how open loop testing fills the gaps for a comprehensive TDD practice. Finally, the session concludes with an insightful Q&A that explores related topics such as hardware verification, functional safety, and integration testing, and discusses industry trends in hardware abstraction layer and driver development. This presentation serves as a crucial guide for software engineers and project managers in embedded systems looking to refine their development practices with TDD, improving their product quality and reliability in a domain where traditional testing methods often fall short. *Chapter Titles* I. Fundamentals of TDD in Embedded Systems - 00:00 Introduction to TDD and Embedded Software Development - 01:59 The Importance and Challenges of TDD in Embedded Systems II. Testing Strategies for Embedded Software - 04:22 Testing Embedded Software Off-Target vs. On-Target - 07:26 Establishing Off Target Testing in Embedded Development - 11:41 Limitations and Risks of Off Target Testing - 14:33 Testing Hardware Dependent Code - 15:34 On Target Testing III. Advanced Testing Techniques and Tools - 17:09 State-of-the-Art in Testing: Pin Behavior - 19:13 Challenges with Manual and Register-Based Testing - 25:06 Open Loop Testing: A New Approach - 28:00 Demonstration of Open Loop Testing IV. Practical Application and Case Studies - 31:09 Configuration and Initial Test - 33:10 Multiple Byte Reception and Hardware Interaction - 35:19 Implementation Adjustments and Debugging V. Summation and Addressing Complex Testing Scenarios - 39:01 Summary and QA Session - 45:12 Concerning Emulation and Real-Time Testing - 47:50 Challenges in Hardware Verification VI. Ensuring Functional Safety and System Integration - 48:35 Functional Safety and Testing Approaches - 50:15 Integration Testing and Developer Feedback - 51:34 Hardware Abstraction Layer and Driver Development VII. Closing Remarks - 53:15 Conclusion *Summary* *Introduction to TDD and Embedded Software Development* - 00:00 Introduction to the audience's familiarity with Test Driven Development (TDD) and experience with microcontrollers. - 00:33 Background of the speaker's experience in embedded software engineering. - 00:58 Contrast between common testing practices in traditional software development and the lack of unit testing and TDD in embedded systems. - 01:22 Current state of TDD in deeply embedded projects. - 01:44 Aim of the talk to discuss the obstacles of using TDD in embedded systems, present the state of the art, and suggest improvements. *The Importance and Challenges of TDD in Embedded Systems* - 01:59 The significance of the TDD micro cycle for software development. - 02:39 Necessity of a quick and automated feedback loop in TDD. - 02:52 Popularity of TDD through Kent Beck's book on the subject. - 03:04 Differences in feedback mechanisms between traditional software and embedded systems. - 03:36 In-depth explanation of the challenges in testing embedded systems. - 04:09 The standard practice of trying code on deeply embedded systems. *Testing Embedded Software Off-Target vs. On-Target* - 04:22 Unit testing in traditional software and the core principle of testing isolated code parts. - 04:53 Question of whether unit testing and abstraction can be applied to embedded systems. - 05:07 James Grenning's book on TDD for embedded C, introducing dual-target testing. - 05:40 Detailed explanation of dual-target testing: running unit tests on microcontrollers (On Target) and on PCs (Off Target). - 07:21 Types of code suitable for Off Target and On Target testing. *Establishing Off Target Testing in Embedded Development* - 07:26 Requirements for Off Target testing, including a compatible compiler and decoupling from hardware dependencies. - 08:03 Generalizing code to allow Off Target testing using standard headers. - 09:12 Example of a unit test for checksum calculation. - 09:55 Need for a setup allowing Off Target testing, including a toolchain and a unit test framework. - 11:00 Critical need to decouple code from hardware dependencies, especially in legacy projects. - 11:27 Benefits and speed of the TDD feedback loop provided by Off Target testing. *Limitations and Risks of Off Target Testing* - 11:41 The limitations and risks of relying solely on Off Target testing. - 11:53 Example showing different results between Off Target and On Target due to compiler differences. - 13:00 Definition of unspecified behavior and potential differences in program behavior. - 13:37 Additional risks including hardware defects and toolchain bugs. - 14:27 Necessity of On Target testing to mitigate risks and ensure object code is tested. *Testing Hardware Dependent Code* - 14:33 The issue of testing code that depends on microcontroller hardware features. - 14:40 Example of hardware-dependent code on an STM32 microcontroller. - 15:19 Possibility of unit testing hardware-dependent code through abstraction. *On Target Testing* - 15:34 Discusses integrating a test framework with an embedded compiler. - 15:46 Notes the challenge of older compilers not supporting modern C++ features. - 15:58 Suggests using C testing libraries like Unity or cppu test for compatibility. - 16:05 Recommends selecting a unit test framework that compiles with an ancient cross compiler. - 16:23 Explains how to adapt a unit test framework to output results via a serial line for PC display. - 16:40 Emphasizes the possibility of quick automated feedback and the importance of a good setup. - 16:47 Mentions the typical bottleneck in testing is microcontroller flashing but it can be optimized. *State-of-the-Art in Testing: Pin Behavior* - 17:09 Introduces the concept of testing pin behavior in embedded systems. - 17:33 Explains that testing should confirm the interactions through microcontroller pins. - 18:01 Describes a test for sending bytes over UART using the STM32 HAL library. - 18:34 Discusses the manual testing process using logic analyzers and other equipment. - 18:53 Highlights the difficulties of accessing pins and the cumbersome nature of manual testing. *Challenges with Manual and Register-Based Testing* - 19:13 Critiques the manual-based testing approach. - 19:26 Introduces register-based testing as an industry standard but flawed in the context of TDD. - 19:54 Explains the complexity of STM32 reference manuals and using them for register-based testing. - 20:29 Provides an example of testing UART initialization through register values. - 21:17 Describes the complex process of determining register values from the reference manual. - 23:25 Discusses why register-based testing is problematic for TDD due to its white-box nature. - 24:10 Illustrates an issue where tests fail despite correct functionality due to register value changes. *Open Loop Testing: A New Approach* - 25:06 Introduces open loop testing with three main requirements: accessible pins, code, and periphery. - 25:29 Describes the process of writing tests for hardware interactions at the pin level. - 25:50 Highlights that the test system should integrate the specific microcontroller used in the product. - 26:41 Explains that the test system allows writing tests to interact with hardware peripherals directly. - 27:00 Uses Robot Framework for writing tests in open loop test systems. *Demonstration of Open Loop Testing* - 28:00 Demonstrates an open loop test using Visual Studio Code connected to a physical test system. - 28:39 Details a test scenario for receiving UART data on a microcontroller. - 29:04 Shows C++ code for initializing UART and registering a function to process received characters. - 29:50 Explains the requirement for the test system to be able to call functions on the microcontroller chip. - 30:28 Describes the test sequence setup in Robot Framework, including flashing firmware and periphery initialization.

• 
  @wolpumba40993 ай бұрын

  *Configuration and Initial Test* - 31:09 Configuration for UART communication involves stop bit and eight data bits. - 31:16 Testing the reception of a single byte using the do or microcontroller. - 31:23 Using the test system endpoint to transmit hex data 6B. - 31:41 Data is sent from the system to a pin to be read by the microcontroller. - 31:48 The `invoke` function "show_received" is used to read the output, which is saved into a variable. - 32:01 The Robot Framework's syntax is utilized for saving output and assertions. - 32:19 Assertion is used to ensure the output matches the expected value, 6B. *Multiple Byte Reception and Hardware Interaction* - 33:10 Testing the reception of multiple bytes (7C8DE9E) and adjusting expectations accordingly. - 33:48 Demonstrating the speed of feedback with tests running quickly and showing implementation is working. - 34:00 Using a logic analyzer to confirm the physical hardware receives the correct data. - 34:33 The second test is run and captured by the logic analyzer to verify pin-level activity. *Implementation Adjustments and Debugging* - 35:19 Implementing parity to handle noise on the line; setting to odd parity and recompiling. - 35:53 Adjusting the test configuration for odd parity. - 36:12 Discovering an error in multiple byte reception; received bytes don't match expected values due to an issue with the eighth bit. - 36:50 Checking the parity implementation in the ST documentation reveals an issue with how data bits are considered when parity is enabled. - 37:38 Fixing the issue by setting word length to nine bits, recompiling, and passing all tests. - 38:27 Automation ensures that tests are run without manual wiring or setup. *Summary and QA Session* - 39:01 Summary of open loop testing, emphasizing the importance of setting up accessible pins and automated scripting for tests. - 39:20 Mentioning the need for accessible code on the chip and making peripheries accessible for different requirements. - 40:05 Discussing the quick and automated feedback from On Target testing. - 41:50 Introducing On Target testing in all serious projects due to benefits and risk mitigation. - 42:12 All tests that can be run off-target should also be run on-target. - 44:05 Clarification between unit testing and integration testing in the context of On Target and open loop testing. - 44:57 Recommending James Grenning's book on test-driven development. *Concerning Emulation and Real-Time Testing* - 45:12 Discussing how Robot Framework with an underlying layer of Python handles real-time requirements. - 46:04 Explaining that real-time critical operations are managed by the test system with FPGA, rather than Robot Framework. - 46:52 Emulation of hardware is not typically feasible due to complexity and potential faults; ARM offers virtual hardware instead. *Challenges in Hardware Verification* - 47:50 Discussing the effort required to create good models for hardware verification. - 47:55 Acknowledges the high number of peripherals and the expense of microcontrollers that support advanced models. - 48:04 Highlights the risk of models not being fully utilized in practice. - 48:09 Points to hardware errata documents as an indication of the complexity and potential for errors in hardware. - 48:15 Suggests that a detailed errata list can illustrate issues missed during extensive testing prior to silicon production. *Functional Safety and Testing Approaches* - 48:35 Recommends running tests directly on hardware. - 48:42 Question about the presenter's experience with functional safety and testing acceptance by authorities. - 48:53 The presenter admits to having no experience with authorities like the TÜV responding to their tests. - 49:04 Different approaches to functional safety testing are mentioned, including black and white channel definitions. - 49:18 Notes that systems have not been used for certification purposes, and certification norms are sometimes ambiguous or demanding. - 49:37 Discusses the trend of avoiding pin-level testing in favor of register-based testing within the context of functional safety. - 49:58 Mentions a lack of examples using a mix of unit and hardware/software integration testing for certification. *Integration Testing and Developer Feedback* - 50:15 Discusses the concept of performing unit tests without hardware interaction and leaving the rest to integration tests. - 50:35 The presenter seeks to clarify what is meant by integration testing, noting many projects only do unit and system testing. - 50:53 Queries about the department responsible for running integration tests in the described scenario. - 51:04 Emphasizes the importance of feedback time when developers hand off code to a separate testing department. - 51:29 Follow-up question regarding the number of bugs found in low-level pin tests. *Hardware Abstraction Layer and Driver Development* - 51:34 Discusses issues typically discovered during low-level pin testing. - 51:45 Considers customer practice of writing their own hardware abstraction layers and drivers for platform-based development. - 51:58 The presenter does not provide precise statistics but notes the trend among customers to reimplement such code for flexibility and cost-saving. - 52:15 Describes the extensive work involved in reimplementing functions found in standard hardware abstraction layers. *Conclusion* - 53:15 Ends the Q&A session as there are no further questions. - 53:22 Confirming no additional online questions. - 53:33 Thanks the audience and closes the session. Disclaimer: I used gpt4-1106 to summarize the video transcript. This method may make mistakes in recognizing words and it can't distinguish between speakers.

• 
  @SamWhitlock3 ай бұрын

  I was a bit skeptical at first, but this analogy she used through whole presentation is actually a great way to present this!

• 
  @Gunbudder3 ай бұрын

  i'm surprised it lets you swap with an empty list, but then i shouldn't be surprised because its C++ lol

• 
  @paxdriver3 ай бұрын

  Jana, please keep giving this talk. It'll get easier every time, don't worry lol very well done 👏