"Desinstalamos 'equinusocio.vsc-material-theme', que foi relatado como problemático."
Essa notificação ainda aparece toda vez que atualizo o VScode.
Já tentei remover manualmente a extensão da pasta de extensões, mas toda vez que abro o VScode aparece um alerta pop-up informando que o VScode tentou instalá-la novamente.
No Java 21 e 23, java.net.InetAddressé declarado
public sealed class InetAddress implements Serializable permits Inet4Address, Inet6Address {
Entretanto, o seguinte código:
switch (addr) {
case Inet4Address a -> ...;
case Inet6Address a -> ...;
};
não compila com:
the switch expression does not cover all possible input values
Estou esquecendo de alguma coisa ou isso é um bug do Java?
Não estou compilando nada para nativo , em outras palavras, não estou usando native-imagedo GraalVM. Estou apenas executando a mesma classe Java (mesmo bytecode Java) com o GraalVM e, em seguida, executando a mesma classe Java (mesmo bytecode Java) com Oracle JVMs regulares.
Não importa qual versão do Java eu uso ou plataforma (eu testei em Linux e Mac). GraalVM é sempre muito mais rápido (30x) do que qualquer outra JVM regular.
Parece que as JVMs regulares não estão otimizando o método corretamente com seu JIT. Observe que o método é muito simples e pequeno.
Alguém tem alguma ideia do porquê esse é o caso e como eu poderia consertar isso na minha JVM regular? A única solução alternativa no momento é migrar para o GraalVM. É muito fácil compilar e executar o código abaixo para reproduzir o problema. Basta compilar e executar primeiro com uma JVM Oracle e depois com qualquer JVM Graal para ver a diferença.
Obrigado!
public class OracleJvm23MathBug {
// simple and small amount of math
// =====> should be optimized/compiled/inlined for sure!
private static final long doSomething(int load, int i) {
long x = 0;
for (int j = 0; j < load; j++) {
long pow = (i % 8) * (i % 16);
if (i % 2 == 0) {
x += pow;
} else {
x -= pow;
}
}
return x;
}
/*
* Execute this with OpenJDK/Zulu/Oracle JVM 23 => average 215 nanoseconds
* Now execute this with Graal23 JVM 23 => average 7 nanoseconds
*
* This bug can be observed in any platform (I tested on Linux and Mac)
*
* $ java -version
* java version "23.0.1" 2024-10-15
* Java(TM) SE Runtime Environment (build 23.0.1+11-39)
* Java HotSpot(TM) 64-Bit Server VM (build 23.0.1+11-39, mixed mode, sharing)
*
* $ java -cp . OracleJvm23MathBug
* Value computed: -550000000000
* Measurements: 10000000| Avg Time: 215 nanos | Min Time: 83 nanos | Max Time: 199750 nanos
*
* $ java -version
* java version "23.0.1" 2024-10-15
* Java(TM) SE Runtime Environment Oracle GraalVM 23.0.1+11.1 (build 23.0.1+11-jvmci-b01)
* Java HotSpot(TM) 64-Bit Server VM Oracle GraalVM 23.0.1+11.1 (build 23.0.1+11-jvmci-b01, mixed mode, sharing)
*
* $ java -cp . OracleJvm23MathBug
* Value computed: -550000000000
* Measurements: 10000000| Avg Time: 7 nanos | Min Time: 0 nanos | Max Time: 178625 nanos
*/
public static final void main(String[] args) {
final int iterations = 10_000_000;
final int load = 10_000;
NanoBench bench = new NanoBench();
long computed = 0;
for (int i = 0; i < iterations; i++) {
bench.mark();
computed += doSomething(load, i);
bench.measure();
}
System.out.println("Value computed: " + computed);
bench.printResults();
}
private static class NanoBench {
private int measurements;
private long totalTime, minTime, maxTime, time;
private final StringBuilder sb = new StringBuilder(128);
NanoBench() {
reset();
}
public final void reset() {
totalTime = time = measurements = 0;
maxTime = Long.MIN_VALUE;
minTime = Long.MAX_VALUE;
}
public final void mark() {
time = System.nanoTime();
}
public final void measure() {
long lastNanoTime = System.nanoTime() - time;
totalTime += lastNanoTime;
minTime = lastNanoTime < minTime ? lastNanoTime : minTime;
maxTime = lastNanoTime > maxTime ? lastNanoTime : maxTime;
measurements++;
}
public final void printResults() {
sb.setLength(0);
sb.append("Measurements: ").append(measurements);
sb.append("| Avg Time: ").append((long) (totalTime / (double) measurements)).append(" nanos");
sb.append(" | Min Time: ").append(minTime).append(" nanos");
sb.append(" | Max Time: ").append(maxTime).append(" nanos\n\n");
for (int i = 0; i < sb.length(); i++) System.out.print(sb.charAt(i));
}
}
}
O std::align_val_ttipo é definido como:
namespace std
{
enum class align_val_t : size_t
{
};
}
Qual é o propósito de uma enumeração tão vazia?
Qual é a diferença com um typedef?
Há algum tempo, me deparei com a ideia de como uma construção C, como (expr0, expr1, expr2), é avaliada (veja "O que o operador vírgula , faz?" para mais contexto).
Comecei a experimentar isso, especialmente dentro de macros do tipo função, e recentemente encontrei um código que é rejeitado por alguns compiladores, enquanto aceito por outros. Parece similar ao seguinte trecho:
#include <stdio.h>
int main(void)
{
int arr[] = {0};
(1, arr[0]) = 30; // <--- potentially (in)valid code
printf("%d\n", arr[0]);
return 0;
}
Como você pode ver, para que isso funcione, (1, arr[0])deve ser avaliado para lvalue arr[0], caso contrário a atribuição NÃO seria possível. No entanto, não tenho certeza se esse comportamento é válido ou não. Ele "faz sentido" e eu encontrei um uso para ele, mas também vejo por que os desenvolvedores do compilador o rejeitariam.
O código acima é rejeitado pelo gcc, clang e msvc (observe que o msvc é principalmente um compilador C++, enquanto o gcc e o clang são front-ends C):
$ gcc main.c
main.c: In function ‘main’:
main.c:6:21: error: lvalue required as left operand of assignment
6 | (1, arr[0]) = 30;
| ^
$ clang main.c -Wno-unused-value
main.c:6:14: error: expression is not assignable
6 | (1, arr[0]) = 30;
| ~~~~~~~~~~~ ^
1 error generated.
$ cl main.c /nologo
main.c
main.c(6): error C2106: '=': left operand must be l-value
Para efeito de comparação, g++, clang++ e tcc funcionam bem com o código mencionado (observe que tcc é um compilador C, enquanto g++ e clang++ são front-ends C++):
$ tcc main.c && ./a.out
30
$ g++ main.c && ./a.out
30
$ clang++ main.c -Wno-unused-value -Wno-deprecated && ./out
30
Também tentei com algumas opções de comando diferentes, como definir explicitamente o msvc para ser executado nos modos /std:c++lateste /std:c99, ou definir algo diferente -stdpara gcc/clang/g++/clang++, mas isso não mudou nada.
No começo, pensei que fosse um bug dentro do tcc, já que é o único compilador C que não rejeita o código "defeituoso", mas então verifiquei os front-ends C++ e não tenho mais tanta certeza sobre isso. Especialmente porque o msvc o rejeita, diferentemente do g++/clang++.
Para referência, estou no Linux x86_64, usando gcc/g++ 14.2.1, clang 18.1.8, msvc 19.40.33811 (executando através do wine) e tcc 0.9.28rc (mob@08a4c52d).
Há uma novidade std::inplace_vectorna biblioteca padrão C++ que parece ter uma capacidade fixa definida em tempo de compilação. Estou tentando entender um caso de uso para std::inplace_vectorinstead of std::arrayor std::vector. Parece que std::inplace_vectortem a vantagem de uma capacidade de tamanho fixo , como std::array, mas em vez disso não requer inicialização de objeto até a inserção. Mas, diferentemente de std::vector, std::inplace_vectortem uma capacidade de tempo de compilação fixa.
Alguém pode dar um exemplo de onde std::inplace_vectorisso pode ser útil?
O código a seguir produz um assembly que executa condicionalmente o SIMD no GCC 12.3 quando compilado com -O3. Para completar, o código sempre executa SIMD no GCC 13.2 e nunca executa SIMD no clang 17.0.1.
#include <array>
__attribute__((noinline)) void fn(std::array<int, 4>& lhs, const std::array<int, 4>& rhs)
{
for (std::size_t idx = 0; idx != 4; ++idx) {
lhs[idx] = lhs[idx] + rhs[idx];
}
}
Aqui está o link em godbolt.
Aqui está a montagem real do GCC 12.3 (com -O3):
fn(std::array<int, 4ul>&, std::array<int, 4ul> const&):
lea rdx, [rsi+4]
mov rax, rdi
sub rax, rdx
cmp rax, 8
jbe .L2
movdqu xmm0, XMMWORD PTR [rsi]
movdqu xmm1, XMMWORD PTR [rdi]
paddd xmm0, xmm1
movups XMMWORD PTR [rdi], xmm0
ret
.L2:
mov eax, DWORD PTR [rsi]
add DWORD PTR [rdi], eax
mov eax, DWORD PTR [rsi+4]
add DWORD PTR [rdi+4], eax
mov eax, DWORD PTR [rsi+8]
add DWORD PTR [rdi+8], eax
mov eax, DWORD PTR [rsi+12]
add DWORD PTR [rdi+12], eax
ret
Estou muito interessado em saber a) o propósito das primeiras 5 instruções de montagem eb) se há algo que possa ser feito para fazer com que o GCC 12.3 emita o código do GCC 13.2 (idealmente, sem escrever manualmente o SSE).
Do documento diz:
pub fn new(x: T) -> Box Aloca memória no heap e depois coloca x nele.
Mas “lugar” é uma palavra complicada. Se escrevermos
let arr_boxed = Box::new([0;1000]);
Será [0;1000]inicializado no heap no local?
Se escrevermos
let arr = [0;1000];
let arr_boxed = Box::new(arr);
O compilador será inteligente o suficiente para inicializar o [0;1000]heap em primeiro lugar?
Esta é a desmontagem de uma compreensão de lista em python 3.10:
Python 3.10.12 (main, Jun 11 2023, 05:26:28) [GCC 11.4.0] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import dis
>>>
>>> dis.dis("[True for _ in ()]")
1 0 LOAD_CONST 0 (<code object <listcomp> at 0x7fea68e0dc60, file "<dis>", line 1>)
2 LOAD_CONST 1 ('<listcomp>')
4 MAKE_FUNCTION 0
6 LOAD_CONST 2 (())
8 GET_ITER
10 CALL_FUNCTION 1
12 RETURN_VALUE
Disassembly of <code object <listcomp> at 0x7fea68e0dc60, file "<dis>", line 1>:
1 0 BUILD_LIST 0
2 LOAD_FAST 0 (.0)
>> 4 FOR_ITER 4 (to 14)
6 STORE_FAST 1 (_)
8 LOAD_CONST 0 (True)
10 LIST_APPEND 2
12 JUMP_ABSOLUTE 2 (to 4)
>> 14 RETURN_VALUE
Pelo que entendi ele cria um objeto de código chamado listcompque faz a iteração real e retorna a lista de resultados, e o chama imediatamente. Não consigo entender a necessidade de criar uma função separada para executar este trabalho. Isso é um tipo de truque de otimização?
Estou tentando portar uma biblioteca para compilar no MSVC. Essa biblioteca armazena dados em uma tupla de vetores ( std::tuple<std::vector<Ts>...>) e usa um iterador personalizado para iterar todos os vetores simultaneamente (semelhante ao que faz um zip_iterator).
O iterador define tipos que se parecem com isso (assumindo Ts...-> <int, int>):
`value_type` is `std::tuple<int, int>`
`reference` is `std::tuple<int&, int&>`
O problema é que no MSVC mais recente (v. 19.35), esse iterador não satisfaz o conceito de std::input_iterator, embora o satisfaça no gcc/clang.
Em uma investigação mais aprofundada, descobri que a falha se deve ao comportamento inconsistente do std::common_referenceconceito em tuplas.
O seguinte static_assertfalha no MSVC, enquanto não falha no gcc/clang
using T = std::tuple<int, int>&;
using U = std::tuple<int&, int&>;
static_assert(std::common_reference_with<T, U>, "failed common_reference_with");
Aqui está em Godbolt (com um exemplo de iterador também)
Um tipo como std::tuple<int, int>&deveria ter um " common_reference_with" std::tuple<int&, int&>? MSVC diz que não, gcc diz que sim.
Qual dos dois comportamentos deve ser esperado de acordo com o padrão em C++20 e posteriores?
Existe alguma maneira fácil de fazer com que esse iterador seja bem-sucedido nas verificações de conceito do iterador no MSVC (ou seja, forçar os dois tipos a terem uma referência comum)?
Também encontrei ótimas respostas de Eric Niebler, em std::common_reference (SO) e em proxy iterators (em seu blog) .
No entanto, não está claro para mim o que deve acontecer no C++ 20 e posterior.