init
249
TERCERO/ATR1/Teoría_2425.md
Normal file
@@ -0,0 +1,249 @@
|
||||
# <mark style="background: #FFF3A3A6;">TEMA 1: Conceptos básicos</mark>
|
||||
## <mark style="background: #ADCCFFA6;">1. Introducción</mark>
|
||||
Estudiar la red a nivel de tecnología, y arquitectura.
|
||||
- Una **red** es un conjunto de hosts o sistemas finales interconectados que se pueden comunicar a través de esta.
|
||||
- La **tecnología** es un conjunto de procedimientos, métodos y elementos físicos que permiten transmitir información.
|
||||
- La **arquitectura** es el conjunto de capas y protocolos de una red de comunicaciones (nombre de capa y protocolo). La **pila de protocolos**, en cambio, es el conjunto de protocolos asociados a **cada capa** de una red de comunicaciones (solamente protocolos).
|
||||
## <mark style="background: #ADCCFFA6;">2. Modelo OSI vs TCP/IP</mark>
|
||||
~~~tabs
|
||||
---tab OSI
|
||||
|
||||
![[Pasted image 20240916084750.png|150]]
|
||||
|
||||
Modelo jerárquico dividido en capas o niveles basado en "divide y vencerás" para cubrir todos los servicios de una red. Debido a la jerarquía, las capas tienen un nivel de complejidad mayor cuanto más abajo están, al igual que son más cercanas al usuario cuanto mas arriba están.
|
||||
|
||||
---tab TCP/IP
|
||||
|
||||
![[Pasted image 20240916092616.png|150]]
|
||||
|
||||
Modelo que simplifica el OSI agrupando algunas capas:
|
||||
- Aplicación, Presentación y Sesión $\rightarrow$ Aplicación
|
||||
- Transporte (Host a Host)
|
||||
- Red
|
||||
- Enlace y Físico $\rightarrow$ Host a Red
|
||||
~~~
|
||||
## <mark style="background: #ADCCFFA6;">3. Relación entre los niveles/capas</mark>
|
||||
Los niveles inferiores suministran servicios a los superiores. El nivel superior "usa" el servicio del nivel inferior. Por ejemplo, TCP es cliente de IP.
|
||||
### <mark style="background: #FFB86CA6;">Encapsulación</mark>
|
||||
Por ejemplo al pedir una página web:
|
||||
**(ENVÍO)**
|
||||
- HTTP monta el mensaje HTTP y pide servicio a TCP.
|
||||
- TCP añade la cabecera TCP al mensaje recibido desde HTTP y pide servicio a IP.
|
||||
- IP añade la cabecera IP al datagrama TCP y pide servicio a IEEE 802.3.
|
||||
- IEEE 802.3 añade cabecera y cola al paquete IP y se envía la trama.
|
||||
**(RECEPCIÓN)**
|
||||
- IEEE 802.3 recibe la trama (binario), desencapsula (quita cabecera y cola) y "sube" el paquete IP.
|
||||
- IP recibe el paquete IP, desencapsula (quita cabecera) y "sube" el datagrama TCP.
|
||||
- TCP recibe el datagrama TCP, desencapsula (quita cabecera) y "sube" el mensaje HTTP.
|
||||
- HTTP recibe el mensaje HTTP y "monta" la respuesta.
|
||||
## <mark style="background: #ADCCFFA6;">4. Nivel de transporte</mark>
|
||||
Proporciona comunicación lógica entre procesos de aplicación que se ejecutan en diferentes hosts: los mensajes de aplicación se dividen en **segmentos** que se pasan al nivel de red. Los protocolos de transporte tienen lugar en los extremos. Existen dos protocolos del nivel de transporte:
|
||||
![[Pasted image 20240918110700.png|600]]
|
||||
### <mark style="background: #FFB86CA6;">Protocolo TCP</mark>
|
||||
|
||||
![[Pasted image 20240918112218.png|500]]
|
||||
|
||||
- **Source Port (16b):** puerto del nivel de aplicación en el host transmisor.
|
||||
- **Destination Port (16b):** puerto del nivel de aplicación en el host receptor.
|
||||
- **Sequence Number (32b):** número del primer octeto.
|
||||
- **ACK (32b):** número de secuencia esperado del otro extremo (confirmando los anteriores).
|
||||
- **Data Offset:** indica que "trozo" es en la segmentación.
|
||||
- **Flags:** banderas booleanas (1/0):
|
||||
- SYN: crear
|
||||
- FIN: cerrar
|
||||
- RST: rechazar
|
||||
- ACK: reconocer
|
||||
- **Window (16b):** tamaño máximo de cada "trozo".
|
||||
### <mark style="background: #FFB86CA6;">Protocolo UDP</mark>
|
||||
|
||||
![[Pasted image 20240918114306.png|500]]
|
||||
|
||||
- **Source Port (16b):** puerto del nivel de aplicación en el host transmisor.
|
||||
- **Destination Port (16b):** puerto del nivel de aplicación en el host receptor.
|
||||
- **Length:** tamaño del campo de datos.
|
||||
- **Checksum:** control de errores.
|
||||
## <mark style="background: #ADCCFFA6;">5. Nivel de red</mark>
|
||||
Define un esquema de direccionamiento. Establece las herramientas necesarias para definir un enrutamiento entre hosts. Emplea el servicio de entrega de R_PDUs suministrado por el nivel de enlace, permitiendo intercambiar datos entre dispositivos que implementen mínimo hasta nivel de enlace.
|
||||
### <mark style="background: #FFB86CA6;">Protocolo IPv4</mark>
|
||||
Características:
|
||||
- No fiable
|
||||
- No orientado a la conexión
|
||||
- Direccionamiento jerárquico de 32b (direcciones IP)
|
||||
- Existen direcciones especiales (127.0.0.1, 192..., 10..., 172..., 0.0.0.0, 255.255.255.255,...)
|
||||
- Soporta fragmentación
|
||||
|
||||
![[Pasted image 20240918115601.png|600]]
|
||||
- **Version (4b):** si es v4 o v6.
|
||||
- **Total Length (16b):** tamaño de la cabecera y datos.
|
||||
- **Fragment Offset:** para fragmentación.
|
||||
- **TTL (8b):** _time to live_ o número de saltos por los que puede pasar el mensaje.
|
||||
- **Source & Destination Address (32b):** direcciones IP de los hosts en transmisor y receptor.
|
||||
|
||||
### <mark style="background: #FFB86CA6;">Direccionamiento IP</mark>
|
||||
|
||||
![[Pasted image 20240918120609.png|350]]
|
||||
Un host está configurado si:
|
||||
- Tiene dirección IP
|
||||
- Tiene router frontera
|
||||
- Tiene máscara de red
|
||||
### <mark style="background: #FFB86CA6;">Sockets</mark>
|
||||
Un socket es el par dirección_ip:puerto. A su vez, un par de sockets, identifica de manera única una conexión en Internet.
|
||||
- Define un extremo de la comunicación.
|
||||
- Identifica un proceso en internet.
|
||||
## <mark style="background: #ADCCFFA6;">6. Identificación de clientes</mark>
|
||||
- TCP y UDP con **puerto**
|
||||
- IP con **Protocol**
|
||||
- Ethernet con **Ethertype**
|
||||
- IEEE 802.3 (MAC) emplea LLC (IEEE 802.2)
|
||||
# <mark style="background: #FFF3A3A6;">TEMA 2: Servicios de directorio</mark>
|
||||
## <mark style="background: #ADCCFFA6;">1. Introducción</mark>
|
||||
- **Configuración y administración:** DHCP.
|
||||
- **Acceso remoto:** SSH.
|
||||
- **Gestión de archivos:** FTP.
|
||||
- **Servicios de impresión:** Compartición de recursos.
|
||||
- **Información:** Compartir y buscar información (www, IPv).
|
||||
- **Comunicación:** Intercambio de texto, audio y/o vídeo entre usuarios (e-mail, chat, VoIP).
|
||||
Existen dos paradigmas:
|
||||
### <mark style="background: #FFB86CA6;">Cliente-Servidor</mark>
|
||||
|
||||
![[Pasted image 20240925105710.png|300]]
|
||||
**Servidor:**
|
||||
- Siempre activo
|
||||
- Dirección IP estática
|
||||
**Cliente:**
|
||||
- Se comunica con el Servidor
|
||||
- No se comunica con otros clientes
|
||||
- Dirección IP dinámica
|
||||
- Conexión intermitente
|
||||
#### <span style="color:red"><strong>Inconveniente:</strong></span> Puede haber un cuello de botella en el Servidor
|
||||
|
||||
Para resolver el cuello de botella se pueden usar servidores de respaldo que pueden servir tanto para contener _backups_ del servidor principal y funcionar en caso de fallo o para balancear la carga entre el principal y ellos y descongestionar el principal.
|
||||
|
||||
![[Pasted image 20240925110142.png|400]]
|
||||
### <mark style="background: #FFB86CA6;">Peer-to-Peer (P2P)</mark>
|
||||
|
||||
![[Pasted image 20240925110416.png|350]]
|
||||
No existe un "servidor principal". Los elementos de la red no tienen por qué estar siempre activos, se pueden comunicar entre sí y pueden tener IPs dinámicas.
|
||||
### <mark style="background: #FFB86CA6;">Híbrido</mark>
|
||||
|
||||
![[Pasted image 20240925111040.png|350]]
|
||||
El servidor no ofrece el servicio en sí, sino que ofrece información necesaria para acceder al mismo. La comunicación entre estaciones es P2P.
|
||||
**Ejemplo:** Chat/VoIP
|
||||
- El servidor centralizado almacena la información necesaria para que los pares se encuentren.
|
||||
- El usuario registra dicha información al conectarse a la red.
|
||||
- El usuario solicita información al servidor para comunicarse con otro par.
|
||||
## <mark style="background: #ADCCFFA6;">2. Introducción al servicio de directorio</mark>
|
||||
Un Servicio de Directorio se define como una o más aplicaciones que permite administrar y organizar los recursos y usuarios de una red. Para ofrecerlo, se debe:
|
||||
- Almacenar información diferenciada por tipo y establecer su formato.
|
||||
- Definir operaciones que se pueden realizar (leer, modificar, borrar, ...).
|
||||
|
||||
Para ofrecer el servicio se deben definir:
|
||||
- **Reglas de acceso** tipo de usuario, autenticación.
|
||||
- **Procedimientos** paradigma, formato de mensajes, mensajes de ops extendidas
|
||||
- **Estructura del servicio:** dónde almacenar la información, relaciones entre "entidades".
|
||||
### <mark style="background: #FFB86CA6;">Características</mark>
|
||||
- Los servicios de directorio están **optimizados para consultas** (uso de caché).
|
||||
- Implementa un **modelo distribuido** de almacenamiento (zonas DNS, dominios, prefijos).
|
||||
- Permite extender los tipos de información.
|
||||
- Ofrece capacidades avanzadas de búsqueda.
|
||||
- Capacidad de replicación.
|
||||
## <mark style="background: #ADCCFFA6;">3. LDAP (Lightweight Directory Access Protocol)</mark>
|
||||
- Basado en X.500.
|
||||
- LDAP usa TCP/IP respecto al modelo OSI que propone X.500
|
||||
- LDAP reduce la carga respecto a X.500
|
||||
- Es un protocolo de aplicación.
|
||||
- Ofrece un modelo mucho más simple tanto a nivel de programación como de administración.
|
||||
### <mark style="background: #FFB86CA6;">Visión global</mark>
|
||||
El paradigma que sigue es Cliente-Servidor.
|
||||
- **Cliente:** Directory User Agent (DUA)
|
||||
- **Servidor:** Directory System Agent (DSA)
|
||||
![[Pasted image 20240925115054.png|500]]
|
||||
**Directorio:** Colección de sistemas abiertos que cooperan para
|
||||
ofrecer servicios de directorios.
|
||||
|
||||
LDAP no especifica cómo o donde almacenar información: cualquier DUA podrá operar con cualquier implementación de LDAP.
|
||||
### <mark style="background: #FFB86CA6;">Introducción</mark>
|
||||
LDAP define dos modelos:
|
||||
- Modelo de Información del Directorio: formato y tipos de información
|
||||
- Modelo de protocolo: operaciones que se pueden realizar
|
||||
## <mark style="background: #ADCCFFA6;">4. Modelo de información del directorio</mark>
|
||||
### <mark style="background: #FFB86CA6;">Modelo de información del usuario del directorio (DUA)</mark>
|
||||
Toda la información contenida en el directorio se denomina **Directory Information Base (DIB)**. Un DIB contiene dos tipos de información:
|
||||
- **Información del usuario:** suministrada y gestionada por el usuario.
|
||||
- **Información administrativa y operacional**
|
||||
#### Entrada
|
||||
![[Pasted image 20240925120207.png|350]]
|
||||
Unidad básica de información (colección de información). Hay diversos tipos: entrada objeto (representa un objeto), entrada alias (representa un nombre alternativo).
|
||||
#### Atributo
|
||||
![[Pasted image 20240925120452.png|350]]
|
||||
Cada entrada es un conjunto de atributos que contienen información sobre el objeto. Pueden representar atributos de usuario o de información administrativa u operacional. La **descripción** de un atributo se compone de un tipo de atributo y un conjunto de 0 o más opciones.
|
||||
**Ejemplo de atributo con su descripción:** givenName - CN
|
||||
#### Tipo de atributo
|
||||
![[Pasted image 20240925120750.png|350]]
|
||||
El tipo de atributo define si el atributo puede tener múltiples valores, la sintaxis, las reglas de relación... El tipo indica si es de usuario u operacional. LDAP permite establecer jerarquía.
|
||||
#### Clase de objeto
|
||||
![[Pasted image 20240925120909.png|350]]
|
||||
Familia de objetos que comparten características. Cada objeto pertenece al menos a una clase. Puede haber herencia de clases. Cada clase se identifica mediante un **Object IDentification (OID)**. Cada clase identifica el conjunto de atributos _permitidos_ en las entradas y _requeridos_ (también dichos conjuntos se heredan de la superclase).
|
||||
#### Esquema
|
||||
![[Pasted image 20240925121156.png|350]]
|
||||
Es un conjunto de definiciones y restricciones en relación a:
|
||||
- La estructura del Directorio.
|
||||
- Las formas de nombrar entradas.
|
||||
- Información que puede contener una entrada.
|
||||
- Atributos usados.
|
||||
- Jerarquías y relaciones.
|
||||
El esquema permite al Directorio:
|
||||
- Prevenir la creación de entradas subordinadas a la clase incorrecta.
|
||||
- Prevenir la adición de tipos de atributos inapropiados.
|
||||
- Asegurarse de que la sintaxis sea correcta.
|
||||
#### EJEMPLO DE ENTRADA
|
||||
![[Pasted image 20240925121537.png]]
|
||||
|
||||
#### <mark style="background: #D2B3FFA6;">Organización de las entradas</mark>
|
||||
El conjunto de entradas que representan el DIB se organizan jerárquicamente en un árbol conocido como **Directory Information Tree (DIT)**. Cada nodo es una entrada del **DIB**. Las aristas representan relaciones entre entradas.
|
||||
![[Pasted image 20240930133135.png]]
|
||||
#### <mark style="background: #D2B3FFA6;">Identificación de las entradas</mark>
|
||||
Cada entrada se identifica mediante un **Relative Distinguished Name (RDN)**. RDN es uno o más pares de descripción de un atributo y su valor asignado. El RDN debe ser único entre todos los nodos hijos de un nodo padre.
|
||||
<u>Ejemplo</u>: UID=12345, CN=Peter García+L=Sevilla
|
||||
|
||||
Cada entrada posee también otra forma de identificarla llamada **Distinguished Name (DN)**, que si el RDN es el relativo este es el "absoluto", es decir, todos los RDN encadenados desde la raíz, identificando así a la entrada de forma unívoca en el DIT.
|
||||
<u>Ejemplo</u>: UID:nobody@example.com,DC=example,DC=comCN: Peter García+L=Sevilla,OU=Ventas,O=ACMELtd,L=Sevilla,C=ESv
|
||||
|
||||
![[Pasted image 20240930133748.png]]
|
||||
#### <span style="color:red"><strong>Importante:</strong></span> el nodo raíz debe tener SIEMPRE `dc`
|
||||
|
||||
#### ¿Qué inconveniente tiene tener un servidor secundario en LDAP?
|
||||
Dicho servidor debe tener una copia del primario para que el servicio LDAP siga activo en caso de caída del primario.
|
||||
### <mark style="background: #FFB86CA6;">Modelo de información del sistema (DSA)</mark>
|
||||
Varios DSAs pueden ofrecer acceso al DIT. El servidor maestro mantiene la información original. Los servidores "shadowing" o "caching" poseen copias de dicha información, con todo lo que conlleva: si se cachea en t=0, se puede volver a actualizar la información en t=n y **NO** estará en la caché (habría que actualizar periódicamente la caché basado en un _timestamp_ y en un tiempo máximo de cacheado).
|
||||
- **Contexto de nombre:** un subárbol de entradas que se gestiona en un sólo DSA maestro.
|
||||
- **Prefijo del contexto:** secuencia de RDNs desde el raíz del DIT al nodo inicial del contexto de nombre (DN del nodo inicial)
|
||||
#### <mark style="background: #D2B3FFA6;">Subentradas</mark>
|
||||
Son una clase especial de entrada. Se emplean para gestionar información asociada con un subárbol.
|
||||
#### <mark style="background: #D2B3FFA6;">Atributo <code>objectClass</code></mark>
|
||||
Cada entrada del DIT posee este atributo. Especifica las clases de objeto de una entrada. Los valores pueden ser modificados por los clientes pero el atributo no lo pueden eliminar.
|
||||
### <mark style="background: #FFB86CA6;">Modelo de información administrativa y operacional</mark>
|
||||
#### <mark style="background: #D2B3FFA6;">Atributos operacionales</mark>
|
||||
Se usan por los servidores para propósito administrativo y operacional. Normalmente no son visibles si no se solicitan explícitamente.
|
||||
<u>Ejemplos</u>: `creatorsName`, `createTimestamp`, `modifiersName`, `modifyTimestamp`.
|
||||
#### <mark style="background: #D2B3FFA6;">Atributos operacionales (X.500)</mark>
|
||||
- **Atributos operacionales del Directorio:** Representan información operacional y/o administrativa. `createTimestamp`, `ditContentRules`
|
||||
- **Atributos operacionales compartidos por DSA:** Representan información del Modelo de Información del DSA que se comparte entre DSAs.
|
||||
- **Atributos operacionales específicos del DSA:** Representan información del Modelo de Información del DSA que es específica de dicho DSA.
|
||||
## <mark style="background: #ADCCFFA6;">5. Modelo de protocolo</mark>
|
||||
Un cliente (DUA) comienza una sesión con LDAP conectándose al puerto TCP (por defecto 389) del servidor LDAP y le solicita que realice alguna acción.
|
||||
![[Pasted image 20241002112436.png|500]]
|
||||
Las solicitudes son generalmente independientes entre ellas y son atómicas (se realizan transacciones como en SQL). El comportamiento solicitud/respuesta es asíncrono.
|
||||
### <mark style="background: #FFB86CA6;">Operaciones en LDAP</mark>
|
||||
`Bind:` Autenticación
|
||||
`Unbind:` Cierra la conexión TCP
|
||||
`Unsolicited notification:` El otro tipo de respuesta que puede enviar el servidor, se manda sin haber solicitado nada. Se usa para notificar a todos los clientes que no se va a poder realizar operaciones por X motivo.
|
||||
`Search:` buscar un nodo
|
||||
`Modify:` modificar cualquier atributo siempre que no sea parte del DN
|
||||
`Add:` añadir un nodo
|
||||
`Delete:` eliminar un nodo
|
||||
`Modify DN:` modificar el DN
|
||||
`Compare:` comparar información entre dos DSA
|
||||
`Abandon:` parar solicitud que se ha enviado pero no ha terminado
|
||||
`Start TLS:` inicia el mecanismo de seguridad para encriptar
|
||||
`Extended:` añadir operaciones a LDAP
|
||||
BIN
TERCERO/ATR1/images/Pasted image 20240916084733.png
Normal file
|
After Width: | Height: | Size: 17 KiB |
BIN
TERCERO/ATR1/images/Pasted image 20240916084750.png
Normal file
|
After Width: | Height: | Size: 15 KiB |
BIN
TERCERO/ATR1/images/Pasted image 20240916092534.png
Normal file
|
After Width: | Height: | Size: 6.1 KiB |
BIN
TERCERO/ATR1/images/Pasted image 20240916092616.png
Normal file
|
After Width: | Height: | Size: 11 KiB |
BIN
TERCERO/ATR1/images/Pasted image 20240918110700.png
Normal file
|
After Width: | Height: | Size: 42 KiB |
BIN
TERCERO/ATR1/images/Pasted image 20240918112218.png
Normal file
|
After Width: | Height: | Size: 66 KiB |
BIN
TERCERO/ATR1/images/Pasted image 20240918114306.png
Normal file
|
After Width: | Height: | Size: 18 KiB |
BIN
TERCERO/ATR1/images/Pasted image 20240918115601.png
Normal file
|
After Width: | Height: | Size: 52 KiB |
BIN
TERCERO/ATR1/images/Pasted image 20240918120609.png
Normal file
|
After Width: | Height: | Size: 16 KiB |
BIN
TERCERO/ATR1/images/Pasted image 20240925105710.png
Normal file
|
After Width: | Height: | Size: 39 KiB |
BIN
TERCERO/ATR1/images/Pasted image 20240925110142.png
Normal file
|
After Width: | Height: | Size: 47 KiB |
BIN
TERCERO/ATR1/images/Pasted image 20240925110416.png
Normal file
|
After Width: | Height: | Size: 34 KiB |
BIN
TERCERO/ATR1/images/Pasted image 20240925111040.png
Normal file
|
After Width: | Height: | Size: 34 KiB |
BIN
TERCERO/ATR1/images/Pasted image 20240925115054.png
Normal file
|
After Width: | Height: | Size: 38 KiB |
BIN
TERCERO/ATR1/images/Pasted image 20240925120207.png
Normal file
|
After Width: | Height: | Size: 18 KiB |
BIN
TERCERO/ATR1/images/Pasted image 20240925120452.png
Normal file
|
After Width: | Height: | Size: 18 KiB |
BIN
TERCERO/ATR1/images/Pasted image 20240925120750.png
Normal file
|
After Width: | Height: | Size: 18 KiB |
BIN
TERCERO/ATR1/images/Pasted image 20240925120909.png
Normal file
|
After Width: | Height: | Size: 18 KiB |
BIN
TERCERO/ATR1/images/Pasted image 20240925121156.png
Normal file
|
After Width: | Height: | Size: 19 KiB |
BIN
TERCERO/ATR1/images/Pasted image 20240925121537.png
Normal file
|
After Width: | Height: | Size: 108 KiB |
BIN
TERCERO/ATR1/images/Pasted image 20240930133135.png
Normal file
|
After Width: | Height: | Size: 78 KiB |
BIN
TERCERO/ATR1/images/Pasted image 20240930133748.png
Normal file
|
After Width: | Height: | Size: 112 KiB |
4
TERCERO/IA/Apuntes Julia.md
Normal file
@@ -0,0 +1,4 @@
|
||||
# `!` modifica estructuras
|
||||
# `:` Symbol (Más rápido que String)
|
||||
|
||||
|
||||
290
TERCERO/IA/Teoría_2425.md
Normal file
@@ -0,0 +1,290 @@
|
||||
# <mark style="background: #FFF3A3A6;">TEMA 1: Introducción a la lógica</mark>
|
||||
## <mark style="background: #ADCCFFA6;">Lógica proposicional</mark>
|
||||
Se utiliza un conjunto de variables atómicas (T ó F, V ó F) llamadas **variables proposicionales**. Se usan unas conectivas (u operadores) los cuales son:
|
||||
- Negación ($\neg ...$)
|
||||
- Disyunción ($... \lor ...$)
|
||||
- Conjunción ($... \land ...$)
|
||||
- Implicación ($... \implies ...$)
|
||||
- Doble implicación ($... \iff ...$)
|
||||
Una forma de dar significado a las conectivas son las **Tablas de Verdad**.
|
||||
![[Pasted image 20240913105735.png|450]]
|
||||
Este tipo de problemas se llaman problemas SAT (o de satisfacción de restricciones). Son NP-Completos. El método de las tablas de verdad, es exponencial ($2^n$).
|
||||
### Consecuencia Lógica
|
||||
Una fórmula $F$ es consecuencia lógica de un conjunto **finito** de fórmulas $U$ y se denota $U\models F$, si se verifica que $F_1\land...\land F_n\rightarrow F$ es una **tautología**.
|
||||
#### <mark style="background: #BBFABBA6;">def.</mark>
|
||||
<hr>
|
||||
|
||||
**TAUTOLOGÍA:** Siempre es verdad
|
||||
|
||||
<hr>
|
||||
### Ejemplo
|
||||
<hr>
|
||||
_Si continúa la investigación, surgirán nuevas evidencias. Si surgen nuevas evidencias, entonces varios dirigentes se verán implicados. Si varios dirigentes están implicados, los periódicos dejarán de hablar del caso. Si la continuación de la investigación implica que los periódicos dejen de hablar del caso, entonces, el surgimiento de nuevas evidencias implica que la investigación continúa. La investigación no continúa. Por tanto, no surgirán nuevas evidencias._
|
||||
|
||||
$p$: Continúa la investigación
|
||||
$q$: Surgen nuevas evidencias
|
||||
$r$: Varios dirigentes se verán implicados
|
||||
$s$: Los periódicos dejarán de hablar del caso
|
||||
|
||||
Por tanto:
|
||||
|
||||
$\{p\implies q,q\implies r, r\implies s,(p\implies s)\implies (q\implies p), \neg p\}$
|
||||
|
||||
En conclusión: $!q$
|
||||
<hr>
|
||||
|
||||
### Fórmulas equivalentes
|
||||
Dos fórmulas $F_1$ y $F_2$ se dicen **equivalentes** si tienen la misma tabla de verdad, o si $F_1 \iff F_2$ es una tautología.
|
||||
|
||||
### Forma Normal Conjuntiva
|
||||
Una fórmula se dice que está en FNC (ó clausal) si es conjunción de disyunciones de literales (producto de sumas).
|
||||
|
||||
### <mark style="background: #FFB86CA6;">Algoritmo DPLL</mark>
|
||||
Este algoritmo permite calcular los modelos, lo cual no es suficiente para saber si es una tautología o no, porque hace falta también saber el número de modelos. Sin embargo, si que sirve por si mismo para saber cuando algo no es satisfactible (todas las ramas acaban en contradicción).
|
||||
#### <mark style="background: #ABF7F7A6;">Nota</mark>
|
||||
<hr>
|
||||
|
||||
$\{p,q,r\},\{\neg{p},q,r\},\{p,\neg{q}\},\{p,r\},\{p\}$
|
||||
que es igual que
|
||||
$\{p\lor{q}\lor{r}\}\land\{\neg{p}\lor{q}\lor{r}\}\land\{p\lor{\neg{q}}\}\land\{p\lor{r}\}\land\{p\}$
|
||||
|
||||
<hr>
|
||||
|
||||
![[Pasted image 20240913113533.png|450]]
|
||||
$\{□\}$ son _cláusulas vacías_ o contradicciones
|
||||
|
||||
### Otro ejemplo
|
||||
<hr>
|
||||
$(F_1\land ...\land F_n)\implies F\in~TAUT$
|
||||
$\{F_1,...,F_n,\neg F\}\notin SAT$
|
||||
<hr>
|
||||
|
||||
### Otro ejemplo
|
||||
<hr>
|
||||
$p\equiv$ Todos los hombres son mortales
|
||||
$q\equiv$ Sócrates es un hombre
|
||||
$r\equiv$ Sócrates es mortal
|
||||
|
||||
Es insuficiente para representar el problema por la independencia de las frases y por la aparición de **objetos**, **propiedades** y **cuantificadores**. Aparece la **Lógica de Primer Orden (LPO)**
|
||||
<hr>
|
||||
## <mark style="background: #ADCCFFA6;">Lógica de Primer Orden</mark>
|
||||
<span style="color:red;">NO existen métodos "mecánicos" para LPO</span>
|
||||
|
||||
Siguiendo el ejemplo de Sócrates:
|
||||
$s\equiv$ Sócrates
|
||||
$H(x)\equiv$ Es un hombre
|
||||
$M(x)\equiv$ Es mortal
|
||||
|
||||
Por tanto:
|
||||
|
||||
$$
|
||||
\left.
|
||||
\forall{x}~(H(x)\implies{M(x)})\atop
|
||||
H(s)
|
||||
\right\}\longrightarrow{
|
||||
\left.
|
||||
\forall{x}~(H(s)\implies{M(s)})\atop
|
||||
H(s)
|
||||
\right\}\longrightarrow{
|
||||
\left.
|
||||
p\implies{q}\atop
|
||||
p
|
||||
\right\}\models{q}\longrightarrow{
|
||||
\{p\implies{q},p,\neg{q}\}
|
||||
}
|
||||
}
|
||||
}
|
||||
$$
|
||||
### Ejemplo: problema de las n reinas
|
||||
<hr>
|
||||
$r_{ij}\equiv$ en la casilla $[i,~j]$ está una reina
|
||||
$r_{ij}\implies\neg{r_{i1}}\land ... \land\neg{r_{in}}$
|
||||
O también:
|
||||
$r_{ij}\implies\land|k\neq{j}~~~~\neg{r_{ik}}$
|
||||
<hr>
|
||||
|
||||
# <mark style="background: #FFF3A3A6;">TEMA 2: Problemas de Satisfacción de Restricciones</mark>
|
||||
Son problemas que básicamente extienden la LP/LPO. Proporciona más capacidad para resolver problemas, pero a su vez hace dicha resolución más compleja.
|
||||
## <mark style="background: #ADCCFFA6;">1. Definir problemas CSP</mark>
|
||||
Un problema CSP viene dado por la terna $(X,D,C)$ donde:
|
||||
- $X = \{x_1,...,x_n\}$ es un conjunto de variables
|
||||
- $D = \langle D_1,...,D_n\rangle$ es un vector de dominios ($D_i$ contiene a todos los posibles valores que puede tomar $x_i$)
|
||||
- $C$ es un conjunto finito de restricciones (valores $k-arios\equiv \{x_{i1},...,x_{ik}\}$). Cada restricción se define sobre un conjunto de $k$ variables de $X$ por medio de un predicado que restringe sus valores.
|
||||
|
||||
Una **asignación de variable** es un par $(x,a)$ (o $x=a$) que representa asignar el valor $a$ a la variable $x$. Una **asignación de un conjunto de variables** sería un conjunto de tuplas ordenadas $((x_i,a_i),...,(x_k,a_k))$ donde cada par asigna el valor $a_i\in D_i$ a $x_i$.
|
||||
|
||||
Una tupla es **localmente consistente** si satisface todas las restricciones que tienen que ver con ella.
|
||||
Un CSP es **consistente** si tiene al menos una solución. Normalmente se intenta encontrar:
|
||||
- Una solución.
|
||||
- Todas las soluciones.
|
||||
- Una solución óptima (usando una **función objetivo**).
|
||||
## <mark style="background: #ADCCFFA6;">2. Métodos de resolución</mark>
|
||||
### <mark style="background: #FFB86CA6;">Fuerza bruta</mark>
|
||||
|
||||
```
|
||||
Fuerza-Bruta
|
||||
As = D₁ × … × Dₙ
|
||||
Para cada A ∈ As:
|
||||
Si A es consistente
|
||||
Devolver A
|
||||
Parar
|
||||
Devolver false
|
||||
```
|
||||
|
||||
El inconveniente obvio de este método es que puede requerir una cantidad excesiva de memoria inicial para almacenar el conjunto completo de las asignaciones y una cantidad excesiva de tiempo para encontrar la solución en el caso peor.
|
||||
### <mark style="background: #FFB86CA6;">Backtracking (BT)</mark>
|
||||
![[Pasted image 20240920111350.png|500]]
|
||||
Las asignaciones parciales se extienden solamente cuando **NO** son inconsistentes. Al encontrar una asignación inconsistente se "poda" o deja de explorar ese espacio de asignaciones.
|
||||
|
||||
Una posible implementación (en pseudocódigo) sería:
|
||||
```
|
||||
BT(A, U)
|
||||
Si A es completa
|
||||
Devolver A
|
||||
Seleccionar una variable x de U
|
||||
U ← U − {x}
|
||||
Para cada v ∈ D(x):
|
||||
Si {x = v} es consistente con A
|
||||
res ← BT(A ∪ {x = v}, U)
|
||||
Si res ≠ false
|
||||
Devolver res
|
||||
Devolver false
|
||||
```
|
||||
|
||||
Existen algunas estrategias para la optimización de BT:
|
||||
- **Valores Mínimos Restantes (MRV):** se elige la variable no asignada con menos valores restantes válidos, ya que es posible que se quede sin valores válidos antes y que de lugar a un retroceso.
|
||||
- **Valor Menos Restrictivo (LCV):** se selecciona el valor (de variable) que elimine el menor número de valores de los dominios de los valores sin asignar restantes.
|
||||
- **Min-conflicts:** ordena los valores de acuerdo a los conflictos en los que estos están involucrados con las variables no asignadas. Esta heurística asocia a cada valor de la variable actual, el número total de valores en los dominios de las futuras variables adyacentes que son incompatibles con él. El valor seleccionado es el asociado a la suma más baja.
|
||||
# <mark style="background: #FFF3A3A6;">TEMA 3: Espacios de estados</mark>
|
||||
Esencialmente un espacio de estados es una 4-tupla $(X,S,G,T)$, donde:
|
||||
- $X$ es el conjunto de estados
|
||||
- $S\subseteq X$ es un conjunto no vacío de estados iniciales
|
||||
- $G\subseteq X$ es un conjunto no vacío de estados finales
|
||||
- $T:X\rightarrow P(X)$ es una función de transición
|
||||
El problema consiste en decidir si, partiendo desde los estados de $S$, se puede $G$ aplicando $T$.
|
||||
### <mark style="background: #FFB86CA6;">Problema: misioneros-caníbales</mark>
|
||||
Se podría representar matemáticamente de la siguiente forma:
|
||||
$(m_D,~c_D,~m_I,~c_I,~b)~o~tambien:~(m_D,~c_D,b)$ ya que $m_D+m_I=3$ y $c_D+c_I=3$
|
||||
|
||||
$S=(m_D,~c_D,b)$
|
||||
|
||||
$b=0:$
|
||||
- $(m,c)$
|
||||
- $0\leq m\leq m_I$
|
||||
- $0\leq c\leq c_I$
|
||||
- $1\leq m+c \leq 2$
|
||||
$a(m,c)\rightarrow S'=(m_I-m,~c_I-c,~1)$
|
||||
|
||||
$b=1:$
|
||||
- $(m,c)$
|
||||
- $0\leq c \leq 3·m_I$
|
||||
- $0\leq c \leq 3-c_I$
|
||||
- $1\leq m+c \leq 2$
|
||||
$a(m,c)\rightarrow S'=(m_I+m,~c_I+c,~0)$
|
||||
|
||||
$valid(S):$
|
||||
- $m_I\geq c_I$
|
||||
- $3-m_I\leq 3-c_I$
|
||||
|
||||
<hr>
|
||||
|
||||
$S\longrightarrow valido(S):$
|
||||
- $Sí\implies calcular~y~aplicar~A(S)$
|
||||
- $No\implies S'=S$
|
||||
|
||||
### <mark style="background: #FFB86CA6;">Problema: todos los dígitos del rey</mark>
|
||||
Sea el conjunto $S=\{0,...,9\}$, insertar los símbolos de los operadores aritméticos ($\times +-/$) entre ellos para que la expresión resultante se evalúe como $100$.
|
||||
$S=(+,~·,~-,~+,~+,...)$
|
||||
|
||||
## <mark style="background: #ADCCFFA6;">1. Posibles algoritmos</mark>
|
||||
|
||||
```jl
|
||||
function Generate-X-from(S)
|
||||
Fr = S
|
||||
X = Fr
|
||||
while(Fr ∩ G = ∅)
|
||||
Fr = T(Fr)
|
||||
X = X ∪ Fr
|
||||
return X
|
||||
end
|
||||
```
|
||||
1. Parte de la frontera inicial `Fr = S`
|
||||
2. Se aplican todas las $T$ posibles
|
||||
3. Se acumula `Fr` en `X` para no perder los estados obtenidos
|
||||
4. Si en `Fr` no hay elementos de `G` se vuelve a empezar hasta que lo haya y se retorne
|
||||
|
||||
Una mejora del algoritmo anterior es añadiendo una selección:
|
||||
|
||||
```jl
|
||||
function Selected-Search-from(s0)
|
||||
Fr = {s0}
|
||||
X = Fr
|
||||
while(Fr ∩ G = ∅)
|
||||
sel_s = select(Fr)
|
||||
Fr = Fr ∪ T(sel_s) - {sel_s}
|
||||
X = X ∪ Fr
|
||||
return X
|
||||
end
|
||||
```
|
||||
Donde `select()` sería una función que selecciona el estado a expandir en este paso. Por ejemplo se puede tomar `select(C) = rand(C)`, y se convertiría en búsqueda aleatoria.
|
||||
|
||||
### <mark style="background: #FFB86CA6;">Búsquedas no informadas (DFS, BFS)</mark>
|
||||
|
||||
```jl
|
||||
function bfs(vecinos::Function, s_0, G)
|
||||
# lista de tuplas que almacena el vértice actual y el camino hacia él
|
||||
bfsCola = [(s_0, [])]
|
||||
# conjunto de visitados
|
||||
visitados = Set()
|
||||
# mientras la cola esté llena
|
||||
while length(bfsCola) != 0
|
||||
# se asigna a s, camino_s el valor de la tupla actual
|
||||
s, camino_s = pop!(bfsCola)
|
||||
# si s es final, termina
|
||||
if s in G
|
||||
# devuvelve el camino de llegada al vértice final
|
||||
return camino_s, push!(visitados, s)
|
||||
end
|
||||
# si s no es final
|
||||
if s in visitados
|
||||
continue
|
||||
end
|
||||
# s se mete en el conjunto de visitados
|
||||
push!(visitados, s)
|
||||
# para cada acción y vértice se mete en la cola
|
||||
# el vértice y el camino hasta él (camino anterior
|
||||
# más la nueva acción)
|
||||
for (a_ss', s') in vecinos(s)
|
||||
push!(bfsCola, (s', push!(camino_s, a_ss') ) )
|
||||
end
|
||||
end
|
||||
return :nopath
|
||||
end
|
||||
```
|
||||
|
||||
DFS y BFS son lo que se llaman **búsquedas ciegas**.
|
||||
|
||||
### <mark style="background: #FFB86CA6;">Búsqueda informada: A*</mark>
|
||||
A* lo que hace en cada paso básicamente es:
|
||||
$g(s)=coste(s)+h^*(s)$
|
||||
Y además guarda un "historial" y mantiene la cola abierta.
|
||||
Con todo esto, intenta elegir el camino mínimo más óptimo, siendo el final del algoritmo **no el vértice final** sino **cuando el coste es mínimo**.
|
||||
#### <mark style="background: #D2B3FFA6;">EJERCICIO A*</mark>
|
||||
$A\rightarrow B:1$
|
||||
$A\rightarrow D:1$
|
||||
$A\rightarrow C:1$
|
||||
$B\rightarrow D:2$
|
||||
$C\rightarrow D:1$
|
||||
$C\rightarrow F:2$
|
||||
$D\rightarrow E:2$
|
||||
$D\rightarrow F:1$
|
||||
$E\rightarrow F:1$
|
||||
$E\rightarrow G:1$
|
||||
$F\rightarrow G:2$
|
||||
$G\rightarrow H:2$
|
||||
$F\rightarrow H:3$
|
||||
|
||||
| Nodo | $A$ | $B$ | $C$ | $D$ | $E$ | $F$ | $G$ | $H$ |
|
||||
| ----------- | --- | --- | --- | --- | --- | --- | --- | --- |
|
||||
| **h(Nodo)** | $4$ | $4$ | $3$ | $3$ | $2$ | $3$ | $2$ | $0$ |
|
||||
|
||||
BIN
TERCERO/IA/images/Pasted image 20240913105735.png
Normal file
|
After Width: | Height: | Size: 10 KiB |
BIN
TERCERO/IA/images/Pasted image 20240913113533.png
Normal file
|
After Width: | Height: | Size: 166 KiB |
BIN
TERCERO/IA/images/Pasted image 20240920111350.png
Normal file
|
After Width: | Height: | Size: 75 KiB |
BIN
TERCERO/IA/images/dpll2.jpg
Normal file
|
After Width: | Height: | Size: 128 KiB |
184
TERCERO/SPD/Teoría_2425.md
Normal file
@@ -0,0 +1,184 @@
|
||||
# <mark style="background: #FFF3A3A6;">TEMA 1: Conceptos básicos</mark>
|
||||
## <mark style="background: #ADCCFFA6;">1. Técnicas estáticas y dinámicas</mark>
|
||||
- **Estática:** compilador/programador
|
||||
- **Dinámica:** procesador (runtime)
|
||||
- **Planificación estática:** reordenar instrucciones o scheduling
|
||||
- **Planificación dinámica:** algoritmo en hardware, scheduling dinámico
|
||||
|
||||
### Ejemplo 1
|
||||
<hr>
|
||||
Sea este bucle:
|
||||
```C
|
||||
for(i=0; i<M; i++)
|
||||
y[i] = x[i] * s;
|
||||
```
|
||||
Que traducido a ensamblador sería:
|
||||
```asm
|
||||
======= ÚTILES =========================
|
||||
LF Fx, (Rx)0
|
||||
MULF
|
||||
SF (Ry)0, Fy
|
||||
|
||||
======= OVERHEAD (inútiles) =============
|
||||
ADDI ; i++;
|
||||
CMPLT ; i < M;
|
||||
BNEZ ; salto para iterar
|
||||
```
|
||||
|
||||
### Ejemplo 2: Planificación
|
||||
<hr>
|
||||
Hacer que MULTF y ADDF estén lo más separadas posible.
|
||||
```asm
|
||||
LOOP: LF Fx, (Rx)0
|
||||
LF Fy, (Ry)0
|
||||
MULTF Fax, Fx, Fa
|
||||
ADDF Faxy, Fax, Fy
|
||||
SF (Ry)0, Faxy
|
||||
ADDI Rx, Rx, 4
|
||||
ADDI Ry, Ry, 4
|
||||
SLTI Rc, Rx, Rxfin
|
||||
BNEZ Rc, LOOP
|
||||
```
|
||||
Código modificado:
|
||||
```asm
|
||||
LOOP: LF Fx, (Rx)0
|
||||
MULTF Fax, Fx, Fa
|
||||
LF Fy, (Ry)0
|
||||
ADDI Rx, Rx, 4
|
||||
ADDI Ry, Ry, 4
|
||||
SLTI Rc, Rx, Rxfin
|
||||
ADDF Faxy, Fax, Fy
|
||||
SF (Ry)-4, Faxy
|
||||
BNEZ Rc, LOOP
|
||||
```
|
||||
|
||||
## <mark style="background: #ADCCFFA6;">2. Leyes y principios. Rendimiento y productividad</mark>
|
||||
|
||||
### $t_{CPU,Sync}=n_{ciclos}\times{T_{CLK}}$
|
||||
### $t_{CPU,Pipeline}=CPI\times{T_{CLK}}\times{n_{instrucciones}}$
|
||||
### $CPI=\frac{n_{ciclos}}{n_{instrucciones}}$
|
||||
### $Rend.=\frac{1}{t_{CPU}}\rightarrow Arquitectura~~\downarrow$
|
||||
### $Productividad = \frac{Nº tareas}{S}\rightarrow SO/BD~ (mucha~I/O)$
|
||||
### $Ac_{A-B}=\frac{t_{CPU,A}}{t_{CPU,B}}\geq 1.0$
|
||||
|
||||
Razonar las siguientes afirmaciones:
|
||||
1. Mas rendimiento $\rightarrow$ más productividad. <span style="color:green;">Verdad</span>
|
||||
2. Más productividad $\rightarrow$ más rendimiento. <span style="color:red;">Falso</span>
|
||||
3. Más máquinas en paralelo $\rightarrow$ más rendimiento. <span style="color:red;">Falso</span>
|
||||
4. Más máquinas en paralelo $\rightarrow$ más productividad. <span style="color:green;">Verdad</span>
|
||||
|
||||
![[Pasted image 20240930084659.png]]
|
||||
### Sobre el CPI...
|
||||
- El CPI aumenta si la máquina **NO** está optimizada. Pero **SI LO ESTÁ**, el CPI ideal se vuelve 1.
|
||||
- Hoy en día el CPI es **NO ADITIVO**, y suele ser $\lt{1}$. Para calcularlo, se suele usar el caso peor (bottleneck).
|
||||
Existen "tipos" de CPI:
|
||||
- $CPI_{datos}\equiv$ Dependencias
|
||||
- $CPI_{estructural}\equiv$ Bloqueos porque todos los recursos (U.F.) están en uso.
|
||||
- $CPI_{control}~(flujo)~\equiv$ Saltos buscan instrucción siguiente $\rightarrow$ rompe la cadena.
|
||||
- $CPI_{memoria}\equiv$ Memoria RAM lenta. Favorecen el cacheado eficiente.
|
||||
|
||||
### <mark style="background: #FFB86CA6;">Ley de Amdahl</mark>
|
||||
Lo importante de la Fracción del sistema es dónde se puede optimizar y no tanto la aceleración parcial.
|
||||
![[Pasted image 20240916121903.png|350]]
|
||||
### $t_{CPU,inicial}=1$
|
||||
### $t_{CPU,final}=(1-F)+\frac{F}{A_{P}}$
|
||||
|
||||
### $A_{total}=\frac{t_{CPU,inicial}}{t_{CPU,final}}$
|
||||
|
||||
### <mark style="background: #FFB86CA6;">Ley 10/90 (Principio de localidad)</mark>
|
||||
|
||||
**Nota**
|
||||
>10% programa contiene el 90% del $t_{CPU}$
|
||||
|
||||
Gracias al principio de localidad las cachés funcionan. Comparando el principio en datos e instrucciones:
|
||||
- Instrucciones: se cumple muy bien excepto en los saltos. MR casi 1% en caché $L1_{instrucciones}$.
|
||||
- Datos: se cumple peor. MR casi 5-10% en $L1_{datos}$.
|
||||
Existen localidad temporal y espacial:
|
||||
- Temporal: si se acede a una dirección, pronto se accederá otra vez.
|
||||
- Espacial: si se accede a D, también se accederá eventualmente a D+1, D+2... (bloque o línea de caché).
|
||||
### <mark style="background: #FFB86CA6;">Otras medidas de rendimiento</mark>
|
||||
<div class="nota"><h4>NOTA</h4><p>Todas pueden tener el prefijo correspondiente a la magnitud (Tera, Giga, Mega...)</p></div>
|
||||
**IPS (Instrucciones Por Segundo)**
|
||||
**FLOPs (Floating Point OPerations)**:
|
||||
- Sólo + - / * y trascendentes (todos valor 1 FLOP)
|
||||
- Para código científico/multimedia (ejemplo TFLOPs en GPUs)
|
||||
**FMA (Fused Multiply Add)**: $SAXPY\Rightarrow a*\vec{x}+\vec{y}$
|
||||
**MACS (Multiply-ACcumulate)**: $Sumatorio\Rightarrow a=a+b*c$
|
||||
### <mark style="background: #FFB86CA6;">Rendimiento de máquina (comparativa)</mark>
|
||||
<div class="nota">
|
||||
<h4>NOTA</h4>
|
||||
<p>La media aritmética castiga un valor bajo. El cociente de la media de N tiempos es igual a la media de aceleraciones. La media aritmética no cumple con esto.</p>
|
||||
<p>Se pueden comparar dos máquinas respecto a otra de referencia, normalizando respecto a la media geométrica de referencia (nunca la aritmética)</p>
|
||||
<img src="C:\Users\jomaa\OneDrive\Educasao\Universidad\ETSII_Vault\TERCERO\SPD\images\medias.png"/>
|
||||
</div>
|
||||
Colecciones de benchmarks:
|
||||
```mermaid
|
||||
graph TD;
|
||||
1(3 clasicas) --> 2(SPEC)
|
||||
2(SPEC) -- Muchos organismos \n 15 o 20 benchmarks --> 5(Hoy)
|
||||
5(Hoy) --> 6(FP/INT)
|
||||
5(Hoy) --> 7(multicore)
|
||||
5(Hoy) --> 8(I/O)
|
||||
5(Hoy) --> 9(Servidores)
|
||||
|
||||
1(3 clasicas) --> 3(TPC)
|
||||
3(TPC) -- Transaction Processing Council \n solo I/O --> 10(Bancos)
|
||||
|
||||
1(3 clasicas) --> 4(EEMBC)
|
||||
4(EEMBC) -- Embedded Microprocessor \n Benchmark Consortium --> 11(En sistemas empotrados)
|
||||
```
|
||||
### <mark style="background: #FFB86CA6;">Ley de Moore (1965, Intel)</mark>
|
||||
La tecnología aumenta cierto porcentaje cada año (cada 3 años se multiplica por 4 el número de transistores).
|
||||
![[Ley_de_Moore.png]]
|
||||
### <mark style="background: #FFB86CA6;">Lenguajes compilados VS interpretados</mark>
|
||||
```mermaid
|
||||
graph TD;
|
||||
1((ALGORITMO)) -- Python/Java --> 2[Código HLL]
|
||||
1((ALGORITMO)) -- C/C++ --> 3[Código HLL]
|
||||
2[Código HLL] -- Intérprete --> 4[Meta ensamblador]
|
||||
3[Código HLL] -- Compilador \n Análisis global --> 5[OBJ]
|
||||
8[S.O. + librerías] --> 6[Máquina virtual]
|
||||
8[S.O. + librerías] --> 7[Linkado y .exe nativo]
|
||||
4[Meta ensamblador] --> 6[Máquina virtual]
|
||||
5[OBJ] --> 7[Linkado y .exe nativo]
|
||||
6[Máquina virtual] -- Traducción --> 9[Ensamblador nativo]
|
||||
7[Linkado y .exe nativo] --> 10[CPU]
|
||||
9[Ensamblador nativo] --> 10[CPU]
|
||||
```
|
||||
# <mark style="background: #FFF3A3A6;">TEMA 3: Paralelismo a nivel de instrucciones (ILP)</mark>
|
||||
## <mark style="background: #ADCCFFA6;">1. Técnicas de planificación dinámicas</mark>
|
||||
### $t_{CPU}=N_{instr}\times CPI\times T_{CLK}$
|
||||
|
||||
1. Para reducir el $N_{instr}$ lo que obtenemos es una máquina VLIW (Very Long Instruction Word), en la que usamos macroinstrucciones (128 ó 256 bits). En estas máquinas hay muchas instrucciones RISC. Si hay operaciones **SIN** dependencia $\Rightarrow$ La reordenación depende del compilador.
|
||||
2. Si reducimos el $CPI$, obtenemos máquinas superescalares donde por cada ciclo se ejecutan varias instrucciones
|
||||
$$\begin{equation}
|
||||
CPI = \frac{1}{m}, m\equiv grado~de~escalaridad
|
||||
\end{equation}
|
||||
$$
|
||||
3. El bajar el $T_{CLK}$, a día de hoy se ha saturado la frecuencia. <u>Truco</u>: superpipeline/superencadenamiento.
|
||||
![[Imagen de WhatsApp 2024-10-09 a las 21.20.30_7d2eb4f4.jpg|500]]
|
||||
La lectura es doble porque $m=2$. Múltiples puertos (AB, DB).
|
||||
|
||||
<u>Pág 15</u>
|
||||
![[Imagen de WhatsApp 2024-10-09 a las 21.34.14_bd89b69c.jpg|500]]
|
||||
Con técnicas dinámicas se anotan las RAWs, por lo que sólo hay ciclos de espera de las instrucciones dependientes:
|
||||
![[Imagen de WhatsApp 2024-10-09 a las 21.39.25_22abea24.jpg|500]]
|
||||
El **algoritmo de Tomasulo (1967)** es un algoritmo distribuido que anota las dependencias reales en las RS (Reservation Station).
|
||||
![[Imagen de WhatsApp 2024-10-09 a las 22.00.36_cbfd6ee8.jpg|500]]
|
||||
El contenido de las RS está formateado de la siguiente forma:
|
||||
![[Imagen de WhatsApp 2024-10-09 a las 22.05.13_e4102573.jpg|500]]
|
||||
### <mark style="background: #FFB86CA6;">5 casos de bloqueo</mark>
|
||||
1. Muchos RAW (como ADD o MUL).
|
||||
$\frac{duracion}{iteracion}=duración~de~ADD~ó~MUL~(EX+WB)$
|
||||
5. UF no segmentada (no permite encadenamiento). Normalmente con instrucciones complejas como DIV, SQRT, LOG, TRIGON, aunque no haya RAWs.
|
||||
2. Balanceo de UF respecto a tipos de instrucción (no importan las RAWs).
|
||||
- Acceso a memoria
|
||||
- Todo INT
|
||||
- Matemática en la GPU
|
||||
3. (y 4.) son casos estadísticos:
|
||||
4. Depende del % de aciertos del predictor de saltos ó **BTB (Branch Target Buffer)**. Si no falla es muy probable que el CPI sea ideal. Si hay al menos 1 fallo del BTB: se vacían las colas de instrucciones (ABORT $\rightarrow$ `AB`).
|
||||
$$
|
||||
\begin{equation}
|
||||
CPI_{BLOQ}=\frac{ciclos_{BLOQ}}{1~fallo~predicción}\times\frac{F~fallos}{100~saltos}\times\frac{K~saltos}{100~instrucciones}
|
||||
\end{equation}
|
||||
$$
|
||||
BIN
TERCERO/SPD/images/550px-Ley_de_Moore.png
Normal file
|
After Width: | Height: | Size: 55 KiB |
BIN
TERCERO/SPD/images/Ley_de_Moore.png
Normal file
|
After Width: | Height: | Size: 22 KiB |
BIN
TERCERO/SPD/images/Pasted image 20240916121903.png
Normal file
|
After Width: | Height: | Size: 14 KiB |
BIN
TERCERO/SPD/images/Pasted image 20240930084659.png
Normal file
|
After Width: | Height: | Size: 46 KiB |
BIN
TERCERO/SPD/images/medias.png
Normal file
|
After Width: | Height: | Size: 47 KiB |
119
TERCERO/SS/SS 24-25.md
Normal file
@@ -0,0 +1,119 @@
|
||||
# <mark style="background: #FFF3A3A6;">TEMA 1: Introducción</mark>
|
||||
Aunque la sintaxis de Java derive de C, NO son tan similares. Hay que entender el ámbito del lenguaje: por ejemplo C (Software de Sistemas, sustitución de assembly, etc) o Java (aplicaciones, etc). Existen palabras reservadas con más de un uso (`static` o `const`).
|
||||
|
||||
> **C++ amplia el ámbito de C**
|
||||
|
||||
## <mark style="background: #ADCCFFA6;">1. Introducción y características</mark>
|
||||
### <mark style="background: #FFB86CA6;">Estandarización</mark>
|
||||
Los estándares más usados para C y C++ son el 99 y 98 respectivamente.
|
||||
```C
|
||||
#include "archivo.h"
|
||||
// "pega" archivo.h y sigue compilando
|
||||
void main() {
|
||||
|
||||
}
|
||||
```
|
||||
Dependiendo del compilador se pueden especificar directivas como `#pragma once` para solo incluir el archivo una vez.
|
||||
|
||||
### ⚠ Incongruencia
|
||||
C/C++ es portable para **aplicaciones** pero para Software de Sistemas **NO** $\rightarrow$ siempre habrá problemas de portabilidad. **SÍ** que es portable desde el punto de vista de los 80:
|
||||
- Hay compilador C para cualquier arquitectura.
|
||||
- Si sé C, puedo programar en cualquier arquitectura.
|
||||
- El código fuente es compatible.
|
||||
|
||||
### <mark style="background: #FFB86CA6;">Nivel de abstracción</mark>
|
||||
Varía de un lenguaje a otro (C tiene menor nivel de abstracción que los lenguajes modernos). Las estructuras del lenguaje y funcionamiento general son lo más parecido al código máquina. C++ tiene mayor nivel de abstracción pero aumenta la sobrecarga.
|
||||
|
||||
### <mark style="background: #FFB86CA6;">Runtime, librerías, frameworks</mark>
|
||||
**Runtime** es el código que añade el compilador, que no está asociado al código de usuario sino al lenguaje. En C es mínimo, por eso se prefiere para sistemas empotrados.
|
||||
|
||||
### <mark style="background: #FFB86CA6;">Relación C/C++</mark>
|
||||
Compatible C -> C++. Las extensiones mas importantes de C++ son POO, tipado, librerías...
|
||||
La mayor parte de compiladores son duales. La extensión del archivo determina si hay que compilar C (.c, .h) o C++ (.cpp, .hpp ó .hh).
|
||||
|
||||
### <mark style="background: #FFB86CA6;">Java VS C/C++</mark>
|
||||
|
||||
| **Java** | **C** | **C++** |
|
||||
| ----------------------------------------------------------------------------------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ------- |
|
||||
| El programa se compone de clases (propiedades y métodos). | El programa es un conjunto de datos y funciones, **no existen clases**. | |
|
||||
| Para ejecutar un programa, se empieza por el punto de entrada (main) y se van instanciando, modificando, destruyendo objetos. | Para ejecutar un programa, se empieza por el punto de entrada (main), se inicializan las variables globales y se van creando, modificando variables y ejecutando funciones. | |
|
||||
| Base de programación: Objetos | No hay base de programación | |
|
||||
| La unidad de compilación es el fichero (o clase pública). | La unidad de compilación es el fichero. | |
|
||||
| <span style="color:red">Básicamente, típico lenguaje orientado a objetos</span> | <span style="color:red">Básicamente, típico lenguaje imperativo (procedural)</span> | |
|
||||
## <mark style="background: #ADCCFFA6;">2. Programar en C/C++</mark>
|
||||
A diferencia de Java, que declarar y definir se realiza a la vez:
|
||||
```java
|
||||
public class Persona {
|
||||
private String name;
|
||||
|
||||
...
|
||||
|
||||
public String getName() {
|
||||
return this.name;
|
||||
}
|
||||
}
|
||||
```
|
||||
En C/C++ se debe declarar primero la función para que al compilar, la primera pasada la "registre", y luego a la hora de ejecutar, se pueda ejecutar dicha función.
|
||||
```C
|
||||
void funcion(); // declaración
|
||||
|
||||
int main()
|
||||
{
|
||||
funcion();
|
||||
return 0;
|
||||
}
|
||||
|
||||
void funcion()
|
||||
{
|
||||
// definición
|
||||
}
|
||||
```
|
||||
En C/C++ se pueden usar sentencias `#include` para "importar" archivos que contienen declaraciones (de variables, funciones, etc)
|
||||
### <mark style="background: #FFB86CA6;">Tipos de datos</mark>
|
||||
**Variables:**
|
||||
- `char` = 8 bits (-128, 127)
|
||||
- `unsigned char` = 8 bits (0, 255)
|
||||
- `short int` = 16 bits
|
||||
- `int` = 32 bits
|
||||
- `long int` = 32 bits
|
||||
- `long long int` = 64 bits
|
||||
**En cuanto a punteros:**
|
||||
- `<tipo>*` 32 bits (x86) 64 bits (x64)
|
||||
# <mark style="background: #FFF3A3A6;">TEMA 2: Depuración</mark>
|
||||
|
||||
## <mark style="background: #ADCCFFA6;">1. Introducción</mark>
|
||||
El depurador es una herramienta para diseccionar el código y poder analizarlo para arreglar los errores. En ingeniería se sigue la regla "Para matar moscas mejor usar un matamoscas que un cañón. "
|
||||
## <mark style="background: #ADCCFFA6;">2. Tipos de error</mark>
|
||||
Los errores son comportamientos no deseados del código causados por la inexperiencia (al principio) o falta de atención del programador.
|
||||
### <mark style="background: #FFB86CA6;">Errores sintácticos</mark>
|
||||
Son los errores más fáciles de detectar y corregir. El compilador suele detectar todos y decirte dónde están y qué los causa (pero no siempre). Suelen provocar más errores en cadena.
|
||||
### <mark style="background: #FFB86CA6;">Errores lógicos/semánticos</mark>
|
||||
Más difíciles de detectar (ninguna herramienta los detecta del todo bien) pero relativamente fáciles de corregir.
|
||||
### <mark style="background: #FFB86CA6;">Errores de diseño</mark>
|
||||
Todos los componentes del sistema funcionan pero el sistema no hace lo esperado. Problemas asociados a la Ing. del Software. Muy difíciles de detectar y costosos de arreglar.
|
||||
## <mark style="background: #ADCCFFA6;">3. Fases del tratamiento de errores</mark>
|
||||
Hay una serie de pasos comunes (pero no infalibles):
|
||||
- Detectar el problema
|
||||
- Recolectar datos
|
||||
- Diagnóstico
|
||||
- Reparación
|
||||
- Verificación
|
||||
### <mark style="background: #FFB86CA6;">Detección del problema</mark>
|
||||
Hay varias herramientas:
|
||||
- **Warnings:** muchas veces son la posible causa de errores futuros. Se deberían arreglar siempre que se pueda, pero OJO: algunas veces son <span style="color:rgb(255, 0, 0)">falsos positivos</span>.
|
||||
### <mark style="background: #FFB86CA6;">Controlar la ejecución</mark>
|
||||
Los computadores actuales no son capaces de determinar la información importante para dar con un error. Para eso se usa el **depurador**, que aunque no te da la causa del error como tal, si que se puede descubrir "pidiéndole" la información adecuada.
|
||||
### <mark style="background: #FFB86CA6;">Inspección de estado</mark>
|
||||
**Contexto:** datos accesibles en medio de la ejecución (variables locales o globales, parámetros...).
|
||||
### <mark style="background: #FFB86CA6;">Pila de llamadas y marco de pila</mark>
|
||||
La pila de llamadas es un bloque de memoria que el S.O. asigna al programa para llamadas y retornos de funciones. Si este se llena, se produce un "stack overflow". El marco de pila es básicamente la región de la pila marcada por los punteros ESP (límite superior de la pila) y EBP (inicio de marco de pila), que pertenece a una función.
|
||||
|
||||
![[Pasted image 20241003113528.png|500]]
|
||||
# <mark style="background: #FFF3A3A6;">TEMA 3: Generación de programas</mark>
|
||||
## <mark style="background: #ADCCFFA6;">1. Introducción</mark>
|
||||
Es conveniente conocer como se genera el código:
|
||||
- qué es un programa ejecutable
|
||||
- cómo se trata desde el punto de vista del SO y del IDE
|
||||
y qué elementos intervienen en la generación del ejecutable:
|
||||
- compiladores y linkers
|
||||
- archivos objeto, runtime, bibliotecas estáticas y dinámicas
|
||||
24
TERCERO/SS/SS Lab.md
Normal file
@@ -0,0 +1,24 @@
|
||||
# Práctica 1
|
||||
<hr>
|
||||
### Ejercicio 1.2.
|
||||
El código debería detectar una pulsación de tecla (`_kbhit`) dentro del _timer_ de 10s e imprimirla por consola si existe (`_getch`) y en caso contrario, imprimir que no se ha pulsado ninguna.
|
||||
### Ejercicio 1.3.
|
||||
No. Devuelve 0 siempre ya que la variable tecla está definida como variable local dentro del bucle `for` en `smt4497-P1.cpp`.
|
||||
### Ejercicio 1.4.
|
||||
Una refactorización para que quede más limpio el código es usar un **fichero de inclusión de proyecto**
|
||||
|
||||
_smt4497-P1.h_
|
||||
```C
|
||||
#pragma once
|
||||
|
||||
#define _CRT_SECURE_NO_WARNINGS
|
||||
#include <stdio.h>
|
||||
#include <conio.h>
|
||||
#include <windows.h>
|
||||
|
||||
int esperaPulseTecla(int toutMs);
|
||||
```
|
||||
### Ejercicio 1.5.
|
||||
El modo `release` es más rápido que el `debug` al usar la optimización del compilador, haciendo desaparecer algunas funciones y por tanto algunos breakpoints.
|
||||
### Ejercicio 1.8.
|
||||
Cuenta mientras no pulses una tecla. Al llegar a 2147483647 se desborda.
|
||||
BIN
TERCERO/SS/images/Pasted image 20241002112049.png
Normal file
|
After Width: | Height: | Size: 42 KiB |
BIN
TERCERO/SS/images/Pasted image 20241002112350.png
Normal file
|
After Width: | Height: | Size: 55 KiB |
BIN
TERCERO/SS/images/Pasted image 20241002112436.png
Normal file
|
After Width: | Height: | Size: 55 KiB |
BIN
TERCERO/SS/images/Pasted image 20241003113528.png
Normal file
|
After Width: | Height: | Size: 12 KiB |