Pull to refresh
19
0

Инженегр АСУТП

Send message
Если не теоретизировать, то стандартный pystone (python) работает в 100 раз медленнее, чем drystone, написанный на С.
Какое отношение имеет Windows к скорости Lisp или Python .vs. С? Прошу озаботиться чтением вопроса
Это настолько фантастическое предположение, что хотелось бы увидеть примеры.
«Я не пишу на С», «Я не знаком с миром микроконтроллеров», " скачки по указателям, которые мажут мимо кэша" может тебе не стоит пытаться обсуждать вещи, в которых ты не разбираешься?
В процессе портирования сейчас PolarSSL, но не закончен, но в целом система не POSIX, и системные вещи не так просто портировать. Особенно сетевые.
Ну актуальные, наверное, только на SVN

Хотя, если попытки были давно, можно что конкретное поиском по форуму
Пока в качестве мануалов только примеры и комментарии по исходникам. В планах подровнять комментарии для Doxygen, и получить подобную Gtk документацию есть.

По списку виджетов есть еще option_box, scrollbar, progressbar, аналог TImageButton, menu в двух вариантах, file_browser, tree_list, frame.

Для С-- есть дополнительно 14шт уникальных виджетов, хотя некоторые из них дублируют уже имеющиеся, но они с 3D или плоским дизайном. В области разработки библиотек всегда требуются добровольцы ;-)
JavaScript нет, и в ближайшее время не ожидается. Из скриптов есть LUA
Степень совместимости tcc и gcc по компилируемому исходному коду очень хорошая (им даже на пробу скорости компилировалось ядро linux), а из отличий AFAIK неполная поддержка всех возможностей __asm__ и некоторых других директив. В Колибри есть ffmpeg 2.8, собранный gcc. Так что шанс собрать есть и с помощью TinyC, но не уверен что это хорошая идея — использовать для вычислительных задач неоптимизирующий компилятор.
На самом деле, перекомпилировать не нужно. Это же Си — обычные константы!
Просто новые Визиторы должны видеть дополненный enum.

Вот интересно скорость сравнить — мой вариант сравнить с табличкой производительности.
Ассемблерный код switch я уже посмотрел — 2 инструкции сравнения )
Это Cyclic Visitor, только завернут в шаблоны.
А, действительно. Но как пишет Александреску — это самый неудачный паттерн, потому редко используемый.

В вашем примере в итоге весь выигрыш из-за неудачной реализации dynamic_cast, который вы с помощью 3х листов исходного кода, с блекджеком и шаблонами реализуете руками с помощью map<>.

На мой взгляд, не нужно множить сущности, http://ideone.com/K0KQhk вот реализация проще, расширяемая и более эффективная, т.к switch() отлично оптимизируется компилятором
Заголовок спойлера
#include <iostream>
#include <vector>
#include <algorithm>

using namespace std;
enum e_type {
	ENTITY,
	GEOMETRY,
	MODEL
};

struct visitor_base;
struct visitable 
{
    virtual void accept(visitor_base & obj) = 0;
};

struct visitor_base
{
    virtual void visit(visitable &, enum e_type type) = 0;
};

struct entity : visitable
{
    void accept(visitor_base & obj)
    {
        obj.visit(*this, ENTITY);
    }
};

struct geometry : entity
{
	void accept(visitor_base & obj)
    {
        obj.visit(*this, GEOMETRY);
    }
};

struct model : geometry
{
    void accept(visitor_base & obj)
    {
        obj.visit(*this, MODEL);
    }
};

struct test_visitor : visitor_base
{
    void visit(visitable & obj, enum e_type type)
    {
		switch(type)
		{
			case	ENTITY:
				{
					entity	&ent = (entity&)obj;  // its enough safe
					cout << "Visited ENTITY" << endl;
					break;
				}
			case	GEOMETRY:
				{
					geometry	&geo = (geometry&)obj;
					cout << "Visited GEOMETRY" << endl;
					break;
				}
			case	MODEL:
				{
					model	&mod = (model&)obj;
					cout << "Visited MODEL" << endl;
					break;
				}
			default:
				// TRAP
				;
		}
	}
};

struct modern_visitor : test_visitor // extension for new objects
{
	// add new methods for new visitables, call parent otherwise
};


int main() {
	entity E;
	geometry G;
	model M;
	vector<entity*> vec = {&E, &G, &M};
	test_visitor visi;
	for_each(vec.begin(), vec.end(), [&](entity *i){ i->accept(visi); });

	// your code goes here
	return 0;
}

Непонятно, зачем нужен dynamic_cast<geometry_visitor*>(&obj)) в типичной реализации, если obj.visit() — виртуальный? Соответственно, вызов виртуального метода быстрее, чем RTTI.
Ну и тогда проблемы, которая решается в статье, нет вообще.
Есть более-менее стандартное решение в виде Boost Multi-index Конечно, если огромный бюст вас не пугает в проекте.
А зачем работать с указателями, когда можно обойтись индексами? Тип фиксирован, максимальный размер известен, зачем городить указатели?
Ммм, ну я не знаю, откуда ты взял проблемы в своем п.3

Индексы в С это и есть указатели, точнее смещение к указателю.

Ладно, с алгоритмом обращения я похоже спутал какой то другой алгоритм, который в новостях недавно пробегал.

Прекращаю оффтопить.
Вообще то статья не о качестве исходного кода, а об оптимизации.

STL наоборот, дает еще преимущества отсутствия необходимости работы с указателями и дает некоторую защиту от выхода за рейнж при отладке.

Зачем оптимизировать метод Гаусса компилятором или пытаться прикрутить к нему STL, если есть гораздо более эффективные _алгоритмы_? Неудачный пример, но не надо конечно везде совать шаблоны, согласен.

Статически или на стеке — для скорости работы не важно. Но невозможно для компилятора создать объект неизвестного заранее размера с фиксированным адресом. Да и не нужно.
Пример стекового аллокатора я привел, как оптимизация в плане исключения запросов выделения памяти ОС.

Я уже пытался ему объяснить вкус устриц.

Если вкратце, то стоит просто посмотреть, в какой машинный код превращается программа с использованием STL при компиляции с разной степенью оптимизации. Тогда можно начинать спорить.

Смотреть после опытов
Как ни странно, но STL-шаблоны бывают эффективнее С-кода. И можно сделать кастомный аллокатор на стеке, если смущает куча.
Язык это не так уж сложно. Проблема в объеме современных фреймворков
Через несколько — на том же. А вот через десять…

На С
В общем понятно, что Вы, с помощью некоторой ловкости рук, хотите объявить несостоятельным формат IEEE754 и предложить свою модификацию или даже новейшую разработку.

Будет интересно посмотреть.

Я недавно столкнулся с задачей реализовать стандартный набор С-функций math.h на ассемблере. В процессе чего выяснилось — что набор инструкций, удобный процессору, во многом перпендикулярен привычным человеку математическим функциям.

Соответственно, разрабатывая новый формат, Вам нужно спроектировать к нему и набор инструкций, эффективно с ним работающий.

Удачи.

Information

Rating
Does not participate
Location
Россия
Registered
Activity