Perguntas[c](coding)

Quero usar a operação de varredura inclusiva no OpenMP para implementar um algoritmo. O que se segue é uma descrição da minha tentativa de fazer isso, e não conseguindo mais do que uma aceleração morna.

A operação inclusiva é definida como segue: para um vetor de entrada, digamos que [x1,x2,x3,x4]ele produz a sequência de somas parciais [x1, x1+x2, x1+x2+x3, x1+x2+x3+x4]. Esta é uma operação altamente paralelizável e aparentemente foi bem implementada no OpenMP.

Dei uma olhada na seguinte referência: https://theartofhpc.com/pcse/omp-reduction.html#Scanprefixoperations (A referência do manual https://www.openmp.org/spec-html/5.0/openmpsu45.html#x68-1940002.9.6 parece muito enigmática para mim agora)

O site artofhpc diz que a cláusula de redução recebe um modificador inscan:

#pragma omp parallel for reduction(inscan,+:sumvar)`

No corpo do loop paralelo há uma diretiva scan que permite que você armazene os resultados parciais. Para scans inclusivos, a variável reduction é atualizada antes do pragma scan:

  sumvar // update
#pragma omp scan inclusive(sumvar)
  partials[i] = sumvar

Tentei seguir a mesma sintaxe, para medir o desempenho versus redução serial padrão e os resultados foram bem decepcionantes. Meu código está no final do post.

No código, estou apenas fazendo um teste simples considerando um vetor muito grande de tamanho 90 milhões consistindo de valores aleatórios no intervalo [-1,1], e realizando uma varredura nele usando um número crescente de threads e medindo a aceleração. Aqui estão meus resultados (recebo a mesma resposta em execuções repetidas). A CPU do meu laptop tem 16 threads de hardware, mas a aceleração geral é decepcionante 1,36. (Eu esperaria algo substancialmente maior!)

Há algo errado na maneira como estou usando a sintaxe OpenMP para redução?

➜  Desktop gcc -fopenmp scantest.c  && ./a.out

NumThreads  Speedup
1        0.458
2        1.173
3        1.424
4        1.686
5        1.635
6        1.501
7        1.522
8        1.499
9        1.455
10       1.416
11       1.395
12       1.393
13       1.352
14       1.336
15       1.353
16       1.357

#include<stdio.h>
#include<omp.h>
#include<math.h>
#include<stdlib.h>
#include<assert.h>

int main(int argc, char** argv){

  int N = 9e7;     // vector size 
  double* x;                   // vector to reduce
  double* partials_s;          // vector to scan into
  double* partials_p;          // vector to scan into
  
  double end, start;           // timing variables
  double sumvar;
  
  int tmax = argc>1? atoi(argv[1]):35;
  int threadcount ;

  // Allocate space for all vectors
  x           = (double*) malloc(sizeof(double)*N);
  partials_s  = (double*) malloc(sizeof(double)*N);
  partials_p  = (double*) malloc(sizeof(double)*N);
    
  // Populate the input vectors
  for(int i=0 ; i<N ; ++i){
    x[i] = -1+2.0*rand()/(double)RAND_MAX;
    partials_s[i] = 0.0;
    partials_p[i] = 0.0;
  }

  //-----------------------------------------
  // Serial inclusive scan
  //-----------------------------------------
  start = omp_get_wtime(); 
  sumvar = 0.0;
  for(int i=0 ; i<N ; ++i){
      sumvar += x[i];
      partials_s[i] = sumvar;
  }
  end = omp_get_wtime();
  double stime = end-start; // Time to run the serial code


  //-----------------------------------------------------------------------------
  // Performance of parallel inclusive scan. Print ratio of serial/parallel time
  //----------------------------------------------------------------------------
  printf("\nNumThreads  Speedup \n");
  for(threadcount=1;threadcount<=tmax;++threadcount){

    start = omp_get_wtime();

    sumvar = 0.0;
    #pragma omp parallel for num_threads(threadcount) reduction(inscan,+:sumvar)
    for(int i=0 ; i<N ; ++i){

      sumvar = sumvar + x[i]; // updating the value of sumvar
      #pragma omp scan inclusive(sumvar)
      partials_p[i] = sumvar;
    }
    end = omp_get_wtime();
    double ptime = end-start;

    printf("%d \t %.3f\n",threadcount,stime/ptime);

  }

  //for(int i=0 ; i<N ; ++i){
  //  printf("%.4f  %.4f\n", partials_s[i], partials_p[i]);
  //}

  // Deallocate
  free(x);
  free(partials_s);
  free(partials_p);
  
  return 0;
}

Tenho o seguinte código C que grava em um arquivo tanto do processo pai quanto do filho após um fork(). No entanto, a saída em testfile.txtàs vezes é corrompida ou está em uma ordem inesperada.

Estou anexando o código:

#include <stdio.h>
#include <stdlib.h>
#include <unistd.h>
#include <fcntl.h>

int main() {
    int fd = open("testfile.txt", O_WRONLY | O_CREAT, 0644);
    if (fd == -1) {
        perror("open");
        return 1;
    }

    if (fork() == 0) { 
        // Child process
        write(fd, "Child\n", 6);
        close(fd);
    } else {
        // Parent process
        write(fd, "Parent\n", 7);
        close(fd);
    }

    return 0;
}

Emitir :

• O arquivo às vezes contém "Child\nParent\n"e outras vezes"Parent\nChild\n"
• Em alguns casos, a saída é corrompida ou misturada
• Eu esperava que cada processo fosse escrito separadamente, mas eles parecem interferir um no outro

Pergunta:

1. Por que isso está acontecendo?
2. Como posso garantir gravações corretas e separadas de cada processo?

Cenário

Tenho um bug estranho em que, quando adiciono uma variável aleatória ao código, ele altera a saída. Descobri o que estava causando o problema, mas não tenho certeza do porquê.

O código tem a intenção de validar números de cartão de crédito usando o Algoritmo de Luhns . Ele faz parte do curso edX CS50, no entanto, decidi experimentá-lo sem suas bibliotecas personalizadas em uma tentativa de aprender o máximo possível.

O problema que estou enfrentando é que, se eu executar o código abaixo como está, a resposta sai errada (ou seja, um '9' anexado à saída inteira). Agora, se eu descomentar ou int random_integer = 0; , char random_character = 'M'; a saída funciona inteiramente como o esperado.

• Saída errada (deixando essas variáveis ​​aleatórias comentadas):209
• Saída correta (descomentar uma (ou ambas) dessas variáveis ​​aleatórias):20

Estranhamente, notei que se eu mudar char sum_to_str[3];para char sum_to_str[10];, o problema desaparece completamente.

Por favor, deixe-me saber o que você pensa, pois sou novato em C e estou interessado em entender as nuances.

Código

#include <stdio.h> // For Standard Input/Output
#include <stdlib.h> // For the atoi() function
#include <string.h> // For the strchr() and strlen() functions

// This value is the length plus one
#define MAX_INPUT_LENGTH 255

int main(void) {
    char user_input[MAX_INPUT_LENGTH];
    char *p;

    // Output CLI instructions
    printf("Welcome to the Credit Card Validator!!\n");
    printf("INSTRUCTIONS: At the prompt, please provide a CC number.\n");
    printf("NOTES ON LENGTH: Visa -> 13 || 16, AmEx -> 15 and MC -> 16\n");

    // Algorithm
    char example_card_num[] = "4003600000000014";

    // Check the length
    int card_num_length = strlen(example_card_num);

    int skip_flag = 0;
    int sum_of_values = 0;
    char value_at_index;
    char str_of_evens[20];
    for (int i = card_num_length - 1; i >= 0; i--) {
        char sum_to_str[3];
        switch (skip_flag) {
            case 0:
                // Add 'odd' values together
                value_at_index = example_card_num[i];
                sum_of_values = sum_of_values + atoi(&value_at_index);

                // Toggle flag
                skip_flag = 1;
                break;
            case 1:
                // Add 'even' values together (with multiplier)
                value_at_index = example_card_num[i];

                // 1. Convert each str to int
                // 2. Multiply by two
                // 3. Convert back to str in new variable
                sprintf(sum_to_str, "%d", (atoi(&value_at_index) *2));

                // Concatenate each substring to a new string
                strcat(str_of_evens, sum_to_str);
                 
                // Toggle flag
                skip_flag = 0;
                break;
        }
    }

    // int random_integer = 0;
    // char random_character = 'M';

    char value_at_index_two;
    for (int i = 0; i < strlen(str_of_evens); i++) {
        value_at_index_two = str_of_evens[i];
        sum_of_values = sum_of_values + atoi(&value_at_index_two);
    }

    printf("~~~~~~~~~~~\n");
    printf("Sum of Values 01: %d\n", sum_of_values);

    // Terminate the program
    return 0;
}

Eu tentei o seguinte:

• Comentando/descomentar e int random_integer = 0;depois recompilando
• Adicionando char random_character = 'M';e alternando como um comentário e recompilando
• Modificou o char sum_to_str[3];parachar sum_to_str[3];

Também tentei alterar a entrada (ou seja, example_card_num[]) ligeiramente para determinar se havia algo gerando um "9" arbitrário ou se o número anexado mudou, o que aconteceu.

Enquanto aprendia sobre como as macros funcionam, tentei definir uma macro que funcionasse com diferentes tipos de dados sem ter que definir vários tipos. Eu costumava _Generictornar essa tarefa mais fácil. No entanto, depois que não funcionou, mesmo depois de fazer alterações várias vezes, pedi ao deepseek para descobrir, o que eventualmente resultou nisso:

#define FOO(var) _Generic((var), \
    int:    printf(#var " = %d\n", (int)(var)), \
    double: printf(#var " = %lf\n", (double)(var)), \
    long:   printf(#var " = %ld\n", (long)(var)), \
    char:   printf(#var " = '%c'\n", (char)(var)), \
    float:  printf(#var " = %f\n", (float)(var)), \
    default:printf(#var " = unknown type\n"))

int main(void) {
    int a = 3;
    FOO(a); // correctly prints "a = 3"
}

Em outros exemplos de código na referência cpp e no SO, nunca vi ninguém tendo que fazer typecast para fazer isso funcionar. Remover os typecasts ( int: printf(#var " = %d\n",(var)), \...) mostra um aviso "O formato especifica o tipo 'long', mas o argumento tem o tipo 'int'" e fornece um aviso de compilação ( -Wallhabilitado):

ue_05.c: In function ‘main’:
ue_05.c:47:14: warning: format ‘%lf’ expects argument of type ‘double’, but argument 2 has type ‘int’ [-Wformat=]
   47 |         FOO(a);
      |              ^
ue_05.c:27:25: note: in definition of macro ‘FOO’
   27 |         double: printf(#var " = %lf\n", (var)), \
      |                         ^~~
ue_05.c:47:14: warning: format ‘%ld’ expects argument of type ‘long int’, but argument 2 has type ‘int’ [-Wformat=]
   47 |         FOO(a);
      |              ^
ue_05.c:28:25: note: in definition of macro ‘FOO’
   28 |         long:   printf(#var " = %ld\n", (var)), \
      |                         ^~~
ue_05.c:47:14: warning: format ‘%f’ expects argument of type ‘double’, but argument 2 has type ‘int’ [-Wformat=]
   47 |         FOO(a);
      |              ^
ue_05.c:30:25: note: in definition of macro ‘FOO’
   30 |         float:  printf(#var " = %f\n", (var)), \

Não consegui descobrir por que o typecast é necessário aqui e o deepseek também não conseguiu esclarecer as coisas.

Por que o typecast é necessário aqui e onde ele está documentado?

Em muitos casos, compilamos um programa C e executamos o binário sem nos preocuparmos com mudanças no arquivo fonte original. No entanto, estou curioso:

É possível que um programa C em execução detecte se seu próprio .carquivo de origem foi modificado após a compilação?

Algumas restrições a considerar:

• O programa deve verificar se há modificações em seu próprio arquivo de origem, não apenas no binário ( a.out)
• Não deve depender de ferramentas externas como md5sumou statpor meio system()de chamadas.
• A solução deve funcionar em sistemas operacionais comuns (Linux/Windows)
• Isso deve ser feito puramente em C, usando bibliotecas de sistema padrão ou amplamente disponíveis.

Isso exigiria a leitura do arquivo de origem em tempo de execução e a comparação de registros de data e hora ou hashes, ou existe uma maneira mais elegante de fazer isso?

Em um grande arquivo de cabeçalho C onde define muitos struct, como o seguinte,

struct s1 {
  ...
};

struct s2{
  int var_1;
  int var_2;
  int var_3;

  ...
  int var_200;
  ...

  int var_500;
};

struct s3{
  ...
};

Quero saber var_200a qual pertence struct, neste caso, é s2.

Rolar para cima neste caso não é apenas lento, mas também fácil de perder a chave correta (porque pode haver structno struct, pode haver muitas chaves). Existe algum bom método para fazer isso?

De acordo com o Padrão C :

Cada tipo complexo tem os mesmos requisitos de representação e alinhamento de um tipo de matriz contendo exatamente dois elementos do tipo real correspondente; o primeiro elemento é igual à parte real e o segundo elemento à parte imaginária do número complexo.

Dessa forma, é possível lançar com segurança a _Complex float *em a float *e então acessar os componentes reais/imaginários usando o float *? Ou isso ainda violaria tecnicamente o aliasing estrito e, portanto, invocaria um comportamento indefinido?

_Complex float c;

((float *)&c)[0] = 1;
((float *)&c)[1] = 2;

c; // 1 + 2i

Acredito que me deparei com um caso ambíguo no padrão C em relação ao escopo de objetos declarados na primeira cláusula de um forloop em comparação com objetos declarados no corpo do loop.

Dado o seguinte código:

for (int i = 1; i < 5; i++) {
    int i = 2;
    printf("%d ", i);
}

À primeira vista, parece que a declaração identro do corpo do loop está em um escopo interno em comparação ao ideclarado na primeira cláusula do forloop.

A seção 6.2.1p4 do padrão C23 afirma o seguinte em relação aos identificadores de escopo de bloco :

Se o declarador ou especificador de tipo que declara o identificador aparecer dentro de um bloco ou dentro da lista de declarações de parâmetros em uma definição de função, o identificador tem escopo de bloco , que termina no final do bloco associado

E 6.2.2p6 sobre ligação :

Os seguintes identificadores não têm vinculação: um identificador declarado como algo diferente de um objeto ou uma função; um identificador declarado como um parâmetro de função; um identificador de escopo de bloco para um objeto declarado sem o especificador de classe de armazenamentoextern .

Portanto, ambos têm escopo de bloco e nenhuma vinculação.

Entretanto, olhando para 6.2.1p6 que diz o seguinte sobre a comparação de escopos:

Dois identificadores têm o mesmo escopo se e somente se seus escopos terminam no mesmo ponto.

E 6.8.5.3p1 sobre a fordeclaração diz o seguinte sobre o escopo dos identificadores que declara:

Se a cláusula 1 for uma declaração, o escopo de quaisquer identificadores que ela declara é o restante da declaração e o loop inteiro, incluindo as outras duas expressões; ele é alcançado na ordem de execução antes da primeira avaliação da expressão de controle

Juntando tudo isso, parece que ambos os objetos declarados como itêm escopos que terminam no mesmo ponto, ou seja, a chave de fechamento do forloop (ou seja, o fim de "todo o loop") e, portanto, têm o mesmo escopo e, além disso, ambos não têm vinculação.

Isso seria então uma violação de restrição conforme 6.7p3:

Se um identificador não tiver vinculação, não deverá haver mais de uma declaração do identificador (em um declarador ou especificador de tipo) com o mesmo escopo e no mesmo espaço de nomes.

Mas nenhum compilador que testei exibe qualquer diagnóstico.

Intuitivamente, parece que isso deveria ser permitido.

Isso é um defeito no padrão ou estou esquecendo de algo? Existe uma razão específica para que a correspondência de escopo verifique apenas o fim, mas não o começo? A linguagem é a mesma desde C99, quando declarações em forloops foram introduzidas.

Ao sombrear identro do loop for, o seguinte código

#include <stdio.h>

int main()
{
    for (int i = 1; i < 5; i++) {
        printf("%d", i);
        int i = i;
        printf("%d ", i);
    }
}

saídas:

10 20 30 40

Pelo meu entendimento de shadowing, deveria ter sido icriado um novo com o valor igual ao anterior i. Isso significa que a saída que eu esperava seria:

11 22 33 44

Além disso, o código parece armazenar o novo ivalor se você incrementá-lo.

#include <stdio.h>

int main()
{
    for (int i = 1; i < 5; i++) {
        printf("%d", i);
        int i = i + 2;
        printf("%d ", i);
    }
}

isso produz:

12 24 36 48

Aparentemente, inão está sendo redeclarado a cada iteração - funciona como uma variável que foi inicialmente 0e depois incrementada a cada iteração.

O que está realmente acontecendo aqui? Como você prevê o comportamento?

Lembro-me de que durante 2 a 3 meses esse código e outras variações me davam resultados diferentes para classificação e tamanho, mas agora estou perdido, não entendo qual poderia ser o problema.

Poderia ser a atualização do 22.04 para o Ubuntu 24.04? Se sim, há uma maneira de resolver? Preciso consertar o mais rápido possível porque preciso disso para um dos meus cursos.

Eu estava testando este programa simples usando MPI no meu laptop (ubuntu 24.04LTS):

#include <mpi.h>
#include <stdio.h>

int main(int argc, char *argv[]) {
    int rank, size;

    MPI_Init(&argc, &argv);              
    MPI_Comm_rank(MPI_COMM_WORLD, &rank); 
    MPI_Comm_size(MPI_COMM_WORLD, &size);

    printf("I'm processor %d of %d!\n", rank, size);

    MPI_Finalize();  
    return 0;
}

No terminal escrevi isto:

mpicc nomeDoMeuArquivo.c

mpirun -n 4 ./a.out (também tentei mpirun -np)

A saída é a seguinte:

Eu sou o processador 0 de 1! Eu sou o processador 0 de 1! Eu sou o processador 0 de 1! Eu sou o processador 0 de 1!

Já tentei reinstalar o MPICH e verifiquei a versão no terminal com: mpirun --version

Detalhes da compilação do HYDRA: Versão: 4.2.0 Data de lançamento: Sex, 9 de fev. 12:29:21 CST 2024