Specialized computer hardware is often used to execute artificial intelligence (AI) programs faster, and with less energy, such as Lisp machines, neuromorphic engineering, event cameras, and physical neural networks. Since 2017, several consumer grade CPUs and SoCs have on-die NPUs. As of 2023, the market for AI hardware is dominated by GPUs. As of the 2020s, AI computation is dominated by graphics processing units (GPUs) and newer domain-specific accelerators such as Google's Tensor Processing Units (TPUs), AMD's Instinct MI300 series, and various on-device neural-processing units (NPUs) found in consumer hardware. == Scope == For the purposes of this article, AI hardware refers to computing components and systems specifically designed or optimized to accelerate artificial-intelligence workloads such as machine-learning training or inference. This includes general-purpose accelerators used for AI (for example, GPUs) and domain-specific accelerators (for example, TPUs, NPUs, and other AI ASICs). Event-based cameras are sometimes discussed in the context of neuromorphic computing, but they are input sensors rather than AI compute devices. Conversely, components such as memristors are basic circuit elements rather than specialized AI hardware when considered alone. == Lisp machines == Lisp machines were developed in the late 1970s and early 1980s to make artificial intelligence programs written in the programming language Lisp run faster. == Dataflow architecture == Dataflow architecture processors used for AI serve various purposes with varied implementations like the polymorphic dataflow Convolution Engine by Kinara (formerly Deep Vision), structure-driven dataflow by Hailo, and dataflow scheduling by Cerebras. == Component hardware == === AI accelerators === Since the 2010s, advances in computer hardware have led to more efficient methods for training deep neural networks that contain many layers of non-linear hidden units and a very large output layer. By 2019, graphics processing units (GPUs), often with AI-specific enhancements, had displaced central processing units (CPUs) as the dominant means to train large-scale commercial cloud AI. OpenAI estimated the hardware compute used in the largest deep learning projects from Alex Net (2012) to Alpha Zero (2017), and found a 300,000-fold increase in the amount of compute needed, with a doubling-time trend of 3.4 months. === General-purpose GPUs for AI === Since the 2010s, graphics processing units (GPUs) have been widely used to train and deploy deep learning models because of their highly parallel architecture and high memory bandwidth. Modern data-center GPUs include dedicated tensor or matrix-math units that accelerate neural-network operations. In 2022, NVIDIA introduced the Hopper-generation H100 GPU, adding FP8 precision support and faster interconnects for large-scale model training. AMD and other vendors have also developed GPUs and accelerators aimed at AI and high-performance computing workloads. === Domain-specific accelerators (ASICs / NPUs) === Beyond general-purpose GPUs, several companies have developed application-specific integrated circuits (ASICs) and neural processing units (NPUs) tailored for AI workloads. Google introduced the Tensor Processing Unit (TPU) in 2016 for deep-learning inference, with later generations supporting large-scale training through dense systolic-array designs and optical interconnects. Other vendors have released similar devices—such as Apple's Neural Engine and various on-device NPUs—that emphasize energy-efficient inference in mobile or edge computing environments. === Memory and interconnects === AI accelerators rely on fast memory and inter-chip links to manage the large data volumes of training and inference. High-bandwidth memory (HBM) stacks, standardized as HBM3 in 2022, provide terabytes-per-second throughput on modern GPUs and ASICs. These accelerators are often connected through dedicated fabrics such as NVIDIA's NVLink and NVSwitch or optical interconnects used in TPU systems to scale performance across thousands of chips.
Vulnerability Discovery Model
A Vulnerability Discovery Model (VDM) uses discovery event data with software reliability models for predicting the same. A thorough presentation of VDM techniques is available in. Numerous model implementations are available in the MCMCBayes open source repository. Several VDM examples include: Alhazmi-Malaiya: Time based model (Alhazmi-Malaiya Logistic (AML) model) Alhazmi-Malaiya: Effort based model Rescorla: Quadratic Model and Exponential Model Anderson: Thermodynamic Model Kim: Weibull Model Linear Model Hump-Shaped Model Independent and Dependent Model Vulnerability Discovery Modeling using Bayesian model averaging Multivariate Vulnerability Discovery Models
Project Debater
Project Debater is an IBM artificial intelligence project, designed to participate in a full live debate with expert human debaters. It follows on from the Watson project which played Jeopardy! == Development == Project Debater was developed at IBM's lab in Haifa, Israel. The project was proposed by Noam Slonim in 2011 as the IBM Research next Grand Challenge, following Deep Blue and the victory of Watson in Jeopardy! It was exposed for the first time in a closed media event at June 18, 2018, in San Francisco, under the leadership of Ranit Aharonov and Slonim, both from the IBM Research lab in Haifa, Israel. The AI technology debated two human debaters, Noa Ovadia, who was the 2016 Israeli debate champion and Dan Zafrir. The two debated on the topics "We should subsidize space exploration" and "Should we increase the use of telemedicine." A demonstration of Project Debater also aired on the Discovery Channel in June 2018 debating the question of whether sports gambling should be legalized. == Live Debate == On February 11, 2019, Project Debater was revealed to the world in a live debate in San Francisco. Nonpartisan media group Intelligence Squared U.S. Debates hosted the debate which was moderated by journalist John Donvan. The debate took place between Project Debater and Harish Natarajan, who holds the world record in number of debate competition victories. The motion was “We should subsidize preschools.” == That's Debatable Television Show == Project Debater was featured in a television series called “That’s Debatable” presented by Intelligence Squared U.S. Debates and Bloomberg Media. For each episode of “That’s Debatable,” Project Debater provided insight into three distinct debate topics on the redistribution of wealth, modern monetary theory, and a US-China space race. More than 5,000 arguments were submitted online from around the world across the three topics, which were then analyzed and distilled into key points that were highlighted on the television show and discussed by human debaters. == Artificial Intelligence Capabilities == To develop Project Debater, the IBM Research team had to endow the system with the following AI capabilities: Data-driven speech writing and delivery: Project Debater is the first demonstration of a computer that can digest massive corpora, and given a short description of a controversial topic, write a well-structured speech, and deliver it with clarity and purpose, while even incorporating humor where appropriate. Listening comprehension: the ability to identify the key concepts and claims hidden within long continuous spoken language. Four minutes of persuasive speech: the guarantee of producing four minutes of persuasive speech. Modeling human dilemmas: modeling the world of human controversy and dilemmas in a unique knowledge representation, enabling the system to suggest principled arguments as needed. An article on the project was published in Nature in March 2021.
Theaitre
Theaitre (stylized as THEaiTRE) is an interdisciplinary research project investigating to what extent artificial intelligence is able to generate theatre play scripts. The first theatre play produced within the project, AI: When a Robot Writes a Play, premiered online on February 26, 2021. == Goal == Following similar previous projects such as Sunspring, a short sci-fi movie with an automatically generated script, the THEaiTRE project investigates whether current language generation approaches are mature enough to generate a theatre play script that could be successfully performed in front of an audience. The project falls within the area of generative art, famously represented e.g. by the portrait of Edmond de Belamy which was generated by an artificial neural network. In this field, artists are trying to use automated techniques to create "art", questioning the modern definition of art itself. More broadly, the project aims at promoting cooperation rather than competition of humans and artificial intelligence as the more beneficial approach for both. The first theatre play created within the project, titled AI: When a Robot Writes a Play, was presented in February 2021 at the 100th anniversary of the premiere of the R.U.R. theatre play by the Czech author Karel Čapek to celebrate the invention of the word "robot". While R.U.R. was a play written by a human about robots (and humans), THEaiTRE tried to reverse this idea by presenting a play written by a "robot" (artificial intelligence) about humans (and robots). The script of the play was published online, with marked parts of the text which were written manually or manually post-edited. The analysis shows that 90% of the script is automatically generated, with 10% manually written or manually post-edited. The project also plans to produce a second play in 2022, addressing some of the many shortcomings of the approach used to generate the first play, as well as attempting to further minimize the amount of human influence on the script. == Approach == At the core of the project is the GPT-2 language model by OpenAI with various adjustments motivated by the task of generating theatre play scripts, for which the model is not particularly trained. The GPT-2 model is used in the usual way, providing it with a start of a document and prompting it to generate a continuation of the document. Specifically, the input for GPT-2 in this project is typically a short description of the scene setting, followed by a few lines to introduce the characters and start the dialogue. The model then generates 10 continuation lines, and hands control to the user, who can then either ask the model to continue generating, or make various edits before letting the model to generate further, deleting some parts of the script or adding new lines into the script. The adjustments include restricting the generator to only produce lines pertaining to characters appearing in the input prompt, limiting the repetitiveness of the generated text, and employing automatic summarization of the input prompt and the generated text to overcome the limitation of the GPT-2 model which only attends to the last 1,024 subword tokens. The limitations of the model include, among other, a lack of distinctiveness and self-consistency of the characters, an inability to generate the script for the whole play (scripts for individual scenes are generated independently), and errors due to the employment of automated machine translation, as GPT-2 generates English texts but the final play script is being produced in Czech language. The source codes of the project are available under the MIT licence. The project has also published some sample outputs. == Team == The project is a cooperation of the following experts, all based in Prague, Czech Republic: computational linguists from the Faculty of Mathematics and Physics, Charles University theatre experts from the Švanda Theatre and from the Theatre Faculty of the Academy of Performing Arts in Prague hackers from CEE Hacks The project is financially supported by the Technology Agency of the Czech Republic.
HYPO CBR
HYPO is a computer program, an expert system, that models reasoning with cases and hypotheticals in the legal domain. It is the first of its kind and the most sophisticated of the case-based legal reasoners, which was designed by Kevin Ashley for his Ph.D dissertation in 1987 at the University of Massachusetts Amherst under the supervision of Edwina Rissland. HYPO's design represents a hybrid generalization/comparative evaluation method appropriate for a domain with a weak analytical theory and applies to tasks that rarely involve just one right answer. The domain covers US trade secret law, and is substantially a common law domain. Since Anglo-American common law operates under the doctrine of precedent, the definitive way of interpreting problems is of necessity and case-based. Thus, HYPO did not involve the analysis of a statute, as required by the Prolog program. Rissland and Ashley (1987) envisioned HYPO as employing the key tasks performed by lawyers when analyzing case law for precedence to generate arguments for the prosecution or the defence. HYPO was a successful example of a general category of legal expert systems (LESs), it applies artificial intelligence (A.I.) techniques to the domain of legal reasoning in patent law, implementing a case-based reasoning (CBR) system, in contrast to rule based systems like MYCIN, or mixed-paradigm systems integrating CBR with rule-based or model-based reasoning like IKBALS II. A legal case-based reasoning essentially reasons from prior tried cases, comparing the contextual information in the current input case with that of cases previously tried and entered into the system. As noted by Ashley and Rissland (1988) CBR is used to "... capture expertise in domains where rules are ill-defined, incomplete or inconsistent". The HYPO project set out to model the creation of hypotheticals in law, where no case matches well enough. HYPO uses hypotheticals for a variety of tasks necessary for good interpretation: "to redefine old situations in terms of new dimensions, to create new standard cases when an appropriate one doesn’t exist, to explore and test the limits of a concept, to refocus a case by excluding some issues and to organize or cluster cases". Hypotheticals can include facts that support two conflicting lines of reasoning. So, it makes and responds to arguments from competing viewpoints about who should win the dispute. HYPO use heuristics such as making a case weaker or stronger, making a case extreme, enabling a near-miss, disabling a near-hit to generate hypotheticals in the context of an argument by using the dimensions mechanism. Dimensions have a range of values, along which the supportive strength that may shift from one side to the other. What differentiated this expert system from others was its facility not only to return a primary to best-case response but to return near-best-fit responses also. == Components == Legal knowledge in HYPO is contained in: the case-knowledge-base (CKB) and the library of dimensions. The CKB contains HYPO's base of known cases that are highly structured objects and sub-objects both real and hypothetical in the area of trade secret law. Each case is represented as a hierarchical set of frames whose slots are important facets of the case (e.g. Plaintiff, defendant, secret knowledge, employer/employee data).Ashley’s HYPO system used a database of thirty cases in the area indexed by thirteen dimensions. A key mechanism in HYPO is a dimension i.e. a mechanism to allow retrieval from the CKB, in order to represent legal cases. Ashley's dimensions are composed of (i) prerequisites, which are a set of factual predicates that must be satisfied for the dimension to apply (ii) focal slots, which accommodate one or two of the dimension's prerequisites designated as being indicative of the case's strength along that dimension and (iii) range information, which tells how a change in focal slot value effects the strength of a party's case along a given dimension. Dimensions focus attention on important aspects of cases. In HYPO's domain of misappropriation of trade secrets the dimension called “secrets voluntary disclosed” captures the idea that the more disclosures the plaintiff has made of his/her putative secret, the less convincing is his/her argument that the defendant is responsible for letting the secret. HYPO, like any other CBR system has also the following components: Similarity/relevancy metrics: that is, standards by which to evaluate the closeness of cases, judge their relevancy to the instant case, and select “most on point” cases. Half-Order Theory of the Application Domain: that is, hierarchies and taxonomies of knowledge, especially regarding the application domain. Precedent-based argumentation abilities: that is, capabilities to generate and evaluate precedent-based arguments. Knowledge to generate hypotheticals: that is, the ability to generate hypothetical cases to deal with various circumstances, like testing the validity of an interpretation or argument by providing gedanken experiments such as test cases or to fill in a weak CKB. == Functions == HYPO's method of creating an argument and justifying a solution or position has several steps. HYPO begins its processing with the current fact situation (cfs) which is direct input by the user into HYPO's representation framework. Once the user inputs the case, HYPO begins its legal analysis. The cfc is analyzed for relevant factors. Based on these factors HYPO selects the relevant cases and produces a case-analysis-record that records which dimensions apply to the cfc and which nearly apply (i.e. are "near misses"). The combined list of applicable and near miss dimensions is called the D-list. At this point the fact gathered module may request additional information from the user in order to draw a legal conclusion. Once all the facts are in the case-positioner module it uses the case-analysis record to create the claim lattice. This is a technique that organizes the relevant retrieved cases from the point of view of the cfc and makes it easy for HYPO to ascertain the most-on point cases (mopc) and to least on-point-cases. HYPO's arguments are 3ply, leading to the construction of the skeleton of an argument: it makes a point for one side, drawing the analogy between the problem and the precedent, responds with an argument for the opponent side, endeavoring to differentiate the cited case and citing other cases as counterarguments. Then it makes a final rebuttal, attempting to differentiate the counterarguments. The claim lattice also enables the HYPO-generator module to produce legally hypotheticals. With its use of dimension-based heuristics, the HYPO-generator does a heuristic search of the space of all possible cases. Lastly, the Explanation module expands upon the argument skeleton and provides explanation and justification for the different lines of analysis and cases found by HYPO. == An intelligent legal tutoring system == Legal expert systems are specifically designed to teach an area of law and are useful for pedagogical purposes. Ashley's work was mainly concerned to build tools to help students understand legal reasoning. Explanation and argument are the bases of the case method used in many professional schools in the U.S., first introduced by the Dean of the Harvard Law School, Christopher Columbus Langdell in 1870. The case method focuses on close readings of cases and principles; it involves students in pointed Socratic dialogue and makes strong use of hypotheticals (hypos). Thus, CATO (Aleven 1997) was a research project to device and test an intelligent, case-based tutorial program for teaching law students how to argue with cases implementing the HYPO program. Within the tutor system, Ashley and Aleven (1991) proposed to leverage an understanding of legal reasoning against the standard case-based tutoring methodology. What makes this tutoring system stand out is the additional levels of abstraction involved in its results. The system presents exercises, including the facts of a problem and a set of on-line cases and instructions to make, or respond to, a legal argument about the problem. The student/user will have a set of tools to analyze the problem and fashion an answer comparing it to other cases. Instead of simply generating precedent cases, the system works to interpret student responses, comparing them against a list of possibilities and responding to student entries, for example, by citing counterexamples, and providing feedback on a student's problem solving activities with explanations of correctness or giving further hints as to what may be wrong with evaluating a student's ability to perform legal reasoning and argument, examples and follow-up assignments by employing HYPO's model of case-based structure. == HYPO’s progeny == The quality of HYPO's results speak for themselves, in that a number of sequent legal reasoning systems are either directly based upon H
Security of the Java software platform
The Java software platform provides a number of features designed for improving the security of Java applications. This includes enforcing runtime constraints through the use of the Java Virtual Machine (JVM), a security manager that sandboxes untrusted code from the rest of the operating system, and a suite of security APIs that Java developers can utilise. Despite this, criticism has been directed at the programming language, and Oracle, due to an increase in malicious programs that revealed security vulnerabilities in the JVM, which were subsequently not properly addressed by Oracle in a timely manner. == Security features == === The JVM === The binary form of programs running on the Java platform is not native machine code but an intermediate bytecode. The JVM performs verification on this bytecode before running it to prevent the program from performing unsafe operations such as branching to incorrect locations, which may contain data rather than instructions. It also allows the JVM to enforce runtime constraints such as array bounds checking. This means that Java programs are significantly less likely to suffer from memory safety flaws such as buffer overflow than programs written in languages such as C which do not provide such memory safety guarantees. The platform does not allow programs to perform certain potentially unsafe operations such as pointer arithmetic or unchecked type casts. It manages memory allocation and initialization and provides automatic garbage collection which in many cases (but not all) relieves the developer from manual memory management. This contributes to type safety and memory safety. === Security manager === The platform provides a security manager which allows users to run untrusted bytecode in a "sandboxed" environment designed to protect them from malicious or poorly written software by preventing the untrusted code from accessing certain platform features and APIs. For example, untrusted code might be prevented from reading or writing files on the local filesystem, running arbitrary commands with the current user's privileges, accessing communication networks, accessing the internal private state of objects using reflection, or causing the JVM to exit. The security manager also allows Java programs to be cryptographically signed; users can choose to allow code with a valid digital signature from a trusted entity to run with full privileges in circumstances where it would otherwise be untrusted. Users can also set fine-grained access control policies for programs from different sources. For example, a user may decide that only system classes should be fully trusted, that code from certain trusted entities may be allowed to read certain specific files, and that all other code should be fully sandboxed. === Security APIs === The Java Class Library provides a number of APIs related to security, such as standard cryptographic algorithms, authentication, and secure communication protocols. === The sun.misc.Unsafe class === sun.misc.Unsafe is an internal utility class in the Java programming language which is a collection of low-level unsafe operations. While it is not a part of the official Java Class Library, it is called internally by the Java libraries. It resides in an unofficial Java module named jdk.unsupported. Beginning in Java 11, it has been partially migrated to jdk.internal.misc.Unsafe (which resides in module java.base). Its primary feature is to allow direct memory management (similar to C memory management) and memory address manipulation, manipulating objects and fields, thread manipulation, and concurrency primitives. Its declaration is: public final class Unsafe;, and it is a singleton class with a private constructor. It contains the following methods, many of which are declared native (invoking Java Native Interface): static Unsafe getUnsafe(): retrieves the Unsafe instance. It uses sun.reflect.Reflection to do so. int getInt(Object o, long offset): fetches a value (a field or array element) in the object at the given offset. (There are corresponding getBoolean(), getByte(), getShort(), getChar(), getLong(), getFloat(), and getDouble() methods as well.) void putInt(Object o, long offset, int x): stores a value into an object at the given offset. (There are corresponding putBoolean(), putByte(), putShort(), putChar(), putLong(), putFloat(), and putDouble() methods as well.) Object getObject(Object o, long offset): fetches a reference value from an object at the given offset. void putObject(Object o, long offset, Object x): stores a reference value into an object at the given offset. int getInt(long address): fetches a value at the given address. (There are corresponding getBoolean(), getByte(), getShort(), getChar(), getLong(), getFloat(), and getDouble() methods as well.) void putInt(long address, int x): stores a value into the given address. (There are corresponding putBoolean(), putByte(), putShort(), putChar(), putLong(), putFloat(), and putDouble() methods as well.) long getAddress(long address): fetches a native pointer from a given address. void putAddress(long address, long x): stores a native pointer into a given address. long allocateMemory(long bytes): allocates a block of native memory of the given size (similar to malloc()). long reallocateMemory(long address, long bytes): resizes a block of native memory to the given size (similar to realloc()). void setMemory(Object o, long offset, long bytes, byte value), void setMemory(long address, long bytes, byte value): sets all bytes in a block of memory to a fixed value (similar to memset()). void copyMemory(Object srcBase, long srcOffset, Object destBase, long destOffset, long bytes), void copyMemory(long srcAddress, long destAddress, long bytes): sets all bytes in a given block of memory to a copy of another block (similar to memcpy()). void freeMemory(long address): deallocates a block of native memory obtained from allocateMemory() or reallocateMemory(), similar to free()). long staticFieldOffset(Field f): obtains the location of a given field in the storage allocation of its class. long objectFieldOffset(Field f): obtains the location of a given static field in conjunction with staticFieldBase(). Object staticFieldBase(Field f): obtains the location of a given static field in conjunction with staticFieldOffset(). void ensureClassInitialized(Class c): ensures the given class has been initialized. int arrayBaseOffset(Class arrayClass): obtains the offset of the first element in the storage allocation of a given array class. int arrayIndexScale(Class arrayClass): obtains the scale factor for addressing elements in the storage allocation of a given array class. static int addressSize(): obtains the size (in bytes) of a native pointer. int pageSize(): obtains the size (in bytes) of a native memory page. Class defineClass(String name, byte[] b, int off, int len, ClassLoader loader, ProtectionDomain protectionDomain): signals to the JVM to define a class without security checks. Class defineAnonymousClass(Class hostClass, byte[] data, Object[] cpPatches): signals to the JVM to define a class but do not make it known to the class loader or system directory. Object allocateInstance(Class cls) throws InstantiationException: allocates an instance of a class without running its constructor. void monitorEnter(Object o): locks an object. void monitorExit(Object o): unlocks an object. boolean tryMonitorEnter(Object o): tries to lock an object, returning whether the lock succeeded. void throwException(Throwable ee): throws an exception without telling the verifier. final boolean compareAndSwapInt(Object o, long offset, int expected, int x): updates a variable to x if it is holding expected, returning whether the operation succeeded. (There are corresponding compareAndSwapLong() and compareAndSwapObject() methods as well.) int getIntVolatile(Object o, long offset): volatile version of getInt(). (There are corresponding getBooleanVolatile(), getByteVolatile(), getShortVolatile(), getCharVolatile(), getLongVolatile(), getFloatVolatile(), getDoubleVolatile(), and getObjectVolatile() methods as well.) void putIntVolatile(Object o, long offset, int x): volatile version of putInt(). (There are corresponding putBooleanVolatile(), putByteVolatile(), putShortVolatile(), putCharVolatile(), putLongVolatile(), putFloatVolatile(), putDoubleVolatile(), and putObjectVolatile() methods as well.) void putOrderedInt(Object o, long offset, int x): version of putIntVolatile() not guaranteeing immediate visibility of storage to other threads. (There are corresponding putOrderedLong() and putOrderedObject() methods as well.) void unpark(Object thread): unblocks a thread. void park(boolean isAbsolute, long time): blocks the current thread. int getLoadAverage(double[] loadavg, int nelems): gets the load average in the system run queue assigned to available processors averaged over various periods of time. void invokeCleaner(ByteBuffe
Split Up (expert system)
Split Up is an intelligent decision support system, which makes predictions about the distribution of marital property following divorce in Australia. It is designed to assist judges, registrars of the Family Court of Australia, mediators and lawyers. Split Up operates as a hybrid system, combining rule – based reasoning with neural network theory. Rule based reasoning operates within strict parameters, in the form: IF < condition(s) > then