Pull to refresh

Comments 7

Спасибо за статью. Проверил, на некоторых примерах нужен интеллект похлеще искусственного, чтобы понять, что же оно(она?он?) отвечает.

Притом что врёт местами безбожно. Например в случае sqlite про скорость оно всё с точностью наоборот. Т.к. sqlite не умеет в оптимизацию NOT IN () чтобы юзать кортёжный индекс (type,id), т. е. получим fullscan со всеми вытекающими.
Более того не просто соврамши - а конкретно так, ибо big-O в случае NOT IN () сильно так нелинейно будет.

Прув на Tcl (просто мерить сподручнее и быстрее)
% sqlite3 db :memory:
% db eval "CREATE TABLE pages ( type TEXT, id TEXT, content TEXT, PRIMARY KEY (type, id) ); CREATE TABLE pages_done ( type TEXT, id TEXT, PRIMARY KEY (type, id) );"
% set i 0; while {$i < 10000} {incr i; set t "type$i"; set c "content $i"; db eval {insert into pages values(:t, :i, :c)}; if {$i & 1} {db eval {insert into pages_done values(:t, :i)}}}
% db eval {select (select count(*) from pages), (select count(*) from pages_done)}
10000 5000
% timerate {db eval {SELECT p.type, p.id, p.content FROM pages p LEFT JOIN pages_done pd ON p.type = pd.type AND p.id = pd.id WHERE pd.type IS NULL LIMIT 4999,1}}
4185.05 µs/# 239 # 238.95 #/sec 1000.226 net-ms
% timerate {db eval {SELECT type, id, content FROM pages WHERE (type, id) NOT IN (SELECT type, id FROM pages_done) LIMIT 4999,1}}
1520435 µs/# 1 # 0.658 #/sec 1520.435 net-ms

Для случая IN () AI был бы прав:

% timerate {db eval {SELECT p.type, p.id, p.content FROM pages p LEFT JOIN pages_done pd ON p.type = pd.type AND p.id = pd.id WHERE pd.type IS NOT NULL LIMIT 4999,1}}
3879.22 µs/# 258 # 257.78 #/sec 1000.839 net-ms
% timerate {db eval {SELECT type, id, content FROM pages WHERE (type, id) IN (SELECT type, id FROM pages_done) LIMIT 4999,1}}
2326.35 µs/# 431 # 429.86 #/sec 1002.658 net-ms

Ну, тем не менее, уже близко к уровню ответов на stackoverflow. :v)

Ну как близко... https://stackoverflow.com/a/2246793

Проблема с теми AI здесь всегда собственно обучающая выборка - на чем его натаскивают и насколько это "правильно" им разбирается, от "синтаксиса" и "морфологии" до абстракций каких-нибудь... А сарказм если, а пограничные условия какие-либо, и т.п.

Скормил GPT-3 рандомный кусок кода из ядра Linux.
Болдом - ответ GPT-3, остальное мой ввод.

Explain this code:

static bool nft_payload_fast_eval(const struct nft_expr *expr,
          struct nft_regs *regs,
          const struct nft_pktinfo *pkt)
{
  const struct nft_payload *priv = nft_expr_priv(expr);
  const struct sk_buff *skb = pkt->skb;
  u32 *dest = &regs->data[priv->dreg];
  unsigned char *ptr;

  if (priv->base == NFT_PAYLOAD_NETWORK_HEADER)
    ptr = skb_network_header(skb);
  else {
    if (!pkt->tprot_set)
      return false;
    ptr = skb_network_header(skb) + pkt->xt.thoff;
  }

  ptr += priv->offset;

  if (unlikely(ptr + priv->len > skb_tail_pointer(skb)))
    return false;

  *dest = 0;
  if (priv->len == 2)
    *(u16 *)dest = *(u16 *)ptr;
  else if (priv->len == 4)
    *(u32 *)dest = *(u32 *)ptr;
  else
    *(u8 *)dest = *(u8 *)ptr;
  return true;
}

This code is from the Linux kernel and it is used to evaluate the payload of a packet. The code is written in C.

Explain in detail

The code is used to evaluate the payload of a packet. The payload is the data part of the packet, which contains the actual information being sent. The code is written in C.

The code first checks if the base is set to NFT_PAYLOAD_NETWORK_HEADER. If it is, the code sets the pointer (ptr) to the beginning of the network header. If not, the code checks if the tprot_set flag is set. If it is, the code sets the pointer to the beginning of the transport header. Otherwise, the code returns false.

Next, the code adds the offset to the pointer. The offset is the number of bytes from the beginning of the header that the payload starts at.

Then, the code checks if the payload is too long for the packet. If it is, the code returns false.

Это очень круто!

Оно даже распознало, что в pkt->xt.thoff лежит смещение до транспортного заголовка!

Sign up to leave a comment.